@joshuafolkken/kit 1.1050.0 → 1.1128.0

package/prompts/collaboration-workflow/report-format.md

@@ -102,7 +102,7 @@ pnpm josh read:files <path> [<path> ...]   # 変更対象を 1 ターンでま
 - **読み取りが 1 ターンに畳まれると、続く別ファイルへの編集は互いに依存しなくなり同じターンに載る。** #2178 の「1 ファイルずつ読んで直す」9 ターンの並びが、まとめ読み 1 ターン＋まとめ編集 1 ターンの 2 ターンになる。読み取りと編集を交互に出すのをやめ、読み取りを先に畳むのが梃子である。
 - **助言でないのは、密度を動かした実績があるのが合成コマンドだけだからである**（#2165 / #2162）。助言（#1304）・実行中の提示（#1329 / #1337）・レーン子の通知（#2164）はいずれも動かさず、バッチガードは子で `off`（#2178）なので、実装中の独立編集に効く梃子はこの入口が唯一。
 - 上限超過時は本文を出さず「Read ツールで 1 ターンにまとめて読め」と返す。根拠と前後は [`turn-batching.md`](turn-batching.md) →「実装中の独立編集に効く合成コマンド」。
-- **読んだ後の独立した編集は、1 回の `pnpm josh edit:files -` で送る（joshuafolkken/kit#2493）。** 計画ファイルを作らず、クォート付きヒアドキュメント（`<<'EDITS'`）で old/new の組を標準入力に渡す。形式と拒否条件は `docs/josh-commands.md` →「`josh edit:files`」。**個別の `Edit` に戻すのは**、前の編集結果に依存する編集（`dependent` で拒否される）、編集が 1 件だけのとき、ファイル全体を書くとき（`Write`）の 3 つ。
+- **読んだ後の独立した編集は、1 回の `pnpm josh edit:files -` で送る（joshuafolkken/kit#2493）。** 計画ファイルを作らず、クォート付きヒアドキュメント（`<<'EDITS'`）で old/new の組を標準入力に渡す。形式と拒否条件は `docs/josh-commands-automation.md` →「`josh edit:files`」。**個別の `Edit` に戻すのは**、前の編集結果に依存する編集（`dependent` で拒否される）、編集が 1 件だけのとき、ファイル全体を書くとき（`Write`）の 3 つ。
 
 ### 完了報告（セッション向け）
 

package/prompts/collaboration-workflow/residency.md

@@ -82,7 +82,7 @@
 **第 1 問で「名指しできる」となり、引き金つき配送へ移したもの**（joshuafolkken/kit#1524）。いずれも本文は消えておらず、規則が効く瞬間にフックが突きつける。下は常駐に 1 行を残した、またはその判断に理由が要った行だけであり、配送されている規則の全体ではない。**列挙表と、引き金が発火しないターンの意味の単一ソースは [`rule-delivery.md`](./rule-delivery.md) であり、ここには行数を写さない** — 2 か所に置いた数は必ずずれる（joshuafolkken/kit#1525）。
 
 - **独立した呼び出しを同じターンに載せる規則** — 引き金は `pnpm josh batch:guard`（単発呼び出しのターンが 3 つ続いた次の `Bash` / `Edit` / `Read`）。常駐していた間の実測が示したのは、**常駐は効いていなかった**という事実である（数値は指し先）。実測値・却下した機構案・ゲートを弱めない条件は [`turn-batching.md`](./turn-batching.md) にある（joshuafolkken/kit#1304、#1390、#1524、`Edit` は #1762、`Read` は #1798 で加わった）
-- **バックログの WIP 上限（オープン 30 件）** — 引き金は `pnpm josh rule:guard`（Issue を作成する `Bash`）。配送文が件数の数え方・起票しない判断・2 つの免除・**割り込みの 3 条件**をそのまま運ぶ。3 条件を落とすと「重大かどうか」が判断に戻るため、配送文からも削っていない（joshuafolkken/kit#1518）。コメントの投稿は起票ではないので対象外である。手順と数字を動かす条件は [`wip-cap.md`](./wip-cap.md) にある（joshuafolkken/kit#1469、#1524）
+- **バックログの WIP 上限** — 引き金は `pnpm josh rule:guard`（Issue を作成する `Bash`）。配送文が件数の数え方・起票しない判断・2 つの免除・**割り込みの 3 条件**をそのまま運ぶ。3 条件を落とすと「重大かどうか」が判断に戻るため、配送文からも削っていない（joshuafolkken/kit#1518）。コメントの投稿は起票ではないので対象外である。手順と数字を動かす条件は [`wip-cap.md`](./wip-cap.md) にある（joshuafolkken/kit#1469、#1524）
 - **Issue コメントの読み取り** — 引き金は `pnpm josh rule:guard`（Issue 本文だけを読む `Bash`）。拒否文はコメント込みの読み直しと、本文と食い違うコメントの扱いを渡す。前提を満たすまで毎回拒否するので、`batch:guard` と引き金が重なるターンでも拒否する。手順は `SKILL.md` → §2g に残る — フックを走らせないセッションにも読み取りの義務は残るからである
 - **本文をシェルの二重引用符に載せない** — 引き金は `pnpm josh rule:guard`（本文値にバッククォートか `$` を含む `Bash`）。**引き金はフラグではなく本文を読む** — 作例はどれも無害なプレースホルダを渡しているので、フラグで引くと規則を既に守っているターンで拒否することになる。**常駐側に 1 行が残っているのは、ここが「削除してよい」側ではないからである** — 配送は Claude Code にしか届かず、正規表現が知っている綴り（`-f body=` ／ `--body` ／ `--notify-message`）だけが規則の適用範囲になってはならない。実測・安全な綴り・引き金の死角は [`shell-body.md`](./shell-body.md) にある（joshuafolkken/kit#1198）
 
@@ -107,9 +107,9 @@ no になり skill 側に本体を置くものの例:
 
 **指し先を「カノニカル参照」として名指すと、2 回読みが戻ってくる。** 索引を指してから節名を書く形を禁じたのと同じ欠陥であり、しかも今度は本文が 1 行も無いファイルを経由させる。読み手は指し先を開き、そこに書かれた skill の名前を読み、もう一度開くことになる。**節名まで書いてある引用はさらに悪い** — 指し先には本文が無いのだから、その節はもうそこには無い。
 
-**話題ファイル自体は残す。** 索引（`prompts/collaboration-workflow.md`）は全話題ファイルを列挙しており、正典を人が読むときの入口はそこにある。指し先になった話題ファイルは「本文がどこへ行ったか」の記録として索引から辿られるものであり、他の文書からの引用で辿られるものではない。例外は単一ソースである skill 自身で、自分の指し先を名指すのは逆向きの参照だから 2 回読みを生まない。
+**指し先だけになった話題ファイルは残さない。** 本文が skill へ移り、案内の 1 段落しか持たなくなった話題ファイルは削除し、索引（`prompts/collaboration-workflow.md`）の行も消す（joshuafolkken/kit#1925、joshuafolkken/kit#2996）。削除までの間に残る指し先は「本文がどこへ行ったか」の記録として索引から辿られるものであり、他の文書からの引用で辿られるものではない。例外は単一ソースである skill 自身で、自分の指し先を名指すのは逆向きの参照だから 2 回読みを生まない。
 
