@joshuafolkken/kit 1.1010.0 → 1.1050.0

package/prompts/collaboration-workflow/residency.md

@@ -1,6 +1,8 @@
 ## 常駐ドキュメントと skill の分担（何を常駐に残すか）
 
-`CLAUDE.md` は毎ターン全文が読み込まれる。したがって常駐に書ける量は有限で、`scripts/claude/workflow-skills.test.ts` の `RESIDENT_CEILING_BYTES` がその上限を固定している。**どの規則を常駐に残すかは、書き手の重要度判断ではなく 3 問の順序判定で決める。**
+**規則をどこに書くか、常駐にどこまで残すかの判定は、このファイルが単一ソースである**（joshuafolkken/kit#2891）。`CLAUDE.md` →「Collaboration Workflow」、`.claude/skills/workflow-commands/SKILL.md` → §3、[`rule-delivery.md`](./rule-delivery.md) はここを指すだけで、問いを写さない。**読むのは規則を置く・移す・引退させるターンだけ**であり、Issue を実行するターンでは一度も読まれないので、ワークフローの入口の読み取りには入れていない（joshuafolkken/kit#1797、joshuafolkken/kit#2161）。
+
+`CLAUDE.md` は毎ターン全文が読み込まれる。したがって常駐に書ける量は有限で、`scripts/claude/workflow-skills.test.ts` の `RESIDENT_CEILING_BYTES` がその上限を固定している。**どの規則をどこに置くかは、書き手の重要度判断ではなく、下の 4 つの問いを順に当てて決める。**
 
 ### 第 0 問（先に問う）
 
@@ -18,15 +20,48 @@
 
 **順序でないなら、以下の 2 問に進む。**
 
+### 第 1 問 — 引き金を名指しできるか
+
 > **その規則が効き始める瞬間を、1 件のツール呼び出しとして名指しできるか。**
 
-**名指しできる規則は、規則本文を常駐から出す**（joshuafolkken/kit#1524）。`prompts/collaboration-workflow/rule-delivery.md` の列挙表に 1 行加え、フックがその呼び出しを拒否して規則本文を突きつける — 常駐の散文より安く、かつ**拒否は読み飛ばせない**。ただし**フックが届くのは Claude Code だけ**なので、常駐側にはトリガと判断基準の 1 行が残る（[`rule-delivery.md`](./rule-delivery.md) →「常駐側に残すのはトリガと判断基準の 1 行」）。名指しできない規則は、次の問いに進む。
+**名指しできる規則は、規則本文を常駐から出す**（joshuafolkken/kit#1524）。[`rule-delivery.md`](./rule-delivery.md) の列挙表に 1 行加え、フックがその呼び出しを拒否して規則本文を突きつける — 常駐の散文より安く（それ以外のターンでは何も払わない）、かつ**拒否は読み飛ばせない**。**移設は削除ではない** — 規則本文は消えず、より強い経路に移る。
+
+**常駐側にはトリガと判断基準の 1 行を残す。配送経路は 1 つの harness にしか届かないからである。** フックが届くのは Claude Code だけである。`CLAUDE.md` は特定のエージェントに依存しない前提で書かれており（`AGENTS.md` / `GEMINI.md` / `.cursorrules` はいずれもそこへの導線である）、Codex や Gemini CLI、Cursor のセッションは `.claude/settings.json` のフックを 1 つも走らせない。停止スイッチを立てた Claude Code も同じである。**規則の行を丸ごと消すと、それらのセッションではその規則がどこにも存在しなくなる。** したがって移設で常駐から出るのは**規則本文**であって行そのものではなく、実測値・却下した機構案・手順は配送側と話題ファイルへ移り、1 行だけが残る。**得るのは本文であって行ではない。** 常駐から完全に外してよいのは、その規則に従う主体が常にこの harness だと言える場合に限られる。
+
+**第 1 問が先に来るのは、届ける手段が増えたからである。** 旧来この一覧は第 2 問だけで決まっていたが、それは「規則を届ける手段が常駐しかない」時代の基準だった。`PreToolUse` / `PostToolUse` / `UserPromptSubmit` が稼働している以上その前提は成立せず、joshuafolkken/kit#1344 と joshuafolkken/kit#1460 は**常駐していながら一度も発火していなかった規則が実在した**ことを計測で示している。
+
+名指しできない規則は、次の問いに進む。
+
+### 第 2 問 — skill なしのターンでも効く必要があるか
 
 > **その規則は、skill がロードされていないターンでも効く必要があるか。**
 
-答えが yes の規則だけが常駐に残り、それ以外は skill へ置いて常駐からは導線だけを張る。判定の入力は「その規則が最初に効き始めるのはコマンド開始の前か後か」の 1 点だけであり、規則の重要さは入力に含まれない。
+**`CLAUDE.md` に残るのは、skill がロードされていないターンでも効く必要がある規則だけである。** 判定の入力は「その規則が最初に効き始めるのはコマンド開始の前か後か」の 1 点だけであり、規則の重要さは入力に含まれない。ランが skill を読んだ**後に**だけ到達する規則は、`CLAUDE.md` から導線を張り、そこで再掲しない。この判定が対象とするのは `CLAUDE.md` だけである — `AGENTS.md` と `GEMINI.md` は規則を持たず、`CLAUDE.md` への導線である。
+
+### 常駐規則をどこまで常駐させるか — トリガと導線
+
+上の問いは規則を常駐に**残すかどうか**を決めるが、**どこまで残すか**は決めない。長いあいだ何もそれを決めておらず、通った規則は手順を丸ごと連れて入ってきた。その結果、手順を既に移し終えた後でも `CLAUDE.md` は上限まで 585 バイトのところまで膨らみ直した（joshuafolkken/kit#964）。
+
+**常駐規則は、トリガと導線の 2 つで書く。** 3 つ目は置かない。
 
