@joshuafolkken/kit 1.1240.0 → 1.1373.0

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

@@ -8,7 +8,7 @@
 
 ### 出力はコードフェンスで囲まない（必須）
 
-以下のテンプレートは **フェンスの中身だけ**をセッションに書く。フェンスで囲むと等幅・背景色で描画され、平易な概要が読みにくくなる。空白での桁揃えと単独行の `---` も使わない（前者は潰れ、後者は水平線になる）。
+以下のテンプレートは **フェンスの中身だけ**をセッションに書く（空白での桁揃えと単独行の `---` も使わない）。
 
 ### ラベルはセッション言語に訳し、注釈は付けない（必須）
 
@@ -28,6 +28,15 @@
 
 **(2) ラベルに注釈を付けない。** `■ 概要（平易な説明）` は誤り。注意書きはラベルではなく、ラベルの下の説明文に置く。
 
+### 作業前サマリはいつ・どう出すか
+
+`CLAUDE.md` → "Code Change Rules" の Step 0 が指す細目の単一ソース。
+
+- **いつ**: 実装コードを書く前に、Issue ごとに 1 回出す。`fullrun` / `halfrun` / `prrun` / `backlogrun` で必須、`kickoff` は対象外。確認のための停止ではない — 出したらそのまま実装に進む
+- **概要**: `Now` / `Change` / `Check` を各 1 文、セッション言語で、プログラマでない人にも追える文で書く。各行に具体的な主語を書き、主語のない文は不可（下記「具体的な主語を必ず書く」）。ファイルパス・関数名や型名・CLI のオプションフラグは書かない — 禁じるのは内部識別子だけである
+- **技術詳細**: すべての変更をそのテストとともに `<変更内容> — Test: <Unit|E2E> — <file path> — <検証する挙動>` の形で並べる
+- **完了報告**は `Cause` / `Fix` / `Result` を先頭に置く
+
 ### 作業前サマリ（セッション向け・`JOSH_SESSION_LANG` の言語）
 
 ```md
@@ -68,7 +77,7 @@
 
 ### 変更対象はまとめて読んでから編集する（joshuafolkken/kit#2202）
 
-**「変更とテスト」が変更対象ファイルを列挙した直後、それらを 1 回の `pnpm josh read:files <path> [<path> ...]` で読み、続く独立した編集は 1 回の `pnpm josh edit:files -` で送る**（形式は `docs/josh-commands-run.md` →「`josh edit:files`」）。**個別の `Edit` に戻すのは**、前の編集結果に依存する編集（`dependent` で拒否される）、編集が 1 件だけのとき、ファイル全体を書くとき（`Write`）の 3 つ。根拠は [`turn-batching.md`](turn-batching.md) →「実装中の独立編集に効く合成コマンド」。
+**「変更とテスト」が変更対象ファイルを列挙した直後、それらを 1 回の `pnpm josh read:files <path> [<path> ...]` で読み、続く独立した編集は 1 回の `pnpm josh edit:files -` で送る**（個別の `Edit` に戻すのは依存する編集・1 件だけの編集・`Write` のとき）。単一ソースは [`turn-batching.md`](turn-batching.md) →「実装中の独立編集に効く合成コマンド」。
 
 ### 完了報告（セッション向け）
 
@@ -90,43 +99,21 @@
 
 **実行証跡は「動くこと」の証拠であり、gate の緑ではない（joshuafolkken/kit#2246）。** 同じ証跡を PR 本文の `## 実機証跡` 節（コマンド＋実出力のフェンス）にも置く。無い実行時の変更は `pnpm josh followup` がマージを拒否する（#2446）。
 