-`scripts/rules/pointer-citation-document-rule.test.ts` がこれを固定する。**縮小した話題ファイルは冒頭に「この規則の単一ソースは …」の宣言文を置くこと** — 検査はこの宣言文で指し先を機械的に検出し、そこに書かれた skill が実在すること、および他の文書がその話題ファイルを引用していないことを確かめる。宣言文が入口なので、横展開で新しく縮小された話題も、この規則の対象へ自動で入る。
+`scripts/rules/pointer-citation-document-rule.test.ts` がこれを固定する。**削除までの間に残る、縮小した話題ファイルは冒頭に「この規則の単一ソースは …」の宣言文を置くこと** — 検査はこの宣言文で指し先を機械的に検出し、そこに書かれた skill が実在すること、および他の文書がその話題ファイルを引用していないことを確かめる。宣言文が入口なので、横展開で新しく縮小された話題も、この規則の対象へ自動で入る。
 
 ### 常駐予算
 

package/prompts/collaboration-workflow/rule-delivery.md

@@ -37,7 +37,7 @@
 | **ターン内バッチング**（`turn-batching.md`）                                                                                                                           | `pnpm josh batch:guard` — 単発呼び出しのターンが 3 つ続いた次の `Bash` / `Edit` / `Read`                                                                                                                                                                                                                                                                                                                                                                                                                                                                               | 往復あたりの呼び出し数が下限を上回っている ＝ 規則は既に守られている                                                                                                                                                            |
 | **調査の委譲しきい値**（`SKILL.md` → §2b）                                                                                                                             | `pnpm josh investigation:guard` — 編集しないファイルの読み取りが 3 件目に達した `Read` / `Bash`                                                                                                                                                                                                                                                                                                                                                                                                                                                                        | 読み取りがしきい値未満 ＝ 委譲する対象がまだ無い                                                                                                                                                                                |
 | **バックログ WIP 上限**（`wip-cap.md`）                                                                                                                                | `pnpm josh rule:guard` — Issue を起票する `Bash`（`pnpm josh issue:file`）                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             | Issue が起票されていない ＝ 上限に触れる行為が無い                                                                                                                                                                              |
-| **直接起票の禁止**（`docs/josh-commands.md` → `josh issue:file`、joshuafolkken/kit#2808）                                                                              | `pnpm josh rule:guard` — `josh issue:file` を通さずに Issue を作成する `Bash`（`gh issue create`、または `…/issues` への `title` 付き POST）。拒否文は `pnpm josh issue:file` の書式を渡す。重複探し・本文の検査と分類ラベル・`## Origin` の確認・`epic:bundle` はこのコマンドが実行するので、それぞれを別の行で見張らない。**毎回発火する**                                                                                                                                                                                                                           | `pnpm josh issue:file` で起票している ＝ 起票の全段がそろっている                                                                                                                                                               |
+| **直接起票の禁止**（`docs/josh-commands-automation.md` → `josh issue:file`、joshuafolkken/kit#2808）                                                                   | `pnpm josh rule:guard` — `josh issue:file` を通さずに Issue を作成する `Bash`（`gh issue create`、または `…/issues` への `title` 付き POST）。拒否文は `pnpm josh issue:file` の書式を渡す。重複探し・本文の検査と分類ラベル・`## Origin` の確認・`epic:bundle` はこのコマンドが実行するので、それぞれを別の行で見張らない。**毎回発火する**                                                                                                                                                                                                                           | `pnpm josh issue:file` で起票している ＝ 起票の全段がそろっている                                                                                                                                                               |
 | **1 ラン 10 件の起票上限**（`.claude/skills/workflow-commands/SKILL.md` → §2d、`observation-filing.md`）                                                               | `pnpm josh rule:guard` — Issue を起票する `Bash`（`pnpm josh issue:file`）。そのランで**拒否されていない**起票が既に 10 件あるとき、11 件目を拒否する。終了コードが 0 でない `issue:file` 呼び出しは起票に数えない。`is_issue_filing` を再利用し、新しい述語は作らない                                                                                                                                                                                                                                                                                                 | 拒否されていない起票が 10 件未満 ＝ 上限に触れていない。**繰り返す行為を止める行なので毎回発火する**（下の「例外」に従う）                                                                                                      |
 | **Issue コメントの読み取り**（`SKILL.md` → §2g）                                                                                                                       | `pnpm josh rule:guard` — Issue 本文だけを読む `Bash`（`gh issue view <N>`、または `…/issues/<N>` で終わる GET）                                                                                                                                                                                                                                                                                                                                                                                                                                                        | Issue を読んでいない、または最初から `--comments` 付きで読んでいる                                                                                                                                                              |
 | **本文をシェルに載せない**（`shell-body.md`）                                                                                                                          | `pnpm josh rule:guard` — 二重引用符の本文値（`-f body="…"` ／ `-f "body=…"` ／ `--body "…"` ／ `--notify-message "…"`）にバッククォートか `$` を含む `Bash`                                                                                                                                                                                                                                                                                                                                                                                                            | 本文がシェルに評価されない ＝ 規則は既に守られている                                                                                                                                                                            |

package/prompts/collaboration-workflow/turn-batching.md

@@ -50,7 +50,7 @@
 
 - **PreToolUse フックが「1 件の呼び出しだけを見て、それが独立かどうかを判定する」。** 採れない。**呼び出しの独立性は、1 件の呼び出しからは観測できない。** フックが見るのはこれから走る 1 件だけで、それが直前の結果に依存しているかどうかはフックの入力に無い。依存している正当な直列実行（`grep` → `sed -n`、Edit の前の読み取り）を止めてしまい、しかも止めた側は理由を説明できない。`output-bounds.md` が「形で見分ける案は実データ上で外れる」として PreToolUse guard を却下したのと同じ形である。
 
