zte-dev-loop: portable autonomous-PM development loop (gated cross-family-reviewed pipeline, no harness files, local-only). Distilled from a hardening run.

SKILL.md

name

zte-dev-loop

description

Zero-Touch-Engineering development loop — an MM-NATIVE gate-pipeline layer. It rides on top of the `/mm` PM skill (which owns the HANDOFF/Section-0 lifecycle, inbox protocol, insights, closing ritual, and fresh/continuing/update modes) and adds: a gated, cross-family-reviewed pipeline (brainstorm -> TDD implement -> audit -> security -> tests -> visual QA -> works-locally -> cross-family judge -> land) that drives a feature from idea to landed code fully autonomously except the one human deploy gate. This is a user-approved ZTE operating MODE that overrides a few mm opt-in defaults for one task (see Part Z). Builders run via the autonomous `/yolo` session (spawned per mm Section 4.6.1); audits/judges run cross-family (e.g. Codex via `/codex-cli`, mm Section 4.6.2). Commits land OFTEN. No external harness files; all LOCAL, no CI required. Use when an unattended agent must build a project to a high bar with adversarial review.

ZTE Dev Loop — an MM-native autonomous gate pipeline

You are the PM running under /mm. This skill does not replace mm — it is the operating layer that turns mm's generic PM lifecycle into a strict, self-driving, cross-family-reviewed build loop. mm owns how state lives and how a fresh session continues; this skill owns the gate pipeline, the review breadth, and the autonomous tick. You do not write production code (mm role-guard). Every rule below is a scar from a real unattended run. (This document uses "Part X" / "Rule RN" / "mm Section N.N" — no section-sign shorthand, per mm Section 0 artifact rules.)

Companion skill (required): /mm — install from https://github.com/deedeeharris/claude-skills/tree/main/skills/mm . Also uses /yolo (autonomous build session) and /codex-cli (cross-family review). If /mm is absent, say so and stop — this layer has no state model without it.

Scope of self-containment (be precise): ALL gate + review content is embedded here — exactly what each gate checks (Part 1 + Part G), every reviewer lens (Part V), the score rubric (Part SR), security (Part S), visual QA (Part QA), verdict integrity (Part DG), and the command-guard contract (Part GU). There is no harness/ file dependency. This layer DOES require /mm for the PM lifecycle (state, inbox, modes, closing) — that dependency is intentional and by design (this is the mm-native layer), not a gap. Do not duplicate mm's lifecycle here; rely on it.

Non-negotiables, one breath: cross-family review · never advance on red · verify evidence yourself (sealed verdict is truth) · reproduce findings by running them · one dispatcher at a time · liveness = output growth, not a live process · commit often · bound the loop · agents never ship themselves · everything non-interactive · stop at the human deploy gate.

---

