@joshuafolkken/kit 1.872.0

package/prompts/collaboration-workflow/shell-body.md

@@ -0,0 +1,82 @@
+## 本文をシェルの二重引用符に載せない（joshuafolkken/kit#1198）
+
+`CLAUDE.md` →「Never put a body in shell double quotes」の単一ソース。隣にある「Never carry a file's new text inside a shell command」（[`file-edits.md`](./file-edits.md)）と対になる規則である。**あちらは「ファイルの中身をシェルに載せるな」、こちらは「本文をシェルに載せるな」** であり、禁じている理由が違う — あちらはコストの二重払い、こちらは**テキストが実行されること**である。
+
+### 何が起きるのか
+
+シェルの二重引用符の中では、バッククォートはコマンド置換として、`$` は変数展開として**コマンドが走る前に評価される**。したがって次の呼び出しは、本文を投稿しない。
+
+```bash
+gh api repos/{owner}/{repo}/issues/1535/comments -f body="… `pnpm josh ms` は …"
+```
+
+zsh は `pnpm josh ms` を実行し、その標準出力を本文に埋め込む。2026-09-07 深夜の joshuafolkken/kit#1535 の実行では、これで**レーンの work tree が `main` に切り替わり、実行が止まった**。復旧は手動である。
+
+同じ根がもう 1 つの口にもある。`pnpm josh followup --notify-message "…"` に渡した本文のバッククォート語（`` `owner/repo#` ``）が空文字に置換され、Telegram 通知の 1 行目から語が丸ごと消えた（joshuafolkken/kit#1176 の子 #1182）。**被害の重さが違うだけで、原因は同一である。**
+
+- **通知経路**: 置換結果が本文に混ざる。壊れ方が静かで、`followup` は正常終了する
+- **`gh` 経路**: 置換された結果が捨てられるのではなく、**コマンドとして実行される**
+
+### 実測 — 発火するのは `` ` `` と `$` であって `!` ではない
+
+本リポジトリの実行環境（非対話 zsh）で確かめた結果は次のとおりである。
+
+| 文字            | 二重引用符の中で                                     |
+| --------------- | ---------------------------------------------------- |
+| `` ` ``         | **発火する**（コマンド置換）                         |
+| `$`             | **発火する**（変数展開）                             |
+| `!`             | 発火しない（履歴展開は非対話では無効）               |
+| `\$` / `` \` `` | 発火しない（直前のバックスラッシュがリテラル化する） |
+
+joshuafolkken/kit#1198 のコメントは `!` も発火すると書いていたが、**この環境では発火しない**。引き金にも入れていない — 「!」を含む本文は日常的であり、そこで拒否するフックは[「誤ったターンで発火するフック」](./rule-delivery.md)そのものになる。
+
+### 安全な書き方
+
+**本文をファイルに書いて、パスで渡す。** シェルは本文を一切解釈しない。
+
+```bash
+pnpm josh issue:comment <N> --body-file <path>
+gh api -X PATCH repos/{owner}/{repo}/issues/<N> --field body=@<path>
+pnpm josh followup "<title> #<N>" --notify-message-file <path>
+pnpm josh notify --task-type confirmation --issue-url "<url>" --body-file <path>
+```
+
+**PR コメントも同じ経路である** — REST では pull request のコメントは issue のコメントであり、`pnpm josh issue:comment <N> --body-file <path>` がそのまま使える。`gh issue comment` / `gh pr comment` にも `--body-file` はあるが、本リポジトリの配布ドキュメントは GraphQL 経由の `gh` サブコマンドを実行可能ブロックに書かない（クラウドセッションでは 403 になる。`scripts/gh/gh-document-guard.test.ts`）。
+
+### コメント投稿は `pnpm josh issue:comment` の 1 綴りだけ（joshuafolkken/kit#2304）
+
+**`gh api` には「本文をパスで渡す」の綴りが 2 つあり、片方は黙って壊れる。**
+
+- `gh api ... -F body=@<path>` ／ `--field body=@<path>` — `@` で始まる値を**ファイルとして読む**。正しい
+- `gh api ... -f body=@<path>` ／ `--raw-field body=@<path>` — 値を**そのまま送る**。`@<path>` というリテラル文字列がコメントとして投稿される
+
+`-f` と `-F` は 1 文字違いで、どちらでも `gh` は終了コード 0 でコメント URL を返す。**壊れたことが分かるのは後で人が Issue を見たときだけ**である（joshuafolkken/kit#2304 は park コメント 2 件がこれで失われた）。
+
+だから **Issue／PR コメントの投稿は `pnpm josh issue:comment <N> --body-file <path>` ただ 1 綴りに寄せる** — 間違ったフラグを選ぶ余地が無く、本文は `cli-body.ts` を通ってパスで渡るためシェルも評価しない。`-f body=@…` の綴りは実行前に `pnpm josh rule:guard` が拒否する（列挙表の `raw-field-body` 行、`scripts/rules/raw-field-body.ts`）。上の Issue body 書き換え（`-X PATCH ... --field body=@<path>`）は `-F` 側で安全なので綴りを変えない。
+
+`--body-file` / `--notify-message-file` はいずれも `-` で標準入力を読む（`gh issue create --body-file -` と同じ約束）。読み取りは `scripts/josh/cli-body.ts` の 1 本だけで、`josh notify` / `josh followup` / `epic --rationale-file` / `epic --decision-file` の 4 つがそれを共有する。**`--body` と `--body-file` の同時指定は拒否する** — 優先順位を決めると、ファイルを渡したつもりの呼び出しが、避けようとしていたインライン文字列をそのまま送ってしまう。
+
+**`$'…'` も安全である。** ANSI-C クォートの中ではコマンド置換も変数展開も起きない。`CLAUDE.md` が Telegram の本文に `--body=$'…'` を指定しているのはそのためであり、この規則はそれを置き換えるものではない。ただし本文が長くなるほどファイルの方が扱いやすい。
+
+### 引き金つき配送 — 書いただけでは守られないため
+
+**規則を書くだけでは守られないことは、本リポジトリで繰り返し計測されている**（[`rule-delivery.md`](./rule-delivery.md)）。したがってこの規則は joshuafolkken/kit#1524 の機構に 1 行として載っており、`pnpm josh rule:guard` が該当する `Bash` 呼び出しを拒否して本文を突きつける。列挙表の行は `scripts/rules/delivered-rules.ts` の `shell-body` であり、その行が読む引き金 — どの綴りが本文をインラインで運ぶか、シェルがその値に何をするか — は `scripts/rules/shell-body-trigger.ts` にある。
+
+**引き金はフラグではなく本文の中身である。** 本リポジトリのプロンプトにある作例はいずれもプレースホルダ（`-f body="<plan>"`）を渡しており、これは無害である。フラグで引くと、規則が既に守られているそれらのターンでも拒否することになる。実際にバッククォートか `$` を含む本文が二重引用符に載った瞬間だけが、テキストが実行される呼び出しである。
+
+### 引き金が見えないもの
+
+- **node の中から REST で投稿する経路**（`pnpm josh propagate` など）はシェル文字列に現れない
+- **`gh api --input <file>`** は本文がファイルにあるため、そもそも安全である
+- **`-b`（GitHub CLI の `--body` の短縮形）は覆っていない** — 同じ綴りが `git checkout -b` のブランチ名でもあり、そこで拒否するのは誤ったターンでの発火になる
+- **`-f title="…"`** は覆っていない。タイトルは英語へ正規化された短い語であり、バッククォートを含む運用がない
+
+**この 4 つがあるため、常駐側の 1 行は消していない。** 配送は Claude Code にしか届かず（Codex / Gemini / Cursor はフックを走らせない）、正規表現が知っている綴りだけが規則の適用範囲になってはならない。
+
+### マーカーテスト
+
+- `scripts/josh/cli-body.test.ts` — バッククォート・`$` を含む本文がファイル経由で無改変に通ること、`-` が標準入力を読むこと、通常ファイル以外の読める経路（`/dev/stdin`・プロセス置換）を開けること、インラインとファイルの同時指定を拒否すること
+- `scripts/rules/shell-body-trigger.test.ts` — 危険な綴りで発火し、プレースホルダ・`@file` 形式・エスケープ済み `\$` では無言であること。`body=` のどちら側に引用符があっても発火すること、`$( … )` で包んでもバッククォートは免除されないこと、`$( … )` の中の引用符で捕捉が切れないことを、いずれも発火・非発火の対で固定する
+- `scripts/rules/raw-field-body.test.ts` — `-f` ／ `--raw-field body=@` の綴りで発火し、`-F` ／ `--field body=@`・`@` を含まない本文・`labels[]=`・`pnpm josh issue:comment` では無言であること
+- `scripts/rules/delivered-rules.test.ts` — 上の引き金が列挙表の行に配線されており、非 `Bash` ツールでは無言であること
+- `scripts/rules/shell-body-rule.test.ts` — 常駐 1 行がこの文書を指しており、配送文が被害・安全な綴り・再発行の指示を運ぶこと。**この一覧そのものも固定する** — 一覧が「あるスイートが何を固定しているか」を書きながら、そのケースが存在しないという食い違いが実際に起きた（`-` の標準入力）

package/prompts/collaboration-workflow/simplicity-first.md

@@ -0,0 +1,9 @@
+## 設計はエレガント・シンプルを第一目標にする
+
+新しい仕組み（フック・ガード・ルール・抽象化）を足す前に、**原因側を直せばその仕組みが要らなくならないか**を先に問う。要らなくなるなら、足さない。エレガントでシンプルな設計を第一目標に置き、症状を叱る仕組みを重ねるのではなく、症状を生んでいる材料を断つ。
+
+- **問いは 1 つ**: 「この仕組みは、どこかの原因を直せば不要にならないか」。答えが「不要になる」なら、仕組みではなく原因を直す。
+- **足す前に断つ**: 検出・通知・叱責を強化する前に、その入力を生んでいる側を探す。入力が消えれば、それを捌く仕組みそのものが消える。
+- **適用例（joshuafolkken/kit#2329）**: セッション向け出力に裸の `#N` が混じり、`Stop` フックが返答全体を出し直させて重複が起きていた。素朴な答えは叱る側（フック）の強化だが、エレガントな答えは**裸の `#N` を供給している印字側を直す**こと。材料が消えれば叱られる回数そのものが減る。
+
+このルールは横断ドキュメント（`CLAUDE.md` の「設計はエレガント・シンプルを第一目標にする」）のカノニカル参照。**書かれたコードの可読性**（camelCase を避ける、意図が伝わる命名、過度な抽象化を避ける、など）は `prompts/coding-standards.md` の担当で、こちらは**設計時にどの仕組みを足すか・どこへ置くかを決める**規則。両者は別レイヤーなので、片方の本文をもう片方へ写さず、互いを指すだけにする。