-  **却下したのはこの判定のしかたであって、`PreToolUse` という機構そのものではない。** joshuafolkken/kit#1390 は**まさに `PreToolUse` フックとして** `pnpm josh batch:guard` を実装し、`.claude/settings.json` で配布している。判定に使うのは、いま出そうとしている 1 件ではなく**閉じた履歴** — 結果が返り終わったターンの並び — である。単発呼び出しのターンが 2 つ続いたことは 1 件からは見えないが、履歴からは見える。上に並べた懸念は、それぞれ設計で避けてある。依存は**共有ターゲット**で見るので `grep` → `sed -n` は止まらず、**書き込みも読み取りとまったく同じ基準で拒否され**（joshuafolkken/kit#1762）、**手元の呼び出しが直前の列と共有ターゲットを持つときは拒否を取り下げる**（書き込み同士を含む）。拒否は 1 つの単発連続につき **1 回だけ**である（窓を超える連続は `docs/maintainers/turn-batching-rationale.md` →「`batch:guard` の拒否窓」）。委譲された子やレビューエージェントは、親の記録を共有せず、それぞれに配送される（`docs/maintainers/turn-batching-rationale.md` →「フォークへの配送の実装（joshuafolkken/kit#1424）」）。機構の全体は `docs/josh-commands.md` →「`josh batch:guard`」にある。範囲が `Bash|Edit|Read` に広がった経緯（joshuafolkken/kit#1509 を含む）は `docs/maintainers/turn-batching-rationale.md` →「書き込みが範囲に入った経緯（joshuafolkken/kit#1762）」、`docs/maintainers/turn-batching-rationale.md` →「読み取りが範囲に入った経緯（joshuafolkken/kit#1798）」、`docs/maintainers/turn-batching-rationale.md` →「事務コマンドが範囲に入った経緯（joshuafolkken/kit#1875）」。
+  **却下したのはこの判定のしかたであって、`PreToolUse` という機構そのものではない。** joshuafolkken/kit#1390 は**まさに `PreToolUse` フックとして** `pnpm josh batch:guard` を実装し、`.claude/settings.json` で配布している。判定に使うのは、いま出そうとしている 1 件ではなく**閉じた履歴** — 結果が返り終わったターンの並び — である。単発呼び出しのターンが 2 つ続いたことは 1 件からは見えないが、履歴からは見える。上に並べた懸念は、それぞれ設計で避けてある。依存は**共有ターゲット**で見るので `grep` → `sed -n` は止まらず、**書き込みも読み取りとまったく同じ基準で拒否され**（joshuafolkken/kit#1762）、**手元の呼び出しが直前の列と共有ターゲットを持つときは拒否を取り下げる**（書き込み同士を含む）。拒否は 1 つの単発連続につき **1 回だけ**である（窓を超える連続は `docs/maintainers/turn-batching-rationale.md` →「`batch:guard` の拒否窓」）。委譲された子やレビューエージェントは、親の記録を共有せず、それぞれに配送される（`docs/maintainers/turn-batching-rationale.md` →「フォークへの配送の実装（joshuafolkken/kit#1424）」）。機構の全体は `docs/josh-commands-automation.md` →「`josh batch:guard`」にある。範囲が `Bash|Edit|Read` に広がった経緯（joshuafolkken/kit#1509 を含む）は `docs/maintainers/turn-batching-rationale.md` →「書き込みが範囲に入った経緯（joshuafolkken/kit#1762）」、`docs/maintainers/turn-batching-rationale.md` →「読み取りが範囲に入った経緯（joshuafolkken/kit#1798）」、`docs/maintainers/turn-batching-rationale.md` →「事務コマンドが範囲に入った経緯（joshuafolkken/kit#1875）」。
 
   **ガードが見えないところ — ここでは自分で規則を当てる。**
 
@@ -89,9 +89,9 @@ Round trips:
 
 **梃子の本体は読み取りと編集の脱交互化（de-interleave）。** 交互の並びで編集を分けているのは直前の読み取りへの依存で、読み取りを 1 回に畳めば続く別ファイルへの編集は互いにも直前の読み取りにも依存せず 1 ターンに載る。#2178 の並び — `Read A` / `Edit A` / `Read B` / `Edit B` … の **9 ターン** — が、`read:files A B C D` → `Edit A` ＋ `Edit B` ＋ `Edit C` ＋ `Edit D` の **2 ターン**になる。
 
-上限超過時は `read:files` が「Read ツールで 1 ターンにまとめて読め」と返しフォールバックでも読み取りは畳まれたまま。詳細は `docs/josh-commands.md` →「`josh read:files`」。
+上限超過時は `read:files` が「Read ツールで 1 ターンにまとめて読め」と返しフォールバックでも読み取りは畳まれたまま。詳細は `docs/josh-commands-automation.md` →「`josh read:files`」。
 
-書き込みは `pnpm josh edit:files` で畳む（joshuafolkken/kit#2366） — 編集を **プラン（`=====` のパスヘッダ＋ git conflict マーカー対）** として受け取り 1 呼び出しで適用し、各編集は content-addressed なので `old` が 1 箇所に一致しなければ拒否して報告する。#2493 で `-`（標準入力）を受け、依存編集は `dependent` で拒否する。詳細は `docs/josh-commands.md` →「`josh edit:files`」。
+書き込みは `pnpm josh edit:files` で畳む（joshuafolkken/kit#2366） — 編集を **プラン（`=====` のパスヘッダ＋ git conflict マーカー対）** として受け取り 1 呼び出しで適用し、各編集は content-addressed なので `old` が 1 箇所に一致しなければ拒否して報告する。#2493 で `-`（標準入力）を受け、依存編集は `dependent` で拒否する。詳細は `docs/josh-commands-automation.md` →「`josh edit:files`」。
 
 ## ガード発火時にも合成コマンドを手渡す（joshuafolkken/kit#2311）
 

package/prompts/collaboration-workflow/upstream-interrupt.md

@@ -16,7 +16,7 @@
 
 1. **現在の作業を退避する**: `git stash push -u -m "upstream-interrupt: paused #<N>"`（WIP コミットでも可）。退避したことを忘れないよう、この時点で stash を作る。メッセージ付きで積むのは、復元をメッセージで特定するため（下記ステップ 5）
 2. **進行中の Issue に状況を明記する**: `pnpm josh issue:comment <N> --body-file <path>` で、(a) 作業を stash したこと、(b) 中断理由（どの別パッケージの・どんな問題で中断したか）、(c) 対象パッケージに作成した新 Issue へのリンクを `## Upstream issues` 見出しの下に `owner/repo#N` 形式で、を記載する。これにより「なぜこの Issue が一時停止しているか」と「何を待っているのか」が後から監査できる（→「起票元へのバックリンク」）
