autodev フローの実走

この連載が記述する時点

本連載は執筆時点のハーネス実環境 (設定ファイルの内容、実行記録、ファイル数) を素材にした記録です。ハーネス本体は公開後も改修が続いているため、引用したファイル内容や個数、手順は現在の実体と異なる場合があります。本連載の主眼は個々の値ではなく設計の考え方 (5 関心分離、検証ゲート、成長規律) にあります。

本章は、ここまで整理してきた 5 facet + orchestrator (takt 思想) が実際にどう組み合わさって動くかを、autodev-smoke (= 自律開発フロー検証用 scratch repo) の anagram-check task を例に、⓪'-⑤ の各 phase で何が起きたかを spec / plan / story / done / review の 実物引用付き で walkthrough します。

実走 transcript を verbatim 引用するのは、本連載執筆中に最も重視した方針です。「概念だけで終わらせない」「実例を惜しまず入れる」が目標で、ファイルサイズが多少大きくなっても具体物を本文に置きます。

6.1. ターゲット task: anagram-check

anagram-check は autodev-smoke で実装した 7 task の 1 つで、次の仕様の CLI です。

第 1 引数 s1、第 2 引数 s2 を受け取り、両者を Unicode code point 単位で sort して完全一致するなら anagram と判定し exit 0、そうでなければ exit 1 で終了する。空文字列同士は anagram 扱い (exit 0)。raw 比較 (case-sensitive、Unicode 正規化なし)。引数数 ≠ 2 (0 / 1 / 3 以上) は exit 1。

実装の特徴は次の通りです。

Node.js v18+ 組み込みのみ (依存ゼロ)
純関数 isAnagram(s1, s2) + main(argv) + entry guard の 3 部構成
テストは node:test + spawnSync 直叩き、exit code のみ assert (stdout/stderr は freeform)
BMP 外サロゲートペアを含む 10 ケースで Array.from (code point 単位) の挙動を検証

autodev フローでこれが ⓪' から ⑤ まで一直線で完走 (VERDICT FAIL も停滞検出も起きずに) しました。これを各 phase に分けて見ていきます。

6.2. ⓪' 起動前 assert + resume 判定

起動コマンドは次のとおりです。

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

main agent (= orchestrator) が ⓪' で行うのは次の 5 ステップです。

spec パスを realpath で絶対化 → ~/.claude/repos/<repo>/specs/<feature>.md から <repo> 抽出
~/.claude/repos/<repo>/.repo_root を Read/trim して repo_root 取得
git -C <repo_root> rev-parse --is-inside-work-tree で work tree assert
git -C <repo_root> rev-parse HEAD で base SHA を取得
~/.claude/repos/<repo>/handoff/<task>/state.md を新規作成 (resume なら Read)

anagram-check の ⓪' 完了時、state.md は次の状態でした。

# 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

ここで pin している 2 つの値が重要です。

base_sha: 8eb7cc4b...: master HEAD を SHA で pin。以降の subagent はこの SHA を基準に動き、auditor は git diff <base_sha>...<task_branch> で実装差分を取得する
spec_sha256: ce67c282...: spec の SHA256 を pin。実装期間中に spec を変えると SHA が変わるため、spec 変更 = state 解凍手続きが必要 = 検証契約が壊れないようにする (= 循環防御)

anagram-check の spec は冒頭の機能概要に続いて、10 ケース表で受入基準を明示しています。spec 全文の機能概要 + 受入基準を引用します。

## 機能概要
`src/anagram-check.js` に CLI を実装する。第 1 引数 S1、第 2 引数 S2 を受け取り、
両者を **Unicode code point 単位**で sort して完全一致するなら anagram と判定し exit 0、
そうでなければ exit 1 で終了する。空文字列同士 (`'' ''`) は anagram 扱い (exit 0)。
引数の個数が 2 でない場合 (0 / 1 / 3 以上) は exit 1。

## 受入基準 (pass 条件 = テストオラクル)

**`test/anagram-check.test.js` で `spawnSync` を用いて assert する 10 ケース全文**:

| # | 入力引数 (JS リテラル) | 期待 exit | 目的 |
| --- | --- | --- | --- |
| 1 | `'abc'`, `'cba'` | 0 | ASCII basic anagram |
| 2 | `'listen'`, `'silent'` | 0 | 古典 anagram 例 |
| 3 | `'hello'`, `'world'` | 1 | anagram でない (ASCII) |
| 4 | `''`, `''` | 0 | 空文字列同士は anagram |
| 5 | `''`, `'a'` | 1 | 片方空 = length 不一致 → not anagram |
| 6 | `'a'`, `'A'` | 1 | raw 比較なので case-sensitive |
| 7 | `'🍣A'`, `'A🍣'` | 0 | BMP 外サロゲートペアを含む anagram |
| 8 | (引数なし) | 1 | 不正引数: 引数 0 |
| 9 | `'a'` (引数 1 つ) | 1 | 不正引数: 引数 1 |
| 10 | `'a'`, `'b'`, `'c'` (引数 3 つ) | 1 | 不正引数: 引数 3 以上 |

この 10 ケース表がテストオラクルとして ⓪' から merge まで生存し続けます。

6.3. ① architect spawn

⓪' 完了後、orchestrator は architect subagent を spawn します。spawn prompt には spec.md + per-repo 知識 (CLAUDE.md / CONTEXT.md) を絶対パスで注入します。

anagram-check で architect が生成した plan.md の核部分を引用します。

# plan: anagram-check

> architect 生成。spec.md ([anagram-check.md](.../specs/anagram-check.md)) の
> 10 ケース pass 条件を全網羅。実装パターンは既存 [palindrome-check.js](...) と同型。

## 実装計画

1. **`src/anagram-check.js` を新規作成し、純関数 `isAnagram(s1, s2)` を実装する**
   - `Array.from(s1)` / `Array.from(s2)` で **code point 単位**に分解
     (BMP 外サロゲートペアを裂かない仕様要件、ケース 7 用)
   - length 比較で早期 short-circuit (ケース 5)
   - 両配列を sort して全要素 strict equality で比較
   - case-sensitive raw 比較 (Unicode 正規化なし)
   - → 対応: ケース 1, 2, 3, 4, 5, 6, 7

2. **`main(argv)` で引数ガードと exit code を実装する**
   - `argv.length !== 2` → stderr + exit 1
   - → 対応: ケース 8, 9, 10

3. **CLI entry と export を実装する**
4. **`test/anagram-check.test.js` を新規作成し、spec.md テーブル 10 ケースを verbatim 転写する**
5. **動作検証** (developer worktree 内で実行、done.md に証跡記録)
6. **`CONTEXT.md` (pointer 層) に anagram-check 用語追記**

## アーキテクチャ判断

### 判断 1: 比較アルゴリズム (採用: sort + element-wise)

| 案 | trade-off | 採否 |
| --- | --- | --- |
| **A. sort + element-wise 比較** | O(n log n)。`Array.from` で素直に code point 単位。 | **採用** |
| B. frequency map | O(n)。エッジなし。ただし over-engineering。 | 却下 |
| C. `s.split('')` 経由 | 最短だが **`split('')` は code unit 単位**でサロゲートを裂く。 | **禁止採用** |

architect の出力で重要なのは次の 3 点です。

点 1: pass 条件と implementation step の 1:1 対応

各 step に「→ 対応: ケース 1, 2, 3, 4, 5, 6, 7」のような明示マッピングがあり、spec の pass 条件と plan の step が直接対応します。plan-reviewer がカバレッジを検証しやすい構造です。

点 2: トレードオフ表 (採用案 + 却下案)

判断 1 でいうと、「A. sort + element-wise」「B. frequency map」「C. s.split('')」の 3 案を並べ、採否と理由を併記しています。禁止採用まで明示している (= C 案は spec で却下されているという情報を inline 化) のが特徴です。

点 3: column 化された doc 更新義務

plan の末尾に column 化された doc 更新義務表があります。

## ドキュメント更新義務

| 対象パス | 層 | 更新者 | 検証経路 |
| --- | --- | --- | --- |
| `/Users/<name>/.claude/repos/autodev-smoke/CONTEXT.md` |
  pointer (worktree 外、developer commit 対象外) |
  **orchestrator (代行)** |
  auditor が Read で用語追記を確認 |
