claude-code-conductor 2.55.1__tar.gz → 2.57.0__tar.gz

{claude_code_conductor-2.55.1 → claude_code_conductor-2.57.0}/.claude/docs/parallel-agents-setup.md

@@ -101,12 +101,34 @@ parallel-agents は「直近の修正を反映した worktree で並列実装さ
 
 検証実績 (2026-05-23 〜 2026-05-24):
 
-- foreground / background / 並列 / 失敗 (exit 1) の全パターンで 10/10 cleanup 確認
-- ごく稀に **外部要因による一時的ファイルロック** で cleanup が失敗するケースを
-  1 件観測 (約 1/11 以下)。原因は未特定（アンチウィルス・バックアップソフト・
-  その他常駐プロセスのいずれかの可能性）
-- SKILL.md Step 2-F-3 の残留チェック + `git worktree prune` フォールバックで
-  実害なく吸収される設計
+- 2026-05-23 の集中検証で foreground / background / 並列 / 失敗 (exit 1) の 4 パターン・
+  **全 5 シナリオで cleanup 確認**（一次資料:
+  `.claude/reports/archive/worktree-cleanup-verification-20260523-234110.md`。ただし
+  この検証ログは gitignored かつ配布対象外で、C3 配布元のローカルにのみ保管されている。
+  fresh clone / `c3 init` 展開先には存在しないため、配布元での検証可能性を残す目的で
+  パスのみ記載している）
+- 上記に v2.15.2 リリース作業中 (〜2026-05-24) の実起動を加えた累計では **10/11 で
+  cleanup**。残る 1 件は **外部要因による一時的ファイルロック** で cleanup が失敗した
+  ケース (約 1/11)。原因は未特定（アンチウィルス・バックアップソフト・その他常駐
+  プロセスのいずれかの可能性）
+
+なお 2026-05-23 の 5 シナリオ検証はファイル変更を伴わないタスク（`pwd` / `git rev-parse` /
+`date`）のみで実施されており、ソースコード変更を伴うタスクでの auto-cleanup 挙動は
+下記 2026-07-26 実測の追記で初めて確認された（5 シナリオは実行モードの網羅であって
+ファイル変更の有無の網羅ではないため、両者は矛盾しない）。
+
+**2026-07-26 実測で判明した条件**:
+
+- **git 的に未変更の worktree は確実に auto-cleanup される** — confirm- 系の
+  gitignored-only レポート出力タスクなど、`writes` が全て `.claude/reports/` 等の
+  gitignored ファイルのみの場合、Agent 完了時に worktree が自動削除される
+- **変更が残る worktree は残留しうる** — ソースコード修正など変更が git 管理下に
+  残る worktree は auto-cleanup されず残留することがある。残留時は SKILL.md Step
+  2-F-3 の残留チェック + 手動 cleanup（`git worktree remove` / `git branch -D`）で
+  後始末する
+
+SKILL.md Step 2-F-3 の残留チェック + `git worktree prune` フォールバックで
+実害なく吸収される設計。
 
 ---
 

{claude_code_conductor-2.55.1 → claude_code_conductor-2.57.0}/.claude/skills/autonomous-mode/SKILL.md

@@ -66,7 +66,7 @@ D-0（実行モード自動判別）は AskUserQuestion を持たないステッ
 | **B-3** | レポート承認 AskUserQuestion | **要点をテキスト提示して自動で次フェーズへ**（レポートは通常どおり Write・記録も通常どおり） |
 | **C-1** | マイルストーン要否 | 「設けない」相当で自動進行 |
 | **C-2** | レポート承認 AskUserQuestion | **要点をテキスト提示して自動で次フェーズへ**（レポートは通常どおり Write・記録も通常どおり） |
-| **C-3** | 監査 opt-in＋findings 分岐 | design-critic を**必ず起動**し、findings 分岐は原則**「全て対応する」に固定**（「全て許容して進む」を選べるのは **High/Medium が 0 で Low のみが残ったサイクル**に限る＝空収束防止）。**High/Medium 0 まで自動ループ（初回上限 5 サイクル、差し戻し後は上限 2 サイクルの別枠）**。Low の残存は収束を妨げない（残存件数を報告する）。severity 記録は通常どおり |
+| **C-3** | 監査 opt-in＋findings 分岐 | design-critic を**必ず起動**し、findings 分岐は原則**「全て対応する」に固定**（「全て許容して進む」を選べるのは **High/Medium が 0 で Low のみが残ったサイクル**に限る＝空収束防止）。**High/Medium 0 まで自動ループ（初回上限 5 サイクル、差し戻し後は上限 2 サイクルの別枠）**。Low の残存は収束を妨げない（残存件数を報告する）。severity 記録は通常どおり（差し戻し後も design-critic を必ず起動する。上限 2 サイクルの別枠・本表の C-3 行のとおり。転記行 2 種＝C-3省略宣言 / C-3監査要求の生成・評価も行わない。理由: 自律は人間の承認の目が無いため機械監査を厚く保つ）。ステップ 0 の転記行の確認は HITL のみ |
 | **D-2.5** | テスト承認 | **テスト全緑まで自動**（stuck 時は systematic-debugger 経由も自動）。全緑が客観条件 |
 | **D-3** | テスト承認 | **テスト全緑まで自動**（stuck 時は systematic-debugger 経由も自動）。全緑が客観条件 |
 | **D-5** | テスト承認 | **テスト全緑まで自動**（stuck 時は systematic-debugger 経由も自動）。全緑が客観条件 |
@@ -86,6 +86,8 @@ D-0（実行モード自動判別）は AskUserQuestion を持たないステッ
 **High/Medium を許容で流すことは引き続き構造的に禁じる**（空収束防止）。
 許容という価値判断がこの例外に当てはまらない場合は、従来どおり**人間の関所へエスカレーション**する。
 
+**dev-workflow C-3 のステップ 0（転記行の確認）は HITL 専用**: dev-workflow SKILL.md の C-3 ステップ 0 で転記行 2 種（C-3省略宣言 / C-3監査要求）を評価するステップと、これらの転記行を生成する C-2 の C-3省略宣言ブロックは HITL 専用。自律モードでは C-3 全体が本表に従い、差し戻し後も design-critic を必ず起動する（上限 2 サイクルの別枠・本表の C-3 行のとおり）。転記行 2 種の生成・評価も行わない。理由: 自律は人間の承認の目が無いため機械監査を厚く保つ。
+
 **収束サイクルに残った Low の扱い**（C-3 のみ）:
 
 | サイクルの状態 | 分岐 |