-### 区切りの報告（完了報告と区別する・必須）
-
-`backlogrun` の**区切り**（hand-off — 残りを新しいセッションへ渡して止まる）は、完了でも park でも失敗でもない第 4 の停止である（joshuafolkken/kit#984）。**`原因` / `対応` / `結果` を使わない** — 終わっていない epic が終わったように見える。
-
-```md
-**■ 区切り**
+**`run:carry` の実行証跡は `JOSH_TEMP_ROOT` を新しい一時ディレクトリに向けて取る（必須）。** run の状態レコードは、走っている本物の run と共有の 1 か所にあり、作業ディレクトリを移しても `pnpm --dir` を使っても切り離せない。変数は起動時に読まれるので、`JOSH_TEMP_ROOT="$(mktemp -d)" pnpm josh run:carry --begin …` のように各コマンドの頭に付ける（`docs/environment-variables.md` → "Runs"）。**`run:merge` はこれで切り離せない** — レコードの他に main の同期・lane の close・GitHub への書き込みを行うため、一時ルートを変えても本物の run の共有状態に触れる。
 
-- **終わったこと**: <このセッションでマージした子を番号で名指しする>
-- **残っていること**: <残りの子を件数と番号で名指しする。park した子はその旨も>
-- **止めた理由**: <なぜここで区切ったか。判断ではなくコマンドの答えを書く>
-- **次に打つコマンド**: <このランを再開するコマンド。`backlogrun` なら残りだけの `backlogrun #<next> #<after> …`（指定 epic だけなら `backlogrun #<E> --only`）>
-
-**技術詳細**
-
-- 計測: <`pnpm josh cost` が出した値と閾値>
-- 引き継ぎ: <状態は GitHub にあり、会話には何も無いこと>
-```
+### 区切りの報告（完了報告と区別する・必須）
 
-- 4 行それぞれ 1 文、内部識別子は書かず、対象は番号で名指しする。**「残っていること」を省略しない**（そこが完了報告との唯一の見分け）
-- Telegram も同じ書式で、**`--task-type confirmation` で送る**（`completion` は未完了の epic を完了と通知する）
-- **書くのは止まったときだけ。** 閾値を超えても走り続けているあいだは書かず、epic の進捗コメントが記録になる。どこで止まるかは入口ごとに違い、単一ソースは [`.claude/skills/workflow-commands/backlogrun-progress.md`](../../.claude/skills/workflow-commands/backlogrun-progress.md) →「The hand-off」
+`backlogrun` の**区切り**（hand-off）は完了報告ではない — **`原因` / `対応` / `結果` を使わない**。書式は [`.claude/skills/workflow-commands/backlogrun-handoff-report.md`](../../.claude/skills/workflow-commands/backlogrun-handoff-report.md)。
 
 ### 概要 3 行の書き方（ここが本体）
 
-長さ制限だけでは平易にならない。**語彙と抽象度を制約する**:
+字数と内部識別子の混入は `report:lint` が検査する。長さ制限だけでは平易にならないので、**語彙と抽象度を制約する**:
 
-- 各行は 1 文・短く（日本語で 80〜100 字、英語で 20〜25 語）
-- 概要にファイルパス・関数名・型名・CLI のオプションフラグ（＝内部識別子）を書かない（すべて技術詳細側）。ただし利用者が画面で目にする名前は書いてよく、むしろ必要 — 下記「具体的な主語を必ず書く」と必ずセットで読む
 - 専門用語は使わないか、`〜（＝…のこと）` の形でその場で言い換える
 - 変更点の羅列ではなく **原因 → 対応 → 効果の因果**で書く
 - 主語は利用者・システムの振る舞い。「利用者から見て何が違うか」が書けないなら、その行はまだ技術詳細のまま
 
-**送信前セルフチェック**: 報告を送る直前に確認する。
-
-1. 概要 3 行にファイル名・記号・英略語が混じっていないか、プログラマでない人が読んで意味が通るか。混じっていたら技術詳細へ移す
-2. サマリ全体をコードフェンスで囲んでいないか
-3. コードを見ていない読み手が、概要 3 行だけで**どれの話か特定できるか**。できないなら具体的な名詞を 1 つ足す
+**送信前セルフチェック**: コードを見ていない読み手が、概要 3 行だけで**どれの話か特定できるか**。できないなら具体的な名詞を 1 つ足す。
 
 ### 具体的な主語を必ず書く（禁止と対になる要求）
 

package/prompts/collaboration-workflow/residency.md

@@ -18,7 +18,7 @@
 
 > **その規則が効き始める瞬間を、1 件のツール呼び出しとして名指しできるか。**
 
-**名指しできる規則は、規則本文を常駐から出し、[`rule-delivery.md`](./rule-delivery.md) の列挙表に 1 行加える**（joshuafolkken/kit#1524）。フックは Claude Code にしか届かないので、**常駐にはトリガと判断基準の 1 行を残す**。根拠は `docs/maintainers/residency-rationale.md` → "Why a delivered rule keeps one resident line"。
+**名指しできる規則は、規則本文を常駐から出し、配送ガードの行に `scripts/rules/rule-registry.ts` の項目を添え、[`rule-delivery.md`](./rule-delivery.md) が指す `pnpm josh rule:list` の一覧に載せる**（joshuafolkken/kit#1524）。**規則ごとのトリガ行は常駐に残さない** — `CLAUDE.md` が持つのは一覧への導線 1 行だけで、フックが走らないセッションはその一覧を自己点検に適用する（`principles.md` →「Claude Code 以外のエージェントでの読み替え」）。根拠は `docs/maintainers/residency-rationale.md` → "Why a delivered rule leaves no resident line"。
 
 ### 第 2 問 — skill なしのターンでも効く必要があるか
 

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

@@ -1,6 +1,6 @@
 # 引き金つき配送 — 規則を「効く瞬間」に届ける（joshuafolkken/kit#1524）
 
-規則の届け方は 2 つある。**常駐**（`CLAUDE.md` に書き、毎ターン読み込ませる）と、**引き金つき配送**（規則が効く瞬間にフックが本文を突きつける）である。この文書は後者の単一ソースであり、配送される規則の一覧でもある。配線・判定の細部と経緯は `docs/maintainers/rule-delivery-rationale.md` にあり、ランの途中で読む必要はない。
+規則の届け方は 2 つある。**常駐**（`CLAUDE.md` に書き、毎ターン読み込ませる）と、**引き金つき配送**（規則が効く瞬間にフックが本文を突きつける）である。この文書は後者の単一ソースである。配線・判定の細部と経緯は `docs/maintainers/rule-delivery-rationale.md` にあり、ランの途中で読む必要はない。
 
 ## なぜ配送が要るのか
 
@@ -8,111 +8,23 @@
 
 ## 判定基準 — 引き金を特定できるか
 
-どの規則を配送へ移すか — 引き金を 1 件のツール呼び出しとして名指しできるか、常駐側にトリガの 1 行を残す理由、移設が削除ではないこと — の単一ソースは [`residency.md`](./residency.md) →「第 1 問」であり、ここには写さない。この文書が持つのは、移した規則の一覧である。
+どの規則を配送へ移すかの単一ソースは [`residency.md`](./residency.md) →「第 1 問」であり、ここには写さない。
 
 ## 機構 — 1 本だけ、新規に作らない
 
-配送はすべて 1 つの土台に載り、入口はイベントごとに 2 つある。`PreToolUse` の入口が `pnpm josh pretool:guard`（バッチング ／ 調査 ／ 規則の 3 ガードを 1 プロセスで合成）、Stop フックの入口が `pnpm josh stop:guard` である。**2 本目の配送経路を作るのは `CLAUDE.md` →「No clones」が禁じるクローン**である。配線・停止スイッチ・拒否の優先順位: `docs/maintainers/rule-delivery-rationale.md` → "The mechanism"。
+配送はすべて 1 つの土台に載り、入口はイベントごとに 2 つある。`PreToolUse` の入口が `pnpm josh pretool:guard`（バッチング ／ 調査 ／ 規則の 3 ガードを 1 プロセスで合成）、Stop フックの入口が `pnpm josh stop:guard` である。**2 本目の配送経路を作るのは `CLAUDE.md` →「No clones」が禁じるクローン**である。**配送は拒否とは限らず、呼び出しの書き換え（`updatedInput`）でもよい** — 規則の結果そのものを機械的に作れる形に限る。書き換えはフックが添える注記で記録され、`pnpm josh rule:value` が `rewritten` として数える。配線・停止スイッチ・拒否の優先順位: `docs/maintainers/rule-delivery-rationale.md` → "The mechanism"。
 
 ## 配送されている規則
 
-各項目は**規則**（単一ソース）・**発火点**・**発火しないとき**を持つ。フックが走らないエージェントはこれを自己適用のチェックリストにする（`principles.md`）。頻度を書いていない項目は 1 ラン 1 回だけ配送される — 「毎回発火する」「毎回拒否する」「たびに発火する」「停止をブロックする」（`stop:guard` は止まるたびに判定する）と書いた項目は、条件を満たすかぎり何度でも発火し、「再び発火する」と書いた項目は間隔をおいて再発火する。
+一覧は `pnpm josh rule:list` が `scripts/rules/delivered-rules.ts` の行から生成する（joshuafolkken/kit#3399）。各項目は規則の単一ソース・発火点・発火しないときを持ち、フックが走らないエージェントはその出力を自己適用のチェックリストにする（`principles.md`）。
 
-- **ターン内バッチング**（`turn-batching.md`）
-  - 発火点: `pnpm josh batch:guard` — 単発呼び出しのターンが 3 つ続いた次の `Bash` / `Edit` / `Read`。単発が続くかぎり、さらに 3 ターンごとに**再び発火する**（joshuafolkken/kit#2164）
-  - 発火しないとき: 往復あたりの呼び出し数が下限を上回っている ＝ 規則は既に守られている
-- **調査の委譲しきい値**（`delegation.md`）
-  - 発火点: `pnpm josh investigation:guard` — 編集しないファイルの読み取りが 3 件目に達した `Read` / `Bash`。拒否の後も読み取りがもう一度しきい値まで積み上がれば**再び発火する**
-  - 発火しないとき: 読み取りがしきい値未満 ＝ 委譲する対象がまだ無い
-- **バックログ WIP 上限**（`wip-cap.md`）
-  - 発火点: `pnpm josh rule:guard` — Issue を起票する `Bash`（`pnpm josh issue:file`）
-  - 発火しないとき: Issue が起票されていない ＝ 上限に触れる行為が無い
-- **直接起票の禁止**（`docs/josh-commands-backlog.md` → `josh issue:file`、joshuafolkken/kit#2808）
-  - 発火点: `pnpm josh rule:guard` — `josh issue:file` を通さずに Issue を作成する `Bash`（`gh issue create`、または `…/issues` への `title` 付き POST）。拒否文は `pnpm josh issue:file` の書式を渡す。**毎回発火する**
-  - 発火しないとき: `pnpm josh issue:file` で起票している ＝ 重複探し・本文の検査・`epic:bundle` までの全段がそろっている
-- **1 ラン 10 件の起票上限**（`.claude/skills/workflow-commands/prerequisite.md`、`observation-filing.md`）
-  - 発火点: `pnpm josh rule:guard` — 拒否されていない起票が既に 10 件あるランの 11 件目の `pnpm josh issue:file`。失敗した呼び出しは数えない。**毎回発火する**
-  - 発火しないとき: 拒否されていない起票が 10 件未満 ＝ 上限に触れていない
-- **Issue コメントの読み取り**（`issue-comments.md`）
-  - 発火点: `pnpm josh rule:guard` — Issue 本文だけを読む `Bash`（`gh issue view <N>`、または `…/issues/<N>` で終わる GET）。コメント込みで読み直すまで毎回拒否する
-  - 発火しないとき: Issue を読んでいない、または最初から `--comments` ／ `--json comments` ／ `…/comments` で読んでいる
-- **本文をシェルに載せない**（`shell-body.md`）
-  - 発火点: `pnpm josh rule:guard` — 二重引用符の本文値（`-f body="…"` ／ `-f "body=…"` ／ `--body "…"` ／ `--notify-message "…"`）にバッククォートか `$` を含む `Bash`
-  - 発火しないとき: 本文がシェルに評価されない ＝ 規則は既に守られている（経緯: `docs/maintainers/rule-delivery-rationale.md` → "Shell evaluation of a body is one more row of the same mechanism"）
-- **@path をリテラル投稿する誤射**（`shell-body.md`、joshuafolkken/kit#2304）
-  - 発火点: `pnpm josh rule:guard` — 生フィールド（`-f` ／ `--raw-field`）で `body=@<path>` を渡した `Bash`。**毎回発火する**
-  - 発火しないとき: `-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/progress-watcher.md` → 「Progress while the run is quiet」）
-  - 発火点: `pnpm josh rule:guard` — 待つことだけが目的の `Bash`（`sleep` だけ、または `echo` ／ `:` ／ `date` を並べただけ）を、タイマーが生きている回か報告が間隔前に着地する回に出したとき。**毎回発火する**
-  - 発火しないとき: 待機タイマーを自前で張っていない ＝ 時計は `run:progress` が 1 本だけ持っている
-- **run 末尾の空転**（`background-commands.md`）
-  - 発火点: `pnpm josh rule:guard` — `pnpm josh git -y`（別名 `josh g`、`--yes` も同じ）を**前景**で出した `Bash`。**毎回発火する**
-  - 発火しないとき: 背景で発行している ＝ 完了通知が 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` — 派遣されたレーンの子が cut 前に、直近文脈のコストが `pnpm josh cost --cut` のしきい値を超えた状態で出す `Edit` ／ `Write`。拒否文は `pnpm josh run:cut --impl <N> --handoff <path>` を渡す。しきい値を跨ぐたびに発火する
-  - 発火しないとき: レーンの子でない、非編集ツール、既に cut 済み、またはコストがしきい値未満 ＝ 打ち切りが要らない状態
-- **レーンの子の保留**（`.claude/skills/workflow-commands/pre-gate-cut.md`）
-  - 発火点: `pnpm josh rule:guard` — 派遣されたレーンの子が停止通知 `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` — 派遣されたレーンの子の `AskUserQuestion`。park 手順を返す。**毎回発火する**
-  - 発火しないとき: レーンの子でない、または対話ツールでない ＝ 握りつぶされる質問が無い
-- **テストの宣言**（`CLAUDE.md` → Code Change Rules）
-  - 発火点: `pnpm josh rule:guard` — `pnpm josh git -y`（別名 `josh g`）を出した瞬間に `pnpm josh test:declared` が `required` と答える `Bash`
-  - 発火しないとき: `exempt`（非ランタイムのみ）または `satisfied`（テストを含む）＝ テストが要らない、または伴っている
-- **force push / ブランチ削除**（`operating-rules.md`、joshuafolkken/kit#2120）
-  - 発火点: `pnpm josh rule:guard` — 綴りによらず force（`--force` ／ `-f` ／ `-uf` 等）・削除（`--delete` ／ `-d` ／ `-D` ／ `:branch`）と判定した `git push` / `git branch` の `Bash`。**毎回発火する**
-  - 発火しないとき: 通常の `git push` / `git branch` ＝ 破壊的操作が無い
-- **認可外の作業ツリー変更**（`operating-rules.md`、joshuafolkken/kit#2120）
-  - 発火点: `pnpm josh rule:guard` — `git checkout -- <path>` ／ `git restore <path>` ／ 強制 `git clean -f` ／ 認可外の `git stash`（bare・メッセージ無し push・位置指定 pop 等）の `Bash`。**毎回発火する**
-  - 発火しないとき: `git stash push -m` ・`git stash list` ・`pnpm josh git` ・`pnpm josh stash:pop` ＝ 認可された退避
-- **index の書き換え**（`operating-rules.md`、joshuafolkken/kit#2983）
-  - 発火点: `pnpm josh rule:guard` — 綴りによらず `git add` ／ `commit` ／ `reset` ／ `rm` ／ `mv` ／ `restore --staged` と判定した `Bash`。**毎回発火する**
-  - 発火しないとき: `pnpm josh git` ＝ 承認済みのコミットフロー
-- **破壊的コマンド**（`operating-rules.md`、joshuafolkken/kit#2983）
-  - 発火点: `pnpm josh rule:guard` — `rm -rf`（綴りによらず）・`gh repo delete` ／ `archive`・`gh pr close`・`gh api -X DELETE` の `Bash`。**毎回発火する**
-  - 発火しないとき: `gh issue close`・Issue ラベルの削除 ＝ ワークフロー自身の手順
-- **PR の直接作成**（`CLAUDE.md` → Git Rules、joshuafolkken/kit#3183）
-  - 発火点: `pnpm josh rule:guard` — `gh pr create`・`repos/<o>/<r>/pulls` への `gh api` 書き込みの `Bash`。`pnpm josh pr` を案内する。**毎回発火する**
-  - 発火しないとき: `pnpm josh pr`・PR の閲覧 ＝ `closes #N` を生成する経路
-- **保護ファイル**（`operating-rules.md`、joshuafolkken/kit#2983）
-  - 発火点: `pnpm josh rule:guard` — `.env` の `Read`、kit 以外のリポジトリでの `.claude/settings.json` の `Edit` ／ `Write`。**毎回発火する**
-  - 発火しないとき: kit 自身とユーザー単位の `~/.claude/settings.json` の編集
-- **ファイル本文をシェルに載せない**（`file-edits.md`、joshuafolkken/kit#2120）
-  - 発火点: `pnpm josh rule:guard` — 既存ファイルへのヒアドキュメント書き込み・書き込みを伴う `node -e` ／ インタプリタ heredoc・`perl -0pi -e` の `Bash`。**毎回発火する**
-  - 発火しないとき: 新規ファイル作成・読み取り専用のヒアドキュメント・短い `sed -i` ＝ 本文を丸ごと運んでいない
-- **停止時の通知**（`CLAUDE.md` →「Mid-workflow stop notification」、joshuafolkken/kit#2121）
-  - 発火点: `pnpm josh stop:guard` — 作業ツリーを押さえたまま、その turn に `confirmation` 通知を出さずに止まる。**停止をブロックする**
-  - 発火しないとき: 押さえが無い、`confirmation` 通知が末尾にある、または pre-gate cut を取った回 ＝ 人待ちの停止ではない
-- **hold の解放**（`.claude/skills/workflow-commands/working-tree-hold.md`、joshuafolkken/kit#2121）
-  - 発火点: `pnpm josh stop:guard` — ツリーが綺麗なのに `run:hold` 記録が残ったまま止まる。**停止をブロックする**
-  - 発火しないとき: ツリーが汚れている（`halfrun` の commit 前停止・`needs-human-review` 停止）、または解放済み ＝ 次のランが踏まない
-- **Issue 引用の書式**（`prompts/collaboration-workflow/issue-citation.md`、joshuafolkken/kit#2121・joshuafolkken/kit#2247）
-  - 発火点: `pnpm josh stop:guard` — 最後の返信の地の文に裸の `#N` を含む。**停止をブロックする**。引用を直して返信を出し直させる
-  - 発火しないとき: リンク形式・コード／引用行の中・`PR` 直後の `#N`・GitHub 向け成果物 ＝ 差し戻す裸の番号が無い
-- **起票の申し出**（`.claude/skills/workflow-commands/observation-filing.md`、joshuafolkken/kit#2422）
-  - 発火点: `pnpm josh stop:guard` — 最後の返信の地の文が起票を申し出る（「起票してよければ」等）のに、起票していない。**停止をブロックする**
-  - 発火しないとき: 起票済み、フェンス／引用行の中、第三者の `owner/repo` を名指す、または owner 不明 ＝ 保留された Tier A 起票が無い
-- **規則本文を散文に書き足す前の第 0 問・順序の問い**（`residency.md`、joshuafolkken/kit#2272・joshuafolkken/kit#2324）
-  - 発火点: `pnpm josh rule:guard` — `CLAUDE.md` ／ `prompts/**/*.md` ／ `.claude/skills/**/*.md` への `Edit` ／ `Write` で、正味の追記が閾値以上のもの。`pnpm josh oracle:list` と `pnpm josh run:step` の両方を走らせるまで毎回拒否する
-  - 発火しないとき: 規則ドキュメントでない、追記が閾値未満（誤字・リンク張り替え・削除）、または両コマンドを実行済み ＝ 配置の問いに答え済み
-- **オラクル未参照の行為**（`decision-oracle.ts`、joshuafolkken/kit#2324）
-  - 発火点: `pnpm josh rule:guard` — 発火点を宣言したオラクルが支配する `Bash`（`pkg:scout` ＝ `pnpm add`）を、そのオラクルの `pnpm josh <command>` 無しで出したとき。実行するまで毎回拒否する
-  - 発火しないとき: 支配下の行為を出していない、またはそのオラクルを実行済み ＝ 規則は既に守られている
+**引き金はシェルのコマンド文字列しか見えない**（node 内の REST や `gh api --input <file>` は掛からない）。だから常駐側にトリガ 1 行を残し、配送はそれを効く瞬間に補強する。経緯: `docs/maintainers/rule-delivery-rationale.md` → "Shell evaluation of a body is one more row of the same mechanism"。
 
