Repo Task Proof Loop

Platform behavior

• In Codex, keep the normal path serial and auto-mode-first after init. Avoid surfacing delegation internals unless they materially affect the work.
• In Codex, spawn bounded subagents only when the user explicitly asks for sub-agents, delegation, or parallel agent work.
• In Codex, once delegation is authorized, the skill may choose the matching child roles and whether to stay one-child-at-a-time or use bounded fan-out. The user should not need to name specific child roles or slash commands.
• In Codex, child spawning is still an explicit parent-orchestrator action. If the current Codex surface blocks delegation, say so briefly only when it materially affects the work, then continue serially.
• In Codex, keep the task tree shallow. The parent session should spawn research, builder, fixer, and verifier children directly instead of asking one custom task child to orchestrate more children.
• In Codex, once delegation is authorized, choose between one-child-at-a-time delegation and bounded fan-out from the frozen spec, repo shape, and current delegation surface. Keep init, evidence ownership, and every verifier pass serialized either way.
• In Codex, keep helper fan-out modest and wave-based. Prefer up to 3 parallel helper children at once, wait for that wave to finish, then decide the next phase.
• In Codex, built-in explorer is the first choice for read-only repo discovery and proof probes. Built-in worker is appropriate for bounded disjoint implementation or check reruns when you can assign explicit ownership.
• In Codex, reuse the live builder child for evidence packing by sending it a follow-up instruction. Verifier passes must use a fresh child or fresh session; do not satisfy verifier freshness by resuming an earlier verifier. Builder and fixer children can be reused or resumed when you intentionally want that context back.
• In Codex, inspect the current child-thread list before reusing or resuming a child. Use /agent in Codex CLI or any equivalent child-thread inventory surface available in the current Codex product surface.
• In Codex, the plan/todo checklist UI from update_plan is optional session guidance only. It is useful for live progress display, but it is not the source of truth for this workflow.
• In Claude Code, the skill should decide whether to stay on the main thread or let the main Claude session auto-delegate the current phase to a matching built-in or project subagent after init. The user should not need to request a specific Claude subagent or delegation mode separately.
• In Claude Code, TodoWrite or the visible task/todo UI is optional session-scoped progress display only. It can help with live tracking in the current session, but it is not the source of truth for this workflow.
• In Claude Code, prefer the installed project subagents from .claude/agents/, with descriptions written as proactive trigger conditions for the matching proof-loop phase. Claude's main session routes by the task request, subagent descriptions, and current context, so keep each phase prompt clear in natural language. Reuse the same builder child for the evidence step by default. Only run a fresh builder in evidence-only mode if the original builder session is unavailable or you intentionally discarded it. If init just refreshed .claude/agents/* during the current Claude session, fall back to the main thread or already-visible agents instead of assuming the refreshed ones are available immediately.
• In Claude Code, keep the orchestration flat: main-session auto-delegation is fine, but the proof-loop workflow agents themselves are leaf roles. The parent session should own the proof-loop phase transitions instead of asking one custom task agent to spawn another.
• In Claude Code, the canonical durable state is always the repo-local artifact set under .agent/tasks/<TASK_ID>/, especially spec.md, evidence.md, evidence.json, verdict.json, and problems.md.
• If subagents are unavailable, preserve the same role separation across separate sessions or clear mode changes in the current session.

Use the exact role prompts from references/COMMANDS.md.

Spec freeze requirements

spec.md must contain at least:

• original task statement
• explicit acceptance criteria labeled AC1, AC2, ...
• constraints
• non-goals

It may also include:

• repo guidance sources
• verification plan
• assumptions resolved narrowly from the user request

Do not edit production code during spec freeze.

Evidence packing requirements

evidence.md and evidence.json must judge each acceptance criterion independently with one of:

• PASS
• FAIL
• UNKNOWN

Evidence packing may run missing checks, but it must not keep changing production code.

Every PASS must cite concrete proof such as:

• file paths
• commands run
• exit codes
• output summaries
• artifact paths under raw/

Do not claim overall PASS in the evidence bundle unless every acceptance criterion is PASS.

Fresh verification requirements

The verifier must be a fresh session or fresh subagent. In Codex, do not satisfy this requirement by resuming a prior verifier child.

The verifier must judge the current repository state and current rerun results, not the builder narrative.

The verifier writes:

• .agent/tasks/<TASK_ID>/verdict.json
• .agent/tasks/<TASK_ID>/problems.md only when overall verdict is not PASS

problems.md must include, for each non-PASS criterion:

• criterion id and text
• status
• why it is not proven
• minimal reproduction steps
• expected vs actual
• affected files
• smallest safe fix
• corrective hint in 1-3 sentences

The verifier must not modify production code or backfill the evidence bundle.

Fixer requirements

The fixer reads only:

• spec.md
• verdict.json
• problems.md

The fixer must:

• reconfirm each listed problem in the codebase before editing
• make the smallest safe change set
• avoid regressing already-passing criteria
• regenerate evidence.md, evidence.json, and raw artifacts
• stop without writing final sign-off

Validation

Before claiming the workflow is correctly initialized or the artifact set is complete, run:

scripts/task_loop.py validate --task-id <TASK_ID>

Run validate only after init has fully finished. If it reports initialization in progress, wait and rerun it instead of treating that result as stable task failure.

For a quick summary:

scripts/task_loop.py status --task-id <TASK_ID>

Run status only after init has fully finished when you need stable task state. If it reports init_in_progress: true, treat that as a retry-later condition.

Guardrails

• Keep .agent/tasks/<TASK_ID>/ inside the repo
• Treat the Codex todo/checklist UI as ephemeral progress only; the durable workflow state lives in .agent/tasks/<TASK_ID>/
• Never claim task completion unless every acceptance criterion is PASS
• Separate evaluator and fixer roles
• Keep Codex fan-out shallow and bounded. Parallel helpers may inform the proof loop, but one builder still owns evidence and one fresh verifier still owns verdict.
• Keep the verifier fresh
• Prefer the smallest defensible diffs during fixes
• Preserve existing user guidance outside the managed blocks in AGENTS.md and the repo's chosen Claude guide file