-3. **対象パッケージのリポジトリに新しい Issue を作成する（確認なし）**: `pnpm josh issue:file "<root-cause title>" --body-file <body-file> --depth <n> --route tier-a --repo <owner>/<repo>`（`route:tier-a` は実装中の Tier A 起票を経路として集計するためのラベル — joshuafolkken/kit#1083。付与するのは first-party の場合だけで、third-party はコマンド自身が拒否し起票しない）。本文の検査、本文が宣言する分類ラベルの付与、`## Origin` 節の確認、起票先での重複探し、`epic:bundle` はこのコマンドが実行する（`docs/josh-commands.md` → `josh issue:file`）。分類の単一ソースは `prompts/collaboration-workflow/issue-template.md`。根本原因・再現・期待結果を Step 1 のテンプレに沿って記載し、**本文に `## Origin` 節を置いて起票元 Issue を `owner/repo#N` 形式で書く**（→「起票元へのバックリンク」）。上流 Issue は欠陥を、起票元 Issue は証拠を持つため、リンクがないと上流 Issue は後から解釈できなくなる。ここで「起票してよいか」を尋ねて停止してはならない。**ただし確認なしで起票してよいのは対象が first-party のときだけ**で、third-party（owner が自リポジトリと一致しないリポジトリ）なら起票せずに停止する（→「第三者リポジトリへの書き込みは Tier C（明示指示が必要）」）
+3. **対象パッケージのリポジトリに新しい Issue を作成する（確認なし）**: `pnpm josh issue:file "<root-cause title>" --body-file <body-file> --depth <n> --route tier-a --repo <owner>/<repo>`（`route:tier-a` は実装中の Tier A 起票を経路として集計するためのラベル — joshuafolkken/kit#1083。付与するのは first-party の場合だけで、third-party はコマンド自身が拒否し起票しない）。本文の検査、本文が宣言する分類ラベルの付与、`## Origin` 節の確認、起票先での重複探し、`epic:bundle` はこのコマンドが実行する（`docs/josh-commands-automation.md` → `josh issue:file`）。分類の単一ソースは `prompts/collaboration-workflow/issue-template.md`。根本原因・再現・期待結果を Step 1 のテンプレに沿って記載し、**本文に `## Origin` 節を置いて起票元 Issue を `owner/repo#N` 形式で書く**（→「起票元へのバックリンク」）。上流 Issue は欠陥を、起票元 Issue は証拠を持つため、リンクがないと上流 Issue は後から解釈できなくなる。ここで「起票してよいか」を尋ねて停止してはならない。**ただし確認なしで起票してよいのは対象が first-party のときだけ**で、third-party（owner が自リポジトリと一致しないリポジトリ）なら起票せずに停止する（→「第三者リポジトリへの書き込みは Tier C（明示指示が必要）」）
 4. **`confirmation` Telegram を送って停止する**: 上流 Issue の URL と、何が止まっているかを本文に書く（→ `CLAUDE.md` → "Mid-workflow stop notification (`confirmation`)"）。無人実行でも画面外でユーザーが気付ける。停止は Issue が既に存在する状態で行うので、ユーザーは「待つ / 先送りする」を Issue を見ながら 1 語で答えられる
 5. **元の作業を再開する**: 上流の修正がマージされた、または**ユーザーが先送りを明示判断した**後に `pnpm josh stash:pop "upstream-interrupt: paused #<N>"`（位置指定や引数なしの `git stash pop` は使わない — stash は全 work tree が共有する 1 本のスタックで、別のレーンの stash を取り込む恐れがある）して、退避していた元タスクを続行する。上流 Issue を割り込みで実装するかどうかもユーザーの判断（上流パッケージの実装・PR・マージはそれぞれのワークフロー規則に従う）
 

package/prompts/collaboration-workflow/wip-cap.md

@@ -1,4 +1,4 @@
-# オープン Issue の WIP 上限（30 件）
+# オープン Issue の WIP 上限
 
 **単一ソースはこのファイルである。**
 
@@ -8,7 +8,7 @@
 
 ## 規則
 
-**オープン Issue が 30 件を超えている状態で新しく起票するときは、先に 1 件閉じる。**
+**オープン Issue が上限を超えている状態で新しく起票するときは、先に 1 件閉じる。**
 
 件数は毎回数える。見積もりでも記憶でもない。
 
@@ -19,7 +19,7 @@ gh api "repos/{owner}/{repo}/issues?state=open&per_page=100" --paginate \
 
 - **数えるのは「起票しようとしているリポジトリ」のオープン Issue 全件**である。`{owner}/{repo}` はカレントリポジトリに展開されるので、**別リポジトリへ起票するときはそのリポジトリのパスを直接書く**（例: `repos/joshuafolkken/app-kit/issues?...`）。自リポジトリの件数で他リポジトリへの起票を判断するのは、別のバックログを見ているのと同じである。
 - epic も子も含める。epic を除外すると、epic を作ることで上限を回避できてしまう。
-- **上限は 30。** 31 件目以降を作る前に 1 件閉じる。
+- **上限は 30。** これを超える 1 件を作る前に 1 件閉じる。エージェントが読む文書（`CLAUDE.md`・`prompts/`・配布 skill）がこの数字を書くのはこの行だけで、一次情報は `scripts/rules/delivered-rules.ts` の `WIP_CAP` である（一致はテストが固定する）。
 - **プルリクエストは数えない。** REST の `issues` エンドポイントは PR も返すため、`select(.pull_request == null)` で落とす。この 1 句を省くと、PR が開いているだけで上限に達する。
 - **`gh issue list` は使わない。** 配布ドキュメントの実行可能ブロックに置ける `gh` は REST のものだけで、`gh issue list` は GraphQL 経由のためクラウドセッションで 403 になる。
 
@@ -27,11 +27,11 @@ gh api "repos/{owner}/{repo}/issues?state=open&per_page=100" --paginate \
 
 測定は `docs/maintainers/wip-cap-rationale.md` →「なぜ上限が要るのか — 測定」。
 
-**上限は、増加を見えるようにするための強制装置である。** 数を減らすこと自体が目的ではない。30 を超えた状態で起票しようとしたときに「本当にこれは 1 件増やす価値があるか」を必ず 1 回考えさせる、そこだけが役割である。
+**上限は、増加を見えるようにするための強制装置である。** 数を減らすこと自体が目的ではない。上限を超えた状態で起票しようとしたときに「本当にこれは 1 件増やす価値があるか」を必ず 1 回考えさせる、そこだけが役割である。
 
 ## 超過時の手順
 
-起票しようとした時点で 30 件を超えていたら、**その起票が裁量によるものか、実行がそれに詰まっているか、割り込みか**の 3 つに分岐する。判断ではなく、起票の種類で決まる。**上限が効くのは裁量側だけである。**
+起票しようとした時点で上限を超えていたら、**その起票が裁量によるものか、実行がそれに詰まっているか、割り込みか**の 3 つに分岐する。判断ではなく、起票の種類で決まる。**上限が効くのは裁量側だけである。**
 
 **判定するのは「起票 1 件」ではなく「起票のひとまとまり」である。** 分割判定が作る子 N 件とその epic、割り込み Issue とその上流バックリンク、起票直後の `epic:bundle` が `create_epic` と答えたときの epic — これらは 1 回の起票行為であり、途中で上限に当たって半分だけ作るのが最悪の結果になる。**ひとまとまりの先頭で 1 回だけ判定し、通ったらまとまり全体を作り切る。**
 
@@ -71,36 +71,39 @@ gh api "repos/{owner}/{repo}/issues?state=open&per_page=100" --paginate \
 
 #### 該当したときの手順
 
-1. **上限に関係なく起票する。** 1 件閉じることを条件にしない。起票は `pnpm josh issue:file` で行う。本文の検査、本文が宣言する分類ラベルの付与、重複探し、`epic:bundle` はこのコマンドが実行する（`docs/josh-commands.md` → `josh issue:file`）。
+1. **上限に関係なく起票する。** 1 件閉じることを条件にしない。起票は `pnpm josh issue:file` で行う。本文の検査、本文が宣言する分類ラベルの付与、重複探し、`epic:bundle` はこのコマンドが実行する（`docs/josh-commands-automation.md` → `josh issue:file`）。
 
    ```bash
    pnpm josh issue:file "<title>" --body-file <body-file> --depth <n> --route interrupt
    ```
 
 2. **超過している事実と、当たった条件の番号を本文に 1 行書く**（例:「オープン 37 件で起票。3 条件のうち 2（文書化された手順が完了できない）に該当」）。**どちらか一方では足りない** — 件数だけでは判定が再現できず、条件だけでは上限の可視化が効かない。
