Walking the autodev flow

About the point in time this series describes

This series is a record based on the harness environment as it existed at the time of writing (file contents, run logs, file counts). The harness has kept evolving since this series was written, so quoted file contents, counts, and procedures may differ from the current state. The focus of this series is the design ideas (five-facet separation, verification gates, growth discipline) rather than the specific values.

This chapter walks through how the 5 facets + orchestrator (takt-inspired) actually combine in the autodev flow, using the anagram-check task in autodev-smoke (a scratch repo for verifying the autonomous-dev flow), with real-document excerpts for each phase.

Quoting the run transcript verbatim is the highest-priority direction in this series. "Don't stop at concepts; quote examples generously" is the goal, and concrete files go into the body even at the cost of length.

6.1. The target task: anagram-check

anagram-check is one of the 7 tasks implemented in autodev-smoke. Its spec:

Take s1 and s2 as the first and second arguments, sort both in Unicode code points, and exit 0 if they match exactly (an anagram), 1 otherwise. Empty-vs-empty is an anagram (exit 0). Raw comparison (case-sensitive, no Unicode normalization). Argument count not 2 (0 / 1 / 3+) returns exit 1.

Implementation highlights:

• Node.js v18+ built-in only (zero dependencies)
• Pure function isAnagram(s1, s2) + main(argv) + entry guard, in three sections
• Tests via node:test + spawnSync direct CLI; only exit-code asserts (stdout/stderr are free-form)
• 10 test cases including BMP-outside surrogate-pair input that verifies Array.from (code-point unit) behavior

The autodev flow ran this from ⓪' to ⑤ without VERDICT FAIL or stagnation. The phases follow.

6.2. ⓪' Pre-launch assert + resume judgment

The launch command:

/autodev /Users/<name>/.claude/repos/autodev-smoke/specs/anagram-check.md

What the main agent (orchestrator) does in ⓪', in 5 steps:

1. realpath the spec path → extract <repo> from ~/.claude/repos/<repo>/specs/<feature>.md
2. Read/trim ~/.claude/repos/<repo>/.repo_root → obtain repo_root
3. Assert work-tree via git -C <repo_root> rev-parse --is-inside-work-tree
4. Pin the base SHA via git -C <repo_root> rev-parse HEAD
5. Create a new ~/.claude/repos/<repo>/handoff/<task>/state.md (Read if resuming)

After ⓪' for anagram-check, state.md looks like:

# state: anagram-check

base_sha: 8eb7cc4b59e9f3666196aac10b351fe5babd9a73
repo: autodev-smoke
repo_root: /Users/<name>/Dev/autodev-smoke
spec_path: /Users/<name>/.claude/repos/autodev-smoke/specs/anagram-check.md
spec_sha256: ce67c282c486503ad40286a02087238d7a77712e16d0c9fcdc2e332212da0092
last_completed_step: phase0
plan_iteration: 0
impl_iteration: 0
error_signature: ""
story_needs_resync: true
pending_human_decision: ""
task_branch: anagram-check-impl

Two pinned values matter:

• base_sha: 8eb7cc4b...: master HEAD pinned by SHA. Downstream subagents operate on it; auditor uses git diff <base_sha>...<task_branch> for the impl diff
• spec_sha256: ce67c282...: SHA256 of the spec. Editing spec mid-implementation would change this; spec edits require a state-thaw procedure (= the circular defense for the verification contract)

anagram-check's spec carries the function description plus a 10-case acceptance table. Function description and acceptance excerpt:

## Function overview
Implement a CLI at `src/anagram-check.js`. Take S1 and S2 as first and second
arguments, sort both **in Unicode code points**, and exit 0 if they match
exactly (anagram). Empty-vs-empty (`'' ''`) is anagram (exit 0). Arg count
not 2 (0 / 1 / 3+) → exit 1.

## Acceptance (pass conditions = test oracle)

