@joshuafolkken/kit 1.872.0

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

@@ -0,0 +1,206 @@
+## 報告フォーマット（平易な概要 ＋ 技術詳細）
+
+作業前サマリ（Step 7）と完了報告（Step 5）は、**平易な概要を先頭に置き、技術詳細をその下に降格する 2 層構造**で書く。ここが横断ドキュメント（`CLAUDE.md`）のカノニカル参照。
+
+理由: 報告の読み手は実装者とは限らない。ファイル名・型名・オプション名が並ぶ説明は「何が原因で、どう対応し、結果どうなったか」を伝えない。詳細を消すのではなく、**先に結論を平易な言葉で伝え、詳細は読み飛ばせる位置に置く**。
+
+### 機械的な半分は `josh report:lint` が検査する（導線）
+
+**このフォーマットには機械が判定できる半分がある** — ラベルの有無、概要行の字数上限、コードフェンス囲みでないこと、概要へのファイルパス・CLI フラグの混入。これらは目視ではなく `pnpm josh report:lint` に標準入力でサマリを渡して検査する（`ok` か違反行を印字する）。以下の各節はその**理由**を述べる散文であり、判定の一次ソースはコマンド側の定数である（joshuafolkken/kit#2123）。
+
+**判断が要る半分はコマンドの対象外で、散文として残す** — 「主語が具体的か」（下記「具体的な主語を必ず書く」）は機械には答えられない。この節が縮むのは機械的な半分の記述だけで、判断の半分はここに残る。
+
+### 出力はコードフェンスで囲まない（必須）
+
+以下のテンプレートは **フェンスの中身だけ**をセッションに書く。フェンス（` ``` `）自体はこのドキュメントでテンプレートの範囲を示すための区切りであり、**出力には含めない**。
+
+理由: セッション出力はターミナルでマークダウンとして描画される。フェンスで囲むとブロック全体に背景色と等幅フォントが当たり、平易な概要を読みやすくするという書式の目的と正面から衝突する。特に日本語の文章は等幅で詰まって読みづらくなる。
+
+そのため、テンプレートは**素のマークダウンとして成立する形**で定義してある。空白を並べた桁揃えは使わない（マークダウンは連続空白を 1 つに潰すため崩れる）。ラベルは太字、行は箇条書きで表す。`---` を単独行に置くのも避ける（水平線として描画される）。
+
+### ラベルはセッション言語に訳し、注釈は付けない（必須）
+
+ラベルについての規則は 2 つあり、**混ぜてはならない**。1 文にまとめると「書かれている通りに出す」＝「英語のまま出す」と読めてしまい、日本語セッションなのにラベルだけ英語で並ぶ出力になる。
+
+**(1) ラベルはセッション言語に訳す。** テンプレートは英語ドキュメント側の定義であり、セッションにはその訳を出す。日本語セッションでの対応:
+
+| 英語ドキュメントのラベル                                 | 日本語セッションでの表記                                              |
+| -------------------------------------------------------- | --------------------------------------------------------------------- |
+| `■ Overview`                                             | `■ 概要`                                                              |
+| `Now` / `Change` / `Check`                               | `今こうなっている` / `こう直す` / `確かめ方`                          |
+| `Details`                                                | `技術詳細`                                                            |
+| `Changes and tests`                                      | `変更とテスト`                                                        |
+| `Cause` / `Fix` / `Result`（完了報告）                   | `原因` / `対応` / `結果`                                              |
+| `■ Hand-off`（区切り）                                   | `■ 区切り`                                                            |
+| `Done` / `Remaining` / `Why it stopped` / `Next command` | `終わったこと` / `残っていること` / `止めた理由` / `次に打つコマンド` |
+
+英語のまま残すのは誤り。成果物の散文（Issue 本文、Issue／PR コメント、Telegram 本文）も同じく `JOSH_SESSION_LANG`（未設定なら `ja`）で書き、その中の `Cause` / `Fix` / `Result` などのラベルもこの対応表に従って訳す。英語のまま残るのは「出力の言語（`JOSH_SESSION_LANG`）」が挙げた 3 つ — Issue／PR タイトル、コード規約（コメント・テストタイトル・コミットメッセージ）、スクリプトが出力する固定文字列 — だけである。
+
+**(2) ラベルに注釈を付けない。** 書式の説明（「平易な説明」「先頭に置く」など）を括弧書きでラベルに足さない。`■ 概要（平易な説明）` は誤りである。
+
+理由: ドキュメント側のラベルに AI 向けの注意書きを埋め込むと、それがラベルの一部として読まれ、セッション出力にそのまま — あるいは翻訳されて — 現れる。読み手にとっては意味のない内部向けの注記が、最初に目に入る行を占めることになる。**注意書きはラベルではなく、ラベルの下の説明文に置く**。`**技術詳細**` `**変更とテスト**`、および完了報告の `**■ 完了報告**` も同じ扱い。
+
+### 作業前サマリ（セッション向け・`JOSH_SESSION_LANG` の言語）
+
+```md
+**■ 概要**
+
+- **今こうなっている**: <1文 — 利用者から見て何が起きているか>
+- **こう直す**: <1文 — 手段ではなく、直った後どうなるか>
+- **確かめ方**: <1文 — どう確認するか>
+
+**技術詳細**
+
+- 対象: <触るファイル / モジュール>
+- 方針: <アプローチとその理由>
+- 副作用 / スコープ外: <意図的にスコープ外にした点。なければ省略>
+
+**変更とテスト**
+
+1. <変更内容> — Test: <Unit|E2E> — `<file path>` — <検証する挙動>
+   - ケース: 正常 / 空・0件 / 1件 / 多数 / 境界 / 不正入力 / 重複 / 順序 / null
+     - 該当しないものは消し、消した理由を添える（例:「重複: 該当なし — 入力は集合なので重複しない」）
+   - 壊れるとしたら:
+     1. <この変更に固有の、壊れうる条件>
+     2. <...>
+     3. <...>
+2. ...
+```
+
+**テスト宣言はケース単位の 2 段で書く（joshuafolkken/kit#2246）**。1 行 1 テストの宣言はほぼ必ず正常系だけになり、場合分けを列挙する工程がどこにも無かった。そこで各変更のテスト宣言を 2 段にする。
+
+**第 1 段は形から出るケース**。固定語彙（`正常` / `空・0件` / `1件` / `多数` / `境界` / `不正入力` / `重複` / `順序` / `null`）を並べ、**該当しないものは理由を付けて消す**。効くのは残した行ではなく**消した行**で、漏れが「考えなかった」から「考えて外した」に変わる。消すときは `該当なし` に続けて理由を書く（理由の無い `該当なし` は `pnpm josh report:lint` が違反として印字する）。
+
+**第 2 段は「壊れるとしたら」**。この変更に固有の、壊れうる条件を**最低 3 件**書く。固定語彙で捕まるのは型と形から出るケースだけで、実際の想定漏れはそこに無い — 「どんなケースがあるか」は開いた問いで盲点がそのまま残るが、「壊れるとしたらどこか」は自分のコードを攻撃する問いなので盲点に当たる。**3 件書けないときは `どう呼ばれても壊れない` と明示する**（この抜け道が無いと件数の水増しを招く）。
+
+**1 ケース＝1 テスト関数ではない。** 宣言の単位とテストの単位は別で、複数ケースは `it.each` 1 本に畳んでよい。テスト本数は増えない。
+
+**境界の必須異常系はコマンドが突きつける。** 差分が HTTP・プロセス起動・ファイル IO・時間の境界を跨ぐとき、その境界の異常系（非 200・タイムアウト・空レスポンス・不正 JSON・レート制限、時間なら期限超過・重複発火など）は第 2 段に載せる。跨いだ境界と必須異常系語彙は `pnpm josh cases <path...>` が変更パスから読んで印字するので、判断ではなくコマンドの答えになる。ユニットスイートは構造的にネットワークを遮断している（`scripts/test/test-network-guard.ts`）ため、境界の異常系はスイートで実行されず、**宣言の側で突きつける**しかない。
+
+### 行数予算は編集前に読む
+
+**「対象」に書くファイルの行数の残りは、書き始める前に読む。** run #1406（PR #1422、45.8 分）を transcript から手で計測したところ、**run 全体の 19.8%・543 秒が `max-lines` の後追い対応**に消えていた。実装を書き切ったあとに `pnpm josh gate` が行数上限超過を報告し、そこから分割が始まる — その追い込みで gate が 5 回、`pnpm josh lint` が 4 回走り、うち 115 秒がツール実行、残る 353 秒はその間のモデル時間である。分割そのものは正しい作業で、**間違っているのは設計時ではなく事後に決めていること**（joshuafolkken/kit#1425）。
+
+```bash
+pnpm josh lines <path> [<path>...]   # コード行数 / 上限 / 残り、および上限に近いかどうか
+```
+
+- **手順は 2 つだけ。** Step 0 の「対象」に書くファイルを `pnpm josh lines` に渡し、**上限に近いと言われたファイルには、その場で分割方針を「対象」に書く**。書き足す量が残りを超えると分かった時点で、どこを切り出すかは設計判断であり、gate の指摘を待つ理由はない。
+- **近いかどうかは判断ではなくコマンドの答え。** 上限（ファイル 300 コード行）の 85% から「近い」で、境界はレポート自身が毎回 `near from` として印字する。85% という比率は joshuafolkken/kit#951 の常駐予算と同じ形 — 「上限に当たった」を、まだ直しを書く余裕があるうちに警告に変えるための余白 — から来ており、joshuafolkken/kit#1249（配布ドキュメントの resident budget）はまだ未実装で揃えるべき数値を持たない。常駐予算の比率（60,000 バイト中 2,000、3.3%）をそのまま当てると余白は 10 行、関数 1 個ぶんにも足りず、行き先のない警告になる。
+- **数え方は lint のものであり、`wc -l` ではない。** `max-lines` は `skipBlankLines` / `skipComments` 付きで走るのでコメントと空行は数えず、厚くコメントされたファイルは物理 453 行で 300 を通る（joshuafolkken/kit#1070）。このコマンドは行を自分で数えず、**`pnpm josh lint` と同じ eslint 実行に `max-lines` の上限だけを 0 にして尋ね**、ルール自身が報告した数値をそのまま出す。in-process の eslint API は `#!` で始まるファイルで **CLI より 1 行少なく答える**（eslint 10.10.0 で実測、CLI 301 に対し API 300）ため、gate と一致する CLI を必ず経由する。
+- **上限そのものは変わらず、これは第 2 の enforcement point でもない。** レポートは大きいファイルで失敗しない — 上限を課すのは lint であり、同じ条件で非ゼロ終了するコマンドをもう 1 つ置けば、「別の数え方で上限を満たす」という `CLAUDE.md` が禁じる workaround への入口になる。変わるのは**いつ知るか**だけである。
+- **対象外**: 関数単位の上限（25 コード行）はこのコマンドの対象ではない。`pnpm josh lint` が報告する。
+
+### 変更対象はまとめて読んでから編集する（実装前・joshuafolkken/kit#2202）
+
+**Step 0 の「変更とテスト」が変更対象ファイルを列挙した直後、それらを 1 回の `pnpm josh read:files` で読む。** 行数予算の一手順（上の `pnpm josh lines`）と同じ位置 — 列挙された「対象」に対して実装前に打つ定型コマンド — であり、助言ではなく手順である。
+
+```bash
+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 つ。
+
+### 完了報告（セッション向け）
+
+```md
+**■ 完了報告**
+
+- **原因**: <1文 — なぜそうなっていたか>
+- **対応**: <1文 — 何をしたか>
+- **結果**: <1文 — 利用者から見て何が変わったか>（v<version>）
+
+**技術詳細**
+
+- 変更ファイル: <...>
+- テスト結果: <...>
+- 実行証跡: <実行可能な経路を触った変更では、実際に叩いたコマンドとその出力（UI ならスクリーンショット）。無いなら理由>
+- 捕まえられた検証: <不具合修正のみ。その検証の種類を 1 行（2 回目は台帳で昇格, #2448）>
+- 残課題: <なければ「なし」>
+```
+
+**実行証跡は「動くこと」の証拠であり、gate の緑（回帰していないこと）ではない（joshuafolkken/kit#2246）**。実行可能な経路を触った変更では、実際に叩いたコマンドと出力（UI ならスクリーンショット）をこの行に置き、触っていなければ「なし」と理由を書く。**同じ証跡を PR 本文の `## 実機証跡` 節（コマンド＋実出力のフェンス）にも置き、無い実行時の変更は `pnpm josh followup` がマージを拒否する（#2446）**。
+
+### 区切りの報告（完了報告と区別する・必須）
+
+`backlogrun` の**区切り**（hand-off — 残りの子を新しいセッションへ渡してこのセッションを終える停止）は、**完了でも park でも失敗でもない第 4 の停止**である。既存の 3 つのどれかに寄せると必ずどれかを誤って名乗るため、専用の書式を持つ（joshuafolkken/kit#984）。
+
+**`原因` / `対応` / `結果` を使わない。** この 3 行は `CLAUDE.md` が「finished なランを報告するとき」と定義している形であり、**epic はまだ終わっていない**。実際に joshuafolkken/kit#970 を区切ったランは、中身に「残り 1 件」と正しく書きながら完了報告の 3 行で報告し、読み手には終わったように見えた。
+
+必要なのは 4 つ — **何が終わり、何が残り、なぜ止め、次に何を打つか**。
+
+```md
+**■ 区切り**
+
+- **終わったこと**: <このセッションでマージした子を番号で名指しする>
+- **残っていること**: <残りの子を件数と番号で名指しする。park した子はその旨も>
+- **止めた理由**: <なぜここで区切ったか。判断ではなくコマンドの答えを書く>
+- **次に打つコマンド**: <このランを再開するコマンド。`backlogrun` なら残りだけの `backlogrun #<next> #<after> …`（指定 epic だけなら `backlogrun #<E> --only`）>
+
+**技術詳細**
+
+- 計測: <`pnpm josh cost` が出した値と閾値>
+- 引き継ぎ: <状態は GitHub にあり、会話には何も無いこと>
+```
+
+書き方は完了報告と同じ制約に従う — 4 行それぞれ 1 文、内部識別子は書かず、対象は番号で名指しする。**「残っていること」を省略しない**: そこが完了報告との唯一の見分けであり、省いた瞬間に区切りは完了に見える。
+
+Telegram 本文も同じ書式で書き、**`--task-type confirmation` で送る**。区切りは人が次のコマンドを打つのを待つ停止であり、それが `confirmation` の意味である。`completion` で送ると、完了していない epic が完了として通知される — 書式を分けた意味がラベルの側で失われる。
+
+**この書式は「止まったとき」だけのものである。閾値を超えたこと自体は区切りではなく、停止したことが区切りである。** 4 行が答えているのは「誰が何を引き継ぐか」であり、同じセッションが走り続けているあいだ引き継ぐ人はいないからである。**まだ止まっていないランは区切りの報告を書かない** — そのときの記録は epic の進捗コメントであって、この書式ではない。
+
+**どこが「止まった」かは入口ごとに違い、条件は入口の側にある。** joshuafolkken/kit#1713 以降、`pnpm josh cost --cut` が `over` と答えたら、`backlogrun` は走っている lane を**待たずに引き継いで、そのターンで止まる** — 各 lane が unit の出力パスを自分の `.env` に記録しており、新しいセッションが `pnpm josh lane:list` からそれを読んで poll を継ぐ — ので、止まったその場で書く。例外は poll できない lane（`unreadable`、または記録の無い `open`）があるときだけで、そのときは停止せずループへ戻るので、まだ書かない。`backlogrun` の指定 Issue は 1 件ずつ走るため、その区間では待つものが無く、`over` を読んだ区切りで止まって書く（`auto-ok` バックログの区間は epic の子の区間と同じく lane を引き継ぐ）。`fullrun` / `halfrun` は joshuafolkken/kit#1605 以降**入口でも同じ判定を問う**ので、`over` ならまだ何も作っていない入口でそのまま止まって書く — 「残っていること」は着手していない Issue そのものである。**この書式を lane の状態で条件づけない**: lane を開かない入口が永久に条件を満たせなくなり、書けない側は禁じたはずの完了報告の書式へ落ちる。単一ソースは [`.claude/skills/workflow-commands/backlogrun-progress.md`](../../.claude/skills/workflow-commands/backlogrun-progress.md) →「The hand-off」。
+
+### 概要 3 行の書き方（ここが本体）
+
+長さ制限だけでは平易にならない。**語彙と抽象度を制約する**:
+
+- 各行は 1 文・短く（日本語で 80〜100 字、英語で 20〜25 語）
+- 概要にファイルパス・関数名・型名・CLI のオプションフラグ（＝内部識別子）を書かない（すべて技術詳細セクション側）。ただし利用者が画面で目にする名前は書いてよく、むしろ必要 — この禁止は下記「具体的な主語を必ず書く」と必ずセットで読む
+- 専門用語は使わないか、`〜（＝…のこと）` の形でその場で言い換える
+- 変更点の羅列ではなく **原因 → 対応 → 効果の因果**で書く
+- 主語は利用者・システムの振る舞い。「利用者から見て何が違うか」が書けないなら、その行はまだ技術詳細のまま
+
+**送信前セルフチェック（`/code-review` チェーン規則の自己チェックと同じ位置づけ）**: 報告を送る直前に次の 2 点を確認する。
+
+1. 概要 3 行にファイル名・記号・英略語が混じっていないか、プログラマでない人が読んで意味が通るか。混じっていたらその語を技術詳細へ移してから送る
+2. サマリ全体をコードフェンスで囲んでいないか。囲んでいたらフェンスを外し、上記テンプレートの素のマークダウン形に直してから送る
+3. コードを見ていない読み手が、概要 3 行だけで**どれの話か特定できるか**。特定できないなら、下記に従って具体的な名詞を 1 つ足してから送る
+
+### 具体的な主語を必ず書く（禁止と対になる要求）
+
+上の「書かない」規則だけを守ると、今度は**何の話か特定できない**概要になる。「古いまま」「案内されたコマンド」「状況が変わらない」— 文としては成立しているが、どのパッケージが古く、何を案内したのか、代わりに何が出るのかが一切分からない。禁止規則が、利用者が実際に画面で目にする名詞にまで過剰適用された結果である。
+
+そこで、禁止と対になる**要求**を置く:
+
+- **何かが「古い」「壊れている」「変わらない」と書くときは、その対象を名指しする。** 対象パッケージ名・画面名・出力の種類のいずれかを必ず含める
+- **主語のない「状況」「案内」「問題」「その処理」だけで済ませない。** 読み手がどれのことか特定できない指示語は書き換える
+- **書いてよい具体名**: 利用者が画面で目にするもの — パッケージ名、表示されるコマンドの目的、画面名、メッセージの種類
+- **書いてはいけない具体名**: 内部識別子のみ — ファイルパス、関数名・型名、CLI のオプションフラグ
+
+字数を 80〜100 字としたのはこの要求と両立させるため。60 字では対象を名指しする余地が残らず、抽象化するしかなくなっていた。
+
+**悪い例**（何の話か特定できない）:
+
+```md
+- **今こうなっている**: 古いままだと警告が出るのに、案内されたコマンドを実行しても状況が変わらないことがある。
+- **こう直す**: 効き目のない案内は理由の説明に置き換え、同じ案内が何度も並ぶのもやめる。
+- **確かめ方**: 自動テストで、無駄な案内が消え・重複が消え・従来の表示は変わらないことを確かめる。
+```
+
+**良い例**（同じ内容で、対象を名指ししている）:
+
+```md
+- **今こうなっている**: バージョン確認が「全体で使う app-kit が古い」と警告するのに、一緒に出る更新コマンドは既に入っている版を指していて、実行しても何も変わらず同じ警告がまた出る。
+- **こう直す**: 何も変えられないコマンドを出すのをやめ、なぜ変えられないかを一行で説明し、同じコマンドが並ぶときは 1 つにまとめる。
+- **確かめ方**: 自動テストで、効かないコマンドが説明に置き換わり、重複が 1 行になり、通常の表示は変わらないことを確かめる。
+```
+
+悪い例と良い例の違いは長さではなく、**名指ししているかどうか**にある。良い例には内部識別子は 1 つも出てこない。
+
+### 成果物（Issue / PR / Telegram）側
+
+言語は「出力の言語（`JOSH_SESSION_LANG`）」に従う — `JOSH_SESSION_LANG` の言語、未設定なら `ja`。**構造も**セッション向けと同じ 2 層にする。`--notify-message` は `Added ... / Changed ...` の羅列ではなく、`Cause / Fix / Result` の 3 行を先頭に置き、変更点の箇条書きを `Details:` 以下にまとめる（`--notify-message` の実例は [`followup.md`](../../.claude/skills/workflow-commands/followup.md) にある）。

package/prompts/collaboration-workflow/residency.md

@@ -0,0 +1,94 @@
+## 常駐ドキュメントと skill の分担（何を常駐に残すか）
+
+`CLAUDE.md` は毎ターン全文が読み込まれる。したがって常駐に書ける量は有限で、`scripts/claude/workflow-skills.test.ts` の `RESIDENT_CEILING_BYTES` がその上限を固定している。**どの規則を常駐に残すかは、書き手の重要度判断ではなく 3 問の順序判定で決める。**
+
+### 第 0 問（先に問う）
+
+> **その規則の答えは、機械的に読める入力だけから計算できるか。**
+
+**できるなら、規則は文書で届けない — コマンドが答える。** `pnpm josh oracle:list` が既存の決定オラクルを 20 件以上列挙しており、各行が「判断 / コマンド / 回答語彙 / 手順の単一ソース文書」を持つ。文書に残るのは「このコマンドに聞け」という導線 1 行だけで、判断の手順そのものは書かない。`scripts/rules/decision-oracle.ts` がその単一ソースである。
+
+**できない場合は、次の順序の問いに進む。**
+
+### 順序の問い（第 0 問の次に問う）
+
+> **その規則は「何を」ではなく「いつ・どの順で・どの引数で」を決めているか。**
+
+**そうであれば、規則はドライバの状態遷移に書き、散文には書かない。** `pnpm josh run:step <N>` が、実行の現在位置をイベントストリーム・キャリーレコード・Issue 状態の 3 つだけから計算し、次の 1 手を印字する（`scripts/run/run-step.ts` がその単一ソース、joshuafolkken/kit#2248）。第 0 問が**判断**を機械化したのに対し、この問いは**順序**を機械化する — 順序を散文に書けば、ドライバが計算する状態機械を読み手が毎ターン組み直す 2 つ目の手順書が並ぶだけで、読み取り量は下がらない。`fullrun.md` / `backlogrun.md` / `SKILL.md` が実行順を `run:step` へ指すだけで再説明しないのはこのためである。第 0 問と同じく、順序を決める規則はコマンド（ドライバ）が答え、文書は導線 1 行を張るだけである。
+
+**順序でないなら、以下の 2 問に進む。**
+
+> **その規則が効き始める瞬間を、1 件のツール呼び出しとして名指しできるか。**
+
+**名指しできる規則は、規則本文を常駐から出す**（joshuafolkken/kit#1524）。`prompts/collaboration-workflow/rule-delivery.md` の列挙表に 1 行加え、フックがその呼び出しを拒否して規則本文を突きつける — 常駐の散文より安く、かつ**拒否は読み飛ばせない**。ただし**フックが届くのは Claude Code だけ**なので、常駐側にはトリガと判断基準の 1 行が残る（[`rule-delivery.md`](./rule-delivery.md) →「常駐側に残すのはトリガと判断基準の 1 行」）。名指しできない規則は、次の問いに進む。
+
+> **その規則は、skill がロードされていないターンでも効く必要があるか。**
+
+答えが yes の規則だけが常駐に残り、それ以外は skill へ置いて常駐からは導線だけを張る。判定の入力は「その規則が最初に効き始めるのはコマンド開始の前か後か」の 1 点だけであり、規則の重要さは入力に含まれない。
+
+**第 1 問が先に来るのは、届ける手段が増えたからである。** 旧来この一覧は第 2 問だけで決まっていたが、それは「規則を届ける手段が常駐しかない」時代の基準だった。`PreToolUse` / `PostToolUse` / `UserPromptSubmit` が稼働している以上その前提は成立せず、joshuafolkken/kit#1344 と joshuafolkken/kit#1460 は**常駐していながら一度も発火していなかった規則が実在した**ことを計測で示している。**移設は削除ではない** — 規則本文は消えず、より強い経路に移る。
+
+**この一覧の対象範囲は、オンデマンド側に対応する手順を持つ常駐規則である** — skill であれ、オンデマンドで読むプロンプトであれ、常駐の記述が導線を張っている先を持つもの。判定基準が問うているのはまさにその規則群であり、いずれも「移せたはずだが、名前を挙げるに足る理由で残った」ものである。この範囲の中では網羅的であり、対応する手順を持つ規則がここに載らずに常駐へ入っていれば、判定基準に照らされていない。
+
+**skill の数で線を引くのは誤りである** — `verify-ui` も 3 文書から導線が張られており、下の一覧の 1 件は skill ですらない `prompts/review.md` を指している。
+
+**範囲の外にある常駐規則はこの一覧に載らないのが正常である。** 命名規約、品質上限、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` である。
+
+- **明示起動の必須**（「指示されていない行動は取らない」）— そもそもワークフローを開始してよいかを決める規則なので、ユーザーがキーワードを打った瞬間、つまり 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）
+
+**第 1 問で「名指しできる」となり、引き金つき配送へ移したもの**（joshuafolkken/kit#1524）。いずれも本文は消えておらず、規則が効く瞬間にフックが突きつける。列挙表と、引き金が発火しないターンの意味は [`rule-delivery.md`](./rule-delivery.md) にある。
+
+- **独立した呼び出しを同じターンに載せる規則** — 引き金は `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）
+
+no になり skill 側に本体を置くものの例:
+
+- 分割判定（`.claude/skills/workflow-commands/split-assessment.md`）
+- 実行中に前提 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`）
+- `auto-ok` の拾い上げと「ラベルを付けるのは人だけ」（`.claude/skills/workflow-commands/backlogrun.md`）。書き込みの禁止は普通なら常駐側に来るが、`auto-ok` はそれを禁じているドキュメント以外のどこにも存在しないため、それらを開かないターンではそもそも到達しない
+
+### 指し先になった話題ファイルは引用しない
+
+**引用先は「本文がある場所」であって、ファイルの役割名ではない。** 話題ファイルの本文を skill へ単一ソース化し、話題ファイル自体を指し先へ縮小したら、その話題への引用は **skill のファイルを直接指す**。`CLAUDE.md` も `docs/` も他の話題ファイルも同じで、「カノニカル参照」として指し先の話題ファイルを名指すことはしない（joshuafolkken/kit#1178）。
+
+判定は 1 問で、書き手の裁量には委ねない。
+
+> **その話題の本文はどのファイルにあるか。**
+
+本文がまだ話題ファイルにあるなら、これまでどおり話題ファイルを直接指す。本文が skill にあるなら skill を指す。横展開（joshuafolkken/kit#1176）の途中では両方の状態の話題が同時に存在するので、ファイルの役割名ではなく本文の所在で決めることが要る。
+
+**指し先を「カノニカル参照」として名指すと、2 回読みが戻ってくる。** 索引を指してから節名を書く形を禁じたのと同じ欠陥であり、しかも今度は本文が 1 行も無いファイルを経由させる。読み手は指し先を開き、そこに書かれた skill の名前を読み、もう一度開くことになる。**節名まで書いてある引用はさらに悪い** — 指し先には本文が無いのだから、その節はもうそこには無い。
+
+**話題ファイル自体は残す。** 索引（`prompts/collaboration-workflow.md`）は全話題ファイルを列挙しており、正典を人が読むときの入口はそこにある。指し先になった話題ファイルは「本文がどこへ行ったか」の記録として索引から辿られるものであり、他の文書からの引用で辿られるものではない。例外は単一ソースである skill 自身で、自分の指し先を名指すのは逆向きの参照だから 2 回読みを生まない。
+
+`scripts/rules/pointer-citation-document-rule.test.ts` がこれを固定する。**縮小した話題ファイルは冒頭に「この規則の単一ソースは …」の宣言文を置くこと** — 検査はこの宣言文で指し先を機械的に検出し、そこに書かれた skill が実在すること、および他の文書がその話題ファイルを引用していないことを確かめる。宣言文が入口なので、横展開で新しく縮小された話題も、この規則の対象へ自動で入る。
+
+**この基準は努力目標ではない。** 常駐に手順を書き戻すと、その分の予算を次に本当に常駐が要る規則が既存の文章から取り返すことになる。上限に張り付いた状態で 1 文を足すために別の文を削ると、**削る対象はマーカーで固定されていなかった箇所から選ばれる** — 規則の重要度ではなく、テストに拾われていなかったかどうかで残る文が決まる（joshuafolkken/kit#951）。上限そのものを引き上げる対処は、上限が防いでいる状態の追認にあたるので採らない。
+
+### 上限を引き上げてよい条件（反証条件）
+
+**「引き上げない」は絶対の禁止ではなく、反証可能な既定である。** 禁止としてだけ書くと、回収の余地が本当に尽きた日に上限を動かす手続きがどこにも無いことになり、そのとき選ばれるのは「マーカーで固定されていない文を削る」という、この基準がまさに防いでいる手であった（joshuafolkken/kit#1275）。したがって、引き上げが正当化される条件をここに書き下しておく。
+
+**次の 3 つが同時に満たされたときにかぎり、`RESIDENT_CEILING_BYTES` の引き上げを提案してよい。** 1 つでも欠けていれば、引き上げではなく回収を先にやる。
+
+1. **安いほうの選択肢が枯れている。** 常駐に残っている記述が全部この基準（「skill がロードされていないターンでも効くか」＋「トリガと導線だけか」）を通っており、指し先へ戻せる手順・根拠・ワークト例がもう無い。**枯れたことは主張ではなく測定で示す** — 回収候補を列挙し、それぞれが基準を通る理由を 1 行ずつ書いた上で、合計回収可能量が要求量を下回っていることを示す。joshuafolkken/kit#1275 の時点ではこれが満たされていなかった（Code Change Rules Step 0 のラベル規則だけで約 3KB の回収余地があり、実際に回収された）。
+2. **要求が 1 つの規則ではなく構造から来ている。** 「次の 1 文が入らない」は回収で解ける。引き上げが要るのは、常駐すべき規則の**件数**が増えて構造的に収まらなくなったときであり、そのときは「どの規則が増えたか」を列挙できる。
+3. **引き上げ幅が測定に基づく。** 1 で数えた回収可能量と 2 で数えた要求量の差だけを足す。切りのよい数字に丸めない — 丸めた余白は次の書き戻しに使われる。
+
+**非対称なリスクがあるので、迷ったら回収を選ぶ。** 回収を選んで足りなかった場合の損失は「もう一度考える」だけだが、引き上げを選んで間違っていた場合の損失は、常駐面が毎ターン全文読まれるコストとして恒久的に乗り続ける。しかも上限は一度上げると次の判断の基準線になるので、誤りが自己修復しない。
+
+**引き上げは 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 を実行するターンでは一度も読まれない**ので、ワークフローの起動読み取りから外してある

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

