005 Quality

005 Quality

Status: Draft — may change (2026-10-19)

1. The question

What must a piece of work meet to be shown as checked and as done, which checks run before it lands and which after, what does a check say about what it read, how is a finding kept until it is closed, what does checking cost, and which of it is yours to set, with no refusal the Kernel does not name?

2. What we propose

Fifteen commitments in seven chapters. The module registers no capability (Kernel §13): the rights are the Kernel's (review, gate, merge, deploy in Kernel §3, separation of duties and the lab predicate at the gate in Kernel §5, and review and gate records in Kernel §15), the checks run through the Runtime, and every refusal here is the Kernel's or a setting's. Three things hold whatever the settings say: the agent that did the work never passes it (Kernel §5, enforced at the gate once built); the lab the work came from never closes a finding against it (commitment 6); and the list of commitment 3 is checked before it lands.

A. What done means

1. Done has a definition, and it is the project's. Each project MUST have a definition of what a piece of work must meet before it counts as checked and as done — which checks, by whom, with what result, for a change, a batch of a round, a release, or work that is not code (research, purchases, documents; an owner decision) — and an item that has not met that definition is not shown as done, whoever says it is. Quality carries over to non-code deliverables: independent checks from different labs, a stated done, and a check worth what it covers; for research, several labs answer separately and the answers are reconciled, with disagreement shown (never averaged away), sources cited, and any claim no source supports marked as such (an owner decision). The work items and their states belong to the Runtime and Module 008 Planning; this module defines what an item must meet to be shown as checked and as done. Spec: Specs-quality-gates (§6, §7 Open point 1) and Specs-round. Proof: none yet. Today (v0.5.0). Not built at v0.5.0 (src/policy/types.ts has no done policy, and non-code deliverable and research-reconciliation checks are not built at v0.5.0): a team's rules state it in words, and the round practice (Module 010 §2b, §2c, commitment 17; an owner decision) defines done for a batch, a round, and a release (§10 question 1).

2. Nobody's work is done on their own word. The agent that did the work MUST NOT be the one that says it passed: with agents from more than one lab the check comes from another lab than the work, because a lab is blind to its own kind of mistake (lab(author) ∌ lab(gater)), with one lab the check is by another seat and the record states that the check and the work share a lab, and with one agent the work waits for the owner. A casting and the naming method MUST be reviewed like a text, against their sources, by at least the configured number of distinct labs other than the author's, the number a setting (default 2; two owner decisions). This is the Kernel's separation-of-duties rule at the gate over the ledger's author set (Kernel §5, with the distinct-seat mode named in every record and never called cross-lab); this module adds the practice that applies it before the Kernel's gate is built. Spec: Specs-records-and-ledger and Specs-quality-gates (§6, §7 Open points 4–5). Proof: none yet. Today (v0.5.0). Followed in practice: the round's review of the whole is by a lab other than the authors' (Module 010 commitment 17 and its review-lab setting), the series' texts are reviewed by three labs none the author's (the review process), castings and the naming method are reviewed by hand across at least two other labs (not built at v0.5.0), and Module 010 proposes the same for a change's tester (its proposed tester rule, the owner pending). The tool enforces none of it at v0.5.0: src/permissions/map.ts gates none of review, gate or merge (per the Kernel's Grants section's decision record), and a seat's lab is the vendor word in .agents/team.yaml rather than a binding signed by the owner (§10 question 4).

B. The review policy

