--- name: ulw-loop description: Goal-like loop that uses ultrawork mode to decompose work into systematic, evidence-bound steps. metadata: short-description: Goal-like ultrawork loop for systematic decomposition --- ## Role Expert goal orchestration agent. You conduct; right-sized parallel subagents play. Plan multi-goal work that survives across turns and sessions, fan independent work out to workers, QA every result yourself, record only proven evidence. Use GPT-5.x style: outcome-first, evidence-bound, atomic decisions, no nested branching prose. ## Goal Deliver every goal in `.omo/ulw-loop/goals.json` end-to-end. Prove EVERY success criterion with captured observable evidence from a real-usage scenario you actually ran (HTTP call / tmux / browser use / computer use — see the Manual-QA channels below). TESTS ALONE NEVER PROVE DONE. A green test suite is supporting evidence, not completion proof. Audit each pass, fail, block, steering change, and checkpoint in `.omo/ulw-loop/ledger.jsonl`. ## Manual-QA channels Run each criterion's real-surface proof yourself through the channel that faithfully exercises it; capture the artifact before recording PASS. 1. **HTTP call** — hit the live endpoint with `curl -i` (or a Playwright APIRequestContext); capture status line + headers + body. 2. **tmux** — `tmux new-session -d -s ulw-qa-`, drive with `send-keys`, dump via `tmux capture-pane -pS -E -`; transcript is the artifact. 3. **Browser use** — use Chrome to drive the REAL page; if Chrome is not available, download and use agent-browser (https://github.com/vercel-labs/agent-browser). Capture action log + screenshot path. Never downgrade to a non-browser surface for a browser-facing criterion. 4. **Computer use** — when the surface is a desktop/GUI app rather than a page, drive it via OS-level automation (a computer-use agent, AppleScript, xdotool, etc.) against the running app; capture action log + screenshot. Use this for any non-browser GUI criterion. For TUI visual QA, pair the tmux transcript with a browser-rendered terminal screenshot. In this repo run `node script/qa/web-terminal-visual-qa.mjs --from-file --evidence-dir ` and record `terminal.png`, `terminal.html`, `terminal.txt`, and `metadata.json` as the visual evidence bundle. This is mandatory when a PR or review needs to inspect the terminal screen, not just the text. Auxiliary surfaces (CLI stdout / DB state diff / parsed config dump) are first-class evidence for CLI- or data-shaped criteria; use a channel scenario when the behavior is user-facing. `--dry-run`, printing the command, "should respond", and "looks correct" never count. ## Delegation model (ATLAS-STYLE — YOU CONDUCT, WORKERS PLAY) You read, search, plan, integrate, and QA. You DELEGATE every code edit, test write, bug fix, and QA execution to a right-sized `multi_agent_v1.spawn_agent` worker, then verify what comes back. Fan out independent tasks in PARALLEL in one response; serialize only on a NAMED dependency (one task consumes another's output or edits the same file). Size each worker to the task. Put the intended role, rigor level, and specialty inside the worker `message`. | Task shape | Message instruction | |---|---| | Trivial / mechanical (rename, move, obvious one-liner, config edit) | `TASK: act as a focused worker for a trivial mechanical edit. ...` | | Pure implementation against a clear spec (new function, endpoint, test from a named pattern) | `TASK: act as a high-rigor implementation worker. ...` | | Deep debugging / race / perf / subtle cross-module reasoning | `TASK: act as a deep debugging worker. ...` | | QA execution (drive a channel, capture evidence) | `TASK: act as a QA execution worker. ...` | | Read-only codebase search | `TASK: act as an explorer. ...` | | External library / docs research | `TASK: act as a librarian. ...` | | Final verification audit | `TASK: act as a rigorous final verification reviewer. ...` | For reviewer work, use a self-contained reviewer assignment, tight scope, and explicit verification in `message`. Never spawn a context-only child for review. Every worker message MUST carry: goal + exact files in scope; the PIN + failing-first proof required before production code (Per-Criterion Cycle step 3); constraints + project rules; the verification commands; the ONE Manual-QA channel and the exact evidence artifact to capture; for git-tracked edits, require `git-master` plus repository-wide and touched-path commit history inspection before commit. Workers have NO interview context — be exhaustive, and forward accumulated learnings to every next worker. Codex subagent reliability: - Start every `multi_agent_v1.spawn_agent` message with `TASK: `, then name `DELIVERABLE`, `SCOPE`, and `VERIFY`. State that it is an executable assignment, not a context handoff. - Use `fork_context: false` unless full history is truly required; paste only the context the child needs. Full-history forks can make the child continue old parent context instead of the delegated task. - Plan and reviewer agents may run for a long time; spawn them in the background, keep doing independent root work, and poll with short `multi_agent_v1.wait_agent` cycles. Never use a single long blocking wait for them. - For work likely to exceed one wait cycle, require the child to send `WORKING: - ` before long reading, testing, or review passes, and `BLOCKED: ` only when it cannot progress. - While any child is active, keep the parent visibly alive with active subagent count, agent names, latest `WORKING:` phase, and whether the parent is waiting for mailbox updates. - Track spawned agent names locally. Use `multi_agent_v1.wait_agent` for mailbox signals, not proof of completion. A timeout only means no new mailbox update arrived. Treat a running child as alive. - Fallback only when the child is completed without the deliverable, ack-only after followup, explicitly `BLOCKED:`, or no longer running. Then send `TASK STILL ACTIVE: return or BLOCKED: ` when a targeted followup can still recover the lane; otherwise record inconclusive, do not count it as pass/review approval, close if safe, and respawn a smaller `fork_context: false` task with the missing deliverable. ## Artifacts - `.omo/ulw-loop/brief.md`: original brief and durable constraints. - `.omo/ulw-loop/goals.json`: goals with embedded `successCriteria` per goal. - `.omo/ulw-loop/ledger.jsonl`: append-only audit trail. - Read artifacts before resuming, steering, or checkpointing. - After any compaction or context loss, re-read brief + goals + ledger FIRST via `omo sparkshell cat .omo/ulw-loop/ledger.jsonl` (or read the paths directly), then `omo ulw-loop status --json`, before any further action. Recover state from these artifacts; never re-plan from scratch or repeat completed work (re-hypothesizing inside a research goal is not a re-plan). - Never invent state outside `.omo/ulw-loop` artifacts or `omo ulw-loop status --json`. ## Bootstrap Do all three steps before execution. No edits, goal tools, or checkpointing before bootstrap completes. ### 1. Create goals from the brief Resolve the CLI before the first command. If `omo` is absent from PATH or lacks `ulw-loop`, use the stable local installer bin or cached Codex component CLI — same CLI, so PATH absence is not a blocker. If PATH is empty, the fallback uses shell builtins and absolute Node locations before reporting guidance, recording the failure in `.omo/ulw-loop/bootstrap-notepad.md`. ```sh CODEX_HOME="${CODEX_HOME:-$HOME/.codex}" ULW_LOOP_NODE="$(command -v node 2>/dev/null || true)" if [ -z "$ULW_LOOP_NODE" ]; then for candidate in /opt/homebrew/bin/node /usr/local/bin/node /usr/bin/node; do [ -x "$candidate" ] || continue ULW_LOOP_NODE="$candidate" break done fi ULW_LOOP_CLI= if command -v omo >/dev/null 2>&1 && omo ulw-loop help >/dev/null 2>&1; then ULW_LOOP_CLI=omo elif [ -n "$ULW_LOOP_NODE" ]; then for candidate in "$HOME/.local/bin/omo" "$CODEX_HOME/bin/omo" "$CODEX_HOME"/plugins/cache/sisyphuslabs/omo/*/components/ulw-loop/dist/cli.js; do [ -f "$candidate" ] || [ -x "$candidate" ] || continue if "$ULW_LOOP_NODE" "$candidate" ulw-loop help >/dev/null 2>&1; then ULW_LOOP_CLI="$candidate" break fi done if [ -n "$ULW_LOOP_CLI" ] && [ -n "$ULW_LOOP_NODE" ]; then omo() { "$ULW_LOOP_NODE" "$ULW_LOOP_CLI" "$@"; } fi fi if [ -z "${ULW_LOOP_CLI:-}" ]; then /bin/mkdir -p .omo/ulw-loop 2>/dev/null || mkdir -p .omo/ulw-loop 2>/dev/null || true NOTE="${NOTE:-.omo/ulw-loop/bootstrap-notepad.md}" printf '%s\n' "No ulw-loop-capable omo executable found; PATH omo may be the OpenCode CLI without the Codex ulw-loop subcommand, and cached ulw-loop CLI was not found under ${CODEX_HOME:-$HOME/.codex}." >> "$NOTE" 2>/dev/null || true printf '%s\n' "Install with npx lazycodex-ai install or set CODEX_LOCAL_BIN_DIR to a PATH directory." >&2 fi ``` If `ULW_LOOP_CLI` is empty, open the durable notepad first, record the missing CLI evidence, then surface the installer issue. Run one form: ```sh omo ulw-loop create-goals --brief "" --json omo ulw-loop create-goals --brief-file --json cat | omo ulw-loop create-goals --from-stdin --json ``` If the existing aggregate is already complete, do not steer or force the completed default state for unrelated new work. Start a fresh run with `omo ulw-loop create-goals --session-id ...`; use `--force` only when deliberately overwriting completed evidence. Write state through the CLI path. Do not hand-edit state files. ### 2. Refine success criteria + a Prometheus-grade QA and parallelism plan per goal Gather context BEFORE planning with parallel `explorer` / `librarian` workers plus your own read-only tools. First survey available skills: read every loosely-relevant skill's description, deliberately choose which this work uses, and prefer applying genuinely-relevant skills over working raw. Then run tier triage per goal — rigor (LIGHT/HEAVY below) and shape (`delivery` default, or `research` when the deliverable is a cited answer, not an artifact) — and record both in an `annotate_ledger` steering entry. Default is LIGHT — a narrow change inside existing layers. Take HEAVY only on a fact you can point to: a new module / abstraction / domain model; auth, security, or session; an external integration; a DB schema or migration; concurrency, transaction boundaries, or cache invalidation; a cross-domain refactor; or the user signaled care or demanded review. When unsure, take HEAVY; upgrade the moment a HEAVY fact surfaces, never downgrade mid-run. HEAVY goals: spawn the `plan` agent with the gathered context, follow its wave ordering and parallel grouping exactly, and run the verification it specifies; carry 3+ successCriteria covering happy path, edge, regression, and adversarial risk. LIGHT goals: plan directly; carry 1-2 successCriteria (happy path + the riskiest edge) with one real-surface proof of the deliverable. Research-shape goals change the cycle: BEFORE each investigation, read this goal's prior ledger findings and open hypotheses, then extend them — never re-investigate an answered question (the ledger is your research notebook). Record findings via `annotate_ledger` with their source (`file:line`, command output, doc URL) as `--evidence`. Track hypotheses as `HYPOTHESIS[id]: | status: open`, flipped to `confirmed`/`refuted` only on an observed source. A research criterion passes on a cited answer — skip QA-channel, cleanup, and commit, but keep source-observability (never "looks correct"). Keep hypotheses inside the user's stated question; a scope-widening one is an `add_subgoal` proposal you surface, never silent creep. For a `research`-shape goal you MAY load `ulw-research` (legacy alias: `ultraresearch`) without hesitation — otherwise explicit-request-only, a research-shape goal IS that explicit demand. Research-only: never for a `delivery` goal. It composes with the librarian routing above — `ulw-research` for saturation (many parallel sources, recursive expansion), a single `librarian` for one lookup. For each criterion, define upfront: `id`, exact `scenario` (tool + inputs + binary pass/fail), `expectedEvidence` artifact path, adversarial classes, stop condition, and Manual-QA channel. Vague QA ("verify it works") is a rejected criterion — revise it before execution. For optimization work, capture baseline speed before changes plus behavior/regression proof. Every attempt records speed, behavior/regression, and the keep/revert/iterate decision. A criterion's adversarial classes are the ultraqa classes a fact about the change triggers: malformed input, prompt injection, cancel/resume, stale state, dirty worktree, hung or long commands, flaky tests, misleading success output, repeated interruptions. Record untriggered classes as not-applicable in one line. Use channel-table evidence verbs (tmux transcript, curl status+body, screenshot, action log, CLI stdout, DB diff, parsed config dump) — not vibes. **Plan for maximum parallelism (HEAVY goals).** Decompose each goal's criteria into atomic tasks (Implementation + its Test = ONE task, never split) and group them into dependency waves. Target 5–8 tasks per wave; <3 per wave (except the final wave) means under-splitting — extract shared prerequisites into Wave 1. For each task record its wave, what it blocks, what blocks it, the worker tier from the Delegation table, and its QA scenario + evidence path. Build a dependency matrix (Task | Depends on | Blocks | Can parallelize with) and name the critical path. Anything not on a real dependency edge MUST share a wave and dispatch together. Revise any criterion that lacks observable `expectedEvidence` or a named channel before execution. ### 3. Inspect state Run `omo ulw-loop status --json`. Read pending goals, criteria IDs, current ledger head, blockers, and aggregate Codex objective. ## Execution Loop Loop per goal. Cap at 5 cycles per goal. Cap identical same-criterion failures at 3. ### Acquire Next Goal 1. Run `omo ulw-loop complete-goals --json` and read the handoff, including criteria. 2. Call `get_goal` and inspect active Codex state. 3. Apply this table exactly: | get_goal result | action | |-----------------|--------| | no active goal | Call `create_goal` with objective only from `instruction.json.objective`; do not copy lifecycle fields such as `status`. | | same aggregate objective active | Continue the current ulw-loop story. | | different goal active | STOP. Checkpoint blocked and surface the conflict. | 4. If retrying failed work, run `omo ulw-loop complete-goals --retry-failed --json`. 5. Never create a second Codex goal for the same aggregate objective. ### Per-Criterion Cycle 1. PLAN: read `criterion.scenario`, `criterion.expectedEvidence`, prior ledger entries, and safety bounds. Identify which tasks in the current wave are independent. 2. Register atomic todos via `update_plan` — one ultra-granular step per action, `path: for - verify by `. Call `update_plan` on every transition (start → `in_progress`, finish → `completed`); exactly one `in_progress`, mark completed immediately, never batch, never let the rendered plan lag behind reality. 3. DELEGATE-IN-PARALLEL: dispatch every independent task in the wave at once via right-sized `multi_agent_v1.spawn_agent` workers (Delegation table). Each worker captures evidence failing-first: when the task touches EXISTING behavior, PIN it FIRST — a characterization test that asserts the current observable behavior and PASSES on the unchanged code, as rigorous as the new-behavior scenario (exact inputs, exact observable, exact assertion). Then RED through the cheapest faithful channel — a unit test where a seam exists, an integration/e2e test where the behavior lives in wiring, or the criterion's scenario captured failing when no test seam exists — failing for the RIGHT reason (no syntax/import error). A test that mirrors its implementation (mock-call assertions, pinned constants, cannot fail under plausible regression) is not evidence; use the scenario as the failing proof instead. Then the SMALLEST GREEN change; before GREEN work that depends on external review, PR, issue, or branch state, refresh current branch/PR/issue state, preserve existing ordering/policy, and separate compatibility detection from policy changes unless the goal explicitly asks to change policy. A GREEN far larger than the criterion implies means the proof was too coarse — instruct a split. Serialize only on a NAMED dependency. 4. INTEGRATE + CRITICAL SELF-QA + GIT CHECKPOINT (EVERY WORKER RETURN): do NOT trust the worker's report. Read the diff yourself, re-run its tests, and run LSP diagnostics on the changed files. Treat "done" as a claim to disprove. If the diff drifts, the test is hollow, or evidence is missing, RESPAWN the worker with the specific failure context. Once the work unit is verified, use `git-master` before staging: inspect recent repository commits and touched-path history to infer commit language, Conventional Commit scope, message shape, and unit size. Stage only that unit's files and commit in the observed style; do not carry verified work forward into a later omnibus commit. If no git-tracked files changed or committing is unsafe, record the no-commit reason as evidence. Forward every finding/learning to subsequent workers. 5. EXECUTE-AS-SCENARIO: ACTUALLY run the Manual-QA scenario the criterion named (channel table above). Run it yourself for the orchestrator check; for heavier flows dispatch a dedicated QA worker (`worker`, `gpt-5.5`, `high`) whose ONLY job is to drive the channel and write the artifact to the named evidence path. If the scenario FAILS, respawn the implementing worker with the captured failure — do not hand-patch around it. 6. CAPTURE: collect the observable artifact path: transcript, stdout, screenshot, assertion, status+body, diff, or parsed dump. No artifact written at the evidence path — not done; record BLOCKED and respawn QA. 7. CLEAN (PAIRED, NEVER SKIP): tear down every runtime artifact step 5 spawned BEFORE recording — server PIDs (`kill`, verify `kill -0` fails), `tmux` sessions (`tmux kill-session -t ulw-qa-`; confirm `tmux ls`), browser / Playwright contexts (`.close()`), containers (`docker rm -f`), bound ports (`lsof -i :` empty), temp sockets / files / dirs (`rm -rf` the `mktemp` paths), QA-only env vars, AND `multi_agent_v1.close_agent` on every finished worker. Register each teardown as its own todo the moment the QA spawns the resource (scripts, tmux assets, browsers / agent-browser sessions, PIDs, ports) so none is forgotten. Embed a one-line cleanup receipt in the evidence string, e.g. `cleanup: killed 12345; tmux kill-session ulw-qa-foo; rm -rf /tmp/ulw.aB12cD; multi_agent_v1.close_agent w-3`. Missing receipt → record BLOCKED, not PASS. 8. RECORD exactly one result: - PASS: `omo ulw-loop record-evidence --goal-id --criterion-id --status pass --evidence " | " --json` - FAIL: `omo ulw-loop record-evidence --goal-id --criterion-id --status fail --evidence " | " --notes "" --json` - BLOCKED: `omo ulw-loop record-evidence --goal-id --criterion-id --status blocked --evidence "" --notes "" --json` 9. If actual does not match expected, diagnose, respawn the right-sized worker with the failure context to fix minimally, and rerun the SAME criterion (including a fresh cleanup). 10. After 3 same-criterion failures, exit the goal with diagnosis. 11. After 5 cycles on one goal without required criteria passing, checkpoint failed. 12. Continue only when the next pending criterion has a concrete `expectedEvidence` target. ### Goal Completion 1. Non-final aggregate goal: confirm every `essential` criterion is `pass`; non-essential criteria may remain pending. Final aggregate goal: confirm every criterion across the whole plan is `pass`. 2. Call `get_goal` for a fresh snapshot. 3. Run `omo ulw-loop checkpoint --goal-id --status complete --evidence "" --codex-goal-json --json`. 4. If blocked or failed, checkpoint with `--status blocked` or `--status failed` and include diagnosis evidence. 5. If this is the final goal, run the final quality gate first and pass `--quality-gate-json`. ## Final Quality Gate Trigger only for the final aggregate goal after every criterion in every goal is `pass`. 1. Run targeted verification for changed behavior. 2. Run Manual-QA for every criterion; confirm each artifact exists and is non-empty. 3. Spawn final reviewers with `fork_context: false`: code review, QA review, gate review. Include original brief, goals, desired outcome, and diff. 4. Treat timeout, missing deliverable, ack-only, `BLOCKED:`, or inconclusive review as a blocker. Fix, rerun affected verification/Manual-QA, and repeat review. 5. If review remains blocked, run `omo ulw-loop record-review-blockers --goal-id --title "<...>" --objective "<...>" --evidence "" --codex-goal-json --json`. 6. If clean, checkpoint final completion: ```sh omo ulw-loop checkpoint --goal-id --status complete --evidence "" --codex-goal-json --quality-gate-json --json ``` `--quality-gate-json` shape: ```json { "codeReview":{"by":"lazycodex-code-reviewer","recommendation":"APPROVE","codeQualityStatus":"CLEAR","reportPath":"packages/omo-codex/plugin/components/ulw-loop/test/fixtures/artifacts/code-review.md","evidence":"Diff review passed.","blockers":[]}, "manualQa":{"by":"lazycodex-qa-executor","status":"passed","evidence":"CLI and data surfaces passed.","surfaceEvidence":[{"id":"surface-cli-pass","criterionRef":"C1","surface":"cli","invocation":"omo ulw-loop checkpoint --quality-gate-json sample-quality-gate.json --json","verdict":"passed","artifactRefs":["artifact-cli-pass"]},{"id":"surface-data-pass","criterionRef":"C2","surface":"data","invocation":"diff -u before-ledger.json after-ledger.json","verdict":"passed","artifactRefs":["artifact-data-diff"]}],"adversarialCases":[{"id":"adv-malformed-input","criterionRef":"C3","scenario":"malformed gate input omits manual QA evidence","expectedBehavior":"validator rejects ULW_LOOP_QUALITY_GATE_INVALID","verdict":"passed","artifactRefs":["artifact-cli-reject"]}],"artifactRefs":[{"id":"artifact-cli-pass","kind":"cli-transcript","description":"CLI pass artifact.","path":"packages/omo-codex/plugin/components/ulw-loop/test/fixtures/artifacts/cli-pass.txt"},{"id":"artifact-cli-reject","kind":"log","description":"Reject log artifact.","path":"packages/omo-codex/plugin/components/ulw-loop/test/fixtures/artifacts/rejection.txt"},{"id":"artifact-data-diff","kind":"data-diff","description":"Data diff artifact.","path":"packages/omo-codex/plugin/components/ulw-loop/test/fixtures/artifacts/data-diff.txt"}]}, "gateReview":{"by":"lazycodex-gate-reviewer","recommendation":"APPROVE","reportPath":"packages/omo-codex/plugin/components/ulw-loop/test/fixtures/artifacts/gate-review.md","evidence":"Gate review passed.","blockers":[]}, "iteration":{"fullRerun":true,"status":"passed","rerunCommands":["bunx vitest run packages/omo-codex/plugin/components/ulw-loop/test/quality-gate-doc.test.ts"],"evidence":"Focused rerun passed."}, "criteriaCoverage":{"totalCriteria":3,"passCount":3,"originalIntent":"User wanted artifact-backed completion.","desiredOutcome":"Behavior ships with review and QA evidence.","userOutcomeReview":"Result matches brief and goals.","adversarialClassesCovered":["malformed_input","stale_state"]} } ``` Artifacts must be non-empty; counts alone fail. LIGHT without adversarial class records `"adversarialClassesCovered": ["none-applicable: "]`. ## Dynamic Steering Use steering only for structured evidence-backed mutation. Reject natural-language steering requests. | Kind | When to use | Required fields | |------|-------------|-----------------| | add_subgoal | Real blocker found; new story required | `--title`, `--objective`, `--evidence`, `--rationale` | | split_subgoal | Story too large; needs decomposition | `--goal-id`, `--children` JSON, `--evidence`, `--rationale` | | reorder_pending | Discovered dependency order | `--order` JSON array of ids, `--evidence`, `--rationale` | | revise_pending_wording | Title/objective ambiguous | `--goal-id`, `--title?`, `--objective?`, `--evidence`, `--rationale` | | revise_criterion | Criterion lacks observable PASS evidence | `--goal-id`, `--criterion-id`, `--scenario?`, `--expected-evidence?`, `--evidence`, `--rationale` | | annotate_ledger | Audit-only note | `--evidence`, `--rationale` | | mark_blocked_superseded | Old story replaced by new evidence | `--goal-id`, `--replacements?`, `--evidence`, `--rationale` | Command form: `omo ulw-loop steer --kind [] --evidence "<...>" --rationale "<...>" --json`. Structured prompt directives accepted: `OMO_ULW_LOOP_STEER: { ... }`, `omo.ulw-loop.steer: {...}`, `omo ulw-loop steer: {...}`. ## Constraints 1. NEVER call `update_goal` mid-aggregate; only on final story after the quality gate passes. 2. NEVER call `create_goal` when `get_goal` shows a different active goal. 3. NEVER mark `criterion.status == "pass"` without captured observable evidence in `record-evidence`. 4. NEVER bypass the criteria gate: non-final aggregate completion requires all essential criteria; final aggregate completion requires all criteria across the whole plan. 5. Baseline build/lint/typecheck/test commands are necessary evidence, NOT SUFFICIENT completion proof. Criteria coverage with observable evidence is the gate. 6. Treat `.omo/ulw-loop/ledger.jsonl` as the durable audit trail; checkpoint after every success or failure. 7. Per-story Codex goal mode is opt-in only with `--codex-goal-mode per-story`; default is aggregate. 8. Structured steering directives mutate state through validation; normal prose does not. 9. Evidence MUST be observable from the real surface: tmux transcript, curl status+body, browser/Playwright assertion, CLI stdout, DB state diff, parsed config dump. 10. Probe the adversarial classes each criterion's trigger facts name (list in Bootstrap step 2); record untriggered classes as not-applicable in one line. 11. After completing an aggregate ulw-loop run, clear the Codex goal manually with `/goal clear` before starting another in the same session. 12. The shell command emits a model-facing handoff; only the Codex agent calls `get_goal`, `create_goal`, or `update_goal` tools. 13. NEVER record `--status pass` while a QA-spawned process, `tmux` session, browser context, bound port, container, or temp file / dir is still alive, or while any worker is still open. The evidence string MUST include the cleanup receipt. Leftover runtime state = BLOCKED, not PASS. 14. DELEGATE all code edits, test writes, fixes, and QA execution to right-sized `multi_agent_v1.spawn_agent` workers (Delegation table); you read, search, plan, integrate, and QA. NEVER record `--status pass` from a worker's self-report — only from evidence you re-verified yourself. Dispatch independent tasks in parallel; serialize only on a NAMED dependency. 15. Every verified work unit that touched git-tracked files must leave either an atomic `git-master`-style commit hash or explicit no-commit blocker evidence before the next unit starts. ## Stop Rules - All goals complete plus every plan criterion `pass` plus final quality gate clean: DONE. - 3x same criterion failure: checkpoint failed, surface diagnosis. - 5 cycles on one goal without required criteria passing: checkpoint failed, surface. - Safety boundary such as destructive command, secret exfiltration, or production write: block and surface a safe substitute. - Codex `get_goal` reports a different active goal: checkpoint blocker, stop, surface. - Leftover state from QA (live process, `tmux` session, browser context, bound port, temp dir): NOT pass. Clean up, append the receipt, then continue. - User issues `/cancel`: release in-progress state cleanly and do not auto-resume.