claude-code-conductor 2.52.0__tar.gz → 2.53.0__tar.gz

{claude_code_conductor-2.52.0 → claude_code_conductor-2.53.0}/.claude/CLAUDE.md

@@ -31,6 +31,8 @@
 
 コンテキストに応じて選択肢を追加してよい。
 
+自律モード（autonomous-mode skill・opt-in 必須）が有効な場合のみ、上記の承認ゲートは同 skill のゲート対応表に従って客観条件へ付け替わる。既定は常に HITL であり、opt-in なしに挙動が変わることはない（ただしこれは文書規約レベルの不変則であり、モード行挿入自体を機械的に承認と紐付ける仕組みではない。詳細は SKILL.md「モード行挿入の前提条件（不変則）」を参照）。
+
 ## Compact Instructions
 
 ### KEEP（保持する）
@@ -61,4 +63,6 @@
 - **`Skill` ツール / `/<skill>`** の参照は、Codex では `.agents/skills/<name>/SKILL.md`、Cursor では `.claude/skills/<name>/SKILL.md` を直接読み込む。OpenCode では `.opencode/agents/c3-skill-<name>.md`（`.claude/skills/<name>/SKILL.md` を本文に埋め込み済み）を `@mention` で起動する（スラッシュコマンド自動展開は Claude Code 専用機能）
 - **`isolation: worktree`** / **`permissionMode`** / **`tools` 制限** など agent フロントマターの一部キーは Claude Code 仕様。adapter 側では読み替え不能なものは無視される（OpenCode adapter は全 agent に `bash/read/edit/write/websearch` を一律付与する）
 
+- **自律モード**: autonomous-mode は Claude Code 専用。Codex / Cursor / OpenCode では自律宣言は常に無効＝HITL で動作する（モード行の検証は `mode_line.py`・Bash 経由に依存し、他プラットフォームで安全に再現できないため。検証できない → HITL の fail-closed 原則がそのまま正しい挙動になる）。adapter 生成物にも autonomous-mode skill は写像されない。
+
 レポート（`.claude/reports/`）・state（`.claude/state/`）・memory（`.claude/agent-memory/`）のファイル名と書き込み先は全プラットフォーム共通。adapter 生成物の詳細は `c3 init --platform codex|cursor|opencode` で出力される `AGENTS.md` / `.cursor/rules/c3-core.mdc` / `.opencode/agents/` を参照。

claude_code_conductor-2.53.0/.claude/docs/autonomous-mode-onboarding.md

