Summary
Decide whether the ## Verification Discipline section in the hub AGENTS.md should be carried to the fleet, and if so, genericize the hub-specific parts and reconcile a small thematic overlap with the new Repository Boundaries and Write Safety section.
Filed as a deliberate follow-up to keep #367 (the write-safety incident change) a single-incident change.
Current state
## Verification Discipline was added to the hub AGENTS.md on 2026-07-19 (c81420d), but it is not in the spec/files.json AGENTS.md sections allowlist, so it is hub-only and does not propagate to downstream repos. #367 added Repository Boundaries and Write Safety as the first carried section; Verification Discipline sits just below it in the same file, uncarried.
The section's rules:
- A test must assert the mechanism it names.
- Gates, filters, and gate-like watchers fail loud, never narrow quietly.
- Run the repo's whole lint gate before every push.
- Editing CRLF files programmatically:
. matches \r in a regex.
- A green check is not evidence the work happened.
- A workflow change is only fully exercised by CI.
- A review flags an instance; fix the class.
The decision
Most of these are fleet-general (test discipline, run-all-linters, green-is-not-done, CRLF-regex hazard, fix-the-class) and would benefit every derived repo. A few lean hub/workflow-specific and would need genericizing or dropping before carrying:
- The
WORKFLOW.md D8.4 cross-reference (identity-allowlist gate).
- The codegen
changes-job reference under "Branching Model".
- "A workflow change is only fully exercised by CI" (assumes the repo ships the shared workflow set).
If carried
- Add
"Verification Discipline" to the AGENTS.md sections allowlist in spec/files.json.
- Genericize or footnote the three hub-specific bullets so a downstream repo without the shared workflows still reads cleanly.
- Reconcile the thematic overlap with
Repository Boundaries and Write Safety: both touch the "a construct reports success while doing nothing" idea (a suppressed write misread as a harmless failure; a skipped job indistinguishable from a passing one). State the write-verification point once rather than twice.
No code change is required to keep it hub-only; this issue is the explicit decision point.
Summary
Decide whether the
## Verification Disciplinesection in the hubAGENTS.mdshould be carried to the fleet, and if so, genericize the hub-specific parts and reconcile a small thematic overlap with the newRepository Boundaries and Write Safetysection.Filed as a deliberate follow-up to keep #367 (the write-safety incident change) a single-incident change.
Current state
## Verification Disciplinewas added to the hubAGENTS.mdon 2026-07-19 (c81420d), but it is not in thespec/files.jsonAGENTS.mdsectionsallowlist, so it is hub-only and does not propagate to downstream repos. #367 addedRepository Boundaries and Write Safetyas the first carried section; Verification Discipline sits just below it in the same file, uncarried.The section's rules:
.matches\rin a regex.The decision
Most of these are fleet-general (test discipline, run-all-linters, green-is-not-done, CRLF-regex hazard, fix-the-class) and would benefit every derived repo. A few lean hub/workflow-specific and would need genericizing or dropping before carrying:
WORKFLOW.mdD8.4 cross-reference (identity-allowlist gate).changes-job reference under "Branching Model".If carried
"Verification Discipline"to theAGENTS.mdsectionsallowlist inspec/files.json.Repository Boundaries and Write Safety: both touch the "a construct reports success while doing nothing" idea (a suppressed write misread as a harmless failure; a skipped job indistinguishable from a passing one). State the write-verification point once rather than twice.No code change is required to keep it hub-only; this issue is the explicit decision point.