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

{claude_code_conductor-2.80.0 → claude_code_conductor-2.82.0}/.claude/agents/design-critic.md

@@ -20,7 +20,7 @@ tools:
 ## Memory
 - 作業終了時、次回以降の監査に役立つ知見があれば `.claude/agent-memory/design-critic/MEMORY.md` に追記する。記録対象は以下に限定する:
   - 実際に手戻りを起こした**前提崩れ・曖昧さ・抜け漏れの型**（次回の 3 レンズ適用で優先的に当てる観点）
-  - **許容例外**: ユーザーが `[許容]` と裁定した finding の観点と理由（`[許容例外]` プレフィックスを付ける。C-3 の裁定は c3.db にも記録されるが、それを後付けで差し戻す review-hint は CR / SR 専用で design-critic には届かないため、次回の再指摘を防げるのはこの MEMORY.md だけ）
+  - **許容例外**: ユーザーが `[許容]` と裁定した finding の観点と理由（`[許容例外]` プレフィックスを付ける。C-3 の裁定は c3.db にも記録されるが、それを後付けで差し戻す review-hint は CR / SR 専用で design-critic には届かないため、次回の再指摘を防げるのはこの MEMORY.md だけ）。学習するのはユーザーが裁いた `[許容]` に限る。`[退ける]`（裏取りで偽と確かめた指摘）と、自律モードで親が付けた `[許容]`（理由が `自律:` で始まるもの）は学習しない
   - 本プロジェクトで繰り返す**起因層の偏り**（`A要件` / `B設計` / `C計画` のどこが弱いか）と、それを突くのに効いた定型チェック
 - 雑記録・一回性の進捗ログは記録しない。1 エントリ 1 行で簡潔に書き、MEMORY.md 全体は 200 行 / 25KB 以内に保つ（超過分は起動時に読まれない・超えたら価値の低いエントリから削除する）。
 
@@ -29,7 +29,7 @@ tools:
 ✅ 担当すること:
 - requirements-report / architecture-report / plan-report の監査
 - 3 レンズ（前提発掘 / 曖昧さ / 抜け漏れ）による finding 抽出
-- 各 finding への重要度・起因層・該当箇所の付与
+- 各 finding への重要度・起因層・主張の種類・根拠・該当箇所の付与
 - design-review-report の出力
 
 ❌ 担当しないこと:
@@ -50,13 +50,8 @@ tools:
 
 **During:**
 - ルーブリックの 3 レンズ（前提発掘 `[DC-AS-NNN]` / 曖昧さ `[DC-AM-NNN]` / 抜け漏れ `[DC-GP-NNN]`）を順に適用する
-- この段階の役割は**網羅（coverage）であり取捨選択ではない**。確信度が低い finding・Low 重要度の finding も握り潰さず report する。重要度による最終的な絞り込みは下流（ユーザー承認・層別ルーティング）に委ねる
-- 各 finding に必須付与する項目（詳細は `.claude/skills/dev-workflow/references/design-critic-rubric.md` の「Finding 必須項目」セクションを参照）:
-  - **重要度**: High（このまま実装すれば確実に手戻り）/ Medium（解釈次第で手戻り）/ Low（改善余地）
-  - **起因層**: `A要件` / `B設計` / `C計画`（層別ルーティングの判定キー）
-  - **該当箇所**: どのレポートのどのセクションか
-  - **問題点**: 何が問題か・なぜリスクか
-  - **実装前に確認・修正すべきこと**: 解消するために必要なアクション
+- この段階の役割は**網羅（coverage）であり取捨選択ではない**。確信度が低い finding・Low 重要度の finding も握り潰さず report する。最終的な絞り込みは下流（親 Claude の裏取りと区分・ユーザーの裁定。dev-workflow C-3 ステップ 3）に委ねる
+- 各 finding に、`.claude/skills/dev-workflow/references/design-critic-rubric.md` の「Finding 必須項目」セクションの 7 項目（重要度・起因層・主張の種類・根拠・該当箇所・問題点・実装前に確認・修正すべきこと）を付与する。重要度・主張の種類の定義は同セクションが正本である。`現物` の主張は Read / Glob / Grep で確かめたファイルと行を根拠に書き、確かめられなければ「未確認」と書く（確かめられないことは report を見送る理由にしない）
 - findings が出なかった場合は「findings なし」として明記し、その旨 report に記載する
 
 **After:**
@@ -68,4 +63,4 @@ tools:
 ## Related Agents
 - 上流: planner（plan-report を受け取る）
 - ピア: code-reviewer / security-reviewer（同じ監査型エージェント。design-critic はフェーズ C-3 で設計監査、code-reviewer / security-reviewer はフェーズ E でコード・セキュリティ監査を独立稼働）
-- 下流: 親 Claude（C-3 ゲート: findings の承認フロー・層別ルーティングを担う）→ 起因層に応じて interviewer / architect / planner へルーティング
+- 下流: 親 Claude（C-3 ゲート: findings の裏取り・区分・裁定と層別ルーティングを担う）→ 起因層に応じて interviewer / architect / planner へルーティング

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

@@ -10,11 +10,6 @@ tools:
   - Bash
   - Glob
   - Grep
-  - TodoWrite
-  - TaskCreate
-  - TaskUpdate
-  - TaskList
-  - TaskGet
   - Skill
 ---
 

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

@@ -11,11 +11,6 @@ tools:
   - Bash
   - Glob
   - Grep
-  - TodoWrite
-  - TaskCreate
-  - TaskUpdate
-  - TaskList
-  - TaskGet
   - Skill
 ---
 

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

@@ -96,3 +96,6 @@ permission_rules.json
 # ---- v2.80.0: mcp-config / codex-review skill 廃止 ----
 skills/mcp-config/SKILL.md
 skills/codex-review/SKILL.md