{claude_code_conductor-2.55.1 → claude_code_conductor-2.57.0}/.claude/skills/dev-workflow/SKILL.md

@@ -237,6 +237,68 @@ plan-report の全タスクを走査し、以下の形式でテキスト出力
 `read_only: false` のタスクに `tester` / `developer` 以外の agent が使われている場合は、
 その理由をテキストで説明した上で承認を求めること。
 
+**plan-report の新規タイムスタンプ必須（全経路）**
+
+C-2 へ戻る全経路（E→C 差し戻し・C-3 層別ルーティング・C-2 否認のいずれも）で plan-report を再生成する場合は、必ず新規タイムスタンプで Write する（ピンポイント修正であっても既存 plan-report の Edit・同一タイムスタンプでの再承認は禁止）。転記行と plan の 1:1 紐付けと「最新＝現行」の成立を守るための書式規約であり、初回 C-3 の挙動は変えない。運転モードを問わず適用する。
+
+**C-3省略宣言（レビュー差し戻し時の再承認のみ・HITL 専用）**
+
+本ブロック（転記行 2 種＝C-3省略宣言 / C-3監査要求の生成）と C-3 ステップ 0（転記行 2 種の評価）は HITL 専用。自律モードでは C-3 全体が autonomous-mode のゲート対応表に従い、宣言・監査要求行の転記も行わない。
+
+**宣言を提示してよい場面**: 直前の `現在地:` が `フェーズC 計画中（レビュー差し戻し）` である C-2 再承認時のみ。初回の C-2 では宣言を書かない（書かれても無効）。判定時点はこの C-2（現在地がまだ差し戻し表記のうち）に固定する（C-2 承認後は現在地が `フェーズD 実装中` へ書き戻され、C-3 到達時点では差し戻し経由かを現在地から判定できないため）。
+
+**省略条件（4 条件の AND・いずれか判定不能・曖昧なら不成立＝宣言を書かない）**:
+
+1. **直接反映のみ**: 修正計画の全タスクが E findings の直接反映（テスト追加・文言修正・レビュアー提示の具体案の移植）である。不成立側の境界例: レビュアー提示案と異なる方式・より強い方式を採る修正（複数 findings の一括解消のための方式変更を含む）／既存テスト・テストハーネスの構造変更を伴う修正（アサーション追加・文言追随は直接反映側）。成立側の補足: [CR-NEW] / [SR-NEW] などチェックリスト外 ID であること自体は不成立事由にしない（対応内容で判定）。レビュアーが複数案を提示しそのうち 1 つを選ぶ修正は、いずれもレビュアー提示案なら成立側。
+
+2. **帰属アンカー（肯定表明方式）**: 当該差し戻しを発生させたゲート 1 つ（E-1 または E-2）の帰属判定 failure 記録（通常 1 件）について、次の両方が成り立つときのみ成立とする（両方のゲートの failure が記録されている場合のみ両方を見る（HITL の通常フローでは発生しない）。片方のゲートに記録が無いことは不成立事由にしない）:
+   - (i) architect 帰属を含まない（developer / tester / planner のみ）
+   - (ii) 記録の --note に固定トークン `帰属根拠:明確` が含まれる。トークン不在・`帰属根拠:要判断`・note が取得できない・note から帰属根拠が一意に読み取れない、はいずれも不成立
+
+   **判定入力の取得手順（3 段・会話優先）**: --role・--note は当該差し戻しで親自身が実行した record ブロックの値を C-2 提示に転記する（会話に残っている値を優先し、fallback は補助）。会話上に残っていない場合（compaction・セッション交代後）は `c3 tier stats --json --recent 100`（--recent を十分大きく明示する。既定 10 件では当該行が落ちる）の recent_outcomes から当該 E-1/E-2 failure 行（gate・ts で特定）の note を読む。別周回排除の ts 照合: 基準は `.claude/reports/code-review-report-*.md`（E-2 の場合は `security-review-report-*.md`）のファイル名タイムスタンプが最大のもの 1 件とする（差し戻し起因の C-2 は当該 E 周回の直後にしか到達せず、C-2 到達までに新しい CR/SR は生成されないため最新＝当該周回が成立する）。基準レポートが存在しない場合は判定不能＝不成立。取得した記録の ts が基準レポートの ts より前なら当該周回の記録ではない（5 分 dedupe による未記録）とみなし判定不能＝不成立。それでも取得できない場合も判定不能＝不成立。会話に値が残っている場合でも、可能なら DB 側の該当行（`c3 tier stats --json --recent 100` の recent_outcomes を gate・ts で特定）と突合し、不一致なら判定不能＝不成立とする。
+
+   **注記**: DB 保存時の note には先頭に `[task:<id>]` マーカーが付く場合があるため、トークン判定は含有判定とする（先頭一致にしない）。なお E ゲートの帰属判定 role 列挙に interviewer は存在しないため A要件起因は帰属アンカーでは検出できず、条件 (3) の記述的判定で捕捉する。
+
+3. **上流文書との無差分**: 修正が requirements-report・architecture-report の記述と矛盾せず、これらの文書の改訂（要件・設計の追加/変更）を必要としない
+
+4. **新規導入なし**: 新規機構・新規ファイルの導入を伴わない
+
+**宣言の固定書式（機械可読・タスク一覧と同じ提示ブロックに含める。role・note の転記も同じ提示に含める）**:
+
+```
+C-3省略宣言: plan-report-{当該 plan のタイムスタンプ} 上流逸脱なし（直接反映のみ・帰属 {当該差し戻しで記録した role の列挙}・上流文書無差分・新規導入なし）
+```
+
+帰属欄は実際に記録した role をそのまま列挙する（許容集合は developer / tester / planner。事実と異なる列挙は書かない）。条件不成立の場合は宣言を書かず、architect 帰属を含む場合は「C-3判定: 要監査（B設計起因の指摘を含む）」の 1 行提示を推奨。**暗黙スキップ禁止（宣言なし・転記なしの省略は不可）**。
+
+セッションファイルの自由記述セクション（`## うまくいったアプローチ` 等）へ実値入りの転記行書式を書かない（説明目的で書式に言及する場合はタイムスタンプをプレースホルダ表記 `{ts}` にする）。ステップ 0 の誤判定を防ぐため。
+
+**承認後の転記**: 当日のセッションファイル（`.claude/memory/sessions/{YYYYMMDD}.tmp`＝Stop hook が作成する当日ファイル）へ宣言と同一の 1 行を転記する。**転記位置は `現在地:` 行の直後を必須とする**（ステップ 0 の判定はこの位置に連続する転記行のみを読むため、他の位置への転記は無効）。当日ファイルに `現在地:` 行が無い場合（非標準構造）・当日ファイルそのものが存在しない場合（当日 1 度も Stop hook が走っていない等）は転記できない＝省略を宣言しない（fail-safe）。
+
+**4 択 JSON の使い分け**: 宣言を提示する C-2 再承認時のみ、承認 AskUserQuestion を 4 択にする。**既存の 3 択 JSON ブロックは初回・条件不成立時用としてそのまま残し、宣言提示時用の 4 択 JSON ブロックを本ブロック内に別途併記する**。**宣言を提示した C-2 再承認では下の 4 択 JSON を、それ以外は従来の 3 択 JSON を使う**。
+
+**4 択 JSON（宣言提示時・レビュー差し戻し C-2 再承認時のみ使用）**:
+
+```json
+{
+  "questions": [{
+    "question": "plan-report の内容を確認してください。どうしますか？",
+    "options": [
+      { "label": "承認", "description": "宣言を転記し C-3 で省略成立" },
+      { "label": "承認（監査は実施）", "description": "計画は承認する（ただし C-3 監査は実施する）。宣言は転記せず、代わりに C-3監査要求 を転記。C-3 ではステップ 0 の順 1 によりステップ 1 を出さずステップ 2 へ進む" },
+      { "label": "否認・修正を依頼する", "description": "フィードバックを入力して計画をやり直す" },
+      { "label": "否認・自分でファイルを編集する", "description": "reports/ のファイルを直接編集してから続ける" }
+    ]
+  }]
+}
+```
+
+「承認」「承認（監査は実施）」は承認側として扱い、セッションファイルの `- [ ] 計画` の `[x]` 化・`現在地:` の Edit・tier-routing 結果記録（--role planner --outcome success --gate C-2）は両方とも「承認」と同一とする。差分は以下のみ:
+- 「承認」: 宣言を当日セッションファイルへ転記
+- 「承認（監査は実施）」: 宣言の代わりに `C-3監査要求: plan-report-{当該 plan のタイムスタンプ}` の 1 行を当日セッションファイルへ転記する
+
+**3 択 JSON（初回 C-2・条件不成立時・非差し戻し経路用）**:
+
 内容を提示した後、AskUserQuestion で確認する:
 
 ```json
@@ -280,6 +342,28 @@ c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
 
 **セッションファイル運用:** C-3 は C-2 で `計画 [x]` 化が完了した後の独立ゲートである。セッションファイルへの新規 `- [ ]` フェーズ行の追加は不要。
 
+**ステップ 0: 転記行の確認（HITL 専用）**
+
+本ステップ（転記行 2 種＝C-3省略宣言 / C-3監査要求の評価）と転記行の生成（C-2 の C-3省略宣言ブロック）は HITL 専用。自律モードでは C-3 全体が autonomous-mode のゲート対応表に従う（design-critic を必ず起動・転記行の生成・評価は行わない）。自律モード（Claude Code 専用機能）では本ステップを適用しない（Claude Code 環境では `autonomous-mode` skill のゲート対応表を参照。Codex / Cursor / OpenCode には同 skill が写像されないため、本注記だけで判断できる）。
+
+**入口の優先関係**: C-3 に到達したら（HITL では）必ず本ステップ 0 を先に評価する。ステップ 4 末尾の『連鎖が C-2 を経て C-3 に戻ったら → ステップ 5 へ』は、本ステップ 0 が『転記行なし』と判定した場合の従来入口を指す。
+
+**判定手順**（当日セッションファイル `.claude/memory/sessions/{YYYYMMDD}.tmp` の未消費転記行のみで判定する。過去ファイル・archive は遡らない＝日跨ぎで転記行が失われた場合は下記「転記行なし」に倒れる・fail-safe。会話記憶で代替しない）:
+
+**判定対象は `現在地:` 行の直後に連続して置かれた転記行のみ**とし、自由記述セクション・他の位置に同型の文字列があっても判定に使わない。**判定対象内に現行 plan タイムスタンプと一致する未消費行が複数ある場合は『転記行なし』に倒す**（複数マッチ不成立・fail-safe）。
+
+| 順 | 判定 | 入口 | 消費処理 |
+|---|---|---|---|
+| 1 | 現行 plan タイムスタンプと一致する未消費の `C-3監査要求:` 行がある | ステップ 2（design-critic 起動。ステップ 1 は出さない＝ユーザーが C-2 で監査実施を選択済み） | 進むと同時に当該行を `C-3監査要求(消費済):` へ Edit |
+| 2 | 現行 plan タイムスタンプと一致する未消費の `C-3省略宣言:` 行がある | フェーズ D（省略成立。ステップ 1〜5 を実行しない） | 進むと同時に当該行を `C-3省略宣言(消費済):` へ Edit |
+| 3 | 転記行なし | 従来の入口へ: C-3 層別ルーティングからの連鎖復帰（ステップ 4 末尾の規定）はステップ 5・初回到達はステップ 1。**連鎖復帰かどうかが判別できない場合（compaction・セッション交代後等）はステップ 1 に倒す**（fail-safe。ステップ 1 は監査を促す側の質問であり安全側） | なし |
+
+**現行 plan タイムスタンプの取得**: 照合キーは「C-2 で承認した plan-report のタイムスタンプ」を用いる。会話に残っていない場合は `.claude/reports/plan-report-*.md` の最新ファイルのタイムスタンプを用いるが、**最新ファイルが当該 C-2 で承認した plan と異なる可能性がある場合（同日に別ワークフローが plan-report を Write した等）は照合不一致として扱い、fail-safe で「転記行なし」に倒す**。転記行の書式・タイムスタンプ・消費状態のいずれかが一致しない場合は「転記行なし」と扱う。
+
+**消費規定の補足**: **未消費のまま残った転記行は失効処理・削除を行わない**（当日ファイル限定と plan タイムスタンプ一致により判定上は自動的に無効化される。未消費行は効果観測で『宣言したが成立しなかった周回』として数えるため証跡として残す）。
+
+**省略の意味**: 省略は『質問の省略』であって監査の禁止ではない（ユーザーはいつでも監査を明示要求できる）。
+
 **ステップ 1: opt-in の確認（AskUserQuestion 単独ターン）**
 
 AskUserQuestion で確認する（このブロックに Agent 起動などの副作用ツールを混在させない）:
@@ -780,7 +864,7 @@ c3 run .claude/skills/dev-workflow/scripts/record_review_decision.py \
   --reviewer code-reviewer
 ```
 
