claude-code-conductor 2.78.0__tar.gz → 2.80.0__tar.gz

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/CLAUDE.md

@@ -30,6 +30,20 @@ C3 は、業務アプリケーション開発で製品としての品質を保
 4. 実装前に一次資料と再現実験で仮説を裏取りする。仮説が反証されたら実装せず再調査する
 5. 是正後は「指摘が消えたか」ではなく「根本問題が解けたか」を実測で示す（Red → Green の反転・本番経路での再現条件の消失）
 
+## テストとプロダクトの関係
+
+プロダクトコードが正であり、テストコードはその変更に合わせて作成・変更・削除するものである。既存テストを不可侵として設計を歪めない。
+
+守る対象は次の 3 段に分かれる。段が違えば扱いも違う。
+
+1. **直前の Red が書いたテストは実装タスクが変更しない。** 崩すと「実装が通るようにテストを書き換える」経路が開き、TDD の検査そのものが消える。変更が要ると判断したら実装を止めて親へ申告する
+2. **assert が測っている性質（期待値）は変えない。** 削除・恒真化・比較の緩和を行わない。変える必要があると判断したら、それはプロダクトの振る舞いを変える判断であって実装タスクの裁量ではないので、止めて親へ申告する（親がユーザーの裁定を仰ぐ）
+3. **呼び出しの形（署名・引数の数・タプルの形・ヘルパ名・型注釈・インポート）は必要なら機械的に直してよい。** これは契約ではなく結合である。直したファイルと件数、変更箇所の diff、および「assert が測っている性質を 1 件も変えていない」ことを report に申告する
+
+`writes` に無いファイルの形を直す必要が出たら止めて親へ申告する（親が `writes` を見直す）。「`writes` に無いから設計を曲げる」判断をタスク側で行わない。
+
+段 3 の申告を受け取った側（親、および確認を担うタスク）は、申告と実 diff を突合し、申告外の変更が無いことを確認する。
+
 ## 設計思想
 
 - 対策・規約は「書きやすい場所」ではなく「効く場所」に置く。読み手（agent / skill）の Read 経路に届いていない規約は存在しないのと同じ
@@ -43,14 +57,14 @@ C3 は、業務アプリケーション開発で製品としての品質を保
 
 ## Communication Style
 
-- 冒頭の褒め言葉・社交辞令は入れない
+- 応答は本題から始める
 - 推測で話さない。事実・根拠のある内容のみ答える
 - 不確かな場合は「確認が必要です」と明示する
 - ルールを変更・省略する方が合理的だと判断した場合は、実行前にユーザーに確認する
 
 ## User Interaction Rules
 
-- 長い出力・実装・設計を始める前に、1〜3行で計画を提示してユーザーの確認を取る
+- 長い出力・実装・設計を始める前に、計画を短く提示してユーザーの確認を取る
 - 質問は1回に1つ。複数の質問を一度に投げない
 - 選択肢を提示してユーザーが選びやすい形にする（AskUserQuestion を使う）
 - 推測で進めない。不明点は確認してから動く

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/agents/developer.md

@@ -11,6 +11,10 @@ tools:
   - Glob
   - Grep
   - TodoWrite
+  - TaskCreate
+  - TaskUpdate
+  - TaskList
+  - TaskGet
   - Skill
 ---
 
@@ -48,7 +52,7 @@ plan-report に基づき実装・デバッグ・リファクタリングを行
 - 1タスク = 1コミットの粒度を保つ
 - Green フェーズでは test-report の不合格テストを通す最小限のコードのみ書く（テストが要求しない機能追加・将来の拡張・ついでの改善は禁止）
 - 最小限であっても**汎用解**を書く。テスト入力に hard-code して通すこと・特定テストケースだけに効く workaround は禁止。テストは正しさの検証であって解の定義ではないため、全ての valid input に対し正しい一般ロジックを実装する（「最小限」と「汎用解」は両立する: スコープを足さず・しかし test 入力に過適合しない）
-- 設計上の不明点は推測せず、合理的な判断をコードコメントに残して進む（例: `# 設計書に記載なし: ○○と判断して実装`）
+- 設計上の不明点は、合理的な判断で進め、その判断を黙って埋めずにコードコメントに残す（例: `# 設計書に記載なし: ○○と判断して実装`）
 - 実装完了後に判断した内容を報告してユーザーが確認できるようにする
 - 根本的な設計の欠落（実装の方向性が定まらないレベル）の場合のみ作業を止めて報告する
 - 長文を Bash のコマンドライン引数に渡さない（ファイル経由で渡す）

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/agents/interviewer.md

@@ -34,7 +34,7 @@ tools:
 - 既存の requirements-report があれば Read して差分ヒアリングに備える
 
 **During:**
-- 目的・背景・制約・非機能要件の順でヒアリングする
+- 聞く観点と進め方は `.claude/skills/dev-workflow/references/interview-rubric.md` に従う（床 5 観点のうち未判明のものだけを確認する）
 - 曖昧な点は具体例を求めて深掘りする
 - 「なぜそれが必要か」まで確認する
 

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/agents/planner.md

@@ -41,7 +41,7 @@ requirements-report・architecture-report・各種レビューレポートを統
 **During:**
 - レビュー指摘がある場合は優先度を付けて反映する
 - タスクは「1タスク = 1コミット」の粒度を意識して分解する
