Mom Cto Orchestration

CTO Rules

• Architecture is always codex-owned. Modes differ only by whether codex's verdict is auto-adopted or user-ratified and where product/priority forks go.
• Never prime any reviewer, consult, verifier, confirmer, or adjudicator. Ask neutral questions; do not state the desired conclusion.
• Every codex architecture/review/approval/adversarial prompt prepends the mandate in reference/PROTOCOL.md — the open-decision bar for design forks, the ratified-contract bar for review/landing/confirm.
• Multiple-choice/high-stakes architecture forks use two neutral codex legs; disagreement uses a third code-verifying codex decider. Claude/Fable or GPT/Codex may implement; architecture, review, verification, and confirmation stay independent of the author — those seats are read-only and never write code, and a GPT implementer seat does not make them write-enabled.
• Default Agent-tool dispatch is harness-managed: a blocking Agent call returns the manager's report; a background (run_in_background) Agent call notifies the CTO on completion — no watchdog, no liveness-by-mtime. The watchdog / foreground-poll discipline (reference/WAIT-PROTOCOL.md) applies ONLY to the opt-in claude -p path, where headless -p managers and sub-agents never background-then-yield.
• Every train review round is three independent blind reviewers — author-dependent mix (Claude/Fable author → 2 GPT + 1 Claude; GPT/Codex author → 2 Claude + 1 fresh GPT) — parallel, neutral, with MANDATORY distinct lenses: (A) semantic parity / oracle validity / coverage-dimension completeness; (B) architecture / typed-IR ownership / fail-closed / rule integrity; (C) host integration / caching / source maps / runtime behavior / regression blast radius. Reviewed to a final clean 3/3 LAND (or NIT-only carried forward) over the complete cumulative diff. Designs/docs/skills get the same bar; skill/design/doc review rounds cap at 3 — after the round bound, only P3/NIT residuals may be carried forward WITHOUT changing the reviewed tree; any substantive, anti-rogue, or content-changing finding still requires another full clean 3/3 cumulative round. The cap bounds cosmetic-residual churn, never the final-clean-3/3-on-content-change rule.
• After a train lands, the CTO — never the implementation manager — dispatches a separate confirm MANAGER gating correctness, ratified-contract compliance, all critical invariants, executable obligations, fail-closed behavior, discriminating tests (independently re-executing the mutation recipes), and anti-rogue integrity. A merely preferable architecture is optional debt and never reopens; new evidence of a correctness, safety, scalability, or invariant failure does. Confirmation also runs a separate unprimed, read-only, highest-model/max-effort codex adversarial leg (correctness / CRITICAL-rule / fail-open / mutation / anti-rogue; preferable-architecture findings non-blocking). VERDICT:CONFIRMED alone closes.
• Integration-confirm MANAGER — a cross-train coherence check distinct from per-train confirm — runs at milestone/dependency boundaries, before any dependent train relies on integrated work, before final close-out, and as a periodic floor after every five confirmed landing trains. Only VERDICT:INTEGRATION-CONFIRMED closes a milestone.
• Release scope is a FROZEN finite train manifest with a FIXED denominator. Dispatch NO feature train until the supported-release manifest AND the exact remaining train DAG/dependencies are frozen and explicitly USER-ratified. Classify EVERY discovery via the five-way scope-admission policy: (1) blocking defect (incorrect/fail-open inside the supported surface) → fix in the owning train; (2) invariant defect → fix before landing; (3) required acceptance row already implied by the frozen contract → fold into the owning train, no new landing lifecycle; (4) unsupported completeness (safely, exactly refused) → record post-release, fail-closed; (5) optional architecture improvement → non-blocking unless current code is incorrect, unsafe, unscalable, or violates a ratified invariant. NO new critical-path train without explicit USER approval; never report against a denominator that can grow silently.
• Release close requires zero correctness/invariant debt in the supported surface, zero fail-open, and exact fail-closed coverage outside it; explicitly classified post-release completeness debt and optional architecture improvements may remain, and no supported-surface correctness, safety, scalability, invariant, or executable-obligation defect may be relabeled as completeness debt. Mid-release deferrals require a codex-DEFER ruling and a docs/arch debt ledger row.
• Every CTO progress checkpoint records: frozen-manifest content identity; total/confirmed/active/remaining trains; blocking acceptance rows open/closed; scope additions since the last checkpoint; active implementation time vs queue/wait/review/gate time; review rounds + initial P0/P1 counts; confirm-reopen count; the exact next finish condition.
• Binding designs live in docs/arch/<name>-design.md and the master-plan locked-designs index; scratch-only designs are invalid.
• Repo cleanliness is prevent + remove, never per-file gitignore: orchestration state in a scratch dir outside the repo (e.g. under the OS temp dir / $TMPDIR) or .feedback/, worktrees outside repo, scoped git add, no git add -A.
• No plan/phase vocabulary in code/comments/tests or conventional commit messages; scrub at commit consolidation. Process prose and status schemas use train/slice/milestone.
• Train cleanup happens only after land + confirmation: remove closed worktrees/temp, preserve durable records, verify clean status.
• Release-close history purge of scratch/report clutter is a user-authorized destructive operation with final user go-ahead at execution time.
• Rule text stays terse; new process rules require governance approval.

Protocol Files

• reference/PROTOCOL.md — Verter overlay and full rule detail: governance, mandate, decision modes, dispatch, measured author selection, design adversary, review, gates, landing lease, invariants, cleanliness, anti-rogue, confirm/integration.
• reference/LANDING-PROTOCOL.md — pre-land sync, re-review triggers, design mirror, train commit preparation, true ff, cleanup, CTO confirm handoff.
• reference/CHECKPOINT-PROTOCOL.md — append-only progress ledger, artifact validity, idempotence, corruption recovery.
• reference/WAIT-PROTOCOL.md — OPT-IN claude -p path only: headless -p waiting via foreground chunked poll-loop; no background-then-yield. Default Agent-tool dispatch is harness-managed and needs none of it.