package/prompts/collaboration-workflow/single-source-rules.md

@@ -0,0 +1,13 @@
+## エージェント規則の単一ソースは `CLAUDE.md`（`AGENTS.md` / `GEMINI.md` は導線）
+
+**規則の本体は `CLAUDE.md` にしか無い。** `AGENTS.md` と `GEMINI.md` は「規則は `CLAUDE.md` にある。作業前に全文を読むこと」だけを書いた短い導線文書であり、規則を 1 行も持たない（joshuafolkken/kit#963）。
+
+- **規則の追加・仕様変更・文言修正・節の追加は `CLAUDE.md` に 1 回だけ書く。** 他の 2 本には触れない
+- **導線文書に規則を書き戻さない。** そこに書かれた規則は、次の改訂で更新し忘れる 4 つ目の置き場になる
+- `scripts/document/ai-document-pointers.test.ts` が機械的に守る。導線文書に規則本体が再出現した場合、導線の一文が消えた場合、`CLAUDE.md` が単一ソースであることの記述が消えた場合に落ちる
+
+**なぜこうなったか。** 3 本はほぼ同一の複製で、規則を 1 つ変えるたびに 3 回書いて 3 回レビューする必要があり、しかも 3 本とも常駐上限まで 1KB を切っていた。これは `CLAUDE.md` 自身が「No clones — single-source」で禁じているクローンそのものであり、禁止を書いている文書がその禁止に違反している状態だった。
+
+**他ツールでの検証は行っていない。** Codex / Cursor / Gemini CLI が導線を辿るかは未確認で、現在 Claude しか使っていないという判断による（joshuafolkken/kit#970 の `## Decisions`）。導線を辿らないツールを使い始める時点で、そのツールについて別途扱う。
+
+- このルールは横断ドキュメント（CLAUDE.md「Doc Sync Rules」）のカノニカル参照

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