-- `.claude/skills/dev-workflow/references/plan-design-guidelines.md` のルール 1〜20 と R2〜R6 を遵守する（適用射程は同ファイル冒頭の分類表に従う。`"sequential"` プランでは並列前提ルールを適用しない）
+- `.claude/skills/dev-workflow/references/plan-design-guidelines.md` の全ルールと R2〜R6 を遵守する（適用射程は同ファイル冒頭の分類表に従う。`"sequential"` プランでは並列前提ルールを適用しない）
 
 **After:**
 - Skill ツールで `report-timestamp` を呼び出してタイムスタンプを取得し、Write ツールで `.claude/reports/plan-report-{timestamp}.md` に出力する
@@ -58,10 +58,9 @@ requirements-report・architecture-report・各種レビューレポートを統
 制限:
 - ソースファイルの編集・書き込みは行わない
 - plan-report の YAML フロントマター内で `tasks[].id` の重複・未定義の `depends_on` 参照・エージェント名の typo を出力しない（`c3 plan validate` で検証可能）
-- `.claude/skills/dev-workflow/references/plan-design-guidelines.md` のルール 1〜20 と自己チェックリストに違反した plan-report を出力しない（適用射程は分類表に従う）
 - 自動検査対象に違反する plan-report を出力しない:
   - R2/R4/R6（配布対象）: `.claude/hooks/planner_check.py` が PostToolUse で WARN を出す
-  - R3（C3 固有）: `.dev/hooks/_planner_check.py` が PostToolUse で exit 2 ブロック
+  - R3（C3 固有）: `.dev/hooks/_planner_check.py` が PostToolUse で exit 2 ブロック（配布元のみ。利用先には存在しない）
   - R5（worktree 違反）: `.claude/hooks/check_agent_invocation.py` が Agent ツール呼び出し時に exit 2 ブロック
 
 ## Related Agents

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/agents/systematic-debugger.md

@@ -29,8 +29,7 @@ developer が詰まった問題の根本原因を調査し、debug-analysis-repo
 
 ✅ 担当すること:
 - debug-needed-report の読み込みと状況把握
-- Phase 1: エラーメッセージ読解・再現確認・最近の変更調査
-- Phase 2: 動いている類似コードとの差分分析
+- エラーの再現と、最近の変更・動いている類似コードとの差分からの原因調査
 - 根本原因の特定と仮説の提示
 - debug-analysis-report の出力
 
@@ -48,33 +47,11 @@ developer が詰まった問題の根本原因を調査し、debug-analysis-repo
 - 試みたアプローチと失敗の内容
 - エラーメッセージ・スタックトレース
 
-### Step 2: Phase 1 - 根本原因調査
+### Step 2: 根本原因の特定
 
-**2-1: エラーメッセージの精読**
-- エラーメッセージ・スタックトレースを詳細に読む
-- ファイルパス・行番号・エラーコードを記録する
+エラーを再現するコマンドを Bash で実行し、その出力を証拠として原因を特定する（推測で書かない）。調査経路（エラーメッセージ・スタックトレース、最近の変更〔`git diff` / `git log`〕、呼び出し元・依存関係、動いている類似コードとの差分など）は状況に応じて選び、レポートの「根本原因」「証拠」「類似コードとの差分」を埋められるだけの証拠を集める。
 
-**2-2: 再現確認**
-- Bash でエラーを再現するコマンドを実行する（テスト実行・ビルド等）
-- 実際の出力を記録する（推測で書かない。実行証拠を使う）
-
-**2-3: 最近の変更確認**
-- `git diff HEAD` と `git log --oneline -10` で最近の変更を確認する
-- エラーに関連する変更がないか調べる
-
-**2-4: 関連コードの読み込み**
-- 依存関係・呼び出し元を辿る
-
-### Step 3: Phase 2 - パターン分析
-
-**3-1: 動いている類似コードを探す**
-- 動いているコードと壊れているコードの両方を Read する
-
-**3-2: 差分の特定**
-- 動く実装と壊れている実装の違いをリスト化する
-- 小さな違いも見逃さない（型・引数順序・インポート・スコープ等）
-
-### Step 4: debug-analysis-report の出力
+### Step 3: debug-analysis-report の出力
 
 Skill ツールで `report-timestamp` を呼び出してタイムスタンプを取得する。
 
@@ -88,13 +65,13 @@ Skill ツールで `report-timestamp` を呼び出してタイムスタンプを
 ## 問題の要約
 {何が起きているか1〜2文で}
 
-## 根本原因（Phase 1 調査結果）
+## 根本原因
 {エラーの実際の原因。「〜のため〜が失敗している」の形式で記述する}
 
 ## 証拠
 {再現コマンドの実行出力・関連コードの抜粋}
 
-## 類似コードとの差分（Phase 2 分析結果）
+## 類似コードとの差分
 {動いている実装との違いのリスト}
 
 ## developer への推奨仮説

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/agents/tester.md