-**第 1 問が先に来るのは、届ける手段が増えたからである。** 旧来この一覧は第 2 問だけで決まっていたが、それは「規則を届ける手段が常駐しかない」時代の基準だった。`PreToolUse` / `PostToolUse` / `UserPromptSubmit` が稼働している以上その前提は成立せず、joshuafolkken/kit#1344 と joshuafolkken/kit#1460 は**常駐していながら一度も発火していなかった規則が実在した**ことを計測で示している。**移設は削除ではない** — 規則本文は消えず、より強い経路に移る。
+1. **トリガ** — 規則が効く状況と、ほかを何も読む前に従うべき 1 つの指示。そこから先を何も読まないエージェントでも、止まる・起票する・拒否する・尋ねるといった安全な振る舞いができるように書く。
+2. **導線** — 手順を持つ `prompts/collaboration-workflow/` の話題ファイルか skill のファイル。探さずに開けるだけ正確に名指す。
+
+それ以外 — 手順、作例、根拠、規則が書かれるきっかけになった失敗 — は導線の先に置く。**判定は、導線を一度も開かないターンでも常駐の記述だけで正しく振る舞えるかである。** ある文を落とすとエージェントが誤って進みうるなら、その文はトリガの一部である。落としても情報が減るだけなら、導線の先に置く。
+
+**削ることは移すことであり、削除は理由を示して初めて許される例外である。** 文が `CLAUDE.md` から出る前に、その文は導線の先に存在していなければならず、それを固定していたマーカーテストは捨てずに導線の先へ付け替える。正典の節が常駐の写しより薄いのは普通のことであって削除の理由にはならない — そのときは常駐側が詳しい版なので、先に正典へ移してから常駐から切る。
+
+**移すことしかできない仕組みはいずれ詰まるので、出口を 1 つだけ設ける。ただし狭い**（joshuafolkken/kit#1525）。規則を移すのではなく**引退**させてよいのは、消してもどのエージェントの振る舞いも変わりえないときだけであり、それは主張ではなく次の 3 条件で示す。
+
+1. **単一ソースが宣言された文の写しである。** 単一ソースが同じ文書の中で名指されている。2 つが食い違えば誤っているのは写しの側なので、写しに正しく依存できるものは無い。
+2. **ほかのどこにも無い文を 1 つも運んでいない。** 記憶ではなく、写し元の単一ソースと突き合わせて確かめる。
+3. **マーカーテストが固定していない。** 引退と一緒に落ちるアサーションが無い。
+
+**「重複に見える」は 3 条件のどれも満たさない。発火テスト・マーカー・測定された効果を持つ規則は、そもそも候補ではない。** これらの文書の規則はどれも、特定の失敗の後に書かれている。今日何も変えていない規則は、**そこにあるから**失敗が再発していないだけかもしれない。3 条件がそろわなければ、その発見は証拠つきの候補として記録し、規則は残す — 載せた候補は何も払わず後で拾えるが、誤って消した規則は何か月も後に、誰も見ていないランで黙って失敗する。**引退できるものが無かった回は、候補と証拠を記録してそこで止める** — 削除が出てくるまで基準を下げることはしない。
+
+**`rule:value` は測定であって、削減の門番ではない**（joshuafolkken/kit#1931 → `## Decisions`）。低い単独遵守率は常駐の写しが働いている証拠になるが、何も引退させなかった読み取りが文書を凍結することはない。単一ソースの導線先に本文が重複している常駐の写しは、読み取りの許可を待たずに上の「削ることは移すこと」に従ってトリガまで削る。比較の値が `-` の規則は遵守テストを宣言していないのであって、0 ではなく**未測定**であり、それだけで候補にはならない。門番として使っていた時期の経緯と各回の読み取りは `docs/maintainers/residency-rationale.md` → "The reduction freeze and its retraction"、`docs/maintainers/residency-rationale.md` → "Measurement decides what leaves"、`docs/maintainers/residency-rationale.md` → "The `rule:value` readings" にある。
+
+### 常駐規則の一覧
 
 **この一覧の対象範囲は、オンデマンド側に対応する手順を持つ常駐規則である** — skill であれ、オンデマンドで読むプロンプトであれ、常駐の記述が導線を張っている先を持つもの。判定基準が問うているのはまさにその規則群であり、いずれも「移せたはずだが、名前を挙げるに足る理由で残った」ものである。この範囲の中では網羅的であり、対応する手順を持つ規則がここに載らずに常駐へ入っていれば、判定基準に照らされていない。
 
@@ -34,21 +69,22 @@
 
 **範囲の外にある常駐規則はこの一覧に載らないのが正常である。** 命名規約、品質上限、Code Change Rules、Package-First などには移す先が存在せず、判定基準が問う「skill がロードされていないターンでも効くか」という問い自体が成り立たない。一覧に無いことは欠落ではない（joshuafolkken/kit#955）。
 
-範囲の中で常駐に残る規則は次で全部であり、いずれも `CLAUDE.md` に残っていることをマーカーテストが表明している（大半は `scripts/claude/workflow-skills.test.ts`、UI 検証ゲートは `scripts/claude/verify-ui-skill.test.ts`、後追い起票は `scripts/document/document-markers.test.ts`、ファイル編集の禁止は `scripts/document/document-markers.test.ts`）。**引き金つき配送へ移した規則は、常駐にあることではなく発火することで固定される** — ターン内バッチングは `scripts/rules/turn-batching-rule.test.ts`、WIP 上限は `scripts/backlog/backlog-manufacturing-rule.test.ts`、機構そのものは `scripts/rules/delivered-rules.test.ts` である。
+範囲の中で常駐に残る規則は次で全部であり、いずれも `CLAUDE.md` に残っていることをマーカーテストが表明している（大半は `scripts/claude/workflow-skills.test.ts`、UI 検証ゲートは `scripts/claude/verify-ui-skill.test.ts`、後追い起票とファイル編集の禁止は `scripts/document/document-markers.test.ts`）。**引き金つき配送へ移した規則は、常駐にあることではなく発火することで固定される** — ターン内バッチングは `scripts/rules/turn-batching-rule.test.ts`、WIP 上限は `scripts/backlog/backlog-manufacturing-rule.test.ts`、機構そのものは `scripts/rules/delivered-rules.test.ts` であり、常駐していると表明されるのはトリガの 1 行だけである。
 
 - **明示起動の必須**（「指示されていない行動は取らない」）— そもそもワークフローを開始してよいかを決める規則なので、ユーザーがキーワードを打った瞬間、つまり skill を読むより前に効く必要がある
 - **停止時の `confirmation` 通知** — これを要する停止の大半（別パッケージ起因の割り込み、Tier C の確認）は、ワークフローのキーワードが一度も打たれていないターンで起きる
 - **`overrides` の保護**と **`devEngines` の保護** — 依存更新コマンドはどのターンでも走りうる。`dependency-update` skill をロードしないターンでも走り、skill を読む頃には pin は既に書き換わっている
 - **UI 検証ゲート** — 画面に出る変更は、実際にレンダリング結果を見るまで完了ではない。撮影の手順は `verify-ui` にある。このゲートが効くのは UI 変更の完了を報告する瞬間であり、ワークフローのキーワードが打たれておらず skill が何もロードされていないターンであることが多い