@@ -0,0 +1,137 @@
+# 独立した呼び出しは同じターンに載せる（joshuafolkken/kit#1304）
+
+`CLAUDE.md` →「Put every call that does not depend on another's result in the same turn」の正典。**常駐側にはトリガと判断基準の 1 行だけが残り、規則本文は `pnpm josh batch:guard` が効く瞬間に配送する**（joshuafolkken/kit#1524、下の「なぜ resident ではなく引き金つき配送に置くか」）。
+
+## 何を求めているか
+
+**判断は 1 問で決まる。**
+
+> **この呼び出しの入力は、いま出していない別の呼び出しの結果に依存しているか。**
+
+- no → **その呼び出しは、依存していない他の呼び出しと同じターンに載せる**
+- yes → 結果を待つ。別のターンになるのが正しい
+
+依存していない呼び出しを 1 つずつ別のターンに出す形が、この規則が禁じているものである。ファイルを 3 つ読むために 3 ターン使う、同じファイルの離れた 3 箇所を直すために 3 ターン使う、`git status` と `pnpm josh issue:state` と `pnpm josh latest:scope` を 3 ターンに分ける — いずれも後続の入力が前の結果を使っていない。
+
+## なぜターン数が費用なのか
+
+**費用は仕事の量ではなく往復の回数にある。** joshuafolkken/kit#1295 の run（1,471 秒 / 153 ターン）で実測した:
+
+| 種別                                                             | 回数 | ツール実行時間の合計 |
+| ---------------------------------------------------------------- | ---: | -------------------: |
+| `Edit`                                                           |   34 |                48 秒 |
+| 読み取り系の小さな `Bash`（`grep` 12 / `sed` 11 / `cat` 4 ほか） |   32 |                 6 秒 |
+
+**ツール自体が動いていたのは合わせて約 54 秒**である。同じ 66 往復が消費した壁時計は 66 × 9〜13 秒 ≒ 600〜850 秒で、1 桁違う。1 ターンあたりの壁時計は 9〜13 秒の狭い帯に収まるので、**ターン数がそのまま run の下限を決めている。**
+
+epic #1262 の子（#1256〜#1260）がゲートを 133 秒から中央値 5 秒まで削ったのに run 全体が 5% しか縮まなかったのは、これが理由である。削った先が壁時計を決めていなかった。
+
+## 判断基準は「依存の有無」であって、呼び出しの種類ではない
+
+読み取りだけの規則ではない。**`Edit` も同じ規則の対象である** — 同じファイルの離れた領域や、別々のファイルへの編集は、互いの結果を使っていないので同じターンに載る。実測で最大の単一項目が `Edit` 34 回だったのは、そこが最も守られていなかったからである。
+
+逆に、**依存があるなら分けるのが正しい。** 次はいずれも 1 つ前の結果を入力に使うので、同じターンに載せてはならない。
+
+- `grep` の結果を見てから、その行番号で `sed -n` を出す
+- `git switch` の成否を見てから `pnpm josh latest:scope` を出す
+- Edit の対象文字列を確かめるために先にファイルを読む（**Edit の前に読むことは省略できない**）
+
+## 検証ゲートとレビューは往復を減らす対象ではない
+
+**ゲート・レビュー・差分の読み取りを、往復を減らす名目で弱めてはならない。** これは joshuafolkken/kit#1304 の受け入れ条件そのものである。具体的には:
+
+- `pnpm josh gate` の出力を絞り込んで読む、失敗の内訳を読まずに次へ進む — いずれも禁止
+- `git diff main...HEAD` を一部だけ読んでレビューを「指摘なし」と結論づける — 禁止（`output-bounds.md` →「切り詰められた出力を、完全な出力として読まない」と同じ理由）
+- 単発の再実行（`pnpm josh lint:related` / `pnpm josh test:related`）をまとめるために、走らせるべきチェックを落とす — 禁止
+
+**往復を減らすのは「同じ仕事を少ないターンで出す」ことであって、「仕事を減らす」ことではない。** 減らしてよいのはターンの数だけである。
+
+## 機構で強制しない理由（却下した案）
+
+- **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 回だけ**である（フックが読む窓を超えて続く連続では、列の開始が窓の外へ出るため窓ごとに 1 回になる — 詳細は下記の `docs/josh-commands.md`）。機構の全体は `docs/josh-commands.md` →「`josh batch:guard`」にある。
+
+  **フックはフォークにも届く。** joshuafolkken/kit#1424 以降、判定も「1 回だけ」の記録も、親ではなく**フォーク自身の transcript** を鍵にする — フックの入力にある `agent_id` から解決する `time_hook_transcript.transcript_of`（`scripts/time-runtime/time-hook-transcript.ts`）が単一ソースで、ガードは `scripts/josh/hook-decision.ts` 経由でそこを通る。委譲された子やレビューエージェントは、親の記録を共有せず、それぞれに配送される。
+
+  **書き込みが範囲に入ったのは joshuafolkken/kit#1762 である。** それまでの限界は 2 つあり、どちらも書き込みに一度も届かないという同じ結果になっていた。joshuafolkken/kit#1509 が、同じファイルを続けて編集する区間では共有ターゲットの判定が列を毎回捨てて数え直すため拒否に必要な 2 件に列が届かないことを特定し（`time-bundles.ts` の write→write 例外として解消済み）、そのうえで**配線が `Bash` のみだったので `Edit` の連続にはそもそもフックが呼ばれなかった**。実測 19 run で、回収できる往復 261 件のうち **184 件（70.5%）が書き込み**、`Edit` だけで 158 件（60.5%）— 最大の寄与源が構造上ずっと圏外だった。
+
+  **却下されていたのは「マッチャだけを広げる案」であって、「書き込みを拒否可能にする案」ではない。** 判定述語が書き込みに常に `false` を返す状態でマッチャだけ広げれば、必ず「許可」としか答えられないプロセスが編集ごとに 1 つ増える — この費用の議論は正しく、いまも有効である。joshuafolkken/kit#1762 は**先に述語を広げて**から配線を `Bash|Edit` にしたので、マッチャが届く先には答えのある問いがある。
+
+  **「拒否された編集は兄弟だけが適用されて自分は残らない」という安全側の懸念は、除外ではなく依存判定の絞り込みで塞いである。** 実害が出るのは「いま書き換え中のファイル」を名指す編集だけなので、**手元の呼び出しが直前の列と共有ターゲットを持つときは拒否を取り下げる**（書き込み同士を含む）。残るのは列がまったく触れていないファイルへの編集で、その再発行は書いたときとまったく同じ本文に当たる。
+
+  **塞ぎきれないのは「いま中断しているターンの中身」であり、これは transcript から観測できないので設計上残る。** 同じファイルへの編集 3 件を 1 ターンにまとめた場合、先頭だけが拒否され残り 2 件が適用されることはある。**ただし壊れるのではなく失敗する** — 拒否されうる書き込みはいずれも本文で位置を決める形なので、再発行された編集は書いたときの本文に一致するか、一致せずに報告されるかのどちらかである。誤った位置に当たることはない。通常は 1 往復、この場合でも編集 1 件のやり直しで、読み取り側が既に受け入れている誤検知の代償と同じ大きさである。
+
+  **ファイル全体を書き出す `Write` だけは拒否しない。それがこの上限を成り立たせている。** 再発行された `Write` は本文を照合しないので、そのターンの兄弟が適用した編集を無言で上書きしうる。1 つのファイルを `Write` してから `Edit` するターンは実際に起きる形なので、例外ではなくツール名で除外してある。`>` によるシェルの上書きも同じ性質だが、衝突するには 1 ターンに同じパスへの書き込みが 2 件必要で、そういう形は起きない。
+
+  **読み取りが範囲に入ったのは joshuafolkken/kit#1798 である。** `Read` は述語（`is_guarded_call`）では最初から候補として扱われていた — 配線が `Bash|Edit` のままだったので、フックがそもそも呼ばれなかっただけである。`fullrun #1783` の実測では、本流 76 リクエストのうち **46 が単発**、3 連続以上の塊が **7 つ**あったのに対し、拒否は **2 回**しか発火していない。7 つのうち 4 つが `Read` / `Write` / `Agent` を含み、いずれも配線の外だった。**計数側は正しかった** — 単発ターンが連続を延長するかどうかは `is_bundleable` が決めており、`Read` / `Glob` / `Grep` / `Write` はいずれも延長する。連続を切るのは「そもそもまとめられない呼び出し」、すなわち結果を次の呼び出しが必要とする委譲である。したがって直したのは配線だけで、`Bash|Edit|Read` になった。
+
+  **事務コマンドが範囲に入ったのは joshuafolkken/kit#1875 である。** `is_bundleable` は先頭語の allow-list（`READ_COMMANDS`）と mutation deny-list で判定するので、**`pnpm` で始まる `pnpm josh …` はすべて非バンドル**だった — 書き込む josh コマンド（`gate` / `followup` / `git`）を弾くための `pnpm` が、読み取り専用の `issue:state` / `release:scope` まで一緒に落としていた。結果として事務往復は `Bundling:` の回収可能数にも `batch:guard` の判定にも一度も現れず、run の最も高い終盤で最大の事務カテゴリが構造上ずっと圏外だった。**直したのは判定であって規則ではない**（この Issue の受け入れ条件そのもの）: 読み取り専用サブコマンドの allow-list（`READ_JOSH_SUBCOMMANDS`、別名は正準名に解決してから照合）を足し、これに載る `pnpm josh` を bundleable にした。書き込む・外部送信するサブコマンド（`run:progress --mark` はマーカーを書き、`notify` は送信し、`main:sync` / `epic` / `run:hold` は状態を書く）は allow-list に**入れない** — 取りこぼしは floor、誤って入れれば claim、というこのモジュール一貫の非対称性に従う。連鎖した行（`&&` / `|` / `>` など）は、先頭の `pnpm` が後続の変更を隠すため読みとしては信用せず、通常判定に落とす。**guard を弱めるのではなく、これまで見えていなかった呼び出しに届かせる強化である。**
+
+- **複数編集を 1 呼び出しにまとめるツールを前提にする。** 前提にできない。この repository が対象とする harness には常に存在するとは限らず、存在しない側では規則が一度も発火しない。**同じターンに複数の `Edit` を並べる形はどの harness でも成立する**ので、規則はそちらで書く。**ただし joshuafolkken/kit#2366 が「そちらで書く」前提を実測で反証した** — 直近 6 レーンで 230 ターンすべてが単発（密度 1.000）、native な複数編集は一度も起きていない。却下されたのは _harness の_ ツールを前提にすることで、`pnpm josh` はどの harness にも存在するから、#2366 は合成コマンド `pnpm josh edit:files` を置いた（下節）。却下はそのまま有効で、答えはその外側にある。
+- **ターンごとに件数の下限を課す。** 却下。依存が連続する区間では 1 件が正しい答えであり、下限は正しい振る舞いを罰する。上限も下限も持たないのが正しく、**代わりに事後の計測を置く**（次節）。
+
+harness 側の一般的な指示（「依存のない呼び出しは同じブロックで出す」）は**すでに存在していて、実測では発火していなかった** — 4 本の run で 1 往復あたり 1.13 / 1.04 / 1.03 / 1.00 呼び出し。一般論だけでは動かないので、この文書は **判断基準を 1 問に固定し、守られていなかった具体形を名指しし、結果を数字で見えるようにする**という 3 点で置き換えている。`file-edits.md` が同じ 3 点で出力トークン側を動かしたのと同じ形である。
+
+## 事後の計測 — 実行タイミングレポートの `Round trips:`
+
+強制の代わりに、**結果が毎回の計測に出る。**
+
+```
+Round trips:
+  tool calls                    104   over 153 turn(s)
+  round trips                   104   1.00 calls per round trip
+  ⚠ independent calls are going out one per turn (floor 1.50 calls per round trip)
+```
+
+- **round trip は「1 ターンがまとめて出した呼び出しのかたまり」1 つ**であって、呼び出し 1 件ではない。まとめて出せば呼び出し数はそのままで往復だけが減る — つまりこの数字は、仕事を減らさずに費用だけ下げたかどうかを直接見せる
+- **しきい値は 1.50 呼び出し/往復。** 下回ると 1 行の指摘が出る。少しでもまとめている run は超えるので、これは程度を採点するのではなく**まとめていないこと**を検出する
+- **`tool-less turns` の行は、ツールを 1 つも呼ばなかったターン数**（`turn_count − round_trips`、joshuafolkken/kit#1875）。`batch:guard` は発話だけのターンを拒否できない — 呼ぶツールが無く `PreToolUse` が発火しないので、唯一の梃子がこの事後計測である。`Bundling:` はこれを構造上見られない（まとめる対象を持たないターンは列に入らない）。実測 run #1864 は 177 ターン中 149 が呼び出しあり、**28 がツールなし**だった
+- 実装は `scripts/time-runtime/time-round-trips.ts`、詳細は `docs/josh-commands.md` の `time` コマンドの項
+
+## 実装中の独立編集に効く合成コマンド（joshuafolkken/kit#2202）
+
+**フックが届かない一区間が残っていた — レーン子の実装中の独立編集である。** `pnpm josh batch:guard`（拒否）は本流で密度を動かしたが、レーン子（headless `claude -p`）では拒否がターンを終わらせて子を殺すため発火できず（#2138）、代わりの通知も数字を動かさなかった（#2164）ので #2178 は子でガードを `off` にした。残ったのが、別々のファイルへ `Read` → `Edit` を交互に出す 9 ターンの並び（#2178 計測）で、編集集合が事前確定の定型でないため既存の合成コマンドでは畳めなかった。
+
+**しかし 1 手前に確定している — Step 0 が変更ごとに対象ファイルを列挙する。** `pnpm josh read:files` はその点で読み取りを畳む合成コマンドである（密度を動かした実績があるのは合成コマンドだけ — #2165 / #2162 — で、助言・提示・通知はいずれも動かさなかった）。「もう一度言う」形ではなく、`report-format.md` が Step 0 の継ぎ目（`josh lines` の隣）でランをここへ導く**手順**である。
+
+**梃子の本体は読み取りと編集の脱交互化（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 ターン**になる。
+
+**#2164 / #2178 の成果は後退しない** — バッチガードにもレーンガードポリシーにも触れないので、子は拒否で殺されず、効かない助言の毎ターンの文脈費用も払わない。上限超過時は `read:files` が「Read ツールで 1 ターンにまとめて読め」と返しフォールバックでも読み取りは畳まれたまま。詳細は `docs/josh-commands.md` →「`josh read:files`」。
+
+**編集自体を畳むコマンドは #2202 では置かず（native な複数編集を優先、上の却下案第 1 項）、joshuafolkken/kit#2366 がそれを置いた。** #2202 の「native に委ねる」判断は 230/230・密度 1.000 で反証済み。合成コマンドだけが密度を動かしたのと同じ理由で、書き込みは `pnpm josh edit:files` で畳む — 編集を **プラン（`=====` のパスヘッダ＋ git conflict マーカー対）** として受け取り 1 呼び出しで適用し、各編集は content-addressed なので `old` が 1 箇所に一致しなければ拒否して報告する。#2493 で `-`（標準入力）を受け、依存編集は `dependent` で拒否する。詳細は `docs/josh-commands.md` →「`josh edit:files`」。
+
+## ガード発火時にも合成コマンドを手渡す（joshuafolkken/kit#2311）
+
+**#2276 は通知に「直前に 1 件ずつ出した具体的な呼び出し」を名指しさせたが、密度は動かなかった（実測 1.084、ベースライン 1.147 を下回った）。** 名指しても通知は依然「1 ターンにまとめて出し直せ」と求めており、これはモデルが構造的に苦手とする並列 `tool_use` ブロックの要求である。梃子として実績があるのは合成コマンドだけ（上節・#2165 / #2162）なので、ガードが**単発の読み取り連続**で発火したとき、通知はその読み取りを畳む `pnpm josh read:files <path> …` を貼り付け可能な形で手渡す — モデルが 1 ターンで確実に出せる単一の呼び出しである。
+
+**読み取りに限り、2 件以上のときだけ。** 書き込みは `read:files` の対象外なので除外し、読み取り 1 件は既に単発なので畳むものがない。実装は `scripts/time-runtime/time-batch-guard.ts` の `recent_candidates`（`read_fold_directive`）で、全通知配送が通る唯一の地点である。密度が計測されるのはレーン子（`notice` モード）なので、ここに合成コマンドを差し込むのが計測面に一致する。#2202 の Step 0 継ぎ目での畳み込みを、ガードが発火する実装中の一点へ広げたものであり、「もう一度言う」形の追加ではない。
+
+**書き込み側も同じ地点で手渡す（joshuafolkken/kit#2366）。** 単発 `Edit` の連続でガードが発火したとき、通知はその編集を名指し、それらのファイルにわたる `pnpm josh edit:files` の畳み込みを添える（`write_fold_directive`）。読み取りはパスだけで畳めるが編集は本文を伴うので、貼り付け可能なのはコマンドとファイル名までで、プラン本体はモデルが書く — それでも並列 `tool_use` ブロックではなく 1 ターンで出せる単一呼び出しに落ちる。`Edit` だけを数え、content-address できない `Write`（既に独自の通知を持つ）は除く。
+
+## なぜ resident ではなく引き金つき配送に置くか（joshuafolkken/kit#1524）
+
+**この規則は常駐から外れている。** `pnpm josh batch:guard` が、単発呼び出しのターンが 3 つ続いた次の呼び出し（`Bash` / `Edit` / `Read`）を拒否し、そこで規則本文を突きつける — 規則が効く瞬間そのものである。配送の判定基準と機構は `rule-delivery.md` にある。
+
+**移設で失われた散文は、そもそも効いていなかった。** 上の「却下した案」の直後に記録したとおり、常駐の一般指示があった状態での実測は 1 往復あたり 1.13 / 1.04 / 1.03 / 1.00 呼び出しであり、常駐している間ずっと守られていなかった。数値を動かしたのは joshuafolkken/kit#1390 のフックである。したがって**常駐をやめても失われるのは「読み飛ばされていた文」だけ**で、実際に効いていた経路は残る。
+
+**引き金が発火しないターンでは何も起きず、それが正しい。** 発火しないということは往復あたりの呼び出し数が下限（1.50）を上回っているということであり、規則が守られている状態と一致する。
+
+配送文（`scripts/time-runtime/time-batch-guard.ts` の `REASON`、および `time-density.ts` の実行時 1 行）が運ぶのは次の 2 点である。常駐側に残していたのと同じ内容であり、削っていない。
+
+1. 別の呼び出しの結果に依存しない呼び出しは、同じターンに載せる
+2. 判断基準は「依存の有無」であって呼び出しの種類ではない（読み取りも編集も同じ）。かつ、往復を減らすことは仕事を減らすことではない
+
+実測値・却下した機構案・計測の読み方はこのファイルにあり、配送文からは落としている。
+
+**上の「却下した案」の第 1 項と矛盾しない。** あれが却下したのは「1 件の呼び出しだけを見て独立性を判定する」形であり、joshuafolkken/kit#1390 が実装したのは**閉じた履歴**（既に終わったターンの並び）から判定する形である。単発呼び出しのターンが 3 つ続いたことは 1 件の呼び出しからは見えないが、履歴からは見える。
+
+## マーカーテスト
+
+`scripts/rules/turn-batching-rule.test.ts` が次を固定する。
+
+- 配送文が規則のトリガ文と判断基準の一文を運んでいること
+- 配送文の指し先が `CLAUDE.md` ではなくこのファイルであること（規則が常駐していない以上、`CLAUDE.md` を指す参照は何も指していない）
+- このファイルが判断基準・却下した機構案・ゲートを弱めない条件・計測の読み方を持っていること
+- 実測値（`600〜850`、`1.13`）が常駐側にも residency 一覧にも貼り戻されていないこと
+- 配送されている規則の一覧（`rule-delivery.md`）と residency の一覧（`.claude/skills/workflow-commands/SKILL.md` とこのディレクトリの `residency.md`）にこの規則が載っていること

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