+
+# ---- v2.82.0: C-3省略宣言プロトコル廃止（E→C 差し戻し時の C-3 判定へ置換） ----
+skills/dev-workflow/references/c3-omission-declaration.md

{claude_code_conductor-2.80.0 → claude_code_conductor-2.82.0}/.claude/docs/autonomous-mode-onboarding.md

@@ -64,7 +64,7 @@ C3 の「自律モード（autonomous mode）」を初めて使う人向けの
 
 自律運転は無限に回らない。C-3 監査・E レビューにはサイクル上限があり、到達すると次の流れで止まる。
 
-1. **上限到達**（例: C-3 が上限サイクルまで回っても High/Medium が 0 に収束しない）
+1. **上限到達**（例: C-3 が上限サイクルまで回っても、収束の判定〔dev-workflow の C-3 ステップ 5〕を満たさない）
 2. **状態保全**: ワーキングツリー・レポート群をそのまま残す（調査可能な形で保全）
 3. **報告**: 収束または打ち切りで初めてまとめて人間へ報告する（逐一停止はしない）
 4. **裁定**: 人間が続行・方針変更・打ち切りを判断する
@@ -81,8 +81,9 @@ C3 の「自律モード（autonomous mode）」を初めて使う人向けの
 **C-3 監査が収束しても、それは「欠陥がゼロになった」ことを意味しない。**
 C-3 の収束条件が保証する射程は、**その時点の計画の健全性**に限られる。
 
-- **実測の裏付け**: C-3 が収束（High/Medium 0）した後の E レビューで、実装バグが実際に発見された事例がある。
-  収束は「設計・計画レベルで High/Medium の指摘が消えた」ことであって、実装が正しいことの証明ではない。
+- **実測の裏付け**: C-3 が収束した後の E レビューで、実装バグが実際に発見された事例がある（当時の収束は High/Medium 0 件の判定だった）。
+  収束の判定は現在、件数でなく根本解決の反映と実装を止める項目の有無で行う（正本: dev-workflow の C-3 ステップ 5、autonomous-mode のゲート対応表 C-3 行）。
+  いずれにせよ収束は設計・計画レベルの健全性であって、実装が正しいことの証明ではない。
 - **構造的な限界**: C-3 を担う design-critic は **Bash を持たず、コードを実行して検証できない**
   （静的な読解のみ）。エスケープ処理・パーサ・状態機械のような組み合わせロジックの欠陥は、
   静的読解では原理的に取りこぼしうる。

{claude_code_conductor-2.80.0 → claude_code_conductor-2.82.0}/.claude/docs/parallel-agents-setup.md

@@ -16,7 +16,7 @@ C3 の `parallel-agents` skill（`/develop` から間接起動）を快適に使
 
 | 項目 | 推奨値 | 既定との差 |
 |---|---|---|
-| Claude Code バージョン | **2.1.150 以降** | 古いと auto-cleanup 不在 |
+| Claude Code バージョン | **2.1.295 以降**（C3 全体の下限。README の「前提条件」を参照。worktree auto-cleanup が安定するのは 2.1.150 以降で、下限を満たせばこちらも満たす） | 2.1.150 未満だと auto-cleanup 不在 |
 | `worktree.baseRef` | **`"head"`** | 既定は `"fresh"` (= `origin/<default>` から作成) |
 
 設定しなくても skill 自体は動くが、以下の問題に遭遇しやすくなる:
@@ -83,7 +83,11 @@ parallel-agents は「直近の修正を反映した worktree で並列実装さ
 
 ## Claude Code バージョン要件
 
-### 2.1.150 以降を推奨する理由
+### 2.1.150 以降が必要な理由（worktree auto-cleanup）
+
+C3 全体の下限は 2.1.295 であり（README の「前提条件」を参照）、下限を満たす環境では
+以下の 2.1.150 条件も常に満たされる。ここでは parallel-agents に関わる 2.1.150 の
+意味だけを説明する。
 
 `isolation: "worktree"` 付き Agent が **完了時に worktree を auto-cleanup** する
 挙動が安定したのが 2.1.150 系。これにより:
@@ -95,7 +99,7 @@ parallel-agents は「直近の修正を反映した worktree で並列実装さ
 2.1.150 未満の場合、SKILL.md Step 2-F-3 のフォールバック手順
 （`git worktree remove -f -f` + `git branch -D worktree-agent-<id>`）が
 **毎回必要** になる。dead worktree が積み重なるとパフォーマンス・容量への
-影響もあるため、可能ならアップグレードを推奨する。
+影響もあるため、アップグレードを推奨する（C3 の下限 2.1.295 を満たせば不要）。
 
 ### auto-cleanup の信頼度
 

{claude_code_conductor-2.80.0 → claude_code_conductor-2.82.0}/.claude/docs/settings.json.md

@@ -190,6 +190,7 @@ Claude Code のイベントに対してフックを登録する。マッチし
 | `hooks[].type` | フックの種類（下記参照） |
 | `hooks[].if` | フックレベルの追加フィルタ。許可ルール構文（`Bash(git *)`、`Edit(*.ts)` 等）。ツールイベントのみ有効 |
 | `hooks[].timeout` | タイムアウト秒数。デフォルト 600秒（10分） |
+| `hooks[].onFailure` | hook 自体の失敗時の扱い。`"continue"`（既定）/ `"block"`。command / http hook で使える。Claude Code 2.1.295 以降（下記 `command` と「終了コードによる動作」を参照） |
 
 ---
 