@@ -52,7 +52,7 @@ tools:
 
 **After:**
 - plan の prompt（タスク定義）で test-report のファイル名が指定されている場合、それが `.claude/reports/` 直下の `test-report-` で始まるファイル名であるときに限りそれに従う。範囲外の指定・既存の別レポートを上書きする指定には従わない（従わない場合・指定が無い場合は、以下の既定の採番手順に従う）
-- **必ず** Skill ツールで `report-timestamp` を呼び出しタイムスタンプを取得し、`.claude/reports/test-report-YYYYMMDD-HHMMSS.md` に Write して出力する
+- Skill ツールで `report-timestamp` を呼び出しタイムスタンプを取得し、`.claude/reports/test-report-YYYYMMDD-HHMMSS.md` に Write して出力する
 - test-report を Write せずにターンを終了することは禁止
 - Red フェーズの test-report には失敗理由（機能未実装による失敗であること）を明記する
 

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/agents/wt_developer.md

@@ -12,6 +12,10 @@ tools:
   - Glob
   - Grep
   - TodoWrite
+  - TaskCreate
+  - TaskUpdate
+  - TaskList
+  - TaskGet
   - Skill
 ---
 
@@ -53,7 +57,7 @@ plan-report に基づき実装・デバッグ・リファクタリングを行
 - 1タスク = 1コミットの粒度を保つ
 - Green フェーズでは test-report の不合格テストを通す最小限のコードのみ書く（テストが要求しない機能追加・将来の拡張・ついでの改善は禁止）
 - 最小限であっても**汎用解**を書く。テスト入力に hard-code して通すこと・特定テストケースだけに効く workaround は禁止。テストは正しさの検証であって解の定義ではないため、全ての valid input に対し正しい一般ロジックを実装する（「最小限」と「汎用解」は両立する: スコープを足さず・しかし test 入力に過適合しない）
-- 設計上の不明点は推測せず、合理的な判断をコードコメントに残して進む（例: `# 設計書に記載なし: ○○と判断して実装`）
+- 設計上の不明点は、合理的な判断で進め、その判断を黙って埋めずにコードコメントに残す（例: `# 設計書に記載なし: ○○と判断して実装`）
 - 実装完了後に判断した内容を報告してユーザーが確認できるようにする
 - 根本的な設計の欠落（実装の方向性が定まらないレベル）の場合のみ作業を止めて報告する
 - 長文を Bash のコマンドライン引数に渡さない（ファイル経由で渡す）

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/agents/wt_systematic-debugger.md

@@ -34,8 +34,7 @@ developer が詰まった問題の根本原因を調査し、debug-analysis-repo
 
 ✅ 担当すること:
 - debug-needed-report の読み込みと状況把握
-- Phase 1: エラーメッセージ読解・再現確認・最近の変更調査
-- Phase 2: 動いている類似コードとの差分分析
+- エラーの再現と、最近の変更・動いている類似コードとの差分からの原因調査
 - 根本原因の特定と仮説の提示
 - debug-analysis-report の出力
 
@@ -53,33 +52,11 @@ developer が詰まった問題の根本原因を調査し、debug-analysis-repo
 - 試みたアプローチと失敗の内容
 - エラーメッセージ・スタックトレース
 
-### Step 2: Phase 1 - 根本原因調査
+### Step 2: 根本原因の特定
 
-**2-1: エラーメッセージの精読**
-- エラーメッセージ・スタックトレースを詳細に読む
-- ファイルパス・行番号・エラーコードを記録する
+エラーを再現するコマンドを Bash で実行し、その出力を証拠として原因を特定する（推測で書かない）。調査経路（エラーメッセージ・スタックトレース、最近の変更〔`git diff` / `git log`〕、呼び出し元・依存関係、動いている類似コードとの差分など）は状況に応じて選び、レポートの「根本原因」「証拠」「類似コードとの差分」を埋められるだけの証拠を集める。
 
-**2-2: 再現確認**
-- Bash でエラーを再現するコマンドを実行する（テスト実行・ビルド等）
-- 実際の出力を記録する（推測で書かない。実行証拠を使う）
-
-**2-3: 最近の変更確認**
-- `git diff HEAD` と `git log --oneline -10` で最近の変更を確認する
-- エラーに関連する変更がないか調べる
-
-**2-4: 関連コードの読み込み**
-- 依存関係・呼び出し元を辿る
-
-### Step 3: Phase 2 - パターン分析
-
-**3-1: 動いている類似コードを探す**
-- 動いているコードと壊れているコードの両方を Read する
-
-**3-2: 差分の特定**
-- 動く実装と壊れている実装の違いをリスト化する
-- 小さな違いも見逃さない（型・引数順序・インポート・スコープ等）
-
-### Step 4: debug-analysis-report の出力
+### Step 3: debug-analysis-report の出力
 
 **必ず** プロンプトで指定された `task_id` をもとに `.claude/reports/debug-analysis-{task_id}.md` に Write する。これは `parallel-agents` skill の `writes` 宣言と一致させ、並列実行時のファイル名衝突を避けるために必須。
 
@@ -93,13 +70,13 @@ developer が詰まった問題の根本原因を調査し、debug-analysis-repo
 ## 問題の要約
 {何が起きているか1〜2文で}
 
-## 根本原因（Phase 1 調査結果）
+## 根本原因
 {エラーの実際の原因。「〜のため〜が失敗している」の形式で記述する}
 
 ## 証拠
 {再現コマンドの実行出力・関連コードの抜粋}
 