-- **レビュー上限後の後追い起票の手順** — 起票して `epic:bundle` で EPIC へ繋ぎ直すところまで。コミット前セルフレビューはワークフローの外でも回るので、そこで起票された Issue も同じように孤児になる。完全な手順は `prompts/review.md` →「Review round cap」にある
-- **`josh epic:*` のうちコマンドの外側で効く 3 件** — 決定の記録による `needs-decision` の解除、`epic:audit` の指摘を直すのが Tier A であること、別リポジトリの EPIC を `owner/repo#N` で参照すること。いずれも `epic:*` コマンドを走らせていないターン（Issue を起票した直後、決定を書いた瞬間）に効く
-- **編集後の本文をコマンドに載せない禁止** — ファイル編集はどのターンでも起き、**編集の直前にロードされる skill は存在しない**。オンデマンド側に置くとこの規則は一度も発火せず、書いたのに削除したのと同じ振る舞いになる。実測値・可否表・根拠は [`file-edits.md`](./file-edits.md) にあり、常駐に残すのは指示と判断基準（「本文を丸ごと運ぶか」であってツール名ではない）だけである（joshuafolkken/kit#1150）。**Edit 自体を全文へ広げる形も同じ規則の一部である** — 数行の指摘に対する全文書き直しは、ツールを替えただけで同じコストを払っている。常駐にはその禁止の一句だけを置き、全文を書いてよい 3 条件は同じ指し先にある（joshuafolkken/kit#1260）
+- **レビュー上限後の後追い起票の手順** — 起票して `epic:bundle` で EPIC へ繋ぎ直すところまで。コミット前セルフレビューはワークフローの外でも回るので、そこで起票された Issue も同じように孤児になる。完全な手順は `prompts/review.md` →「Review round cap」にある（joshuafolkken/kit#946）
+- **`josh epic:*` のうちコマンドの外側で効く 3 件** — 決定の記録による `needs-decision` の解除、`epic:audit` の指摘を直すのが Tier A であること、別リポジトリの EPIC を `owner/repo#N` で参照すること。いずれも `epic:*` コマンドを走らせていないターン（Issue を起票した直後、決定を書いた瞬間）に効く。コマンド自身の手順は `.claude/skills/epic-commands/` にある
+- **編集後の本文をコマンドに載せない禁止** — ファイル編集はどのターンでも起き、**編集の直前にロードされる skill は存在しない**。オンデマンド側に置くとこの規則は一度も発火せず、書いたのに削除したのと同じ振る舞いになる。可否表は [`file-edits.md`](./file-edits.md)、実測値と根拠は [`docs/maintainers/file-edits-rationale.md`](../../docs/maintainers/file-edits-rationale.md) にあり、常駐に残すのは指示と判断基準（「本文を丸ごと運ぶか」であってツール名ではない）だけである（joshuafolkken/kit#1150）。**Edit 自体を全文へ広げる形も同じ規則の一部である** — 数行の指摘に対する全文書き直しは、ツールを替えただけで同じコストを払っている。常駐にはその禁止の一句だけを置き、全文を書いてよい 3 条件は同じ指し先にある（joshuafolkken/kit#1260）
 
-**第 1 問で「名指しできる」となり、引き金つき配送へ移したもの**（joshuafolkken/kit#1524）。いずれも本文は消えておらず、規則が効く瞬間にフックが突きつける。列挙表と、引き金が発火しないターンの意味は [`rule-delivery.md`](./rule-delivery.md) にある。
+**第 1 問で「名指しできる」となり、引き金つき配送へ移したもの**（joshuafolkken/kit#1524）。いずれも本文は消えておらず、規則が効く瞬間にフックが突きつける。下は常駐に 1 行を残した、またはその判断に理由が要った行だけであり、配送されている規則の全体ではない。**列挙表と、引き金が発火しないターンの意味の単一ソースは [`rule-delivery.md`](./rule-delivery.md) であり、ここには行数を写さない** — 2 か所に置いた数は必ずずれる（joshuafolkken/kit#1525）。
 
