MindStone · Engineering discipline

The gate sequence that turns a model’s draft into a shipped, correct result.

The interesting variable in the Fable 5 vs Opus 4.8 study wasn’t which model is smarter. A harnessed Opus reached Fable’s quality band, and the bare models’ shortfall was on discipline — hygiene, validation, not shipping unverified work — not on raw capability. This is that discipline layer, made concrete.

The loopsignal flow, left to right
  1. 01 Recon Read the code before you trust the ticket’s premise.
  2. 02 · Gate 1 Plan ↔ ticket The plan matches exactly what’s asked.
  3. 03 Implement The work itself.
  4. 04 · Mandatory Adversarial QA Refute, don’t confirm. Self-review does not count. Independent context
  5. 05 Security review Auth, injection, secrets, deps.
  6. 06 Verify E2E Exercised the way the user exercises it.
  7. 07 · Gate 2 Delivery ↔ ticket Diff against the ticket, point by point.
  8. 08 Receipt The auditable ship record.
  9. 09 Checkpoint Persist the reasoning; discipline compounds.

Gate 1 / Gate 2 are the two ticket-fidelity checks, before code and before commit. 04 runs in a fresh context, not the author’s.

Why it exists

Capability writes a draft. Discipline is what ships it.

Nothing in the loop depends on the model being clever. It depends on the model being made to check — the layer a bare model skips and a harness supplies.

The proof is a bug that passed every self-run check. On a real deploy, the author’s own verification — tests green, types clean, “seeds idempotent” — blessed a deploy-breaking defect: a hardcoded developer-machine path that could never run in the container, masked by the author’s own failure-tolerant setup. An independent agent, briefed to refute rather than confirm, found it in a single pass. The author-context review structurally could not: it carried the reasoning that produced the bug.

Independence is the active ingredient — not effort, and not model tier.
Referencewhat “pass” means at each gate
#GateWhat it isPass means
01 Recon Read the code before you trust the ticket’s premise. Stale “we don’t have X” framings and already-shipped work are caught before a line is written.
02 Plan ↔ ticketGate 1 The plan matches exactly what’s asked. Every criterion covered — nothing invented, nothing misread. Divergence reconciled first.
03 Implement The work itself. Built to the plan.
04 Adversarial QAMandatory Refute, don’t confirm. Self-review does not count. Ranked confirmed findings with file:line. Self-review does not satisfy it, any tier. Confirmed defects block the ship.
05 Security review Auth, injection, secrets, deps. Findings triaged; medium and high fixed before ship; result recorded.
06 Verify E2E Exercised the way the user exercises it. “Done” is the exact artifact the user checks, their way. Artifact-present ≠ feature-works.
07 Delivery ↔ ticketGate 2 Diff against the ticket, point by point. Every requirement met, nothing extra, nothing missing.
08 Receipt The auditable ship record. A reviewer can see the gates ran — auditable, not vibes.
09 Checkpoint Persist the reasoning; discipline compounds. Receipts and reasoning become recallable next session — re-run, never re-learned.

The gates bind subagents too. A delegated worker inherits none of the orchestrator’s session, so the relevant gates are written into the delegation prompt.

Where it livescanon vs operator layer

Universal discipline is shared canon. The apparatus around it isn’t.

An engineering rule true for anyone running the framework belongs in shared canon; an operator’s or a client’s specific machinery does not. Keeping that line clean is the point.

MS4CC canonpublic, distributed by version pin — true for anyone running the framework

Engineering-discipline gates

Recon, ticket-fidelity, the adversarial-QA gate, verify-before-done, git safety — the always-loaded AGENTS.md section.

Subagent mechanism

The independent contexts the gates run in.

Checkpoint + memory

Persists the receipts and makes them recallable.

builds on ↓

Operator & client layerbuilt on top — deliberately kept out of the public framework

Client-specific PR gates

A customer-facing Definition of Done built on top of the canon gates.

A benchmark harness

The verified-working evidence engine — operator-scoped tooling.

Named QA / security agents

The concrete independent contexts that execute the review gates.

Voice & presentation rules

Stakeholder-specific framing — not engineering discipline.

The mechanismwhy independence, not effort

An author cannot adversarially review their own work from inside the same context. They carry the chain of reasoning that produced the bug, so they re-walk the same path and reach the same wrong conclusion. Green tests don’t rescue this: a passing suite is evidence only for the paths it covers, and the paths a bug hides in are, by definition, the ones the author didn’t think to cover.

A fresh context has no such investment. Briefed to refute, it 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 self-review does not satisfy it regardless of model tier: a stronger model reviewing its own work is still trapped in its own reasoning, while a weaker model with a refute mandate and a clean context routinely out-finds it.

Statuswhere it stands
Canon now
The “Engineering discipline” section in the framework’s always-loaded AGENTS.md — closes issue #62 (the adversarial-QA gate) and lands part 1 of #66. Distributed to installs via the version pin.
Operator layer
A client-facing Definition of Done, a benchmark harness, named review agents, voice rules — built on canon but kept in the operator layer by design.
Still open
Ship the situational gotchas as a canonical seed-memory set so new installs boot with them; the fleet-operator overlay; and cross-substrate coordination.