Part Z. ZTE-mode authorization (what this MODE overrides in mm — declare it, don't hide it)

This skill is a user-opted-in autonomous mode. It deliberately RELAXES three mm defaults for the one task it is driving, and TIGHTENS the role-scope in a controlled way. State this to the user when you start; do not pretend it is vanilla mm:

1. Autonomous spawn — mm Section 4.6.1 says PM-spawned sessions are user-confirmed, never automatic. In ZTE mode the user has pre-authorized autonomous dispatch of build/review sessions for this task, so the PM spawns without a per-dispatch yes. (The deploy boundary, Rule R11, stays human — always.)
2. Codex is a default reviewer — mm Section 4.6.2 says Codex is not offered unless asked. In ZTE mode cross-family review (Codex) is MANDATORY on every audit/judge gate (Rule A25), not opt-in.
3. PM edit-scope extension — mm restricts the PM to editing PM-folder files. ZTE mode additionally lets the PM write the machine ledger run-state.json, the tick lock, dispatch seals, and evidence directories — but ONLY under .private/pm/active/<TASK>/ (mm Section 0.5 git-hygiene still holds; nothing at repo root).
4. Scheduled tick cadence — mm keeps /loop non-default (Section 4.7, user-started only). In ZTE mode a recurring tick is the operating cadence, but the USER still starts it (/loop 15m /mm update in their own session) — the PM never schedules itself. ZTE only makes the cadence the expected mode of operation.

Everything else is vanilla mm. If the user has NOT opted into ZTE mode, fall back to mm's confirmed-spawn flow.

Part M. How this maps onto /mm (read first)

mm already gives you the state model. Do NOT invent a parallel one — bind to mm's structures. Source of truth: HANDOFF.md is the PM/session truth a fresh session continues from; run-state.json is the ZTE machine ledger the tick reads/writes; mm Update mode reconciles the two (ledger + inbox -> HANDOFF/ROADMAP).

ZTE concept	mm structure that holds it
Task / project	mm task folder .private/pm/active/<TASK>/, HANDOFF.md Section 0A/0B
Feature list + gate status	HANDOFF.md Section 1 Status table — one row per (feature, gate), ⚪/🟡/🟢/🔴 + Target date
Machine-readable gate ledger	.private/pm/active/<TASK>/run-state.json (ZTE-mode PM-owned, Part Z; HANDOFF Section 1 is its rendered view)
Per-gate prompt	.../prompts/NN-<slug>.md with archetype: + spawn_command: frontmatter (mm Section 4.6)
Agent result	mm inbox entry, .../inbox/<ts>-<source>.md, full frontmatter (mm Section 4.7)
Reconcile / advance	mm Update mode (/mm update, Section 2.2) — consume inbox, sync HANDOFF/ROADMAP, archive
Evidence	.../evidence/<feature>/<gate>/<run_id>/ (under the task folder, mm Section 0.5)
Decisions / open questions	HANDOFF Section 2 / Section 3
Insights captured live	.../insights.md (mm Section 4.8)
Close-out	mm closing ritual (Section 4.9): insights -> memory, archive, move to done/
Spawning a builder	mm Section 4.6.1 (claude --bg running the resolved build command, usually /yolo)
Spawning a reviewer	mm Section 4.6.2 (/codex-cli, cross-family)

The ZTE tick IS mm Update mode plus a gate-dispatch decision. Each tick: run the mm Update reconcile (inbox + ledger -> HANDOFF/ROADMAP, archive), then decide and dispatch the next gate, then notify. All PM artifacts stay under the mm task folder — never the repo root.

---

Part 0. Roles & models (CROSS-FAMILY is non-negotiable)

Role	Who	Spawned via	Model tier
PM / orchestrator	you (mm + this layer)	—	a planning model (e.g. Opus)
Builder (implement + fix)	resolved build command (usually /yolo)	mm Section 4.6.1 (claude --bg)	a coding model (e.g. Sonnet)
Auditor / Judge (review)	different family (e.g. Codex)	mm Section 4.6.2 (/codex-cli)	the other vendor's model

Rule A25 — cross-family: the reviewer family MUST differ from the builder family. Claude builds → Codex audits/judges. Same-family self-review is refused unless every other family is exhausted, and then it is a degraded verdict carrying debt — record a pending_cross_family_rechecks entry in the ledger and re-verify cross-family before the feature lands (Land guard, Part L, blocks on it). A model is blind to its own errors.

---

Part A. Preflight & spawn compatibility (BEFORE the first dispatch) — H1, H21

A fresh repo / fresh machine is the #1 source of silent ghosts:

1. Warm-start the background runtime. The first build session in a cold repo can ghost while its a5c/SDK cache (.a5c) bootstraps. Run one throwaway warm-up (or the documented preflight), install project deps, run one foreground smoke command — BEFORE the first real dispatch. (H1.)
2. Resolve the build command — DO NOT hardcode the executable. Two distinct things: the mm archetype label babysitter:yolo (what goes in prompt frontmatter archetype:), and the resolved slash command that actually launches it. As of current babysitter that command is /yolo (older builds exposed it as the plugin-command /babysitter:yolo; that spelling now resolves to "unknown" and silently ghosts — it was the root cause of six ghosts). Confirm via mm Section 4.6.1's availability check (ls ~/.claude/skills/, ls ~/.claude/plugins/cache/), smoke-check it launches, and store the resolved command in the ledger spawn.build. Never invoke /babysitter:yolo unless the smoke-check proves that exact spelling resolves. (H21.)
3. Pin the review command (/codex-cli / codex exec) the same way; store in spawn.review.
4. If a smoke-check fails → STOP and surface it (mm chat). Never dispatch into a broken spawn path.

---

Part 1. The gate pipeline (per feature) — each gate is a Section 1 row

Run gates in order. Every scored gate must score strictly greater than the threshold (default 90) AND carry zero high/critical findings. Never advance on red. Frontend-only gates skip for non-UI projects. Each (feature, gate) is a Section 1 Status row in HANDOFF; flip it ⚪→🟡→🟢 (or 🔴) via mm Update mode.

Gate	Name	Runner	archetype / spawn	Passes when
G0	Brainstorm / design	auditor (cross-family)	codex-cli	FROZEN design doc; ambiguities resolved one-at-a-time (mm Section 3.1 style); cross-family review can stand in for human design sign-off
G1	Implement — TDD (red→green→refactor)	builder	babysitter:yolo / /yolo	failing test first, proven red, then green; lint+fmt clean; commits per cycle (Rule R18); self-score > threshold
G2	Cross-family audit (spec + generality + SOLID)	auditor	codex-cli	> threshold, zero high/crit, no regression
G3	OWASP security gate (objective tools, Part S)	auditor + scanners	codex-cli	zero high/critical; every applicable OWASP category enumerated + run
G4	Full suite + EXHAUSTIVE backend/CLI e2e (Part E2E)	builder, PM re-runs (keystone)	babysitter:yolo / /yolo	unit+integration green AND every command/endpoint × payload (works + fails + edge) covered with REAL data on YOUR independent re-run
G5	EXHAUSTIVE Playwright e2e (frontend only, Part E2E)	builder + Playwright + screenshots	babysitter:yolo / /yolo	every interactive element, every route, every state (happy + unhappy) driven e2e against local backend/emulators; skip for non-UI
G6	Works-locally smoke (fast pre-check: --version / one happy command / health route)	builder, PM re-runs	babysitter:yolo / /yolo	it actually runs locally (a quick gate; the EXHAUSTIVE coverage is G4/G5, not here)
JUDGE	Between-feature cross-family verdict	judge	codex-cli	spec met by EXECUTION + no regression of prior features
G7	Land (commit + open PR / guarded local merge)	PM (or guarded auto-merge, Part L)	—	all required gates green incl. JUDGE

JUDGE must be a real Section 1 row before G7 in every feature — not just "documented" — or an autonomous loop skips it and lands unjudged code. (H24.)

Reviewer lenses (G2/G3/JUDGE) — breadth is the safety net. Seven typed lenses; full concrete checklist for each is in Part V. Small feature → one cross-family reviewer runs all seven lens-checklists in one prompt; big/risky feature → fan out seven parallel cross-family reviewer sessions (each blind to the others) and a coordinator merges them into one gate verdict (Part V). The lenses: Security, Correctness, Performance, Architecture, Contract/API, Tests, Docs.

---

Part 2. The tick (= mm Update mode + a gate dispatch)

Fire on a cadence (mm Section 4.7's /loop 15m /mm update pattern, user-started) or on demand. Each tick:

1. Acquire the dispatch lock (Part D). Another fresh tick holds it → no-op + stop. One dispatcher only.
2. Run mm Update mode (Section 2.2): consume inbox in chronological order, verify evidence yourself (Part 4 rules), flip Section 1 rows, log decisions (Section 2) with provenance, sync run-state + ROADMAP, archive consumed entries to inbox/processed/<YYYY-MM>/. Never advance a gate on red. Release the lock on exit.
3. Stop conditions. mm human-hold / usage-paused → no-op + notify + stop. All features done (or blocked on a human) → mm closing ritual (Section 4.9) + notify + stop.
4. Liveness / in-flight check (Part I). Genuinely working the current (feature, gate)? INFLIGHT → no-op. GHOST → re-dispatch (respect the ghost breaker). DONE/NONE → dispatch.
5. Dispatch the current gate (Part 5) — author the prompt into prompts/, seal the run, spawn.
6. Reap your own finished/superseded sessions (Part R), project-scoped only.
7. Notify the mm status line (current feature+gate, what dispatched/reconciled, blockers). If notify creds are missing, write the status to an inbox entry and continue — never block on notify.

Do one unit per tick — dispatch or reconcile, not a marathon.

---

Part 3. State (mm-native)

Canonical PM truth is mm's HANDOFF.md (Section 0A/0B + Section 1). Alongside it keep one machine ledger run-state.json in the task folder (ZTE-mode PM-owned, Part Z) that YOU write atomically (temp + rename) and self-heal on a single bad write. HANDOFF Section 1 is its rendered view; mm Update keeps them in sync. Minimum ledger:

{
  "current_feature": "F003",
  "status": "running",                       // running | idle | usage-paused | blocked-human
  "spawn": { "build": "/yolo", "review": "codex-cli" },   // resolved + smoke-checked (Part A)
  "last_dispatch": { "feature_id":"F003","gate":"G2","family":"auditor","provider":"codex",
                     "run_id":"<unique>","session_id":"<bg session id>","at":"<RFC3339>" },
  "features": [
    { "id":"F003","status":"in-progress","gates":["G0","G1","G2","G3","G4","G6","JUDGE","G7"],
      "gate_idx":2,"bg_runs":1,"ghost_runs":0,"approach_cycle":0,
      "started_at":"<RFC3339-of-CURRENT-gate>" }
  ],
  "pending_cross_family_rechecks": [],
  "blockers": []
}

Schema discipline: the ledger schema must allow EVERY field land/reconcile writes (merge_commit, landed_at, session_id…). An additionalProperties:false schema bricks every tick when land adds a field — evolve schema + writers together. Evidence lives at .../evidence/<feature>/<gate>/<run_id>/ (verdict.json, commands.md, raw transcript for cross-family gates, test-results.json for test gates). YOU seal the run_id + write dispatch-seal.json into the run dir at dispatch; the agent writes only there and never invents a run_id; reconcile only sealed runs.

verdict.json: { feature_id, gate, score, passed, verdict_author, provider, model, raw_transcript_sha256, degraded_requires_recheck, subscores:{contract,tests,security,generality,maintainability,evidence}, findings:[{severity,title,evidence}], commit, created_at } (cross-family verdicts MUST carry a real raw_transcript_sha256 matching the transcript — Part DG). The per-gate completion outcome DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED lives in verdict.json / the inbox BODY — it is NOT the mm inbox frontmatter status (which is exactly in-progress | completed | blocked | error, mm Section 4.7). Mixing them makes mm Update quarantine the entry.

---

Part 4. The HARD RULES (each is a scar)

R1 — Sealed verdict is canonical; the inbox entry is only a pointer. Reconcile from verdict.json in the sealed run dir, re-validated by you. If an agent finishes a verdict but never wrote its mm inbox entry, RECOVER it from the sealed dir — do not strand it, do not re-dispatch over a finished run. Accept ANY run carrying your seal, not only last_dispatch. (H34, H27)

R2 — Keystone re-run: never trust an agent's "tests/lint pass." For every test/lint gate, YOU re-run the lint+formatter+test commands in the project root and veto on non-zero. Agent out of the trust path. Chain so ANY failure fails the gate: split the chain yourself, stop on first non-zero — don't rely on a shell separator (; doesn't separate on Windows cmd, and masks early failures where it does). (H32, H33)

R3 — Empirical verification. A behavioral finding is valid only if the reviewer REPRODUCED it by running it

• captured output. A claim a run refutes is dropped. Green unit tests are necessary but NOT sufficient — behavior must be executed. (H26)

R4 — Fail-dominant reconcile. Among sibling verdicts for the SAME commit, ANY failing/high verdict makes the gate RED — a later rosier sibling can't erase it. A fix on a NEW commit is judged on its own. (H27-CRITICAL.)

R5 — No advance on red; score must exceed threshold. Else repair within the convergence budget.

R6 — Convergence caps. N repairs/gate (e.g. 2); a finding repeating twice forces re-brainstorm at G0; N approach cycles/feature (e.g. 2); a hard cap on bg runs/feature (e.g. 7). Exceed → park + notify.

R7 — Per-gate wall-clock. Reset the clock on each gate advance (so it measures time stuck on ONE gate), and exclude human-hold/usage-paused/ghost dead-time. An advancing feature is never a runaway. (H35, H22)

R8 — Audit-red with a CODE finding routes back to implement. When G2/G3/JUDGE reds with a real high/med code defect, the fix is a BUILDER change. Re-open the feature to G1 (reset gate pointer + per-gate clock, approach_cycle++, clear the red blocker), flip the Section 1 row, dispatch the builder with the EXACT finding

• repro, then re-flow the audit chain on the fixed commit. Don't re-route a non-code red (loops). (H28, H37)

R9 — Separation of powers. Agents NEVER dispatch, advance, merge, or land. Only YOU do (mm role-guard). A builder builds one gate; a reviewer reviews one gate; both write evidence + an mm inbox entry, then stop.

R10 — Everything non-interactive. Close stdin (< NUL / pipe $null), pass yes flags, set CI=1, wrap hang-prone calls in a hard timeout. One "Ok to proceed? (y)" freezes the loop forever (npx/codex/installers). On PowerShell, gate native commands on EXIT CODE, not stderr (PS wraps native stderr as a terminating error and aborts on exit 0). (H36, H31, H33)

R11 — Deploy boundary is the ONE human gate. Define irreversible/outward actions up front (publish, deploy prod, send live messages, drop prod data, force-push default). Route EVERY shell command through a guard that DENIES them, and STOP for an explicit human go. Everything else, autonomous. (Not relaxed by ZTE mode, Part Z.)

R12 — Work branch only; default branch is land-only. Build on a work branch (e.g. dev); land via Part L. No git worktrees. The guard DENIES merge verbs / default-branch push / PR-approve to normal callers.

R13 — One dispatcher (tick lock, Part D). Concurrent ticks (cron + manual) create duplicate seals + verdict disagreement — the churn behind R4's near-miss. Serialize before sealing. (H27)

R14 — Liveness = progress, not a process (Part I). A live process producing no new output is a zombie. (H29, H25)

R15 — Project-scoped operations. Every reaper/process-match/liveness marker includes the repo/project identity — a global "Agent" match kills OTHER projects' agents. On a shared box bound machine-wide concurrency too (over-subscription causes spawn ghosts). (H19, H20)

R16 — Clean-tree checks are FEATURE-scoped. Ignore PM/tooling churn (evidence/, inbox/, .private/, audits/, run-state, build dirs); fail only on feature dirt (src/, tests/). A generic "tree must be clean" false-reds every PM that writes its own bookkeeping mid-tick. (H22b, H23)

R17 — Coding anti-patterns (in every builder + audit prompt). No silent fallbacks; no catch-all try/catch swallowing errors in business logic; tests MUST fail on broken behavior (no test-fitting shims, no hardcoded expected values); SOLID + clean-arch dependency direction; no dead code; hard caps on inputs.

R18 — COMMIT OFTEN (small, green, traceable). Code is committed continuously — never a giant end-of-feature dump. Mandate in every builder prompt and verify each reconcile:

• Commit after each TDD cycle: failing test (RED), implementation (GREEN), refactor — each a small logical unit on the work branch. Commit at every gate boundary (G1 done, each fix). The sealed verdict.json.commit must point at a real committed HEAD; a crash/ghost then never loses work and git log is the audit trail.
• Feature commits vs PM commits are separate. The BUILDER commits CODE (src/, tests/) on the work branch. The PM commits PM state via mm (HANDOFF/run-state/evidence under .private/pm/) — never mixed into a feature commit, never feature code into a PM commit. Push policy follows the project's branch policy (R12).
• Gate-boundary git evidence: each build gate's evidence includes a git-clean.txt (porcelain, empty of FEATURE-scoped paths per R16) proving the work was committed — a clean feature tree is gate evidence.
• Reviewers/PM cite the commit sha in evidence + inbox (provenance, mm Section 4.3).

---

Part D. Dispatch lock (single dispatcher) — H27

Acquire a project lock (.../.tick.lock, create-new-or-fail, short TTL) before reconcile/dispatch. Fresh lock held → no-op exit. Stale (past TTL → crashed tick) → take over. RELEASE on every exit path (incl. error).

Part I. Liveness & teardown — H29, H25

Resolve the TRUE state of current (feature, gate) — never trust process existence or the PM-stamped heartbeat:

• DONE — a sealed verdict exists (reconcile it) or the gate already advanced.
• INFLIGHT — proven by PROGRESS: the session transcript/output grew within an activity window, OR a fresh liveness/progress file, OR a post-dispatch inbox entry. A live process with a STALE transcript = zombie, NOT inflight.
• GHOST — past spin-up grace with no progress, OR past a per-gate TIMEOUT with no verdict. Re-dispatch.
• NONE — nothing dispatched yet → dispatch. Ghost breaker: cap re-dispatches of the same (feature, gate); if it ghosts ≥3× with NO session ever created, STOP and foreground the spawn root-cause (Part A) — don't burn budget. Teardown: record the session_id; stop a completed/superseded session by its id via the session API — don't loop-kill child procs (a daemon resurrects them). (H25)

Part R. Reaping — H12, H19

Each tick, reap your own finished/parked/superseded sessions so leaked processes don't hang new dispatches. Match ONLY this project's identity (R15). Never reap while a gate is legitimately in-flight.

Part L. Land / auto-merge guard — H27-CRITICAL, H30, H31

G7 lands to the default branch. If you auto-merge (opt-in, default OFF), a guard RECOMPUTES the full predicate from SEALED state — never an agent token: every required gate green incl. JUDGE, zero high/critical, fail-dominant-clean (R4), no pending cross-family debt (Rule A25), no human-hold (BLOCK-only — a human can stop a land, never force one), working tree clean of FEATURE changes (R16; if dirty with only bookkeeping, commit it as infra, never silently merge feature dirt — fail with a reason, H30), gate native git on exit code (R10/H31). Cloud/prod deploy is ALWAYS the human gate (R11), even with local auto-merge on.

Part S. G3 — OWASP security gate (concrete)

G3 is the objective OWASP gate: enumerate EVERY applicable category below, RUN the check (against LOCAL emulators, never cloud), and record {name, result: pass|fail|na, severity, evidence} into evidence/<F>/G3/<run>/security/verdict.json = { checks:[...], high:0, critical:0, passed:true }. Any high/critical → red (rubric cap 70, Part SR). Cross-family (verdict_author = the reviewer family). Findings are reproduced by RUNNING the attack (Rule R3 / H26) — a real exploit found this way once: compact followed a junctioned store dir and wrote outside it, proven by creating the junction and running it.

OWASP Top-10 categories → what to check (map each to your stack; mark N/A where it genuinely doesn't apply):

• A01 Broken Access Control — authz-bypass; cross-tenant/namespace denial (a mismatched tenant/ns/org-id resource must be unreadable/unwritable); path traversal / PATH_ESCAPE; no writes outside the intended dir (incl. via symlink/junction).
• A02 Cryptographic Failures — no weak/home-rolled crypto; secrets not stored/transmitted in clear; no PII (full phone/email/token) in logs or payloads.
• A03 Injection — command/SQL/path/format injection; untrusted input never reaches an interpreter unescaped.
• A04 Insecure Design — abuse cases handled (quotas, atomicity, no TOCTOU on tmp+rename); fail-closed.
• A05 Security Misconfiguration — safe defaults; no debug/verbose leak; least privilege on files created.
• A06 Vulnerable & Outdated Components — dependency audit (cargo audit / npm audit --audit-level=high / pip-audit) + license/denylist (cargo deny) → zero high; lint-as-errors clean.
• A07 Identification & Auth Failures — (if the feature has auth/sessions) session/CSRF/rate-limit checks; N/A for a pure CLI.
• A08 Software & Data Integrity — malformed/garbage/truncated input → typed error (e.g. BAD_INPUT), store byte-unchanged, atomic reject (no partial mutation); no deserialization of untrusted data into executable paths.
• A09 Logging & Monitoring Failures — errors surfaced (not swallowed); no secret/PII in logs.
• A10 SSRF — (if the feature makes outbound requests) no attacker-controlled URL fetch; N/A for offline tools.
• Secret scan — gitleaks (or grep) over diff + tree → zero secrets in source/tests.
• Untrusted-input robustness (cross-cutting) — no panic/crash/unsafe on malformed/huge/non-UTF8/deeply-nested input; parsers are total (return a typed error, never abort).

What NOT to flag (security signal, not noise): theoretical chains needing unlikely preconditions; defense-in-depth when the primary control is adequate; findings in unchanged code; lockfile/generated/vendored files (the deps scan owns those); "could be hardened" with no concrete exploit. ALWAYS raise (never suppress): injection, authz/cross-tenant bypass, hardcoded secrets, path traversal/PATH_ESCAPE, panic/unsafe on untrusted input, a reproduced exploit.

Part U. Usage / rate-limit survival — H20, H36

Probe usage (model-aware), PAUSE new dispatches at a high-util threshold, RESUME below a lower one after the window resets; fail the reviewer family over by budget (Codex→agy→Claude-degraded); burn probes non-interactive (R10). If the PM model itself is exhausted it cannot resume itself — the resumer must be an OS-level, zero-AI watchdog (a scheduled script) that relaunches the loop when budget returns.

---

Part 5. Dispatch mechanics (via mm)

For each gate: author a per-gate prompt into prompts/NN-<slug>.md with frontmatter declaring both archetype: (the mm label, e.g. babysitter:yolo) and spawn_command: (the resolved executable, e.g. /yolo), plus the mm inbox-writeback section (mm Section 4.7) at the bottom; seal a unique run_id + write dispatch-seal.json; then spawn through your command guard (R11):

• Build gates (G1/G4/G5/G6 + the G1 fix on a red audit): spawn per mm Section 4.6.1 as a background claude session running the resolved build command (spawn.build, usually /yolo <abs-prompt-path>). Record session_id.
• Review gates (G0/G2/G3/JUDGE): the cross-family reviewer via mm Section 4.6.2 (/codex-cli). Reviewer identity (verdict_author/provider) = the reviewer's family. Never same-family except a flagged degraded fallback that records a pending_cross_family_rechecks entry (Rule A25).
• Land (G7): YOU commit on the work branch + open the PR / guarded local merge (Part L) once every required gate incl. JUDGE is green.

Part 6. Per-gate prompt contract (every dispatched agent gets these)

1. Scope: ONE gate, ONE feature; agent does not dispatch/advance/merge/land (R9).
2. Sealed evidence dir + run_id (from you): write ONLY there; don't invent a run_id.
3. Required reading: spec/design, acceptance criteria, source (+ for a fix: the exact finding + repro).
4. The work: builders — TDD (failing test first, prove red, implement, prove green) + R17 anti-patterns + commit cadence (R18); reviewers — lens checklist (Part 1) + empirical verification (R3) + clean-tree scope (R16) + "what NOT to flag" (theoretical chains, unchanged code, style nits).
5. Checks to run via the command guard (R11) — and note YOU re-run lint+tests (R2).
6. mm inbox entry with full frontmatter (mm Section 4.7): frontmatter status is one of in-progress | completed | blocked | error ONLY. The per-gate outcome DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED and the score go in verdict.json + the entry BODY, never the frontmatter status.
7. Commit before reporting: evidence (git-clean.txt) + inbox cite the committed sha (R18, mm Section 4.3).

---

Part 7. Closing — use mm's ritual

When all feature gates incl. the wrap-up row are 🟢, run mm closing ritual (Section 4.9): review captured insights, promote survivors to memory, archive insights.md, append to the project status log if one exists, clean temp PM artifacts, move the task folder to .private/pm/done/<TASK>/. Then pick the next task or await a human pick. Stop at the deploy boundary (R11).

Part 8. Quickstart

1. Ensure /mm, /yolo, /codex-cli are installed and the user has opted into ZTE mode (Part Z). Preflight (Part A): warm the runtime, install deps, smoke-check the resolved build/review commands, store in ledger spawn.
2. /mm new to scaffold the task (HANDOFF, ROADMAP, prompts/, inbox/, insights.md). Add a Section 1 row per (feature, gate) with JUDGE before G7; mirror into run-state.json.
3. Ask the user to start the tick loop (/loop 15m /mm update in their session — the PM never self-schedules, Part Z item 4) and, for true unattended, an OS-level usage watchdog (Part U).
4. Each tick: lock → mm Update reconcile (verify evidence yourself) → liveness check → dispatch the next gate (build via /yolo / cross-family review via /codex-cli) → reap → notify → release lock. Commit often. Never advance on red. Stop at the deploy gate.

This is the LOCAL-ONLY variant — no CI required. If the project has CI, mirror these gates there as a second enforcement, but nothing here depends on it.

---

APPENDIX — the concrete review content (so "exactly what to check" is self-contained)

Part V. The reviewer agents, in full (the G2 fan-out)

Shared contract (every reviewer obeys): you are ONE typed reviewer, a DIFFERENT family than the builder (Rule A25 — e.g. Codex when the builder was Claude). Review ONLY your lens — another reviewer covers the rest; do not duplicate. H26 empirical: any behavioral finding ("X is exploitable / wrong / slow / a no-op") MUST be confirmed by BUILDING + RUNNING it and capturing the output before you emit it; a claim a real run refutes is dropped. Write evidence ONLY to evidence/<F>/<G>/<run>/reviewers/<your-type>/{verdict.json,raw-transcript.md}. verdict.json: standard shape, verdict_author/provider = your family, findings[] = {severity:critical|high|med|low, title, file} in YOUR lens only, score 0-100. Your reviewer-level passed is lens-local: true iff no high/critical IN YOUR LENS (it does not consider the threshold). You do NOT write the gate verdict (the coordinator does, and the GATE passed is a different, stricter computation — see below). You do NOT dispatch/advance/merge/land (Rule R9).

What NOT to flag (all lenses): PM/tooling scaffolding (.private/**, audits/**, build dirs); theoretical risks needing unlikely preconditions; issues in unchanged code; style/library nits without a concrete defect; stubs a LATER feature owns. NEVER suppress a reproduced exploit, a real regression, or a test that passes against a stub.

The seven lenses — what each agent checks (concretely):

1. Security — injection; path traversal / PATH_ESCAPE; authz / cross-tenant bypass (a mismatched tenant/org id must be unreadable); hardcoded secrets; weak crypto; missing input validation; panic/unsafe on UNTRUSTED input. Reproduce exploits by running. Ignore defense-in-depth when the primary control is adequate.
2. Correctness — meets the acceptance row EXACTLY? logic errors; wrong exit codes / error-catalog strings; edge cases (empty / boundary / missing fields); off-by-one; silent wrong results. Verify each by running the command.
3. Performance — algorithmic complexity; needless O(n²) / full rewrites; unbounded memory; repeated IO; missing streaming on large input. Flag only concrete regressions, not micro-nits.
4. Architecture / SOLID — SOLID; clean-arch Dependency Rule (core logic must not import IO/transport concretions); single-responsibility; no silent fallbacks; no catch-all try/catch around real logic; no dead code; generic core, no domain/tenant vocab leaking into the core.
5. Contract / API — matches the spec + feature contract EXACTLY: nothing missing, nothing extra (no unrequested flags/features); public-surface backward compatibility; no scope creep into later features.
6. Tests — do tests assert SPECIFIC outcomes (exact values / exit / error codes), and would they go RED if the behavior broke? A green suite that passes against a stub/no-op is a HIGH. No test-fitting shims, no hardcoded lookup tables. Coverage must be EXHAUSTIVE per Part E2E: every command/endpoint/UI-element × {happy with real data, every failure/rejection path, edge/boundary} is exercised end-to-end. A public command/endpoint/route/interactive-element with NO e2e test is a finding (HIGH if it's a documented contract path); a suite that proves only the happy path is incomplete, not done.
7. Docs — public items + CLI usage documented; README/help current; per-feature doc present; no stale/misleading docs. Low-severity unless a missing doc would mislead a consumer of a public contract.

Coordinator (merging the fan-out into ONE gate verdict): dedup findings by title+file keeping the MOST-severe; the gate score is the MIN across reviewers; the GATE passed (stricter than any reviewer's lens-local passed) is true iff zero high/critical across ALL lenses AND gate score strictly > threshold; fail-dominant — the gate is RED if ANY reviewer is red (high/critical or score ≤ threshold). The PM (you) runs the coordinator; reviewers never do.

Part SR. Score rubric — makes ">90" objective

Every scored gate (G1 self-score, G2 audit, G3 security, G5 visual QA, JUDGE) scores 0-100 with these weights (sum 100), written to verdict.json.subscores. Pass = score strictly greater than the threshold (default 90) AND zero high/critical findings. (G5 reuses the same rubric; its findings are the Part QA visual/e2e defects, weighted into Contract + Tests + Evidence.)

• Contract match (meets the spec / acceptance exactly): 25
• Tests (TDD followed; covers happy + every rejection/edge path; all green): 20
• Security & privacy (authz, input validation, no PII in logs, tenant isolation): 20
• Generality / architecture fit (generic core, tenant isolation, no banned vocab): 15
• Maintainability (small files, no dead code, no swallowed errors, clear naming): 10
• Evidence quality (commands, raw transcripts, reproducible verdicts present): 10

Hard caps (override the weighted sum): any high/critical → capped at 70; missing tests or TDD not followed → 80; missing required raw evidence (e.g. no cross-family transcript on a cross-family gate) → 85; any known failing test left in → 60 (enforced: tests_failing>0 vetoes passed=true regardless of self-score — a rosy self-score can't override a real failing test).

Part QA. G5 — visual layer ON TOP of the exhaustive Part E2E (frontend only)

G5's exhaustive coverage (every element / route / state, happy + unhappy) is Part E2E — do that FIRST. This Part QA is the VISUAL layer added on top of it. Runs in a builder (Claude) session with real browser tooling (Playwright); cross-family judgment still happens at JUDGE. App runs LOCALLY (dev server + emulators), never cloud. On top of the Part E2E matrix, check:

• Render capture screenshots at each step (desktop + mobile width).
• Direction / locale — dir correct (RTL where the org requires), no mojibake, logical-property layout not visually broken.
• States (visual) — empty / loading / error / the feature's specific states render correctly.
• e2e — the exhaustive Part E2E matrix (every element/route/state, happy + unhappy) passes end-to-end against the real local backend/emulators — not "the relevant flow," not component-mocked.
• Parallel visual sub-agents per screen; reconcile findings. Evidence: screenshots/* + e2e report + verdict.json (score > threshold, findings[]).

Part DG. Verdict integrity & degraded fallback (enforced by your evidence check)

• A codex/agy (cross-family) verdict REQUIRES a raw-transcript.md whose sha256 matches verdict.json.raw_transcript_sha256 — no transcript, no cross-family credit.
• If BOTH cross-family providers are exhausted, a Claude self-review is verdict_author: claude-degraded with degraded_requires_recheck: true, and you add a pending_cross_family_rechecks entry. G7 and JUDGE MUST fail while any recheck is pending (Part L checks this).
• NEVER label a Claude-authored verdict as codex/agy — that fakes A25 and is the one integrity line that, if crossed, makes the whole cross-family safety net a lie.

Part G. Concrete per-gate checklists (the gates not covered by Parts V/S/QA/L)

G2 = Part V. G3 = Part S. G5 = Part QA + Part E2E. G4 backend e2e = Part E2E. G7 = Part L. The rest, concretely:

G0 — design freeze (cross-family reviewer). Produce a FROZEN design doc containing: the goal + the exact "done" definition; in-scope vs explicit non-goals; the data model / interfaces / error catalog the feature will use; the chosen approach + 1–2 rejected alternatives + why; and the acceptance criteria as concrete, testable bullets (these are exactly what G1's tests must hit and what every later gate measures against). Resolve open questions ONE AT A TIME (never batch). Freeze criteria: zero unresolved blocking ambiguities; every acceptance bullet is concrete + testable; a cross-family reviewer signs off (stands in for human design approval). Output: the design doc (in the task folder) + a verdict. The frozen doc is the contract G1..JUDGE hold the work to.

G1 — implement, TDD (builder). Map EACH acceptance bullet → at least one test. Per bullet: write the test, RUN it, prove RED (capture), implement minimally, prove GREEN; refactor with tests green. Lint+formatter clean. Commit per cycle (Rule R18). Self-score via Part SR's six subscores. Evidence: commands.md, test-output.txt (red→green), git-clean.txt (feature-clean), test-results.json (consistent counts, tests_failing=0), verdict.json (commit = a real HEAD). Pass needs self-score > threshold AND every acceptance bullet covered by a test that would go RED if the behavior broke.

G4 — full suite + exhaustive backend e2e (builder; PM keystone re-runs). Discover the project's test/lint/format commands (from the build manifest / project config) and record them in the ledger so they are stable. The builder runs the FULL suite including the exhaustive backend/CLI/API e2e of Part E2E (every command/endpoint × works/fails/edge, real data, multi-step flows, persistence across restart); YOU independently re-run it (Rule R2) and veto on non-zero. Evidence: full test-output.txt + test-results.json (total/passed/failing(0)/skipped) + the Part E2E coverage matrix. Any failing test → red (rubric cap 60); any uncovered public command/endpoint → a Tests finding. Prefer the harness's own re-run output as authoritative over agent-pasted (the H38 direction).

G6 — works-locally (builder; PM re-runs). Smoke matrix by stack: CLI → --version/--help + one real end-to-end command, assert exit code + output; API/service → boot against LOCAL emulators, hit a health/route, assert the response; UI → covered by G5. Where relevant, check persistence (write then read back), clean exit, clean logs. Green tests are NOT a substitute (H26) — the artifact must actually run. Evidence: the command(s) + captured output + verdict.

JUDGE — between-feature, cross-family. Build the inventory: THIS feature's acceptance + EVERY prior done feature's contract. Probe: (a) this feature meets its acceptance BY EXECUTION (run the commands); (b) run the full suite + spot-check each prior feature's key behavior — no regression; (c) generic-core / no scope-creep. Score via Part SR; pass = > threshold AND zero high/critical AND zero regression. A behavioral claim the binary refutes is dropped (H26). Cross-family identity + transcript integrity (Part DG).

Part GU. The command guard (Rule R11) — contract

Every shell command the PM or any agent runs is routed through ONE guard that fails-closed:

• DENY (and STOP for an explicit human go) any command in the irreversible/outward categories: registry publish (npm publish / cargo publish / pip upload / docker push), cloud/prod deploy (your prod project/account ids), live external sends (email/SMS/chat to real users), prod data drops, default-branch force-push, secret / CI-config mutation. Maintain the deny patterns as regexes in project config.
• DENY merge verbs / default-branch push / PR-approve to NORMAL callers; ALLOW them ONLY when invoked by the land step (Part L) with an explicit flag.
• ALLOW everything else (build / test / lint / git on the work branch / local run / local emulators).
• Gate native commands on EXIT CODE, not stderr text (Rule R10). On a denied command, print the reason and exit non-zero so the caller stops. The guard is a DEPLOY/merge filter, not a sandbox — only declare TRUSTED commands.

Part E2E. Exhaustive end-to-end coverage — the BAR (this is NOT smoke)

"It compiles and one happy path works" is NOT acceptance. G6 is only a fast smoke pre-check; the REAL coverage lives in G4 (backend/CLI/API) and G5 (frontend), and both are RED until the matrix below is covered with REAL data (real local files, a real local DB/emulator — not mocks where a real local resource exists). The Tests reviewer (Part V lens 6) flags any uncovered public path as a finding.

Backend / CLI / API/service — exhaustive e2e (G4):

• Enumerate every command / subcommand / endpoint from the spec. For EACH, test all three classes:
  1. Works — the happy path with real data: assert exit code/HTTP status + output/payload + side effects (persistence: write, then read it back; idempotency where claimed).
  2. Doesn't work — EVERY failure/rejection path: bad args, missing/extra fields, wrong types, malformed/oversized/empty/non-UTF8 input, not-found, unauthorized / cross-tenant, conflict, rate-limit — assert the EXACT error code / catalog string AND that state is left unchanged (atomic reject).
  3. Edge/boundary — zero / one / many / max / min / unicode / duplicate / interleaved.
• Multi-step e2e flows with real data — chain commands as a user would (e.g. create → read → update → list → export → import → delete → compact) and assert end-state correctness + persistence across a process restart.
• API/service — boot the REAL server against LOCAL emulators; exercise every route × method × {authz-pass, authz-fail, valid body, each invalid body}; assert status + body + persisted effect.

Frontend — exhaustive Playwright e2e, CLI-driven (G5):

• Drive the REAL app (local dev server + emulators) with the Playwright CLI — e2e, not component-mocked.
• Every interactive element — every button, link, form field, toggle, menu, modal: click/fill/submit each and assert the resulting state/navigation/request.
• Every route / navigation path — including back/forward, deep links, guarded routes.
• Every state per view — empty, loading, success, error, validation-failure, permission-denied, offline/network-error.
• Happy AND unhappy — submit invalid input → assert the error UI; force a failing request → assert graceful handling (no white screen, no swallowed error).
• Cross-cutting — desktop + mobile widths; locale/direction (RTL where required, no mojibake); keyboard/a11y basics. Capture screenshots + Playwright traces as evidence.

Coverage evidence (both): a coverage matrix in the gate evidence — backend: (command/endpoint) × (works / fails / edge); frontend: (interactive-element / route / state) × (happy / unhappy) — showing each cell exercised and its result. A public command/endpoint/route/interactive-element with no e2e test is a finding (HIGH if it's a documented contract path). A suite that proves only happy paths is incomplete. The PM independently re-runs the e2e suite at G4/G5 (Rule R2 keystone) — agent-claimed coverage that the harness re-run can't reproduce does not count.