@@ -203,6 +204,21 @@ Claude Code のイベントに対してフックを登録する。マッチし
 { "type": "command", "command": "python script.py" }
 ```
 
+| フィールド | 説明 |
+|---|---|
+| `command` | 実行するコマンド |
+| `args` | 引数の配列。指定すると `command` をシェルを介さず実行する（exec 形式。C3 の登録はすべてこの形式） |
+| `onFailure` | hook 自体が失敗したとき（起動できない・タイムアウト・0 と 2 以外の終了コード）の扱い。`"continue"`（既定）は失敗を通知して続行する。`"block"` は exit 2 と同じ扱いでアクションをブロックする。Claude Code 2.1.295 以降 |
+
+```json
+{
+  "type": "command",
+  "command": "c3",
+  "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/pre_tool.py"],
+  "onFailure": "block"
+}
+```
+
 #### `http`
 
 イベントデータを HTTP エンドポイントに POST する。
@@ -252,8 +268,32 @@ Claude Code のイベントに対してフックを登録する。マッチし
 | `2` | アクションをブロック。stderr の内容が Claude へのフィードバックになる。ブロック不可イベントでは stderr をユーザーに表示し続行 |
 | その他 | 続行。トランスクリプトに `<hook name> hook error` 通知 + stderr 1行目を表示 |
 
+> **`onFailure: "block"` のエントリ**: 0 と 2 以外の終了コード・起動失敗・タイムアウトは exit 2 と同じ扱い（アクションをブロックし、stderr が Claude へのフィードバックになる）。このときエラーには `PreToolUse:Bash hook error: [<hook のコマンド>]: failed; blocking because onFailure is "block"` のように、イベント名・ツール名・失敗した hook のコマンドが出る。onFailure 未指定（`"continue"`）では上表「その他」のとおり続行する。
+
 > **注意**: exit 2 と JSON 出力を混在させないこと。Claude Code は exit 2 時に JSON を無視する。
 
+### C3 の `onFailure` 方針
+
+(i) **onFailure: "block" を付けている hook**（`.claude/settings.json` の PreToolUse・7 エントリ）:
+
+| hook | matcher |
+|---|---|
+| `pre_tool.py` | `Bash` |
+| `worktree_guard.py` | `Write` / `Edit` |
+| `patterns_guard.py` | `Write` / `Edit` |
+| `report_path_guard.py` | `Write` |
+| `check_agent_invocation.py` | `Agent` |
+
+(ii) **判断基準**: 安全境界（破壊的コマンド・secret・書き込み先・reviewer の起動条件などの関所）の PreToolUse hook に付ける。hook 自体が失敗したときに関所を素通りさせないため。利便用の hook（例: `tier_autoapply.py`）や、失敗時に全操作を止めてしまう hook（UserPromptSubmit 系など）には付けない。PostToolUse は実行後のため、Stop 系は効果が無いため付けない。対象外の hook には `"continue"` も書かず、キー自体を省略する。
+
+(ii-a) **onFailure が拾う範囲**: 拾うのは hook 自体の失敗（起動不能・0 と 2 以外の終了コード・タイムアウト・不正な JSON 出力）である。hook が意図して exit 0 で通す入力（stdin の JSON の解析失敗など）は失敗ではないため対象外で、そのまま通過する。
+
+(ii-b) **block 対象に hook を加えるときの確認**: block 時は stderr 全文が Claude に渡るため、その hook が例外時に stderr へ機密（トークン・環境変数・ファイル内容など）を出さないことを確認する。
+
+(iii) **自分の hook に付けるかの指針**: `settings.local.json` 等に登録した自分の PreToolUse hook が「失敗時に通すと困る関所」なら `"block"` を付け、「失敗しても作業を続けたい補助」なら付けない。
+
+分類の正本は C3 開発リポジトリの `tests/test_settings_hooks_registration.py`（配布物には含まれない）にある閉じた分類表で、配布元が `.claude/settings.json` の PreToolUse の全 hook を「block 対象」か「非対象」に分類して機械検査している。`c3 run` で起動される hook は、`c3` が見つからない（venv が activate されていない等）と起動に失敗するため、上記の hook が付いたツール（Bash / Write / Edit / Agent）がブロックされる。対処は README の「前提条件」を参照。
+
 ---
 
 ### 構造化 JSON 出力（exit 0 + stdout）

{claude_code_conductor-2.80.0 → claude_code_conductor-2.82.0}/.claude/settings.json

@@ -70,7 +70,8 @@
           {
             "type": "command",
             "command": "c3",
-            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/pre_tool.py"]
+            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/pre_tool.py"],
+            "onFailure": "block"
           }
         ]
       },
@@ -80,17 +81,20 @@
           {
             "type": "command",
             "command": "c3",
-            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/worktree_guard.py"]
+            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/worktree_guard.py"],
+            "onFailure": "block"
           },
           {
             "type": "command",
             "command": "c3",
-            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/patterns_guard.py"]
+            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/patterns_guard.py"],
+            "onFailure": "block"
           },
           {
             "type": "command",
             "command": "c3",
-            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/report_path_guard.py"]
+            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/report_path_guard.py"],
+            "onFailure": "block"
           }
         ]
       },
@@ -100,12 +104,14 @@
           {
             "type": "command",
             "command": "c3",
-            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/worktree_guard.py"]
+            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/worktree_guard.py"],
+            "onFailure": "block"
           },
           {
             "type": "command",
             "command": "c3",
-            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/patterns_guard.py"]
+            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/patterns_guard.py"],
+            "onFailure": "block"
           }
         ]
       },
@@ -115,7 +121,8 @@
           {
             "type": "command",
             "command": "c3",
-            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/check_agent_invocation.py"]
+            "args": ["run", "${CLAUDE_PROJECT_DIR}/.claude/hooks/check_agent_invocation.py"],
+            "onFailure": "block"
           },
           {
             "type": "command",

{claude_code_conductor-2.80.0 → claude_code_conductor-2.82.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 記録は通常どおり（差し戻し後も design-critic を必ず起動する。上限 2 サイクルの別枠・本表の C-3 行のとおり。転記行 2 種＝C-3省略宣言 / C-3監査要求の生成・評価も行わない。理由: 自律は人間の承認の目が無いため機械監査を厚く保つ）。ステップ 0 の転記行の確認は HITL のみ |
+| **C-3** | 監査 opt-in＋findings の裏取りと裁定 | design-critic を**必ず起動**する（初回）。findings は dev-workflow C-3 ステップ 3 の手順で親が裏取りして区分（退ける／直す／許容）し、サイクルごとに区分と根拠を gaps 台帳へ 1 行記録する（severity 記録は通常どおり）。**親が単独で「退ける」「許容」にしてよいのは、design-critic の重要度が High でなく、かつ品質の下限（機能欠陥・セキュリティ・保守性の必須要件。`.claude/CLAUDE.md`「品質保証の判断基準」）に関わらない指摘に限る。それ以外の指摘を「退ける」「許容」にするときは、重要度を問わず親が単独で裁かず人間の関所 2 へ出す**。再監査と打ち切りは同ステップ 5 の判定（設計を変えた是正ごとに 1 回・収束は件数でなく根本解決の反映と実装を止める項目の有無）を親が規則として適用する。**上限（初回 5 サイクル、差し戻し後は 2 サイクルの別枠）は変えない**。E→C 差し戻し後は dev-workflow C-2 の「E→C 差し戻し時の C-3 判定」を親が行い gaps 台帳に 1 行残す（`C-3: 実施` ならステップ 2 から design-critic を起動する） |
 | **D-2.5** | テスト承認 | **テスト全緑まで自動**（stuck 時は systematic-debugger 経由も自動）。全緑が客観条件 |
 | **D-3** | テスト承認 | **テスト全緑まで自動**（stuck 時は systematic-debugger 経由も自動）。全緑が客観条件 |
 | **D-5** | テスト承認 | **テスト全緑まで自動**（stuck 時は systematic-debugger 経由も自動）。全緑が客観条件 |
@@ -81,23 +81,16 @@ D-0（実行モード自動判別）は AskUserQuestion を持たないステッ
 承認ゲート 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 にはこの例外を適用しない（「全て許容」を選ばない）。
+**findings 分岐の固定**（E-3）: E-3 の findings 分岐 AskUserQuestion には HITL で
+「全て対応する／対応する指摘を選ぶ／全て許容して完了／否認・再レビューを依頼する」の選択肢があるが、
+**自律モードでは「全て対応する」を選ぶ**。E-3 では「全て許容」を選ばない。
 **High/Medium を許容で流すことは引き続き構造的に禁じる**（空収束防止）。
-許容という価値判断がこの例外に当てはまらない場合は、**人間の関所へエスカレーション**する。
+許容という価値判断が必要になった場合は、**人間の関所へエスカレーション**する。
+C-3 の findings の扱いは本表の C-3 行に従う。
 
-**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 のみ）:
-
-| サイクルの状態 | 分岐 |
-|---|---|
-| 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 へ |
+**C-3 の人間の目の代わり**: 自律では人間の承認の目が無く、親の区分を検算する者がいない。
+そのため、見落とすと実害が大きい判断（High の指摘と品質の下限に関わる指摘を「退ける」「許容」にする判断）は C-3 行のとおり人間の関所 2 に残し、
+親が単独で裁いた区分は、裏取りの根拠を gaps 台帳で追えることをもって人間の目の代わりとする。
 
 **cycles_used の定義**: E は**周回数**。CR∥SR 並列 1 セット＋修正＝1 サイクル。
 `cycles=` トークンの `E` は E-1+E-2+E-3 を 1 セットとした周回集約 ID（承認ゲート ID の E-3 とは別語彙）。
@@ -281,11 +274,9 @@ opt-in は plan-report 生成前（フェーズ A 以前）に行われるため
 
 - **レビューレポート件数の再集計**: 周回時に指摘件数を転記し、再度手で数え直して確認する
   （「レビュアーは数え間違える」法則への当面の手当て）。
-  C-3 でも同じ規律を適用し、収束判定の前に **design-review-report の High/Medium 件数**を本文から数え直してサマリ表の数値と突合する。
-  さらに C-3 では、件数の数え直しに加えて **High/Medium 0 と判定したサイクルに限り**、
-  **Low に落ちている findings の重要度が妥当か**を親が 1 度確認する。妥当性に疑義があれば**収束させず次サイクルへ回す**。
-  これは収束条件を High/Medium 0 としたことに伴うトレードオフに対する唯一の担保であり、
-  design-critic の重要度付与が粗く、本来 High のものが Medium/Low に落ちて収束が早まる事態を防ぐためのもの
+  C-3 でも同じ規律を適用し、裁定の前に **design-review-report の重要度別件数**を本文から数え直してサマリ表の数値と突合する。
+  C-3 の収束は件数では判定しない（dev-workflow C-3 ステップ 5 の 2 点で判定する）。重要度の付与が粗く本来 High のものが
+  Medium/Low に落ちていても、ステップ 3 の区分は重要度でなく内容（実装を止める欠陥か・品質の下限に触れるか）で行う
 
 - **対応案の前提裏取り**: 裏取りの対象は、(a) レビューが提示した対応案の理由文に現れる事実主張、**(b) 親 Claude 自身が新設する是正策・検査・成功条件・テスト仕様が依拠する事実主張（規約・設計文書に書く事実主張を含む）** の両方とする
   （レビューが前提を明示しない場合は、案を採用する理由として自分が書こうとしている事実主張が対象）

{claude_code_conductor-2.80.0 → claude_code_conductor-2.82.0}/.claude/skills/dev-workflow/SKILL.md

@@ -227,17 +227,20 @@ plan-report の全タスクを走査し、以下の形式でテキスト出力
 
 **plan-report の新規タイムスタンプ必須（全経路）**
 
-C-2 へ戻る全経路（E→C 差し戻し・C-3 層別ルーティング・C-2 否認のいずれも）で plan-report を再生成する場合は、必ず新規タイムスタンプで Write する（ピンポイント修正であっても既存 plan-report の Edit・同一タイムスタンプでの再承認は禁止）。転記行と plan の 1:1 紐付けと「最新＝現行」の成立を守るための書式規約であり、初回 C-3 の挙動は変えない。運転モードを問わず適用する。
+C-2 へ戻る全経路（E→C 差し戻し・C-3 層別ルーティング・C-2 否認のいずれも）で plan-report を再生成する場合は、必ず新規タイムスタンプで Write する（ピンポイント修正であっても既存 plan-report の Edit・同一タイムスタンプでの再承認は禁止）。承認と plan の 1:1 紐付けと「最新＝現行」の成立を守るための書式規約である。運転モードを問わず適用する。
 
-**C-3省略宣言（レビュー差し戻し時の再承認のみ・HITL 専用）**
+**E→C 差し戻し時の C-3 判定（レビュー差し戻し時の再承認のみ）**
 
-C-3 省略宣言の生成ルール詳細（4 条件・固定書式・転記規定・JSON 使い分け）は `.claude/skills/dev-workflow/references/c3-omission-declaration.md` を Read する。
+直前の `現在地:` が `フェーズC 計画中（レビュー差し戻し）` である C-2 再承認では、タスク一覧と同じ提示に C-3 を行うかの判定を 1 行で書く。修正計画が次の 4 つを全て満たすなら `C-3: 省略（計画のみの補正のため）`、1 つでも満たさない・判定できないなら `C-3: 実施（{満たさない条件}のため）` と書く:
 
-本ブロック（転記行 2 種＝C-3省略宣言 / C-3監査要求の生成）と C-3 ステップ 0（転記行 2 種の評価）は HITL 専用。自律モードでは C-3 全体が autonomous-mode のゲート対応表に従い、宣言・監査要求行の転記も行わない。
+1. 要件・設計（requirements-report / architecture-report）を変えない
+2. 新しい機構・ファイルを入れない
+3. plan-report の方向検算表（`references/plan-design-guidelines.md` ルール 15）に `方式変更` の行が無い
+4. 差し戻しの起因となった E の指摘（`[対応予定]` を付けたもの）に、重要度 High 以上の指摘もセキュリティの Medium 以上の指摘も含まれない
 
-**発火条件**: 宣言を提示してよいのは、直前の `現在地:` が `フェーズC 計画中（レビュー差し戻し）` である C-2 再承認時のみ（初回の C-2 では宣言を書かない・書かれても無効）。該当時は上記 reference を Read し、省略条件（4 条件の AND）・宣言の固定書式・転記規定・4 択 JSON の使い分けに従う。宣言を提示した C-2 再承認では reference の 4 択 JSON を、それ以外は下の 3 択 JSON を使う。
+ユーザーは C-2 の承認でこの判定を裁定する（判定に異議があれば否認して理由を伝える）。初回の C-2 では判定行を書かない。自律モードでは親がこの判定を規則として適用し、gaps 台帳（`loop-impl-gaps-*.md`）に判定行と同じ内容を 1 行残す。
 
-**3 択 JSON（初回 C-2・条件不成立時・非差し戻し経路用）**:
+**承認 JSON**:
 
 内容を提示した後、AskUserQuestion で確認する:
 
@@ -254,7 +257,7 @@ C-3 省略宣言の生成ルール詳細（4 条件・固定書式・転記規
 }
 ```
 