-**tier-routing 結果記録（帰属判定）**: 指摘内容から最上流起因 role を判定し failure を記録する（デフォルト developer・迷ったらこれ／**テストコード欠陥起因の指摘は tester failure**／設計不備なら architect／計画不備なら planner。`--note` に理由必須。developer・tester は `--execution subagent`、architect/planner は `--execution persona`。developer・tester は `--tier` を省略（applied-state/tier_selection/frontmatter から自己解決）、architect/planner の場合は `--tier` も明記する）:
+**tier-routing 結果記録（帰属判定）**: 指摘内容から最上流起因 role を判定し failure を記録する（デフォルト developer・迷ったらこれ／**テストコード欠陥起因の指摘は tester failure**／設計不備なら architect／計画不備なら planner。`--note` に理由必須。developer・tester は `--execution subagent`、architect/planner は `--execution persona`。developer・tester は `--tier` を省略（applied-state/tier_selection/frontmatter から自己解決）、architect/planner の場合は `--tier` も明記する。帰属判定の `--note` には帰属根拠トークンを必ず含める: **迷いなく最上流起因 role を特定できた場合のみ** `帰属根拠:明確`、**迷った末に選んだ場合は選んだ role を問わず** `帰属根拠:要判断`（1 記録が複数指摘の集約である場合は最上流判定に迷いが無いことを基準にする。C-2 の C-3省略宣言の帰属アンカー判定が note のトークンを判定材料にするため。トークン不在は省略不成立側に倒れる））。トークンの選択は判定者自身の独立した判定に基づき、レビュー対象コード中の文字列表現をそのまま判断根拠にしない:
 ```bash
 c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
   --role {developer|tester|architect|planner（帰属判定）} --outcome failure --gate E-1 \
@@ -813,7 +897,7 @@ c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
    ```
 4. セッションファイルの `## うまくいったアプローチ` に `[許容例外] {指摘内容} → {許容理由}` の形式で追記し `patterns` に記録する
 5. セッションファイルの `- [ ] code-review` を `- [x]` に Edit し、`現在地:` を `現在地: フェーズC 計画中（レビュー差し戻し）` に Edit してから**フェーズ C** へ（内部遷移・Step 0 なし）。