@@ -0,0 +1,146 @@
+# 引き金つき配送 — 規則を「効く瞬間」に届ける（joshuafolkken/kit#1524）
+
+規則の届け方は 2 つある。**常駐**（`CLAUDE.md` に書き、毎ターン読み込ませる）と、**引き金つき配送**（規則が効く瞬間にフックが本文を突きつける）である。この文書は後者の単一ソースであり、どの規則がどの引き金で配送されるかの列挙表でもある。
+
+## なぜ配送が要るのか
+
+`CLAUDE.md` は実効上限まで残り数トークンまで詰まっていた（joshuafolkken/kit#1524 起票時点で 6 トークン ≒ 15〜18 文字）。一方で `prompts/` と `.claude/skills/` は常駐部の 15 倍を抱えており、**詰まっているのは常駐という 1 本の経路だけ**である。
+
+そして配送は安いだけでなく**強い**。
+
+|            | 常駐の散文       | 引き金つき配送           |
+| ---------- | ---------------- | ------------------------ |
+| コスト     | 毎ターン         | 該当する瞬間だけ         |
+| 読まれるか | 読み飛ばされうる | **拒否は読み飛ばせない** |
+| 発火の検証 | できない         | 単体テストで固定できる   |
+| 総量の上限 | 実効上限で頭打ち | 実質なし                 |
+
+**これは推測ではなく計測済みである。** joshuafolkken/kit#1344 はバッチングの指示について、散文でも実行時の注意書きでも数値がまったく動かなかったランを 3 回連続で記録した。`PreToolUse` フックにして初めて動いた。調査ガード（joshuafolkken/kit#1460）も同じ経緯である。**常駐していながら一度も発火していなかった規則が実在した**ということであり、移設で失われるものは「効いていなかった散文」だけである。
+
+## 判定基準 — 引き金を特定できるか
+
+> **その規則が効き始める瞬間を、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 本だけ、新規に作らない
+
+配送はすべて `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` のマッチャで配線されている。拒否の優先順位はバッチングの理由が先、次に調査、最後に規則であり、各ガードは内部で従来どおり自分の環境変数スイッチを尊重する。
+- **停止スイッチ**: `JOSH_RULE_GUARD`（規則ガードのぶん。既定で有効。`off` / `0` / `false` / `no` で無効）。バッチング・調査の各ガードも同じく自前のスイッチを持つ。
+
+**規則ガードの列挙表に載るのは、効く瞬間がシェル呼び出しである規則に限られる。** Claude Code は 1 ターンのうち 1 件だけを拒否して残りを実行するため、拒否された `Edit` は兄弟の編集だけが適用された状態を残す（joshuafolkken/kit#1390）。単一の `pretool:guard` プロセスは `Bash|Edit|Read|Write` を受け取るが、規則ガードが拒否理由を返すのはシェル呼び出しに限られる。
+
+### Stop フック — 2 つ目の入口、同じ土台（joshuafolkken/kit#2121）
+
+`pretool-guard` が `PreToolUse` の入口であるのと同じ意味で、`stop:guard`（`scripts/hooks/stop-guard.ts` ＝ `pnpm josh stop:guard`）は **`Stop` イベントの入口**である。`.claude/settings.json` の `Stop` に matcher 空の**単一エントリ**として配線され、turn の終わりごとに走る。
+
+**土台は共有し、判定は再利用する。** スイッチ（`JOSH_STOP_GUARD`）と `.env` の読み込みは `hook-decision.ts` のものを、停止通知かどうかは `lane-park.ts` の正規表現を、押さえの有無は `run:hold` の記録読み取りを使う — **2 本目の判定機構は作らない**。起票の有無は `filing-cap.ts` の数え方を、第一者かどうかは `repo-party.ts` の比較を使う。違うのはイベントだけで、`Stop` のペイロードにはツール呼び出しが無く、4 行はいずれも `{"decision":"block","reason":…}` で返す。`Stop` イベントからモデルへ文字を届ける経路はこれ 1 本しかない（joshuafolkken/kit#2247）。
+
+**入口が 2 つでも土台は 1 つ。**「1 本だけ、新規に作らない」が禁じるのは共有部の 2 つ目の写しであって、イベントごとの入口ではない。`stop:guard` の 4 行は下の列挙表に載るが、引き金がシェル呼び出しではなく**ランの停止**なので、`delivered-rules.ts` の `DELIVERED_RULES`（`PreToolUse` 専用）ではなく `stop-rules.ts` に住む。どのエラーでも停止は通す（フェイルオープン）— 4 つのブロック行は自己解消し（通知を送る／押さえを解放する／起票する／引用を直して返信を出し直す）、`stop_hook_active` が無限ループの歯止めになる。
+
+`backlogrun` の通常の親ループと次の Issue の取得は監督プロセスが扱うため、次の Issue を取得させる Stop 判定は撤去した。名前を指定したエピックを判断用の headless セッションに渡す経路では、子レーンの待機がそのセッションに残るため、待機保護を維持する。停滞と取り残しの検出は Stop イベントが起きた時だけ実行し、停止判定とは独立して報告する。
+
+## 配送されている規則
+
+| 規則                                                                                                                                                                   | 引き金                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  | 引き金が発火しないターンでは                                                                                                                                                                                                    |
+| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **ターン内バッチング**（`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`（`gh issue create`、または `…/issues` への `title` 付き POST）                                                                                                                                                                                                                                                                                                                                                                                                                                                                         | Issue が起票されていない ＝ 上限に触れる行為が無い                                                                                                                                                                              |
+| **起票前の下調べ**（`.claude/skills/workflow-commands/SKILL.md` → §2e）                                                                                                | `pnpm josh rule:guard` — Issue を作成する `Bash`。そのランのトランスクリプト末尾に `pnpm josh issue:scout` が見当たらないときに拒否する。拒否文は走らせるべき `issue:scout` コマンドそのものを渡す                                                                                                                                                                                                                                                                                                                                                                                      | 起票の前に `issue:scout` を走らせている ＝ 規則は既に守られている（`issue-comments` と同じく 1 ラン 1 回）                                                                                                                      |
+| **1 ラン 10 件の起票上限**（`.claude/skills/workflow-commands/SKILL.md` → §2d、`observation-filing.md`）                                                               | `pnpm josh rule:guard` — Issue を作成する `Bash`。そのランで**拒否されていない**起票が既に 10 件あるとき、11 件目を拒否する。`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`                                                                                                                                                                                                                                                                                                                                                                                                                             | 本文がシェルに評価されない ＝ 規則は既に守られている                                                                                                                                                                            |
+| **@path をリテラル投稿する誤射**（`shell-body.md`、joshuafolkken/kit#2304）                                                                                            | `pnpm josh rule:guard` — 生フィールド（`-f` ／ `--raw-field`）で `body=@<path>` を渡した `Bash`。`@` で始まる値をそのまま送るため `@<path>` がコメントとして投稿される。**毎回発火する**                                                                                                                                                                                                                                                                                                                                                                                                | `-F` ／ `--field body=@`（ファイルを読む正しい綴り）・`@` を含まない本文・`pnpm josh issue:comment` ＝ リテラルの `@path` が送出されない                                                                                        |
+| **検証コマンドのパイプ**（`output-bounds.md`）                                                                                                                         | `pnpm josh rule:guard` — 合否を意味する josh のチェック（`gate` ／ `check` ／ `lint*` ／ `cspell*` ／ `test*` ／ `eval` ／ `overrides` ／ `ranges`）がパイプの手前に立った `Bash`                                                                                                                                                                                                                                                                                                                                                                                                       | 検証の終了コードが握りつぶされていない ＝ 失敗が失敗として伝わる                                                                                                                                                                |
+| **早すぎる進捗報告**（`.claude/skills/workflow-commands/backlogrun-progress.md` → 「Progress while the run is quiet」）                                                | `pnpm josh rule:guard` — 待つことだけが目的の `Bash`（全区間が `sleep`、または `sleep` に `echo` ／ `:` ／ `date` が並ぶだけ）。既に生きているタイマーがある回、またはその報告が間隔前に着地する回に拒否する                                                                                                                                                                                                                                                                                                                                                                            | 待機タイマーを自前で張っていない ＝ 時計は `run:progress` が 1 本だけ持っている                                                                                                                                                 |
+| **run 末尾の空転**（`background-commands.md`）                                                                                                                         | `pnpm josh rule:guard` — commit・push・PR 作成をまとめる段（`pnpm josh git -y` ／ 別名 `josh g`、`--yes` も同じ）を**前景**で出した `Bash`。`run_in_background` が付いていれば引き金に当たらない                                                                                                                                                                                                                                                                                                                                                                                        | 背景で発行している ＝ 完了通知が run を再開させ、push とマージのあいだが空かない                                                                                                                                                |
+| **gate 手前の cut**（`.claude/skills/workflow-commands/pre-gate-cut.md`）                                                                                              | `pnpm josh rule:guard` — レーンの作業ツリーに居て、目印 `JOSH_LANE_CHILD` がその Issue を指し、cut 記録がまだ無いまま `pnpm josh gate`（別名 `josh ga` も同じ）を走らせる `Bash`                                                                                                                                                                                                                                                                                                                                                                                                        | レーン以外の checkout に居る、目印が無い（レーン内の人）、または既に cut 済み ＝ 規則が守られている状態                                                                                                                         |
+| **実装フェーズの cut**（`.claude/skills/workflow-commands/pre-gate-cut.md` → 「It is a guard, fired at the edit that crosses the threshold」、joshuafolkken/kit#2310） | `pnpm josh rule:guard` — 派遣されたレーンの子（目印 `JOSH_LANE_CHILD` がその Issue を指す）で cut 記録がまだ無く、直近文脈のコスト（`pnpm josh cost --cut` と同一の統計・同一のしきい値 `CONTEXT_CUT_THRESHOLD`、測定不能は `!== UNDER` で安全側に発火）が超過しているときに出した `Edit` ／ `Write`。編集の直前で拒否し `pnpm josh run:cut --impl <N> --handoff <path>` を返す。**しきい値を跨ぐたびに発火する**（`decide`、joshuafolkken/kit#2385）。直後の同じ編集の出し直しは通すので `busy` ／ `failed` でも空回りしない                                                           | レーンの子でない（レーン外・目印なし・レーン内の人）、非編集ツール、既に cut 済み、またはコストがしきい値未満 ＝ 打ち切りが要らない状態                                                                                         |
+| **レーンの子の保留**（`.claude/skills/workflow-commands/pre-gate-cut.md`）                                                                                             | `pnpm josh rule:guard` — 派遣されたレーンの子（目印 `JOSH_LANE_CHILD` がその Issue を指す）が、判断待ちの停止通知 `pnpm josh notify --task-type confirmation` を出した `Bash`                                                                                                                                                                                                                                                                                                                                                                                                           | レーンの子でない（レーン外・目印なし・レーン内の人）、または停止通知でない ＝ 保留を記録すべき停止が無い                                                                                                                        |
+| **レーンの子の対話質問**（`.claude/skills/workflow-commands/pre-gate-cut.md` → 「The interactive ask is refused one call earlier」）                                   | `pnpm josh rule:guard` — 派遣されたレーンの子（目印 `JOSH_LANE_CHILD` がその Issue を指す）が `AskUserQuestion` を呼んだ呼び出し。停止通知の 1 つ手前で拒否し park 手順を返す。ハーネスは対話質問をターン終了で拒否するので、この 1 つ前が正しい引き金である。**毎回発火する**                                                                                                                                                                                                                                                                                                          | レーンの子でない（レーン外・目印なし・レーン内の人）、または対話ツールでない ＝ 握りつぶされる質問が無い                                                                                                                        |
+| **テストの宣言**（`CLAUDE.md` → Code Change Rules）                                                                                                                    | `pnpm josh rule:guard` — commit・push・PR 段（`pnpm josh git -y` ／ 別名 `josh g`）を出した瞬間に `pnpm josh test:declared` が作業ツリーを `required`（テストでも機械的免除パスでもない変更ファイルがある）と読む `Bash`。`run_tail` の commit 段照合を再利用し、新しい配送経路は作らない                                                                                                                                                                                                                                                                                               | 差分が `exempt`（`*.md` 等の非ランタイム）または `satisfied`（`*.test.ts` ／ `*.e2e.ts` を含む）＝ テストが要らない、または既に伴っている。免除は人が Step 0 で宣言するため 1 ラン 1 回だけ配送する                             |
+| **force push / ブランチ削除**（`operating-rules.md`、joshuafolkken/kit#2120）                                                                                          | `pnpm josh rule:guard` — `git push` / `git branch` を argv として解析し、force（`--force` ／ `-f` ／ 結合クラスタ `-uf`）・削除（`--delete` ／ `-d` ／ `-D` ／ コロン形 `:branch`）・`git -C` 前置を綴りによらず判定した `Bash`。**毎回発火する**                                                                                                                                                                                                                                                                                                                                       | force / 削除でない通常の `git push` / `git branch` ＝ 破壊的操作が無い                                                                                                                                                          |
+| **認可外の作業ツリー変更**（`operating-rules.md`、joshuafolkken/kit#2120）                                                                                             | `pnpm josh rule:guard` — `git checkout -- <path>` ／ `git restore <path>`（worktree）／ 認可外の `git stash`（bare・メッセージ無し push・位置指定 pop 等）を出した `Bash`。**毎回発火する**                                                                                                                                                                                                                                                                                                                                                                                             | メッセージ付き `git stash push -m` ・`git stash list` ・`pnpm josh git` ・`pnpm josh stash:pop` ＝ 認可された退避                                                                                                               |
+| **ファイル本文をシェルに載せない**（`file-edits.md`、joshuafolkken/kit#2120）                                                                                          | `pnpm josh rule:guard` — 既存ファイルを対象としたヒアドキュメント書き込み・書き込みを伴う `node -e` ／ インタプリタ heredoc・in-place `perl -0pi -e` を出した `Bash`。既存判定は `stat` 1 回。**毎回発火する**                                                                                                                                                                                                                                                                                                                                                                          | 新規ファイル作成・読み取り専用のヒアドキュメント・短い `sed -i` ＝ 本文を丸ごと運んでいない                                                                                                                                     |
+| **停止時の通知**（`CLAUDE.md` →「Mid-workflow stop notification」、joshuafolkken/kit#2121）                                                                            | `pnpm josh stop:guard` — `Stop` フックで、作業ツリーを押さえたまま（`run:hold` 記録あり）その turn に `confirmation` 通知を出さずに止まろうとする。**停止をブロックする**                                                                                                                                                                                                                                                                                                                                                                                                               | 押さえを持っていない、`confirmation` 通知が末尾にある、または pre-gate cut を取った回（レーンの子の自動継続）＝ 人待ちの停止ではない（`stop_hook_active` が無限ループの歯止め）                                                 |
+| **hold の解放**（`.claude/skills/workflow-commands/SKILL.md` → §2f、joshuafolkken/kit#2121）                                                                           | `pnpm josh stop:guard` — `Stop` フックで、ツリーが綺麗（`git status --porcelain` が空）なのに `run:hold` 記録が残ったまま止まる。**停止をブロックする**                                                                                                                                                                                                                                                                                                                                                                                                                                 | ツリーが汚れている（`halfrun` の commit 前停止・`needs-human-review` 停止）、または既に解放済み ＝ 次のランが踏まない                                                                                                           |
+| **Issue 引用の書式**（`prompts/collaboration-workflow/issue-citation.md`、joshuafolkken/kit#2121・joshuafolkken/kit#2247）                                             | `pnpm josh stop:guard` — `Stop` フックで、`last_assistant_message` の地の文に裸の `#N` を含む。**停止をブロックする**（モデルに差し戻し、引用を直して返信を出し直させる）                                                                                                                                                                                                                                                                                                                                                                                                               | リンク形式で引用している、コードフェンス／インラインコード／引用行の中、`PR` ／ `pull request` 直後の `#N`、または GitHub 向け成果物（`gh` 引数として渡る）、あるいは `stop_hook_active` が立っている ＝ 差し戻す裸の番号が無い |
+| **起票の申し出**（`.claude/skills/workflow-commands/SKILL.md` → §2i、joshuafolkken/kit#2422）                                                                          | `pnpm josh stop:guard` — `Stop` フックで、`last_assistant_message` の地の文が起票を申し出る（「起票してよければ」等）のに、transcript 末尾に起票（`filing_cap` の数え方）が無い。**停止をブロックする**                                                                                                                                                                                                                                                                                                                                                                                 | 起票済み、フェンス／引用行の中、第三者の `owner/repo` を名指す（`repo_party.classify`）、owner 不明、または `stop_hook_active` ＝ 保留された Tier A 起票が無い                                                                  |
+| **規則本文を散文に書き足す前の第 0 問・順序の問い**（`residency.md`、joshuafolkken/kit#2272・joshuafolkken/kit#2324）                                                  | `pnpm josh rule:guard` — `CLAUDE.md` ／ `prompts/**/*.md` ／ `.claude/skills/**/*.md` を対象とする `Edit` ／ `Write` で、リンク・URL を除いた正味の追記が閾値以上（規則本文の追記）。誤字・リンク張り替え・削除は当たらない。第 0 問（`oracle:list`）と順序の問い（`run:step`）を突きつける。1 ラン 1 回。**#2324 で stand-down** — `oracle:list` と `run:step` の両方を走らせた記録が末尾にあれば通す（リマインダではなく「問いに答えたか」で通す）                                                                                                                                    | 規則ドキュメントを編集していない、追記が閾値未満、または両方の配置判定コマンドを実行済み ＝ 散文の規則が増えていない、または配置の問いに答え済み                                                                                |
+| **オラクル未参照の行為**（`decision-oracle.ts`、joshuafolkken/kit#2324）                                                                                               | `pnpm josh rule:guard` — 発火点を宣言したオラクルが支配する `Bash`（`pkg:scout` ＝ `pnpm add`、`issue:lint` ＝ Issue 起票）を、そのオラクルの `pnpm josh <command>` 無しで出したとき拒否。拒否文は登録簿（判断・コマンド・回答語彙・単一ソース）から組み立て手書きしない。1 ラン 1 回、実行済みで stand-down。発火点を名指しできないオラクルは理由を宣言し**可視化された未強制**として残る（`oracle:list` が発火点／理由を印字）。`release:scope` は理由側で、`pnpm josh followup` のマージ**後**に owe されるリリースを読むためマージを gate せず trail する（joshuafolkken/kit#2334） | 支配下の行為を出していない、またはそのオラクルを実行済み ＝ 規則は既に守られている                                                                                                                                              |
+
+**引き金はシェルのコマンド文字列しか見えない。** したがって node の中から REST で Issue を作る経路（`pnpm josh propagate` など）は上の正規表現に掛からない。同じ理由で、本文をファイルで渡す `gh api --input <file>` もタイトルが文字列に現れないため掛からない（`-f` / `-F` / `--field` / `--raw-field` の 4 綴りは覆う）。**これが、規則本文を配送に移したうえで常駐側にトリガ 1 行を残す理由の 1 つである** — 常駐の 1 行は経路によらず効き、配送はそれを効く瞬間に補強する。引き金つきの配送だけにすると、正規表現が知っている綴りだけが規則の適用範囲になる。
+
+**「引き金が発火しないターンでは何も起きない」ことは、欠落ではなく仕様である。** 上の各行はいずれも、発火しない状態が「規則が守られている状態」と一致している。この一致が取れない規則は、引き金を特定できていないということであり、常駐に残す。**誤ったターンで発火するフックは、フックが無いより悪い。**
+
+### コメント投稿は引き金ではない
+
+WIP 上限の引き金は Issue の**作成**だけを見る。`…/issues/<N>/comments` はコメントであり、起票ではない — コメントは起票より桁違いに多く、そこで拒否するフックは「誤ったターンで発火するフック」そのものになる。`scripts/rules/delivered-rules.test.ts` がこの境界を両方向から固定している。
+
+### Issue コメントの読み取り — 「読め」ではなく「目の前に置く」（joshuafolkken/kit#1319）
+
+**引き金は実装の開始ではなく、本文が届いた 1 件の呼び出しである。** 「実装を始める瞬間」は 1 件のツール呼び出しとして名指しできないが、「Issue の本文がランの目に入る瞬間」は名指しできる — `gh issue view <N>` か、`…/issues/<N>` で終わる GET。この行が判定基準を通るのはそこである。
+
+**拒否文は「コメントも読め」という要求ではなく、読み直しのコマンドそのものを渡す。** 散文の要求は joshuafolkken/kit#1344 が 3 ラン連続で「数値がまったく動かなかった」と実測した形式であり、この行がそれを避けるのは、本文だけの読み取りが**通らない**ことによる。ランの次の一手はコメント込みの読み取りになり、コメントは「読むべきもの」ではなく実際に手元にある。ただし `PreToolUse` の拒否が運べるのは文字列 1 本だけなので、**フックがコメント本文を注入するわけではない** — 1 往復ぶん遅れて、ランが自分で取りに行く。
+
+**この行は `batch:guard` と引き金が重なる唯一の行である。** `time_batch_guard.is_guarded_call` は `gh issue view` を候補として扱う（`gh issue create` は扱わない）。したがって `is_first_delivery` の待避分岐は、WIP 上限では一度も発火しない不活性な保険だったが、この行で初めて実際に働く — バッチングの拒否が出るターンでは何も配送せず（記録も残さず）、再発行で配送する。`delivered-rules.test.ts` が両方向を固定している。
+
+**判定はコマンド 1 件ごとに、行頭に錨を打って行う。** シェル 1 行は複数のコマンドを運ぶため、`&&` ／ `||` ／ `;` ／ 改行で区切った各区間をそれぞれ判定する（`|` は区切りに使わない — `--jq` の中に現れる方がはるかに多い）。これがないと 2 つの誤りが同時に出る。引用符の中に `gh issue view` を含む書き込み（`gh issue comment <N> -b "…"`）が読み取りと誤認され、逆に `gh issue view <N> && grep -c x` のように無関係な `-c` を含む行が「コメント込み」と誤認されて配送が消える。
+
+**書き込みは読み取りではない。** `gh api` は `-f` ／ `-F` ／ `--field` ／ `--raw-field` ／ `--input` のいずれかが現れた時点で POST になり、`kickoff` はまさに `…/issues/<N>` へ PATCH してタイトルを正規化し空の本文を埋める。メソッドが明示的に `GET` でない、またはフィールド系のフラグを伴う呼び出しは対象外とする — さもないと 1 ラン 1 回の配送を書き込みに使い切り、同じランの本当の本文読み取りは無防備になる。
+
+**`-c` は「コメント込み」と見なさない。** `gh issue view <N> -c` は正しい読み取りだが、`-c` は `wc` ／ `grep` ／ `sort` のものである方が圧倒的に多く、これを行全体で許すとパイプで終わる複合行すべてで規則が黙る。誤って 1 往復ぶん止める側に倒し、`--comments` ／ `--json` の `comments` ／ `…/comments` エンドポイントの 3 綴りだけを「コメント込み」とする。最後の 1 つが要るのは、バッチングが本文とコメントを 1 行にまとめさせるからで、それを拒否すれば規則が求める形そのものを拒否することになる。
+
+**それでもシェル文字列しか見えない。** node の中から REST で本文を読む経路は最初から掛からない。だからこそ手順本体は `SKILL.md` → §2g に置かれており、フックはそれを補強するだけである。
+
+## 配送は 1 ラン 1 回
+
+配送文は**ラン 1 回につき 1 度**しか出ない（記録は `hook-decision.ts` の stamp）。2 度目も拒否すれば、規則に従った直後の呼び出しを止めてラン自体を詰まらせる。したがって**配送文には「数えたうえで同じ呼び出しをもう一度出せ」と明記する**。これが無いと、拒否された側は次に何をすればよいか分からない。
+
+### 例外 — 繰り返す行為を止める行は毎回発火する（joshuafolkken/kit#1570）
+
+**1 ラン 1 回が正しいのは、拒否がランの「知っていること」を変える行だけである。** コメントを読む、Issue を数える、本文をファイルに書く — いずれも一度届けば、そのランは以後それを知った状態で進む。**一方、止めたい対象そのものが繰り返される行為なら、1 回で終わる配送は「一度断られたあとは自由」を意味し、強制は親の自制に戻る。** その自制が破れたのが #1570 である。
+
+そこで **`decide` を自前で持つ行は 1 ラン 1 回の対象から外れ、条件を満たすかぎり毎回拒否する**。
+
+**`batch:guard` との待避分岐は、そういう行では守る対象が変わる。** 1 ラン 1 回の行では**記録**を守っていた — レースに負ければ、そのランに 1 度しかない配送を無駄打ちするからである。毎回発火する行はその形では消えない。一方で待機タイマーを張る呼び出しは定義上「単発の `Bash`」であり、まさにバッチングガードも候補として扱う形なので、**拒否まで待避させると、10 秒の窓とその中の再発行で規則がまるごと黙る**。したがって**拒否は無条件に行い、待避は「記録してよいか」として行へ渡す** — 他のフックが止めうる呼び出しでしてはならないのは、走らなかったタイマーを生きていると書き残すことだからである。配送文には「これは毎回発火する」と明記する（1 回きりだと読まれると、再発行すれば通ると誤解される）。
+
+## 本文のシェル評価は同じ機構の 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) にある。
+
+## マーカーテスト
+
+- `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/issue-scout.test.ts` — 起票前の下調べの述語（`runs_the_scout` ／ `already_scouted`）を固定する。発火・非発火（下調べのない起票で発火し、直前に `issue:scout` があるターンでは無言、`#N` の読み取り・更新では無言）は `scripts/rules/delivered-rules.test.ts` が固定する
+- `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）、および実際の配送経路での 1 ラン 1 回はこの 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` が固定する