claude-code-conductor 0.2.4__tar.gz → 0.3.1__tar.gz

{claude_code_conductor-0.2.4 → claude_code_conductor-0.3.1}/.claude/agents/planner.md

@@ -79,6 +79,42 @@ plan-report の YAML フロントマターは `parallel-orchestra` (PO) で並
 - [ ] 同じファイルを書く複数タスクで衝突対策が取られているか
 - [ ] レビュータスク（read_only:true）が全 dev タスクに depends_on を持っているか
 - [ ] `tasks[].id` が一意で、`depends_on` の参照先が全て存在するか
+- [ ] `depends_on` を空配列（`[]`）で書いていないか（無依存ならフィールド自体を省略）
+
+### タスクあたりの所要時間制約
+
+PO は内部で **タスクごとのタイムアウトを 900 秒（15 分）でハードコード** している（`_INTERNAL_TIMEOUT_SEC = 900`、フロントマター側からは上書き不可）。1 タスクが 15 分を超えると PO 側で kill されて failure 扱いになる。
+
+11. **1 タスクは 15 分以内に終わる粒度で分解する** — `tdd-develop` の tester→developer→tester ループでも 15 分を上限の目安にする。長くなりそうな機能は (a) ファイル境界でタスク分割、(b) MVP と機能拡張で別タスク化、のいずれかで時間を切る
+- 自己チェックリストに追加: `[ ] 想定実行時間が 15 分を超えるタスクがないか`
+
+### YAML フロントマターの落とし穴
+
+実装時に踏みやすい入力ミス。dry-run で検出できるが、出力前に planner 側で潰しておく:
+
+9. **`depends_on: []` を空配列で書かない** — `c3 po dry-run` が「`depends_on` must be a list of strings」で fail する（非空のときだけ list として扱われ、空配列は仕様違反扱い）。依存が無いタスクは `depends_on` フィールド**自体を省略**する
+10. **`writes` の重複は dry-run の `Write-path conflict` で検出される** — 同じファイルを書くタスクが複数あれば必ず (a) タスクをまとめる、(b) `depends_on` で順序付け、(c) `concurrency_group` で同時実行を 1 に制限、のいずれかで解消する（既存ルール 8 の補足。dry-run が落ちるので出力前に必ず確認する）
+
+### 直列・並列交互パターンの取り扱い
+
+ユーザーが **stage 単位で順序を強制したい / 中間状態を確認したい** と要求した場合は、ルール 1（「真の依存だけに絞る」）から逸脱して順序付けの `depends_on` を許容してよい。典型構造:
+
+```
+Stage 1: dev_a, dev_b, dev_c (並列)
+  └─ Stage 2: review_or_sync (依存: dev_a/b/c) ← 中間レビュー / 集約
+      └─ Stage 3: dev_d, dev_e (並列、依存: review_or_sync)
+          └─ Stage 4: review_or_sync_2 (依存: dev_d/e)
+              └─ ...
+```
+
+採用条件:
+
+- ユーザーが明示的に要求している（自己判断で勝手にこの形にしない）
+- 各 stage 内の並列度は **2 以上**を維持する（直列に潰してはいけない）
+- ルール 2（直列化セルフチェック: チェーン長 ≦ タスク数 / 2）は依然として守る
+- 「stage 区切り」自体は plan-report 本文で明文化し、`depends_on` だけに頼らない
+
+詳細な構造例は `.claude/docs/parallel-orchestra-manifest.md` の「並列・直列交互パターン」を参照。
 
 ## Tools & Constraints
 制限:

claude_code_conductor-0.3.1/.claude/commands/develop.md

@@ -0,0 +1,11 @@
+# /develop コマンド
+
+plan-report に基づいて実装フェーズを実行する。
+
+## 必ず守ること
+
+1. **最初に必ず** `.claude/skills/dev-workflow.md` を Read する。記憶・推測で進めない
+2. **フェーズ D（実装）** から実行する
+3. dev-workflow.md の AskUserQuestion・Edit・セッションファイル更新の手順を省略しない
+4. D-0 で plan-report に YAML フロントマター（`po_plan_version`）が検出された場合は、続けて **必ず** `.claude/skills/wave-execution.md` を Read してその手順に従う（C3 メイン + PO スポット並列モード）
+5. フロントマターが無い場合は legacy の D-1〜D-5 ceremony（tester→developer→tester の TDD 逐次実行）にフォールバックする