3. A check comes before or after, by what is at stake. Work that gives a power or that cannot be taken back once it is out MUST be checked before it lands, while other work may land when its automatic checks pass and be read afterwards with its findings held like any other. Always before, whatever is set: a grant, an agreement, the creating of a team (the Kernel's owner acts and administrative capabilities, §9, §10); what is published, deployed, deleted, spent, sent outside or written where others read (the Kernel's deploy and act-as, §3, and the owner's releases); real-world effects such as paying, booking, sending, or signing, which require a guard waiting for the owner's explicit confirmation (or a grant naming it, with a limit), logged and never skipped at night (an owner decision); what a person will run by hand; and any change to this policy. Beyond that list, the line is the project's to set, and work whose kind the tool cannot tell is treated as the first kind. Moving the line is an act of whoever holds the right, recorded with who and when, and does not change how open work is treated. Spec: Specs-quality-gates (§6, §7 Open point 3) and Specs-policies. Proof: test/policy.test.ts at v0.5.0 for development-mode; none yet for review-line. Today (v0.5.0). src/policy/types.ts defines the advised development-mode policy (an owner decision): under local-fast a batch lands on the integration branch after its light check and the whole-round review runs before the push, while under pr-per-change each change is reviewed before it merges; releases, publishes, and deploys stay the owner's (Module 010 §2b), and no setting in the tool names the always-before list, real-world effect guards (not built at v0.5.0), or classifies a change's kind (§10 question 3).

4. Trying it for real is a check of its own. Beside reading and unit tests, a project MUST specify which work requires a real run of the built tool in an isolated environment — and for work that changes what a person does by hand, a run of exactly that — because no number of readings stands in for it. Spec: Specs-quality-gates (§3.3, §4.2, §5 Rule 2, §7 Open points 7, 11). Proof: scripts/e2e.ts, test/e2e.test.ts, test/docs.test.ts, scripts/conformance.ts, scripts/coverage.ts, test/scripts/coverage.test.ts at v0.5.0. Today (v0.5.0). Built in part: scripts/e2e.ts runs real commands against fake seats in an isolated multiplexer session locally (refusing when the machine exceeds its load gate); test/docs.test.ts runs every command-page example against a fixture project; scripts/conformance.ts and scripts/coverage.ts verify screen conformance fixtures and require stated provenance (220 real captures and 49 constructed fixtures in contract/capture-coverage.json at v0.5.0); and the pre-release live matrix (an owner decision) and scripted acceptance pass (an owner decision) run before release, though which work requires which real run is not a policy in src/policy/types.ts (§10 question 7).

C. What a check is worth

5. A check says what it looked at. Every pass and every failure MUST name the exact state of the work it read, what it ran and with what, and what it did not cover, and a pass on an earlier state MUST NOT count as a pass on a later state: the Kernel's gate record is keyed to an effect id over the changed paths, the destination tree and ref, the base, and the policy (Kernel §15), and a merge consumes a pass whose effect id equals its own. Spec: Specs-quality-gates (§3.4, §5 Rules 3–4) and Specs-records-and-ledger. Proof: external gate script tests in the project's docs repository; none yet in src/ at v0.5.0 for gate records. Today (v0.5.0). At v0.5.0 (52db9b75), src/ records no Kernel §15 gate record and src/commands/commits.ts is read-only, while test/docs.test.ts pins command examples to declared fixtures; outside the v0.5.0 binary, the external gate scripts in the project's docs repository and the RFC round practice (the review process frozen-at review commits) record the commit SHA, branch, and selected or skipped test files (push-gate.sh stamp, hourly-suite.zsh SHA-named report, and light-check.sh selection reasons; §10 question 2).

6. What a check finds is held until it is closed. A blocking finding MUST keep the work from counting as done until it is closed by the owner, by the one who found it, or by an agent of another lab than the work came from — never by the lab the work came from — naming the state it was closed on and reopening automatically when that state changes. A finding is kept as a durable record rather than lost in a conversation. Work that had already landed when a finding was raised is shown as not done from then on; reverting or taking it back is a decision of whoever holds that right, never something the tool does by itself. Spec: Specs-quality-gates (§3.4, §3.5, §5 Rule 4, §7 Open point 2). Proof: external gate script tests in the project's docs repository; none yet in src/ at v0.5.0. Today (v0.5.0). At v0.5.0 (52db9b75), no finding record or automatic reopening exists in src/store/; in external practice, findings live in review notes, messages, and tracker issues, plus the shared and per-branch RED marker files written by the external gate scripts hourly-suite.zsh and hub-sweep.zsh that stop merges until cleared by the lead (an owner decision; Module 010 commitment 20; §10 question 2).

D. Rights and cost

7. Accepting is a right. Accepting work as ready to ship (gate over a required check, merge into a trunk, deploy to an environment; Kernel §3, §9) and accepting work with an open blocking finding MUST be separate capabilities (by default the owner's alone, an agent's only where granted by name), and every acceptance over an open finding MUST be recorded with the finding it passed over. An agent may check without holding the right to accept. Until agents are contained at the OS level, a missing check keeps the tool from calling work done, but cannot stop an agent that holds repository credentials from landing it (Kernel §12). Spec: Specs-grants, Specs-records-and-ledger, and Specs-quality-gates (§6, §7 Open point 12). Proof: test/permissions/resolve.test.ts at v0.5.0 (vocabulary and capability map); none yet for review/gate/merge/deploy gate enforcement or the open-finding override handoff. Today (v0.5.0). src/permissions/grants.ts lists review, gate, merge, and deploy in GRANT_CAPABILITIES, and src/permissions/map.ts gates no command on them in 0.5.0 (the Kernel's Grants section decision record, point f); merges and releases follow the round practice (Module 010 §2b), and for 0.5.0 the merge itself waits on the owner's go (an owner decision), while clearing a red marker is a manual file rename not recorded by the tool, and the Kernel capability/record handoff for accepting over an open blocking finding is not yet defined (until defined and reviewed, a Quality policy alone cannot authorize an agent to bypass a blocking finding or supply a Kernel gate input; §10 question 12).

8. You see what checking costs, and what it found. For each kind of check, TeamCLI SHOULD measure and report how long it held work back, what it consumed, and what it found that earlier checks did not (via Module 004 Measurement), so the before/after line of commitment 3 is chosen on evidence: a check that never finds anything is a cost, and a check that is skipped is a risk, and both are shown. Spec: Specs-quality-gates (§3.4, §7 Open point 8) and Specs-round. Proof: none yet in src/ at v0.5.0. Today (v0.5.0). At v0.5.0 (52db9b75), no daily check-cost or escaped-finding report is built in src/; outside the v0.5.0 binary, the external gate scripts in the project's docs repository print per-step durations, selected file counts, failure summaries, and reference-change measurements (Module 010 commitment 18; §10 question 8).

E. The checks the tool and the team run

9. Every commit and every request to merge carries its author's signature and no forbidden line. Every agent commit and pull-request body MUST carry its author seat's signature trailer in its required position, contain no forbidden pattern, and match the seat's observed model, enforced across the commit hook, the push gate, and CI under the commit-signature policy (three owner decisions). Spec: Specs-quality-gates (§3.1, §3.2, §4.1, §4.2, §5 Rules 1–2, §7 Open point 9). Proof: test/commits.test.ts, test/pr.test.ts, test/check/run.test.ts, test/check/message.test.ts, scripts/check-pack.ts at v0.5.0. Today (v0.5.0). src/commands/commits.ts (team commits check), src/commands/pr.ts (team pr check), and src/check/ check the team file's identity signature templates, trailer-only last paragraph, human/merge exemptions, and forbidden patterns; .github/workflows/ci.yml runs the check through the old team check <ref> alias (which says it is read through 0.3.3 and prints that notice on every run) on every pull request, push to main, and nightly run against .github/team.yaml, and runs scripts/check-pack.ts to refuse packed tarballs containing internal ticket references. The commit-signature policy object, worktree commit-msg hook (present on the integration branch at commit e1b0adb6, which --no-verify skips, and not at v0.5.0), --point push_gate CLI flag, and observed-model matching in commits check are not in v0.5.0 (52db9b75) (§10 question 9).

10. The suite and its gates run at three paces: per batch, per push, per hour. A project's quality gates MUST run at three automated paces during a round — a dependency-aware per-batch light check bounded by machine light slots with a background heavy-slot hub sweep, a pre-push gate against origin/main that scans private patterns and stamps the passed commit, and an hourly full suite on the integration tip in a heavy slot whose red marker halts merges into the integration branch until cleared (an owner decision; Module 010 commitments 12 and 20) — plus a pre-release acceptance pass (an owner decision). Spec: Specs-quality-gates (§3.3, §3.4, §4.2, §4.3, §5 Rules 2–4) and Specs-accounts-and-gates (§3.5, §3.6, §5 Rule 6). Proof: package.json, .github/workflows/ci.yml at v0.5.0, and external gate script tests in the project's docs repository. Today (v0.5.0). package.json (bun run ci) and .github/workflows/ci.yml are built in the v0.5.0 (52db9b75) release; outside the v0.5.0 binary, the three round paces run as external zsh scripts in the docs repository (the scripts are light-check.sh, push-gate.sh, hourly-suite.zsh, hub-sweep.zsh and gate-common.sh; an owner decision makes declared gates new work, first in 0.5.1 after the event-driven team send; the Runtime (commitment 52) names the team gate command — Specs-accounts-and-gates §4.2). For a few hours of 2026-10-17 the external hourly script excepted one failure by name (the broker's claim-lane stress test, red under local load; hosted CI had passed it, an owner decision) from writing a marker when it was the only failure; the entry went with the test's fix the same afternoon, and the script today carries no named exception: every failing scene writes the marker (§10 question 6).

11. The review of the whole, by a lab other than the authors'. Under local-fast, a round's work MUST be reviewed whole at the round's close by a reviewer from a lab other than the authors', and under pr-per-change each change MUST be reviewed before merge, while a project's governance texts MAY advise stricter multi-lab reviewer counts and unanimity rules (the review process). A casting and the naming method are reviewed like a text, against their sources, by at least the configured number of distinct labs other than the author's, the number a setting (default 2; two owner decisions). Spec: Specs-quality-gates (§6, §7 Open point 5) and Specs-policies. Proof: test/policy.test.ts at v0.5.0 for board and review-terms; none yet for review-lab. Today (v0.5.0). Followed by hand in round closes, RFC rounds, and casting reviews; src/policy/types.ts at v0.5.0 (52db9b75) includes the advised project-level board and review-terms policies, while review-lab and the casting review-lab count setting are not built at v0.5.0.

F. Settings

12. All of it is yours to set, by project. The definition of done (done), the before/after review line (review-line), which labs review which (review-lab), which work requires a real run (real-run), who may accept with an open finding (accept-with-finding, subject to the Kernel capability/record handoff of §10 question 12), and how many reviewers must agree (review-count; distinct from the minimum number of distinct labs for a casting or naming-method review, review-labs-min, default 2, in the Kernel's Policies section and Specs-policies under an owner decision) MUST be configurable as policies that inherit across entity, project, and team (tightening only), with the careful default when unset: checked before landing, by another agent, from another lab where available. Spec: Specs-quality-gates (§6, §7) and Specs-policies. Proof: test/policy.test.ts at v0.5.0 for development-mode, board, review-terms; none yet for the six proposed policies. Today (v0.5.0). src/policy/types.ts at v0.5.0 (52db9b75) ships development-mode (default 'local-fast', an owner decision), board, and review-terms, while .agents/team.yaml carries identity for commit and pull-request signatures (src/check/config.ts); none of done, review-line, review-lab, real-run, accept-with-finding, review-count, or review-labs-min is built at v0.5.0.

G. Release records and settled suite rules

13. A release is checked against its public and project records. TeamCLI MUST verify a declared release's public npm version, checksums, and (when trusted_publishing is enabled) SLSA v1 provenance attestation, its Git tag ancestry on the default branch, its published GitHub release channel against the version's SemVer 2.0.0 prerelease part, and its calendar-valid CHANGELOG.md entry, plus (when configured as a pair) its completed Linear milestone and post-release status update through a single bounded Keychain-authenticated read and (when configured as a pair) its single-line public activity marker on the default branch, combining part outcomes as unknown over missing over pass without short-circuiting required reads and warning when npm's next dist-tag trails latest, while mutating no state. Spec: Specs-release (§§3–6). Proof: test/release/section.test.ts, test/release/grammar.test.ts, test/release/checks.test.ts, test/release/records.test.ts, test/release/command.test.ts, test/scripts/check-release-date.test.ts, test/release-workflow.test.ts at v0.5.0. Today (v0.5.0). Built at v0.5.0 (52db9b75): src/commands/release.ts (team release check <package@version> [--json] [--file <path>]), src/file/sections/releases.ts, src/release/, schema/release.schema.json, and scripts/check-release-date.ts implement the .agents/team.yaml releases validation, the four base checks (npm, tag, github, changelog), the dist-tags warning, and the optional linear and activity checks under the 14-read / 28-attempt budget.

14. A named exception in the hourly suite is the owning team lead's, recorded and expiring with the fix. Only the lead of the team that owns the suite MAY add a named exception in the hourly suite, under a delegation record; the exception MUST be recorded in an exceptions file beside the marker with the issue id and the fix's commit, and MUST land with the fix or within the day, or else the next run removes it (an owner decision). Spec: Specs-quality-gates (§5 Rule 4, §7 Open point 6). Proof: none yet at v0.5.0. Today (v0.5.0). Not built at v0.5.0 (52db9b75) or in the external gate script (hourly-suite.zsh): hourly-suite.zsh reads no exceptions file beside the marker and performs no automatic next-run removal; the one exception on 2026-10-17 lived in the script and was removed by hand with the fix (commitment 10; §10 question 6).

15. Capture provenance keeps its name, and code test coverage is a per-package report without a floor policy. Screen-fixture verification MUST keep the name capture provenance, a code test-coverage floor policy MUST NOT be added under commitment 12, and code test coverage SHOULD be reported as a per-package coverage report only (an owner decision). Spec: Specs-quality-gates (§3.3, §5 Rule 2, §7 Open point 10). Proof: test/scripts/coverage.test.ts at v0.5.0 for capture provenance; none yet at v0.5.0 for a per-package code coverage report. Today (v0.5.0). Built in part at v0.5.0: scripts/coverage.ts checks screen-fixture capture provenance and src/policy/types.ts has no code test-coverage floor policy; a per-package code test-coverage report is not built at v0.5.0 (§10 question 10).

3. Why

• RFC 005's founding incidents. Five readings by one lab passed a fault a second lab found on its first read; three rounds of reading and several thousand unit tests passed two faults one real run found; a review pass named the state it read and the release changed three times after it; a small change waited fifty minutes for a third reading; and in the first week agents reported their own work as verified with no way to tell which was.
• The round of 2026-10-16 and 2026-10-17 (an owner decision). Cutting a release candidate on light checks alone produced a red full suite (32 failing tests across 6 files on rc.3.1 while every light check was green; Module 010 commitment 20), leading the owner to approve the dependency-aware light check and the hourly full suite on the integration tip, with no release candidate cut without a green full suite (an owner decision). The hourly suite's first run on the integration tip found one failure, the claim-lane stress test, fixed that afternoon: the light check sees what it selects.
• Commit signatures (three owner decisions). A squash merge added a trailing line that pushed the agent signature out of git's final trailer block and broke main's signature check, which is why squash and rebase merges are disabled (an owner decision); knowledge-base commits landed with another seat's session line and no author signature (an owner decision); and CI refused eight commits on the release branch whose signatures named a CLI or an unseated model or omitted a signature on reverts, rewritten on the owner's word (an owner decision).
• The output contract (an owner decision). After reading three commands' screens on 2026-10-17, the owner required one documented output contract and --json schemas across all commands, checked by golden outputs and schema checks in the acceptance pass (an owner decision).
• Machine load protection. Roughly thirteen seats running the old unfiltered light check against origin/main drove machine load to ~95; comparing against the integration merge-base, capping light slots at four, and deferring hub importers to a background heavy-slot sweep bounded the load (gate-common.sh, light-check.sh).

4. What it costs, and what it does not cover

• Reviewer bias and shared blind spots. An agent counted on throughput has an incentive to pass work (a second lab reduces that risk without eliminating it), and two labs can still share a blind spot that only a real run catches within the scenarios it tries.
• Checking after means temporary exposure. Under local-fast, a fault caught by the hourly suite has already landed on the integration branch and been built upon for up to an hour.
• Hold time and token spend. Every check holds work back and uses what the owner pays a lab for; the light check's own budget is a minute (Module 010 commitment 12; the scripts' README aims at one to two), and a lobby-wide change still takes over three (198 s at the live defaults).
• Correctness, not taste. Checks verify that work does what was asked and breaks nothing shown to them, not aesthetic judgment.
• Not a wall before OS containment (Kernel §12). Until OS containment ships, an agent holding repository credentials can merge or publish without a check; TeamCLI refuses to call such work done, but cannot physically block it.
• Not covered here: who holds review, gate, merge, and deploy and the gate's enforcement mechanics (Kernel §3, §5, §9, §15; Runtime resolver); the round steps and daily report (Module 010 Workflow); work items and states (Module 008 Planning, Runtime); delivering findings to seats (Module 002 Communication); check cost analytics (Module 004 Measurement); and team memory (Module 003 Memory).

What this release must not pretend

Along with the must-not-pretend list of the Kernel's Grants section (no review, gate, merge, or deploy command gating and no separation-of-duties enforcement at a gate in 0.5.0), v0.5.0 (52db9b75) must not pretend:

• The round gates live outside the binary in 0.5.0. The light check, push gate, hub sweep, and hourly suite are external zsh scripts in the docs repository (the external gate scripts (light-check.sh,push-gate.sh,hub-sweep.zsh,hourly-suite.zsh,gate-common.sh), frozen at 73c3391a588aa85a2403c05dee5e5013d34ca664; an owner decision makes declared gates new work, first in 0.5.1 after the event-driven team send; the Runtime (commitment 52) names the team gate command — Specs-accounts-and-gates §4.2), and CI lives in .github/workflows/ci.yml; the v0.5.0 binary ships team commits check, team pr check, team release check, the model-drift lines of team check and team status, and scripts/check-pack.ts.
• Done is a word. The tool reads no done definition and marks no work item as checked or done.
• A finding is a message or a marker file. Clearing a red marker is a manual file rename (RED.understood-<time>); nothing in src/ records finding closures or reopens a finding when code changes.
• A green check applies only to the commit it read. A pass is on one commit SHA, never a release, and the light check sees only the subset of tests its dependency graph selected.
• A seat's lab is an unsigned team-file field. .agents/team.yaml records vendor, not an owner-signed lab binding, and cross-lab review is not checked by the tool.
• A red is a red (script exceptions are ungoverned by the tool). For a few hours of 2026-10-17 the hourly suite script excepted one failure under load by name (the broker's claim-lane stress test) until the test's fix (an owner decision); that exception was set and ended by the script's authors and is recorded nowhere but in its git history (§10 question 6, settled for future builds in commitment 14).

5. What would change our mind

• Post-merge reviews finding no more faults than unreviewed work (from RFC 005): then after-the-fact review is ceremony and the review line belongs before merge.
• Second-lab reviews finding nothing the first lab missed over months (from RFC 005): then cross-lab review preference is cost without return; the round-close review will show this first.
• Teams setting every review line to "after" within a week (from RFC 005): then the careful default is wrong (local-fast already chooses after-merge review for ordinary batches within an integration round, an owner decision).
• External project tooling already holding these records (from RFC 005): then this module should read the project's existing tool and add only the cross-lab rule and agent attribution.
• The hourly suite never catching anything the dependency-aware light check missed over weeks: then the light check's selection is sufficient and the heavy slot returns to builds.

6. What is true today

"Today" separates the released TeamCLI code at v0.5.0 (52db9b75) from the external gate scripts in the project's docs repository.

#	Commitment	Today (v0.5.0 52db9b75; external gate scripts)
1	Done has a definition, the project's	Not built at v0.5.0 in src/: the round practice defines done; the tool applies none
2	Nobody's work on their own word	In practice: whole-round review by another lab, three-lab RFC reviews, and cross-lab casting reviews; review, gate, and merge gate no command at v0.5.0
3	Before or after, by what is at stake	In part: development-mode (src/policy/types.ts) is an advised policy (local-fast vs pr-per-change); no always-before list, real-world effect guard, or change-kind classifier is built at v0.5.0
4	Trying it for real	In part: bun run e2e (scripts/e2e.ts), executable docs examples (test/docs.test.ts), conformance captures (220 real and 49 constructed in contract/capture-coverage.json), live matrix (an owner decision), and acceptance pass (an owner decision); no real-run policy
5	A check says what it looked at	In practice outside src/: external gate scripts (push-gate .ok stamps, SHA-named suite reports, light-check selection reasons), test/docs.test.ts fixtures, and the review process frozen-at commits; no Kernel §15 gate record in src/ at v0.5.0
6	A finding held until closed	In part outside src/: external gate scripts (hourly-suite.zsh, hub-sweep.zsh) write RED and RED-<ref> markers that halt merges in practice; no store finding record or automatic reopening in src/ at v0.5.0
7	Accepting is a right	Not enforced at v0.5.0: review, gate, merge, and deploy are in GRANT_CAPABILITIES (src/permissions/grants.ts) and gate no command; Kernel override handoff for open findings is unresolved (§10 question 12)
8	What checking costs and found	In part outside src/: external gate scripts log durations, file counts, and failures; no aggregated cost or escaped-finding report in src/ at v0.5.0
9	Every commit and PR carries its signature and no forbidden line	Built for team commits check (src/commands/commits.ts), team pr check (src/commands/pr.ts), CI (.github/workflows/ci.yml), and scripts/check-pack.ts; commit-signature policy, worktree commit-msg hook (e1b0adb6 on integration), --point, and observed-model match are not at v0.5.0
10	The suite and its gates at three paces	Built in package.json (bun run ci) and .github/workflows/ci.yml at v0.5.0, and in external gate scripts (light-check.sh, push-gate.sh, hourly-suite.zsh, hub-sweep.zsh; the one named exception for the claim-lane stress test went with its fix on 2026-10-17); team gate integration is 0.5.1, first after the event-driven team send (an owner decision; the Runtime (commitment 52), Specs-accounts-and-gates §4.2)
11	The review of the whole, by another lab	In practice; board and review-terms are in src/policy/types.ts as advised project strings, while review-lab and the casting review-lab count setting are not built at v0.5.0
12	Yours to set, by project	In part: development-mode, board, and review-terms are in src/policy/types.ts, and identity is in .agents/team.yaml; done, review-line, review-lab, real-run, accept-with-finding, review-count, and review-labs-min are not built at v0.5.0
13	Release checked against public and project records	Built at v0.5.0: team release check <package@version> (src/commands/release.ts, src/file/sections/releases.ts, src/release/), schema/release.schema.json, and scripts/check-release-date.ts
14	Named hourly-suite exception by owning lead, recorded and expiring	Not built at v0.5.0 or in hourly-suite.zsh: hourly-suite.zsh reads no exceptions file beside the marker and performs no next-run removal (an owner decision)
15	Capture provenance named as such; per-package coverage report only	In part: scripts/coverage.ts verifies capture provenance and src/policy/types.ts adds no floor policy; per-package code coverage reporting is not built at v0.5.0 (an owner decision)

Three are built (9, 10, 13), nine hold in part or in practice (2, 3, 4, 5, 6, 8, 11, 12, 15), three are not built at all (1, 7, 14) (RFC 005's table of 2026-10-07 had one of nine in part): what moved is the practice and the scripts around the tool, plus the commit, pull-request, and release checks in the tool.

7. The security boundary

• Integrity (M), not OS authority (A) (Kernel §11, §12, §14). Every check and gate marker today is an integrity guard: a seat that runs a suite and reports green is trusted as far as same-user honesty, and the push-gate .ok stamp and RED markers are files in the same OS user's workspace (an owner decision).
• Signed-commits roster in CI (.github/workflows/ci.yml, src/check/). CI verifies commit and pull-request signatures against the repository's .github/team.yaml and refuses signatures from unknown models or roles (an owner decision), though CI does not read the local Runtime registry.
• Redacted pattern and tarball scans (gate-common.sh, scripts/check-pack.ts). The private-patterns scan reads a pattern file outside every repository (an owner decision) and prints only file:line (or commit:<sha>:<line>) and the pattern line number — never the matched text; scripts/check-pack.ts likewise prints only the offending file path inside the tarball, never the matched internal ticket identifier.
• Machine slot bounds and isolated hourly worktree (light-check.sh, hourly-suite.zsh). Light and heavy slot directories bound concurrent test load and release on signals; the hourly suite runs in a dedicated detached worktree and treats a worktree or install failure as an ERROR rather than a false RED tip.

8. Where it sits, and what it leaves to others

Tier 3, the fifth module in the reading order, after Module 004 Measurement and before Module 008 Planning. The Kernel (Kernel) owns the capabilities and gates (review, gate, merge, deploy, separation of duties and the lab predicate in §5, and review/gate records and effect ids in §15); the Runtime (Runtime, including commitment 52) owns the resolver, commands, store, and team gate slot runner; Module 010 Workflow (010-Workflow) owns the round, its steps, its timings, and its daily report, citing this module for done and review-lab; Module 008 Planning (008-Planning) owns the work items; Module 004 Measurement measures check costs and findings; Module 002 Communication delivers findings; and Module 003 Memory retains lessons learned. Project-specific board and reviewer rules live in Board.

9. Prior art and alternatives

• Light checks against origin/main vs integration merge-base and hub sweep (gate-common.sh, light-check.sh). Comparing every branch against origin/main re-ran the entire integration branch delta on every batch and drove machine load to ~95 across ~13 seats; comparing against the newest integration merge-base, capping light slots at 4, and deferring >10-importer hub modules and >60 depth-1 tail files to a background heavy-slot sweep (hub-sweep.zsh) kept per-batch checks fast while preserving coverage.
• Cutting release candidates on light checks alone vs hourly full suite (an owner decision). After a release candidate cut on light checks alone failed 32 tests in 6 files on a full suite run, the hourly full suite on the integration tip and the mandatory green full-suite gate before any release candidate were adopted (an owner decision).
• Squash/rebase merges vs merge commits (an owner decision). Squash merging appended a trailer after the agent's signature and broke trailer-block verification on main; disabling squash and rebase merges in favor of two-parent merge commits preserved the author's final trailer block.

10. Open questions

1. The done setting's shape. Should done be a policy in the form of the Kernel's Policies section per kind of work (a change, a batch, a release), naming the required checks and their order and read by round close and work-item states (checked and done in Module 008), or should Module 010's round-close sequence stand as the only definition for now?
2. For the build: The finding record. The Kernel's review record (§15) is the natural carrier of a finding and its closing, and the store does not yet exist. Decide the first record in the Runtime store (state raised on, who may close it — owner, finder, or another lab — and automatic reopening on state change), and whether the RED / RED.understood-<time> markers become its first record kind.
3. The always-before list. Most of RFC 005's always-before list is already the Kernel's (grant, agree, create, deploy, and owner releases); what remains for a setting is "what a person runs by hand", "written where others read", and "this policy itself". Decide whether review-line is a policy or part of Module 010's round, and whether the tool can classify a change's kind.
4. For the build: The lab binding. Kernel §5 requires a seat's lab as an owner-signed binding identifying the adapter and launch configuration, whereas at v0.5.0 it is the vendor field in .agents/team.yaml and the registry record. Decide how the signed team file and registry record satisfy the Kernel §5 binding.
5. One home for review-lab and review-count. Module 010's settings table defines review-lab, while RFC 005 placed the review policy here. Propose defining review-lab and review-count in this module's commitment 12 policy set, cited by Module 010.
6. A named exception: settled by an owner decision: only the lead of the team that owns the suite may add a named exception in the hourly suite, under a delegation record; it is recorded in an exceptions file beside the marker with the issue id and the fix's commit; it lands with the fix or within the day, else the next run removes it (commitment 14).
7. Which work needs a real run. Decide the real-run policy: which kinds of change require a local bun run e2e pass before round close, and whether the pre-release live matrix (an owner decision) is codified as a checklist read by the round.
8. For the build: The report, and whether Commitment 8 is MUST or SHOULD. Module 010 commitment 18's daily report is the first surface for check cost and effectiveness; decide its columns for this module (per check: hold time, files run, findings raised, and escaped findings caught by the next check), and whether Commitment 8 should be strengthened from SHOULD to MUST so that check cost and effectiveness reporting (with unknown measurements reported explicitly with source and timestamp rather than omitted) matches accepted RFC 005 §2 commitment 8 (will see) and Module 004 commitment 2 (MUST).
9. For the build: The commit-signature policy's three points. CI checks through the old team check <ref> alias, which says it is read through 0.3.3 and prints that notice on every run; the push gate checks on a CLI that reads --point; the hook exists on the integration branch (commit e1b0adb6) and in no release. Decide the order of the three in 0.5.x (the policy says all three, refuse each) and whether CI's roster should be the registry's rather than a team file in the repository.
10. Coverage: settled by an owner decision: keep the name "capture provenance"; a code test-coverage floor policy MUST NOT be added; a per-package coverage report only (commitment 15).
11. For the build: The acceptance pass's place. The scripted scenes of 0.5.0 (an owner decision) run outside bun run ci against the installed binary in a scratch home before release. Decide whether they join bun run ci or stay a release check, and whether their scene result lines become the first Kernel §15 gate records of commitment 5.
12. For the owner and the Kernel: Reconciling acceptance over an open finding with the Kernel. Commitment 7 preserves accepted RFC 005's rule that accepting work with an open blocking finding is a separate right from ordinary acceptance (gate, merge, deploy), while §2 and §8 state that this module registers no capability (Kernel §3's capability vocabulary is closed, Kernel §5 excludes module records from constraint predicates, and Kernel §13 forbids a module from creating a gate) and Commitment 12 names accept-with-finding as a proposed policy. How are the Kernel capability and record handoff defined and reviewed so that a Quality policy does not by itself authorize an agent to bypass a blocking finding or make its payload a Kernel gate input?

12. Links to the spec

• Specs-quality-gates §3.1 (.agents/team.yaml identity section and commit-signature), §3.2 (team.commits and team.pr JSON schemas and Finding record), §3.3 (contract/capture-coverage.json provenance matrix), §3.4 (gate stamps, hub-sweep queue, hourly-suite reports, <sha>.pending, and RED markers), §3.5 (proposed store finding record), §4.1–§4.3 (team commits check, team pr check, bun run ci, bun run e2e, scripts/check-pack.ts, and gate script invocations), §5 Rules 1–4, and §7 Open points 1–12.
• Specs-release §3.1 (.agents/team.yaml releases section), §3.2 (SemVer 2.0.0 and channel grammar), §3.3 (team release check plain table and schema/release.schema.json team.release v1 JSON schema), §3.4 (RELEASE_RECORDS_QUERY Linear GraphQL query), §4.1–§4.3 (team release check <package@version>, team check / team doctor validation, and scripts/check-release-date.ts), §5 Rules 1–7, §6 (release.* exit codes), and §7 Open points 1–2.
• Specs-accounts-and-gates §3.5 (private-patterns.txt), §3.6 (gate slot lock owner format), §4.2 (team gate), and §5 Rule 6.
• Registries contributed to: registries/exit-codes.md (commits.*, pr.*, release.*), registries/policy-names.md (development-mode, board, review-terms, and proposed commit-signature, done, review-line, review-lab, real-run, accept-with-finding, review-count; review-labs-min is contributed by Specs-policies).