Supergoal Claude Code Audit: The Deleted Deliverable That Passed

Supergoal reported a deleted deliverable as present, and it did so with a green exit code. A fresh 23 July 2026 replay reproduced that result against the current public source: tag v0.7.0, commit a8761ed5c5317e5f5f480b0f5069d97b146bf5b4. The same 22-case probe also confirmed what the helper gets right—it sees committed, staged, unstaged, untracked, and deleted work in one inventory.

That mixed result is the reason to use Supergoal with a narrow job description. It is a useful run ledger for long Codex or Claude Code work. It is not a release authority. Roadmaps, phase files, retry state, and final-audit output preserve evidence across a long session; repository-native tests and end-state assertions decide whether the promised result exists.

The purchase is a ledger, not more autonomy

Supergoal wraps a coding agent with files that can outlive one prompt. Its planner writes a roadmap, state, phase specifications, and a protocol under a namespaced .supergoal/ run directory. The execution handoff advances phases, retains verification requirements, and bounds recovery: first retry, then a focused fix specification, then a human handoff after another failure.

Those artifacts answer questions that chat history answers badly after a long run: Which revision was the baseline? Which phase owns the current diff? What failed? Which commands were mandatory? What evidence was requested? A reconnect, context compaction, or model handoff does not erase the files.

The boundary matters. Codex CLI owns local repository work, tools, permissions, skills, and review. OpenClaw can own message routing and session persistence around that work. Supergoal contributes a repository-local planning and audit convention. None of those layers proves the others: a persistent session does not prove a build, and a complete phase file does not prove its deliverable.

Three proof surfaces hide behind one “complete”

A Supergoal run produces several kinds of evidence, but they answer different questions. Promotion gets unsafe when they are collapsed into one boolean.

The plan receipt

ROADMAP.md, STATE.md, and the phase files show what the run promised and how it intended to verify the work. They are excellent for ownership and recovery. They remain claims until the required commands and observations actually run against the final tree.

The tree receipt

repo-state.sh deliberately compares more than HEAD. In the disposable repository, it found a file committed after baseline, a staged addition, an unstaged tracked edit, an untracked file, an unchanged baseline file, and a deletion. That is materially stronger than an audit based only on git diff baseline..HEAD.

The release receipt

A release receipt asks whether the candidate now satisfies the repository’s contract. A must-exist file needs an existence and type assertion. A generated document may need a schema validator or hash. A removal needs absence. Code needs the project’s own build, tests, typecheck, lint, migrations, and security checks as appropriate. Supergoal can carry those commands through the run, but their fresh results—not the phase marker—authorize promotion.

Two green exits change the promotion policy

Deletion is change, not presence

The first branch of repo-state.sh deliverable asks Git for a path-limited diff stat. Any non-empty stat prints “present — changed vs baseline” and returns zero. Deletion produces a non-empty stat, so it enters the same branch as an added or modified file.

baseline: deleted.txt exists
working tree: deleted.txt removed

repo-state.sh deliverable <baseline> deleted.txt
present — changed vs baseline (1 file changed, 1 deletion(-))
exit: 0

The helper truthfully established that the path participated in the run. It answered the wrong release question. The correction is not a more elaborate diff parser; it is an explicit deliverable contract. Classify each output as must-exist, must-change, must-delete, or generated, then test that final state directly.

Four headings can contain zero criteria

The phase validator blocked a missing phase-start marker, a missing file, no argument, and the absence of Work, Acceptance criteria, Mandatory commands, or Evidence required. It did not block a phase that retained all four headings but removed every bullet. That fixture printed a “look thin” warning, reported “structure ok,” and exited zero.

That choice is defensible for a general-purpose skill: bullet counts are crude, and prose criteria can be legitimate. A high-risk repository should make its own stricter decision. Every deliverable should have at least one machine-runnable assertion or an explicitly named human-review reason. “Thin” can remain advisory for low-risk work and become terminal for a release candidate.

The handoff should seal a candidate, not continue the run

The safest operating model keeps Supergoal’s durable orchestration and draws a hard boundary before external mutation. The autonomous loop may repair code and collect evidence. Promotion begins only after it hands a stable candidate to a fresh reviewer.

1. Seal the candidate state. Record exact HEAD, staged diff, unstaged diff, deletions, and untracked inventory. Restart review if any component changes.
2. Resolve deliverables by final state. Apply different assertions to must-exist, must-change, must-delete, and generated outputs. A deletion cannot satisfy an existence promise.
3. Run repository-native checks in a clean command context. Build, tests, typecheck, lint, migrations, and security checks carry semantic weight that template structure cannot.
4. Review the complete diff. Include secrets, debug output, dependency drift, scope expansion, and generated files—not only committed changes.
5. Keep subjective evidence explicit. UI quality, copy, and product judgment need screenshots or a named reviewer rather than an automated-pass label.
6. Promote only the sealed revision. Reconcile current upstream state, rerun affected checks, and use the repository’s normal release workflow.

This policy preserves the part of Supergoal worth adopting: the roadmap, state, bounded recovery, mandatory-command ledger, and full-tree inventory. It rejects only the category error that turns “the run recorded completion” into “the repository is releasable.”

The evidence is current, narrow, and reproducible

The 23 July replay cloned the public v0.7.0 source, bound both helper scripts by SHA-256, and ran the retained 22-case fixture inside a disposable Git repository. All expected results matched; the deleted-deliverable and zero-bullet cases remained warnings. Six current primary-source checks also passed, including the public main revision, pinned README and scripts, official Codex CLI documentation, and official OpenClaw session documentation.

The probe did not install Supergoal into Codex or Claude Code, invoke a model, execute a real autonomous phase, measure token use, judge plan quality, modify a production repository, use credentials, merge code, release an application, or deploy infrastructure. It establishes source behavior at one revision—not completion rates or future behavior.

• Supergoal repository — current main and tested tag v0.7.0 resolve to commit a8761ed5c5317e5f5f480b0f5069d97b146bf5b4.
• Pinned Supergoal README — run artifacts, preflight, recovery, working-tree comparison, and final audit.
• Pinned repo-state.sh — deliverable, changed-file, and added-line behavior.
• Pinned validate-phase.sh — required sections and thin-criteria warning.
• Official Codex CLI documentation — local coding surface, permissions, and skills.
• Official OpenClaw session documentation — routing, persistence, storage, and reset boundaries.

The conclusion is intentionally smaller than the autonomy pitch. Supergoal makes a long run easier to inspect and resume. The repository’s own evidence still decides whether the result can ship.