-- **独立した呼び出しを同じターンに載せる規則** — 引き金は `pnpm josh batch:guard`（単発呼び出しのターンが 3 つ続いた次の `Bash`）。常駐していた間の実測が示したのは、**常駐は効いていなかった**という事実である（数値は指し先）。実測値・却下した機構案・ゲートを弱めない条件は [`turn-batching.md`](./turn-batching.md) にある（joshuafolkken/kit#1304、#1390、#1524）
-- **バックログの WIP 上限（オープン 30 件）** — 引き金は `pnpm josh rule:guard`（Issue を作成する `Bash`）。配送文が件数の数え方・起票しない判断・2 つの免除・**割り込みの 3 条件**をそのまま運ぶ。3 条件を落とすと「重大かどうか」が判断に戻るため、配送文からも削っていない（joshuafolkken/kit#1518）。手順と数字を動かす条件は [`wip-cap.md`](./wip-cap.md) にある（joshuafolkken/kit#1469、#1524）
-- **本文をシェルの二重引用符に載せない** — 引き金は `pnpm josh rule:guard`（本文値にバッククォートか `$` を含む `Bash`）。**常駐側に 1 行が残っているのは、ここが「削除してよい」側ではないからである** — 配送は Claude Code にしか届かず、正規表現が知っている綴り（`-f body=` ／ `--body` ／ `--notify-message`）だけが規則の適用範囲になってはならない。実測・安全な綴り・引き金の死角は [`shell-body.md`](./shell-body.md) にある（joshuafolkken/kit#1198）
+- **独立した呼び出しを同じターンに載せる規則** — 引き金は `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）
+- **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）
 
 no になり skill 側に本体を置くものの例:
 
@@ -56,6 +92,7 @@ no になり skill 側に本体を置くものの例:
 - 実行中に前提 Issue が判明した場合の入口別手順（`fullrun.md` / `halfrun.md` / `.claude/skills/workflow-commands/backlogrun.md`）
 - `backlogrun` の単独 Issue 受理と park-and-continue（`.claude/skills/workflow-commands/backlogrun.md`）
 - 検証ゲートとマージ連鎖（`.claude/skills/workflow-commands/chain-rule.md` / `followup.md`）
+- 依存更新後の検証手順（`.claude/skills/dependency-update/`）— 上の 2 つの保護が導線を張る先
 - `auto-ok` の拾い上げと「ラベルを付けるのは人だけ」（`.claude/skills/workflow-commands/backlogrun.md`）。書き込みの禁止は普通なら常駐側に来るが、`auto-ok` はそれを禁じているドキュメント以外のどこにも存在しないため、それらを開かないターンではそもそも到達しない
 
 ### 指し先になった話題ファイルは引用しない
@@ -74,7 +111,9 @@ no になり skill 側に本体を置くものの例:
 
 `scripts/rules/pointer-citation-document-rule.test.ts` がこれを固定する。**縮小した話題ファイルは冒頭に「この規則の単一ソースは …」の宣言文を置くこと** — 検査はこの宣言文で指し先を機械的に検出し、そこに書かれた skill が実在すること、および他の文書がその話題ファイルを引用していないことを確かめる。宣言文が入口なので、横展開で新しく縮小された話題も、この規則の対象へ自動で入る。
 
-**この基準は努力目標ではない。** 常駐に手順を書き戻すと、その分の予算を次に本当に常駐が要る規則が既存の文章から取り返すことになる。上限に張り付いた状態で 1 文を足すために別の文を削ると、**削る対象はマーカーで固定されていなかった箇所から選ばれる** — 規則の重要度ではなく、テストに拾われていなかったかどうかで残る文が決まる（joshuafolkken/kit#951）。上限そのものを引き上げる対処は、上限が防いでいる状態の追認にあたるので採らない。
+### 常駐予算
+
+**この基準は努力目標ではない。** `scripts/claude/workflow-skills.test.ts` は常駐文書ごとに `RESIDENT_CEILING_BYTES` の上限とその下の余白を要求する。常駐に手順を書き戻すと、その分の予算を次に本当に常駐が要る規則が既存の文章から取り返すことになる。上限に張り付いた状態で 1 文を足すために別の文を削ると、**削る対象はマーカーで固定されていなかった箇所から選ばれる** — 規則の重要度ではなく、テストに拾われていなかったかどうかで残る文が決まる（joshuafolkken/kit#951）。予算が詰まったときに何を出すかは、マーカーの有無ではなく測定で決める（`rule:value`、上の「トリガと導線」の節）。上限そのものを引き上げる対処は、上限が防いでいる状態の追認にあたるので採らない。
 
 ### 上限を引き上げてよい条件（反証条件）
 
@@ -90,5 +129,6 @@ no になり skill 側に本体を置くものの例:
 
 **引き上げは Tier C として扱う。** `scripts/claude/workflow-skills.test.ts` で常駐予算を決めている定数——`RESIDENT_CEILING_BYTES`、`RESIDENT_HEADROOM_BYTES`、および書き戻しを検知する下限 `RE_INLINE_GUARD_HEADROOM_BYTES`——の**緩和**は、上の 3 条件を示した上でユーザーの明示指示を得てから行う。条件が揃っていること自体は、変更してよいという指示ではない。**どれか 1 つだけを名指しすると、そのとき実際に効いている限界が対象外になる** — 上限に余裕があっても下限に張り付いていれば、緩めたくなるのは下限のほうであり、そこが素通しなら禁止は形だけになる。締める向きの変更（上限を下げる、下限を上げる）はこの禁止の対象外である。
 
-- このルールは横断ドキュメント（CLAUDE.md「Shorthand Commands」）および `.claude/skills/workflow-commands/SKILL.md`「What stays resident, and what is read from here」のカノニカル参照
-- **常駐ルールを「どこまで常駐させるか」の本体は `.claude/skills/workflow-commands/rule-residency.md` にある**（joshuafolkken/kit#1797）。常駐可否を決める 2 つの問いは `SKILL.md` §3 に残り、トリガ＋ポインタの形・常駐ルールの列挙・引退経路とその 3 条件・`rule:value` の測定結果はそちらへ移した。**発火するのはこれらの文書を編集するターンだけで、Issue を実行するターンでは一度も読まれない**ので、ワークフローの起動読み取りから外してある
+### 経緯
+
+この基準の適用の記録は保守者向けの文書に移してあり、規則は持たない。配送済み規則の一覧から件数を外した経緯は `docs/maintainers/residency-rationale.md` → "Why the delivered list carries no count"、二重の一覧を 1 つにした経緯は `docs/maintainers/residency-rationale.md` → "One list, not two" にある。

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

@@ -4,39 +4,18 @@
 
 ## なぜ配送が要るのか
 
-`CLAUDE.md` は実効上限まで残り数トークンまで詰まっていた（joshuafolkken/kit#1524 起票時点で 6 トークン ≒ 15〜18 文字）。一方で `prompts/` と `.claude/skills/` は常駐部の 15 倍を抱えており、**詰まっているのは常駐という 1 本の経路だけ**である。
-
-そして配送は安いだけでなく**強い**。
-
-|            | 常駐の散文       | 引き金つき配送           |
-| ---------- | ---------------- | ------------------------ |
-| コスト     | 毎ターン         | 該当する瞬間だけ         |
-| 読まれるか | 読み飛ばされうる | **拒否は読み飛ばせない** |
-| 発火の検証 | できない         | 単体テストで固定できる   |
-| 総量の上限 | 実効上限で頭打ち | 実質なし                 |
-
-**これは推測ではなく計測済みである。** joshuafolkken/kit#1344 はバッチングの指示について、散文でも実行時の注意書きでも数値がまったく動かなかったランを 3 回連続で記録した。`PreToolUse` フックにして初めて動いた。調査ガード（joshuafolkken/kit#1460）も同じ経緯である。**常駐していながら一度も発火していなかった規則が実在した**ということであり、移設で失われるものは「効いていなかった散文」だけである。
+常駐の経路は実効上限で詰まっており、配送は該当する瞬間だけのコストで届き、拒否は読み飛ばせず、発火を単体テストで固定できる。経緯: `docs/maintainers/rule-delivery-rationale.md` →「なぜ配送が要るのか」。
 
 ## 判定基準 — 引き金を特定できるか
 
-> **その規則が効き始める瞬間を、1 件のツール呼び出しとして名指しできるか。**
-
-名指しできる規則は、**規則本文を常駐から出す**。列挙表に 1 行加え、フックが効く瞬間に配送する。名指しできない規則 — 振る舞いの原則、報告の書き方、判断の階層 — は、これまでどおり第 2 問（「skill がロードされていないターンでも効く必要があるか」）で決める。旧基準だけで決めていたのは、**届ける手段が常駐しかなかった時代のもの**であり、`PreToolUse` / `PostToolUse` / `UserPromptSubmit` の 3 点が稼働している以上その前提は成立していない。
-
-### 常駐側に残すのはトリガと判断基準の 1 行 — 配送経路は 1 つの harness にしか届かない
-
-**フックが届くのは Claude Code だけである。** `CLAUDE.md` は特定のエージェントに依存しない前提で書かれており（`AGENTS.md` / `GEMINI.md` / `.cursorrules` はいずれもそこへの導線である）、Codex や Gemini CLI、Cursor のセッションは `.claude/settings.json` のフックを 1 つも走らせない。停止スイッチを立てた Claude Code も同じである。**規則の行を丸ごと消すと、それらのセッションではその規則がどこにも存在しなくなる** — 本 Issue 自身が禁じている「削除」そのものになる。
-
-したがって移設で常駐から出るのは**規則本文**であって、行そのものではない。常駐に残るのは residency 基準が言うところの「トリガ＋導線」— 実測値・却下した機構案・手順は配送側と話題ファイルへ移り、**1 行だけが残る**。常駐から完全に外してよいのは、その規則に従う主体が常にこの harness だと言える場合に限られる。
-
-**移設は削除ではない。** 規則本文は消えず、より強い経路に移る。したがって joshuafolkken/kit#1477（読み込む命令文のコスト測定）の答えを待つ必要はない — あちらが門番なのは**削除**の判断である。
+どの規則を配送へ移すか — 引き金を 1 件のツール呼び出しとして名指しできるか、常駐側にトリガの 1 行を残す理由、移設が削除ではないこと — の単一ソースは [`residency.md`](./residency.md) →「第 1 問」であり、ここには写さない。この文書が持つのは、移した規則を届ける機構と列挙表である。移設は削除ではないので、joshuafolkken/kit#1477（読み込む命令文のコスト測定）の答えを待つ必要はない — あちらが門番なのは**削除**の判断である。
 
 ## 機構 — 1 本だけ、新規に作らない
 
 配送はすべて `scripts/josh/hook-decision.ts` の `create_transcript_guard` の上に載る。バッチガード（joshuafolkken/kit#1390）と調査ガード（joshuafolkken/kit#1460）が既に共有している唯一の土台であり、ペイロードのスキーマ、`deny` の封筒、環境変数のスイッチ、`.env` の読み込み、ラン 1 回だけ発火させる記録の 5 つを持つ。**2 本目の配送経路を作るのは `CLAUDE.md` →「No clones」が禁じるクローン**であり、しかも 2 本が「配送したかどうか」で食い違いうる唯一の場所である。
 
 - **列挙表**: `scripts/rules/delivered-rules.ts`。1 規則 = 1 行（`id` ／ 引き金 ／ 配送文）。
-- **入口**: `scripts/hooks/pretool-guard.ts` ＝ `pnpm josh pretool:guard`。3 つの `PreToolUse` ガード（バッチング ／ 調査 ／ 規則）を 1 プロセスにまとめ、`.claude/settings.json` の `PreToolUse` に**単一エントリ**として `Bash|Edit|Read|Write` のマッチャで配線されている。拒否の優先順位はバッチングの理由が先、次に調査、最後に規則であり、各ガードは内部で従来どおり自分の環境変数スイッチを尊重する。
+- **入口**: `scripts/hooks/pretool-guard-cli.ts`（ガードの合成は `scripts/hooks/pretool-guard.ts`）＝ `pnpm josh pretool:guard`。3 つの `PreToolUse` ガード（バッチング ／ 調査 ／ 規則）を 1 プロセスにまとめ、`.claude/settings.json` の `PreToolUse` に**単一エントリ**として `Bash|Edit|Read|Write` のマッチャで配線されている。拒否の優先順位はバッチングの理由が先、次に調査、最後に規則であり、各ガードは内部で従来どおり自分の環境変数スイッチを尊重する。
 - **停止スイッチ**: `JOSH_RULE_GUARD`（規則ガードのぶん。既定で有効。`off` / `0` / `false` / `no` で無効）。バッチング・調査の各ガードも同じく自前のスイッチを持つ。
 
 **規則ガードの列挙表に載るのは、効く瞬間がシェル呼び出しである規則に限られる。** Claude Code は 1 ターンのうち 1 件だけを拒否して残りを実行するため、拒否された `Edit` は兄弟の編集だけが適用された状態を残す（joshuafolkken/kit#1390）。単一の `pretool:guard` プロセスは `Bash|Edit|Read|Write` を受け取るが、規則ガードが拒否理由を返すのはシェル呼び出しに限られる。
@@ -132,28 +111,8 @@ WIP 上限の引き金は Issue の**作成**だけを見る。`…/issues/<N>/c
 
 ## 本文のシェル評価は同じ機構の 1 行で覆った（joshuafolkken/kit#1198）
 