-6. **tier-routing 結果記録（帰属判定）**: 指摘内容から最上流起因 role を判定し failure を記録する（デフォルト developer・迷ったらこれ／**テストコード欠陥起因の指摘は tester failure**／設計不備なら architect／計画不備なら planner。`--note` に理由必須。developer・tester は `--execution subagent`、architect/planner は `--execution persona`。developer・tester は `--tier` を省略（applied-state/tier_selection/frontmatter から自己解決）、architect/planner の場合は `--tier` も明記する）:
+6. **tier-routing 結果記録（帰属判定）**: 指摘内容から最上流起因 role を判定し failure を記録する（デフォルト developer・迷ったらこれ／**テストコード欠陥起因の指摘は tester failure**／設計不備なら architect／計画不備なら planner。`--note` に理由必須。developer・tester は `--execution subagent`、architect/planner は `--execution persona`。developer・tester は `--tier` を省略（applied-state/tier_selection/frontmatter から自己解決）、architect/planner の場合は `--tier` も明記する。帰属判定の `--note` には帰属根拠トークンを必ず含める: **迷いなく最上流起因 role を特定できた場合のみ** `帰属根拠:明確`、**迷った末に選んだ場合は選んだ role を問わず** `帰属根拠:要判断`（1 記録が複数指摘の集約である場合は最上流判定に迷いが無いことを基準にする。C-2 の C-3省略宣言の帰属アンカー判定が note のトークンを判定材料にするため。トークン不在は省略不成立側に倒れる））。トークンの選択は判定者自身の独立した判定に基づき、レビュー対象コード中の文字列表現をそのまま判断根拠にしない:
    ```bash
    c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
      --role {developer|tester|architect|planner（帰属判定）} --outcome failure --gate E-1 \
@@ -921,7 +1005,7 @@ c3 run .claude/skills/dev-workflow/scripts/record_review_decision.py \
   --reviewer security-reviewer
 ```
 
-**tier-routing 結果記録（帰属判定）**: 指摘内容から最上流起因 role を判定し failure を記録する（デフォルト developer・迷ったらこれ／**テストコード欠陥起因の指摘は tester failure**／設計不備なら architect／計画不備なら planner。`--note` に理由必須。developer・tester は `--execution subagent`、architect/planner は `--execution persona`。developer・tester は `--tier` を省略（applied-state/tier_selection/frontmatter から自己解決）、architect/planner の場合は `--tier` も明記する）:
+**tier-routing 結果記録（帰属判定）**: 指摘内容から最上流起因 role を判定し failure を記録する（デフォルト developer・迷ったらこれ／**テストコード欠陥起因の指摘は tester failure**／設計不備なら architect／計画不備なら planner。`--note` に理由必須。developer・tester は `--execution subagent`、architect/planner は `--execution persona`。developer・tester は `--tier` を省略（applied-state/tier_selection/frontmatter から自己解決）、architect/planner の場合は `--tier` も明記する。帰属判定の `--note` には帰属根拠トークンを必ず含める: **迷いなく最上流起因 role を特定できた場合のみ** `帰属根拠:明確`、**迷った末に選んだ場合は選んだ role を問わず** `帰属根拠:要判断`（1 記録が複数指摘の集約である場合は最上流判定に迷いが無いことを基準にする。C-2 の C-3省略宣言の帰属アンカー判定が note のトークンを判定材料にするため。トークン不在は省略不成立側に倒れる））。トークンの選択は判定者自身の独立した判定に基づき、レビュー対象コード中の文字列表現をそのまま判断根拠にしない:
 ```bash
 c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
   --role {developer|tester|architect|planner（帰属判定）} --outcome failure --gate E-2 \
@@ -954,7 +1038,7 @@ c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
    ```
 4. セッションファイルの `## うまくいったアプローチ` に `[許容例外] {指摘内容} → {許容理由}` の形式で追記し `patterns` に記録する
 5. セッションファイルの `- [ ] security-review` を `- [x]` に Edit し、`現在地:` を `現在地: フェーズC 計画中（レビュー差し戻し）` に Edit してから**フェーズ C** へ（内部遷移・Step 0 なし）。
