Files
clide/governance/README.md
T
jpmschweitzerandClaude 2b93bb1cb2
test / unit + widget + golden + a11y (push) Failing after 26s
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 1m0s
D-70/71/72: lock in the T-99 IPC server architecture choices
Three architectural commitments T-124 needs settled before any code:

* D-70 — socket path is per-workspace and deterministic
  (`$XDG_RUNTIME_DIR/clide/<sha256(workspace)[:16]>.sock`). No env
  override; matches the per-repo tmux socket pattern (D-41) so users
  see one consistent shape across clide's process boundaries.
* D-71 — file permissions are the only gate: `0600` on the socket,
  `0700` on the parent. Capability-token auth stays a Tier-6 concern
  tracked by Q-1.
* D-72 — multi-connection accept loop, serial dispatch on the main
  Flutter isolate. Per-handler isolate offload (the NativePty /
  SchedulerService pattern) is available where it matters; the IPC
  layer doesn't impose isolate-safety across every subsystem.

T-124's description updated to inline the three decisions so the
implementer starts with the contract, not a discovery pass.

Co-Authored-By: Claude <noreply@anthropic.com>
2026-05-18 14:43:09 +02:00

17 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