@@ -0,0 +1,51 @@
+## 別パッケージ起因の問題は割り込み Issue で対応する
+
+作業中（実装・検証・レビュー対応のいずれの段階でも）に新たな課題を発見した場合、**即席対応を優先せず根本的な解決を先に行う**。発見した問題が、実は別パッケージ（依存パッケージや、このプロジェクトが消費している配布元 = kit / `josh` ツールなど）に起因する場合でも同様で、現在のリポジトリ内のローカル回避策（ハック・パッチ・回避コード）で押し切ってはならない。根本原因を **対象パッケージ側** で解決する。
+
+### 無条件ルール: 起票は確認なし、停止は必ず
+
+**この手順に「これは今の作業をブロックするか？」という判定は一切存在しない。** 上流の欠陥は、ブロックするものもしないものも、**発見した時点で**同じ手順を通る。例外はない。
+
+- **トリガーは「発見」であって「ブロックし始めたとき」ではない**。ブロック判定は作業を先へ進めたい圧力の下で下されるため、回避策が最も魅力的な瞬間に「ブロックしない」へ倒れる。しかも「ブロックするか」の線は発見時点には存在しない — 非ブロックに見えた欠陥が完了ゲートで初めて牙を剥いたときには、既に手心が加えられた後である。判定そのものを置かないことで、一時凌ぎがツリーに入る前にルールが発火する
+- **起票は Tier A（確認なし）**。起票してよいか、どのリポジトリへ起票するか、いずれもユーザー確認を取らない。起票は元々このルールが指示している行動であり、確認は何も生まない。**ただしこれが成り立つのは対象が first-party のときだけ**であり、third-party リポジトリへの書き込みは Tier C として明示指示を要する（→「第三者リポジトリへの書き込みは Tier C（明示指示が必要）」）
+- **停止は無条件**。Issue が存在する状態にしてから停止する。上流の修正を待つか先送りするかは、Issue を目の前にしたユーザーが決める
+- **多少の冗長さは許容コスト**。ユーザーが素通りさせたはずの発見で停止しても往復 1 回で済むが、見送るべきだった発見を素通りさせると、回避策が全消費者に配布されるリポジトリへ入る。たまに外す判断より、毎回適用する一律ルールを採る
+- **`backlogrun` の中では、停止の範囲がセッション全体ではなくその子 Issue に限定される**。起票は変わらず無条件（first-party なら Tier A）で、回避策の禁止も変わらない。変わるのは停止の及ぶ範囲だけであり、該当の子に `needs-decision` を付けて park し、依存していない他の子へ進む（→「backlogrun — 子 Issue の無人実行」）。回避策を書かせないという本来の目的は、起票と回避策禁止が保たれることで維持される
+
+手順:
+
+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 を作成する（確認なし）**: `gh api repos/<owner>/<repo>/issues -f title="<root-cause title>" -f 'labels[]=route:tier-a' -f 'labels[]=depth:<n>' -f body="<root cause and context>"`（`route:tier-a` は実装中の Tier A 起票を経路として集計するためのラベル — joshuafolkken/kit#1083。付与するのは first-party の場合だけで、third-party はそもそもこの手順に到達せず起票しない）。根本原因・再現・期待結果を Step 1 のテンプレに沿って記載し、**本文に `## Origin` 節を置いて起票元 Issue を `owner/repo#N` 形式で書く**（→「起票元へのバックリンク」）。上流 Issue は欠陥を、起票元 Issue は証拠を持つため、リンクがないと上流 Issue は後から解釈できなくなる。ここで「起票してよいか」を尋ねて停止してはならない。**ただし確認なしで起票してよいのは対象が first-party のときだけ**で、third-party（owner が自リポジトリと一致しないリポジトリ）なら起票せずに停止する（→「第三者リポジトリへの書き込みは Tier C（明示指示が必要）」）
+4. **`confirmation` Telegram を送って停止する**: 上流 Issue の URL と、何が止まっているかを本文に書く（→「確認待ちで停止するときの Telegram 通知（`confirmation`）」）。無人実行でも画面外でユーザーが気付ける。停止は Issue が既に存在する状態で行うので、ユーザーは「待つ / 先送りする」を Issue を見ながら 1 語で答えられる
+5. **元の作業を再開する**: 上流の修正がマージされた、または**ユーザーが先送りを明示判断した**後に `pnpm josh stash:pop "upstream-interrupt: paused #<N>"`（位置指定や引数なしの `git stash pop` は使わない — stash は全 work tree が共有する 1 本のスタックで、別のレーンの stash を取り込む恐れがある）して、退避していた元タスクを続行する。上流 Issue を割り込みで実装するかどうかもユーザーの判断（上流パッケージの実装・PR・マージはそれぞれのワークフロー規則に従う）
+
+### 第三者リポジトリへの書き込みは Tier C（明示指示が必要）
+
+上の「起票は確認なし」は **first-party の集合**（kit / app-kit / game-kit / jgame）を前提に書かれている。トラッカーが自分たちのもので、重複起票のコストがバックログ 1 行で済むからである。**自分たちが所有しないリポジトリへの書き込みは、これとは別物**として扱う。
+
+- **判定は機械的に行い、判断に委ねない**: `pnpm josh repo:party [<owner/repo>]` が `first-party` / `third-party` / `unknown` の 1 語で答える（対象リポジトリの owner がセッションのリポジトリの owner と一致すれば **first-party**、owner を読めなければ **unknown** で third-party 扱いはしない）。**それ以外は全て third-party** で、fork も、単に contribute しているだけの org リポジトリも third-party に入る。この判定は `delivered-rules.ts` の `third-party-write` ルールが同じ計算を使って third-party への `gh api` 書き込みを拒否する（読み取りは素通し）
+- **first-party は従来どおり**: Tier A。確認なしで起票し、双方向バックリンクを書き、停止する。kit / app-kit / game-kit のフローに新しい摩擦は加わらない
+- **third-party は書き込みの種別を問わず Tier C**: Issue・コメント・PR・Discussion・レビューのいずれも、**その turn におけるユーザーの明示指示**なしに行ってはならない。公開は外向きかつ実質不可逆で、Issue はユーザーの GitHub アカウント名義で公開され、watcher へ通知され、検索に載る。後からクローズしてもそのいずれも取り消せない。加えて、誰も差し出すと約束していないメンテナの時間を消費する
+- **third-party だと判明したときの手順**: (1) **自分たちの側の Issue** に証拠込みで所見を記録する。見出しは `## Upstream candidate` を使い、`## Upstream issues` は使わない（後者は「起票済み」を主張する見出しであるため）。(2) 報告本文の下書きをその Issue 内に用意し、ユーザーが 1 メッセージで承認できる状態にする。(3) 対象プロジェクト名と報告しようとしている内容を書いた `confirmation` Telegram を送って**停止する**
+- **third-party 報告の証拠バー**（下書きを提示する前に満たす）:
+  - **自プロジェクトの外で成立する最小再現**（対象の依存だけを入れた素の scaffold）。用意できない場合は「プロジェクト組み込みの再現しかない」ことを下書きに明記する
+  - **本文の全主張が検証済み**であること。推測を事実として書かない
+  - 同じ欠陥を扱う**既存 Issue の検索**
+- **取り下げも外向きの行為**: 既に起票した third-party Issue のクローズ・編集・コメントも、同じく明示指示を要する
+- **正しい診断は公開の許可ではない**。sveltejs/kit#16623 の事例では所見自体は上流のソースで検証可能な正しいものだったが、手順として誤っていた。所見の正しさは、この節のどの要求も免除しない
+- このルールは横断ドキュメント（CLAUDE.md「Third-party repositories are Tier C」）のカノニカル参照
+
+### 検証ゲートを緩めることも「回避策」である
+
+ローカルに回避コードを書くことだけが違反ではない。**上流の欠陥に合わせて `lint` / `tsc` / `cspell` / unit / E2E の出力を絞り込む・狭める・読み替える行為も、ローカルパッチを書くのと同じ違反**であり、同じ停止を引き起こす。
+
+- 典型例: 上流が配布する設定によって生成されるディレクトリ由来の型エラーを除外し、「プロジェクトソースはエラー 0」として完了ゲートを通過したことにする
+- **絞り込んだことを正直に開示しても、ルールを満たしたことにはならない**。完了報告の読者は「緑ではない型チェック」を緑として受け取る
+- 検証ゲートは上流の欠陥に合わせて調整しない。**調整したくなった時点が、このルールの発火点**である
+
+注意:
+
+- **即席回避と根本対応は「迷って選ぶもの」ではない**。上流起因と分かった時点で選択肢は根本対応だけであり、「今回は軽いから即席で」という判断はこの手順に存在しない
+- 別パッケージへの新 Issue 作成・stash・Issue コメントは可逆かつ低コストな調査/起票操作なので、Tier C（不可逆・共有状態の操作）ではなく Tier A として確認なしで進める。ただし上流パッケージの **マージ等の共有状態操作** は通常どおりそれぞれのワークフローの明示起動を要する。**「可逆かつ低コスト」という前提が成り立つのは自分たちが所有するリポジトリに対してだけ**で、third-party への起票は外向き・実質不可逆なので Tier C になる（→「第三者リポジトリへの書き込みは Tier C（明示指示が必要）」）
+- このルールは横断ドキュメント（CLAUDE.md「Cross-package problems → file the upstream Issue, then always stop」）のカノニカル参照

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

