An auditor that runs your undo steps, not just reads them
The phase-auditor checks one thing: did Claude deliver exactly what each part of the plan promised? It compares the promised files, tests and checks against what actually changed. Then it runs every undo step itself, in a separate copy of your repo. An undo step that does not undo is a critical finding.
How to use it
TLM Forge launches it for you after you type /tlmforge:build and describe the task. It runs once, in the background, at the final review (Stage 5) on Medium and Deep work, over the whole change. It does not run after each part of the build. Light work runs no review agents.
Words you will see on this page
- Light, Medium, Deep
- TLM Forge's three levels of care: Light is a tiny edit, Medium fixes or improves what exists, Deep adds something new or changes a security decision.
- Phase and phase spec
- A phase is one part of the build, committed on its own; its spec is the written promise of what that part will change and test.
- Evidence notes
- Claude's record for each phase of what it did, including test output.
- Rollback (undo step)
- The written command for undoing a phase, such as reverting a commit or reversing a database migration.
- Worktree
- A separate, temporary copy of your repo, so running undo steps never touches the copy you are working in.
- Final review (Stage 5)
- Reviewers check the whole finished change at the end of the build.
What it looks for
| What it looks for | An example of what it catches |
|---|---|
| Promised files never changed | The phase spec says the retry module will change, but it was never touched. CRITICAL. |
| Files changed outside the promise | A file the spec never mentioned was edited anyway. MEDIUM scope creep. |
| Promised tests missing, failing or at the wrong level | A promised integration test was written only as a unit test. HIGH. |
| Claims without proof | The notes say "all tests pass" but show no test output, or report counts that do not match the saved run. |
| Success criteria with no evidence | A checkbox in the phase spec has no matching proof in the notes. HIGH. |
| Undo steps that do not undo | Running the phase 2 undo step leaves the new payments_retryattempt table in the database. CRITICAL. |
When it runs
| Level | Does it run? | When, in plain words |
|---|---|---|
| Light (tiny edit: typo, rename, config value) | No | Claude makes the change directly, with a test first. No review agents run. |
| Medium (fix or improve something that exists) | Yes, once | At the end, on the whole finished change, next to the code-reviewer (plus the ux-reviewer if the change has a user interface). TLM Forge tells Claude not to start the fix step until it has run. |
| Deep (something new, or a change to how security decisions are made) | Yes, once | At the end, on the whole finished change, as one of five reviewers working at the same time (six if the change has a user interface). |
What it does
On Medium and Deep work, Claude builds in parts called phases, and each phase starts from a written phase spec: the files it will change, the tests it will add, how success is checked, and a rollback table (how to undo it, how long that takes, and whether data is at risk). The auditor treats the spec as the promise, Claude's evidence notes as the receipt, and the actual code changes as the delivery.
It walks each list in order. A promised file that was never changed is CRITICAL. A file changed outside the promise is MEDIUM scope creep. A promised test that is missing or failing is CRITICAL, and one at the wrong level is HIGH. Notes that say "tests pass" without the real test output are HIGH, and numbers that do not match the saved test run are CRITICAL.
Then it runs things. In its own temporary copy of your repo, never your working copy, it runs every phase's undo step in reverse order and checks the code really goes back as promised. It also runs every proof command from the goal file whose output was not already saved. TLM Forge's own notes say that reading evidence produced tidy-up notes, while the auditor's real catches came from running the undo.
How it works, step by step
Read the promise, receipt and delivery
The phase specs, Claude's evidence notes, GOAL.md (the build's goal file, listing how success will be proven) and every change since the build began, starting from the final-review brief.
Check scope
Every promised file must be changed in the way the spec says. Files changed outside the spec are flagged as scope creep, unless the edit is incidental, such as an import or a lint fix.
Check tests
Every promised test must exist, sit at the promised level and pass. The notes must include real test output and the full existing test suite result, and their numbers must match the saved run.
Check the success criteria
Each checkbox in the phase spec needs matching proof in the evidence notes, or it is a HIGH finding.
Run the undo steps and proofs
In a fresh temporary copy of the repo (a git worktree), it runs each phase's undo step in reverse order and each unsaved proof command, then deletes the copy. A command your Claude Code permissions refuse to run is recorded as blocked, not retried.
Give a verdict
Approve, needs revision, or do not ship. Any CRITICAL, such as a missing promised test or an undo step that does not undo, means do not ship.
What it looks like
What an audit report looks like. The undo step for phase 2 was supposed to remove a new database table, but when the auditor ran it, the table was still there. That one failure makes the verdict DO_NOT_SHIP. The content is invented; the format is the real one.
## Verdict: DO_NOT_SHIP
## Rollback safety
phase 2: migrate payments 0006 -> executed-fail
table payments_retryattempt still present after rollback
phase 1: git revert <sha> -> executed-pass
GOAL.md proof 1 -> executed-pass
{"reviewer": "phase-auditor", "verdict": "do_not_ship",
"findings": [{"severity": "critical", "file": "specs/retries/phase-2-retry-table.md",
"line": 13, "finding": "rollback leaves new table", "suggested_fix": "..."}]}Why it is better
Running beats reading
Without TLM Forge, an undo step that reads perfectly is assumed to work until the day you need it. With it, the auditor runs it in a clean copy, so the report says whether it actually restored the code.
Checks the receipts, not the story
Without it, Claude's own summary of what it did is taken on trust. With it, the auditor compares those notes against the real changes and the saved test run, so a summary that drifted from reality is caught.
Your working copy stays clean
Without care, running undo steps would mess up the files you are working in. With it, the auditor is told to run them in a temporary copy made for the audit and deleted afterwards.
Good to know
- It runs once, at the end, over the whole change. Undo steps and proof commands only all exist once the last part is committed, so there are no per-part runs.
- It is a promise checker only. It will approve a mediocre design that was delivered faithfully; design, edge cases, security and style belong to the other reviewers.
- It does not re-run your test suite. It cites the run TLM Forge saved at the audited commit; what it runs itself is the undo steps and any proof command without saved output.
- If a phase spec is too vague to say what was promised, it flags that as MEDIUM instead of inventing a scope to check against.
- Security or design concerns it notices go in its written report as notes only, never into its findings or verdict.