{claude_code_conductor-0.2.4 → claude_code_conductor-0.3.1}/.claude/docs/parallel-orchestra-manifest.md

@@ -115,6 +115,46 @@ on_failure:
 
 ---
 
+## 並列・直列交互パターン
+
+中間レビューや段階的な動作確認を挟みたい場合の plan-report 構造。stage 内では並列、stage 間は順序を強制する形を取る。C3 の wave-execution でも各 stage 完了後にユーザー承認が入るので、ヒューマン・イン・ザ・ループ前提の中規模実装で有効。
+
+### 用途
+
+- 段階的にユーザー確認・中間レビューを挟みたい
+- 実装ステージごとに動作確認が必要（例: 認証 → 認可 → 監査ログ、と段階的に積み上げる）
+- 後続の dev タスクが前段のレビュー指摘を受けて方針調整する可能性がある
+
+### 構造
+
+```
+Stage 1: dev_a, dev_b, dev_c (並列)
+  └─ Stage 2: review_or_sync (依存: dev_a / dev_b / dev_c)  ← 中間レビュー / 集約
+      └─ Stage 3: dev_d, dev_e (並列、依存: review_or_sync)
+          └─ Stage 4: review_or_sync_2 (依存: dev_d / dev_e)
+              └─ ...
+```
+
+特徴:
+
+- 各 stage 内は **2 件以上の独立タスク**で並列度を維持する
+- stage を区切る `review_or_sync` タスクは `code-reviewer`（read_only: true）か、軽い同期目的のサマライズタスク
+- 中間レビュータスクが次 stage の dev タスクに `depends_on` で繋がる → **stage 間は完全に直列**
+
+### 動作実績
+
+17 tasks / 7 stages 構成（3〜4 並列の dev stage と 1 件の review stage が交互）で動作確認済み。各 stage が wave 1 つに対応し、wave-execution.md の per-wave 承認フローに綺麗に乗る。
+
+### 採用条件（planner 側のルール）
+
+- ユーザーが明示的に要求している（自動でこの形にしない）
+- 各 stage 内の並列度は **2 以上**を維持する（直列に潰さない）
+- 全体のチェーン長 ≦ タスク数 / 2 を依然として守る
+
+詳細は `.claude/agents/planner.md` の「直列・並列交互パターンの取り扱い」を参照。
+
+---
+
 ## アンチパターン（避けるべき書き方）
 
 ### A. 全部直列にしてしまう

{claude_code_conductor-0.2.4 → claude_code_conductor-0.3.1}/.claude/skills/dev-workflow.md

@@ -217,39 +217,29 @@ AskUserQuestion ツール:
 
 ---
 
-## フェーズ D: TDD
+## フェーズ D: 実装
 
 **フェーズ C から続いている場合:** plan-report はコンテキスト内にあるため読み直し不要。
 **直接開始の場合:** Glob で `.claude/reports/plan-report-*.md` の最新を Read する。存在しない場合はフェーズ C から始めるよう案内して終了する。
 
+### D-0: 実行モード自動判別
+
+plan-report の冒頭を Read し、YAML フロントマター（`---` で始まり `po_plan_version: "0.1"` を含む）の有無を確認する。
+
+**フロントマターありの場合:**
+1. **最初に必ず** `.claude/skills/wave-execution.md` を Read する（記憶・推測で進めない）
+2. `wave-execution.md` の手順に完全に従って wave 単位で実装を進める
+3. 全 wave 完了後はフェーズ E（レビュー）へ進む（wave に reviewer タスクが含まれていれば E をスキップ可能と案内する）
+
+**フロントマターなしの場合（legacy フォールバック）:**
+
 今日のセッションファイルに以下を追記する（未登録の場合のみ）:
 - `- [ ] tester: Red フェーズ`
 - `- [ ] developer: Green フェーズ`
 - `- [ ] developer: Refactor フェーズ`
 - `- [ ] tester: 最終確認`
 