**The 10 cases asserted by `test/anagram-check.test.js` via `spawnSync`**:

| # | input args (JS literal) | expected exit | purpose |
| --- | --- | --- | --- |
| 1 | `'abc'`, `'cba'` | 0 | ASCII basic anagram |
| 2 | `'listen'`, `'silent'` | 0 | classic anagram |
| 3 | `'hello'`, `'world'` | 1 | not an anagram |
| 4 | `''`, `''` | 0 | empty vs empty |
| 5 | `''`, `'a'` | 1 | one empty = length mismatch |
| 6 | `'a'`, `'A'` | 1 | raw compare; case-sensitive |
| 7 | `'🍣A'`, `'A🍣'` | 0 | BMP-outside surrogate pair |
| 8 | (no args) | 1 | invalid: 0 args |
| 9 | `'a'` (1 arg) | 1 | invalid: 1 arg |
| 10 | `'a'`, `'b'`, `'c'` | 1 | invalid: 3 args |

This 10-case table lives as the test oracle from ⓪' through merge.

6.3. ① architect spawn

After ⓪', the orchestrator spawns the architect subagent. The spawn prompt injects spec.md + per-repo knowledge (CLAUDE.md / CONTEXT.md) by absolute path.

Excerpt of the plan.md architect produced for anagram-check:

# plan: anagram-check

> architect-generated. Covers all 10 spec.md pass conditions. The
> implementation pattern is isomorphic to the existing palindrome-check.js.

## Implementation plan

1. **Create `src/anagram-check.js` and implement the pure function `isAnagram(s1, s2)`**
   - `Array.from(s1)` / `Array.from(s2)` to decompose by **code point**
     (avoids splitting BMP-outside surrogate pairs; required by case 7)
   - Length compare for early short-circuit (case 5)
   - Sort both arrays; compare with strict equality across all elements
   - Case-sensitive raw compare (no Unicode normalization)
   - → covers: cases 1, 2, 3, 4, 5, 6, 7

2. **Implement argument guard and exit code in `main(argv)`**
   - `argv.length !== 2` → stderr + exit 1
   - → covers: cases 8, 9, 10

