claude-code-conductor 2.40.0__tar.gz → 2.42.0__tar.gz

{claude_code_conductor-2.40.0 → claude_code_conductor-2.42.0}/.claude/breaking-changes.txt

@@ -6,3 +6,4 @@
 
 v2.11.0|summarize-memory agent + skill removed; replaced by `c3 recall`|summarize-memory エージェント / skill を完全廃止。代替は `c3 recall` の意味検索。
 v2.20.0|hooks/schema.sql removed; SQLite schema is now managed by c3/migrations/ (auto-applied at session_start)|hooks/schema.sql を削除しました。SQLite スキーマは c3/migrations/ (wheel 内) で管理され session_start で自動適用されます。
+v2.41.0|Learning tables tier_bandit/tier_recent_outcomes are DROPPED and learning data resets; record_tier_outcome.py replaced by record_agent_outcome.py; c3 tier stats --json shape changed; old db.py tier APIs removed or shimmed (shims removed next release)|

{claude_code_conductor-2.40.0 → claude_code_conductor-2.42.0}/.claude/deletions.txt

@@ -84,3 +84,6 @@ skills/wave-execution/SKILL.md
 docs/parallel-orchestra-manifest.md
 docs/po-worktree-writes.md
 hooks/po_heartbeat.py
+
+# ---- v2.41.0: tier-routing 学習シグナル再設計（record_agent_outcome.py へ置換） ----
+skills/dev-workflow/scripts/record_tier_outcome.py

{claude_code_conductor-2.40.0 → claude_code_conductor-2.42.0}/.claude/hooks/select_tier.py

@@ -5,14 +5,19 @@ tier-routing MVP: タスクの複雑度を簡易ヒューリスティックで
 （または学習データ収集期は uniform random）で推奨 Tier を決定して
 ``additionalContext`` で親 Claude に伝える。
 
-MVP スコープ（ユーザー承認済み）:
-- **やる**: 推奨 Tier を提示するのみ。agent の `model:` フロントマターは触らない
-- **やらない**: 動的 model 切替（次フェーズ）、フォールバック（Haiku 失敗→Sonnet 自動昇格）
+MVP スコープ（ユーザー承認済み・tier-routing 自動適用フェーズ2でソフト適用を追加）:
+- **やる**: 推奨 Tier を提示し、developer / wt_developer の Agent 起動時に
+  `model:` へ明示適用するよう親 Claude に指示する（ソフト適用・
+  additionalContext 経由の行動指示であり機械強制ではない）。agent の
+  `model:` フロントマター自体は変更しない
+- **やらない**: PreToolUse hook 等による機械適用（updatedInput での自動書き換え・
+  次フェーズ）、developer 以外の role への適用、フォールバック（Haiku 失敗→Sonnet 自動昇格）
 
 学習データ:
 - 結果は ``.claude/state/tier_selection.json`` に直近 1 件のみ書き込む
-- dev-workflow フェーズ E の承認/否認時に ``record_tier_outcome.py`` が
-  この json を読んで ``tier_bandit`` テーブルを更新する
+- dev-workflow の各フェーズ承認ゲート（並列タスク単位を含む）で
+  ``record_agent_outcome.py`` がこの json を読んで ``agent_tier_bandit``
+  テーブルを更新する
 
 入力 / 出力:
 - stdin: UserPromptSubmit payload（``prompt`` フィールドを参照）
@@ -70,7 +75,7 @@ COMPLEX_KEYWORDS = frozenset({
     "リファクタ", "再設計", "移行", "セキュリティ", "並行",
 })
 
-# 結果の永続化先（dev-workflow フェーズ E の record_tier_outcome.py が読む）
+# 結果の永続化先（dev-workflow の各フェーズ承認ゲートで record_agent_outcome.py が読む）
 _HOOKS_DIR = os.path.dirname(os.path.abspath(__file__))
 _CLAUDE_DIR = os.path.dirname(_HOOKS_DIR)
 TIER_SELECTION_PATH = os.path.join(_CLAUDE_DIR, "state", "tier_selection.json")