-コメント本文をシェルに載せるとバッククォートがコマンドとして実行される問題は、**この機構の追加 1 行で覆った**。起票時の見込みどおり新しい機構は要らず、`delivered-rules.ts` の `shell-body` 行と、その発火・非発火を固定するテストで足りている（実装先として書いていた joshuafolkken/kit#1542 は #1198 の重複として閉じられたため、実装は #1198 側で行った）。
-
-**引き金は当初の見込みより狭い。** `-f body=` ／ `--body "` というフラグで引くのではなく、**二重引用符の本文値に `` ` `` か `$` が実際に含まれるとき**だけ発火する。本リポジトリのプロンプトにある作例はいずれもプレースホルダ（`-f body="<plan>"`）を渡しており無害なので、フラグで引くと**規則が既に守られているターンで拒否する**ことになり、この文書自身の「誤ったターンで発火するフックはフックが無いより悪い」に反する。`!`（履歴展開）も引き金に入れていない — 非対話 zsh では発火しないことを実測した。規則本文と引き金の死角は [`shell-body.md`](./shell-body.md) にある。
+`delivered-rules.ts` の `shell-body` 行は、`-f body=` ／ `--body "` というフラグで引くのではなく、**二重引用符の本文値に `` ` `` か `$` が実際に含まれるとき**だけ発火する。`!`（履歴展開）は引き金に入れない。規則本文と引き金の死角は [`shell-body.md`](./shell-body.md) にある。経緯: `docs/maintainers/rule-delivery-rationale.md` →「本文のシェル評価を同じ機構の 1 行で覆った経緯」。
 
 ## マーカーテスト
 