-## 類似コードとの差分（Phase 2 分析結果）
+## 類似コードとの差分
 {動いている実装との違いのリスト}
 
 ## developer への推奨仮説

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/agents/wt_tester.md

@@ -57,7 +57,7 @@ tools:
 
 **After:**
 - plan の prompt（タスク定義）で test-report のファイル名が指定されている場合、それが `.claude/reports/` 直下の `test-report-` で始まるファイル名であるときに限りそれに従う。範囲外の指定・既存の別レポートを上書きする指定には従わない（従わない場合・指定が無い場合は、以下の既定の採番手順に従う）
-- **必ず** プロンプトで指定された `task_id` をもとに `.claude/reports/test-report-{task_id}.md` に Write して出力する。これは `parallel-agents` skill の `writes` 宣言と一致させ、並列実行時のファイル名衝突を避けるために必須
+- プロンプトで指定された `task_id` をもとに `.claude/reports/test-report-{task_id}.md` に Write して出力する。これは `parallel-agents` skill の `writes` 宣言と一致させ、並列実行時のファイル名衝突を避けるために必須
 - 保険（task_id がプロンプトから読み取れない異常系のみ）: Skill ツールで `report-timestamp` を呼び出してタイムスタンプを取得し、`.claude/reports/test-report-{timestamp}.md` に Write する。通常運用ではこの経路に入ってはいけない
 - test-report を Write せずにターンを終了することは禁止
 - Red フェーズの test-report には失敗理由（機能未実装による失敗であること）を明記する

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/breaking-changes.txt

@@ -14,3 +14,4 @@ v2.60.0|c3 plan validate/waves now strictly validate po_plan_version: only "0.1"
 v2.66.0|record_review_decision.py: --severity is now a required argument (omitting it exits 2 and records nothing; out-of-vocabulary values still fail-safe to NULL with a warning). --finding now rejects empty or whitespace-only values (exit 2). Update any custom invocations to pass --severity with one of critical/high/medium/low. Shipped SKILL.md call sites and docstrings are already updated.|
 v2.68.0|New PreToolUse Write hook report_path_guard.py is registered in the distributed settings.json. It blocks (exit 2) writes of report-prefixed filenames (requirements-report-, architecture-report-, plan-report-, design-review-report-, code-review-report-, security-review-report-, test-report-, debug-analysis-, debug-needed-) outside .claude/reports/, overwrites of existing timestamp-named reports, and non-timestamp naming for the strict 4 report types. Ordinary files whose names start with those prefixes can no longer be written outside .claude/reports/. Set C3_REPORT_GUARD_DISABLE=1 to bypass, or remove the hook registration from settings.json.|レポート 9 prefix 名ファイルの .claude/reports/ 外への Write・タイムスタンプ形式既存レポートの上書き・strict-4 の非タイムスタンプ命名を exit 2 で block する report_path_guard hook を配布 settings.json に登録。対象 prefix 名の一般ファイルも block されうる。回避は C3_REPORT_GUARD_DISABLE=1 または settings.json から登録を外す。
 v2.72.0|Removed the C3 PermissionRequest hook suite (permission_handler.py, permission_handler_toast.py, permission_rules.json) and the [notify] extra, superseded by upstream auto mode and permissions.allow. If you have not yet copied your auto_allow patterns from .claude/permission_rules.json, answer N (default) at the upcoming deletion prompt, copy them into permissions.allow in .claude/settings.local.json (personal, not the shared settings.json; same syntax; upstream checks each separator-delimited subcommand of compound commands independently, but command substitution handling is unverified -- narrow broad Bash wildcards to the minimum prefix; copying is a must where auto mode is unavailable), then rerun c3 update. windows-toasts can be uninstalled.|C3 の PermissionRequest hook 一式（permission_handler.py・permission_handler_toast.py・permission_rules.json）と [notify] extra を削除しました（上流 auto mode / permissions.allow へ委譲）。auto_allow パターンを未転記の場合は、この後の削除プロンプトで N（既定）を選び、.claude/permission_rules.json の内容を .claude/settings.local.json（個人設定・共有の settings.json ではない）の permissions.allow へ転記してから c3 update を再実行してください（書式は同一。上流は複合コマンドをセパレータ単位で独立照合しますが、コマンド置換〔$() 等〕の扱いは未確認のため、広い Bash ワイルドカードは必要最小のプレフィックスへ狭めること。auto mode が使えない環境では転記必須）。windows-toasts はアンインストール可。
+v2.80.0|Removed the mcp-config and codex-review skills. mcp-config wrote MCP server definitions to mcpServers in .claude/settings.json, which is not a documented location for MCP server definitions (project scope belongs in .mcp.json, local scope in ~/.claude.json), so servers registered with it were likely never loaded; use the built-in /mcp or 'claude mcp add' instead. The Codex adapter output (c3 init --platform codex) is unchanged. c3 update offers the two SKILL.md files for deletion.|mcp-config / codex-review skill を削除しました。mcp-config は MCP サーバー定義を .claude/settings.json の mcpServers に書いていましたが、そこは公式に記載された MCP サーバーの置き場所ではなく（プロジェクトスコープは .mcp.json、ローカルは ~/.claude.json）、登録したサーバーは読み込まれていなかった可能性が高いです。MCP サーバーの追加は標準の /mcp または claude mcp add を使ってください。Codex adapter（c3 init --platform codex）の生成物は変更ありません。c3 update 実行時に両 SKILL.md が削除候補として提示されます。

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/deletions.txt