@@ -244,7 +249,7 @@ def _read_prompt_history() -> list[dict]:
     """prompt-history.jsonl から末尾 N 行を読み込む。
 
     各行は ``{"ts", "prompt_hash", "prompt_prefix", "complexity", "tier", "outcome"}``
-    の形式（record_tier_outcome.py が書き込む）。
+    の形式（record_agent_outcome.py が書き込む）。
     壊れた行はスキップ。ファイル不在時は空リスト。
     """
     if not os.path.isfile(PROMPT_HISTORY_PATH):
@@ -440,7 +445,7 @@ def _db_failure_rate(complexity: str, tier: str) -> tuple:
     c3_db = _load_c3_db_module()
     if c3_db is None:
         return None, 0
-    return c3_db.read_tier_failure_rate(complexity, tier)
+    return c3_db.read_agent_failure_rate("developer", complexity, tier)
 
 
 def maybe_escalate(
@@ -500,7 +505,7 @@ def write_tier_selection(
 ) -> None:
     """直近の選択結果を ``tier_selection.json`` に書く。
 
-    record_tier_outcome.py がこの json を読んで α/β を更新する。
+    record_agent_outcome.py がこの json を読んで agent_tier_bandit の α/β を更新する。
     既存ファイルは上書きされる（最新 1 件のみ保持）。
 
     ``suggested_model`` を併せて書く。tier 名と model の短縮名は同一とする。
@@ -597,9 +602,15 @@ def build_additional_context(
         suffix += " [cost-aware: 成功率拮抗のため低コスト Tier を選択]"
 
     return (
-        f"[tier-routing 推奨] 複雑度: {complexity} / 推奨 Tier: {tier}（{confidence}）。"
-        f" 親 Claude の Agent ツール経由ではエージェント定義の frontmatter 指定が"
-        f" 優先されるため、コスト最適化したい場合は手動切替してください。{suffix}"
+        f"[tier-routing 推奨] 複雑度: {complexity} / 推奨 Tier: {tier}（{confidence}・developer 基準）。"
+        f" エージェント定義 frontmatter の model がデフォルトですが、Agent 呼び出し時に"
+        f" model: を明示指定すれば上書きできます（fork を除く）。"
+        f" 指示: developer / wt_developer を Agent ツールで起動する際は"
+        f" model: {tier} を明示指定してこの推奨 Tier を適用すること"
+        f"（学習データ収集中の期間も含め常に適用する。fork は model 上書き不可のため対象外）。"
+        f" 対象は developer / wt_developer のみ。tester 等の他 role、および親 Claude"
+        f" ペルソナで動かす role（interviewer / architect / planner）は"
+        f" tier レバーが無いため対象外で従来どおりとする。{suffix}"
     )
 
 
@@ -756,7 +767,7 @@ def main() -> int:
         # DB ヘルパーが無い環境でも uniform 選択で推奨を返す
         params = {t: (1.0, 1.0, 0) for t in TIERS}
     else:
-        params = c3_db.read_tier_params(complexity)
+        params = c3_db.read_agent_tier_params("developer", complexity)
 
     # v2.24.0: cost_map をハイブリッド解決（実測 rate USD/MTok を主に、欠損 tier は静的単価で補完）。
     # rate 化により measured(実測)と tier_reference_cost(静的)が同次元（USD/MTok）になり単位整合済み。

{claude_code_conductor-2.40.0 → claude_code_conductor-2.42.0}/.claude/hooks/session_stop.py

@@ -103,8 +103,6 @@ def main() -> int:
                 from c3.usage_ingester import ingest_session  # noqa: PLC0415
                 project_dir = _Path(transcript_path).parent
                 ingest_session(session_id=session_id, project_dir=project_dir)
-                from c3.db import sync_tier_bandit_cost  # noqa: PLC0415
-                sync_tier_bandit_cost()
     except Exception as e:
         print(f"[session_stop:usage_ingester] failed: {type(e).__name__}", file=sys.stderr)
 

{claude_code_conductor-2.40.0 → claude_code_conductor-2.42.0}/.claude/settings.json

@@ -10,7 +10,7 @@
       "Bash(python .claude/hooks/recall_autorebuild.py*)",
       "Bash(python .claude/skills/dev-workflow/scripts/review_hint_inject.py*)",
       "Bash(python .claude/skills/dev-workflow/scripts/record_review_decision.py*)",
-      "Bash(python .claude/skills/dev-workflow/scripts/record_tier_outcome.py*)",
+      "Bash(python .claude/skills/dev-workflow/scripts/record_agent_outcome.py*)",
       "Bash(python .claude/skills/init-session/scripts/session_guard.py*)",
       "Read(**)",
       "Glob(**)",

{claude_code_conductor-2.40.0 → claude_code_conductor-2.42.0}/.claude/skills/dev-workflow/SKILL.md

@@ -24,12 +24,32 @@ user-invocable: false
 
 ---
 
+## tier-routing 結果記録の運用
+
+各フェーズの承認ゲート・タスク単位で `record_agent_outcome.py` を呼び、role 別に実際に使われた tier の成功/失敗を記録する（architecture-report-20260702-214748.md §3-4）。全記録ブロック共通のルール:
+
+- `--complexity` は必須。値は**ワークフロー開始時に UserPromptSubmit hook が表示した `[tier-routing 推奨]` 表示の複雑度**（simple/medium/complex）で、フェーズ A 冒頭でセッションファイルへ `tier-routing複雑度:` 行として 1 度だけ永続化する（本ワークフロー中に再判定しない）。以降の各ブロックの `{セッションファイルの tier-routing複雑度: 行の値}` はこの永続化された値を参照するプレースホルダ（`現在地:` フィールドと同じ、compaction・長時間セッション耐性のための設計）
+- `--execution` は必須。interviewer/architect/planner を**親 Claude ペルソナ**で採用した場合は `persona`（bandit 更新なし・イベントログのみ）、**Agent ツールでサブエージェント起動した場合は `subagent`**（bandit 更新あり）を渡す。developer/tester は dev-workflow では常に `subagent`
+- `--execution persona` のブロックは `--tier {親モデルのtier名（haiku/sonnet/opus）。判別不能なら unknown}` も明記する。record_agent_outcome.py は persona 実行かつ `--tier` 省略時に常に `unknown` 固定で記録するため、実際の親モデル tier を記録に残したい場合は明示が必要（`--execution subagent` のブロックは frontmatter から自己解決するため `--tier` 不要）
+- `--task` は任意引数。同一 gate/role/outcome の記録がタスクごとに繰り返し発生するゲート（D-2.5/D-3 等）では `--task {plan タスクID}` を付与して dedupe キーの粒度を上げる。1 ワークフロー 1 判定のゲート（A-4/B-3/C-2/C-3/D-5/E-1/E-2）は付与不要
+- `--note` は指摘本文を逐語引用せず、シェルメタ文字（引用符・バッククォート・`$` 等）を含まない短い要約で書く（コマンドライン展開事故・シェルインジェクションを避けるため。record_agent_outcome.py 側で長さ上限と秘密情報マスクも適用されるが、そもそも逐語引用しないことが第一防御）
+- 全エラー exit 0 のため呼び出しが失敗してもワークフローは止めない（記録漏れの可能性はあるが後続フェーズはブロックしない）
+
+**ソフト適用（推奨 Tier の `model:` 指定・ADR-AS-1/ADR-AS-2）:**
+
+- developer を Agent ツールで起動する箇所（**D-2 / D-2.5 の再実行 / D-4**）では、`[tier-routing 推奨]` が指示した推奨 Tier を Agent 呼び出しの `model:` に明示指定する（ソフト適用・学習データ収集中の期間も含め常に適用する。fork は model 上書き不可のため対象外）。**tester / systematic-debugger は対象外**で従来どおり frontmatter 任せとする。interviewer/architect/planner は親 Claude ペルソナで動かし tier レバーが無いため対象外。
+- **推奨 Tier の SSOT**: 「推奨 Tier」の唯一のソースは `.claude/state/tier_selection.json` の `tier`（無ければ `suggested_model`）であり、`[tier-routing 推奨]` の additionalContext テキストはその値を人間可読に射影した派生表示で SSOT ではない。この値は kickoff プロンプトの UserPromptSubmit で select_tier が 1 度だけ書き、E-2 の `--final` で削除されるまで wave/ゲートをまたいで安定する（承認応答は UserPromptSubmit を発火しないため途中で上書きされない）。
+- developer の record ブロックは**原則 `--tier` を付けない**（record_agent_outcome.py が tier_selection.json から実適用 tier を機械解決する。tier 値の LLM 申告を行わない）。**例外（機械条件・ADR-AS-2）**: developer 起動時に指定した `model:` が推奨 Tier（tier_selection.json.tier）と**異なる値だった場合は、必ずその実際に指定した値を `--tier {実 model の tier}` に付けて**実態を記録する（「指定 model: ≠ 推奨 Tier なら必ず付与」という観測可能な二値条件で判定する）。
+
+---
+
 ## フェーズ A: ヒアリング
 
 `.claude/agents/interviewer.md` を Read してペルソナを採用する。
 
 今日のセッションファイルに以下を追記する（未登録の場合のみ）:
 - `- [ ] ヒアリング` / `- [ ] 設計` / `- [ ] 計画`
+- `tier-routing複雑度: {ワークフロー開始時に UserPromptSubmit hook が表示した [tier-routing 推奨] の複雑度}`（1 度だけ追記。既にあれば追記しない。以降の全 tier-routing 記録ブロックの `--complexity` はこの行の値を参照する）
 
 ### A-1〜A-3: 動的ヒアリング（ルーブリック型）
 
@@ -66,8 +86,24 @@ user-invocable: false
 
 承認後 → セッションファイルの `- [ ] ヒアリング` を `- [x] ヒアリング` に Edit し、`現在地:` を `現在地: フェーズB 設計中` に Edit して**フェーズ B** へ。
 
+**tier-routing 結果記録**:
+```bash
+python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+  --role interviewer --outcome success --gate A-4 \
+  --execution persona --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+  --tier {親モデルのtier名（haiku/sonnet/opus）。判別不能なら unknown}
+```
+（interviewer を Agent ツールでサブエージェント起動した場合は `--execution subagent` を渡す。その場合 `--tier` は不要）
+
 **知識蓄積:**
-- 「否認・修正を依頼する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+- 「否認・修正を依頼する」「否認・自分でファイルを編集する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+- **tier-routing 結果記録（否認時）**:
+  ```bash
+  python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+    --role interviewer --outcome failure --gate A-4 \
+    --execution persona --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+    --tier {親モデルのtier名（haiku/sonnet/opus）。判別不能なら unknown}
+  ```
 - 承認かつ非自明なアプローチが有効だった場合: `## うまくいったアプローチ` に追記し `patterns` にも追加する
 
 ---
@@ -116,8 +152,24 @@ user-invocable: false
 
 承認後 → セッションファイルの `- [ ] 設計` を `- [x] 設計` に Edit し、`現在地:` を `現在地: フェーズC 計画中` に Edit して**フェーズ C** へ。
 
+**tier-routing 結果記録**:
+```bash
+python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+  --role architect --outcome success --gate B-3 \
+  --execution persona --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+  --tier {親モデルのtier名（haiku/sonnet/opus）。判別不能なら unknown}
+```
+（architect を Agent ツールでサブエージェント起動した場合は `--execution subagent` を渡す。その場合 `--tier` は不要）
+
 **知識蓄積:**
-- 「否認・修正を依頼する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+- 「否認・修正を依頼する」「否認・自分でファイルを編集する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+- **tier-routing 結果記録（否認時）**:
+  ```bash
+  python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+    --role architect --outcome failure --gate B-3 \
+    --execution persona --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+    --tier {親モデルのtier名（haiku/sonnet/opus）。判別不能なら unknown}
+  ```
 - 承認かつ非自明なアプローチが有効だった場合: `## うまくいったアプローチ` に追記し `patterns` にも追加する
 
 ---
@@ -181,8 +233,24 @@ plan-report の全タスクを走査し、以下の形式でテキスト出力
 
 承認後 → セッションファイルの `- [ ] 計画` を `- [x] 計画` に Edit し、`現在地:` を `現在地: フェーズD 実装中` に Edit して**C-3（計画監査ゲート）** へ。
 
+**tier-routing 結果記録**:
+```bash
+python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+  --role planner --outcome success --gate C-2 \
+  --execution persona --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+  --tier {親モデルのtier名（haiku/sonnet/opus）。判別不能なら unknown}
+```
+（planner を Agent ツールでサブエージェント起動した場合は `--execution subagent` を渡す。その場合 `--tier` は不要）
+
 **知識蓄積:**
-- 「否認・修正を依頼する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+- 「否認・修正を依頼する」「否認・自分でファイルを編集する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+- **tier-routing 結果記録（否認時）**:
+  ```bash
+  python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+    --role planner --outcome failure --gate C-2 \
+    --execution persona --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+    --tier {親モデルのtier名（haiku/sonnet/opus）。判別不能なら unknown}
+  ```
 - 承認かつ非自明なアプローチが有効だった場合: `## うまくいったアプローチ` に追記し `patterns` にも追加する
 
 ---
@@ -289,6 +357,16 @@ design-review-report を Read して findings の有無を確認する。design-
 | B設計 が最上流 | フェーズ B | architect（該当設計のみ修正） | B → C → C-3 |
 | C計画 のみ | フェーズ C | planner（該当タスクのみ修正） | C → C-3 |
 
+**tier-routing 結果記録**: 上表により層別ルーティングが発動した場合（`[対応予定]` が 1 件以上ある場合）のみ、戻り先の最上流 role へ failure を 1 件記録する（`[許容]` のみで `[対応予定]` が 0 件・findings なしの場合は記録しない）:
+```bash
+python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+  --role {interviewer|architect|planner（戻り先 role）} --outcome failure --gate C-3 \
+  --execution persona --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+  --tier {親モデルのtier名（haiku/sonnet/opus）。判別不能なら unknown} \
+  --note "{層別ルーティングの起因概要（コード断片の逐語引用禁止）}"
+```
+（戻り先 role を Agent ツールでサブエージェント起動した場合は `--execution subagent` を渡す。その場合 `--tier` は不要）
+
 上流フェーズ修正後は下流へ自然に連鎖する（例: B 修正 → C 再計画 → C-2 再承認 → C-3）。各フェーズでも該当 `[対応予定]` の finding のみを反映する。
 
 連鎖が C-2 を経て C-3 に戻ったら → ステップ 5（再監査の選択）へ。
@@ -403,7 +481,7 @@ Agent ツールで `tester` エージェントを起動する。→ 失敗する
 
 ### D-2: developer（Green フェーズ）
 
-Agent ツールで `developer` エージェントを起動する。→ テストが通る実装を行う。
+Agent ツールで `developer` エージェントを起動する（`model:` に推奨 Tier を指定・上記「tier-routing 結果記録の運用」節参照）。→ テストが通る実装を行う。
 
 ### D-2.5: Stuck チェック
 
@@ -412,7 +490,7 @@ Glob で `.claude/reports/debug-needed-*.md` の最新を確認する。
 **ファイルが存在する場合:**
 1. Agent ツールで `systematic-debugger` を起動する。プロンプトに debug-needed ファイルのパスのみを含め、内容は agent 側で Read させる（プロンプトに直接展開しない）[SR-AI-001]
 2. 生成された `.claude/reports/debug-analysis-*.md` を Glob で取得してパスのみコンテキストに保持する（内容は次段で agent に Read させる）
-3. D-2 の developer を再実行する。プロンプトに debug-analysis の**ファイルパスのみ**を含め、内容は agent 側で Read させる（プロンプトに展開しない）[SR-AI-001]
+3. D-2 の developer を再実行する（`model:` に推奨 Tier を指定・上記「tier-routing 結果記録の運用」節参照）。プロンプトに debug-analysis の**ファイルパスのみ**を含め、内容は agent 側で Read させる（プロンプトに展開しない）[SR-AI-001]
 4. debug-needed ファイルを削除する
 
 **ファイルが存在しない場合:** そのまま次へ進む
@@ -433,8 +511,23 @@ AskUserQuestion で確認する:
 
 承認後 → セッションファイルの `- [ ] developer: Green フェーズ` を `- [x]` に Edit し、`現在地:` を `現在地: フェーズD 実装中 / 次: Refactor` に Edit する（**bug-fix モードではこの Edit をスキップする**。D-2 で `- [ ] developer: 修正実装` を既に `[x]` 化済みのため、Green フェーズ行自体がセッションファイルに存在しない）。
 
+**tier-routing 結果記録**:
+```bash
+python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+  --role developer --outcome success --gate D-2.5 \
+  --execution subagent --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+  --task {plan タスクID}
+```
+
 **知識蓄積:**
-- 「否認・再実装を依頼する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+- 「否認・再実装を依頼する」「否認・自分でコードを修正する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+- **tier-routing 結果記録（否認時）**:
+  ```bash
+  python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+    --role developer --outcome failure --gate D-2.5 \
+    --execution subagent --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+    --task {plan タスクID}
+  ```
 
 ### D-3: tester（確認）
 
@@ -456,9 +549,17 @@ AskUserQuestion で確認する:
 
 不合格の場合: D-2（developer）に戻る。合格するまで繰り返す。
 
+**tier-routing 結果記録（不合格時のみ・D-2.5 と重複回避のため全合格時は記録しない・欠陥の所在で判定）**: D-5 否認ブロックと同型で、テストコード欠陥は `tester` failure、プロダクトコード欠陥は `developer` failure、両方または判別不能な場合は `developer` のみ記録する:
+```bash
+python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+  --role {tester|developer（欠陥の所在で判定・テストコード欠陥=tester／プロダクトコード欠陥=developer／両方または判別不能=developer）} --outcome failure --gate D-3 \
+  --execution subagent --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+  --task {plan タスクID}
+```
+
 ### D-4: developer（Refactor フェーズ）
 
-Agent ツールで `developer` エージェントを起動する。→ テストを壊さずにコードを整理する。
+Agent ツールで `developer` エージェントを起動する（`model:` に推奨 Tier を指定・上記「tier-routing 結果記録の運用」節参照）。→ テストを壊さずにコードを整理する。
 
 完了後 → セッションファイルの `- [ ] developer: Refactor フェーズ` を `- [x]` に Edit し、`現在地:` を `現在地: フェーズD 実装中 / 次ゲート: tester 最終確認` に Edit する。
 
@@ -482,8 +583,21 @@ AskUserQuestion で確認する:
 
 承認後 → セッションファイルの `- [ ] tester: 最終確認` を `- [x]` に Edit し、`現在地:` を `現在地: フェーズE レビュー中` に Edit して**フェーズ E** へ。
 
+**tier-routing 結果記録**:
+```bash
+python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+  --role tester --outcome success --gate D-5 \
+  --execution subagent --complexity {セッションファイルの tier-routing複雑度: 行の値}
+```
+
 **知識蓄積:**
-- 「否認・修正を依頼する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+- 「否認・修正を依頼する」「否認・自分でコードを修正する」: `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する
+- **tier-routing 結果記録（否認時・欠陥の所在で判定）**: テストコード欠陥は `tester` failure、プロダクトコード欠陥は `developer` failure、両方または判別不能な場合は `developer` のみ記録する:
+  ```bash
+  python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+    --role {tester|developer（欠陥の所在で判定）} --outcome failure --gate D-5 \
+    --execution subagent --complexity {セッションファイルの tier-routing複雑度: 行の値}
+  ```
 
 ---
 
@@ -525,6 +639,13 @@ AskUserQuestion で確認する:
 
 承認後 → セッションファイルの `- [ ] code-review` を `- [x]` に Edit し、`現在地:` を `現在地: フェーズE レビュー中 / 次: security-review` に Edit して E-2 へ。
 
+**tier-routing 結果記録**:
+```bash
+python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+  --role developer --outcome success --gate E-1 \
+  --execution subagent --complexity {セッションファイルの tier-routing複雑度: 行の値}
+```
+
 **指摘がある場合:**
 指摘一覧をテキストで提示してから AskUserQuestion で方針を確認する:
 ```json
@@ -544,6 +665,16 @@ AskUserQuestion で確認する:
 **「全て対応する」の場合:**
 全指摘に `> **[対応予定]**` をマークし、セッションファイルの `- [ ] code-review` を `- [x]` に Edit し、`現在地:` を `現在地: フェーズC 計画中（レビュー差し戻し）` に Edit してから**フェーズ C** へ（内部遷移・Step 0 なし）。
 
+**tier-routing 結果記録（帰属判定）**: 指摘内容から最上流起因 role を判定し failure を記録する（デフォルト developer・迷ったらこれ／**テストコード欠陥起因の指摘は tester failure**／設計不備なら architect／計画不備なら planner。`--note` に理由必須。developer・tester は `--execution subagent`、architect/planner は `--execution persona`。developer・tester は `--tier` を省略（frontmatter/tier_selection から自己解決）、architect/planner の場合は `--tier` も明記する）:
+```bash
+python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+  --role {developer|tester|architect|planner（帰属判定）} --outcome failure --gate E-1 \
+  --execution {developer・tester=subagent / architect・planner=persona} \
+  --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+  --tier {developer・tester は省略（frontmatter/tier_selection から自己解決） / architect・planner は親モデルのtier名（haiku/sonnet/opus）。判別不能なら unknown} \
+  --note "{帰属理由を1行で（コード断片の逐語引用禁止）}"
+```
+
 **「対応する指摘を選ぶ」の場合:**
 続けて AskUserQuestion で確認する:
 ```json
@@ -566,6 +697,15 @@ AskUserQuestion で確認する:
    ```
 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` を省略（frontmatter/tier_selection から自己解決）、architect/planner の場合は `--tier` も明記する）:
+   ```bash
+   python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+     --role {developer|tester|architect|planner（帰属判定）} --outcome failure --gate E-1 \
+     --execution {developer・tester=subagent / architect・planner=persona} \
+     --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+     --tier {developer・tester は省略（frontmatter/tier_selection から自己解決） / architect・planner は親モデルのtier名（haiku/sonnet/opus）。判別不能なら unknown} \
+     --note "{帰属理由を1行で（コード断片の逐語引用禁止）}"
+   ```
 
 **「全て許容して進む」の場合:**
 AskUserQuestion で許容理由を確認する:
@@ -580,10 +720,17 @@ AskUserQuestion で許容理由を確認する:
 2. **review-hint 判断記録**: 全 `[CR-XX-NNN]` 指摘について `record_review_decision.py --decision accepted` で記録する
 3. セッションファイルの `## うまくいったアプローチ` に `[許容例外] {指摘内容} → {許容理由}` の形式で追記し `patterns` に記録する
 4. セッションファイルの `- [ ] code-review` を `- [x]` に Edit し、`現在地:` を `現在地: フェーズE レビュー中 / 次: security-review` に Edit して E-2 へ。
+5. **tier-routing 結果記録**:
+   ```bash
+   python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+     --role developer --outcome success --gate E-1 \
+     --execution subagent --complexity {セッションファイルの tier-routing複雑度: 行の値}
+   ```
 
 **「否認・再レビューを依頼する」の場合:**
 追加の AskUserQuestion でフィードバックを確認し再実行する。
 セッションファイルの `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する。
+**tier-routing 結果記録**: なし（否認・再レビュー依頼は記録対象外）。
 
 ---
 
@@ -620,9 +767,13 @@ AskUserQuestion で確認する:
 ```
 
 承認後 → セッションファイルの `- [ ] security-review` を `- [x]` に Edit し、`現在地:` を `現在地: 完了` に Edit する。続けて **「引き継ぎバックログの照合」**（後述の共通ステップ）を実行してからコミットを提案する。
-**tier-routing 結果記録**: フェーズ E の最終承認時のみ Bash で記録する（多重カウント防止のため E-1 では記録しない）:
+
+**tier-routing 結果記録**:
 ```bash
-python .claude/skills/dev-workflow/scripts/record_tier_outcome.py --outcome success
+python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+  --role developer --outcome success --gate E-2 \
+  --execution subagent --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+  --final
 ```
 
 **指摘がある場合:**
@@ -644,6 +795,16 @@ python .claude/skills/dev-workflow/scripts/record_tier_outcome.py --outcome succ
 **「全て対応する」の場合:**
 全指摘に `> **[対応予定]**` をマークし、セッションファイルの `- [ ] security-review` を `- [x]` に Edit し、`現在地:` を `現在地: フェーズC 計画中（レビュー差し戻し）` に Edit してから**フェーズ C** へ（内部遷移・Step 0 なし）。
 
+**tier-routing 結果記録（帰属判定）**: 指摘内容から最上流起因 role を判定し failure を記録する（デフォルト developer・迷ったらこれ／**テストコード欠陥起因の指摘は tester failure**／設計不備なら architect／計画不備なら planner。`--note` に理由必須。developer・tester は `--execution subagent`、architect/planner は `--execution persona`。developer・tester は `--tier` を省略（frontmatter/tier_selection から自己解決）、architect/planner の場合は `--tier` も明記する）:
+```bash
+python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+  --role {developer|tester|architect|planner（帰属判定）} --outcome failure --gate E-2 \
+  --execution {developer・tester=subagent / architect・planner=persona} \
+  --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+  --tier {developer・tester は省略（frontmatter/tier_selection から自己解決） / architect・planner は親モデルのtier名（haiku/sonnet/opus）。判別不能なら unknown} \
+  --note "{帰属理由を1行で（コード断片の逐語引用禁止）}"
+```
+
 **「対応する指摘を選ぶ」の場合:**
 続けて AskUserQuestion で確認する:
 ```json
@@ -666,6 +827,15 @@ python .claude/skills/dev-workflow/scripts/record_tier_outcome.py --outcome succ
    ```
 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` を省略（frontmatter/tier_selection から自己解決）、architect/planner の場合は `--tier` も明記する）:
+   ```bash
+   python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+     --role {developer|tester|architect|planner（帰属判定）} --outcome failure --gate E-2 \
+     --execution {developer・tester=subagent / architect・planner=persona} \
+     --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+     --tier {developer・tester は省略（frontmatter/tier_selection から自己解決） / architect・planner は親モデルのtier名（haiku/sonnet/opus）。判別不能なら unknown} \
+     --note "{帰属理由を1行で（コード断片の逐語引用禁止）}"
+   ```
 
 **「全て許容して完了」の場合:**
 AskUserQuestion で許容理由を確認する:
@@ -682,22 +852,16 @@ AskUserQuestion で許容理由を確認する:
 4. セッションファイルの `- [ ] security-review` を `- [x]` に Edit し、`現在地:` を `現在地: 完了` に Edit する。続けて **「引き継ぎバックログの照合」**（後述の共通ステップ）を実行してからコミットを提案する。
 5. **tier-routing 結果記録**: 全許容で完了するのも「成功」としてカウント:
    ```bash
-   python .claude/skills/dev-workflow/scripts/record_tier_outcome.py --outcome success
+   python .claude/skills/dev-workflow/scripts/record_agent_outcome.py \
+     --role developer --outcome success --gate E-2 \
+     --execution subagent --complexity {セッションファイルの tier-routing複雑度: 行の値} \
+     --final
    ```
 
 **「否認・再診断を依頼する」の場合:**
 追加の AskUserQuestion でフィードバックを確認し再実行する。
 セッションファイルの `## 試みたが失敗したアプローチ` に教訓をルール形式で追記し `patterns` に追加する。
-**tier-routing 結果記録**: 否認は「失敗」としてカウント:
-```bash
-python .claude/skills/dev-workflow/scripts/record_tier_outcome.py --outcome failure
-```
-
-**「全て対応する」「対応する指摘を選ぶ」の場合（フェーズ C へ戻る）:**
-これらも tier の選択がコスト最適でなかったとみなし、**tier-routing 結果記録**で失敗をカウントしてからフェーズ C へ:
-```bash
-python .claude/skills/dev-workflow/scripts/record_tier_outcome.py --outcome failure
-```
+**tier-routing 結果記録**: なし（否認・再診断依頼は記録対象外）。
 
 ---