claude-code-conductor 2.63.0__tar.gz → 2.65.0__tar.gz

{claude_code_conductor-2.63.0 → claude_code_conductor-2.65.0}/.claude/agents/architect.md

@@ -35,12 +35,14 @@ requirements-report を受け取り、システム設計・技術選定・依存
 
 **Before:**
 - requirements-report を Read する
-- 既存コードがあれば Glob / Grep で構造を把握する
+- 採用する対策・パターンと同種の対策が過去に破られていないか、reviewer 系の agent-memory を確認する（agent-memory は gitignored でありディレクトリ横断の検索は空振りする。対象ファイルを列挙してから個別に読む）
 
 **During:**
 - 技術選定の根拠とトレードオフを必ず記録する
 - 複数案がある場合は比較表を作り採用理由を明示する
 - 不明点はユーザーに確認する
+- 対策・不変則は判定手段でなく満たすべき性質で書く（手段の固定は射程を縮める）
+- 対策・規約の配置先を決めるときは `.claude/skills/dev-workflow/references/reachability-map.md` で読み手に届くかを確認する
 
 **After:**
 - Skill ツールで `report-timestamp` を呼び出してタイムスタンプを取得し、Write ツールで `.claude/reports/architecture-report-{timestamp}.md` に出力する

{claude_code_conductor-2.63.0 → claude_code_conductor-2.65.0}/.claude/agents/developer.md

@@ -43,7 +43,6 @@ plan-report に基づき実装・デバッグ・リファクタリングを行
 
 **Before:**
 - plan-report を Read して実装対象タスクを確認する
-- 既存コードを Glob / Grep で把握する
 
 **During:**
 - 1タスク = 1コミットの粒度を保つ

{claude_code_conductor-2.63.0 → claude_code_conductor-2.65.0}/.claude/agents/doc-writer.md

@@ -36,7 +36,6 @@ tools:
 
 **Before:**
 - プロンプトに含まれる要件（種類・読み手・目的・粒度・対象・出力先）を確認する
-- Glob / Grep で対象ファイル・ディレクトリの構造を把握する
 - Read で関連ファイルを読み込む（大規模な場合は優先度の高いファイルから）
 
 **During:**