@@ -0,0 +1,102 @@
+# 自律モード オンボーディング
+
+C3 の「自律モード（autonomous mode）」を初めて使う人向けの導入ガイド。
+**手順と心構え**だけを書く。数値・条件・文法の厳密な定義は規約 SSOT である
+`.claude/skills/autonomous-mode/SKILL.md` を参照すること（本文書は規約を再定義しない）。
+
+> このガイドは `.claude/docs/` 配下の人間向けリファレンス。エージェントが実行時に読む必要はない。
+
+---
+
+## ① 自律モードとは
+
+自律モードは、C3 標準ワークフローの承認ゲート（レポート承認・テスト承認・findings 分岐など）を、
+ユーザーが承認した**委任プラン**に従って客観条件で自動進行させる運転モードである。
+
+- **既定は常に HITL（Human In The Loop）**。何もしなければ従来どおり各フェーズで承認を求める。
+- 有効化には**二重の opt-in** が必要:
+  1. プランモードで「資源同意節を含む委任プラン」をユーザーが承認する
+  2. その承認直後に、親 Claude がセッションファイルへ**モード行**を挿入する
+- opt-in なしに挙動が変わることはない（誤発動ゼロを最優先に設計されている）。
+  ただしこれは文書規約レベルの不変則であり、モード行の挿入自体がセレモニー経由であることを機械検証する仕組みではない
+  （既知の限界は SKILL.md「モード行挿入の前提条件（不変則）」を参照）。
+
+---
+
+## ② 正しい始め方
+
+**プランモードを先に通すのが唯一の正しい入口**。順序を守ること。
+
+1. **プランモードで委任プランを作る**。プランには固定様式の `## 資源同意` 節を含める
+   （ハード上限・起動体数の見込み・「承認をもって資源消費に同意」の 3 点。様式は SKILL.md の
+   「委任プランの必須節（資源同意）」を参照）。
+2. **プランを承認する**。この承認が「資源消費への同意」の成立点になる。
+3. 承認直後に、親 Claude が `現在地:` 行の直後へモード行を挿入する。初期形は
+   `モード: 自律 plan=<委任プランの絶対パス> cycles=C-3/0,E/0`（`cycles=` は opt-in 時に発効し初期値は両ゲート 0）。
+
+**よくある誤り**:
+
+- **`/start` を先に叩くのは誤り**。標準ワークフローを HITL で走らせてしまい、自律モードにはならない。
+  自律運転は「プランモード承認 → モード行挿入」を経てから、init-session（セッション交代・コンパクト後）が
+  モード行を読んで継続する形で成立する。
+- 資源同意節を欠くプランで opt-in を成立させてはならない（欠落時は人間へ確認＝関所 2）。
+
+---
+
+## ③ 質問が来るのは設計どおり
+
+自律運転中でも人間に質問が返ってくることがある。これは**故障ではなく設計どおりの安全装置**である。
+以下の 2 類型（人間の関所）は自律モードでも自動選択せず、必ず人間が判断する。
+
+| 類型 | 具体例 | なぜ人間のままか |
+|---|---|---|
+| **非可逆操作** | git commit / push / tag / release・ファイル削除 | 取り消せない操作は最後の人間判断を残す（検証用ビルド足場の作成・後始末は含まない） |
+| **情報不足の質問** | task-question（このタスクに不足する情報）／ axis-question（以後の全タスクに効く方針） | 情報の欠落は自動では埋められない |
+
+加えて、E フェーズ最終承認後の**引き継ぎバックログ照合**と**コミット提案**はコミット直前＝人間の関所領域であり、
+自律でも AskUserQuestion を出して自動選択しない。
+
+「質問が来た＝暴走していない」と受け止めてよい。
+
+---
+
+## ④ 止まり方（上限到達時の流れ）
+
+自律運転は無限に回らない。C-3 監査・E レビューにはサイクル上限があり、到達すると次の流れで止まる。
+
+1. **上限到達**（例: C-3 が上限サイクルまで回っても High/Medium が 0 に収束しない）
+2. **状態保全**: ワーキングツリー・レポート群をそのまま残す（調査可能な形で保全）
+3. **報告**: 収束または打ち切りで初めてまとめて人間へ報告する（逐一停止はしない）
+4. **裁定**: 人間が続行・方針変更・打ち切りを判断する
+5. **再開**: 裁定を受けて運転を継続、または HITL へ復帰する
+
+実例（B1 実走）: E→C 差し戻し後に同一カウンタで早期に上限へ到達し、運転が止まった事例がある。
+この経験から「差し戻しごとに小上限の別枠を付与する」規定が入った（詳細と数値は SKILL.md 参照）。
+止まること自体は異常ではなく、上限に守られて安全側に倒れた結果である。
+
+---
+
+## ⑤ C-3 収束 ≠ 欠陥ゼロ
+
+**C-3 監査が収束しても、それは「欠陥がゼロになった」ことを意味しない。**
+C-3 の収束条件が保証する射程は、**その時点の計画の健全性**に限られる。
+
+- **実測の裏付け**: C-3 が収束（High/Medium 0）した後の E レビューで、実装バグが実際に発見された事例がある。
+  収束は「設計・計画レベルで High/Medium の指摘が消えた」ことであって、実装が正しいことの証明ではない。
+- **構造的な限界**: C-3 を担う design-critic は **Bash を持たず、コードを実行して検証できない**
+  （静的な読解のみ）。エスケープ処理・パーサ・状態機械のような組み合わせロジックの欠陥は、
+  静的読解では原理的に取りこぼしうる。
+- **最後の網は E の実行検証**: テスト実行を伴う E フェーズ（およびテスト全緑を客観条件とする D）が、
+  実装バグに対する最後の防波堤になる。C-3 収束を「もう安全」と読み替えないこと。
+
+---
+
+## ⑥ 従量課金ユーザー向け注記
+
+`## 資源同意` 節への承認は、**費用への同意を兼ねる**。
+
+- **定額プラン**では、資源同意は主に「残枠（サイクル回数）の消費」を意味する。
+- **従量課金（API 等）**では、資源同意は**費用の発生への同意**を意味する。
+- **重要**: ハード上限が担保するのは**サイクル回数**であって費用ではない。
+  D のタスク数はプラン依存で可変、stuck 時は systematic-debugger が加算され、E→C 差し戻しごとに D 相当が再走する。
+  **費用の上界は規約では担保されない**。従量課金で使う場合は、この点を理解した上で opt-in すること。