-### D-0: 実行モード選択
-
-AskUserQuestion ツール:
-```json
-{
-  "questions": [{
-    "question": "TDD サイクルの実行モードを選んでください",
-    "options": [
-      { "label": "TDD 逐次実行", "description": "従来の D-1〜D-5（tester→developer→tester）で1タスクずつ進める" },
-      { "label": "PO 並列実行", "description": "parallel-orchestra で plan-report の独立タスクを git worktree 並列実行する（PO のインストールが必要）" }
-    ]
-  }]
-}
-```
-
-**「TDD 逐次実行」の場合:** D-1 へ進む。
-
-**「PO 並列実行」の場合:**
-1. **最初に必ず** `.claude/skills/parallel-execution.md` を Read する（記憶・推測で進めない）
-2. セッションファイルに `- [ ] PO 並列実行` を追記する
-3. `parallel-execution.md` の手順を完全に守る
-4. 完了後はフェーズ E（レビュー）へ進む
+D-1 へ進む。
 
 ### D-1: tester（Red フェーズ）
 

claude_code_conductor-0.3.1/.claude/skills/wave-execution.md

@@ -0,0 +1,276 @@
+# Wave Execution
+
+`/develop` のフェーズ D で plan-report に YAML フロントマター（`po_plan_version: "0.1"`）が含まれるときに Read される手順。
+
+C3 の親 Claude が plan-report の DAG を **wave 単位**で歩く。
+- 単独 wave（タスク 1 件） → C3 が直接実行（Agent ツール起動 or ペルソナ採用）
+- 複数 wave（タスク 2 件以上） → parallel-orchestra（PO）にスポット並列委譲
+
+各 wave 完了後にユーザーの承認を取る。
+
+---
+
+## 前提条件
+
+- `claude-code-conductor` がインストール済みで `c3` コマンドが PATH 上にあること
+- plan-report が `.claude/reports/plan-report-*.md` の形式で配置され、YAML フロントマターを持つこと（フロントマターが無ければ `dev-workflow.md` の D-1〜D-5 ceremony へフォールバック）
+
+---
+
+## Step 0-pre: ワーキングツリーの事前確認
+
+PO は worktree からの auto-merge で main に成果物を取り込む仕様で、**main 側に未コミット変更や untracked ファイルがあると、worktree が同名ファイルを再生成して必ず衝突する**。実行前に `git status` でクリーンであることを確認する。
+
+1. Bash で `git status --short` を実行する
+2. stdout が空（クリーン）→ Step 0 へ
+3. クリーンでない場合:
+   - 検出された変更ファイルをユーザーに提示する
+   - AskUserQuestion で次を確認する:
+
+     ```json
+     {
+       "questions": [{
+         "question": "PO 実行前に main がクリーンである必要があります。どうしますか？",
+         "options": [
+           { "label": "コミットしてから続行", "description": "親 Claude が変更内容を確認してコミットしてから wave 実行に進む" },
+           { "label": "stash してから続行", "description": "git stash で退避してから wave 実行に進む。完了後に stash pop するかは別途判断" },
+           { "label": "キャンセル", "description": "wave 実行を中止し、ユーザーが自分で整理してから /develop を再実行する" }
+         ]
+       }]
+     }
+     ```
+
+   - 「コミットしてから続行」→ 親 Claude が `git status` / `git diff` を見て妥当な単位でコミットしてから Step 0 へ
+   - 「stash してから続行」→ Bash で `git stash push -u -m "wave-execution pre-clean"` を実行してから Step 0 へ
+   - 「キャンセル」→ スキル終了
+
+**特に注意すべきファイル:**
+
+- `.claude/settings.local.json` — Claude Code が permission 自動追加で勝手に更新する。気付かないうちに dirty になっているケースが多い
+- `package.json` / `vitest.config.js` 等の事前準備（W0）ファイル — 未コミットで PO に入ると worktree でも同ファイルが書き換わって必ず衝突する
+- `.claude/reports/` 配下の中間生成物
+
+---
+
+## Step 0: 妥当性チェック
+
+1. Glob で `.claude/reports/plan-report-*.md` の最新ファイルパスを取得する
+2. Read で内容（フロントマター含む）を確認する
+3. Bash で以下を実行する:
+
+   ```
+   c3 po dry-run <plan-report-path>
+   ```
+
+   - 終了コード `0` = マニフェスト妥当 → Step 1 へ
+   - 終了コード `2` = マニフェストエラー（フィールド欠損・agent 不在等）→ stderr のメッセージを整形してユーザーに提示し、`/start` のフェーズ C（計画）を再実行するか手動で plan-report を編集するよう案内してこのスキルを終了する
+   - 終了コード `1` = PO 未インストール → 以下の案内文を**そのまま提示**してこのスキルを終了する:
+
+     > 並列実行を使うには `pip install parallel-orchestra` を実行してください。
+     > 詳細: https://pypi.org/project/parallel-orchestra/
+
+     親 Claude は逐次実行（`dev-workflow.md` の D-1〜D-5）に切り替えるか、PO をインストールして `/develop` を再実行するかをユーザーに選んでもらう。
+
+---
+
+## Step 1: wave 分解
+
+Bash で以下を実行する:
+
+```
+c3 po waves <plan-report-path>
+```
+
+stdout の JSON は以下の形式になる:
+
+```json
+{
+  "waves": [
+    {
+      "index": 0,
+      "tasks": [
+        { "id": "tdd-login", "agent": "tdd-develop", "read_only": false, "writes": ["src/auth/login.py"], "prompt": "..." },
+        { "id": "tdd-logout", "agent": "tdd-develop", "read_only": false, "writes": ["src/auth/logout.py"], "prompt": "..." }
+      ]
+    },
+    {
+      "index": 1,
+      "tasks": [
+        { "id": "review-auth", "agent": "code-reviewer", "read_only": true, "writes": [], "prompt": "..." }
+      ]
+    }
+  ]
+}
+```
+
+- 終了コード `0` = 分解成功 → 親 Claude が JSON をパースして `waves` 配列を取得し Step 2 へ
+- 終了コード `2` = フロントマター不正・循環依存等 → stderr メッセージを提示して終了
+
+セッションファイル（`.claude/memory/sessions/YYYYMMDD.tmp`）に以下を追記する（未登録の場合のみ）:
+- 各 wave につき `- [ ] Wave {N} ({task_count} tasks)` を 1 行ずつ
+
+---
+
+## Step 2: wave ごとに実行する
+
+`waves` 配列を index 順にループする。各 wave で以下を順に行う。
+
+### 2-A: wave 内容を提示する
+
+親 Claude が wave のタスク一覧を Markdown 表で提示する:
+
+| id | agent | read_only | writes |
+|---|---|---|---|
+| tdd-login | tdd-develop | false | src/auth/login.py |
+| tdd-logout | tdd-develop | false | src/auth/logout.py |
+
+### 2-B: 実行可否をユーザーに確認する
+
+AskUserQuestion ツール:
+
+```json
+{
+  "questions": [{
+    "question": "Wave {N} を実行してよいですか？",
+    "options": [
+      { "label": "承認・進む", "description": "この wave を実行する" },
+      { "label": "中断", "description": "ここで wave 実行を停止する。完了済みの wave はそのまま残る" }
+    ]
+  }]
+}
+```
+
+「中断」の場合、セッションファイルの `## 試みたが失敗したアプローチ` に中断理由を追記してスキル終了。
+
+### 2-C: ランナーを選んで実行する
+
+`len(wave.tasks)` で分岐する。
+
+#### case A: 単独 wave（タスク 1 件）
+
+タスクの `agent` フィールドで更に分岐する。
+
+##### A-1: `agent == "tdd-develop"` のとき
+
+**ペルソナ採用パターン**で実行する。Agent ツールで起動するとサブエージェント depth 1 制限により内部の tester/developer サブエージェントが spawn できないため、親 Claude が直接 tdd-develop ペルソナで動く。
+
+1. `.claude/agents/tdd-develop.md` を Read してペルソナを採用する
+2. `.claude/skills/worktree-tdd-workflow.md` を Read して TDD ループ手順（tester→developer→tester）を取得する
+3. タスクの `prompt` を実装内容として、worktree-tdd-workflow.md の Step 1〜4 を **親 Claude が直接** 実行する。tester / developer は Agent ツールでスポーン可能（depth 1 で完結する）
+4. ループ完了後、結果を 2-D の集約に渡す
+
+##### A-2: `agent` がそれ以外（`code-reviewer` / `security-reviewer` / `developer` / `tester` 等）
+
+**Agent ツール起動パターン**で実行する。これらの agent は内部で更に subagent を spawn しないため depth 1 制限に抵触しない。
+
+1. Agent ツールで `subagent_type` は指定せず（カスタム agent は subagent_type 不可）、プロンプトに以下を含める:
+   - 「`.claude/agents/{agent_name}.md` を Read してペルソナを採用すること」
+   - タスクの `prompt` 本文
+   - **「git add / git commit / git push を実行しないこと。コミットは親 Claude がユーザー承認後に行う」を明示**
+2. Agent の返答を 2-D の集約に渡す
+
+**git 禁止ルールの根拠:** 動作確認で developer が独断コミットして Red テストや test-report が untracked のまま実装ファイルだけが main に入る事故が起きた。コミット粒度・承認タイミング・成果物の取りこぼしは親 Claude が一元管理する責務。
+
+##### 将来 agent を追加する場合
+
+「内部で更に subagent を呼ぶ agent」を新たに作る場合は、A-1 のペルソナ採用パターン側に追加する。判断基準: その agent の定義ファイルが「内部で Agent ツールを使う」前提になっているか。tdd-develop が現状の唯一の例。
+
+#### case B: 複数 wave（タスク 2 件以上）
+
+**PO スポット委譲**で実行する。
+
+Bash で以下を実行する:
+
+```
+c3 po run-wave <plan-report-path> --wave-index {N} --report .claude/reports/po-run-report-wave-{N}-{ts}.json
+```
+
+- `{N}` は wave の index
+- `{ts}` は `YYYYMMDD-HHMMSS` 形式。Bash で `python -c "from datetime import datetime; print(datetime.now().strftime('%Y%m%d-%H%M%S'))"` を実行して取得
+- `c3 po run-wave` は `.claude/tmp/po-manifest-wave-{N}-{ts}.md` に ephemeral マニフェストを生成し、PO に subprocess 委譲する。各タスクは PO が `claude -p --agent <name>` を独立 Claude セッション（depth 0）として起動するため、tdd-develop も内部で tester/developer を spawn できる
+
+終了コードと意味:
+
+| exit code | 意味 | 次のアクション |
+|---|---|---|
+| `0` | wave 内全タスク成功 | 2-D へ |
+| `1` | 1件以上のタスクが失敗 | 2-D へ（失敗一覧を含めて提示）。**注:** PO は 1 タスクあたり 15 分（`_INTERNAL_TIMEOUT_SEC = 900`、ハードコード上書き不可）でタイムアウトする。15 分超で failure 扱いになっていれば planner の粒度を見直す |
+| `2` | マニフェストエラー（Step 0 をすり抜けた）| エラー内容を提示しスキル終了 |
+| `3` | auto-merge 衝突（worktree → main の取り込みに失敗）| 下記「auto-merge が衝突した場合」のリカバリ手順へ |
+
+実行完了後、生成された `po-run-report-wave-{N}-{ts}.json` を Read してタスクごとのステータスを取得する。
+
+##### auto-merge が衝突した場合（exit code 3）
+
+PO は worktree でタスクを実行したあと main に auto-merge する。Step 0-pre をすり抜けて main にダーティな状態が残っていたり、複数 worktree が同じ周辺ファイル（CLAUDE.md / settings.local.json 等）を触っていると衝突する。selective checkout でコア成果物だけ救う:
+
+1. 残っている PO ブランチを列挙する: `git branch --list "parallel-orchestra/*"`
+2. 各ブランチを個別に確認する: `git log --stat parallel-orchestra/<task>-<hash>`
+3. **コア成果物のみ**を抽出する: `git checkout parallel-orchestra/<task>-<hash> -- <files>`
+   - 取り込むのはタスクの `writes` フィールドに列挙されたファイルのみ
+   - **取り込まない**: worktree が touch したが本タスクの責務でない周辺ファイル
+     - `CLAUDE.md` / `package.json` / `vitest.config.js` 等の事前準備系ファイル
+     - `.claude/settings.local.json`（permission 自動追加で worktree 側でも更新されている）
+     - `.claude/reports/` 配下の中間生成物
+4. PO ブランチを削除する: `git branch -D parallel-orchestra/<task>-<hash>` を全ブランチに対して実行
+5. 抽出した成果物 + 既存の main 変更分を親 Claude が確認のうえコミットする
+6. `git status --short` で main がクリーンになったことを確認してから次の wave に進む
+
+### 2-D: 結果を集約してユーザーに提示する
+
+ランナー種別ごとに以下の形式で結果を提示する。
+
+**case A（単独 wave）:**
+- A-1: 親 Claude の TDD ループ結果（tester/developer の Agent 返答の要約、最終 tester の合否）
+- A-2: Agent の返答テキスト（必要なら要約）
+
+**case B（複数 wave / PO 委譲）:**
+- `po-run-report-wave-{N}-*.json` を Markdown 表に整形:
+
+  | id | agent | status | worktree | duration | last_error_summary |
+  |---|---|---|---|---|---|
+  | tdd-login | tdd-develop | success | wt-tdd-login | 124s | - |
+  | tdd-logout | tdd-develop | failure | wt-tdd-logout | 89s | TestLogout::test_csrf failed |
+
+### 2-E: 失敗があったら方針を確認する
+
+case A で TDD ループが不合格のまま終わった、または case B で 1 件以上失敗した場合、AskUserQuestion で次を確認する:
+
+```json
+{
+  "questions": [{
+    "question": "Wave {N} に失敗があります。どうしますか？",
+    "options": [
+      { "label": "リトライ", "description": "同じ wave をもう一度実行する" },
+      { "label": "スキップして次の wave へ", "description": "失敗を残したまま次の wave に進む" },
+      { "label": "中断", "description": "ここで wave 実行を停止する。完了済みの wave はそのまま残る" }
+    ]
+  }]
+}
+```
+
+- 「リトライ」 → 2-A から同じ wave を再実行
+- 「スキップして次の wave へ」 → 失敗内容をセッションファイルの `## 試みたが失敗したアプローチ` に追記して次の wave へ
+- 「中断」 → セッションファイルの該当 wave 行は `- [ ]` のままにしてスキル終了
+
+### 2-F: wave 完了をセッションに記録する
+
+全タスク成功した wave のみ、セッションファイルの `- [ ] Wave {N} (M tasks)` を `- [x] Wave {N} (M tasks)` に Edit する。
+
+**次の wave に進む前に main をコミットしてクリーンに保つ。** wave 成果物を未コミットのまま次の wave で PO に入ると、worktree が同名ファイルを再生成して必ず auto-merge 衝突が起きる（Step 0-pre と同じ理由）。親 Claude が wave の成果物を確認のうえ「Wave {N}: {要約}」のメッセージでコミットしてから 2-A の次のループに戻る。
+
+---
+
+## Step 3: フェーズ E への遷移
+
+全 wave 完了後、フェーズ E（レビュー）への遷移を案内する。
+
+- plan-report に reviewer タスク（agent が `code-reviewer` / `security-reviewer`）が含まれている場合は wave で既に実行済みなので、二重レビューを避けるためにユーザーへ「wave 内で reviewer タスクが完了済みなので E をスキップしてもよい」と提示する
+- reviewer タスクが含まれていない場合は通常通りフェーズ E へ進む
+
+---
+
+## 知識蓄積
+
+- wave 実行で**特定パターンが詰まりがち**（例: tdd-develop の persona 起動で context が膨らみやすい）と気付いたら、セッションファイルの `## 試みたが失敗したアプローチ` に追記し `patterns` に登録する
+- wave 分解の精度（planner の出力品質）に関する観察も同様に記録する。これは将来 planner 側のルール改善に繋がる

