Files
clide/governance/README.md
T
jpmschweitzerandClaude Opus 4.7 4489765db9
test / unit + widget + golden + a11y (push) Failing after 29s
test / integration_test (xvfb) (push) Has been skipped
test / bundle smoke (xvfb 5s) (push) Has been skipped
test / daemon subprocess + web WASM smoke (push) Has been skipped
test / dart doc (lib API) (push) Failing after 27s
add D-77: drive Claude via stream-json; clide-owned unified session model
Accepted (phased). Pivot the Claude pane from the interactive tmux TUI to
the stream-json control protocol: structured events instead of transcript
tailing, permissions + AskUserQuestion handled natively via canUseTool,
persistence via --resume. Claude's tmux agent-team mode is headless-
incompatible, so teams become clide-orchestrated — N managed sessions
coordinated by a clide-hosted MCP broker, with team-awareness injected via
--append-system-prompt/--agents.

Captures the unified-session-model upside: teammate / secondary tab /
forked branch / inline subagent collapse into one primitive (a managed
session rendered as a pane), with the sidebar as the cockpit. Amends D-41
(persistence) and evolves D-75 (rendering source). Phase 1 single-agent
first; phase 2 the unified model.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-24 18:25:33 +02:00

18 KiB

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

Rejected