-3. **次に実行されるものとして挿入する。** epic の下にあるなら `pnpm josh epic --add <E> <N>` で、**位置を指定せずに**追加する（`<E>` が epic、`<N>` が起票した割り込み）。**`--before` / `--after` を使ってはならない。** それらは `blocked-by` 関係を実際に書き込むため（`docs/josh-commands.md` →「`josh epic --add`」）、「発見したランをブロックしていない欠陥」という割り込みの定義と矛盾する**偽の依存関係**になり、`epic:next` が実装中の子を「割り込みにブロックされている」として出さなくなる。位置を指定しない追加は依存を一切宣言しない（joshuafolkken/kit#1253）ので、**順序は実行側が持つ** — 次に取り上げるのは実行側の選択であって、宣言された関係ではない（経緯は `docs/maintainers/wip-cap-rationale.md` →「位置を指定しない追加の経緯」）。**先に提示させたいときは `--order-before <M>` を使う**（joshuafolkken/kit#1738）— これはタスクリストの行だけを動かし、依存宣言も `blocked-by` も一切書かないので、上の禁止には当たらない。**禁止しているのは依存を書き込む `--before` / `--after` であって、順序そのものではない。** `epic:next` は runnable な子をタスクリスト順に提示する（joshuafolkken/kit#1583）ため、位置を指定しない追加は「末尾に提示される」を意味する — 割り込みを次に取り上げてほしいなら、行だけを前に出すこの指定がその手段である。**epic の下に無いなら挿入先そのものが無い**ので、この手順は飛ばして 4 だけを行う。
+3. **次に実行されるものとして挿入する。** epic の下にあるなら `pnpm josh epic --add <E> <N>` で、**位置を指定せずに**追加する（`<E>` が epic、`<N>` が起票した割り込み）。**`--before` / `--after` を使ってはならない。** それらは `blocked-by` 関係を実際に書き込むため（`docs/josh-commands-automation.md` →「`josh epic --add`」）、「発見したランをブロックしていない欠陥」という割り込みの定義と矛盾する**偽の依存関係**になり、`epic:next` が実装中の子を「割り込みにブロックされている」として出さなくなる。位置を指定しない追加は依存を一切宣言しない（joshuafolkken/kit#1253）ので、**順序は実行側が持つ** — 次に取り上げるのは実行側の選択であって、宣言された関係ではない（経緯は `docs/maintainers/wip-cap-rationale.md` →「位置を指定しない追加の経緯」）。**先に提示させたいときは `--order-before <M>` を使う**（joshuafolkken/kit#1738）— これはタスクリストの行だけを動かし、依存宣言も `blocked-by` も一切書かないので、上の禁止には当たらない。**禁止しているのは依存を書き込む `--before` / `--after` であって、順序そのものではない。** `epic:next` は runnable な子をタスクリスト順に提示する（joshuafolkken/kit#1583）ため、位置を指定しない追加は「末尾に提示される」を意味する — 割り込みを次に取り上げてほしいなら、行だけを前に出すこの指定がその手段である。**epic の下に無いなら挿入先そのものが無い**ので、この手順は飛ばして 4 だけを行う。
 4. **着手は、既にある承認の内側でのみ、指示を待たずに行う。** `backlogrun` の中なら、打たれたキーワードがバッチを承認しているので、割り込みは次の子として着手してよい。**バッチの外では `CLAUDE.md` →「Explicit invocation required」が変わらず効く** — 起票と挿入まで済ませたうえで、利用者に打つべきコマンド（`fullrun #<N>`）を報告して止まる。**割り込みは上限の例外であって、明示起動規則の例外ではない。**
 
 **起票と、実行されるようにするところまでが 1 つのまとまりである。** epic の下にある割り込みを起票だけして追加しなければ、`epic:next` はそれを候補にすら出さない — Issue は残るが実行されないという、コメントに埋もれるのと大差ない状態になる。**epic の外にある割り込みでは、まとまりの後半は 4 の報告そのもの**であり、打つべきコマンドを利用者に渡すまでが 1 回の行為である。上の「ひとまとまりで判定する」がここにも効く。
 
-#### 実行のしかた — 検証経路そのものの欠陥は単独で走らせる
+#### 実行のしかた — `main` で誤答している検証の欠陥は単独で走らせる
 
-**割り込みの対象が検証経路そのものの欠陥であるとき、その Issue は単独で実行し、バッチを再開するのはそれが `main` へマージされてからとする。** 「着地」はマージであって、PR を開いた時点でもレビューが収束した時点でもない。
+**kit 自身の検証が今の `main` で無関係な PR の判定まで誤らせている欠陥を直す Issue は単独で実行し、バッチを再開するのはそれが `main` へマージされてからとする。** 「着地」はマージであって、PR を開いた時点でもレビューが収束した時点でもない。
 
-**該当するかは判断ではなく、影響先の列挙で決まる。** 欠陥が次のいずれかに影響するか:
+**該当するかは判断ではなく、次の 3 条件で決まる。**
 
-- **検証ゲート**（lint / 型チェック / スペルチェック / 単体テスト）
-- **コードレビュー**
-- **push 時のフック**
-- **マージ時のチェック**
+1. **欠陥である**（`- 種別: 不具合`）。改善・リファクタ・削除・機能追加は当たらない。
+2. **kit 自身の検証の欠陥である。** 検証とは次の 4 つを指し、配布先リポジトリ向けの CI・テンプレートの不具合は当たらない。
+   - **検証ゲート**（lint / 型チェック / スペルチェック / 単体テスト）
+   - **コードレビュー**
+   - **push 時のフック**
+   - **マージ時のチェック**
+3. **今の `main` で、その Issue と無関係な PR の判定まで誤らせている**（嘘の緑 / 嘘の赤）。効率の問題や、特定の条件でしか起きないものは当たらない。
 
-**いずれかに当たれば単独実行。** その Issue に `run:solo` を付け、強制はそれを読む `backlog:next` と `epic:next --lanes` が行う（joshuafolkken/kit#2776）。当たらなければ（機能追加、文書修正など）`run:lane` を付け、並列バッチの一員として走らせてよい。どちらもなければ `triage` が返り何も始まらない（joshuafolkken/kit#2779）ので、run が起票する Issue（割り込み・分割・前提）は起票時にどちらかを付ける。**「重大だと感じるか」は判定条件ではない**（3 条件と同じ理由）。
+**3 条件すべてに当たれば単独実行、1 つでも外れれば `run:lane`。** 単独実行なら `run:solo` を付け、強制はそれを読む `backlog:next` と `epic:next --lanes` が行う（joshuafolkken/kit#2776）。外れれば（改善、機能追加、文書修正、配布先 CI の修正など）`run:lane` を付け、並列バッチの一員として走らせてよい。どちらもなければ `triage` が返り何も始まらない（joshuafolkken/kit#2779）ので、run が起票する Issue（割り込み・分割・前提）は起票時にどちらかを付ける。**「重大だと感じるか」は判定条件ではない**（起票側の 3 条件と同じ理由）。
 
-**理由は 2 つあり、どちらか一方だけでも単独実行の根拠として十分である。** その 2 つと、判定を列挙にした由来は `docs/maintainers/wip-cap-rationale.md` →「単独実行の理由と由来」。
+**他レーンを止める根拠は 1 つ — 壊れた検証の上でバッチを回すと、全員の結果が信用できないこと。** 割り込み自身の検証が欠陥の影響下にあることはその Issue 自身の扱い（修正後の検証で確かめる）であって、他レーンを止める根拠にはしない。根拠と、判定を条件にした由来・狭めた経緯は `docs/maintainers/wip-cap-rationale.md` →「単独実行の理由と由来」。
 
 ## 上限そのものを変えるとき
 