-**引き金はシェルのコマンド文字列しか見えない**（node 内の REST や `gh api --input <file>` は掛からない）。だから常駐側にトリガ 1 行を残し、配送はそれを効く瞬間に補強する。
-
-**「引き金が発火しないターンでは何も起きない」ことは仕様である。** 各項目の発火しない状態は「規則が守られている状態」と一致する。一致が取れない規則は引き金を特定できておらず、常駐に残す。**誤ったターンで発火するフックは、フックが無いより悪い。**
+**「引き金が発火しないターンでは何も起きない」ことは仕様である。** 各項目の発火しない状態は「規則が守られている状態」と一致する。一致が取れない規則は常駐に残す。**誤ったターンで発火するフックは、フックが無いより悪い。**
 
 ## 配送は 1 ラン 1 回
 
-配送文は**ラン 1 回につき 1 度**しか出ない — 2 度目も拒否すれば、規則に従った直後の呼び出しを止めてしまう。だから**配送文には「同じ呼び出しをもう一度出せ」と明記する**。例外は 2 つで、繰り返す行為を止める項目は毎回発火し（joshuafolkken/kit#1570）、前提の行為を求める項目は前提が末尾に現れるまで毎回拒否する（joshuafolkken/kit#2807）。これとは別に、バッチングと調査の 2 ガードは同じ呼び出しを二度拒否しないまま、違反が間隔分続けば再び発火する（joshuafolkken/kit#2164）— 1 回きりの注意ではない。先の 2 つの例外の配送文には「同じ呼び出しをもう一度出せ」ではなく、それぞれ「これは毎回発火する」「前提が末尾に現れるまで拒否する」と明記する — 1 回きりと読まれると、再発行すれば通ると誤解される。前提の証拠を読めないときは拒否を基本とする。経緯と意図した通過例外: `docs/maintainers/rule-delivery-rationale.md` → "One delivery per run"。
+配送文は**ラン 1 回につき 1 度**しか出ないので、**「同じ呼び出しをもう一度出せ」と明記する**。例外は 2 つで、繰り返す行為を止める項目は毎回発火し（joshuafolkken/kit#1570）、前提の行為を求める項目は前提が末尾に現れるまで毎回拒否する（joshuafolkken/kit#2807）。その配送文にはそれぞれ「これは毎回発火する」「前提が末尾に現れるまで拒否する」と明記する。バッチングと調査の 2 ガードは違反が間隔分続けば再び発火する（joshuafolkken/kit#2164）。前提の証拠を読めないときは拒否を基本とする。経緯: `docs/maintainers/rule-delivery-rationale.md` → "One delivery per run"。
 
 ## マーカーテスト
 

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