3. **Implement the CLI entry and export**
4. **Create `test/anagram-check.test.js` and verbatim-transcribe the 10 cases**
5. **Verification** (in developer's worktree; recorded in done.md)
6. **Add the anagram-check term to `CONTEXT.md`** (pointer tier)

## Architecture decisions

### Decision 1: comparison algorithm (chosen: sort + element-wise)

| Choice | Trade-off | Adopt |
| --- | --- | --- |
| **A. sort + element-wise** | O(n log n). Code-point-natural with `Array.from`. | **Adopted** |
| B. frequency map | O(n). No edges, but over-engineering. | Rejected |
| C. `s.split('')` route | Shortest, but **`split('')` splits surrogates by code unit**. | **Forbidden** |

Three things matter in architect's output:

Point 1: 1:1 mapping between pass conditions and implementation steps

Each step contains an explicit "→ covers: cases 1, 2, 3, ..." mapping. The pass conditions in spec and the steps in plan are directly aligned, making coverage easy for plan-reviewer to check.

Point 2: trade-off table (adopt + reject)

Decision 1 lists choices A / B / C with adopt/reject status and reasons. Listing forbidden adoption explicitly (case C is rejected in spec) is part of inlining that context.

Point 3: column-form doc-update obligations

plan.md ends with the column-form doc-update table:

## Doc-update obligations

| Target path | Tier | Updater | Verification path |
| --- | --- | --- | --- |
| `/Users/<name>/.claude/repos/autodev-smoke/CONTEXT.md` |
  pointer (outside worktree; not a developer commit target) |
  **orchestrator (delegate)** |
  auditor Reads to verify term addition |
| `/Users/<name>/Dev/autodev-smoke/src/anagram-check.js` |
  real repo (inside worktree) |
  **developer (worktree commit)** |
  auditor `git diff` to verify new addition |
| `/Users/<name>/Dev/autodev-smoke/test/anagram-check.test.js` |
  real repo (inside worktree) |
  **developer (worktree commit)** |
  auditor `git diff` + done.md `node --test` evidence for 10/10 green |

The "Tier" column splits pointer / real repo and the "Updater" column branches orchestrator (delegate) / developer (worktree commit) accordingly. This structure didn't exist at bootstrap; Phase 1-3 iterations introduced it (see Chapter 8).

6.4. ①' plan-reviewer spawn

After architect produces plan.md, the orchestrator spawns the plan-reviewer subagent. The spawn prompt absolute-path-injects both spec.md and plan.md.

plan-reviewer's output contract is emit VERDICT: PASS|FAIL as the first line of the final utterance. For anagram-check, plan-reviewer issued VERDICT: PASS with only a minor finding (a slight literal-form inconsistency for the surrogate-pair test).

The orchestrator runs:

grep '^VERDICT:' /Users/<name>/.claude/repos/autodev-smoke/handoff/anagram-check/review.md

and uses only the output (= VERDICT: PASS) for branching. No need to read the full ~80-line review.md into context. This is takt's official Output Contract from Chapter 3 (implemented here as the first-line VERDICT: PASS|FAIL convention in review.md).

On FAIL, findings are injected and architect re-spawns (plan bounce up to 1). For anagram-check, no FAIL occurred.

6.5. ② Human approval

Once plan-reviewer returns PASS, the orchestrator presents plan.md to the human (the author) for approval.

The presentation is a single AskUserQuestion, with the following separated by blank lines:

• Implementation plan, a 3-5 line summary
• Adopted choice + main trade-offs
• Impact range (touched files as clickable links)
• Doc-update obligations (column table)
• A trailing link to the full plan.md (at the time of this run it used the file:/// URI form; a later revision changed the rule to raw absolute paths — see Chapter 8)

For anagram-check's ② human approval, the orchestrator presented roughly:

plan-reviewer VERDICT: PASS. anagram-check plan covers all 10 spec cases and
uses the same shape as palindrome-check (Array.from + sort + every).

Adopted choice: sort + element-wise (O(n log n), code-point)
trade-offs: frequency map (O(n) but over-engineering); split('') (forbidden
because split('') splits surrogates by code unit)

Impact range:
- new: src/anagram-check.js / test/anagram-check.test.js (real repo, developer commit)
- add: CONTEXT.md (pointer tier, orchestrator delegate)

Doc-update obligations: column table with 3 rows (1 pointer / 2 real-repo)

[plan.md full text](file:///Users/<name>/.claude/repos/autodev-smoke/handoff/anagram-check/plan.md)

The human picks "approve" from the 3-way (approve / specify changes / abort), and the orchestrator moves on to story.md composition.

Why AskUserQuestion is used at human approval

When /spec-design / /autodev asks for human approval, plain-text "is this OK?" is forbidden (~/.claude/rules/interaction.md). Why:

• Plain-text questions easily get buried in context; the human misses them
• AskUserQuestion uses structured choices (3-way) and provides a "specify changes" route
• It's aligned with hooks/check-plain-question.sh (Stop sensor) blocking plain-text questions

Plain-text confirmation at approval is blocked by check-plain-question.sh's CONFIRMATION pattern ("OK with this?" / "is this good?").

6.6. ②' story.md composition

After human approval, the orchestrator composes story.md by merging the relevant pieces of spec + plan, plus acceptance criteria verbatim and a SELECTIVE pull of per-repo knowledge.

story.md is developer's sole primary input. "Sole" matters: developer does not separately consult spec.md / plan.md. The story.md carries everything needed in itself.

Excerpt from anagram-check's story.md:

# story: anagram-check

> orchestrator-composed. spec + plan-relevant pieces embedded as an
> idempotent derived artifact (source of truth = spec + plan). The sole
> primary input for developer.

## Purpose
Implement a CLI at `src/anagram-check.js` that judges whether two arguments
are anagrams in Unicode code points.

## Acceptance (verbatim from spec)
(10-case table verbatim)

## Implementation plan (from plan.md)
1. **`src/anagram-check.js` new** (CommonJS, zero dependencies):
   ```js
   function isAnagram(s1, s2) {
     const a = Array.from(s1);
     const b = Array.from(s2);
     if (a.length !== b.length) return false;
     const sorted1 = [...a].sort();
     const sorted2 = [...b].sort();
     return sorted1.every((c, i) => c === sorted2[i]);
   }
   function main(argv) {
     if (argv.length !== 2) {
       process.stderr.write('usage: anagram-check <s1> <s2>\n');
       process.exit(1);
     }
     process.exit(isAnagram(argv[0], argv[1]) ? 0 : 1);
   }
   if (require.main === module) {
     main(process.argv.slice(2));
   }
   module.exports = { isAnagram };

Architecture constraints (SELECTIVE)

per-repo Policy excerpt + key design points

Dependencies and preconditions

• base SHA: 8eb7cc4b...
• task branch: anagram-check-impl
• worktree: /tmp/autodev-smoke-anagram-check

Doc-update obligations

(verbatim from plan.md, column-form)

Note that plan.md's column table is **transcribed verbatim** into story.md. This lets developer interpret doc-update obligations correctly, and auditor reference the column table for matching.

## 6.7. ③ developer spawn

Next the orchestrator spawns `developer`. Spawn-time steps:

1. `git -C <repo_root> branch <task_branch> <base_sha>` — branch from the base SHA
2. `git -C <repo_root> worktree add /tmp/<repo>-<task> <task_branch>` — create the worktree
3. Pass story.md path and worktree path to the developer subagent via spawn prompt

Inside the worktree, developer does:

1. `npm install` (deps resolve; even with zero deps, run in isolated worktree)
2. Implement `src/anagram-check.js` according to story.md
3. Create `test/anagram-check.test.js` (verbatim 10 cases)
4. Run pass conditions in the worktree (`node --test test/anagram-check.test.js` / `npm test` / 6 individual CLI directs)
5. Record evidence in `done.md`
6. Update docs (real-repo ones from story's "Doc-update obligations")
7. Commit to the task branch

Excerpt of `anagram-check`'s done.md:

```markdown
# done: anagram-check

> developer's implementation evidence. Per pass condition, cmd + exit code +
> output summary + PASS/FAIL recorded in tables (verification.md discipline).

## Environment
- worktree: `/tmp/autodev-smoke-anagram-check`
- task branch: `anagram-check-impl`
- base SHA: `8eb7cc4b59e9f3666196aac10b351fe5babd9a73`
- deps install: `npm install` → `up to date, audited 1 package` /
  `found 0 vulnerabilities`

## pass condition evidence

### representative machine judgment (`node --test`)

| # | cmd | expected | actual exit | output summary | verdict |
| --- | --- | --- | --- | --- | --- |
| T1 | `node --test test/anagram-check.test.js` | exit 0 / `pass 10` / `fail 0` | 0 |
       `tests 10 / pass 10 / fail 0 / cancelled 0 / skipped 0 / todo 0 /
        duration_ms 337.84` — all 10 ✔ | **PASS** |
| T2 | `npm test` (all tests) | exit 0 (existing 6 files + new anagram-check) | 0 |
       `tests 48 / pass 48 / fail 0` (anagram 10 + factorial 4 +
       fizzbuzz-cli 8 + fizzbuzz 4 + isprime 4 + palindrome 9 +
       reverse-string 9 = 48) | **PASS** |

### per-CLI direct (6 cases)

| # | cmd | expected exit | actual | output | verdict |
| --- | --- | --- | --- | --- | --- |
| C1 | `node src/anagram-check.js abc cba` | 0 | 0 | empty stdout/stderr | **PASS** |
| C2 | `node src/anagram-check.js listen silent` | 0 | 0 | empty | **PASS** |
| C3 | `node src/anagram-check.js hello world` | 1 | 1 | empty | **PASS** |
| C4 | `node src/anagram-check.js '' ''` | 0 | 0 | empty | **PASS** |
| C5 | `node src/anagram-check.js` | 1 | 1 | stderr: `usage: anagram-check <s1> <s2>` | **PASS** |
| C6 | `node src/anagram-check.js a b c` | 1 | 1 | stderr: `usage: anagram-check <s1> <s2>` | **PASS** |

## summary
- pass conditions: 8 (T1, T2, C1-C6)
- PASS: 8 / FAIL: 0
- broken existing tests: none (`npm test` 48/48 PASS, existing 38 cases green)

## commit
- branch: `anagram-check-impl`
- commit SHA: `4651e09e21af6562a91bacab0fbb656c44ffd439`
- target: only `src/anagram-check.js` / `test/anagram-check.test.js` new
- working tree: clean (verified by `git status` post-commit)

Three things to note in done.md:

Point 1: cmd + exit code + output summary + verdict per pass condition

For each of the 8 pass conditions (T1, T2, C1-C6), the command, actual exit, output summary, and verdict are recorded. This implements the "back claims with evidence" Policy of rules/verification.md.

Point 2: no broken existing tests

T2 runs npm test over all 48 cases (existing 38 + new 10), all green. This matches the per-repo Policy in ~/.claude/repos/autodev-smoke/CLAUDE.md: "no change may break existing tests."

Point 3: commit SHA + working-tree-clean check

The commit SHA 4651e09e... is recorded, and git status confirms a clean working tree after commit. This implements "state-changing operations must re-verify the actual state" from rules/verification.md.

6.8. ④ auditor spawn

Once developer writes done.md and commits, the orchestrator spawns auditor.

auditor does not run pass conditions itself (read-only / fresh --bare). It compares done.md evidence against expectations re-derived from spec.md. This is the heart of takt's "Separation Improves Quality" principle (8 design principles #3); see Chapter 3.

The audit has 3 pillars:

1. Primary signal (done.md evidence ⇔ spec re-derivation)
2. code ⇔ spec (git -C <repo_root> diff <base-SHA>...<task-branch>; worktree non-invasive)
3. doc-update omissions (against story's column table)

Excerpt of anagram-check's review.md:

# review: anagram-check (auditor)

VERDICT: PASS

> auditor audit. Comparing done.md evidence against expectations re-derived
> from spec.md, with `git -C /Users/<name>/Dev/autodev-smoke
> diff 8eb7cc4...anagram-check-impl` for code ⇔ spec and CONTEXT.md Read for
> doc-update omissions. All three pillars consistent.

## 1. Primary signal (done.md ⇔ spec.md re-derivation)

### Representative machine judgment (re-derived from spec.md L12-18)

| spec original (re-derived expected) | done.md evidence | verdict |
| --- | --- | --- |
| `node --test test/anagram-check.test.js` → exit 0 / `pass 10` / `fail 0` |
   T1: exit 0, `tests 10 / pass 10 / fail 0` | PASS |
| `node src/anagram-check.js abc cba` → exit 0 | C1: exit 0 | PASS |
| ...

(Other 5 cases match similarly)

## 2. code ⇔ spec (`git diff 8eb7cc4...anagram-check-impl`)

### `src/anagram-check.js` (new, 22 lines)
- `Array.from(s1)` / `Array.from(s2)` for code-point unit → spec-conformant, case 7 passes
- `if (a.length !== b.length) return false` early short-circuit → plan decision 3
- `[...a].sort()` + `every((c, i) => c === sorted2[i])` → plan decisions 1 / 2
- No `toLowerCase` / `normalize` → spec (raw compare), case 6 passes
- Single guard `if (argv.length !== 2)` → plan decision 4
- `if (require.main === module)` entry guard → plan step 3

## 3. Doc-update omissions (against story.md column table)

| target path | owner | verification | result |
| --- | --- | --- | --- |
| `~/.claude/repos/autodev-smoke/CONTEXT.md` (pointer) |
  orchestrator (delegate) |
  Read for term addition |
  PASS — CONTEXT.md L8 explicitly states the term |
| `src/anagram-check.js` (real repo) |
  developer (worktree commit) |
  `git diff` for new addition |
  PASS — diff shows new file mode (22 lines) |
| `test/anagram-check.test.js` (real repo) |
  developer (worktree commit) |
  `git diff` + done.md `node --test` for 10/10 green |
  PASS — diff shows new file mode (59 lines) + T1 10/10 green |

VERDICT: PASS

auditor's audit re-derives from spec.md rather than trusting story.md (an intermediate derived artifact). This is the implementation of the circular defense (don't trust derived artifacts; go back to the original). Even if developer misreads story, auditor catches inconsistency against the spec original.

VERDICT: PASS is emitted as the first line of the final utterance, and the orchestrator confirms it via grep '^VERDICT:'.

6.9. ⑤ ff merge

On PASS from auditor, the orchestrator runs the ff merge:

git -C /Users/<name>/Dev/autodev-smoke checkout master
git -C /Users/<name>/Dev/autodev-smoke merge --ff-only anagram-check-impl

For anagram-check, master advanced 8eb7cc4 → 4651e09 (state.md's master_sha_after_merge: 4651e09e21af6562a91bacab0fbb656c44ffd439).

Post-merge cleanup:

• Remove the manual worktree (/tmp/autodev-smoke-anagram-check) with git worktree remove
• Delete the task branch (anagram-check-impl) with git branch -d (no --force needed because of ff merge)
• Preserve the handoff dir (~/.claude/repos/autodev-smoke/handoff/anagram-check/)

The handoff dir is preserved after merge for these reasons:

• Anchor for resume (if the same task gets additional work later)
• Source for iteration cycles (looking back at past plan / done / review)
• Subject of monthly /harness-prune for 30-day-zero-reference detection

6.10. Full history of the anagram-check run in state.md

Restating the ## History section of state.md, which captures the whole flow:

## History
- ⓪' phase0 complete (assert pass, base_sha pin, spec_sha256 frozen,
                        handoff dir new)
- ① architect complete
  (VERDICT: PASS, column-form ## doc-update obligations table generated;
   verification (c) OK)
- ①' plan-reviewer complete (VERDICT: PASS, column-table consistency)
- ② human approval → story.md composed
  (pointer-tier doc update delegated to orchestrator)
- ③ developer complete (VERDICT: IMPL_READY,
                         worktree=/tmp/autodev-smoke-anagram-check,
                         pass conditions 8/8 PASS, npm test 48/48 PASS,
                         existing 38 cases intact)
- verification (b) PASS: developer subagent reached autonomous commit
                          (4651e09e), passing through with the new hook fix
                          = §11 #2 lasting fix in production
- verification (a) continued: no new .claude/worktrees/agent-*
- orchestrator delegate: 1 line added to CONTEXT.md (pointer tier)
- ④ auditor complete (VERDICT: PASS, three pillars consistent,
                        column-table delegated CONTEXT.md was correctly
                        judged as not a doc-update omission)
- ⑤ ff merge succeeded (master 8eb7cc4 → 4651e09)
- cleanup: manual worktree + task branch deleted

Each step completed in a single straight run on the same day — what matters isn't the date itself, but the order and each phase's verdict.

This history is a condensed run transcript for the autodev flow. Each line corresponds to ⓪' through ⑤, plus these verification flags:

• Verification (a): no new .claude/worktrees/agent-* (the doubled-worktree issue is resolved) — Phase 1-3 iteration #4+#7
• Verification (b): developer subagent reached an autonomous commit (the subagent-commit-gate hook fix took effect) — Phase 1-3 iteration #2
• Verification (c): architect generated a column-form doc-update obligations table naturally (the plan.md template column-form took effect) — Phase 1-3 iteration #3

These verifications act as production-environment tests for the new harness's structural soundness. Concrete iteration history is in the next chapter (08. Iteration cycles).

6.11. Feedback Loop paths (bounces)

The anagram-check task was an example that completed without triggering VERDICT FAIL. All the actual state.md histories (including palindrome-check) pass straight through with PASS verdicts at ①' / ④, and as of this series' writing, no straight-line FAIL → bounce example remains in autodev-smoke's handoff directories.

Bounce paths observed in Phase 4 verification (recorded in ~/.claude/plans/phase4-verification-report.md) are documented below.

Path A: ①' plan-reviewer FAIL → architect re-spawn

In Phase 4 A-4, a plan was deliberately constructed against fizzbuzz with adversarial spec-coverage gaps. plan-reviewer pointed out "pass condition X isn't covered by any plan step" and returned VERDICT: FAIL. The orchestrator grepped the FAIL, injected the finding into the spawn prompt, and re-spawned architect. The second pass returned PASS, and subsequent phases proceeded. This is takt's "Feedback Loops Are First-Class" principle (#4) firing via fail-closed grep '^VERDICT:'.

Path B: ② human-approval [specify changes] → architect re-spawn

In the isPrime task, the human chose [specify changes] at ②, asking for "Miller-Rabin instead of naive trial division." The orchestrator incremented plan_iteration by 1 and re-spawned architect, which produced a plan using Miller-Rabin with deterministic bases [2, 3, 5, 7, 11, 13] and BigInt modPow. The second pass returned plan-reviewer PASS, the subsequent phases ran, and ⑤ ff merge (fe3743a) completed. This is a plan bounce by human judgment, not by VERDICT FAIL, consuming 1 of the plan-bounce budget.

Plan bounces (① → ①') are allowed up to 1; impl bounces (③ → ④) up to 2. Beyond that, stagnation detection (same error_signature twice) escalates to a human (takt principle 5 "Human Judgment Is an Escalation Path"; see Chapter 3).

Tracking bounce history

Each task's bounce count is recorded in plan_iteration / impl_iteration in state.md. Both anagram-check and palindrome-check show 0 — confirming completion without bounces from state.md.

6.12. The full autodev flow (recap)

Recapping the walkthrough in one diagram:

6.13. Summary of this chapter

Key points

• ⓪' pins base SHA + spec SHA into state.md → circular defense holds through implementation
• ① architect → plan.md (implementation plan + arch choices + impact + column-form doc obligations)
• ①' plan-reviewer → fail-closed branching via VERDICT (grep '^VERDICT:' only)
• ② human approval → 3-way AskUserQuestion + a clickable link to the full plan.md
• ③ developer → implement / run pass conditions / record done.md evidence / task-branch commit, all inside the worktree
• ④ auditor → 3-pillar match: done.md evidence ⇔ spec original re-derivation + git diff + doc-update omissions
• ⑤ ff merge + cleanup → preserve the handoff dir (resumable / iteration-cycle source)
• Both anagram-check and palindrome-check complete without VERDICT FAIL (plan_iteration / impl_iteration = 0); bounce examples were observed in other tasks (fizzbuzz adversarial plan / isPrime human-specified change; see 6.11)
• Inside the autodev chain, plan-reviewer / auditor VERDICT contracts handle the gating critique, so devil-advocate (used only on the main-agent path; see 5.3) does not fire inside autodev (avoiding double firing; explicitly noted in rules/adversarial-review.md)

The next chapter covers the growth discipline that supports the autodev flow — the 5 rules that put friction at the entrance and a pull at the exit — with concrete examples of inverted approval.