@@ -0,0 +1,118 @@
+# オープン Issue の WIP 上限（30 件）
+
+**単一ソースはこのファイルである。**
+
+**この規則は常駐していない — 引き金つき配送に移った**（joshuafolkken/kit#1524）。`pnpm josh rule:guard` が Issue を作成する `Bash` 呼び出し（`gh issue create`、または `…/issues` への `title` 付き POST）を拒否し、そこで数え方・拒否・2 つの免除・免除を決める 3 条件を突きつける。起票が無いターンでは何も起きず、それは上限に触れる行為が無いということである。配送は**ラン 1 回につき 1 度**なので、数えたうえで同じ呼び出しをもう一度出せばよい。機構と列挙表は `rule-delivery.md`、配送文の実体は `scripts/rules/delivered-rules.ts` の `WIP_CAP_REASON` にあり、`scripts/backlog/backlog-manufacturing-rule.test.ts` がその中身を固定している。
+
+## 規則
+
+**オープン Issue が 30 件を超えている状態で新しく起票するときは、先に 1 件閉じる。**
+
+件数は毎回数える。見積もりでも記憶でもない。
+
+```bash
+gh api "repos/{owner}/{repo}/issues?state=open&per_page=100" --paginate \
+  --jq '.[] | select(.pull_request == null) | .number' | wc -l
+```
+
+- **数えるのは「起票しようとしているリポジトリ」のオープン Issue 全件**である。`{owner}/{repo}` はカレントリポジトリに展開されるので、**別リポジトリへ起票するときはそのリポジトリのパスを直接書く**（例: `repos/joshuafolkken/app-kit/issues?...`）。自リポジトリの件数で他リポジトリへの起票を判断するのは、別のバックログを見ているのと同じである。
+- epic も子も含める。epic を除外すると、epic を作ることで上限を回避できてしまう。
+- **上限は 30。** 31 件目以降を作る前に 1 件閉じる。
+- **プルリクエストは数えない。** REST の `issues` エンドポイントは PR も返すため、`select(.pull_request == null)` で落とす。この 1 句を省くと、PR が開いているだけで上限に達する。
+- **`gh issue list` は使わない。** 配布ドキュメントの実行可能ブロックに置ける `gh` は REST のものだけで、`gh issue list` は GraphQL 経由のためクラウドセッションで 403 になる（`scripts/gh/gh-document-guard.test.ts`）。
+
+## なぜ上限が要るのか
+
+2026-09-06 までの 7 日間で起票 257 件・クローズ 163 件、**1 日あたり +13.4 件**。直近 14 日は 14 日すべてで起票がクローズを上回った。一方 `fullrun` は PR 作成からマージまで中央値およそ 10 分で、**処理速度は問題ではなかった**。到着側が処理側を上回り続けていたのであり、オープン件数に上限が無いため、その増加は誰にも見えないまま蓄積した。
+
+**上限は、増加を見えるようにするための強制装置である。** 数を減らすこと自体が目的ではない。30 を超えた状態で起票しようとしたときに「本当にこれは 1 件増やす価値があるか」を必ず 1 回考えさせる、そこだけが役割である。
+
+## 超過時の手順
+
+起票しようとした時点で 30 件を超えていたら、**その起票が裁量によるものか、実行がそれに詰まっているか、割り込みか**の 3 つに分岐する。判断ではなく、起票の種類で決まる。**上限が効くのは裁量側だけである。**
+
+**判定するのは「起票 1 件」ではなく「起票のひとまとまり」である。** 分割判定が作る子 N 件とその epic、割り込み Issue とその上流バックリンク、起票直後の `epic:bundle` が `create_epic` と答えたときの epic — これらは 1 回の起票行為であり、途中で上限に当たって半分だけ作るのが最悪の結果になる。**ひとまとまりの先頭で 1 回だけ判定し、通ったらまとまり全体を作り切る。**
+
+### 裁量起票 — 上限が効く側
+
+レビュー上限の branch 2 と、思いついた改善や気付きの記録。**起票しなくても現在の実行が完了するもの**が該当する。
+
+1. **まず 1 件閉じる。** 閉じてよいのは、実際に終わっているもの・重複・別の Issue に取って代わられたもの・もう要らないと判断できるものだけである。クローズコメントにどれに当たるかを 1 行書く。
+2. **正直に閉じられるものが無いなら、起票しない。** 場所を空けるために、まだ意味のある Issue を閉じてはならない。それは上限を満たしたことにはならず、記録を壊すだけである。
+3. **起票しない場合、その指摘は起票以外の出口を取る。** レビュー指摘なら branch 3（PR 本文に 1 行残して落とす）である。**これは既定の出口であり、上限に阻まれたときの代替ではない。**
+
+### 実行が詰まる起票 — 上限が効かない側
+
+前提 Issue（`SKILL.md` → §2d）、別パッケージ起因の割り込み Issue、ユーザーが `new` と打った入口、`issue:scout` が重複無しと答えた新規作業、**そして分割判定が作る子 Issue と epic**。**これらは起票しないと実行が進まない。**
+
+- **上限を理由に止めない。** 止めれば、製造を減らす規則が実行を止めることになり、Issue が言うとおり「今より悪い状態」になる。
+- **分割の子がここに入る理由**: 分割を検出した `fullrun` / `halfrun` は「子と epic を起票して **STOP**」と定められている（`fullrun.md` / `halfrun.md`）。起票を止めて 1 Issue のまま実装へ進むのは、その停止規則を破って 1 Issue 分の承認を N 件分に広げることであり、上限が防ぐはずだったものより重い。**分割するかどうかを決めるのは分割判定の側**で、既定はもう「分割しない」に上がっている — 上限が二重に効く必要はない。
+- **超過した事実は完了報告に 1 行書く**（例: 「オープン 34 件で起票した」）。上限は可視化のための装置なので、超えたことが見えていれば役割は果たしている。
+
+### 割り込み起票 — 上限が効かない側（3 条件で機械的に決める）
+
+**重大な欠陥の発見は、それが現在のランを止めていなくても捨ててはならない。** joshuafolkken/kit#1517 は並列実行を成立させない欠陥だったが、発見した実行単位のランをその瞬間ブロックしてはいなかったため裁量側に落ち、**別 Issue のコメント本文の中にだけ**残った。利用者が偶然そのコメントを読まなければ失われていた。上限の目的は増加を見えるようにすることであって、**発見を捨てることではない**（上の「なぜ上限が要るのか」）。
+
+**別パッケージ起因の割り込みとは別の区分である。** あちらは上流リポジトリへ起票して停止する手順（`upstream-interrupt.md`、`route:tier-a`）で、実行が詰まる側に属する。ここで言う割り込みは、**このリポジトリの欠陥で、発見したランをブロックしていないもの**を指す。両者を同じものとして読んだことが joshuafolkken/kit#1517 を落とした経路そのものである。
+
+#### 3 条件 — 該当するかは判断ではない
+
+**次の 3 つのいずれかを満たすかどうかだけで決める。**
+
+1. **検証が誤った答えを返す** — 緑であってはならないものが緑になる、または無実の変更が赤にされる
+2. **文書化された作業手順が完了できなくなる** — 並列レーン、`josh propagate` など、ドキュメントに書かれた手順が現状のコードでは通らない
+3. **データが失われる、またはリポジトリの外に書き込む**
+
+**3 つのいずれにも当たらない発見は、従来どおり裁量側の出口を取る。** 改善案、設計上の好み、未検証の疑い、「あとで直したい」はここに入らない — レビュー指摘なら branch 3（PR 本文に 1 行残して落とす）であり、それは既定の出口であって上限に阻まれたときの代替ではない。
+
+**深刻さの自己申告は条件ではない。** 「重大だと思う」を条件に加えた瞬間、割り込みは誰でも通れる抜け道になり、上限そのものが無意味になる。3 条件は、当たるか当たらないかを **他人が同じ答えに到達できる**形で書いてあり、そこが唯一の役割である。
+
+#### 該当したときの手順
+
+1. **上限に関係なく起票する。** 1 件閉じることを条件にしない。
+
+   ```bash
+   gh api repos/{owner}/{repo}/issues -f title="<title>" -f 'labels[]=route:interrupt' -f 'labels[]=depth:<n>' -f body="<body>"
+   ```
+
+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）ので、**順序は実行側が持つ** — 次に取り上げるのは実行側の選択であって、宣言された関係ではない（位置無し追加が依存を作らなくなったのは joshuafolkken/kit#1253 であり、`--after` の継ぎ足しなど残りの経路は joshuafolkken/kit#1080 で**まだ開いている** — 塞がった側を自分から迂回して、開いている側と同じ欠陥をここで作り直さないため）。**先に提示させたいときは `--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 回の行為である。上の「ひとまとまりで判定する」がここにも効く。
+
+#### 実行のしかた — 検証経路そのものの欠陥は単独で走らせる
+
+**割り込みの対象が検証経路そのものの欠陥であるとき、その Issue は単独で実行し、バッチを再開するのはそれが `main` へマージされてからとする。** 「着地」はマージであって、PR を開いた時点でもレビューが収束した時点でもない — 壊れた検証の上でバッチを回せないというのがこの節の前提なので、**修正が効き始めるのはマージの瞬間**だからである。
+
+**該当するかは判断ではなく、影響先の列挙で決まる。** 欠陥が次のいずれかに影響するか:
+
+- **検証ゲート**（lint / 型チェック / スペルチェック / 単体テスト）
+- **コードレビュー**
+- **push 時のフック**
+- **マージ時のチェック**
+
+**いずれかに当たれば単独実行。** 当たらなければ（機能追加、文書修正など）並列バッチの一員として走らせてよい。**「重大だと感じるか」は判定条件ではない** — 3 条件と同じ理由で、深刻さの自己申告を条件に加えた瞬間、この区分も抜け道になる。
+
+**理由は 2 つあり、どちらか一方だけでも単独実行の根拠として十分である。**
+
+1. **壊れた検証の上でバッチを回すと、全員の結果が信用できない。** 6 レーンを並列で走らせれば、6 件分のゲートまたはレビューがまとめて無意味になる。直したあとに全部やり直すことになるので、単独実行は遅い選択ですらない。
+2. **割り込み自身の検証が、その割り込みが直そうとしている欠陥の影響下にある。** joshuafolkken/kit#1515（テストが実ネットワークを叩いていた）と joshuafolkken/kit#1517（同時実行のスイートが一時ディレクトリを共有していた）はどちらもこの自己言及の罠を抱えており、両者とも単独実行で扱った。
+
+**判定が揺れた実例がこの節の由来である。** joshuafolkken/kit#1522（レーンで走る子のレビューが、レーンではなくセッションのチェックアウトを読む）は #1515 / #1517 と同じ形なのに、起票直後は並列バッチの一員として扱われ、利用者の指摘で単独に戻された。同じ判断者が同じ週に逆の答えを出しており、**列挙が無ければ一貫しない**ことがそこで示された。しかも #1522 は嘘の赤ではなく**嘘の緑**を返す側で、より危険である。
+
+## 上限そのものを変えるとき
+
+**30 という数字は Tier C ではない** — 引き上げも引き下げも、測定を添えて提案してよい。ただし**変更は必ずこのファイルとマーカーテストの両方を同じコミットで動かす**。片方だけ動かすと、常駐側が存在しない数字を指す。
+
+**引き上げる条件は「窮屈だから」ではない。** オープン件数が 7 日移動平均で減り続けていて、なお上限が起票を止めているとき — つまり装置が目的を果たし終えたときだけである。
+
+## 3 つは一緒に動く
+
+上限は単独では効かない。**製造側を止めないまま上限だけ入れると、製造は続いたまま実行だけが止まる。** だから joshuafolkken/kit#1469 は 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 上限                                  | このファイル                                                            |