-**30 という数字は Tier C ではない** — 引き上げも引き下げも、測定を添えて提案してよい。ただし**変更は必ずこのファイルとマーカーテストの両方を同じコミットで動かす**。片方だけ動かすと、常駐側が存在しない数字を指す。
+**上限の数字は Tier C ではない** — 引き上げも引き下げも、測定を添えて提案してよい。ただし**変更は必ず `WIP_CAP` と「規則」節の 1 行を同じコミットで動かす**。片方だけ動かすと一致を固定するテストが落ちる。
 
 **引き上げる条件は「窮屈だから」ではない。** オープン件数が 7 日移動平均で減り続けていて、なお上限が起票を止めているとき — つまり装置が目的を果たし終えたときだけである。
 
@@ -108,8 +111,8 @@ gh api "repos/{owner}/{repo}/issues?state=open&per_page=100" --paginate \
 
 上限は単独では効かない。**製造側を止めないまま上限だけ入れると、製造は続いたまま実行だけが止まる。** 経緯は `docs/maintainers/wip-cap-rationale.md` →「3 つを 1 コミットで着地させた経緯」。
 
-| 製造元                    | 変更                                              | 単一ソース                                                              |
-| ------------------------- | ------------------------------------------------- | ----------------------------------------------------------------------- |
-| 分割判定                  | 既定を「分割しない」に。目安 10 ファイル / 400 行 | `.claude/skills/workflow-commands/split-assessment.md` → "The question" |
-| レビュー round 2 の残指摘 | 既定を branch 3（PR に 1 行残して落とす）に       | `prompts/review.md` → "Three-way disposition after the cap"             |
-| オープン件数              | 30 件の WIP 上限                                  | このファイル                                                            |
+| 製造元                    | 変更                                           | 単一ソース                                                              |
+| ------------------------- | ---------------------------------------------- | ----------------------------------------------------------------------- |
+| 分割判定                  | 既定を「分割しない」に。目安は単一ソースにある | `.claude/skills/workflow-commands/split-assessment.md` → "The question" |
+| レビュー round 2 の残指摘 | 既定を branch 3（PR に 1 行残して落とす）に    | `prompts/review.md` → "Three-way disposition after the cap"             |
+| オープン件数              | WIP 上限                                       | このファイル                                                            |

package/prompts/collaboration-workflow.md

@@ -2,11 +2,11 @@
 
 <!-- cspell:words coderabbit -->
 
-このドキュメントは、Claude / Cursor / Gemini を含む複数の AI ツールで共通に使う Issue 駆動の共同作業ワークフローの**正典**である。
+このドキュメントは、Claude / Cursor / Gemini を含む複数の AI ツールで共通に使う Issue 駆動の共同作業ワークフローの**索引**である。
 
 ## この索引の使い方
 
-**これは人間が読むための正典であり、実行中の参照先ではない。** 実行中の操作手順は `.claude/skills/workflow-commands/` にあり、規則そのものは `CLAUDE.md` にある。両者とこの正典は一致していなければならない。実行中にこの正典を開く必要があるのは、skill と規則の言い分が食い違ったときだけである。
+**これは人間が読むための索引であり、規則を定める場所ではない。** 常駐の引き金は `CLAUDE.md` に、実行中の操作手順は `.claude/skills/workflow-commands/` に、各話題の規則は下の表のファイルにあり、それぞれが自分の規則の一次情報である。この索引はそれらを言い直さない。
 
 **話題ごとにファイルが分かれている。** 以前はこの内容が 1 本の 169KB のファイルにあり、1 つの節を確かめるだけでも全体を読む必要があった。読んだものはそのセッションの残り全ターンで積み上がった前置きとして課金され続けるため、確認 1 回の費用が会話の長さに比例して効いていた（joshuafolkken/kit#965）。**必要な 1 本だけを開くこと。この索引を入口に、下の表から選ぶ。**
 
@@ -17,11 +17,8 @@
 | Step 2: 提案依頼（AI 共通）                                                                       | [`proposal-request.md`](./collaboration-workflow/proposal-request.md)     |
 | Step 3: 計画コメントを記録して通知する                                                            | [`plan-comment.md`](./collaboration-workflow/plan-comment.md)             |
 | 報告フォーマット（平易な概要 ＋ 技術詳細）                                                        | [`report-format.md`](./collaboration-workflow/report-format.md)           |
-| セッション向け出力で Issue はリンク＋短い日本語要約で参照する                                     | [`issue-citation.md`](./collaboration-workflow/issue-citation.md)         |
-| 後から関連が判明した Issue を epic に束ねる（本文は `epic-commands` skill）                       | [`epic-bundle.md`](./collaboration-workflow/epic-bundle.md)               |
-| オープン Issue の WIP 上限（30 件）                                                               | [`wip-cap.md`](./collaboration-workflow/wip-cap.md)                       |
-| リポジトリをまたぐ EPIC（本文は `epic-commands` skill）                                           | [`cross-repo-epic.md`](./collaboration-workflow/cross-repo-epic.md)       |
-| `josh epic:audit` — 子 Issue 群を横断して矛盾を検出する（本文は `epic-commands` skill）           | [`epic-audit.md`](./collaboration-workflow/epic-audit.md)                 |
+| セッション向け出力で Issue はリンク＋セッション言語の短い要約で参照する                           | [`issue-citation.md`](./collaboration-workflow/issue-citation.md)         |
+| オープン Issue の WIP 上限                                                                        | [`wip-cap.md`](./collaboration-workflow/wip-cap.md)                       |
 | 別パッケージ起因の問題は割り込み Issue で対応する                                                 | [`upstream-interrupt.md`](./collaboration-workflow/upstream-interrupt.md) |
 | 原則 — クローン禁止・シンプル第一・相談と実行の区別・最新優先・恒久ルールと配布物と規則の置き場所 | [`principles.md`](./collaboration-workflow/principles.md)                 |
 | ファイル編集はコマンド本文に本文を載せない                                                        | [`file-edits.md`](./collaboration-workflow/file-edits.md)                 |
@@ -32,12 +29,13 @@
 | 引き金つき配送 — 規則を効く瞬間に届ける                                                           | [`rule-delivery.md`](./collaboration-workflow/rule-delivery.md)           |
 | コマンド出力が文脈へ持ち込む量の上限                                                              | [`output-bounds.md`](./collaboration-workflow/output-bounds.md)           |
 | 運用ルール                                                                                        | [`operating-rules.md`](./collaboration-workflow/operating-rules.md)       |
+| 用語集 — lane・cut・hold・park などの定義と単一ソース                                             | [`glossary.md`](./collaboration-workflow/glossary.md)                     |
 
 **どの 1 本を開けばよいかを決めるのに必要なのは、この索引だけである。** バイト数はここに書かない — 手で保守した数字は本文より先に古くなり、古い数字は無いより悪い。実サイズは `ls -l prompts/collaboration-workflow/` が答える。
 
 ## 参照の書き方
 