@@ -1,6 +1,6 @@
 ## 本文をシェルの二重引用符に載せない（joshuafolkken/kit#1198）
 
-`CLAUDE.md` →「Never put a body in shell double quotes」の単一ソース。隣にある「Never carry a file's new text inside a shell command」（[`file-edits.md`](./file-edits.md)）と対になる規則である。**あちらは「ファイルの中身をシェルに載せるな」、こちらは「本文をシェルに載せるな」** であり、禁じている理由が違う — あちらはコストの二重払い、こちらは**テキストが実行されること**である。
+「本文をシェルの二重引用符に載せない」規則の単一ソース（`CLAUDE.md` からは [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」を経て届く）。「ファイル本文をシェルに載せない」（[`file-edits.md`](./file-edits.md)）と対になる規則である。**あちらは「ファイルの中身をシェルに載せるな」、こちらは「本文をシェルに載せるな」** であり、禁じている理由が違う — あちらはコストの二重払い、こちらは**テキストが実行されること**である。
 
 ### 何が起きるのか
 
@@ -15,18 +15,7 @@ zsh は `pnpm josh ms` を実行し、その標準出力を本文に埋め込む
 - **通知経路**: 置換結果が本文に混ざる。壊れ方が静かで、`followup` は正常終了する
 - **`gh` 経路**: 置換された結果が捨てられるのではなく、**コマンドとして実行される**
 
-### 実測 — 発火するのは `` ` `` と `$` であって `!` ではない
-
-本リポジトリの実行環境（非対話 zsh）で確かめた結果は次のとおりである。
-
-| 文字            | 二重引用符の中で                                     |
-| --------------- | ---------------------------------------------------- |
-| `` ` ``         | **発火する**（コマンド置換）                         |
-| `$`             | **発火する**（変数展開）                             |
-| `!`             | 発火しない（履歴展開は非対話では無効）               |
-| `\$` / `` \` `` | 発火しない（直前のバックスラッシュがリテラル化する） |
-
-`!` は引き金に入れていない。理由は `docs/maintainers/shell-body-rationale.md` → "Why `!` is not a trigger"。
+**発火するのは `` ` `` と `$` であって `!` ではない**（実測表は `docs/maintainers/shell-body-rationale.md` → "Why `!` is not a trigger"）。
 
 ### 安全な書き方
 
@@ -58,13 +47,4 @@ pnpm josh notify --task-type confirmation --issue-url "<url>" --body-file <path>
 
 ### 引き金つき配送
 
-`pnpm josh rule:guard` が、二重引用符の本文値にバッククォートか `$` が実際に含まれる `Bash` 呼び出しを拒否して本文を突きつける。拒否されたら本文をファイルに移して出し直す。配線は `docs/maintainers/shell-body-rationale.md` → "Why it is a triggered delivery"、引き金の設計は `docs/maintainers/shell-body-rationale.md` → "Why the trigger reads the body, not the flag"、固定しているテストは `docs/maintainers/shell-body-rationale.md` → "Marker tests"にある。
-
-### 引き金が見えないもの
-
-- **node の中から REST で投稿する経路**（`pnpm josh propagate` など）はシェル文字列に現れない
-- **`gh api --input <file>`** は本文がファイルにあるため、そもそも安全である
-- **`-b`（GitHub CLI の `--body` の短縮形）は覆っていない** — 同じ綴りが `git checkout -b` のブランチ名でもあり、そこで拒否するのは誤ったターンでの発火になる
-- **`-f title="…"`** は覆っていない。タイトルは英語へ正規化された短い語であり、バッククォートを含む運用がない
-
-引き金が見えない綴りでも規則は同じく拘束する。フックが走らないエージェントも同じである。
+`pnpm josh rule:guard` が、二重引用符の本文値にバッククォートか `$` が実際に含まれる `Bash` 呼び出しを拒否して本文を突きつける。拒否されたら本文をファイルに移して出し直す。**引き金が見えない綴り（`-b`・`-f title=` など）でも、フックが走らないエージェントでも規則は同じく拘束する。** 配線と見えない綴りの一覧は `docs/maintainers/shell-body-rationale.md` → "Why it is a triggered delivery"、引き金の設計は `docs/maintainers/shell-body-rationale.md` → "Why the trigger reads the body, not the flag"、固定しているテストは `docs/maintainers/shell-body-rationale.md` → "Marker tests"。

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

@@ -1,6 +1,6 @@
 # 独立した呼び出しは同じターンに載せる（joshuafolkken/kit#1304）
 
-`CLAUDE.md` →「Put every call that does not depend on another's result in the same turn」の正典。**常駐側にはトリガと判断基準の 1 行だけが残り、規則本文は `pnpm josh batch:guard` が効く瞬間に配送する**（joshuafolkken/kit#1524、`rule-delivery.md`、`docs/maintainers/turn-batching-rationale.md` → "Why it left residency (joshuafolkken/kit#1524)"）。実測・却下した機構案・経緯は `docs/maintainers/turn-batching-rationale.md` にある。
+「独立した呼び出しは同じターンに載せる」規則の正典。**常駐側には [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」への導線だけが残り、規則本文は `pnpm josh batch:guard` が効く瞬間に配送する**（joshuafolkken/kit#1524、`docs/maintainers/turn-batching-rationale.md` → "Why it left residency (joshuafolkken/kit#1524)"）。実測・却下した機構案・経緯は `docs/maintainers/turn-batching-rationale.md` にある。
 
 ## 何を求めているか
 
@@ -23,24 +23,15 @@
 
 ## ガードが見えないところ — ここでは自分で規則を当てる
 
-ガードは閉じた履歴（結果が返ったターンの並び）から判定し、共有ターゲットを持つ呼び出しは依存とみなして止めない。機構は `docs/josh-commands-automation.md` →「`josh batch:guard`」、却下した案は `docs/maintainers/turn-batching-rationale.md` → "Rejected mechanisms"、範囲が広がった経緯は `docs/maintainers/turn-batching-rationale.md` → "How the guard's scope grew"。
-
-- **いま中断しているターンの中身は見えない。** 同じターンの編集の先頭だけが拒否されることがあるが、壊れるのではなく失敗する — 再発行は本文に一致するか、一致せず報告される
-- **ファイル全体を書き出す `Write` は拒否しない**（再発行が兄弟の編集を上書きしうるため）
-- **`pnpm josh …` は読み取り専用の allow-list（`READ_JOSH_SUBCOMMANDS`）だけが bundleable** — 書き込む・送信するサブコマンドと、連鎖した行（`&&` / `|` / `>`）は通常判定に落ちる
-- **ツールを呼ばないターンと、ガードが `off` のレーン子** — 下の計測と合成コマンドが受け持つ
+中断中のターン・`Write`・書き込む `josh` サブコマンドや連鎖した行・ツールを呼ばないターン・ガードが `off` のレーン子は、ガードが止めない。止められなくても規則は同じく拘束する。一覧と機構は `docs/maintainers/turn-batching-rationale.md` → "Where the guard cannot see"、却下した案は `docs/maintainers/turn-batching-rationale.md` → "Rejected mechanisms"、範囲が広がった経緯は `docs/maintainers/turn-batching-rationale.md` → "How the guard's scope grew"。
 
 ## 事後の計測 — 実行タイミングレポートの `Round trips:`
 
-強制の代わりに、結果が毎回の計測に出る。**round trip は 1 ターンがまとめて出した呼び出しのかたまり 1 つ**で、しきい値 1.50 呼び出し/往復を下回ると 1 行の指摘が出る。`tool-less turns` はツールを 1 つも呼ばなかったターン数で、`batch:guard` が拒否できない発話だけのターンは自分で減らす。実装は `scripts/time-runtime/time-round-trips.ts`、詳細は `docs/josh-commands.md` の `time` の項、読み方と実測は `docs/maintainers/turn-batching-rationale.md` → "Reading the round-trip measurement"。
+**round trip は 1 ターンがまとめて出した呼び出しのかたまり 1 つ**で、しきい値 1.50 呼び出し/往復を下回ると 1 行の指摘が出る。`tool-less turns`（発話だけのターン）は自分で減らす。実装は `scripts/time-runtime/time-round-trips.ts`、読み方と実測は `docs/maintainers/turn-batching-rationale.md` → "Reading the round-trip measurement"。
 
 ## 実装中の独立編集に効く合成コマンド（joshuafolkken/kit#2202）
 
-レーン子ではガードが `off` なので、`Read` → `Edit` の交互の並びは誰にも止められない。**Step 0 が対象ファイルを列挙した時点で、`pnpm josh read:files <path> …` で読み取りを 1 回に畳み、続く別ファイルへの編集を 1 ターンに載せる**（`report-format.md` が導く）。書き込みは `pnpm josh edit:files` で畳む（joshuafolkken/kit#2366） — プランを 1 呼び出しで適用し、`old` が 1 箇所に一致しなければ拒否する。形式は `docs/josh-commands-run.md` →「`josh read:files`」と「`josh edit:files`」、経緯は `docs/maintainers/turn-batching-rationale.md` → "The composite commands"。
-
-## ガード発火時にも合成コマンドを手渡す（joshuafolkken/kit#2311）
-
-単発の読み取り（2 件以上）の連続でガードが発火すると、通知はそれを畳む `pnpm josh read:files` を貼り付け可能な形で渡す。単発 `Edit` の連続では、それらのファイルにわたる `pnpm josh edit:files` を添える（プラン本体はモデルが書く）。渡されたら、その 1 呼び出しで出し直す。
+**Step 0 が対象ファイルを列挙した時点で、`pnpm josh read:files <path> …` で読み取りを 1 回に畳み、続く独立した編集は `pnpm josh edit:files` の 1 呼び出しで送る**（`report-format.md` が導く。`old` が 1 箇所に一致しなければ拒否される）。ガードが発火して `read:files` / `edit:files` を手渡したら、その 1 呼び出しで出し直す。形式は `docs/josh-commands-run.md` →「`josh read:files`」と「`josh edit:files`」、経緯は `docs/maintainers/turn-batching-rationale.md` → "The composite commands"。
 
 ## マーカーテスト
 

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

@@ -2,9 +2,9 @@
 
 **単一ソースはこのファイルである。**
 
-**この規則は常駐していない — 引き金つき配送に移った**（joshuafolkken/kit#1524）。`pnpm josh rule:guard` が Issue を作成する `Bash` 呼び出し（`pnpm josh issue:file`。`gh issue create` や `…/issues` への `title` 付き POST による直接起票は `direct-filing` が毎回拒否する）を拒否し、そこで数え方・拒否・2 つの免除・免除を決める 3 条件を突きつける。起票が無いターンでは何も起きず、それは上限に触れる行為が無いということである。配送は**ラン 1 回につき 1 度**なので、数えたうえで同じ呼び出しをもう一度出せばよい。機構と列挙表は `rule-delivery.md`、配送文の実体は `scripts/rules/wip-cap.ts` の `WIP_CAP_REASON` にある（固定するテストは `docs/maintainers/wip-cap-rationale.md` → "Tests that pin the wording"）。
+**この規則は常駐しておらず、配送もされない — 起票するコマンドそのものが守らせる**（joshuafolkken/kit#1524 で常駐を外し、その後 `rule:guard` の配送行も外した）。`pnpm josh issue:file` が起票の前に件数を数え、上限を超えて免除が無ければ何も送らずに保留し、そこで拒否・2 つの免除・免除を決める 3 条件を印字する（`gh issue create` や `…/issues` への `title` 付き POST による直接起票は `direct-filing` が毎回拒否するので、起票は必ずこのコマンドを通る）。事前の拒否と出し直しの往復は無い。保留文の実体は `scripts/issue/issue-wip.ts` の `HELD_MESSAGE` にある（固定するテストは `docs/maintainers/wip-cap-rationale.md` → "Tests that pin the wording"）。
 
-背景・測定・経緯は保守者向けの `docs/maintainers/wip-cap-rationale.md` にあり、ラン中に読む必要はない。
+背景・測定・経緯は保守者向けの文書にあり（上限が要る理由は `docs/maintainers/wip-cap-rationale.md` → "Why a cap is needed — the measurement"）、ラン中に読む必要はない。
 
 ## 規則
 
@@ -12,16 +12,10 @@
 
 **件数は `pnpm josh issue:file` が起票の前に数える**（joshuafolkken/kit#3181）。手で数えることも、見積もりや記憶で済ませることもない。数え方・印字・保留の詳細は `docs/josh-commands-backlog.md` → "`josh issue:file`" にある。
 
-- **上限は 30。** これを超える 1 件を作る前に 1 件閉じる。エージェントが読む文書（`CLAUDE.md`・`prompts/`・配布 skill）がこの数字を書くのはこの行だけで、一次情報は `scripts/rules/wip-cap.ts` の `WIP_CAP` である（一致はテストが固定する）。
+- **上限は 30。** これを超える 1 件を作る前に 1 件閉じる。エージェントが読む文書（`CLAUDE.md`・`prompts/`・配布 skill）がこの数字を書くのはこの行だけで、一次情報は `scripts/issue/issue-wip.ts` の `WIP_CAP` である（一致はテストが固定する）。
 - コマンドは起票先（`--repo` を付ければそのリポジトリ）のオープン Issue を epic も含めて数え、`wip:` 行に件数・上限・判定を印字する。上限を超えて免除が宣言されていなければ**何も送らずに保留し、免除の問いを印字する**。
 - **免除を宣言するのはこのファイルの判断である** — `--route interrupt`（下の 3 条件）、`--route split` / `--route tier-a`（実行が詰まる起票）はルートそのものが宣言になる。ルートの無い実行が詰まる起票（利用者が `new` と打った入口など）は `--over-cap` を付けて出し直す。裁量起票（`--route review-cap` を含む）に `--over-cap` を付けてはならない。
 
-## なぜ上限が要るのか
-
-測定は `docs/maintainers/wip-cap-rationale.md` → "Why a cap is needed — the measurement"。
-
-**上限は、増加を見えるようにするための強制装置である。** 数を減らすこと自体が目的ではない。上限を超えた状態で起票しようとしたときに「本当にこれは 1 件増やす価値があるか」を必ず 1 回考えさせる、そこだけが役割である。
-
 ## 超過時の手順
 
 起票しようとした時点で上限を超えていたら、**その起票が裁量によるものか、実行がそれに詰まっているか、割り込みか**の 3 つに分岐する。判断ではなく、起票の種類で決まる。**上限が効くのは裁量側だけである。**
@@ -46,7 +40,7 @@
 
 ### 割り込み起票 — 上限が効かない側（3 条件で機械的に決める）
 
-**重大な欠陥の発見は、それが現在のランを止めていなくても捨ててはならない。** 上限の目的は増加を見えるようにすることであって、**発見を捨てることではない**（上の「なぜ上限が要るのか」）。由来は `docs/maintainers/wip-cap-rationale.md` → "Where the interrupt category comes from"。
+**重大な欠陥の発見は、それが現在のランを止めていなくても捨ててはならない。** 上限の目的は増加を見えるようにすることであって、**発見を捨てることではない**（`docs/maintainers/wip-cap-rationale.md` → "Why a cap is needed — the measurement"）。由来は `docs/maintainers/wip-cap-rationale.md` → "Where the interrupt category comes from"。
 
 **別パッケージ起因の割り込みとは別の区分である。** あちらは上流リポジトリへ起票して停止する手順（`upstream-interrupt.md`、`route:tier-a`）で、実行が詰まる側に属する。ここで言う割り込みは、**このリポジトリの欠陥で、発見したランをブロックしていないもの**を指す。
 
@@ -76,4 +70,4 @@
 
 **起票と、実行されるようにするところまでが 1 つのまとまりである。** epic の下にある割り込みを起票だけして追加しなければ、`epic:next` はそれを候補にすら出さない — Issue は残るが実行されないという、コメントに埋もれるのと大差ない状態になる。**epic の外にある割り込みでは、まとまりの後半は 4 の報告そのもの**であり、打つべきコマンドを利用者に渡すまでが 1 回の行為である。上の「ひとまとまりで判定する」がここにも効く。
 
-**割り込みをバッチの中で単独で走らせるか、並列のレーンで走らせるか**は `.claude/skills/workflow-commands/backlogrun-lanes.md` → "Lanes — running more than one child at a time" が単一ソースである（理由は `docs/maintainers/wip-cap-rationale.md` → "Why a solo run"）。上限の数字の変え方は `docs/maintainers/wip-cap-rationale.md` → "Changing the cap itself"、上限が分割判定・レビュー上限と一緒に動く理由は `docs/maintainers/wip-cap-rationale.md` → "The three move together"と `docs/maintainers/wip-cap-rationale.md` → "Why the three landed in one commit"にある。
+**割り込みをバッチの中で単独で走らせるか、並列のレーンで走らせるか**は `.claude/skills/workflow-commands/backlogrun-lanes.md` → "A solo run" が単一ソースである（理由は `docs/maintainers/wip-cap-rationale.md` → "Why a solo run"）。上限の数字の変え方は `docs/maintainers/wip-cap-rationale.md` → "Changing the cap itself"、上限が分割判定・レビュー上限と一緒に動く理由は `docs/maintainers/wip-cap-rationale.md` → "The three move together"と `docs/maintainers/wip-cap-rationale.md` → "Why the three landed in one commit"にある。

package/prompts/refactoring.md

@@ -87,7 +87,7 @@ lint が完全に検出できる項目は `pnpm josh refactor:scan` が件数と
 ## 基本方針
 
 - **構造変更の前にテストを書く**: リファクタリング実施前に、対象のふるまいを検証する unit/E2E テストを先に実装し、グリーンを確認する。デグレを防ぐための安全網として機能する
-- **可読性・保守性をパフォーマンスより優先**する
+- **可読性・保守性・パフォーマンス・AI コストは同列で、どれも悪化させない**（`prompts/collaboration-workflow/principles.md` → "quality-priority"）
 - コードクローンの排除・メソッド抽出・共通コンポーネント化は必ず分析・提案に含める
 - **提案しないパターン**: `async () => await fn()` → `() => fn()` への簡素化は行わない
 - 提案が特にない場合は、無理に提案しない

package/prompts/review-rubric.md

@@ -129,36 +129,17 @@ Example: `No issues — checked null returns on X, verified Y edge case, Z is gu
 `No issues` is only acceptable for Security, Performance, i18n, and Comments when there is genuinely
 nothing to check (no auth code, no hot paths, no user strings, no comments touched).
 
-Template:
+Template — one `###` heading per category, in the order of "Review categories" below, then
+`### Summary`:
 
 ```md
 ### Bug risks & logic errors
 
 - `src/foo.ts:42` (high) — <problem> — <fix>
 
-### Security
-
-No issues — no auth code, no user input, no unsafe casts in diff.
-
-### Performance
-
-No issues — no loops, no reactive chains, no I/O on request paths.
-
 ### Project conventions
 
-No issues — verified snake_case, no arrow functions, no magic numbers, i18n covered.
-
-### i18n
-
-No issues — no user-visible strings added.
-
-### Tests
-
-- `e2e/foo.test.ts:15` (medium) — assertion does not fail if implementation is inverted — rewrite to verify X not just that code runs
-
-### Comments & content
-
-No issues
+No issues — `parse_ids` returns what its name says; no near-copy of `split_ids` added; tests sit beside the source.
 
 ### Assumptions audit
 

package/prompts/review.md

@@ -29,35 +29,18 @@ is a verification pass over the fixes, not the first review again
 
 ## Review level (decided by `pnpm josh review:brief --level-only`, never by judgement)
 
-**Run `pnpm josh review:brief --level-only` and use what it prints.** It reads the changed paths and
-answers `low` or `medium`; `--staged` classifies the staged diff instead of the branch diff, and
-`--json` adds the reason. Inside a workflow, `pnpm josh review:brief` prints the same level on its first
-line and the rest of the brief with it.
+**Run `pnpm josh review:brief --level-only` and use what it prints** — `low` or `medium`, from the
+changed paths and nothing else, never "this one is small". `--staged` classifies the staged diff,
+`--json` adds the reason; inside a workflow `pnpm josh review:brief` prints the same level on its first
+line. A `low` change gets 1 round, a `medium` one up to 2 (the cap below). How the answer is derived —
+the inert paths, documentation at `medium`: `docs/maintainers/review-history.md` → "The level is
+decided from the changed paths".
 
 ```bash
 pnpm josh review:brief --level-only            # the branch diff
 pnpm josh review:brief --level-only --staged   # the staged diff
 ```
 
-**The level is decided from the changed paths and nothing else** — never "this one is small"
-(`docs/maintainers/review-history.md`).
-
-| Every changed path is…                                                                   | Level    | Rounds                  |
-| ---------------------------------------------------------------------------------------- | -------- | ----------------------- |
-| **inert** — `.editorconfig`, `.gitignore`, `LICENSE`, `CHANGELOG.md`, `*.code-workspace` | `low`    | 1                       |
-| anything else                                                                            | `medium` | up to 2 (the cap below) |
-
-**One non-inert path decides the whole change.** A review reads the change, not a subset of it, so
-there is no per-file level. An empty diff also takes `medium` — answering `low` to "nothing changed"
-would hand a reduced level to a caller that failed to read the diff.
-
-**Three things that look inert are not.** `.vscode/**`, `.gitattributes` and `.prettierignore` are all
-in `package.json`'s `files` and are written into every consumer project by `josh init` / `josh sync`,
-so a defect in one reaches a consumer and is reviewed at `medium` like any other shipped file.
-
-**Documentation is not inert either.** `CLAUDE.md`, `prompts/**`, `.claude/**` and `docs/**` are all
-reviewed at `medium`, though exempt from _testing_: a reader is the only detector a prose defect has.
-
 **A confirmed High blocks regardless of round count**, and the round cap below does not change that.
 
 ---
@@ -95,16 +78,10 @@ round-1 High/Medium finding actually closed — by a fix in this working tree, o
 positive — and none was filed or deferred. **Without the flag the answer is `required`**, which is also
 what the command answers to every uncertainty it meets, a missing round-1 snapshot included.
 
-**`skip` has exactly two arms, and both are states in which round 1's fix code needs no review**:
-
-| Arm                    | What it is                                                                                                                   |
-| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
-| **A — no fix code**    | The fix delta is empty: round 1's findings closed without an edit, so there is no unreviewed fix code                        |
-| **B — inert fix code** | Every path in the fix delta is inert by the review-level classification above — neither executing, instructing, nor shipping |
-
-**Neither arm weakens the standard.** A round-1 High/Medium that did not close is not a closed finding,
-so the flag is not passable; the cap is still two rounds; and a confirmed High still blocks the merge.
-A documentation-only fix delta is not inert, so a prompt fix answers `required`.
+**`skip` has exactly two arms** — **A** (no fix code: the fix delta is empty) and **B** (inert fix
+code: every path in the fix delta is inert by the review-level classification above); the reason line
+names which fired. Why neither weakens the standard: `docs/maintainers/review-history.md` → "The two
+skip arms".
 
 **A skipped round is recorded on the Issue**, so the condition stays auditable and can be withdrawn if
 a defect is later traced to a skipped delta:
@@ -158,11 +135,11 @@ Only branch 2 files an Issue. What follows applies to that branch.
   `pnpm josh git -y` and before `pnpm josh followup`; where it does not — `halfrun`, or a standalone
   pre-commit self-review — they run as soon as the disposition is decided. **The chain may run in a
   delegated unit** — `pnpm josh delegate followup-filing`.
-- **When the round files a second follow-up, run `pnpm josh issue:fold` first.** Several findings from
-  one review fold into one Issue by default — the filing-time counterpart to the split assessment,
-  reading the same two questions (`.claude/skills/workflow-commands/split-assessment.md` → "The same
-  two questions decide the filing-time fold"). `pnpm josh rule:guard` refuses the second
-  `pnpm josh issue:file` call until it is folded; the first filing asks nothing.
+- **A second follow-up from one round folds into the first by default.** Several findings from one
+  review fold into one Issue — the filing-time counterpart to the split assessment, reading the same
+  two questions (`.claude/skills/workflow-commands/split-assessment.md` → "The same two questions
+  decide the filing-time fold"). `pnpm josh issue:file` asks the fold question itself on the run's
+  second filing and holds a `fold`; the first filing asks nothing.
 
   1. File the follow-up Issue referencing the current one, tagged `route:review-cap` — **before the current Issue closes.**
      `pnpm josh issue:file "<title>" --body-file <body-file> --depth <n> --route review-cap`.

package/prompts/testing-guide.md

@@ -56,12 +56,10 @@ There is exactly **one** convention for every test file — never choose between
 | Component / browser | `*.svelte.test.ts`       | browser/component vitest project |
 | E2E                 | `src/routes/**/*.e2e.ts` | Playwright                       |
 
-- **Use `*.test.ts` — never `*.spec.ts`.** The `.spec.ts` suffix is forbidden for unit/integration tests. This is **lint-enforced**: the test-filename rule building blocks (`eslint/rules/test-filename.js`) are wired into `eslint/base.js` itself, so every project built on `create_base_config` — kit included, since joshuafolkken/kit#1233 — flags any `*.spec.*` file, and any file under a top-level `tests/` directory, and fails `josh lint`. **Both bans cover every JS/TS extension** — `.ts` `.tsx` `.mts` `.cts` `.js` `.jsx` `.mjs` `.cjs` — since joshuafolkken/kit#1414; `.svelte` is deliberately outside them, because the base config has no Svelte parser and a `tests/Foo.svelte` would report a parse error instead of the move instruction. A config that does not use the base can still import the blocks alone, as `@joshuafolkken/kit/eslint/test-filename` — but **wire them through `extend_restricted_syntax(<your own rules>, SPEC_FILENAME_ENTRY)`**, because flat config replaces `no-restricted-syntax` rather than merging it, so the ready-made `spec_filename_rules` / `centralized_tests_directory_rules` records drop whatever selectors that config already restricted, on exactly the files the ban applies to (joshuafolkken/kit#1414). (A vitest `{test,spec}` matcher would still accept both, but the lint rule fails loudly before a stray `.spec.ts` can drift in.)
+- **Use `*.test.ts` — never `*.spec.ts`.** **Lint-enforced** by `eslint/rules/test-filename.js` (wired into `eslint/base.js`) for every JS/TS extension; how the ban is wired and why: `docs/maintainers/testing-guide-history.md` → "Why the `*.spec.*` ban is a lint rule".
 - **The `.svelte.` infix is required for component/browser tests and must be preserved.** `*.svelte.test.ts` routes the file to the **browser/component** vitest project (`include: src/**/*.svelte.{test,spec}.{js,ts}`); plain `*.test.ts` routes to the **node/unit** project (`include: src/**/*.{test,spec}.{js,ts}`). Renaming `Foo.svelte.test.ts` → `Foo.test.ts` silently moves it to the wrong project — do not drop the `.svelte.` infix.
 - **Colocate every test next to the code it exercises.** A top-level `tests/` directory is **not used** — place `foo.test.ts` beside `foo.ts`, and E2E specs under the relevant `src/routes/**` path. The top-level `tests/` ban is **lint-enforced** by the same rule (`eslint/rules/test-filename.js`). Note: `playwright.config.ts` discovers E2E via `testMatch: '**/*.e2e.{ts,js}'`, so an `*.e2e.ts` placed outside `src/routes/**` would still run — that specific `src/routes/**` placement is enforced by **convention/review, not config**, and must be upheld manually.
 
-> **Enforcement:** the `*.spec.ts` ban and the top-level `tests/` ban are enforced by the test-filename rule (`eslint/rules/test-filename.js`), wired into the shared `eslint/base.js`, so they fail loudly in `josh lint` for kit itself, for every consumer of that base config, and for every AI tool (`docs/maintainers/testing-guide-history.md`).
-
 ---
 
 ## 2. Test Guidelines
@@ -187,7 +185,7 @@ Decided by whether a pull request is open, never by judgement:
 
 | Situation                                                                                    | What closes the gate                                                                                             |
 | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
-| A pull request is open — `fullrun`, `backlogrun`                                             | The CI E2E job. `pnpm josh followup` waits for the checks and refuses to merge while any of them is non-passing. |
+| A pull request is open — `fullrun`, `prrun`, `backlogrun`                                    | The CI E2E job. `pnpm josh followup` waits for the checks and refuses to merge while any of them is non-passing. |
 | No pull request — `halfrun`'s stop before commit, a completion reported outside any workflow | `pnpm josh test:e2e`, run by **you**, output read by you.                                                        |
 
 **Never ask the user to run it, in either row.** A completion report is not allowed to depend on

package/scripts/adopt/adopt-logic.ts

@@ -6,7 +6,7 @@ import { self_sync_guard } from '#scripts/self-sync-guard/self-sync-guard-logic'
 import { KIT_PACKAGE_NAME } from '#scripts/version/kit-descriptor'
 
 // The decisions `josh adopt` makes before any step runs: whether this repository may adopt at all,
-// which repository the issue is opened in, and what the run is carrying (joshuafolkken/kit#1085).
+// which repository the issue is opened in, and what the run is carrying.
 
 const ADOPT_ORIGIN = 'Opened by `josh adopt` in this repository.'
 const INCOMPLETE_HEADLINE =
@@ -18,8 +18,8 @@ const MISPLACED_CAUSE =
 const ABSENT_CAUSE =
 	'no runnable CLI here; the package or its `node_modules/.bin` shim is missing. Run `pnpm install`.'
 
-// Adoption never runs inside kit's own repository — the same boundary `josh sync` draws
-// (joshuafolkken/kit#868), and for the same reason: the sync would overwrite the distribution source
+// Adoption never runs inside kit's own repository — the same boundary `josh sync` draws,
+// and for the same reason: the sync would overwrite the distribution source
 // with its own derived templates. Refused here, before anything writes, rather than left for the
 // sync to fail on halfway through the sequence.
 //
@@ -58,8 +58,8 @@ function name_causes(package_names: ReadonlyArray<string>, cause: string): Array
 	return package_names.map((package_name) => `  ${package_name} — ${cause}`)
 }
 
-// A declared toolkit that falls out of the plan is a refusal rather than a warning
-// (joshuafolkken/kit#1540). kit distributes the base files and every other toolkit overlays files
+// A declared toolkit that falls out of the plan is a refusal rather than a warning.
+// kit distributes the base files and every other toolkit overlays files
 // *derived* from them (`docs/maintainers/sync-rationale.md` → "The managed-workflow stamp"), so a run that syncs kit without the
 // overlay does not merely do less — it writes the overlay's paths back to kit's originals. That diff
 // then wears kit's own face in the pull request, which is exactly what a reviewer cannot spot.