@@ -92,3 +92,7 @@ skills/dev-workflow/scripts/record_tier_outcome.py
 hooks/permission_handler.py
 hooks/permission_handler_toast.py
 permission_rules.json
+
+# ---- v2.80.0: mcp-config / codex-review skill 廃止 ----
+skills/mcp-config/SKILL.md
+skills/codex-review/SKILL.md

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/rules/judgment-principles.md

@@ -1,21 +1,17 @@
 # 判定・検証の判断原則
 
-判定・検証を行う際に守る 3 つの規律。要素は原文の逐語を保持する。
+判定・検証を行う際に守る 3 つの規律。
 
 ## 1. 安全側に倒す
 
 「現状 0 hit だから実装しない」判断はせず、安全側に倒す。
 
-実例: 2026-08-06 のユーザー裁定で、根拠不足のまま省略した判断 2 件を是正し、件数を見ずに沈黙していた判断をさらに 2 件検出した。
-
 ## 2. 到達可能性の判定
 
 到達可能性は「参照 0 件」でなく「発火しうる経路が無い」で判定する（削除・影響判定の規約）。当たるべき経路＝動的ロード / subprocess / 名前写像 / 設定 JSON 登録・monkeypatch 対象の導出タイミング（呼び出し時か import 時か）・ローカル skip テストは「実行されていない」前提で判定・探索ツールの射程を明示する（gitignored 配下は rg で 0 件・grep -rn でヒットし、真偽が道具で反転する）。
 
-実例: 2026-08-13 に同型の誤判定が実働で再演し、CI 5 構成全赤を招いた。
+誤判定は CI の全構成を赤にしうる。
 
 ## 3. 機械走査の 3 点申告
 
 機械走査を名乗るときは 3 点を申告する: (a) 走査対象の形式を全部数えて申告（表行・引用ブロック・見出し・本文） (b) 版順の根拠を明示（ファイル名順とは限らない） (c) 検証が測っている性質を書く（「バイト一致」は書き写しの正確さであって拾う版の正しさではない）。
-
-実例: 2026-08-07 の集約・移設作業で「畳む」工程の取り落としを 3 回連続で実測した。

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/skills/autonomous-mode/SKILL.md

@@ -21,13 +21,13 @@ mode-value       ::= autonomous-decl | "HITL"        ; 行が無い/空/"HITL"
 autonomous-decl  ::= "自律" SP plan-ref [SP cycle-state]
 plan-ref         ::= "plan=" plan-path
 plan-path        ::= abs-path | home-plans-path | quoted-path
-                     ; 委任プランの永続先はリポジトリ外・ハーネス管理領域の絶対パス（DC-AS-001/AM-003）
+                     ; 委任プランの永続先はリポジトリ外・ハーネス管理領域の絶対パス
 abs-path         ::= <OS 絶対パス>            ; 例: <ホームディレクトリ>\.claude\plans\dazzling-cooking-dusk.md
 home-plans-path  ::= "~/.claude/plans/" file  ; 上記の ~ 展開形（可搬表記・~ は $HOME/.claude/plans/ へ展開）
 quoted-path      ::= DQUOTE 1*pchar DQUOTE   ; スペース入りパス対応（例: "<パス>/my plan.md"）
 cycle-state      ::= "cycles=" gate-count *( "," gate-count )   ; 任意・揮発耐性の補助
 gate-count       ::= gate-id "/" 1*DIGIT *("+" 1*DIGIT)         ; 例: C-3/2  E/1  C-3/5+2+1
-gate-id          ::= "C-3" | "E"     ; "E" は E-1+E-2+E-3 を 1 セットとした周回集約 ID。承認ゲート ID の E-3 とは別語彙（DC-GP-004）
+gate-id          ::= "C-3" | "E"     ; "E" は E-1+E-2+E-3 を 1 セットとした周回集約 ID。承認ゲート ID の E-3 とは別語彙
 SP               ::= " "
 LF               ::= "\n"
 DQUOTE           ::= '"'
@@ -78,16 +78,16 @@ D-0（実行モード自動判別）は AskUserQuestion を持たないステッ
 承認ゲート 9 個の集合には含めない。自律モードでも**判別ロジックは不変**（HITL と同じ）で、ゲート付け替えの対象ではない。
 
 **E-0（実行検証判定）は承認ゲートではない**（別枠）: E-0 は AskUserQuestion を持たない判定ステップであり、
