Decide whether to carry the Verification Discipline section to the fleet #368

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

1. Add "Verification Discipline" to the AGENTS.md sections allowlist in spec/files.json.
2. Genericize or footnote the three hub-specific bullets so a downstream repo without the shared workflows still reads cleanly.
3. 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.