-承認後 → セッションファイルの `- [ ] 計画` を `- [x] 計画` に Edit し、`現在地:` を `現在地: フェーズD 実装中` に Edit して**C-3（計画監査ゲート）** へ。
+承認後 → セッションファイルの `- [ ] 計画` を `- [x] 計画` に Edit し、`現在地:` を `現在地: フェーズD 実装中` に Edit して**C-3（計画監査ゲート）** へ（E→C 差し戻しの再承認で `C-3: 省略` と判定して承認された場合は C-3 に入らず**フェーズ D** へ）。
 
 **tier-routing 結果記録**:
 ```bash
@@ -282,29 +285,7 @@ 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）。
-
-判定手順の詳細は以下の 3 ステップで構成される: **(1) 判定対象の抽出** — `現在地:` 直後の転記行のみを候補にする、**(2) 複数マッチ検査** — 同一 plan タイムスタンプの行が複数ある場合は不成立に倒す、**(3) 優先順位表** — 表の順番に従い最初にマッチした入口を選択。C-3省略宣言の成立条件（条件(ii) 帰属アンカーの評価）の判定規約は `.claude/skills/dev-workflow/references/c3-omission-declaration.md` を参照。
-
-| 順 | 判定 | 入口 | 消費処理 |
-|---|---|---|---|
-| 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 タイムスタンプ一致により判定上は自動的に無効化される。未消費行は効果観測で『宣言したが成立しなかった周回』として数えるため証跡として残す）。
-
-**省略の意味**: 省略は『質問の省略』であって監査の禁止ではない（ユーザーはいつでも監査を明示要求できる）。
+**入口**: 初回の C-3 はステップ 1（opt-in の確認）から入る。E→C 差し戻しの C-2 再承認で `C-3: 実施` と判定して承認された場合は、ユーザーが C-2 の承認で実施を裁定済みのため、ステップ 1 を出さずステップ 2 へ入る（`C-3: 省略` で承認された場合は C-3 に入らない。C-2 の「E→C 差し戻し時の C-3 判定」）。ステップ 4 の連鎖が C-2 を経て C-3 に戻った場合はステップ 5 へ入る。**差し戻し経由・連鎖復帰かどうかを判別できない場合（compaction・セッション交代後等）はステップ 1 に倒す**（ステップ 1 は監査を促す側の質問であり安全側）。自律モードでのゲートの付け替えは `autonomous-mode` skill のゲート対応表 C-3 行に従う（Codex / Cursor / OpenCode には同 skill が写像されないため、常に本節の HITL の手順で動く）。
 
 **ステップ 1: opt-in の確認（AskUserQuestion 単独ターン）**
 
@@ -338,7 +319,7 @@ design-critic は `.claude/reports/design-review-report-YYYYMMDD-HHMMSS.md` を
 
 完了後 → ステップ 3 へ。
 
-**ステップ 3: findings の分岐**
+**ステップ 3: 指摘の裏取りと裁定**
 
 design-review-report を Read して findings の有無を確認する。design-critic の起動失敗・中断によりレポートが存在しない場合は、AskUserQuestion でユーザーに「再実行する」か「スキップしてフェーズ D へ進む」かを確認する。
 
@@ -346,92 +327,67 @@ design-review-report を Read して findings の有無を確認する。design-
 そのまま**フェーズ D** へ。
 
 **findings あり:**
-指摘一覧をテキストで提示してから AskUserQuestion で方針を確認する（このブロックに副作用ツールを混在させない）。対応方針決定の際は E-3 の裁定の判断基準を適用する:
+対応方針決定の際は E-3 の裁定の判断基準を適用する（参照するのは判断基準の全体であり、下記 2 の裏取りは同基準の第 5 項に当たる）。親はユーザーに聞く前に、各指摘を次の順で処理する:
+
+1. **主張の種類を分ける**: 各 finding を「現物についての主張」と「文面についての主張」に分ける（種類の定義と finding の項目は `.claude/skills/dev-workflow/references/design-critic-rubric.md` の「Finding 必須項目」。design-critic が付けた種類が内容と合わなければ親が付け直す）。現物と文面が混ざる指摘は、現物の部分を 2 の裏取りの対象にする
+2. **主張を 1 件ずつ確かめる**: 現物の主張は現物で（Read / grep / 一次資料。finding の「根拠」を起点にする）、文面の主張は指している箇所（レポートの該当箇所）を Read して確かめる。主張の種類を問わず、主張が偽（誤読・到達不能を含む）と確かめた指摘は **退ける**（根拠のファイルと識別子を添える）。主張の一部だけが偽のときは、偽の部分と真の部分を区分の表で分けて書き、真の部分で区分を決める。「〜が無い」の主張を確かめるときの探索射程は `.claude/rules/judgment-principles.md` §2 に従う
+3. **残った指摘を 2 つに分ける**: **実装を止める欠陥**（書けない・矛盾していて実装者が進めない・機能やセキュリティの欠陥になる）と **実装を止めない指摘**（文面の整合に限らない）。品質の下限（機能欠陥・セキュリティ Medium 以上・保守性の必須要件。`.claude/CLAUDE.md`「品質保証の判断基準」）に触れる指摘は重要度にかかわらず必ず前者に入れる。前者は **直す**、後者は **許容** を推奨にし、許容の理由（なぜ実装を止めないか・どこで拾うか、または手戻りを受け入れるか）は指摘ごとに書く
+4. **3 区分の表と推奨を提示して裁定を仰ぐ**: 退ける／直す／許容 の表（finding ID・重要度・主張の種類・区分・根拠）をテキストで提示してから、AskUserQuestion で裁定を仰ぐ（このブロックに副作用ツールを混在させない）
+
+親が自分で置く是正策や前提（新しい ADR・計画が依拠する事実）も、裁定に出す前に 2 と同じように現物で確かめる。
+
+**区分の付け替えの制限**: design-critic が High（実装を止める）とした指摘を親が「許容」へ付け替えるのは、現物の裏取りで実装を止めないことを示せたときだけとし、その根拠を区分の表に書く。最終の区分はユーザーが裁定する。
 
 ```json
 {
   "questions": [{
-    "question": "design-review-report に指摘があります。対応方針を選択してください。",
+    "question": "design-review-report の指摘を裏取りし、退ける／直す／許容に区分しました。裁定を選択してください。",
     "options": [
-      { "label": "全て対応する", "description": "全指摘に [対応予定] を付けて起因層へ戻す" },
-      { "label": "対応する指摘を選ぶ", "description": "指摘ごとに対応/許容を決める" },
-      { "label": "全て許容して進む", "description": "全指摘を許容してフェーズ D へ" },
+      { "label": "推奨どおり裁く (Recommended)", "description": "提示した表の区分のとおりに裁く" },
+      { "label": "全て対応する", "description": "退けた指摘も含め全件を直す（親の裏取りを覆し、全件に [対応予定] を付けて起因層へ戻す）" },
+      { "label": "区分を変える指摘を選ぶ", "description": "指摘ごとに区分（退ける／直す／許容）を指定し直す" },
       { "label": "否認・再監査を依頼する", "description": "フィードバックして design-critic を再実行" }
     ]
   }]
 }
 ```
 
-**severity 供給経路の注記**: 以下の design-critic 判断記録で渡す `--severity` は `high`/`medium`/`low` の 3 段階のみ（design-critic は `critical` を供給しない。`critical` は security-reviewer 経由でのみ記録され得る）。
-
-**「全て対応する」の場合:**
-全指摘に `> **[対応予定]**` をマークする。
-
-**design-critic 判断記録**: マークした直後・同一ステップ内で、層別ルーティング（ステップ 4）へ進む前に、各 DC-XX-NNN について Bash で c3.db に記録する:
-```bash
-c3 run .claude/skills/dev-workflow/scripts/record_review_decision.py \
-  --reviewer design-critic \
-  --checklist-id DC-XX-NNN \
-  --severity {high|medium|low} \
-  --decision fixed \
-  --finding "{指摘の1行要約（逐語引用せず・引用符/バッククォート/$ 等のシェルメタ文字を含めない。該当文字は置換/省略）}"
-```
+- 「推奨どおり裁く」→ 提示した表の区分で下記のマーカーと記録を行う
+- 「全て対応する」→ 全件を「直す」として下記のマーカーと記録を行う
+- 「区分を変える指摘を選ぶ」→ 続けて AskUserQuestion で、区分を変える指摘 ID と変更後の区分、許容にする場合はその理由を確認する（別ターン）。表の区分に反映してから下記のマーカーと記録を行う
+- 「否認・再監査を依頼する」→ 続けて AskUserQuestion でフィードバックを確認してからステップ 2（design-critic 再起動）へ
 
-層別ルーティング（ステップ 4）へ。
+**マーカーと記録**: 裁定した区分ごとに、各 finding の直下へ次のマーカーを Edit で追記する（検出記録は削除しない）。追記した直後・同一ステップ内で、各 DC-XX-NNN について下の表の `--decision` / `--reason` で c3.db に記録する:
 
-**「対応する指摘を選ぶ」の場合:**
-続けて AskUserQuestion で確認する（別ターン）:
-```json
-{
-  "questions": [{
-    "question": "どの指摘を対応しますか？対応する指摘 ID（例: DC-AS-001）と、許容する指摘の理由を教えてください。"
-  }]
-}
-```
-1. 対応する指摘に `> **[対応予定]**` を Edit で追記する
-2. 許容する指摘の直下に `> **[許容]** {理由}` を Edit で追記する（検出記録は削除しない）
-3. **design-critic 判断記録**: 1・2 で disposition を Edit した直後・同一ステップ内で、各 DC-XX-NNN について Bash で c3.db に記録する（`[対応予定]`→`fixed` / `[許容]`→`accepted`）:
-   ```bash
-   c3 run .claude/skills/dev-workflow/scripts/record_review_decision.py \
-     --reviewer design-critic \
-     --checklist-id DC-XX-NNN \
-     --severity {high|medium|low} \
-     --decision {fixed|accepted} \
-     --finding "{指摘の1行要約（逐語引用せず・引用符/バッククォート/$ 等のシェルメタ文字を含めない。該当文字は置換/省略）}"
-   ```
-4. `[対応予定]` を付けた finding が 1 件以上あれば層別ルーティング（ステップ 4）へ。全て許容した場合はフェーズ D へ。
+| 区分 | マーカー | `--decision` | `--reason` |
+|---|---|---|---|
+| 直す | `> **[対応予定]**` | `fixed` | 付けない |
+| 退ける | `> **[退ける]** {根拠のファイルと識別子}` | `accepted` | `"裏取りで偽: {根拠}"` |
+| 許容 | `> **[許容]** {理由}` | `accepted` | マーカーの `{理由}` と同じ文字列（シェルメタ文字は置換・省略。自律モードでは `自律:` 接頭辞付き。直下の段落） |
 
-**「全て許容して進む」の場合:**
-続けて AskUserQuestion で許容理由を確認する（別ターン）:
-```json
-{
-  "questions": [{
-    "question": "全指摘を許容する理由を教えてください。"
-  }]
-}
-```
-全指摘の直下に `> **[許容]** {理由}` を Edit で追記する。
+許容の `{理由}` は固定の文言にせず、その指摘を許容と裁いた理由（ユーザーが区分を変えた場合はユーザーの理由）を書く。自律モードで親が区分した「許容」は、マーカーの理由の先頭に `自律:` を付ける（`> **[許容]** 自律: {理由}`。design-critic の Memory がユーザーの裁定した許容だけを学習するため）。`--reason` にも `自律:` を含めた同じ文字列を渡す。ただし `--reason` と `--finding` はシェル引数なので、引用符・バッククォート・`$` 等のシェルメタ文字は置換または省略する（マーカー側の理由に含めるのも避け、同じ文字列にそろえる）。
 
-**design-critic 判断記録**: Edit した直後・同一ステップ内で、フェーズ D へ進む前に、各 DC-XX-NNN について Bash で c3.db に記録する:
 ```bash
 c3 run .claude/skills/dev-workflow/scripts/record_review_decision.py \
   --reviewer design-critic \
   --checklist-id DC-XX-NNN \
   --severity {high|medium|low} \