{claude_code_conductor-0.2.4 → claude_code_conductor-0.3.1}/CHANGELOG.md

@@ -1,5 +1,82 @@
 # Changelog
 
+## [0.3.1] - 2026-05-01
+
+### Docs
+- Operational rules captured from a 17-tasks / 7-stages C3+PO verification
+  run in `c3_pip_test`:
+  - `.claude/skills/wave-execution.md`: new **Step 0-pre** that requires a
+    clean working tree before invoking PO (PO's auto-merge re-creates
+    same-named files in worktrees and conflicts on dirty main — most
+    commonly via `.claude/settings.local.json`, which Claude Code auto-edits
+    when granting permissions). Adds an explicit **"do not git
+    add/commit/push"** rule to case A-2 Agent-tool prompts (a developer
+    sub-agent was committing implementation files while leaving Red tests
+    and test-reports untracked). Adds an **auto-merge conflict (exit code
+    3) recovery** sub-section under case B with a selective-checkout
+    procedure that rescues only declared `writes` and discards worktree-
+    side edits to surrounding files. Adds a per-wave commit reminder under
+    Step 2-F. Notes PO's hardcoded 15-minute per-task timeout
+    (`_INTERNAL_TIMEOUT_SEC = 900`, no manifest-level override) so the
+    parent Claude can route exit-code-1 timeouts back to planner sizing
+    rather than agent debugging.
+  - `.claude/agents/planner.md`: documents the `depends_on: []` pitfall
+    (`c3 po dry-run` rejects empty arrays — omit the field instead) and
+    the `writes` collision detection. Adds a per-task time budget rule
+    (≤15 min, matching PO's internal timeout) with a self-check item.
+    Adds an **"alternating parallel/serial pattern"** section that
+    authorises ordering `depends_on` between stages when the user
+    explicitly wants intermediate review/sync points, while preserving
+    in-stage parallelism ≥ 2.
+  - `.claude/docs/parallel-orchestra-manifest.md`: adds an "alternating
+    parallel/serial pattern" section describing the structure with a
+    pointer to the planner rule.
+
+No code changes — `c3 update` after `pip install -U claude-code-conductor`
+brings these into existing projects.
+
+## [0.3.0] - 2026-04-30
+
+### Changed (breaking)
+- `/develop` now auto-detects YAML frontmatter on the latest plan-report and
+  switches between two modes:
+  - **frontmatter present** → new "C3 main + PO spot" workflow. C3 walks the
+    DAG wave-by-wave, asks for user approval before each wave, and dispatches
+    each wave to the right runner: solo waves run on the C3 host (Agent-tool
+    spawn for `code-reviewer` / `developer` / `tester`, parent-Claude persona
+    adoption for `tdd-develop` to avoid the depth-1 nested-spawn limit), and
+    multi-task waves are delegated to parallel-orchestra via an ephemeral
+    wave-only manifest under `.claude/tmp/`.
+  - **no frontmatter** → legacy D-1〜D-5 sequential TDD ceremony, unchanged.
+- The previous "PO 全委譲" model (D-0 two-choice prompt) and
+  `.claude/skills/parallel-execution.md` are removed. The new flow is
+  documented in `.claude/skills/wave-execution.md`.
+
+### Added
+- `c3 po waves <plan-report>` — prints the topological wave decomposition of
+  a manifest as JSON. Used by `wave-execution.md` to drive the per-wave loop.
+- `c3 po run-wave <plan-report> --wave-index N` — generates a wave-only
+  ephemeral manifest under `.claude/tmp/po-manifest-wave-{N}-{ts}.md` and
+  hands it to parallel-orchestra.
+- `c3.po.manifest.compute_waves(frontmatter)` — Kahn's-algorithm topological
+  wave decomposition. Detects cycles, unknown dependency ids, and duplicate
+  task ids.
+- `c3.po.manifest.build_wave_manifest_text(frontmatter, wave_index)` —
+  emits a parseable plan-report Markdown for one wave, dropping `depends_on`
+  and webhook fields and decorating the manifest name with ` - wave N`.
+- `tests/test_po_waves.py` (16 tests) and `tests/test_cli_po.py` (5 tests)
+  covering wave decomposition, ephemeral-manifest generation, CLI exit
+  codes, and frontmatter round-trip.
+
+### Notes
+- The persona-adoption pattern for `tdd-develop` in solo waves is the direct
+  consequence of Claude Code's depth-1 nested-spawn limit (a sub-agent
+  spawned via the Agent tool cannot itself spawn another sub-agent). For
+  agents that internally spawn sub-agents (today: `tdd-develop`), the parent
+  Claude reads the agent definition and adopts its persona instead. Other
+  agents (`code-reviewer`, `security-reviewer`, `developer`, `tester`) keep
+  using the standard Agent-tool spawn path.
+
 ## [0.2.4] - 2026-05-01
 
 ### Changed

{claude_code_conductor-0.2.4 → claude_code_conductor-0.3.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-conductor
-Version: 0.2.4
+Version: 0.3.1
 Summary: Multi-agent orchestration framework for Claude Code (C3)
 Project-URL: Homepage, https://github.com/satoh-y-0323/claude-code-conductor
 Project-URL: Repository, https://github.com/satoh-y-0323/claude-code-conductor

{claude_code_conductor-0.2.4 → claude_code_conductor-0.3.1}/src/c3/__init__.py

@@ -1,3 +1,3 @@
 """Claude Code Conductor (C3) - multi-agent orchestration framework for Claude Code."""
 
-__version__ = "0.2.4"
+__version__ = "0.3.1"