| `/Users/<name>/Dev/autodev-smoke/src/anagram-check.js` |
  実 repo (worktree 内) |
  **developer (worktree commit)** |
  auditor `git diff` で新規追加を確認 |
| `/Users/<name>/Dev/autodev-smoke/test/anagram-check.test.js` |
  実 repo (worktree 内) |
  **developer (worktree commit)** |
  auditor `git diff` + done.md `node --test` 証跡で 10 ケース全 green を確認 |

「層」列が pointer / 実 repo を区別し、それに応じて「更新者」が orchestrator (代行) / developer (worktree commit) を分岐しています。これは bootstrap 時点では存在せず、Phase 1-3 改修で詰めた構造です (第 8 章)。

6.4. ①' plan-reviewer spawn

architect の plan.md が生成されたら、orchestrator は plan-reviewer subagent を spawn します。spawn prompt には spec.md と plan.md の両方を絶対パスで注入します。

plan-reviewer の出力契約は 最終発話の先頭行を VERDICT: PASS|FAIL で始めるです。anagram-check の plan-reviewer は VERDICT: PASS を出し、軽微な指摘 (サロゲートペアのリテラル表記の整合性) のみ記録しました。

orchestrator は

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

の出力 (= VERDICT: PASS) のみで分岐判定します。review.md 全文 (約 80 行) を context に読み込む必要はありません。これが第 3 章で扱った takt 公式の Output Contract (本ハーネスは review.md 先頭行の VERDICT: PASS|FAIL 規約として実装) です。

FAIL だった場合は、指摘を注入して architect を再 spawn します (plan 差し戻し最大 1 回)。anagram-check では FAIL は起きませんでした。

6.5. ② 人間承認

plan-reviewer が PASS を返したら、orchestrator は人間 (= 筆者) に plan.md を提示して承認を取ります。

提示内容は AskUserQuestion の 1 件で、以下を空行区切りで含めます。