-  --decision accepted \
+  --decision {fixed|accepted} \
+  [--reason "{上表の reason}"] \
   --finding "{指摘の1行要約（逐語引用せず・引用符/バッククォート/$ 等のシェルメタ文字を含めない。該当文字は置換/省略）}"
 ```
 
-フェーズ D へ。
+（`--reason` の根拠・理由にも同じくシェルメタ文字を含めない）
+
+**severity 供給経路の注記**: design-critic 判断記録で渡す `--severity` は `high`/`medium`/`low` の 3 段階のみ（design-critic は `critical` を供給しない。`critical` は security-reviewer 経由でのみ記録され得る）。
 
-**「否認・再監査を依頼する」の場合:**
-続けて AskUserQuestion でフィードバックを確認してからステップ 2（design-critic 再起動）へ。
+記録後、「直す」が 1 件以上あれば層別ルーティング（ステップ 4）へ。「直す」が 0 件ならフェーズ D へ。
 
 **ステップ 4: 層別ルーティング**
 
-（ステップ 3 で「全て対応する」または「対応する指摘を選ぶ」を選び、`[対応予定]` が 1 件以上ある場合のみこのステップへ到達する）
+（ステップ 3 で `[対応予定]`（直す）が 1 件以上ある場合のみこのステップへ到達する）
 
-`[対応予定]` を付けた finding の起因層（`A要件` / `B設計` / `C計画`）を集計し、最も上流の層へ戻る（上流順: **A要件 < B設計 < C計画**）。戻り先はピンポイント修正（`[対応予定]` の finding のみ対象。フルやり直しはしない）。**最上流の判定は `[対応予定]` を付けた finding だけで行う（`[許容]` にした finding の起因層は戻り先に影響しない）。**
+`[対応予定]` を付けた finding の起因層（`A要件` / `B設計` / `C計画`）を集計し、最も上流の層へ戻る（上流順: **A要件 < B設計 < C計画**）。戻り先はピンポイント修正（`[対応予定]` の finding のみ対象。フルやり直しはしない）。**最上流の判定は `[対応予定]` を付けた finding だけで行う（`[退ける]`・`[許容]` にした finding の起因層は戻り先に影響しない）。**
 
 | `[対応予定]` finding の最上流起因 | 戻り先 | 修正する担当 | その後の連鎖 |
 |---|---|---|---|
@@ -439,7 +395,9 @@ c3 run .claude/skills/dev-workflow/scripts/record_review_decision.py \
 | B設計 が最上流 | フェーズ B | architect（該当設計のみ修正） | B → C → C-3 |
 | C計画 のみ | フェーズ C | planner（該当タスクのみ修正） | C → C-3 |
 
-**tier-routing 結果記録**: 上表により層別ルーティングが発動した場合（`[対応予定]` が 1 件以上ある場合）のみ、戻り先の最上流 role へ failure を 1 件記録する（`[許容]` のみで `[対応予定]` が 0 件・findings なしの場合は記録しない）:
+**是正は小さく・同じ事実を増やさない**: 各フェーズの改訂は、`[対応予定]` の指摘の是正に必要な節だけに限る。同じ事実（数値・書式・一覧・合格条件）を複数の節・レポートへ写さず、1 か所に置いて他は参照で指す（改訂のたびに写し漏れが次の指摘の材料になるため）。レポートの形式（新規タイムスタンプ・`revision:`）は変えない。
+
+**tier-routing 結果記録**: 上表により層別ルーティングが発動した場合（`[対応予定]` が 1 件以上ある場合）のみ、戻り先の最上流 role へ failure を 1 件記録する（`[退ける]`・`[許容]` のみで `[対応予定]` が 0 件・findings なしの場合は記録しない）:
 ```bash
 c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
   --role {interviewer|architect|planner（戻り先 role）} --outcome failure --gate C-3 \