-`CLAUDE.md` と `.claude/skills/` からこの正典を指すときは、**本文があるファイルを直接指す**（話題ファイル、skill へ単一ソース化済みならその skill。[`residency.md`](./collaboration-workflow/residency.md)）。索引や指し先を経由させる形（`prompts/collaboration-workflow.md` → 「節名」）は、読み手に 2 回読みを強いるうえ、節名が変わると黙って行き止まりになる。
+`CLAUDE.md` と `.claude/skills/` からこれらの話題を指すときは、**本文があるファイルを直接指す**（話題ファイル、skill へ単一ソース化済みならその skill。[`residency.md`](./collaboration-workflow/residency.md)）。索引や指し先を経由させる形（`prompts/collaboration-workflow.md` → 「節名」）は、読み手に 2 回読みを強いるうえ、節名が変わると黙って行き止まりになる。
 
 ```md
 See `prompts/collaboration-workflow/upstream-interrupt.md`.

package/prompts/review-rubric.md

@@ -74,7 +74,7 @@ code changed, because returning none is what the instruction rules out. So a Med
 the second round even where the fixes were sufficient. The second round is narrowed to remove that.
 
 **What changes is the question, never the standard.** A confirmed High still blocks the merge
-whatever the round count, the cap is still two rounds, and every rule here applies to this pass
+whatever the round count, the cap in `prompts/review.md` → "Review round cap" still holds, and every rule here applies to this pass
 unchanged.
 
 |                | The first round      | The second round                                                                                                                                                               |

package/prompts/review.md

@@ -27,8 +27,8 @@ points to them rather than restating them:
 The workflow review uses the `reviewer` role profile printed by `pnpm josh review:brief`. Pass its
 model and effort explicitly to the review subagent; do not substitute the review level for effort.
 
-Re-run after applying fixes until **no high or medium findings remain — or until two reviews have run
-in total, the first included — whichever comes first.** The cap below is not optional. The second round
+Re-run after applying fixes until **no high or medium findings remain — or until the round cap below is
+reached, the first review included — whichever comes first.** The cap below is not optional. The second round
 is a verification pass over the fixes, not the first review again
 (`prompts/review-rubric.md` → "The second round is a verification pass, not a second full review").
 
@@ -197,7 +197,7 @@ Only branch 2 files an Issue. What follows applies to that branch.
   1. File the follow-up Issue referencing the current one, tagged `route:review-cap` — **before the current Issue closes.**
      `pnpm josh issue:file "<title>" --body-file <body-file> --depth <n> --route review-cap`.
      The command lints the body, applies the classification labels it declares, runs the duplicate scan
-     and then `epic:bundle` on the new Issue (`docs/josh-commands.md` → `josh issue:file`). The
+     and then `epic:bundle` on the new Issue (`docs/josh-commands-automation.md` → `josh issue:file`). The
      `epic:bundle` candidate search reads open issues only, so once the parent has closed it answers
      `none` permanently.
   2. Act on the `epic:bundle` answer it prints. **`epic:bundle` recommends and writes nothing**, so acting means running the

package/prompts/sonar-hotspot-handling.md

@@ -9,9 +9,13 @@ AI tools cannot perform OAuth browser login to SonarCloud, so this guide assumes
 ## Quality Gate enforcement (CI blocks PRs)
 
 The distributed `.github/workflows/sonar-qube.yml` runs the SonarCloud scan with
-`-Dsonar.qualitygate.wait=true`. The scanner waits for SonarCloud to evaluate the project's
-Quality Gate and **fails the `SonarQube` job — a required PR check — when the gate is red**, so a
-PR that introduces a finding cannot be merged green. This is the single enforcement point:
+`-Dsonar.qualitygate.wait=true`, so the `SonarQube` job — a required PR check — fails when the
+Quality Gate is red. **The gate alone is not enough**: `Sonar way` judges ratings and ratios, so a
+few MINOR code smells keep the maintainability rating at A and a small copied block stays under the
+duplication threshold. On a pull request the job therefore ends with `pnpm josh sonar:new-code <PR>`,
+which **fails on a single new issue of any type or severity, or a single new duplicated block**
+(joshuafolkken/kit#3045). An issue resolved in SonarCloud as accepted or a false positive is not
+counted — that resolution is the route for a deliberate exception. This job is the single enforcement point:
 `josh followup` does **not** scan SonarCloud findings (it only scans CodeRabbit / Claude Review
 comments), but it **does** wait on the required `SonarQube` CI check, so a red gate also blocks the
 `followup` merge. Consumers pick the workflow up verbatim via `josh sync`; do not re-implement the
@@ -25,6 +29,10 @@ run without the secret in the Dependabot store), so a repository that relies on
 
 ### New Code vs Overall Code semantics
 
+The scan passes `package.json`'s `version` as `sonar.projectVersion`, so New Code — "since the
+previous version" — restarts at every `josh bump` that reaches main instead of growing from the
+first analysis on.
+
 SonarCloud's default **Sonar way** Quality Gate evaluates **New Code only** — conditions
 (new bugs, new code smells above the Maintainability rating, new coverage/duplication) apply to
 lines changed in the PR's New Code period, not the whole codebase. Consequences:

package/prompts/testing-guide.md

@@ -264,9 +264,9 @@ a repository whose CI reports no `E2E` context at all resolves the required entr
 which is never `pass`, so the evaluation stays `pending` until the 32-minute wait times out with
 nothing actually wrong. What guarantees the job runs is the detection rule above, not the required
 list. A project that wants it required opts in through `JOSH_REQUIRED_CHECKS`, which
-`scripts/git/git-pr-checks-eval.test.ts` covers; the decision itself — `E2E` off the default list,
+`scripts/gh/git-pr-checks-eval.test.ts` covers; the decision itself — `E2E` off the default list,
 and a repository reporting no `E2E` check still mergeable — is pinned in
-`scripts/git/git-pr-checks-e2e-gate.test.ts`.
+`scripts/gh/git-pr-checks-e2e-gate.test.ts`.
 
 **A red E2E is reported as soon as it goes red, and by name.** `E2E` is not on the required list, so
 until joshuafolkken/kit#990 nothing ended the wait when it failed: the rollup read as pending,
@@ -275,4 +275,4 @@ to complete.` — a message naming neither the job nor the cause. Any failing ch
 on the poll that sees it, and the error names it (`PR checks failed (failed checks: E2E).`).
 The poll loop keeps CodeRabbit exempt under the temporary kit#753 policy. **This is a change to how fast the gate
 reports, never to what it lets through** — no failing check gained a path to `success`, which
-`scripts/git/git-pr-checks-e2e-gate.test.ts` continues to assert.
+`scripts/gh/git-pr-checks-e2e-gate.test.ts` continues to assert.

package/scripts/adopt/adopt-toolkits.ts