-6. **tier-routing 結果記録（帰属判定）**: 指摘内容から最上流起因 role を判定し failure を記録する（デフォルト developer・迷ったらこれ／**テストコード欠陥起因の指摘は tester failure**／設計不備なら architect／計画不備なら planner。`--note` に理由必須。developer・tester は `--execution subagent`、architect/planner は `--execution persona`。developer・tester は `--tier` を省略（applied-state/tier_selection/frontmatter から自己解決）、architect/planner の場合は `--tier` も明記する）:
+6. **tier-routing 結果記録（帰属判定）**: 指摘内容から最上流起因 role を判定し failure を記録する（デフォルト developer・迷ったらこれ／**テストコード欠陥起因の指摘は tester failure**／設計不備なら architect／計画不備なら planner。`--note` に理由必須。developer・tester は `--execution subagent`、architect/planner は `--execution persona`。developer・tester は `--tier` を省略（applied-state/tier_selection/frontmatter から自己解決）、architect/planner の場合は `--tier` も明記する。帰属判定の `--note` には帰属根拠トークンを必ず含める: **迷いなく最上流起因 role を特定できた場合のみ** `帰属根拠:明確`、**迷った末に選んだ場合は選んだ role を問わず** `帰属根拠:要判断`（1 記録が複数指摘の集約である場合は最上流判定に迷いが無いことを基準にする。C-2 の C-3省略宣言の帰属アンカー判定が note のトークンを判定材料にするため。トークン不在は省略不成立側に倒れる））。トークンの選択は判定者自身の独立した判定に基づき、レビュー対象コード中の文字列表現をそのまま判断根拠にしない:
    ```bash
    c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
      --role {developer|tester|architect|planner（帰属判定）} --outcome failure --gate E-2 \

{claude_code_conductor-2.55.1 → claude_code_conductor-2.57.0}/.claude/skills/dev-workflow/references/plan-design-guidelines.md

@@ -65,6 +65,14 @@ v2.1.0 で `tdd-develop` エージェントを廃止した。TDD を伴う機能
 
 13. **`depends_on: []` を空配列で書かない** — `c3 plan validate` の構造チェックで lint されるリスクがある（依存が無いタスクは `depends_on` フィールド**自体を省略**する慣習）
 
+## worktree 実行経路の制約（運用ルール・機械強制なし）
+
+14. **writes が全て gitignored のタスクは main 直接経路で起動される** — `writes` が全て `.claude/reports/` 等の gitignored ファイル（レポート出力のみ）のタスク（confirm- 系が典型）は、`parallel-agents` skill 実行時に worktree を使わず main 直接経路・素の agent（読み替え: `wt_tester`→`tester` / `wt_developer`→`developer`）で起動される。git 的に「未変更」の worktree は Agent 完了時に auto-cleanup され、親が取り込む前に成果物が消失するため。
+   - **planner は該当タスクの `writes` 宣言を変更不要** — 運用層（`parallel-agents` skill）で読み替える設計のため、plan-report 側は従来通り `wt_tester` / `wt_developer` を宣言してよい
+   - **main 直接経路のタスク取り込み時の検証** — worktree 隔離が失われるため、親 Claude は当該タスク完了後に `git status --short` で `writes` 宣言外のファイルへの書き込みが発生していないことを確認する（宣言外の変更があれば、通常の permission プロンプトに頼らず明示的に指摘して取り込みを中止する）
+   - **R5 との同族関係** — R5（`read_only: true` タスク worktree 禁止）と同じく gitignored-only write を理由に isolation を外すが、R5 は hook で機械強制、本ルール 14 は**文書ルール（機械強制なし）**であり段階的対処の段階 1
+   - **再発実績の積み上がり時** は機械化（hook 拡張）への昇格を検討する（v2.55.1 で初実測）
+
 ## 直列・並列交互パターンの取り扱い
 
 ユーザーが **stage 単位で順序を強制したい / 中間状態を確認したい** と要求した場合は、ルール 1（「真の依存だけに絞る」）から逸脱して順序付けの `depends_on` を許容してよい。典型構造:
@@ -102,6 +110,7 @@ plan-report を Write する前に以下を必ず確認する:
 - [ ] 想定実行時間が 15 分を超えるタスクがないか
 - [ ] R5: `read_only: true` タスクに `isolation: "worktree"` を指定していないか
 - [ ] R6: タスク総数 3 件以上なら reviewer 系タスクが 1 件以上含まれているか
+- [ ] ルール 14: writes が全て gitignored のタスク（confirm- 等）は運用層で main 直接経路に読み替えられることを認識しているか
 
 ---
 

{claude_code_conductor-2.55.1 → claude_code_conductor-2.57.0}/.claude/skills/parallel-agents/SKILL.md

@@ -110,9 +110,9 @@ stdout の JSON 形式:
 |---|---|---|---|---|
 | test-login | tester | `wt_tester` | false | tests/auth/test_login.py, .claude/reports/test-report-test-login.md |
 | impl-login | developer | `wt_developer` | false | src/auth/login.py |
-| confirm-login | tester | `wt_tester` | false | .claude/reports/test-report-confirm-login.md |
+| confirm-login | tester | `tester` | false | .claude/reports/test-report-confirm-login.md |
 
-v2.2.0 以降、全 agent が並列起動可能のため `parallelizable` 列は省略する。subagent_type マッピングは 2-C 参照。
+v2.2.0 以降、全 agent が並列起動可能のため `parallelizable` 列は省略する。subagent_type マッピングは 2-C 参照。confirm-login は writes が gitignored レポートのみのため 2-C の isolation ルール（gitignored-only writes は main 直接経路・素の agent）適用。
 
 ### 2-B: マイルストーン確認（設定時のみ）
 
@@ -154,7 +154,7 @@ plan-report 承認時点で全タスク・agent・writes・prompt が確認済
 
 - `subagent_type`: 上記マッピング表の値
 - `model`: **親 Claude は `model:` を指定しない**。`wt_developer` タスクは起動時に PreToolUse hook（`tier_autoapply.py`）が `[tier-routing 推奨]`（developer 基準）の推奨 Tier を `model:` へ自動適用する（機械適用・親 Claude が model: を転記する必要はない）。この推奨 Tier の SSOT は `.claude/state/tier_selection.json` の `tier`（無ければ `suggested_model`）であり、kickoff の UserPromptSubmit で 1 度確定して以降 wave をまたいで安定する（`[tier-routing 推奨]` の表示テキストはその派生表示）。hook は実適用した model を `.claude/state/tier_autoapply.jsonl` に記録する（適用者=記録 SSOT）。並列 wave 内に複数の `wt_developer` が居る場合、**全 wt_developer は同一の推奨 Tier（単一 tier_selection.json.tier）で起動される。これは本 MVP の設計として明示的に許容する**（per-task complexity に応じて wt_developer ごとに tier を変える機能は本 MVP のスコープ外・フェーズ 3 以降）。推奨と異なる Tier を使いたい場合のみ `model:` を明示指定する（明示指定は hook に尊重され上書きされない）。`wt_tester` は **test- タスク（Red）に限り機械適用対象**（`C3_TASK_ID` マーカーの `test-` プレフィックスで RED_APPLY_ROLES 注入・confirm- 等の非 test- タスクは対象外＝frontmatter 任せ）。`wt_systematic-debugger` / `code-reviewer` / `security-reviewer` は **model: 指定対象外**（frontmatter/元 agent 任せ・機械適用対象外）。fork は model 上書き不可のため対象外。
-- `isolation`: **`read_only: false` タスクのみ `"worktree"` を指定する。`read_only: true`（code-reviewer / security-reviewer）はソースを変更しないため worktree 不要。`isolation` を省略して main リポジトリで直接実行し、レポートを main の `.claude/reports/` に直接書かせる。**
+- `isolation`: **`read_only: false` タスクのみ `"worktree"` を指定する。ただし `writes` が全て gitignored ファイル（実質 `.claude/reports/` のレポートのみ）のタスク（confirm- 系が典型）は git 的に「未変更」の worktree となるため Agent 完了時に auto-cleanup され、親が取り込む前に成果物が消失する（2026-07-26 実測）ため、worktree を使わず `isolation` を省略して main 直接経路・素の agent（読み替え: `wt_tester`→`tester` 等）で起動する。`read_only: true`（code-reviewer / security-reviewer）はソースを変更しないため worktree 不要。`isolation` を省略して main リポジトリで直接実行し、レポートを main の `.claude/reports/` に直接書かせる。**
   > **R5 hook による機械強制**: 上記ルールに違反して `read_only: true` のレビュータスクに `isolation: "worktree"` を指定した場合、`.claude/hooks/check_agent_invocation.py`（PreToolUse Agent hook）が exit 2 でブロックする。詳細は `.claude/skills/dev-workflow/references/plan-design-guidelines.md` R5 参照。
 - `run_in_background`: `true`
 - `description`: タスク id（5 単語以内）
@@ -247,7 +247,7 @@ c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
   --execution subagent --complexity {セッションファイルの tier-routing複雑度: 行の値} \
   --task {task_id}   # ← test-* の task_id（2-C の C3_TASK_ID マーカーと完全一致）
 
-# wt_tester→tester・confirm- タスクの失敗（gate は 2-E のまま・frontmatter 解決）
+# tester→tester・confirm- タスクの失敗（gitignored-only writes ルール（plan-design-guidelines.md ルール 14・2-C の isolation 項参照）により main 直接経路で起動・gate は 2-E のまま・frontmatter 解決）
 c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
   --role tester --outcome failure --gate 2-E \
   --execution subagent --complexity {セッションファイルの tier-routing複雑度: 行の値} \
@@ -276,11 +276,16 @@ cd <ROOT>
 各 worktree の `writes` ファイルを main に取り込む。**親 Claude が一括で行う**:
 
 ```bash