実装計画 3-5 行要約
採用案 + 主要 trade-off
影響範囲 (touch ファイルを clickable link で列挙)
doc 更新義務 (column 化表)
末尾に plan.md 全文へのリンク (この run 当時は file:/// URI 形式。08 章の改修 6 で「素の絶対パス直書き」へ規範修正された)

anagram-check の人間承認時、orchestrator が提示した要約はおおよそ次のような形でした。

plan-reviewer VERDICT: PASS。anagram-check 実装計画は spec の 10 ケース全網羅、
既存 palindrome-check 同型 (Array.from + sort + every) で採用。

採用案: sort + element-wise (O(n log n)、code point 単位)
trade-off: frequency map (O(n) だが over-engineering)、split('') (code unit 単位
でサロゲートを裂くため禁止)

影響範囲:
- 新規: src/anagram-check.js / test/anagram-check.test.js (実 repo、developer commit)
- 追記: CONTEXT.md (pointer 層、orchestrator 代行)

doc 更新義務: column 表 3 行 (pointer 1 / 実 repo 2)

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

人間は 3 択 (承認 / 修正指定 / 中断) から「承認」を選択し、orchestrator は story.md 合成へ進みます。

人間承認で AskUserQuestion を使う理由

/spec-design / /autodev で人間承認するときは、平文で「これでよろしいですか?」と聞かず必ず AskUserQuestion を使います (~/.claude/rules/interaction.md)。理由は次の通りです。

平文質問は context に埋もれやすく、人間が見落とす
AskUserQuestion は構造化選択肢 (3 択) で、修正指定の経路がある
hooks/check-plain-question.sh (Stop sensor) で平文質問を block する規律と整合

承認時の平文質問は、check-plain-question.sh の CONFIRMATION パターン (「これで OK?」「これでいい?」型) で block されます。

6.6. ②' story.md 合成

人間承認後、orchestrator は spec + plan の relevant 部 + 受入基準 verbatim + per-repo 知識 SELECTIVE を embed して story.md を書きます。

story.md は developer の単一主入力です。「単一」が重要で、developer は spec.md / plan.md を別途参照しません。story.md 内に必要な情報が全て embed されている状態で渡します。

anagram-check の story.md 主要部分を引用します。

# story: anagram-check

> orchestrator 合成。spec + plan の relevant 部を embed した冪等派生物
> (source of truth は spec + plan)。developer の単一主入力。

## 目的
`src/anagram-check.js` に Unicode code point 単位で 2 引数の文字列が anagram かを判定する
CLI を実装する。

## 受入基準 (spec から verbatim 転記)
(10 ケース表 verbatim)

## 実装計画 (plan.md から)
1. **`src/anagram-check.js` 新規** (CommonJS、依存ゼロ):
   ```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 };

アーキ制約 (SELECTIVE)

per-repo Policy 抜粋 + 設計判断要点

依存と前提

base SHA: 8eb7cc4b... (master HEAD)
task branch: anagram-check-impl
worktree: /tmp/autodev-smoke-anagram-check

ドキュメント更新義務

(plan.md から verbatim、column 化された表)

story.md には **plan.md の column 化表が verbatim で転記**されているのが分かります。これにより、developer が doc 更新義務を正しく解釈でき、auditor が照合元として参照できます。

## 6.7. ③ developer spawn

orchestrator は次に `developer` subagent を spawn します。この run 当時の spawn 時ステップは次の通りでした (worktree の作成主体や path 規約はその後の改修で変わりうる部分です)。

1. `git -C <repo_root> branch <task_branch> <base_sha>` で task branch を base SHA から切る
2. `git -C <repo_root> worktree add /tmp/<repo>-<task> <task_branch>` で worktree を作る
3. developer subagent に story.md パスと worktree パスを spawn prompt で渡す

developer は worktree 内で次のことを行いました。

1. `npm install` で依存解決 (依存ゼロでも worktree 隔離下で踏む)
2. story.md の実装計画に従って `src/anagram-check.js` を新規作成
3. `test/anagram-check.test.js` を新規作成 (spec の 10 ケース verbatim)
4. pass 条件を worktree 内で実行 (`node --test test/anagram-check.test.js` / `npm test` / 個別 CLI 直叩き 6 種)
5. 結果を `done.md` に証跡記録
6. doc 更新 (story の「ドキュメント更新義務」列挙分、実 repo 内のもの)
7. task branch に commit

`anagram-check` の done.md 主要部分を引用します。

```markdown
# done: anagram-check

> developer による実装証跡。pass 条件ごとの cmd + exit code + 出力要約 + PASS/FAIL を
> 表で記録 (verification.md 規範)。

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

## pass 条件証跡

### 代表機械判定 (`node --test`)

| # | cmd | 期待 | 実 exit | 出力要約 | 判定 |
| --- | --- | --- | --- | --- | --- |
| 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` — 全 10 ケース ✔ | **PASS** |
| T2 | `npm test` (全 test) | exit 0 (既存 6 ファイル + 新規 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** |

### 個別 CLI 直叩き (6 種)

| # | cmd | 期待 exit | 実 exit | 出力要約 | 判定 |
| --- | --- | --- | --- | --- | --- |
| C1 | `node src/anagram-check.js abc cba` | 0 | 0 | stdout/stderr 空 | **PASS** |
| C2 | `node src/anagram-check.js listen silent` | 0 | 0 | stdout/stderr 空 | **PASS** |
| C3 | `node src/anagram-check.js hello world` | 1 | 1 | stdout/stderr 空 | **PASS** |
| C4 | `node src/anagram-check.js '' ''` | 0 | 0 | stdout/stderr 空 | **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** |

## 集計
- pass 条件: 8 件 (T1, T2, C1-C6)
- PASS: 8 / FAIL: 0
- 既存テスト破壊: なし (`npm test` で 48/48 PASS、既存 38 ケース全 green)

## commit
- branch: `anagram-check-impl`
- commit SHA: `4651e09e21af6562a91bacab0fbb656c44ffd439`
- 対象: `src/anagram-check.js` / `test/anagram-check.test.js` の 2 ファイル新規追加のみ
- working tree: clean (commit 後 `git status` で確認済)

done.md で重要なのは次の 3 点です。

点 1: pass 条件ごとに cmd + exit code + 出力要約 + 判定

8 件の pass 条件 (T1, T2, C1-C6) それぞれについて、実行コマンドと実 exit code と出力要約を表に記録しています。これは rules/verification.md の「主張は証跡で裏付ける」規範を実装した形です。

点 2: 既存テスト破壊なし

T2 で npm test 全体 (48 ケース) を走らせ、既存 38 ケース + 新規 10 ケースの 48 ケース全 green を確認しています。これは ~/.claude/repos/autodev-smoke/CLAUDE.md の per-repo Policy「既存テストを壊す変更は禁止」と整合します。

点 3: commit SHA + working tree clean 確認

4651e09e... の commit SHA を記録し、commit 後の git status で working tree clean を確認しています。これは rules/verification.md の「状態変更操作は実行後の実状態を独立に再確認」規範の実装です。

6.8. ④ auditor spawn

developer が done.md を書いて commit したら、orchestrator は auditor subagent を spawn します。

auditor は 自身は pass 条件を実行しません (= read-only / fresh --bare 維持)。done.md の証跡を spec.md 原本から再導出した期待と照合します。これが第 3 章で扱った takt の "Separation Improves Quality" 原則 (8 design principles の 3) の核心です。

auditor の照合は 3 本柱です。

一次信号 (done.md 証跡 ⇔ spec 原本再導出)
code ⇔ spec (git -C <repo_root> diff <base-SHA>...<task-branch> で worktree 非侵入)
doc 更新漏れ (story の column 表通り)

anagram-check の review.md 主要部分を引用します。

# review: anagram-check (auditor)

VERDICT: PASS

> auditor 監査。done.md の証跡を spec.md 原本から再導出した期待と照合し、
> `git -C /Users/<name>/Dev/autodev-smoke diff 8eb7cc4...anagram-check-impl` で
> 実 repo の code ⇔ spec、CONTEXT.md Read で doc 更新漏れも照合。3 本柱とも一致。

## 1. 一次信号 (done.md ⇔ spec.md 原本再導出)

### 代表機械判定 (spec.md L12-18 から再導出)

| spec 原本 (再導出した期待) | done.md 証跡 | 判定 |
| --- | --- | --- |
| `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 |
| `node src/anagram-check.js listen silent` → exit 0 | C2: exit 0 | PASS |
| `node src/anagram-check.js hello world` → exit 1 | C3: exit 1 | PASS |
| `node src/anagram-check.js '' ''` → exit 0 | C4: exit 0 | PASS |
| `node src/anagram-check.js` → exit 1 (引数 0) | C5: exit 1 + stderr usage | PASS |
| `node src/anagram-check.js a b c` → exit 1 (引数 3) | C6: exit 1 + stderr usage | PASS |

(追加 T2 `npm test` 48/48 PASS は既存テスト非破壊の補強証跡、spec 原本にはないが
 per-repo CLAUDE.md「既存テストを壊す変更は禁止」と整合)

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

### `src/anagram-check.js` (新規 22 行)
- `Array.from(s1)` / `Array.from(s2)` で code point 単位分解 → spec 準拠、ケース 7 通る
- `if (a.length !== b.length) return false` 早期 short-circuit → plan 判断 3 準拠
- `[...a].sort()` + `every((c, i) => c === sorted2[i])` → plan 判断 1 / 2 準拠
- `toLowerCase` / `normalize` なし → spec (raw 比較) 準拠、ケース 6 通る
- `if (argv.length !== 2)` 単一ガード → plan 判断 4 準拠
- `if (require.main === module)` entry guard → plan step 3 準拠

## 3. doc 更新漏れ (story.md「ドキュメント更新義務」column 表)

| 対象パス | 担当 | 検証経路 | 結果 |
| --- | --- | --- | --- |
| `~/.claude/repos/autodev-smoke/CONTEXT.md` (pointer) |
  orchestrator (代行) |
  Read で「anagram-check / code point 単位 sort / case-sensitive raw 比較」用語追記を確認 |
  PASS — CONTEXT.md L8 で明記 |
| `src/anagram-check.js` (実 repo) |
  developer (worktree commit) |
  `git diff` で新規追加確認 |
  PASS — diff に new file mode (22 行) |
| `test/anagram-check.test.js` (実 repo) |
  developer (worktree commit) |
  `git diff` + done.md `node --test` 証跡で 10 ケース全 green |
  PASS — diff に new file mode (59 行) + T1 で 10/10 green |

VERDICT: PASS

auditor の照合は spec.md 原本から再導出するのがポイントです。done.md の証跡を「spec が期待する形」と直接照らし合わせ、story.md (= 中間派生物) を経由しません。これは循環防御 (= 派生物を信用しない、原本に戻る) の実装で、developer が story を読み違えても auditor が spec 原本との不一致を検出できる構造です。

VERDICT: PASS を最終発話の先頭行に出力し、orchestrator は grep '^VERDICT:' で PASS を確認します。

6.9. ⑤ ff merge

auditor が PASS を返すと、orchestrator は ff merge を実行します。

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

anagram-check では master が 8eb7cc4 → 4651e09 に進みました (state.md の master_sha_after_merge: 4651e09e21af6562a91bacab0fbb656c44ffd439 がこれを記録)。

merge 後、orchestrator は cleanup を行います。

手動 worktree (/tmp/autodev-smoke-anagram-check) を git worktree remove で削除
task branch (anagram-check-impl) を git branch -d で削除 (commit ありの worktree は force 不要、ff merge 済なので)
handoff dir (~/.claude/repos/autodev-smoke/handoff/anagram-check/) は保全

handoff dir は merge 後も保全します。理由は次の通りです。

後で resume したい場合 (= 同じ task に追加で work が必要な場合) のアンカー
改修サイクル (= 過去の plan / done / review を後から参照する) のソース
月次 /harness-prune で 30 日参照ゼロ判定の対象

6.10. anagram-check 完走の state.md 履歴

⓪' から ⑤ まで完走した state.md の「## 履歴」section を再掲します。

## 履歴
- ⓪' phase0 完了 (assert pass、base_sha pin、spec_sha256 凍結、handoff dir 新規)
- ① architect 完了 (VERDICT: PASS、column 化された ## ドキュメント更新義務 表を生成 = 検証 (c) OK)
- ①' plan-reviewer 完了 (VERDICT: PASS、column 表との整合確認)
- ② 人間承認 → story.md 合成 (pointer 層 doc 更新は orchestrator 代行を明記)
- ③ developer 完了 (VERDICT: IMPL_READY、worktree=/tmp/autodev-smoke-anagram-check、
                    pass 条件 8/8 PASS、npm test 48/48 PASS、既存 38 ケース無傷)
- 検証 (b) PASS: developer subagent が自律 commit (4651e09e) に到達、
                  新 hook 改修で block されず通過 = §11 #2 lasting fix の実環境実証
- 検証 (a) 継続: .claude/worktrees/agent-* 新規発生せず
- orchestrator 代行: CONTEXT.md 1 行追記 (pointer 層、anagram-check 用語)
- ④ auditor 完了 (VERDICT: PASS、3 本柱整合、column 表通り CONTEXT.md 代行を doc 更新漏れではないと判定)
- ⑤ ff merge 成功 (master 8eb7cc4 → 4651e09)
- cleanup: 手動 worktree + task branch 削除済

各 step は同一日のうちに一直線で完了しており、日付そのものより順序と各 phase の判定結果が本質です。

この履歴は autodev フローの実走 transcript の凝縮版です。各行が ⓪'-⑤ の各 phase に対応し、加えて以下の検証フラグが立っています。

検証 (a): .claude/worktrees/agent-* 新規発生せず (= 二重 worktree 問題が解消済) — Phase 1-3 改修 #4+#7
検証 (b): developer subagent が自律 commit に到達 (= subagent commit gate hook 修正が効いた) — Phase 1-3 改修 #2
検証 (c): architect が column 化された doc 更新義務表を自然に生成 (= plan.md テンプレ column 化が連動した) — Phase 1-3 改修 #3

これらの検証は、新ハーネスの構造的健全性を確認する実環境テストとして機能しました。具体的な改修経緯は次章 (08. 改修サイクル)で扱います。

6.11. Feedback Loop (差し戻し) 経路の実例

anagram-check task は VERDICT FAIL が出ない完走例でした。実際の state.md 履歴 (palindrome-check を含む)はいずれも ①' / ④ の VERDICT が PASS で一直線に通っており、本連載執筆時点の autodev-smoke 内の handoff には FAIL → 差し戻しの一直線な実例が残っていません。

ただし、Phase 4 検証期間 (~/.claude/plans/phase4-verification-report.md) に観測された差し戻し経路 (takt 原則 4 "Feedback Loops Are First-Class" に対応) は別 task で記録があります。

経路 A: ①' plan-reviewer FAIL → architect 再 spawn

Phase 4 A-4 検証で、fizzbuzz 初版に対して敵対的に仕様カバレッジ漏れを仕込んだ plan を architect に書かせたところ、plan-reviewer が「pass 条件 X が plan の step で覆われていない」を指摘して VERDICT: FAIL を返し、orchestrator が grep でその FAIL を拾って指摘を spawn prompt に注入し architect を再 spawn しました。2 周目で plan-reviewer が PASS を返し、後続 phase に進みました。これが takt 原則 4 "Feedback Loops Are First-Class" の fail-closed 分岐 (grep '^VERDICT:') による発火例です。

経路 B: ② 人間承認時の [修正指定] → architect 再 spawn

isPrime task では、人間が ② で「naive 試し割りでなく Miller-Rabin に差し替え」を選択し、AskUserQuestion の 3 択から [修正指定] を選びました。orchestrator は plan_iteration カウンタを 1 増やし、architect を再 spawn して [2, 3, 5, 7, 11, 13] の deterministic bases + BigInt modPow による Miller-Rabin 実装計画を生成しました。2 周目で plan-reviewer が PASS、後続 phase に進んで ⑤ ff merge (fe3743a) まで完走しました。これは VERDICT FAIL ではなく人間判断による plan 差し戻しで、最大 1 回の差し戻しカウンタを消費しています。

差し戻しは plan 期 (① → ①') では最大 1 回、実装期 (③ → ④) では最大 2 回まで許容します。それを超えると停滞検出 (error_signature 同一 2 回) で人間エスカレーション (takt 原則 5 "Human Judgment Is an Escalation Path") に切り替わります (第 3 章)。

差し戻し履歴の追跡

各 task の差し戻し回数は state.md の plan_iteration / impl_iteration カウンタに記録されます。anagram-check / palindrome-check ともこれらは 0 で、差し戻しなしの完走であることが state.md から確認できます。

6.12. autodev フロー全体 (再掲)

ここまでの walkthrough を 1 つの図に再掲します。

6.13. 本章のまとめ

要点

⓪' で base SHA + spec SHA を state.md に pin → 実装期間中の循環防御が効く
① architect → plan.md (実装計画 + アーキ判断 + 影響範囲 + column 化された doc 更新義務)
①' plan-reviewer → VERDICT 契約で fail-closed 分岐 (grep '^VERDICT:' のみで判定)
② 人間承認 → AskUserQuestion 3 択 + plan.md 全文への clickable link
③ developer → worktree 内で実装 + pass 条件実行 + done.md 証跡記録 + task branch commit
④ auditor → done.md 証跡 ⇔ spec 原本再導出 + git diff + doc 更新漏れの 3 本柱で照合
⑤ ff merge + cleanup → handoff dir は保全 (resume / 改修サイクルのソース)
anagram-check / palindrome-check とも VERDICT FAIL なしで完走 (plan_iteration / impl_iteration = 0)。差し戻しの実例は別 task で観測 (fizzbuzz の敵対 plan / isPrime の人間修正指定、6.11 参照)
autodev 連鎖内では plan-reviewer / auditor の VERDICT 契約が gating critique を担うため、main agent 経路で使う devil-advocate (5.3 で詳解) は autodev 内では起動しない (二重発火回避、rules/adversarial-review.md に明示)

次章は、autodev フローを支える 成長規律 (入口に摩擦・出口に引力をつける運用) を、5 規律と反転承認の実例で扱います。

6.1. ターゲット task: anagram-check​

6.2. ⓪' 起動前 assert + resume 判定​

6.3. ① architect spawn​

6.4. ①' plan-reviewer spawn​

6.5. ② 人間承認​

6.6. ②' story.md 合成​

アーキ制約 (SELECTIVE)​

依存と前提​

ドキュメント更新義務​

6.8. ④ auditor spawn​

6.9. ⑤ ff merge​

6.10. anagram-check 完走の state.md 履歴​

6.11. Feedback Loop (差し戻し) 経路の実例​

6.12. autodev フロー全体 (再掲)​

6.13. 本章のまとめ​