-- `scripts/rules/delivered-rules.test.ts` — 各エントリが引き金で**実際に発火**し、それ以外では無言であること。散文が効かなかったのがこの機構の出発点であり、**発火しない移設は移設ではない**
-- `scripts/claude/claude-settings-hooks.test.ts` — `rule:guard` が `PreToolUse` に `Bash` だけを名指しして配線され、タイムアウトを宣言し、実在する josh サブコマンドを指すこと
-- `scripts/backlog/backlog-manufacturing-rule.test.ts` — WIP 上限が `wip-cap.md` に単一ソースとして存在し、配送文が数え方・拒否・2 つの免除・免除を決める 3 条件を運ぶこと
-- `scripts/rules/turn-batching-rule.test.ts` — バッチングの配送文が判断基準を運び、参照先が `CLAUDE.md` ではなくこのディレクトリの `turn-batching.md` であること
-- `scripts/document/document-markers.test.ts` — 早すぎる進捗報告の手順が `.claude/skills/workflow-commands/backlogrun.md` の該当節に単一ソースとして存在し、この文書が行と 1 ラン 1 回の例外を書いていること。発火・非発火と「毎回発火する」ことは `scripts/rules/early-heartbeat.test.ts` が固定する
-- `scripts/rules/issue-comments-rule.test.ts` — コメント読み取りの手順が `SKILL.md` → §2g に単一ソースとして存在し、3 つの `#N` 入口がそれを**再掲せずに指す**こと（矛盾時の規則を 3 箇所に写せばクローンになる）。フックが届かないセッションでも規則が残ることを、この対で担保する
-- `scripts/rules/shell-body-rule.test.ts` — 本文のシェル評価が `shell-body.md` に単一ソースとして存在し、配送文が被害・安全な綴り・再発行の指示を運ぶこと
-- `scripts/rules/raw-field-body.test.ts` — 生フィールドの `body=@` 誤射（joshuafolkken/kit#2304）の述語と配送文の文言を固定する。実際の配送経路での発火（`-f` ／ `--raw-field body=@`）・無言（`-F` ／ `--field body=@`・`@` を含まない本文・`pnpm josh issue:comment`）と「1 コマンドを 1 行だけが主張する」ことは `scripts/rules/delivered-rules-bash.test.ts` が固定する
-- `scripts/rules/piped-verification-rule.test.ts` — 検証コマンドのパイプが `output-bounds.md` に単一ソースとして存在し、配送文が仕組み・逃げ道・境界の 3 つを運び、読み取り専用の一覧を巻き込んでいないこと
-- `scripts/rules/pre-gate-cut-rule.test.ts` — gate 手前の cut の手順が `.claude/skills/workflow-commands/pre-gate-cut.md` に単一ソースとして存在し、この文書と `docs/josh-commands.md` の双方が引き金を書いていること。発火・非発火（レーンかつ目印ありかつ未 cut でのみ拒否し、目印の無い人・レーン外・cut 済みでは無言）は `scripts/rules/pre-gate-cut.test.ts` が固定する
-- `scripts/rules/implementation-cut-rule.test.ts` — 実装フェーズの cut の手順が `.claude/skills/workflow-commands/pre-gate-cut.md` →「It is a guard, fired at the edit that crosses the threshold」に単一ソースとして存在し、配送文がその節・命令・再武装の契約（再開で記録を消して両ガードを再武装させること、joshuafolkken/kit#2310）を運ぶこと。発火・非発火（レーンの子かつ目印ありかつ未 cut かつしきい値超過の `Edit` ／ `Write` でのみ拒否し、レーン外・目印なし・非編集・cut 済み・しきい値未満では無言）は `scripts/rules/implementation-cut.test.ts` が固定する
-- `scripts/rules/delivered-rules-filing.test.ts` — 直接起票（`gh issue create`、`…/issues` への `title` 付き POST）が毎回拒否されて `pnpm josh issue:file` を案内され、`issue:file` の呼び出し自体は拒否されないこと。起票上限と畳み込みの行が `issue:file` の呼び出しで発火し、失敗した `issue:file` 呼び出しを起票に数えないことも同じスイートが固定する
-- `scripts/rules/filing-cap.test.ts` — 起票回数の計数（拒否された起票を数に入れないこと）を固定する。発火・非発火（10 件目まで無言・11 件目で拒否・毎回発火する）は `scripts/rules/delivered-rules.test.ts` が固定する
-- `scripts/rules/lane-park-rule.test.ts` — レーンの子の保留の手順が `.claude/skills/workflow-commands/pre-gate-cut.md` に単一ソースとして存在し、配送文がその節を指すこと。発火・非発火（レーンの子かつ停止通知でのみ拒否し、レーン外・目印なし・停止通知でないときは無言）は `scripts/rules/lane-park.test.ts` が固定する
-- `scripts/rules/lane-interactive-ask-rule.test.ts` — レーンの子の対話質問の手順が `.claude/skills/workflow-commands/pre-gate-cut.md` → 「The interactive ask is refused one call earlier」に単一ソースとして存在し、配送文がその節を指すこと（joshuafolkken/kit#2201）。発火・非発火（レーンの子の `AskUserQuestion` でのみ拒否し、レーン外・目印なし・対話ツールでないときは無言）と毎回発火は `scripts/rules/lane-interactive-ask.test.ts` が、終了記録からの質問・選択肢の取り出しは `scripts/agent/interactive-ask.test.ts` が固定する
-- `scripts/rules/lane-switch-main.test.ts` — レーンの子の `git switch main`（joshuafolkken/kit#2313）を、失敗する前に拒否する述語（`switch_target` ／ `is_switch_away_from_lane`）と配送文の文言を固定する。手順の単一ソースは `.claude/skills/workflow-commands/backlogrun-lanes.md` ／ `backlogrun-child.md`。発火・非発火（レーンの子が自分のレーンブランチ以外へ切り替えるときのみ拒否し、自ブランチ・作成/デタッチ・レーン外・主チェックアウトでは無言）と毎回発火、「1 コマンドを 1 行だけが主張する」ことは同スイートが固定する
-- `scripts/rules/git-argv.test.ts` ／ `scripts/rules/git-force.test.ts` ／ `scripts/rules/worktree-guard.test.ts` ／ `scripts/rules/file-body.test.ts` — Bash 文字列の 3 群（joshuafolkken/kit#2120）の述語と配送文の文言を固定する。実際の配送経路での発火・無言と「1 コマンドを 1 行だけが主張する」ことは `scripts/rules/delivered-rules-bash.test.ts` が固定する
-- `scripts/rules/rule-body-guard.test.ts` — 規則本文を散文に書き足す `Edit` ／ `Write`（joshuafolkken/kit#2272）の述語・配送文・列挙表掲載を固定する。発火（規則ドキュメントへの追記）と無言（誤字・リンク張り替え・削除・非規則ファイル・非 Edit/Write）、および実際の配送経路での「2 つのコマンドを実行するまで毎回拒否」はこの 1 スイートが固定する。配送文が第 0 問（`oracle:list`）と順序の問い（`run:step`）を運び、単一ソースが `residency.md` であることも同じスイートが押さえる
-- `scripts/rules/stop-rules-rule.test.ts` — 停止時 4 規則の単一ソース（`CLAUDE.md` の停止通知・`SKILL.md` → §2f・`SKILL.md` → §2i・`issue-citation.md`）と `rule-delivery.md` の列挙表掲載を固定する。発火・無言（押さえ×未通知でブロック／綺麗×押さえでブロック／汚れ・通知済みで無言／`stop_hook_active` で無言／起票の申し出×未起票でブロック・起票済み／第三者リポジトリ／owner 不明で無言／裸 `#N` でブロック・リンク形式やコードフェンス／インラインコード／引用行／PR 参照の中で無言）は `scripts/rules/stop-rules.test.ts`・`scripts/rules/filing-offer.test.ts`・`scripts/rules/issue-citation.test.ts` が、`Stop` フックの配線は `scripts/claude/claude-settings-hooks.test.ts` が固定する
+各テストファイルが何を固定するかの一覧: `docs/maintainers/rule-delivery-rationale.md` →「マーカーテスト」。列挙表の行を固定するスイートには `scripts/rules/turn-batching-rule.test.ts` ／ `scripts/rules/shell-body-rule.test.ts` ／ `scripts/rules/piped-verification-rule.test.ts` ／ `scripts/rules/pre-gate-cut.test.ts` ／ `scripts/rules/implementation-cut-rule.test.ts` ／ `scripts/rules/implementation-cut.test.ts` ／ `scripts/rules/lane-park.test.ts` ／ `scripts/rules/lane-interactive-ask.test.ts` ／ `scripts/rules/rule-body-guard.test.ts` がある。

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

@@ -10,9 +10,7 @@
 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）。**被害の重さが違うだけで、原因は同一である。**
+zsh は `pnpm josh ms` を実行し、その標準出力を本文に埋め込む。`pnpm josh followup --notify-message "…"` の本文も同じ根で壊れる。事故の経緯は `docs/maintainers/shell-body-rationale.md` →「事故の経緯 — 二つの被害、一つの原因」。
 
 - **通知経路**: 置換結果が本文に混ざる。壊れ方が静かで、`followup` は正常終了する
 - **`gh` 経路**: 置換された結果が捨てられるのではなく、**コマンドとして実行される**
@@ -28,7 +26,7 @@ zsh は `pnpm josh ms` を実行し、その標準出力を本文に埋め込む
 | `!`             | 発火しない（履歴展開は非対話では無効）               |
 | `\$` / `` \` `` | 発火しない（直前のバックスラッシュがリテラル化する） |
 
-joshuafolkken/kit#1198 のコメントは `!` も発火すると書いていたが、**この環境では発火しない**。引き金にも入れていない — 「!」を含む本文は日常的であり、そこで拒否するフックは[「誤ったターンで発火するフック」](./rule-delivery.md)そのものになる。
+`!` は引き金に入れていない。理由は `docs/maintainers/shell-body-rationale.md` →「`!` を引き金に入れない理由」。
 
 ### 安全な書き方
 
@@ -41,7 +39,7 @@ 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`）。
+**PR コメントも同じ経路である** — REST では pull request のコメントは issue のコメントであり、`pnpm josh issue:comment <N> --body-file <path>` がそのまま使える。`gh issue comment` / `gh pr comment` は使わない（GraphQL 経由。理由は `docs/maintainers/shell-body-rationale.md` →「`gh` サブコマンドを実行可能ブロックに書かない理由」）。
 
 ### コメント投稿は `pnpm josh issue:comment` の 1 綴りだけ（joshuafolkken/kit#2304）
 