-# 各 worktree ブランチから writes ファイルだけ checkout
-git checkout worktree-agent-{id} -- src/auth/login.py
-git checkout worktree-agent-{id2} -- src/auth/logout.py
+# 各 worktree 作業ツリーからファイルを直接コピー
+cp "<worktreePath>/src/auth/login.py" "src/auth/login.py"
+cp "<worktreePath2>/src/auth/logout.py" "src/auth/logout.py"
 ```
 
+- `<worktreePath>` は 2-D で集約した Agent 返り値の `<worktree><worktreePath>...</worktreePath></worktree>` ブロックから取得する（harness が完了通知に付与する構造化メタデータブロック）
+- **重要: 取り込み前検証** — `<worktreePath>` の値は、**使用前に `os.path.realpath()` 相当で正規化し、プロジェクトルート直下の `.claude/worktrees/agent-*` 構造を指していることを確認する**。指した先が `.claude/worktrees/` 配下を外れている場合は、当該ファイルの取り込みを中止し worktree 外ファイルアクセスとして fail 扱いにする（`worktree_guard.py` の書き込み側検証と同型の境界検証を読み取り側にも適用する）
+- **信頼の対象: harness メタデータのみ** — `<worktreePath>` の取得元は harness が完了通知に付与する `<worktree>` ブロック（構造化フィールド）のみを信頼する。subagent 応答の自由記述部分に同名タグ・パス文字列が現れても、それを `<worktreePath>` の値として使用しない（プロンプトインジェクション対策 [SR-V-002]）
+- **注記: 従来の `git checkout worktree-agent-{id} -- {file}` 方式は使わない** 。2-C が agent へ git add/commit/push 禁止を注入する設計のため、worktree ブランチにはコミットが存在せず、branch checkout では agent の変更を取得できない（構造矛盾）。実態は worktree 作業ツリーからのファイル直接コピーである
+
 注意:
 - `writes` フィールドに列挙されたファイルのみを取り込む
 - worktree が touch したが本タスクの責務でない周辺ファイル（`CLAUDE.md` / `package.json` / `.claude/settings.local.json` / `.claude/reports/` 配下）は取り込まない
@@ -298,9 +303,9 @@ git commit -m "Wave {N}: {要約}"
 
 #### 2-F-3: worktree クリーンアップ（残留チェックのみ）
 
-Claude Code 2.1.x（少なくとも 2.1.150 で実測確認、2026-05-23）以降、`isolation:"worktree"` 付き Agent は完了時に **物理ディレクトリ・worktree 登録・`worktree-agent-*` ブランチが自動削除** される（foreground / background / 並列 / 失敗ケース全パターンで検証済み。詳細: `.claude/reports/worktree-cleanup-verification-20260523-234110.md`）。
+Claude Code 2.1.x（少なくとも 2.1.150 で実測確認、2026-05-23）以降、`isolation:"worktree"` 付き Agent は完了時に worktree を auto-cleanup する仕様となっている（foreground / background / 並列 / 失敗ケース全パターンで検証済み。詳細: `.claude/reports/worktree-cleanup-verification-20260523-234110.md`）。ただし実測では **git 的に未変更の worktree は自動削除されるが、変更が残る worktree は残留しうる**（2026-07-26 実測）。
 
-そのため明示的な `git worktree remove` は **不要**。auto-cleanup が race や障害でスキップされた場合のセーフティとして残留チェックのみ行う:
+したがって明示的な `git worktree remove` は基本的に不要だが、auto-cleanup が完全に走らなかった場合のセーフティとして残留チェック + 手動 cleanup で後始末する:
 
 ```bash
 # 念のため worktree 登録の残留を確認、あれば prune（物理ディレクトリも片付く）