@@ -451,21 +409,28 @@ c3 run .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
 
 上流フェーズ修正後は下流へ自然に連鎖する（例: B 修正 → C 再計画 → C-2 再承認 → C-3）。各フェーズでも該当 `[対応予定]` の finding のみを反映する。
 
-連鎖が C-2 を経て C-3 に戻ったら → ステップ 5（再監査の選択）へ。
+連鎖が C-2 を経て C-3 に戻ったら → ステップ 5（再監査の判定）へ。
 
-**ステップ 5: 修正後の再監査（選択式・無限ループ防止）**
+**ステップ 5: 修正後の再監査の判定**
 
-上流修正の連鎖を経て C-3 に戻ってきた場合、毎回自動再走はしない。AskUserQuestion で再監査の要否を確認する（このブロックに副作用ツールを混在させない）:
+上流修正の連鎖を経て C-3 に戻ってきた場合、毎回自動再走はしない。再監査の要否を次で判定する:
+
+- 今回の是正が**設計（architecture-report）を変えた**ときに限り、再監査を 1 回行う（設計を変えた是正 1 回ごとに design-critic を 1 回起動する）。この場合は収束を判定する前に再監査を先に行い、その結果をステップ 3 の手順で裁いてから下の 2 点を判定する（(ii) は再監査の結果で判定する）。ただし「先に行う」は自律モードの規則であり、HITL では下の AskUserQuestion で「再監査する」が選ばれてから行う（質問の前に再監査を走らせず、設計を変えたことは推奨として示す）
+- 計画（plan-report）だけの補正・文面の整合だけなら再監査しない（(ii) は是正後の計画で判定する）
+
+**収束は件数で判定しない**。次の 2 点を両方満たせば収束とし、残る実装を止めない指摘は許容してフェーズ D へ進む: (i) 根本解決（「直す」と裁いた指摘の根本問題を解く是正）が設計と計画に反映された (ii) 実装を止める欠陥（tester / developer が構造的に止まる項目）が残っていない。再監査後のステップ 3 で「直す」が残れば (ii) を満たさず、ステップ 4 へ進む。
 
 是正起因の欠陥が連続している場合は E-3 の『是正ループの打切条件』を参照する（前提を疑う打切）。
 
