Verification & Discipline

MS4CC ships more than a memory system. As of the Engineering Discipline canon, the framework’s always-loaded AGENTS.md carries a set of universal engineering-discipline gates — behavioral rules that bind the orchestrator and every subagent, not left to probabilistic recall.

The motivation is the finding behind the Fable 5 vs Opus 4.8 case study: a harnessed weaker-tier run reached the stronger tier’s quality band, and the bare models’ shortfall was on discipline — hygiene, validation, not shipping unverified work — not on raw capability. These gates are that discipline layer, written down.

See the whole loop

A visual, gate-by-gate walkthrough lives on the Verification Loop page. This doc is the docs-side summary and pointer.

The gates

Recon before pickup

Read the real code before trusting a ticket’s premise. Stale “we don’t have X” framings and already-shipped work get caught before a line is written.

Two ticket-fidelity gates

After planning, before coding: the plan matches exactly what’s asked. After coding, before committing: diff the change against the ticket, point by point.

Adversarial QA — mandatory

Before critical work ships, an independent agent context reviews with a refute-don’t-confirm brief. Self-review does not satisfy it, regardless of model tier. Confirmed defects block the ship.

Verify before done

“Done” means the exact artifact the user checks, verified their way. Artifact-present is not feature-works; when end-to-end verification isn’t possible, the gap is named, not glossed.

The AGENTS.md section also covers shipping discipline (completed ≠ shipped until deployed; docs ship in the same change), git and multi-agent safety (never git add -A in a shared clone; no destructive git near uncommitted work), and orchestration method.

Why independence is the active ingredient

An author cannot adversarially review their own work from inside the same context — they carry the reasoning that produced the bug, and green tests are evidence only for the paths they cover. A fresh context, briefed to refute, treats the work as a claim to break rather than a result to confirm. That is why the gate specifies an independent context, and why a stronger model reviewing its own work is still weaker at this than a fresh context with a refute mandate.

Canon vs operator layer

Only universal engineering discipline lives in public canon. Operator- and client-specific apparatus — a customer-facing Definition of Done, a benchmark harness, named review agents, voice rules — builds on top of the canon gates but stays in the operator layer by design.

Where it lives

• Canon: the “Engineering discipline” section of the framework’s AGENTS.md, distributed to every install via the version pin.
• In depth: the Verification Loop page — the nine gates, gate by gate, with what “pass” means at each.
• The evidence: the Fable 5 vs Opus 4.8 case study.