-承認ゲート 9 個の集合には含めない。ただし**自律モードでも UNKNOWN・NEEDS_VERIFY は例外なく tester を起動する**（fail-safe 原則・ADR-5/N-2）。
-E-0 起因の差し戻しは E 周回として 1 消費する（CR/SR セットを伴わない周回・ADR-9H）。
+承認ゲート 9 個の集合には含めない。ただし**自律モードでも UNKNOWN・NEEDS_VERIFY は例外なく tester を起動する**（fail-safe 原則）。
+E-0 起因の差し戻しは E 周回として 1 消費する（CR/SR セットを伴わない周回）。
 
 **findings 分岐の固定**（C-3 / E-3 共通）: これら 2 ゲートの findings 分岐 AskUserQuestion には HITL で
 「全て対応する／対応する指摘を選ぶ／全て許容して進む／再監査（再レビュー）」の選択肢があるが、
 **自律モードでは原則「全て対応する」を選ぶ**。「全て許容して進む」を選んでよいのは、
 **C-3 において High/Medium が 0 で Low のみが残ったサイクル（＝C-3 の収束条件を満たした場合）に限る**。
-**この例外は C-3 に限る**。E-3 にはこの例外を適用しない（従来どおり「全て許容」を選ばない）。
+**この例外は C-3 に限る**。E-3 にはこの例外を適用しない（「全て許容」を選ばない）。
 **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 種の生成・評価も行わない。理由: 自律は人間の承認の目が無いため機械監査を厚く保つ。
 
@@ -95,7 +95,7 @@ E-0 起因の差し戻しは E 周回として 1 消費する（CR/SR セット
 
 | サイクルの状態 | 分岐 |
 |---|---|
-| High/Medium が 1 件以上 | 従来どおり「全て対応する」を選ぶ（Low も含めて `[対応予定]`）。層別ルーティングで上流へ戻る＝未収束 |
+| High/Medium が 1 件以上 | 「全て対応する」を選ぶ（Low も含めて `[対応予定]`）。層別ルーティングで上流へ戻る＝未収束 |
 | High/Medium 0・Low が 1 件以上（＝収束） | 残る Low を「全て許容して進む」で処理する。許容理由は「C-3 収束条件（High/Medium 0）を満たしたため、残る Low は実装フェーズ以降で扱う」と記録し、`.claude/skills/dev-workflow/scripts/record_review_decision.py --decision accepted --severity low` で残す（`--severity` は必須引数）。フェーズ D へ進む |
 | findings 0 | そのままフェーズ D へ |
 
@@ -111,6 +111,7 @@ E-0 起因の差し戻しは E 周回として 1 消費する（CR/SR セット
 
 1. **非可逆操作**（git commit/push/tag/release・ファイル削除）は常に人間のまま。
    - **検証用ビルド足場の作成と後始末は含まない**（`git worktree add/remove`・`dist/` 空化・一時ファイル）
+   - **parallel-agents 2-F-2 の wave ごとのローカルコミットは含まない**（plan-report の承認で許可済み。push はしない）
 
 2. **情報不足の質問**（質問出口に人間が必要な場合・下記「質問プロトコル」参照）は人間のまま
 
@@ -126,7 +127,7 @@ E findings の修正も「C 差し戻し → D-2 developer」の正規ルート
 **理由**: 自分のミスの是正であることは、**独立実装レイヤーを外す理由にならない**。
 むしろ直前に判断ミスを示した当人であるほど、独立した実装者を通す価値が高い。
 
-**親の職掌（閉じた列挙）**: 以下 5 種**のみ**が親の直接操作を許される。
+**親の職掌（閉じた列挙）**: 以下 6 種**のみ**が親の直接操作を許される。
 **列挙外のファイル変更**はすべて担当エージェント経由とする（実装・ソースは developer ／ テストコードと test-report は tester）:
 
 1. `.claude/reports/` 配下のうち、**親 Claude がペルソナとして執筆するレポート**（requirements-report / architecture-report / plan-report）の Write。
@@ -139,14 +140,18 @@ E findings の修正も「C 差し戻し → D-2 developer」の正規ルート
 4. `.claude/memory/sessions/*.tmp`（セッションファイル）の更新
 5. `.claude/reports/loop-impl-gaps-*.md`（gaps 台帳）への追記
 6. git 操作のうち**非可逆操作**（commit / push / tag / release・ファイル削除）は**人間の関所 1 の下でのみ**。
-   ただし**検証用ビルド足場は関所の対象外**であり（`git worktree add/remove`・`dist/` 空化・一時ファイル）、親が実施してよい
+   ただし**検証用ビルド足場は関所の対象外**であり（`git worktree add/remove`・`dist/` 空化・一時ファイル）、親が実施してよい。
+   parallel-agents 2-F-2 の wave ごとのローカルコミットも plan-report の承認で許可済みとして親が実施する（push はしない）
 
 **リリース手続きの主体**: CHANGELOG.md の追記は developer 経由
 （`.claude/breaking-changes.txt` / `.claude/deletions.txt` の更新も同じく列挙外＝developer 経由）。
 タグ・push・Release は**人間の関所 1**。
 
-**逸脱時の処置**: まず**親の直接変更を破棄してから再実行する**
-（tracked ファイルは `git checkout -- <path>`／非追跡ファイルは変更前の退避があれば復元し、無ければ関所 2 へ倒して人間の判断を仰ぐ）。
+**逸脱時の処置**: まず**親の直接変更を破棄してから再実行する**。
+破棄は親が加えた変更だけを Edit で逆適用して戻すのを既定とする。
+`git checkout -- <path>` はファイル単位で全差分を消すため、`git diff <path>` に親の変更以外の差分が無いと確認できた場合に限る
+（developer の未コミット成果を巻き込まないため）。非追跡ファイルは変更前の退避があれば復元する。
+いずれも判断できなければ関所 2 へ倒して人間の判断を仰ぐ。
 そのうえでフェーズ別に:
 
 - **D 中の逸脱** → 当該タスクを developer で再実行