+親は上記の判定（設計を変えたか。再監査しない場合は (i)(ii) を満たすか）と推奨を提示し、AskUserQuestion で再監査の要否の裁定を仰ぐ（推奨する側の label に ` (Recommended)` を付ける。このブロックに副作用ツールを混在させない）。自律モードでは親がこの判定を規則として適用する（autonomous-mode のゲート対応表 C-3 行）:
+
 ```json
 {
   "questions": [{
     "question": "修正が入りました。design-critic で再監査しますか？",
     "options": [
-      { "label": "再監査する", "description": "更新後のレポート群を再度チェック（重要案件）" },
-      { "label": "再監査せず実装へ", "description": "フェーズ D へ進む" }
+      { "label": "再監査する", "description": "更新後のレポート群を再度チェック（是正が設計を変えた場合）" },
+      { "label": "再監査せず実装へ", "description": "フェーズ D へ進む（計画のみの補正・文面の整合のみの場合）" }
     ]
   }]
 }
@@ -770,7 +735,7 @@ c3 run .claude/skills/dev-workflow/scripts/detect_execution_verification.py [--b
 語彙定義ファイル自身の変更でも発火する（想定内）。狭めたい場合のみ `--base` を明示する。
 
 **判定結果の記録**:
-スクリプト実行後、当日セッションファイルの `現在地:` 行の直後のヘッダブロック（モード行・転記行）の末尾に 1 行を追記する:
+スクリプト実行後、当日セッションファイルの `現在地:` 行の直後のヘッダブロック（モード行・判定行）の末尾に 1 行を追記する:
 
 ```
 E-0判定: {TOKEN} {件数} plan-report-{タイムスタンプ}