@@ -50,19 +48,19 @@ pnpm josh notify --task-type confirmation --issue-url "<url>" --body-file <path>
 - `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 件がこれで失われた）。
+`-f` と `-F` は 1 文字違いで、どちらでも `gh` は終了コード 0 でコメント URL を返す。**壊れたことが分かるのは後で人が Issue を見たときだけ**である（`docs/maintainers/shell-body-rationale.md` →「`-f body=@` で失われたコメント」）。
 
 だから **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` の同時指定は拒否する** — 優先順位を決めると、ファイルを渡したつもりの呼び出しが、避けようとしていたインライン文字列をそのまま送ってしまう。
+`--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` の同時指定は拒否する**（`docs/maintainers/shell-body-rationale.md` →「`--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` にある。
+`pnpm josh rule:guard` が該当する `Bash` 呼び出しを拒否して本文を突きつける（`docs/maintainers/shell-body-rationale.md` →「引き金つき配送にした理由」）。列挙表の行は `scripts/rules/delivered-rules.ts` の `shell-body` であり、その行が読む引き金 — どの綴りが本文をインラインで運ぶか、シェルがその値に何をするか — は `scripts/rules/shell-body-trigger.ts` にある。
 
-**引き金はフラグではなく本文の中身である。** 本リポジトリのプロンプトにある作例はいずれもプレースホルダ（`-f body="<plan>"`）を渡しており、これは無害である。フラグで引くと、規則が既に守られているそれらのターンでも拒否することになる。実際にバッククォートか `$` を含む本文が二重引用符に載った瞬間だけが、テキストが実行される呼び出しである。
+**引き金はフラグではなく本文の中身である** — 二重引用符の本文値にバッククォートか `$` が実際に含まれるときだけ発火し、プレースホルダの作例（`-f body="<plan>"`）では無言である（`docs/maintainers/shell-body-rationale.md` →「引き金をフラグでなく本文で引く理由」）。
 
 ### 引き金が見えないもの
 

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

@@ -24,11 +24,11 @@
 
 **ツール自体が動いていたのは合わせて約 54 秒**である。同じ 66 往復が消費した壁時計は 66 × 9〜13 秒 ≒ 600〜850 秒で、1 桁違う。1 ターンあたりの壁時計は 9〜13 秒の狭い帯に収まるので、**ターン数がそのまま run の下限を決めている。**
 
-epic #1262 の子（#1256〜#1260）がゲートを 133 秒から中央値 5 秒まで削ったのに run 全体が 5% しか縮まなかったのは、これが理由である。削った先が壁時計を決めていなかった。
+ゲート短縮が run を縮めなかった経緯は `docs/maintainers/turn-batching-rationale.md` →「ゲートを削っても run が縮まなかった理由」。
 
 ## 判断基準は「依存の有無」であって、呼び出しの種類ではない
 
-読み取りだけの規則ではない。**`Edit` も同じ規則の対象である** — 同じファイルの離れた領域や、別々のファイルへの編集は、互いの結果を使っていないので同じターンに載る。実測で最大の単一項目が `Edit` 34 回だったのは、そこが最も守られていなかったからである。
+読み取りだけの規則ではない。**`Edit` も同じ規則の対象である** — 同じファイルの離れた領域や、別々のファイルへの編集は、互いの結果を使っていないので同じターンに載る（実測の内訳は `docs/maintainers/turn-batching-rationale.md` →「`Edit` が最大の単一項目だった理由」）。
 
 逆に、**依存があるなら分けるのが正しい。** 次はいずれも 1 つ前の結果を入力に使うので、同じターンに載せてはならない。
 
@@ -50,28 +50,20 @@ epic #1262 の子（#1256〜#1260）がゲートを 133 秒から中央値 5 秒
 
 - **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`」にある。
+  **却下したのはこの判定のしかたであって、`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）」。
 
-  **フックはフォークにも届く。** 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%）— 最大の寄与源が構造上ずっと圏外だった。
+  - **塞ぎきれないのは「いま中断しているターンの中身」であり、これは transcript から観測できないので設計上残る。** 同じファイルへの編集 3 件を 1 ターンにまとめた場合、先頭だけが拒否され残り 2 件が適用されることはある。**ただし壊れるのではなく失敗する** — 再発行された編集は書いたときの本文に一致するか、一致せずに報告されるかのどちらかである。
+  - **ファイル全体を書き出す `Write` だけは拒否しない。** 再発行された `Write` は本文を照合しないので、そのターンの兄弟が適用した編集を無言で上書きしうる。根拠は `docs/maintainers/turn-batching-rationale.md` →「中断中のターンと `Write` の除外の根拠」。
+  - **連続を切るのは「そもそもまとめられない呼び出し」、すなわち結果を次の呼び出しが必要とする委譲である。**
+  - **`pnpm josh …` は読み取り専用サブコマンドの allow-list（`READ_JOSH_SUBCOMMANDS`）に載るものだけが bundleable である。** 書き込む・外部送信するサブコマンド（`run:progress --mark` はマーカーを書き、`notify` は送信し、`main:sync` / `epic` / `run:hold` は状態を書く）は allow-list に**入れない**。連鎖した行（`&&` / `|` / `>` など）は、先頭の `pnpm` が後続の変更を隠すため読みとしては信用せず、通常判定に落とす。
+  - ツールを 1 つも呼ばないターンと、ガードが `off` のレーン子 — それぞれ下の「事後の計測」と「実装中の独立編集に効く合成コマンド」。
 
-  **却下されていたのは「マッチャだけを広げる案」であって、「書き込みを拒否可能にする案」ではない。** 判定述語が書き込みに常に `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 呼び出しにまとめるツールを前提にする。** 前提にできない。この repository が対象とする harness には常に存在するとは限らず、存在しない側では規則が一度も発火しない。`pnpm josh` はどの harness にも存在するので、書き込みは合成コマンド `pnpm josh edit:files` で畳む（下節）。経緯は `docs/maintainers/turn-batching-rationale.md` →「複数編集ツールの前提を joshuafolkken/kit#2366 が反証した経緯」。
 - **ターンごとに件数の下限を課す。** 却下。依存が連続する区間では 1 件が正しい答えであり、下限は正しい振る舞いを罰する。上限も下限も持たないのが正しく、**代わりに事後の計測を置く**（次節）。
 
-harness 側の一般的な指示（「依存のない呼び出しは同じブロックで出す」）は**すでに存在していて、実測では発火していなかった** — 4 本の run で 1 往復あたり 1.13 / 1.04 / 1.03 / 1.00 呼び出し。一般論だけでは動かないので、この文書は **判断基準を 1 問に固定し、守られていなかった具体形を名指しし、結果を数字で見えるようにする**という 3 点で置き換えている。`file-edits.md` が同じ 3 点で出力トークン側を動かしたのと同じ形である。
+harness 側の一般的な指示（「依存のない呼び出しは同じブロックで出す」）は**すでに存在していて、実測では発火していなかった** — 4 本の run で 1 往復あたり 1.13 / 1.04 / 1.03 / 1.00 呼び出し。帰結は `docs/maintainers/turn-batching-rationale.md` →「一般指示が発火しなかったことの帰結」。
 
 ## 事後の計測 — 実行タイミングレポートの `Round trips:`
 
@@ -86,26 +78,26 @@ Round trips:
 
 - **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 がツールなし**だった
+- **`tool-less turns` の行は、ツールを 1 つも呼ばなかったターン数**（`turn_count − round_trips`、joshuafolkken/kit#1875）。`batch:guard` は発話だけのターンを拒否できない — 呼ぶツールが無く `PreToolUse` が発火しないので、唯一の梃子がこの事後計測である。`Bundling:` はこれを構造上見られない（まとめる対象を持たないターンは列に入らない）。発話だけのターンは自分で減らす（実測は `docs/maintainers/turn-batching-rationale.md` →「`tool-less turns` の実測」）
 - 実装は `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 計測）で、編集集合が事前確定の定型でないため既存の合成コマンドでは畳めなかった。