claude_code_conductor-2.53.0/.claude/skills/autonomous-mode/SKILL.md

@@ -0,0 +1,348 @@
+---
+description: 自律モード（autonomous mode）の操作規約・ゲート対応表・モード行文法・質問出口定義・運用規約。dev-workflow の SSOT。
+user-invocable: false
+disable-model-invocation: true
+---
+
+# Autonomous Mode
+
+C3 標準ワークフロー（`.claude/skills/dev-workflow/SKILL.md`）をユーザーが明示的に承認した委任プランに従い、
+承認ゲートを客観条件で自動進行する「自律モード」の規約書。本ファイルが**唯一の規約 SSOT（Single Source of Truth）**。
+
+---
+
+## モード行文法と有効性判定
+
+### BNF 風文法
+
+```
+mode-line        ::= "モード: " mode-value LF
+mode-value       ::= autonomous-decl | "HITL"        ; 行が無い/空/"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 を 1 セットとした周回集約 ID。承認ゲート E-1/E-2 とは別語彙（DC-GP-004）
+SP               ::= " "
+LF               ::= "\n"
+DQUOTE           ::= '"'
+pchar            ::= <all printable chars except DQUOTE>
+```
+
+### 具体例
+
+```
+モード: 自律 plan=<ホームディレクトリ>\.claude\plans\dazzling-cooking-dusk.md
+モード: 自律 plan=~/.claude/plans/dazzling-cooking-dusk.md cycles=C-3/2,E/1
+モード: 自律 plan="<ホームディレクトリ>\.claude\plans\my plan.md"
+モード: 自律 plan="~/.claude/plans/my plan.md" cycles=C-3/5+2+1,E/1
+モード: HITL
+```
+
+### 有効性判定（3 条件・すべて満たすときのみ有効）
+
+1. 行が `モード: 自律 ` で始まる
+2. `plan=` トークンがあり `plan-path` が非空
+3. `plan-path`（絶対パス／`~/.claude/plans/` 展開形）を§後述「パス用 choke point」の封じ込め検査に通し、許可ルート配下に正規化できたうえで、指すファイルが**実在する**（`Read` で存在確認できる）
+
+**→ `plan=` を欠く「モード: 自律」単体は無効（誤発動ゼロの最優先）**。
+存在しない plan・許可ルート外を指す行も無効化される。init-session は「モード行が無効（プラン不在／許可ルート外）→ HITL で継続」を明示表示する。
+
+---
+
+## ゲート対応表（SSOT 本体）
+
+承認ゲート **10 個**（**A-4 / B-3 / C-1 / C-2 / C-3 / D-2.5 / D-3 / D-5 / E-1 / E-2**）の動作対応。
+D-0（実行モード自動判別）は AskUserQuestion を持たないステップのため承認ゲート集合に含めない（別枠注記）。
+
+| ゲート | HITL（既定） | 自律モード |
+|---|---|---|
+| **A-4** | レポート承認 AskUserQuestion | **要点をテキスト提示して自動で次フェーズへ**（レポートは通常どおり Write・記録も通常どおり） |
+| **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 記録は通常どおり |
+| **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 周・周回数カウント）** |
+
+#### 注記と例外
+
+**D-0（実行モード自動判別）は承認ゲートではない**（別枠）: D-0 は AskUserQuestion を一切持たない Glob/Bash 判定ステップであり、
+承認ゲート 10 個の集合には含めない。自律モードでも**判別ロジックは不変**（HITL と同じ）で、ゲート付け替えの対象ではない。
+
+**findings 分岐の固定**（C-3 / E-1 / E-2 共通）: これら 3 ゲートの findings 分岐 AskUserQuestion には HITL で
+「全て対応する／対応する指摘を選ぶ／全て許容して進む／再監査（再レビュー）」の選択肢があるが、
+**自律モードでは原則「全て対応する」を選ぶ**。「全て許容して進む」を選んでよいのは、
+**C-3 において High/Medium が 0 で Low のみが残ったサイクル（＝C-3 の収束条件を満たした場合）に限る**。
+**この例外は C-3 に限る**。E-1 / E-2 にはこの例外を適用しない（従来どおり「全て許容」を選ばない）。
+**High/Medium を許容で流すことは引き続き構造的に禁じる**（空収束防止）。
+許容という価値判断がこの例外に当てはまらない場合は、従来どおり**人間の関所へエスカレーション**する。
+
+**収束サイクルに残った Low の扱い**（C-3 のみ）:
+
+| サイクルの状態 | 分岐 |
+|---|---|
+| High/Medium が 1 件以上 | 従来どおり「全て対応する」を選ぶ（Low も含めて `[対応予定]`）。層別ルーティングで上流へ戻る＝未収束 |
+| High/Medium 0・Low が 1 件以上（＝収束） | 残る Low を「全て許容して進む」で処理する。許容理由は「C-3 収束条件（High/Medium 0）を満たしたため、残る Low は実装フェーズ以降で扱う」と記録し、`record_review_decision.py --decision accepted` で残す。フェーズ D へ進む |
+| findings 0 | そのままフェーズ D へ |
+
+**cycles_used の定義**: E は**周回数**。CR∥SR 並列 1 セット＋修正＝1 サイクル。
+`cycles=` トークンの `E` は E-1+E-2 を 1 セットとした周回集約 ID（承認ゲート ID の E-1/E-2 とは別語彙）。
+
+**上限到達時**: 途中成果を保全（ワーキングツリー・レポート群）した状態で人へ報告（調査可能な形）。
+収束 or 打ち切りで初めてまとめて報告（逐一停止しない）。
+
+#### 人間の関所（2 類型・不変則）
+
+以下の 2 種類は常に人間が AskUserQuestion で判断する（自律モードでも自動選択しない）:
+
+1. **非可逆操作**（git commit/push/tag/release・ファイル削除）は常に人間のまま。
+   - **検証用ビルド足場の作成と後始末は含まない**（`git worktree add/remove`・`dist/` 空化・一時ファイル）
+
+2. **情報不足の質問**（質問出口に人間が必要な場合・下記「質問プロトコル」参照）は人間のまま
+
+#### ソース変更の実施主体（不変則）
+
+**原則**: 自律運転中、親 Claude による直接編集を禁じ、ファイル変更は担当エージェントが行う
+（**実装は developer**／テストコードと test-report は tester）。
+E findings の修正も「C 差し戻し → D-2 developer」の正規ルートを必ず通る。
+
+**例外**: なし。軽微修正であっても、また修正の必要が**親自身の誤指示に由来する場合であっても**、
+親 Claude による直接 Edit は禁止する。**例外は置かない**。
+
+**理由**: 自分のミスの是正であることは、**独立実装レイヤーを外す理由にならない**。
+むしろ直前に判断ミスを示した当人であるほど、独立した実装者を通す価値が高い。
+
+**親の職掌（閉じた列挙）**: 以下 5 種**のみ**が親の直接操作を許される。
+**列挙外のファイル変更**はすべて担当エージェント経由とする（実装・ソースは developer ／ テストコードと test-report は tester）:
+
+1. `.claude/reports/` 配下のうち、**親 Claude がペルソナとして執筆するレポート**（requirements-report / architecture-report / plan-report）の Write。
+   および**既存レポートへの findings マーク**（`[対応予定]` / `[許容]` の追記）。
+   **担当エージェントが生成するレポートの本文 Write は含まない**
+   （test-report ＝ tester ／ code-review-report ＝ code-reviewer ／ security-review-report ＝ security-reviewer ／ design-review-report ＝ design-critic）
+2. 記録スクリプトの実行（`record_agent_outcome.py` / `record_review_decision.py` / `review_hint_inject.py`）
+3. `.claude/memory/sessions/*.tmp`（セッションファイル）の更新
+4. `.claude/reports/loop-impl-gaps-*.md`（gaps 台帳）への追記
+5. git 操作のうち**非可逆操作**（commit / push / tag / release・ファイル削除）は**人間の関所 1 の下でのみ**。
+   ただし**検証用ビルド足場は関所の対象外**であり（`git worktree add/remove`・`dist/` 空化・一時ファイル）、親が実施してよい
+
+**リリース手続きの主体**: CHANGELOG.md の追記は developer 経由
+（`.claude/breaking-changes.txt` / `.claude/deletions.txt` の更新も同じく列挙外＝developer 経由）。
+タグ・push・Release は**人間の関所 1**。
+
+**逸脱時の処置**: まず**親の直接変更を破棄してから再実行する**
+（tracked ファイルは `git checkout -- <path>`／非追跡ファイルは変更前の退避があれば復元し、無ければ関所 2 へ倒して人間の判断を仰ぐ）。
+そのうえでフェーズ別に:
+
+- **D 中の逸脱** → 当該タスクを developer で再実行
+- **C-3 中の逸脱** → 当該サイクルを無効化して再監査
+- **E 中の逸脱** → 当該周回の収束判定を無効として周回をやり直す
+
+いずれの場合も gaps 台帳へ 1 行記録する。
+
+#### E-1/E-2 の並列と合流点（join）
+
+- CR∥SR は「起動」のみ並列し、両 reviewer が完了した後に以下を所定順で逐次実行:
+  1. `review_hint_inject.py` に**CR・SR 両レポートのパス**を渡して呼ぶ（両レポート必須のため join 後）
+  2. 重複指摘フラグ判定（同上・両レポートが揃ってから）
+  3. tier-routing 記録は**E-1 / E-2 それぞれ個別の gate**（`--gate E-1` / `--gate E-2`）で各 reviewer 分をそれぞれ呼ぶ
+
+#### 引き継ぎバックログ照合（E 最終承認後・コミット直前）
+
+人間のまま。コミット直前＝人間の関所領域。自律でも AskUserQuestion を出し自動選択しない。
+
+---
+
+## ライフサイクル
+
+| 時点 | 動作 | 担当 |
+|---|---|---|
+| opt-in（プランモードで**資源同意節を含む委任プラン**を承認） | `現在地:` 直後にモード行を Edit 挿入する。具体形は `モード: 自律 plan=<絶対パス> cycles=C-3/0,E/0`（`plan=` は絶対パス／`~/.claude/plans/` 形）。**cycles= の発効時点は opt-in 時・初期値は両ゲートとも 0** | 親 Claude |
+| セッション交代・コンパクト後 | init-session が `モード:` 行を Read → 有効なら本 skill を Read して運転継続 | init-session |
+| 収束 or 打ち切り（フェーズ E 完了 / 上限到達で人へ報告） | `モード:` 行を削除（＝HITL 復帰）。cycles トークンも同時に消える | 親 Claude |
+| 日付跨ぎ（新セッションファイル生成） | `_inherit_backlog` は `モード:` を運ばない → 自動的に HITL 既定 | stop.py（既存・変更なし） |
+
+#### モード行挿入の前提条件（不変則）
+
+**モード行の挿入は人間が委任プランを承認した直後に限る**。
+
+- **理由**: モード行の有効性判定（3 条件）は「plan が構文的に正しく実在するか」しか検証せず、
+  **正規のプランモード承認セレモニーを経たかは検証しない**。
+  session.tmp へのモード行挿入自体は親の職掌（item 3）で無条件に許可されているため、
+  判定を通る形のモード行が承認なしに書かれると自律運転が成立してしまう。
+  R1 で走行中の usage 停止を全廃した結果、この場合に**コミット直前まで人間が一度も介在しない**状態まで露出が広がった
+- **限界**: これは文書上の不変則であり**機械的強制ではない**。
+  有効性判定への組み込みは `mode_line.py` の変更を要し、今回の不変条件（コード変更なし）に反するため採らない。
+  機械的な承認バインドは配布切替タスクまたは独立タスクで扱う
+
+**設計判断**: 日付跨ぎで自律が自動継続しないのは「揮発耐性」と一見矛盾するが、
+**同一タスクは同日内に完結する運用**であり、かつ「自律の自動継続を跨がせない」ことは
+**誤発動ゼロ（最優先）**側に倒す安全策。跨ぐ場合は新セッションで再度 opt-in を求める。
+
+---
+
+## 委任プランの必須節（資源同意）
+
+自律 opt-in の対象となる委任プランには、以下の**固定様式**で `## 資源同意` 節を含める。
+opt-in は plan-report 生成前（フェーズ A 以前）に行われるため、その時点で確定していない値は書かせず、
+「確定値」と「計画フェーズで確定する値」を書き分ける。
+
+```
+## 資源同意
+
+- ハード上限: C-3 = 最大 5 サイクル（初回）/ 差し戻し後は 2 サイクルの別枠（最大 4 回・総量 13 上界）/ E = 最大 5 周（autonomous-mode SKILL.md からの転記）
+- 起動体数の見込み:
+  - C-3: 最大 5 体（design-critic・初回）+ 最大 8 体（差し戻し後の再監査。最大 4 回 × 2 サイクル）
+  - E: 最大 10 体（code-reviewer + security-reviewer × 5 周）
+  - D: タスク数 × 2（developer + tester）。タスク数は計画フェーズ C で確定する
+  - 差し戻し・stuck 発生時は上記に加算される
+- 承認をもって上記の資源消費に同意したものとする。走行中の usage 確認による停止は行わない。
+```
+
+| 規約 | 内容 |
+|---|---|
+| **SSOT 優先** | 転記値はあくまで提示であり、**執行値は常に SSOT が優先**する（SSOT ＝ 本 skill）。プラン側の記載が SSOT と食い違うことを発見した場合は、値を上書きせず**関所 2（情報不足の質問）へ倒す** |
+| **回数と費用の区別** | ハード上限が担保するのは**サイクル回数**であって費用ではない。D のタスク数は plan 依存で可変、stuck 時は systematic-debugger が加算され、E→C 差し戻しごとに D 相当が再走する。**定額プランでは残枠、従量課金では費用の同意を意味する。費用の上界は規約では担保しない** |
+| **見込み超過時** | 計画フェーズ C で確定したタスク数が資源同意節の想定を大きく超える場合（目安: **D の起動体数が 2 倍以上**）、**関所 2 として人間へ確認する**。新しい関所を増やすのではなく、既存の関所 2 の適用として扱う |
+| **C-2 時点の提示** | plan 確定時に D の見込み体数が確定するため、**C-2 で 1 度だけテキスト提示**する（提示のみ・停止しない） |
+
+### 有効性判定への非組み込みと不変則
+
+資源同意節の有無は、モード行の**有効性判定 3 条件には加えない**。
+
+- **理由 1**: 判定に加えるとプラン本文のパースが必要になり、`mode_line.py` の変更＝検査系の回帰リスクを招く
+- **理由 2**: 資源同意は opt-in の瞬間に成立する契約であり、承認済みプランはユーザー管理領域にあって封じ込め検査を通過している
+
+**不変則**: 親 Claude は**資源同意節を欠くプランで自律 opt-in を成立させてはならない**。欠落を発見した場合は関所 2 へ倒す。
+
+**移行規定**: 本改訂前に承認された委任プランは資源同意節を持たない。改訂後も有効性判定は通るため、
+放置すると「資源同意を一度も取得せず、かつ走行中の停止も廃止された」状態が成立する。したがって
+**復帰のたびに資源同意節の有無を確認する**（init-session 経由でモード行から運転を継続する時）。
+無ければ関所 2 へ倒し、人間の確認を得てから継続する。
+「1 度だけ」を採らないのは、復帰が 1 運転中に何度も起きる（コンパクト・セッション交代）ためであり、
+判定は資源同意節の存在を Read で見るだけなので毎回実行してもコストは Read 1 回に収まる。
+
+---
+
+## cycles トークンの位置づけ
+
+**cycles= は自律運転中は必須**。E フェーズの「CR∥SR 並列 1 セット＋修正＝1 周」と C-3 のサイクル数を、
+コンパクト後も復元するためのフィールド。
+
+- **更新の不変則**: C-3 の各サイクル完了時・E の各周回完了時に、モード行の cycles= を Edit で更新する
+- **表記の拡張**: 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 という二層関係であり矛盾しない
+- **執行の限界**: ハードリミットの執行点は親 Claude が本 skill の上限（C-3 初回 5 / 差し戻し後 2 / E=5）と突き合わせて判断する。**執行はソフト規約であり機械執行ではない**。cycles= を欠いたまま揮発すると 0 起点で再カウントされる。更新主体と揮発原因がともに親であるため、**更新漏れは構造的に残る**
+- **復帰時チェック（資源同意節と対称）**: **復帰のたびに cycles= の有無を確認する**。欠落していれば関所 2 へ倒す。欠落は検出できるが**値の正しさは検証できない**
+
+---
+
+## 質問プロトコル（型定義）
+
+自律モードでも人間へ出す質問は、以下の 2 型に分類して処理する（宛先写像の実装は非スコープ）:
+
+| 型 | 寿命 | 所有者（概念） | 意味 |
+|---|---|---|---|
+| **task-question** | タスク寿命 | 餌の著者（当該タスクの発注者） | この 1 タスクを完了するのに不足している情報。回答はタスク完了で消費される |
+| **axis-question** | プロジェクト寿命 | 軸の所有者（プロジェクト方針の決定者） | 以後の全タスクに効く判断原則。回答は軸（`axis.md` / rules）へ昇格し得る |
+
+**両型とも人間へ AskUserQuestion で出す**（質問出口は人間のまま）。
+
+---
+
+## 運用規約
+
+自律運転中は以下を遵守する:
+
+- **ギャップ記録**: 構想とのギャップが見つかった場合、`loop-impl-gaps-*.md` に 1 行追記する
+
+- **レビューレポート件数の再集計**: 周回時に指摘件数を転記し、再度手で数え直して確認する
+  （「レビュアーは数え間違える」法則への当面の手当て）。
+  C-3 でも同じ規律を適用し、収束判定の前に **design-review-report の High/Medium 件数**を本文から数え直してサマリ表の数値と突合する。
+  さらに C-3 では、件数の数え直しに加えて **High/Medium 0 と判定したサイクルに限り**、
+  **Low に落ちている findings の重要度が妥当か**を親が 1 度確認する。妥当性に疑義があれば**収束させず次サイクルへ回す**。
+  これは R3（収束条件を High/Medium 0 へ緩和）が受容したトレードオフに対する唯一の担保であり、
+  design-critic の重要度付与が粗く、本来 High のものが Medium/Low に落ちて収束が早まる事態を防ぐためのもの
+
+- **対応案の前提裏取り**: 裏取りの対象は、(a) レビューが提示した対応案の理由文に現れる事実主張、**(b) 親 Claude 自身が新設する是正策・検査・成功条件・テスト仕様が依拠する事実主張（規約・設計文書に書く事実主張を含む）** の両方とする
+  （レビューが前提を明示しない場合は、案を採用する理由として自分が書こうとしている事実主張が対象）
+  - **成立基準（肯定形）**: 該当箇所（**ファイルパスと行番号**）を提示できること
+  - **成立基準（否定形）**: 「〜が存在しない」を主張する場合は走査範囲を明示し、**gitignored ファイルを含む走査**であることを確認する。
+    実測（2026-07-23）では Grep ツールは**ディレクトリ指定では `.gitignore` を尊重して除外ファイルを走査しない**一方、**ファイルを明示すれば走査する**。
+    呼び出し形式で挙動が変わるため、否定形の根拠には `grep -n` を Bash 経由で使うか、対象ファイルを明示した検索を用いる
+  - **裏取り不能な場合**: その案を選ばない。他案を選ぶか、関所 2（情報不足の質問）として人間へ出す
+  - **記録先**: **裏取りの記録先は loop-impl-gaps 台帳**（`loop-impl-gaps-*.md`）の 1 行に固定する。
+    「指示または gaps 台帳」の OR は、どちらにも無い状態を事後に区別できないため採らない
+  - **理由**: 「宣言に嘘を書かせない」ことが目的のタスクで、前提未裏取りの是正指示そのものが**偽の理由文を 1 件生んだ**（2026-07-23 実測・CR-NEW / SR-NEW-4 で重複検出）
+
+- **レビューレポート名の命名**: report-timestamp skill 準拠のタイムスタンプ名で記録する
+  （固定名にしない。E ループの周回履歴保全と `review_hint_inject` のタイムスタンプ前提に整合）
+  形式: `.claude/reports/code-review-report-{YYYYMMDD-HHMMSS}.md` / `.claude/reports/security-review-report-{YYYYMMDD-HHMMSS}.md`
+
+- **5a 手動検証チェックリスト観点（SR-AI-001）**: 許可ルート配下への symlink/junction による偽装ケースを含める。
+  許可ルート内に作成されたシンボリックリンク・NTFS ジャンクションが許可ルート外を指していないことを確認する
+
+---
+
+## 実装・レビューの必須チェック
+
+設計フェーズ B で確定した以下 3 一般則の執行を skill 内規約として明記する。
+詳細はリンク先を参照:
+
+### (a) NUL 境界
+
+機械可読な行集合の区切りは NUL、`\n` は人間可読出力のみ。
+
+実装・検査の実体:
+- 機械検査: `tests/test_nul_boundary_lint.py`（AST ベースの lint。配布元で実行・CI に載る）
+- 宣言マーカー: `# 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（新規防御）
+
+`plan-path` を `Read` 引数に使う前に、以下の**パス用封じ込め型防御**を実装・適用する
+（表示用 SR L-2 とは別の独立した choke point・本 feature 唯一の新規発火点）:
+
+1. 改行・NUL・制御文字を検出したら無効化する
+2. `plan-path` を絶対パスへ正規化（`realpath` 相当・シンボリックリンク解決・`..` 解決）する
+3. 正規化結果（realpath）が**許可ルート配下**に収まるかを判定し、外なら全拒否（HITL へフォールバック）
+   - 許可ルート: **`~/.claude/plans/`（委任プランの正規永続先）のみ**
+   - 許可ルート外の realpath は、拡張子や存在に関わらず一律に無効とする
+
+有効性判定 3 条件の第 3 条（「実在確認」）でこの封じ込め検査を前段に置く。
+
+**機械実行必須化（SR-AI-001）**: realpath 正規化＋許可ルート封じ込め判定は、`.claude/skills/autonomous-mode/scripts/mode_line.py`
+（Bash 経由）を実際に呼び出して判定結果を得ること。文字列の目視比較で代替しないこと。スクリプト不在（配布先等）の場合は無効＝HITL（fail-closed）。
+呼び出し例（セッションファイルからモード行を直接パイプで渡す。コマンドラインに現れるリテラルはファイルパスのみで、モード行の内容はパイプのデータとして流れシェルに評価されない）:
+`grep -m1 '^モード: ' .claude/memory/sessions/{YYYYMMDD}.tmp | python .claude/skills/autonomous-mode/scripts/mode_line.py`
+→ `VALID<TAB>{正規化済み絶対パス}`（exit 0）／`INVALID<TAB>{理由コード}`（exit 1）の 1 行と exit code で判定する。
+モード行の値をコマンド文字列（here-string・引数・ダブルクォート内展開）に直接埋め込んではならない。
+
+### (c) 表示用 choke point（既存 SR L-2 の再利用）
+
+`モード:` 行の値をユーザーへ表示する全出口で 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` にもこの相互参照を明記すること（両側に記す）。