01 / Router files
Separate the implementation contract from long-term context
The reading list distinguishes the current V1 build contract from the longer-horizon product specification. Naming each role tells contributors which document should decide the scope of an implementation.
Source excerpt starting at line 20.20`doc/SPEC.md` is long-horizon product context.21`doc/SPEC-implementation.md` is the concrete V1 build contract.
02
State invariants across layers
The root guide lists cross-layer control-plane invariants, including atomic checkout, approval gates, budget stops, and mutation logging. These constraints apply across schemas, APIs, and interfaces.
Source excerpt starting at line 89.893. Preserve control-plane invariants.90- Single-assignee task model91- Atomic issue checkout semantics92- Approval gates for governed actions93- Budget hard-stop auto-pause behavior94- Activity logging for mutating actions
03 / House vocabulary
Classify data paths before assigning review
First-party telemetry, operator tracing, and local run events map to different source paths and review rules. Classify them by path, not by words in a filename.
Source excerpt starting at line 105.1057. Name the three data paths correctly.106This repo has three separate data paths. Do not confuse them. Match a change to a path by its file path, not by the word "observability" or "telemetry" alone.
04
Match review to where data goes
Default outbound telemetry requires contract and docs updates plus privacy review. Opt-in tracing and local run logs have separate rules, so one policy does not govern all three.
Source excerpt starting at line 125.125- **Telemetry change (strict review).** The author updates the generated contract first. The author updates `packages/shared/src/telemetry/README.md` in the same pull request. The author requests a privacy review. Reason: a Telemetry event goes to a Paperclip endpoint by default, so a mistake sends data immediately.
05 / Verification by change type
Name what the default test command excludes
The file says the cheap default runs Vitest and keeps browser suites opt-in. It reserves the fuller check for a PR-ready hand-off or changes whose scope needs it.
Source excerpt starting at line 161.161This is the cheap default and only runs the Vitest suite. Browser suites stay opt-in:162 163```sh164pnpm test:e2e165pnpm test:release-smoke166```167 168Run the browser suites only when your change touches them or when you are explicitly verifying CI/release flows.
06 / Pointing at the source of truth
Enforce UI tokens with a named check
The design-system section points to the token layer, spells out the disallowed literal values, and names the command that catches violations. Its allowlist lives with the implementation rather than in an agent's judgment.
Source excerpt starting at line 225.225`DESIGN.md` at the repo root is the source of truth for UI design decisions. The token-only rule applies to all `ui/` changes: every color, spacing, radius, type, shadow, and motion value in `ui/src/components/**` and `ui/src/pages/**` comes from the token layer in `ui/src/index.css` — no hex, raw px, arbitrary Tailwind bracket values, or raw `font-size`/`fontSize` declarations in components, outside the documented allowlist in `ui/src/index.css`. Run `pnpm check:token-gates` (`scripts/check-token-gates.mjs`) before committing UI changes — it fails on any violation not covered by that allowlist.