@@ -362,7 +367,7 @@ append_checkpoint(os.path.join(SESSIONS_DIR, '{YYYYMMDD}.tmp'),
 
 - **impl- タスク（wt_developer）の成功** → `--role developer --gate 2-D`（現行のまま）。
 - **test- タスク（wt_tester Red）の成功** → **success を記録しない**（**現行の `--gate 2-D` success 記録は廃止**＝成功の確定は confirm- 全合格まで遅延）。ただし wave 完了処理で親が test-report を確認し、**条件 1（Red の失敗理由が意図と違う）・条件 2（ベースライン破壊）** の違反があれば `--role tester --outcome failure --gate D-1 --task test-{X}` を記録する（違反が無ければこの時点では何も記録しない）。
-- **confirm- タスク（wt_tester）の成功** → **2 件**記録する:
+- **confirm- タスク（plain tester・main 直接経路）の成功** → **2 件**記録する（ルール 14 により gitignored-only writes のため main 直接経路で起動される。記録ルールは同一）:
   1. confirm-X 自身のイベントログ `--role tester --outcome success --gate 2-D --task confirm-{X}`（現行のまま・bandit 外）。
   2. **条件 4（Red 成果物の生存確定）**: confirm-X 全合格（wave 成功）は Red が要求した挙動が実装で満たされた確定点なので、対応する test-X の成功を `--role tester --outcome success --gate D-1 --task test-{X}` として記録する（逐次 D-3 全合格時と同じ確定点）。
 
@@ -375,7 +380,7 @@ c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
   --execution subagent --complexity {セッションファイルの tier-routing複雑度: 行の値} \
   --task {task_id}   # ← 2-C の C3_TASK_ID マーカーと完全一致・突合の必須キー
 
-# confirm- タスク自身のイベントログ: wt_tester→tester（gate 2-D・frontmatter 解決）
+# confirm- タスク自身のイベントログ: tester→tester（ルール 14 により main 直接経路で起動・gate 2-D・frontmatter 解決）
 c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
   --role tester --outcome success --gate 2-D \
   --execution subagent --complexity {セッションファイルの tier-routing複雑度: 行の値} \

{claude_code_conductor-2.55.1 → claude_code_conductor-2.57.0}/CHANGELOG.md

@@ -1,5 +1,42 @@
 # Changelog
 
+## [2.57.0] - 2026-07-27
+
+### 追加
+
+- **dev-workflow C-2 に C-3省略宣言ブロック新設（E→C差し戻し時のレビュー差し戻し再承認のみ・HITL 専用）**: レビューフェーズ E で指摘が出て C へ差し戻される場合に限定して、差し戻し後の C-2 再承認時に 「修正計画が findings の直接反映のみで上流文書との差分がない」という客観条件を満たせば、C-3（design-critic 監査）を質問なく省略できる機構を追加。省略条件は 4 条件の AND: **(1) 直接反映のみ**（テスト追加・文言修正・レビュアー提示の具体案の移植のみ。複数 findings 一括解消のための方式変更・既存テスト構造の変更は不成立側）/ **(2) 帰属アンカー**（当該差し戻しの帰属判定記録に architect 帰属を含まず、かつ note に固定トークン `帰属根拠:明確` が含まれること）/ **(3) 上流文書との無差分**（requirements/architecture との矛盾なし・文書改訂不要）/ **(4) 新規導入なし**（新規機構・新規ファイル導入を伴わない）。暗黙スキップ禁止・判定不能・曖昧なら質問側に倒す fail-safe 設計。4 条件に達した C-2 再承認では、新規の 4 択 JSON を提示（「承認」「承認（監査は実施）」「否認・修正を依頼する」「否認・自分でファイルを編集する」）し、ユーザーの明示宣言により監査省略を確定する。
+- **dev-workflow C-3 ステップ 0 新設（転記行の確認・HITL 専用）**: C-2 の C-3省略宣言ブロックで生成された転記行（`C-3省略宣言:` / `C-3監査要求:`）をセッションファイルで評価する新規ステップ。当日セッションファイル（`.claude/memory/sessions/{YYYYMMDD}.tmp`）の `現在地:` 行の直後に置かれた未消費転記行のうち、現行 plan タイムスタンプと一致するものを判定対象とする（位置限定・複数マッチ不成立）。**順 1**: `C-3監査要求:` があればステップ 2（design-critic 起動・ユーザーが C-2 で監査実施を選択済み）/ **順 2**: `C-3省略宣言:` があればフェーズ D へ進む（省略成立・ステップ 1〜5 実行なし）/ **順 3**: 転記行なし→従来入口（初回はステップ 1・層別ルーティング復帰はステップ 5）。転記行の消費状態を `(消費済):` へ Edit することで、同一セッション内での重複消費を防ぐ。日跨ぎで転記行が失われた場合は fail-safe で質問側に倒す。
+- **plan-report の新規タイムスタンプ必須化（全経路）**: E→C 差し戻し・C-3 層別ルーティング・C-2 否認のいずれで plan-report を再生成する場合も、ピンポイント修正であっても既存 plan-report の Edit・同一タイムスタンプでの再承認は禁止し、必ず新規タイムスタンプで Write する。転記行と plan の 1:1 紐付け（ステップ 0 の ts 一致判定が古い plan と新しい plan を混同しない）と「最新 plan タイムスタンプ = 現行」の成立を守る書式規約。
+- **E-1/E-2 帰属判定に帰属根拠トークン必須化**: tier-routing 結果記録（帰属判定）の `--note` に固定トークン `帰属根拠:明確` / `帰属根拠:要判断` を必ず含める規約を新設。迷いなく最上流起因 role を特定できた場合のみ `帰属根拠:明確`、迷った末に選んだ場合は `帰属根拠:要判断`（複数指摘の集約の場合は最上流判定に迷いが無いことが基準）。このトークンは C-2 の C-3省略宣言の帰属アンカー条件 (2) で直接参照され、省略の成否を左右する肯定表明。トークン不在・`帰属根拠:要判断`・判定記録が取得できない場合は省略不成立側に倒す。
+
+### 変更
+
+- **dev-workflow C-2 節を約 87 行拡張**: 新規タイムスタンプ規約・C-3省略宣言ブロック（4 条件 AND・省略条件の詳細判定手順・固定書式・3 段取得フォールバック・セッションファイルへの転記位置必須化・4 択/3 択 JSON の併記）・4 択新設 JSON の分岐条件がインライン追加される（E→C 差し戻し後のレビュー差し戻し C-2 再承認という発生頻度の低い分岐）。初回 C-2・条件不成立時は従来の 3 択 JSON を使用。
+- **dev-workflow C-3 ステップ 1 の説明を改訂**: opt-in の確認に「省略は『質問の省略』であって監査の禁止ではない（ユーザーはいつでも監査を明示要求できる）」という意味合いを追記。
+- **autonomous-mode SKILL.md のゲート対応表 C-3 行に注記追加**: 自律モードでは C-3 全体が本表に従う（design-critic を必ず起動・差し戻し後も上限 2 サイクルの別枠・転記行の生成・評価は行わない）。理由: 自律は人間の承認の目が無いため機械監査を厚く保つ。ステップ 0 の転記行確認は HITL 専用・自律モードでは実施しない注記も明記。
+- **autonomous-mode SKILL.md に新規注記を追加**: 「dev-workflow C-3 のステップ 0（転記行確認）と転記行生成の C-2 ブロックは HITL 専用。自律モードでは C-3 全体が本表に従い、差し戻し後も design-critic を必ず起動する。転記行 2 種の生成・評価も行わない」。
+
+### 後方互換
+
+- **破壊的変更なし**。本リリースは `.claude/skills/dev-workflow/SKILL.md`（+88/-4）と `.claude/skills/autonomous-mode/SKILL.md`（+3/-1）の文書規約のみを追加・変更する。実装コード・hook・テストの変更は伴わない（confirm- タスク・design-review 6 サイクル・code-review・security-review で検証済み）。初回 C-3（C-2 承認直後に初めて到達）の挙動は変わらず（毎回 opt-in 質問を出す）。C-3省略は E→C 差し戻し後という限定シーンで発動し、既定の HITL・opt-in なし挙動を壊さない不変則（`.claude/CLAUDE.md` Approval Flow）を保持。
+
+## [2.56.0] - 2026-07-26
+
+### 追加
+
+- **plan-design-guidelines にルール 14 を新設（gitignored-only writes タスクの main 直接経路）**: `writes` が全て gitignored ファイル（`.claude/reports/` のレポート出力のみ・confirm- 系が典型）のタスクは、parallel-agents 実行時に worktree を使わず main 直接経路・素の agent（`wt_tester`→`tester` / `wt_developer`→`developer` 読み替え）で起動する運用ルールを文書化。git 的に「未変更」の worktree は Agent 完了時に auto-cleanup され、親が取り込む前に成果物（レポート）が消失する実測 defect（2026-07-26・v2.55.1 走行 Wave 2）の再発防止。R5（read_only タスクの worktree 禁止）と同族だが本ルールは文書ルール（hook 機械強制なし）で、planner の `writes` 宣言は変更不要（読み替えは実行層）。あわせて main 直接経路タスクは worktree の使い捨て隔離を失うため、親がタスク完了後に `git status --short` で宣言外変更なしを確認する検証手順も明記
+- **parallel-agents 2-F-1 に取り込み前検証を新設**: worktree からの成果物取り込みで使う `worktreePath` は、harness が完了通知に付与する `<worktree>` メタデータブロックのみを信頼し（subagent 応答本文中の同名タグ・パス文字列は無視＝プロンプトインジェクション対策）、使用前に realpath 相当で正規化して `.claude/worktrees/agent-*` 配下を指すことを確認する（範囲外は取り込み中止・fail 扱い）。`worktree_guard.py` の書き込み側検証と同型の境界検証を読み取り側にも適用。コマンド例もクォート付きへ修正
+
+### 変更
+
+- **parallel-agents 2-F-1 の取り込み方式を実態合わせ（`git checkout` ブランチ方式 → worktree 作業ツリーからの直接コピー）**: 従来記載の `git checkout worktree-agent-{id} -- {file}` は、2-C が agent へ git commit 禁止を注入する設計と構造矛盾（worktree ブランチにコミットが存在せず変更を取得できない）のため、実態である `cp` 直接コピー方式へ書き換え
+- **parallel-agents 2-F-3 の auto-cleanup 記述を条件形へ**: 「完了時に全パターンで自動削除」から「git 的に未変更の worktree は自動削除・変更が残る worktree は残留しうる（残留チェック＋手動 cleanup で後始末）」へ実測（2026-07-26）に基づき修正。2-A 例示表・2-F-4 の confirm- タスク表記もルール 14 と整合する形へ統一
+- **docs/parallel-agents-setup.md の auto-cleanup 信頼度節を一次資料と整合**: 2026-05-23 検証の実数（4 パターン・全 5 シナリオ）と累計 10/11 の出典関係・検証軸差分（旧検証はファイル変更を伴わないタスクのみ）・引用先の到達可能性（非配布・配布元ローカル保管）を明記
+
+### 後方互換
+
+- **破壊的変更なし**。全て skill / ガイドライン / docs の文書変更（テストは docstring 1 行のみ・実装コード変更なし）。ルール 14 は従来暗黙だった実行層の読み替えを明文化するもので、plan-report のスキーマ・agent 定義・hook 挙動は不変
+
 ## [2.55.1] - 2026-07-26
 
 ### 修正

{claude_code_conductor-2.55.1 → claude_code_conductor-2.57.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-conductor
-Version: 2.55.1
+Version: 2.57.0
 Summary: Multi-agent orchestration framework for Claude Code with Codex/Cursor adapters (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-2.55.1 → claude_code_conductor-2.57.0}/src/c3/__init__.py

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

{claude_code_conductor-2.55.1 → claude_code_conductor-2.57.0}/tests/skills/test_planner_lightweight.py

@@ -45,7 +45,7 @@ def test_planner_references_plan_design_guidelines():
 
 
 def test_plan_design_guidelines_exists_and_has_rules():
-    """skills/dev-workflow/references/plan-design-guidelines.md が存在し、ルール 1〜13 と R2〜R6 を含む。"""
+    """skills/dev-workflow/references/plan-design-guidelines.md が存在し、ルール 1〜14 と R2〜R6 を含む。"""
     content = _read(PLAN_DESIGN_GUIDELINES)
     assert content, "skills/dev-workflow/references/plan-design-guidelines.md が存在しない"
     required_concepts = (