+**フックが届かない一区間が残っていた — レーン子の実装中の独立編集である。** レーン子（headless `claude -p`）ではガードが `off` なので（#2178）、別々のファイルへ `Read` → `Edit` を交互に出す並びは誰にも止められない。経緯は `docs/maintainers/turn-batching-rationale.md` →「合成コマンドに至った経緯（joshuafolkken/kit#2202）」。
 
-**しかし 1 手前に確定している — Step 0 が変更ごとに対象ファイルを列挙する。** `pnpm josh read:files` はその点で読み取りを畳む合成コマンドである（密度を動かした実績があるのは合成コマンドだけ — #2165 / #2162 — で、助言・提示・通知はいずれも動かさなかった）。「もう一度言う」形ではなく、`report-format.md` が Step 0 の継ぎ目（`josh lines` の隣）でランをここへ導く**手順**である。
+**しかし 1 手前に確定している — Step 0 が変更ごとに対象ファイルを列挙する。** `pnpm josh read:files` はその点で読み取りを畳む合成コマンドである。`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`」。
+上限超過時は `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`」。
+書き込みは `pnpm josh edit:files` で畳む（joshuafolkken/kit#2366） — 編集を **プラン（`=====` のパスヘッダ＋ 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 ターンで確実に出せる単一の呼び出しである。
+ガードが**単発の読み取り連続**で発火したとき、通知はその読み取りを畳む `pnpm josh read:files <path> …` を貼り付け可能な形で手渡す — モデルが 1 ターンで確実に出せる単一の呼び出しである。経緯は `docs/maintainers/turn-batching-rationale.md` →「ガード通知に合成コマンドを載せた経緯（joshuafolkken/kit#2311）」。
 
-**読み取りに限り、2 件以上のときだけ。** 書き込みは `read:files` の対象外なので除外し、読み取り 1 件は既に単発なので畳むものがない。実装は `scripts/time-runtime/time-batch-guard.ts` の `recent_candidates`（`read_fold_directive`）で、全通知配送が通る唯一の地点である。密度が計測されるのはレーン子（`notice` モード）なので、ここに合成コマンドを差し込むのが計測面に一致する。#2202 の Step 0 継ぎ目での畳み込みを、ガードが発火する実装中の一点へ広げたものであり、「もう一度言う」形の追加ではない。
+**読み取りに限り、2 件以上のときだけ。** 書き込みは `read:files` の対象外なので除外し、読み取り 1 件は既に単発なので畳むものがない。
 
 **書き込み側も同じ地点で手渡す（joshuafolkken/kit#2366）。** 単発 `Edit` の連続でガードが発火したとき、通知はその編集を名指し、それらのファイルにわたる `pnpm josh edit:files` の畳み込みを添える（`write_fold_directive`）。読み取りはパスだけで畳めるが編集は本文を伴うので、貼り付け可能なのはコマンドとファイル名までで、プラン本体はモデルが書く — それでも並列 `tool_use` ブロックではなく 1 ターンで出せる単一呼び出しに落ちる。`Edit` だけを数え、content-address できない `Write`（既に独自の通知を持つ）は除く。
 
@@ -113,7 +105,7 @@ Round trips:
 
 **この規則は常駐から外れている。** `pnpm josh batch:guard` が、単発呼び出しのターンが 3 つ続いた次の呼び出し（`Bash` / `Edit` / `Read`）を拒否し、そこで規則本文を突きつける — 規則が効く瞬間そのものである。配送の判定基準と機構は `rule-delivery.md` にある。
 
-**移設で失われた散文は、そもそも効いていなかった。** 上の「却下した案」の直後に記録したとおり、常駐の一般指示があった状態での実測は 1 往復あたり 1.13 / 1.04 / 1.03 / 1.00 呼び出しであり、常駐している間ずっと守られていなかった。数値を動かしたのは joshuafolkken/kit#1390 のフックである。したがって**常駐をやめても失われるのは「読み飛ばされていた文」だけ**で、実際に効いていた経路は残る。
+常駐から外した根拠は `docs/maintainers/turn-batching-rationale.md` →「常駐から外した根拠（joshuafolkken/kit#1524）」。
 
 **引き金が発火しないターンでは何も起きず、それが正しい。** 発火しないということは往復あたりの呼び出し数が下限（1.50）を上回っているということであり、規則が守られている状態と一致する。
 
@@ -122,16 +114,8 @@ Round trips:
 1. 別の呼び出しの結果に依存しない呼び出しは、同じターンに載せる
 2. 判断基準は「依存の有無」であって呼び出しの種類ではない（読み取りも編集も同じ）。かつ、往復を減らすことは仕事を減らすことではない
 
-実測値・却下した機構案・計測の読み方はこのファイルにあり、配送文からは落としている。
-
-**上の「却下した案」の第 1 項と矛盾しない。** あれが却下したのは「1 件の呼び出しだけを見て独立性を判定する」形であり、joshuafolkken/kit#1390 が実装したのは**閉じた履歴**（既に終わったターンの並び）から判定する形である。単発呼び出しのターンが 3 つ続いたことは 1 件の呼び出しからは見えないが、履歴からは見える。
+実測値・却下した機構案・計測の読み方はこのファイルと `docs/maintainers/turn-batching-rationale.md` にあり、配送文からは落としている。
 
 ## マーカーテスト
 
-`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`）にこの規則が載っていること
+`scripts/rules/turn-batching-rule.test.ts` が固定する。内訳は `docs/maintainers/turn-batching-rationale.md` →「マーカーテストが固定するもの」。

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

@@ -17,7 +17,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（明示指示が必要）」）
-4. **`confirmation` Telegram を送って停止する**: 上流 Issue の URL と、何が止まっているかを本文に書く（→「確認待ちで停止するときの Telegram 通知（`confirmation`）」）。無人実行でも画面外でユーザーが気付ける。停止は Issue が既に存在する状態で行うので、ユーザーは「待つ / 先送りする」を Issue を見ながら 1 語で答えられる
+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・マージはそれぞれのワークフロー規則に従う）
 
 ### 第三者リポジトリへの書き込みは Tier C（明示指示が必要）