@@ -186,12 +191,12 @@ E findings の修正も「C 差し戻し → D-2 developer」の正規ルート
 
 - **理由**: モード行の有効性判定（3 条件）は「plan が構文的に正しく実在するか」しか検証せず、
   **正規のプランモード承認セレモニーを経たかは検証しない**。
-  session.tmp へのモード行挿入自体は親の職掌（item 3）で無条件に許可されているため、
+  session.tmp へのモード行挿入自体は親の職掌（item 4）で無条件に許可されているため、
   判定を通る形のモード行が承認なしに書かれると自律運転が成立してしまう。
-  R1 で走行中の usage 停止を全廃した結果、この場合に**コミット直前まで人間が一度も介在しない**状態まで露出が広がった
+  走行中の usage 停止を行わないため、この場合に**コミット直前まで人間が一度も介在しない**状態まで露出が広がった
 - **限界**: これは文書上の不変則であり**機械的強制ではない**。
-  有効性判定への組み込みは `.claude/skills/autonomous-mode/scripts/mode_line.py` の変更を要し、今回の不変条件（コード変更なし）に反するため採らない。
-  機械的な承認バインドは配布切替タスクまたは独立タスクで扱う
+  有効性判定への組み込みは `.claude/skills/autonomous-mode/scripts/mode_line.py` の変更を要するため、現時点では実装していない（未解決の限界）。
+  機械的な承認バインドは独立タスクで扱う
 
 **設計判断**: 日付跨ぎで自律が自動継続しないのは「揮発耐性」と一見矛盾するが、
 **同一タスクは同日内に完結する運用**であり、かつ「自律の自動継続を跨がせない」ことは
@@ -233,8 +238,7 @@ opt-in は plan-report 生成前（フェーズ A 以前）に行われるため
 
 **不変則**: 親 Claude は**資源同意節を欠くプランで自律 opt-in を成立させてはならない**。欠落を発見した場合は関所 2 へ倒す。
 
-**移行規定**: 本改訂前に承認された委任プランは資源同意節を持たない。改訂後も有効性判定は通るため、
-放置すると「資源同意を一度も取得せず、かつ走行中の停止も廃止された」状態が成立する。したがって
+**復帰時チェック**: 有効性判定は資源同意節の有無を見ないため、資源同意節を持たない委任プランでも判定は通る。したがって
 **復帰のたびに資源同意節の有無を確認する**（init-session 経由でモード行から運転を継続する時）。
 無ければ関所 2 へ倒し、人間の確認を得てから継続する。
 「1 度だけ」を採らないのは、復帰が 1 運転中に何度も起きる（コンパクト・セッション交代）ためであり、
@@ -248,9 +252,9 @@ opt-in は plan-report 生成前（フェーズ A 以前）に行われるため
 コンパクト後も復元するためのフィールド。
 
 - **更新の不変則**: C-3 の各サイクル完了時・E の各周回完了時に、モード行の cycles= を Edit で更新する
-- **表記の拡張**: E→C 差し戻し後の再監査に対応し、`gate-count` を拡張した。初回消費を記録し、差し戻しごとに `+<当該ブロックの消費数>` を末尾に追記する形式（例: `C-3/5+2+1` ＝ 初回 5、差し戻し 1 回目で 2、差し戻し 2 回目で 1 を消費）。この表記により、復帰後の残枠が一意に復元可能になる（差し戻し回数と末尾要素から小上限 2 との差で算出）
+- **表記**: E→C 差し戻し後の再監査に対応するため、`gate-count` は初回消費を記録し、差し戻しごとに `+<当該ブロックの消費数>` を末尾に追記する形式（例: `C-3/5+2+1` ＝ 初回 5、差し戻し 1 回目で 2、差し戻し 2 回目で 1 を消費）。この表記により、復帰後の残枠が一意に復元可能になる（差し戻し回数と末尾要素から小上限 2 との差で算出）
 - **上限の総量規定**: 初回 C-3 は上限 5 サイクル。E 上限が 5 周のため、E→C 差し戻しは最大 4 回発生可能 → 再監査枠は差し戻しごとに上限 2 サイクルの別枠 → 総量の機械的上界は 5 + (4 × 2) = 13 サイクル（無限ループにならない。資源同意節に反映される）
-- **文法と運用の二層関係**: BNF 上は `[SP cycle-state]` で省略可（**文法は無変更**）だが、運用規約上は自律運転中 required とする。スキーマ上 optional・ポリシー上 required という二層関係であり矛盾しない
+- **文法と運用の二層関係**: BNF 上は `[SP cycle-state]` で省略可だが、運用規約上は自律運転中 required とする。スキーマ上 optional・ポリシー上 required という二層関係であり矛盾しない
 - **執行の限界**: ハードリミットの執行点は親 Claude が本 skill の上限（C-3 初回 5 / 差し戻し後 2 / E=5）と突き合わせて判断する。**執行はソフト規約であり機械執行ではない**。cycles= を欠いたまま揮発すると 0 起点で再カウントされる。更新主体と揮発原因がともに親であるため、**更新漏れは構造的に残る**
 - **復帰時チェック（資源同意節と対称）**: **復帰のたびに cycles= の有無を確認する**。欠落していれば関所 2 へ倒す。欠落は検出できるが**値の正しさは検証できない**
 