@@ -167,7 +167,6 @@ const adopt_toolkits = {
 	TOOLKIT_SCOPE,
 	LATEST_VERSION,
 	is_toolkit_package,
-	compare_toolkits,
 	declared_toolkits,
 	misplaced_toolkits,
 	pick_bin_name,
@@ -175,7 +174,6 @@ const adopt_toolkits = {
 	read_bin_name,
 	all_declared_toolkits,
 	is_unreachable_toolkit,
-	resolve_toolkit,
 	discover_toolkits,
 	unresolved_toolkits,
 }

package/scripts/adopt/adopt.ts

@@ -156,13 +156,11 @@ function main(argv: ReadonlyArray<string>): void {
 }
 
 const adopt = {
-	DRY_RUN_REASON,
 	KNOWN_FLAGS,
 	NOTHING_TO_ADOPT,
 	parse_options,
 	run_here,
 	run,
-	main,
 }
 
 if (process.argv[1] === fileURLToPath(import.meta.url)) main(process.argv.slice(ARGV_OFFSET))

package/scripts/agent/agent-argv.ts

@@ -126,8 +126,6 @@ function resolve_in(
 }
 
 const agent_argv = {
-	build,
-	build_resume,
 	resolve,
 	resolve_in,
 	resume_argv,

package/scripts/agent/agent-diagnostics.ts

@@ -115,7 +115,7 @@ function check(profile: AgentProfile, ports: DiagnosticPorts = default_ports): D
 	return check_auth(cli, ports)
 }
 
-const agent_diagnostics = { AUTH_ARGS, MODEL_CLI_FLOORS, PROVIDER_CLI_TABLE, VERSION_ARGS, check }
+const agent_diagnostics = { check }
 
 export type { DiagnosticPorts, DiagnosticResult, ProcessOutcome }
 export { agent_diagnostics }

package/scripts/agent/agent-role-profile.ts

@@ -302,17 +302,11 @@ function parse(value: unknown): AgentProfile | undefined {
 
 const agent_role_profile = {
 	DEFAULT_PROFILES,
-	EFFORT_SCHEMA,
-	ENV_KEYS,
 	HANDED_PROVIDER_KEY,
 	IMPLEMENTATION_PHASE,
-	LEGACY_WORKER_KEYS,
 	MAX_VALUE_LENGTH,
 	OPENAI_PROFILES,
-	PHASE_EFFORT,
-	PHASE_SCHEMA,
 	PRE_GATE_PHASE,
-	PROVIDER_SCHEMA,
 	PROFILE_SCHEMA,
 	REVIEWER,
 	SCHEDULER,
@@ -322,7 +316,6 @@ const agent_role_profile = {
 	has_completion_callback,
 	is_safe_value,
 	parse,
-	phase_effort,
 	resolve,
 	resolve_provider,
 	with_phase_effort,

package/scripts/agent/claude-agent-argv.ts

@@ -143,8 +143,6 @@ const claude_agent_argv = {
 	build,
 	build_resume,
 	resolve,
-	tool_flags,
-	with_profile,
 }
 
 export type { ClaudeArgv, ClaudeArgvResult }

package/scripts/agent/codex-agent-argv.ts

@@ -88,7 +88,7 @@ function build(invocation: string, profile: AgentProfile, cwd?: string): CodexAr
 	}
 }
 
-const codex_agent_argv = { AGENT_COMMAND, AGENT_FLAGS, build }
+const codex_agent_argv = { build }
 
 export type { CodexArgv }
 export { codex_agent_argv }

package/scripts/agent/codex-hooks.ts

@@ -0,0 +1,92 @@
+import { hook_launch } from '#scripts/init/hook-launch'
+
+// `.codex/hooks.json` is derived from `.claude/settings.json`, never written by hand
+// (joshuafolkken/kit#2997). The hand copy carried every hook command twice, so a change to one side
+// left the other silently stale. Codex differs from Claude Code in three places only, and each is a
+// rule applied here rather than a line maintained in the copy:
+//
+// 1. The pretool and posttool handlers run through the Codex input adapter, which translates the
+//    `apply_patch` payload into the Edit/Write shape the Claude-side guards read.
+// 2. The PreToolUse and PostToolUse matchers also select `apply_patch`, Codex's edit tool.
+// 3. UserPromptSubmit carries no matcher — Codex documents that the event ignores it.
+
+interface HookHandler {
+	type: string
+	command: string
+	timeout?: number
+}
+
+interface MatcherGroup {
+	matcher?: string
+	hooks: Array<HookHandler>
+}
+
+type HookEvents = Record<string, Array<MatcherGroup>>
+
+interface HookConfig {
+	hooks: HookEvents
+}
+
+const CODEX_EDIT_TOOL = 'apply_patch'
+const TOOL_EVENTS: ReadonlySet<string> = new Set(['PreToolUse', 'PostToolUse'])
+const UNMATCHED_EVENTS: ReadonlySet<string> = new Set(['UserPromptSubmit'])
+const JSON_INDENT = '\t'
+
+function adapter_command(mode: string): string {
+	return hook_launch.bundle_launch_command(
+		`codex-hook-adapter.js ${mode}`,
+		`pnpm exec tsx scripts/hooks/codex-hook-adapter.ts ${mode}`,
+	)
+}
+
+// Each Claude-side guard command the adapter stands in for, keyed by that command verbatim.
+const ADAPTED_COMMANDS: ReadonlyMap<string, string> = new Map([
+	[
+		hook_launch.hook_launch_command('pretool-guard.js', 'pretool:guard'),
+		adapter_command('pretool'),
+	],
+	[
+		hook_launch.hook_launch_command('format-edited.js', 'format:edited'),
+		adapter_command('posttool'),
+	],
+])
+
+function codex_handler(handler: HookHandler): HookHandler {
+	return { ...handler, command: ADAPTED_COMMANDS.get(handler.command) ?? handler.command }
+}
+
+function codex_matcher(event: string, matcher: string | undefined): string | undefined {
+	if (UNMATCHED_EVENTS.has(event)) return undefined
+	if (matcher !== undefined && TOOL_EVENTS.has(event)) return `${matcher}|${CODEX_EDIT_TOOL}`
+
+	return matcher
+}
+
+function codex_group(event: string, group: MatcherGroup): MatcherGroup {
+	const matcher = codex_matcher(event, group.matcher)
+	const hooks = group.hooks.map((handler) => codex_handler(handler))
+
+	return matcher === undefined ? { hooks } : { matcher, hooks }
+}
+
+function codex_hook_config(claude: HookConfig): HookConfig {
+	const events = Object.entries(claude.hooks).map(([event, groups]) => [
+		event,
+		groups.map((group) => codex_group(event, group)),
+	])
+
+	return { hooks: Object.fromEntries(events) as HookEvents }
+}
+
+// The file text `.codex/hooks.json` holds — the formatter's own output for this JSON, so a write
+// followed by `pnpm josh format:edited` leaves it byte-identical.
+function codex_hooks_text(claude_settings_text: string): string {
+	const claude = JSON.parse(claude_settings_text) as HookConfig
+
+	return `${JSON.stringify(codex_hook_config(claude), undefined, JSON_INDENT)}\n`
+}
+
+const codex_hooks = { adapter_command, codex_hook_config, codex_hooks_text }
+
+export { codex_hooks }
+export type { HookConfig }

package/scripts/agent/interactive-ask.ts

@@ -86,6 +86,6 @@ function refused_ask_of(permission_denials: unknown): string | undefined {
 	return questions.map((question) => render_question(question)).join(QUESTION_SEPARATOR)
 }
 
-const interactive_ask = { INTERACTIVE_TOOLS, is_interactive_tool, refused_ask_of }
+const interactive_ask = { is_interactive_tool, refused_ask_of }
 
 export { interactive_ask }