{claude_code_conductor-2.63.0 → claude_code_conductor-2.65.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〜15 と R2〜R6 を遵守する（適用射程は同ファイル冒頭の分類表に従う。`"sequential"` プランでは並列前提ルールを適用しない）
+- `.claude/skills/dev-workflow/references/plan-design-guidelines.md` のルール 1〜20 と R2〜R6 を遵守する（適用射程は同ファイル冒頭の分類表に従う。`"sequential"` プランでは並列前提ルールを適用しない）
 
 **After:**
 - Skill ツールで `report-timestamp` を呼び出してタイムスタンプを取得し、Write ツールで `.claude/reports/plan-report-{timestamp}.md` に出力する
@@ -58,7 +58,7 @@ 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〜15 と自己チェックリストに違反した plan-report を出力しない（適用射程は分類表に従う）
+- `.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 ブロック

{claude_code_conductor-2.63.0 → claude_code_conductor-2.65.0}/.claude/agents/security-reviewer.md

@@ -41,7 +41,6 @@ SQLインジェクション・XSS・認証認可・秘密情報漏洩などの
 ## Workflow
 
 **Before:**
-- 変更ファイルと依存関係を Bash / Glob / Grep で確認する
 - 認証・外部入力・データベースアクセスのコードを優先的に確認する
 - `.claude/skills/dev-workflow/references/security-review-checklist.md` を Read してチェック観点を確認する
 

{claude_code_conductor-2.63.0 → claude_code_conductor-2.65.0}/.claude/agents/systematic-debugger.md

@@ -63,13 +63,11 @@ developer が詰まった問題の根本原因を調査し、debug-analysis-repo
 - エラーに関連する変更がないか調べる
 
 **2-4: 関連コードの読み込み**
-- Glob / Grep / Read でエラー箇所周辺のコードを調査する
 - 依存関係・呼び出し元を辿る
 
 ### Step 3: Phase 2 - パターン分析
 
 **3-1: 動いている類似コードを探す**
-- Grep / Glob で同様のパターンを実装している箇所を探す
 - 動いているコードと壊れているコードの両方を Read する
 
 **3-2: 差分の特定**
@@ -107,7 +105,7 @@ Skill ツールで `report-timestamp` を呼び出してタイムスタンプを
 ```
 
 ## Tools & Constraints
-- コードを修正・編集しない（Read / Bash / Glob / Grep / Write のみ使用）
+- コードを修正・編集しない（`memory:` 付き agent には Edit が実行時に自動付与されるため、frontmatter ではなく本規約が唯一の担保）
 - 推測で原因を断言しない。再現コマンドの出力など証拠に基づいて記述する
 - 推奨仮説は1つに絞る（複数の仮説を羅列しない）
 

{claude_code_conductor-2.63.0 → claude_code_conductor-2.65.0}/.claude/agents/wt_developer.md

@@ -17,7 +17,7 @@ tools:
 
 # Developer (worktree-parallel)
 
-> **v2.2.0+**: 本 agent は `parallel-agents` skill が `isolation: "worktree"` 付きで起動する **並列実行専用** バリアント。`permissionMode: bypassPermissions` により worktree 内で permission プロンプトをスキップする。worktree 外への書き込みは `.claude/hooks/worktree_guard.py` (PreToolUse, `PO_WORKTREE_GUARD=1`) でガードされる。
+> 本 agent は `parallel-agents` skill が `isolation: "worktree"` 付きで起動する **並列実行専用** バリアント。`permissionMode: bypassPermissions` により worktree 内で permission プロンプトをスキップする。worktree 外への書き込みは `.claude/hooks/worktree_guard.py` (PreToolUse, `PO_WORKTREE_GUARD=1`) でガードされる。
 >
 > 単発起動（`/develop` フェーズ D-1〜D-5 等、`isolation` なし）では本 agent を**使わない**。元の `developer` agent を使うこと。
 
@@ -48,7 +48,6 @@ plan-report に基づき実装・デバッグ・リファクタリングを行
 
 **Before:**
 - plan-report を Read して実装対象タスクを確認する
-- 既存コードを Glob / Grep で把握する
 
 **During:**
 - 1タスク = 1コミットの粒度を保つ

{claude_code_conductor-2.63.0 → claude_code_conductor-2.65.0}/.claude/agents/wt_systematic-debugger.md

@@ -15,7 +15,7 @@ tools:
 
 # Systematic Debugger (worktree-parallel)
 
-> **v2.2.0+**: 本 agent は `parallel-agents` skill が `isolation: "worktree"` 付きで起動する **並列実行専用** バリアント。`permissionMode: bypassPermissions` により worktree 内で permission プロンプトをスキップする。worktree 外への書き込みは `.claude/hooks/worktree_guard.py` (PreToolUse, `PO_WORKTREE_GUARD=1`) でガードされる。
+> 本 agent は `parallel-agents` skill が `isolation: "worktree"` 付きで起動する **並列実行専用** バリアント。`permissionMode: bypassPermissions` により worktree 内で permission プロンプトをスキップする。worktree 外への書き込みは `.claude/hooks/worktree_guard.py` (PreToolUse, `PO_WORKTREE_GUARD=1`) でガードされる。
 >
 > 単発起動（worktree なしで親 Claude から直接 Agent ツールで起動するケース等）では本 agent を**使わない**。元の `systematic-debugger` agent を使うこと。
 
@@ -68,13 +68,11 @@ developer が詰まった問題の根本原因を調査し、debug-analysis-repo
 - エラーに関連する変更がないか調べる
 
 **2-4: 関連コードの読み込み**
-- Glob / Grep / Read でエラー箇所周辺のコードを調査する
 - 依存関係・呼び出し元を辿る
 
 ### Step 3: Phase 2 - パターン分析
 
 **3-1: 動いている類似コードを探す**
-- Grep / Glob で同様のパターンを実装している箇所を探す
 - 動いているコードと壊れているコードの両方を Read する
 
 **3-2: 差分の特定**
@@ -112,7 +110,7 @@ developer が詰まった問題の根本原因を調査し、debug-analysis-repo
 ```
 
 ## Tools & Constraints
-- コードを修正・編集しない（Read / Bash / Glob / Grep / Write のみ使用）
+- コードを修正・編集しない（`memory:` 付き agent には Edit が実行時に自動付与されるため、frontmatter ではなく本規約が唯一の担保）
 - 推測で原因を断言しない。再現コマンドの出力など証拠に基づいて記述する
 - 推奨仮説は1つに絞る（複数の仮説を羅列しない）
 

{claude_code_conductor-2.63.0 → claude_code_conductor-2.65.0}/.claude/agents/wt_tester.md

@@ -15,7 +15,7 @@ tools:
 
 # Tester (worktree-parallel)
 
-> **v2.2.0+**: 本 agent は `parallel-agents` skill が `isolation: "worktree"` 付きで起動する **並列実行専用** バリアント。`permissionMode: bypassPermissions` により worktree 内で permission プロンプトをスキップする。worktree 外への書き込みは `.claude/hooks/worktree_guard.py` (PreToolUse, `PO_WORKTREE_GUARD=1`) でガードされる。
+> 本 agent は `parallel-agents` skill が `isolation: "worktree"` 付きで起動する **並列実行専用** バリアント。`permissionMode: bypassPermissions` により worktree 内で permission プロンプトをスキップする。worktree 外への書き込みは `.claude/hooks/worktree_guard.py` (PreToolUse, `PO_WORKTREE_GUARD=1`) でガードされる。
 >
 > 単発起動（`/develop` フェーズ D-1〜D-5 等、`isolation` なし）では本 agent を**使わない**。元の `tester` agent を使うこと。
 

{claude_code_conductor-2.63.0 → claude_code_conductor-2.65.0}/.claude/skills/autonomous-mode/SKILL.md

@@ -27,7 +27,7 @@ home-plans-path  ::= "~/.claude/plans/" file  ; 上記の ~ 展開形（可搬
 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 を 1 セットとした周回集約 ID。承認ゲート E-1/E-2 とは別語彙（DC-GP-004）
+gate-id          ::= "C-3" | "E"     ; "E" は E-1+E-2+E-3 を 1 セットとした周回集約 ID。承認ゲート ID の E-3 とは別語彙（DC-GP-004）
 SP               ::= " "
 LF               ::= "\n"
 DQUOTE           ::= '"'
@@ -57,7 +57,7 @@ pchar            ::= <all printable chars except DQUOTE>
 
 ## ゲート対応表（SSOT 本体）
 
-承認ゲート **10 個**（**A-4 / B-3 / C-1 / C-2 / C-3 / D-2.5 / D-3 / D-5 / E-1 / E-2**）の動作対応。
+承認ゲート **9 個**（**A-4 / B-3 / C-1 / C-2 / C-3 / D-2.5 / D-3 / D-5 / E-3**）の動作対応。
 D-0（実行モード自動判別）は AskUserQuestion を持たないステップのため承認ゲート集合に含めない（別枠注記）。
 
 | ゲート | HITL（既定） | 自律モード |
@@ -70,23 +70,22 @@ D-0（実行モード自動判別）は AskUserQuestion を持たないステッ
 | **D-2.5** | テスト承認 | **テスト全緑まで自動**（stuck 時は systematic-debugger 経由も自動）。全緑が客観条件 |
 | **D-3** | テスト承認 | **テスト全緑まで自動**（stuck 時は systematic-debugger 経由も自動）。全緑が客観条件 |
 | **D-5** | テスト承認 | **テスト全緑まで自動**（stuck 時は systematic-debugger 経由も自動）。全緑が客観条件 |
-| **E-1** | CR 承認 | **CR∥SR は「起動」のみ並列**。findings 分岐は**必ず「全て対応する」に固定**（「全て許容」は選ばない）。**High・Medium 0 まで自動ループ（上限 5 周・周回数カウント）** |
-| **E-2** | SR 承認 | **CR∥SR は「起動」のみ並列**。findings 分岐は**必ず「全て対応する」に固定**（「全て許容」は選ばない）。**High・Medium 0 まで自動ループ（上限 5 周・周回数カウント）** |
+| **E-3** | CR・SR 統合裁定 | **CR∥SR は「起動」のみ並列**。両レポート完了後の統合裁定で findings 分岐は**必ず「全て対応する」に固定**（「全て許容」は選ばない）。**High・Medium 0 まで自動ループ（上限 5 周・周回数カウント）** |
 
 #### 注記と例外
 
 **D-0（実行モード自動判別）は承認ゲートではない**（別枠）: D-0 は AskUserQuestion を一切持たない Glob/Bash 判定ステップであり、
-承認ゲート 10 個の集合には含めない。自律モードでも**判別ロジックは不変**（HITL と同じ）で、ゲート付け替えの対象ではない。
+承認ゲート 9 個の集合には含めない。自律モードでも**判別ロジックは不変**（HITL と同じ）で、ゲート付け替えの対象ではない。
 
 **E-0（実行検証判定）は承認ゲートではない**（別枠）: E-0 は AskUserQuestion を持たない判定ステップであり、
-承認ゲート 10 個の集合には含めない。ただし**自律モードでも UNKNOWN・NEEDS_VERIFY は例外なく tester を起動する**（fail-safe 原則・ADR-5/N-2）。
+承認ゲート 9 個の集合には含めない。ただし**自律モードでも UNKNOWN・NEEDS_VERIFY は例外なく tester を起動する**（fail-safe 原則・ADR-5/N-2）。
 E-0 起因の差し戻しは E 周回として 1 消費する（CR/SR セットを伴わない周回・ADR-9H）。
 
-**findings 分岐の固定**（C-3 / E-1 / E-2 共通）: これら 3 ゲートの findings 分岐 AskUserQuestion には HITL で
+**findings 分岐の固定**（C-3 / E-3 共通）: これら 2 ゲートの findings 分岐 AskUserQuestion には HITL で
 「全て対応する／対応する指摘を選ぶ／全て許容して進む／再監査（再レビュー）」の選択肢があるが、
 **自律モードでは原則「全て対応する」を選ぶ**。「全て許容して進む」を選んでよいのは、
 **C-3 において High/Medium が 0 で Low のみが残ったサイクル（＝C-3 の収束条件を満たした場合）に限る**。
-**この例外は C-3 に限る**。E-1 / E-2 にはこの例外を適用しない（従来どおり「全て許容」を選ばない）。
+**この例外は C-3 に限る**。E-3 にはこの例外を適用しない（従来どおり「全て許容」を選ばない）。
 **High/Medium を許容で流すことは引き続き構造的に禁じる**（空収束防止）。
 許容という価値判断がこの例外に当てはまらない場合は、従来どおり**人間の関所へエスカレーション**する。
 
@@ -101,7 +100,7 @@ E-0 起因の差し戻しは E 周回として 1 消費する（CR/SR セット
 | findings 0 | そのままフェーズ D へ |
 
 **cycles_used の定義**: E は**周回数**。CR∥SR 並列 1 セット＋修正＝1 サイクル。
-`cycles=` トークンの `E` は E-1+E-2 を 1 セットとした周回集約 ID（承認ゲート ID の E-1/E-2 とは別語彙）。
+`cycles=` トークンの `E` は E-1+E-2+E-3 を 1 セットとした周回集約 ID（承認ゲート ID の E-3 とは別語彙）。
 
 **上限到達時**: 途中成果を保全（ワーキングツリー・レポート群）した状態で人へ報告（調査可能な形）。
 収束 or 打ち切りで初めてまとめて報告（逐一停止しない）。
@@ -156,12 +155,15 @@ E findings の修正も「C 差し戻し → D-2 developer」の正規ルート
 
 いずれの場合も gaps 台帳へ 1 行記録する。
 
-#### E-1/E-2 の並列と合流点（join）
+#### E-3（CR・SR 統合）の実行フロー
 
+- **E-1 と E-2** は起動・hint 注入のみで、承認ゲートとしての判定は持たない
+- **E-3** は code-reviewer と security-reviewer の両実行が完了した後に実行される統合裁定ゲート
 - CR∥SR は「起動」のみ並列し、両 reviewer が完了した後に以下を所定順で逐次実行:
-  1. `review_hint_inject.py` に**CR・SR 両レポートのパス**を渡して呼ぶ（両レポート必須のため join 後）
+  1. E-2 で `review_hint_inject.py` に**CR・SR 両レポートのパス**を渡して呼ぶ（両レポート必須のため join 後）
   2. 重複指摘フラグ判定（同上・両レポートが揃ってから）
-  3. tier-routing 記録は**E-1 / E-2 それぞれ個別の gate**（`--gate E-1` / `--gate E-2`）で各 reviewer 分をそれぞれ呼ぶ
+  3. **E-3 統合裁定**: 両レポートの指摘を統合して 1 度だけ判定する
+  4. tier-routing 記録は**E-1 / E-2 それぞれ個別の gate**（`--gate E-1` / `--gate E-2`）で各 reviewer 分をそれぞれ呼ぶ（CR failure は E-1・SR failure は E-2。**CR・SR いずれか一方に findings が無い場合、その出所のゲートへは failure を記録しない**）
 
 #### 引き継ぎバックログ照合（E 最終承認後・コミット直前）