package/prompts/collaboration-workflow.md

@@ -0,0 +1,52 @@
+# Issue-Driven Collaboration Workflow
+
+<!-- cspell:words coderabbit -->
+
+このドキュメントは、Claude / Cursor / Gemini を含む複数の AI ツールで共通に使う Issue 駆動の共同作業ワークフローの**正典**である。
+
+## この索引の使い方
+
+**これは人間が読むための正典であり、実行中の参照先ではない。** 実行中の操作手順は `.claude/skills/workflow-commands/` にあり、規則そのものは `CLAUDE.md` にある。両者とこの正典は一致していなければならない。実行中にこの正典を開く必要があるのは、skill と規則の言い分が食い違ったときだけである。
+
+**話題ごとにファイルが分かれている。** 以前はこの内容が 1 本の 169KB のファイルにあり、1 つの節を確かめるだけでも全体を読む必要があった。読んだものはそのセッションの残り全ターンで積み上がった前置きとして課金され続けるため、確認 1 回の費用が会話の長さに比例して効いていた（joshuafolkken/kit#965）。**必要な 1 本だけを開くこと。この索引を入口に、下の表から選ぶ。**
+
+| 話題                                                                           | ファイル                                                                                |
+| ------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------- |
+| Overview                                                                       | [`overview.md`](./collaboration-workflow/overview.md)                                   |
+| Step 1: Issue 作成テンプレ                                                     | [`issue-template.md`](./collaboration-workflow/issue-template.md)                       |
+| 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-bundle.md`](./collaboration-workflow/epic-bundle.md)                             |
+| オープン Issue の WIP 上限（30 件）                                            | [`wip-cap.md`](./collaboration-workflow/wip-cap.md)                                     |
+| リポジトリをまたぐ EPIC                                                        | [`cross-repo-epic.md`](./collaboration-workflow/cross-repo-epic.md)                     |
+| `josh epic:audit` — 子 Issue 群を横断して矛盾を検出する                        | [`epic-audit.md`](./collaboration-workflow/epic-audit.md)                               |
+| 別パッケージ起因の問題は割り込み Issue で対応する                              | [`upstream-interrupt.md`](./collaboration-workflow/upstream-interrupt.md)               |
+| クローン禁止・単一ソース化（パッケージ境界を越えても）                         | [`no-clones.md`](./collaboration-workflow/no-clones.md)                                 |
+| 設計はエレガント・シンプルを第一目標にする（仕組みを足す前に原因を問う）       | [`simplicity-first.md`](./collaboration-workflow/simplicity-first.md)                   |
+| 相談と実行を区別する（議論中にファイルを編集しない）                           | [`consultation-vs-execution.md`](./collaboration-workflow/consultation-vs-execution.md) |
+| 配布ドキュメント・設定の変更は kit に上流化する                                | [`distributed-docs.md`](./collaboration-workflow/distributed-docs.md)                   |
+| エージェント規則の単一ソースは `CLAUDE.md`（`AGENTS.md` / `GEMINI.md` は導線） | [`single-source-rules.md`](./collaboration-workflow/single-source-rules.md)             |
+| 最新優先・fix-forward（pin-back は最終手段）                                   | [`latest-first.md`](./collaboration-workflow/latest-first.md)                           |
+| 恒久ルールは MEMORY ではなくプロンプト／ドキュメントに書く                     | [`durable-rules.md`](./collaboration-workflow/durable-rules.md)                         |
+| ファイル編集はコマンド本文に本文を載せない                                     | [`file-edits.md`](./collaboration-workflow/file-edits.md)                               |
+| 本文をシェルの二重引用符に載せない                                             | [`shell-body.md`](./collaboration-workflow/shell-body.md)                               |
+| 独立した呼び出しは同じターンに載せる                                           | [`turn-batching.md`](./collaboration-workflow/turn-batching.md)                         |
+| `gh` は REST（`gh api`）で書く — 散文の指示も含む                              | [`gh-rest.md`](./collaboration-workflow/gh-rest.md)                                     |
+| 常駐ドキュメントと skill の分担（何を常駐に残すか）                            | [`residency.md`](./collaboration-workflow/residency.md)                                 |
+| 引き金つき配送 — 規則を効く瞬間に届ける                                        | [`rule-delivery.md`](./collaboration-workflow/rule-delivery.md)                         |
+| コマンド出力が文脈へ持ち込む量の上限                                           | [`output-bounds.md`](./collaboration-workflow/output-bounds.md)                         |
+| 運用ルール                                                                     | [`operating-rules.md`](./collaboration-workflow/operating-rules.md)                     |
+
+**どの 1 本を開けばよいかを決めるのに必要なのは、この索引だけである。** バイト数はここに書かない — 手で保守した数字は本文より先に古くなり、古い数字は無いより悪い。実サイズは `ls -l prompts/collaboration-workflow/` が答える。
+
+## 参照の書き方
+
+`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`.
+```
+
+`scripts/claude/collaboration-prompt-split.test.ts` が、文書と skill が指すファイルの実在と、この索引が全ファイルを列挙していることを検査する。