Files
clide/governance/README.md
T
jpmschweitzerandClaude Fable 5 41af83f024 repoint the UI harness at the repo root; CI via make targets (T-384)
tools/ui/build.sh and serve.sh still cd'd into the app/ directory the
flattening removed, so make test-e2e / ui-dev / ui-smoke died at the
first line. The staged Gitea workflow had the same stale cd in every
job, plus a coverage gate with no coverage run before it — it now
goes through the make targets (tooling discipline: the make layer owns
env setup) with make test-coverage feeding make coverage-gate.

Fixing the paths exposed the real break: flutter build web --wasm
cannot compile the tree since the dart:ffi pivot (tree-sitter, native
PTY) — dart:ffi does not exist on the wasm target. Fence vs park vs
drop is filed as Q-50; the workflow's e2e job is withheld with a
pointer there, and T-384 sits in review until Q-50 resolves.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-06-12 01:39:24 +02:00

24 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

Resolved questions

Rejected