@@ -280,7 +284,7 @@ opt-in は plan-report 生成前（フェーズ A 以前）に行われるため
   C-3 でも同じ規律を適用し、収束判定の前に **design-review-report の High/Medium 件数**を本文から数え直してサマリ表の数値と突合する。
   さらに C-3 では、件数の数え直しに加えて **High/Medium 0 と判定したサイクルに限り**、
   **Low に落ちている findings の重要度が妥当か**を親が 1 度確認する。妥当性に疑義があれば**収束させず次サイクルへ回す**。
-  これは R3（収束条件を High/Medium 0 へ緩和）が受容したトレードオフに対する唯一の担保であり、
+  これは収束条件を High/Medium 0 としたことに伴うトレードオフに対する唯一の担保であり、
   design-critic の重要度付与が粗く、本来 High のものが Medium/Low に落ちて収束が早まる事態を防ぐためのもの
 
 - **対応案の前提裏取り**: 裏取りの対象は、(a) レビューが提示した対応案の理由文に現れる事実主張、**(b) 親 Claude 自身が新設する是正策・検査・成功条件・テスト仕様が依拠する事実主張（規約・設計文書に書く事実主張を含む）** の両方とする
@@ -305,8 +309,7 @@ opt-in は plan-report 生成前（フェーズ A 以前）に行われるため
 
 ## 実装・レビューの必須チェック
 
-設計フェーズ B で確定した以下 3 一般則の執行を skill 内規約として明記する。
-詳細はリンク先を参照:
+以下 3 一般則を実装・レビューで執行する。
 
 ### (a) NUL 境界
 
@@ -317,14 +320,10 @@ opt-in は plan-report 生成前（フェーズ A 以前）に行われるため
 - 宣言マーカー: `# nul-boundary: allow(<理由>)` を対象コードの行末に配置
 - ユーザー向け説明: `.claude/docs/nul-boundary.md` — マーカーの書き方・配置規則・既知の限界 L-1〜L-7
 
-参照:
-- auto-memory `feedback_nul_boundary_for_machine_readable_line_sets` — 一般則の背景と理由（6 例の履歴）
-- architecture-report §2-5 / §5 — 設計詳細・言語学的背景・トレードオフ
-
-### (b) パス用 choke point（新規防御）
+### (b) パス用 choke point
 
 `plan-path` を `Read` 引数に使う前に、以下の**パス用封じ込め型防御**を実装・適用する
-（表示用 SR L-2 とは別の独立した choke point・本 feature 唯一の新規発火点）:
+（表示用サニタイズとは別の独立した choke point）:
 
 1. 改行・NUL・制御文字を検出したら無効化する
 2. `plan-path` を絶対パスへ正規化（`realpath` 相当・シンボリックリンク解決・`..` 解決）する
@@ -341,18 +340,7 @@ opt-in は plan-report 生成前（フェーズ A 以前）に行われるため
 → `VALID<TAB>{正規化済み絶対パス}`（exit 0）／`INVALID<TAB>{理由コード}`（exit 1）の 1 行と exit code で判定する。
 モード行の値をコマンド文字列（here-string・引数・ダブルクォート内展開）に直接埋め込んではならない。
 
-### (c) 表示用 choke point（既存 SR L-2 の再利用）
+### (c) 表示用 choke point（init-session と共通の表示用サニタイズ）
 
-`モード:` 行の値をユーザーへ表示する全出口で SR L-2 サニタイズを適用する
+`モード:` 行の値をユーザーへ表示する全出口で表示用サニタイズを適用する
 （C0/C1・DEL・改行・`-->`・U+2028/U+2029 除去）。
-
----
-
-## 相互参照（配布元限定）
-
-`.dev/loop/README.md` と本 skill は、同じ原理（客観収束・二重上限・人間の関所）の 2 実装である:
-
-- **ハーネス**（`.dev/loop/`）= 餌駆動の簡易ワークフロー（headless・claude -p・応答者不在前提。**配布元限定のツール・gitignored**）
-- **本 skill**（autonomous-mode）= C3 標準ワークフロー（対話セッション・親 Claude・質問出口は人間）
-
-`.dev/loop/README.md` にもこの相互参照を明記すること（両側に記す）。

{claude_code_conductor-2.78.0 → claude_code_conductor-2.80.0}/.claude/skills/brainstorm/SKILL.md

@@ -65,7 +65,7 @@ user-invocable: true
 
 ## Step 2: 理解を確認する（軽く）
 
-資料を読んだら、内容を **1〜3 行**に要約し「こういう理解で合っていますか？」と確認する。
+資料を読んだら、要点を短くまとめて「こういう理解で合っていますか？」と確認する。
 ここで細部を詰めすぎない（発散モードなので、ざっくり合っていれば先へ進む）。
 
 ---