Files
clide/governance
jpmschweitzerandClaude Opus 4.8 b7f3731394 decide D-85 (event bus delivery) + D-86 (MCP tool surface); resolve Q-2/3/32/33
D-85 — event bus delivery semantics, resolving Q-2 + Q-3: bounded
per-subscriber ring buffer with drop-oldest back-pressure (producer never
blocks, subscribers never killed) and a gap marker so a pull reader detects
loss; in-memory cursor retention serves `clide events --since`; if
persistence is ever needed it is bus-owned, not a subscriber-subsystem —
reversing ADR 0006's unreasoned open-questions footer.

D-86 — MCP tool surface, resolving Q-32: expose the full mcp__clide__*
namespace but generate tools/list from the co-registered command registry
(D-74) that already feeds CLI + palette, so breadth costs no second
maintained surface; per-command MCP opt-out for poor-fit verbs.

Q-33 drift-fixed: was already closed by D-73 (SSE only) but the index still
listed it open; re-confirmed SSE-only, stdio/WS not added.

Refines T-223 (cursor pull events) and T-225 (MCP reachable) — both now
unblocked and scoped. Index regenerated by pql decisions sync.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-06 12:25:24 +02:00
..

Decisions, Questions, Rejected

This directory holds structured planning records that pql parses into pql.db. Each record is a ### [DQR]-N: Title heading inside a markdown file. Files live in three per-type subdirectories:

  • decisions/<domain>.md — confirmed design decisions
  • questions/<domain>.md — open questions that may resolve into decisions or rejected proposals
  • rejected/<domain>.md — rejected proposals (kept for the audit trail)

The parser infers domain from the filename stem and record type from the parent subdirectory.

D-records that propose implementation work link to initiative-type tickets via decision_ref. Run pql decisions show <id> --with-tickets to inspect implementation status.

Start with this canonical set; create files as records land in each domain:

  • architecture — structural commitments (storage, layering, languages, libraries)
  • process — team workflow (commits, branches, releases, reviews)
  • design — user-facing surface (UX, UI, public APIs)
  • coding-conventions — team-internal code shape (style, lint, file layout)
  • testing — quality strategy (coverage, layers, gates)

You might also want, project-permitting:

  • accessibility — if you ship user-facing software
  • security — if you handle user data or network surfaces
  • licensing — if you release open-source or commercial
  • documentation — if user-docs are non-trivial
  • deployment — if shipping is non-trivial
  • performance — if you have perf budgets / SLOs

Decisions

Open questions

Resolved questions

Rejected