@joshuafolkken/kit 1.1128.0 → 1.1166.0

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、下の「なぜ resident ではなく引き金つき配送に置くか」）。
+`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` にある。
 
 ## 何を求めているか
 
@@ -11,111 +11,37 @@
 - no → **その呼び出しは、依存していない他の呼び出しと同じターンに載せる**
 - yes → 結果を待つ。別のターンになるのが正しい
 
-依存していない呼び出しを 1 つずつ別のターンに出す形が、この規則が禁じているものである。ファイルを 3 つ読むために 3 ターン使う、同じファイルの離れた 3 箇所を直すために 3 ターン使う、`git status` と `pnpm josh issue:state` と `pnpm josh latest:scope` を 3 ターンに分ける — いずれも後続の入力が前の結果を使っていない。
-
-## なぜターン数が費用なのか
-
-**費用は仕事の量ではなく往復の回数にある。** joshuafolkken/kit#1295 の run（1,471 秒 / 153 ターン）で実測した:
-
-| 種別                                                             | 回数 | ツール実行時間の合計 |
-| ---------------------------------------------------------------- | ---: | -------------------: |
-| `Edit`                                                           |   34 |                48 秒 |
-| 読み取り系の小さな `Bash`（`grep` 12 / `sed` 11 / `cat` 4 ほか） |   32 |                 6 秒 |
-
-**ツール自体が動いていたのは合わせて約 54 秒**である。同じ 66 往復が消費した壁時計は 66 × 9〜13 秒 ≒ 600〜850 秒で、1 桁違う。1 ターンあたりの壁時計は 9〜13 秒の狭い帯に収まるので、**ターン数がそのまま run の下限を決めている。**
-
-ゲート短縮が run を縮めなかった経緯は `docs/maintainers/turn-batching-rationale.md` →「ゲートを削っても run が縮まなかった理由」。
+ファイルを 3 つ読むために 3 ターン使う、同じファイルの離れた 3 箇所を直すために 3 ターン使う、`git status` と `pnpm josh issue:state` を別ターンに分ける — いずれも禁じられた形である。**費用は仕事の量ではなく往復の回数にある。** 1 ターンの壁時計はほぼ一定なので、ターン数が run の下限を決める（実測は `docs/maintainers/turn-batching-rationale.md` → "Why the number of turns is the cost"）。
 
 ## 判断基準は「依存の有無」であって、呼び出しの種類ではない
 
-読み取りだけの規則ではない。**`Edit` も同じ規則の対象である** — 同じファイルの離れた領域や、別々のファイルへの編集は、互いの結果を使っていないので同じターンに載る（実測の内訳は `docs/maintainers/turn-batching-rationale.md` →「`Edit` が最大の単一項目だった理由」）。
-
-逆に、**依存があるなら分けるのが正しい。** 次はいずれも 1 つ前の結果を入力に使うので、同じターンに載せてはならない。
-
-- `grep` の結果を見てから、その行番号で `sed -n` を出す
-- `git switch` の成否を見てから `pnpm josh latest:scope` を出す
-- Edit の対象文字列を確かめるために先にファイルを読む（**Edit の前に読むことは省略できない**）
+**`Edit` も同じ規則の対象である** — 別々のファイルや同じファイルの離れた領域への編集は、互いの結果を使っていないので同じターンに載る。逆に、**依存があるなら分けるのが正しい**: `grep` の結果の行番号で `sed -n` を出す、`git switch` の成否を見てから次を出す、Edit の前に対象を読む（**Edit の前に読むことは省略できない**）。
 
 ## 検証ゲートとレビューは往復を減らす対象ではない
 
-**ゲート・レビュー・差分の読み取りを、往復を減らす名目で弱めてはならない。** これは joshuafolkken/kit#1304 の受け入れ条件そのものである。具体的には:
+**ゲート・レビュー・差分の読み取りを、往復を減らす名目で弱めてはならない。** `pnpm josh gate` の出力を絞って失敗の内訳を読まずに進む、`git diff main...HEAD` を一部だけ読んで「指摘なし」とする（`output-bounds.md`）、走らせるべきチェックを落とす — いずれも禁止。**往復を減らすのは「同じ仕事を少ないターンで出す」ことであって、「仕事を減らす」ことではない。**
 
-- `pnpm josh gate` の出力を絞り込んで読む、失敗の内訳を読まずに次へ進む — いずれも禁止
-- `git diff main...HEAD` を一部だけ読んでレビューを「指摘なし」と結論づける — 禁止（`output-bounds.md` →「切り詰められた出力を、完全な出力として読まない」と同じ理由）
-- 単発の再実行（`pnpm josh lint:related` / `pnpm josh test:related`）をまとめるために、走らせるべきチェックを落とす — 禁止
+## ガードが見えないところ — ここでは自分で規則を当てる
 
-**往復を減らすのは「同じ仕事を少ないターンで出す」ことであって、「仕事を減らす」ことではない。** 減らしてよいのはターンの数だけである。
+ガードは閉じた履歴（結果が返ったターンの並び）から判定し、共有ターゲットを持つ呼び出しは依存とみなして止めない。機構は `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"。
 
-## 機構で強制しない理由（却下した案）
-
-- **PreToolUse フックが「1 件の呼び出しだけを見て、それが独立かどうかを判定する」。** 採れない。**呼び出しの独立性は、1 件の呼び出しからは観測できない。** フックが見るのはこれから走る 1 件だけで、それが直前の結果に依存しているかどうかはフックの入力に無い。依存している正当な直列実行（`grep` → `sed -n`、Edit の前の読み取り）を止めてしまい、しかも止めた側は理由を説明できない。`output-bounds.md` が「形で見分ける案は実データ上で外れる」として PreToolUse guard を却下したのと同じ形である。
-
-  **却下したのはこの判定のしかたであって、`PreToolUse` という機構そのものではない。** joshuafolkken/kit#1390 は**まさに `PreToolUse` フックとして** `pnpm josh batch:guard` を実装し、`.claude/settings.json` で配布している。判定に使うのは、いま出そうとしている 1 件ではなく**閉じた履歴** — 結果が返り終わったターンの並び — である。単発呼び出しのターンが 2 つ続いたことは 1 件からは見えないが、履歴からは見える。上に並べた懸念は、それぞれ設計で避けてある。依存は**共有ターゲット**で見るので `grep` → `sed -n` は止まらず、**書き込みも読み取りとまったく同じ基準で拒否され**（joshuafolkken/kit#1762）、**手元の呼び出しが直前の列と共有ターゲットを持つときは拒否を取り下げる**（書き込み同士を含む）。拒否は 1 つの単発連続につき **1 回だけ**である（窓を超える連続は `docs/maintainers/turn-batching-rationale.md` →「`batch:guard` の拒否窓」）。委譲された子やレビューエージェントは、親の記録を共有せず、それぞれに配送される（`docs/maintainers/turn-batching-rationale.md` →「フォークへの配送の実装（joshuafolkken/kit#1424）」）。機構の全体は `docs/josh-commands-automation.md` →「`josh batch:guard`」にある。範囲が `Bash|Edit|Read` に広がった経緯（joshuafolkken/kit#1509 を含む）は `docs/maintainers/turn-batching-rationale.md` →「書き込みが範囲に入った経緯（joshuafolkken/kit#1762）」、`docs/maintainers/turn-batching-rationale.md` →「読み取りが範囲に入った経緯（joshuafolkken/kit#1798）」、`docs/maintainers/turn-batching-rationale.md` →「事務コマンドが範囲に入った経緯（joshuafolkken/kit#1875）」。
-
-  **ガードが見えないところ — ここでは自分で規則を当てる。**
-
-  - **塞ぎきれないのは「いま中断しているターンの中身」であり、これは transcript から観測できないので設計上残る。** 同じファイルへの編集 3 件を 1 ターンにまとめた場合、先頭だけが拒否され残り 2 件が適用されることはある。**ただし壊れるのではなく失敗する** — 再発行された編集は書いたときの本文に一致するか、一致せずに報告されるかのどちらかである。
-  - **ファイル全体を書き出す `Write` だけは拒否しない。** 再発行された `Write` は本文を照合しないので、そのターンの兄弟が適用した編集を無言で上書きしうる。根拠は `docs/maintainers/turn-batching-rationale.md` →「中断中のターンと `Write` の除外の根拠」。
-  - **連続を切るのは「そもそもまとめられない呼び出し」、すなわち結果を次の呼び出しが必要とする委譲である。**
-  - **`pnpm josh …` は読み取り専用サブコマンドの allow-list（`READ_JOSH_SUBCOMMANDS`）に載るものだけが bundleable である。** 書き込む・外部送信するサブコマンド（`run:progress --mark` はマーカーを書き、`notify` は送信し、`main:sync` / `epic` / `run:hold` は状態を書く）は allow-list に**入れない**。連鎖した行（`&&` / `|` / `>` など）は、先頭の `pnpm` が後続の変更を隠すため読みとしては信用せず、通常判定に落とす。
-  - ツールを 1 つも呼ばないターンと、ガードが `off` のレーン子 — それぞれ下の「事後の計測」と「実装中の独立編集に効く合成コマンド」。
-
-- **複数編集を 1 呼び出しにまとめるツールを前提にする。** 前提にできない。この repository が対象とする harness には常に存在するとは限らず、存在しない側では規則が一度も発火しない。`pnpm josh` はどの harness にも存在するので、書き込みは合成コマンド `pnpm josh edit:files` で畳む（下節）。経緯は `docs/maintainers/turn-batching-rationale.md` →「複数編集ツールの前提を joshuafolkken/kit#2366 が反証した経緯」。
-- **ターンごとに件数の下限を課す。** 却下。依存が連続する区間では 1 件が正しい答えであり、下限は正しい振る舞いを罰する。上限も下限も持たないのが正しく、**代わりに事後の計測を置く**（次節）。
-
-harness 側の一般的な指示（「依存のない呼び出しは同じブロックで出す」）は**すでに存在していて、実測では発火していなかった** — 4 本の run で 1 往復あたり 1.13 / 1.04 / 1.03 / 1.00 呼び出し。帰結は `docs/maintainers/turn-batching-rationale.md` →「一般指示が発火しなかったことの帰結」。
+- **いま中断しているターンの中身は見えない。** 同じターンの編集の先頭だけが拒否されることがあるが、壊れるのではなく失敗する — 再発行は本文に一致するか、一致せず報告される
+- **ファイル全体を書き出す `Write` は拒否しない**（再発行が兄弟の編集を上書きしうるため）
+- **`pnpm josh …` は読み取り専用の allow-list（`READ_JOSH_SUBCOMMANDS`）だけが bundleable** — 書き込む・送信するサブコマンドと、連鎖した行（`&&` / `|` / `>`）は通常判定に落ちる
+- **ツールを呼ばないターンと、ガードが `off` のレーン子** — 下の計測と合成コマンドが受け持つ
 
 ## 事後の計測 — 実行タイミングレポートの `Round trips:`
 
-強制の代わりに、**結果が毎回の計測に出る。**
-
-```
-Round trips:
-  tool calls                    104   over 153 turn(s)
-  round trips                   104   1.00 calls per round trip
-  ⚠ independent calls are going out one per turn (floor 1.50 calls per round trip)
-```
-
-- **round trip は「1 ターンがまとめて出した呼び出しのかたまり」1 つ**であって、呼び出し 1 件ではない。まとめて出せば呼び出し数はそのままで往復だけが減る — つまりこの数字は、仕事を減らさずに費用だけ下げたかどうかを直接見せる
-- **しきい値は 1.50 呼び出し/往復。** 下回ると 1 行の指摘が出る。少しでもまとめている run は超えるので、これは程度を採点するのではなく**まとめていないこと**を検出する
-- **`tool-less turns` の行は、ツールを 1 つも呼ばなかったターン数**（`turn_count − round_trips`、joshuafolkken/kit#1875）。`batch:guard` は発話だけのターンを拒否できない — 呼ぶツールが無く `PreToolUse` が発火しないので、唯一の梃子がこの事後計測である。`Bundling:` はこれを構造上見られない（まとめる対象を持たないターンは列に入らない）。発話だけのターンは自分で減らす（実測は `docs/maintainers/turn-batching-rationale.md` →「`tool-less turns` の実測」）
-- 実装は `scripts/time-runtime/time-round-trips.ts`、詳細は `docs/josh-commands.md` の `time` コマンドの項
+強制の代わりに、結果が毎回の計測に出る。**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"。
 
 ## 実装中の独立編集に効く合成コマンド（joshuafolkken/kit#2202）
 
-**フックが届かない一区間が残っていた — レーン子の実装中の独立編集である。** レーン子（headless `claude -p`）ではガードが `off` なので（#2178）、別々のファイルへ `Read` → `Edit` を交互に出す並びは誰にも止められない。経緯は `docs/maintainers/turn-batching-rationale.md` →「合成コマンドに至った経緯（joshuafolkken/kit#2202）」。
-
-**しかし 1 手前に確定している — Step 0 が変更ごとに対象ファイルを列挙する。** `pnpm josh read:files` はその点で読み取りを畳む合成コマンドである。`report-format.md` が Step 0 の継ぎ目（`josh lines` の隣）でランをここへ導く**手順**である。
-
-**梃子の本体は読み取りと編集の脱交互化（de-interleave）。** 交互の並びで編集を分けているのは直前の読み取りへの依存で、読み取りを 1 回に畳めば続く別ファイルへの編集は互いにも直前の読み取りにも依存せず 1 ターンに載る。#2178 の並び — `Read A` / `Edit A` / `Read B` / `Edit B` … の **9 ターン** — が、`read:files A B C D` → `Edit A` ＋ `Edit B` ＋ `Edit C` ＋ `Edit D` の **2 ターン**になる。
-
-上限超過時は `read:files` が「Read ツールで 1 ターンにまとめて読め」と返しフォールバックでも読み取りは畳まれたまま。詳細は `docs/josh-commands-automation.md` →「`josh read:files`」。
-
-書き込みは `pnpm josh edit:files` で畳む（joshuafolkken/kit#2366） — 編集を **プラン（`=====` のパスヘッダ＋ git conflict マーカー対）** として受け取り 1 呼び出しで適用し、各編集は content-addressed なので `old` が 1 箇所に一致しなければ拒否して報告する。#2493 で `-`（標準入力）を受け、依存編集は `dependent` で拒否する。詳細は `docs/josh-commands-automation.md` →「`josh edit:files`」。
+レーン子ではガードが `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-automation.md` →「`josh read:files`」と「`josh edit:files`」、経緯は `docs/maintainers/turn-batching-rationale.md` → "The composite commands"。
 
 ## ガード発火時にも合成コマンドを手渡す（joshuafolkken/kit#2311）
 
-ガードが**単発の読み取り連続**で発火したとき、通知はその読み取りを畳む `pnpm josh read:files <path> …` を貼り付け可能な形で手渡す — モデルが 1 ターンで確実に出せる単一の呼び出しである。経緯は `docs/maintainers/turn-batching-rationale.md` →「ガード通知に合成コマンドを載せた経緯（joshuafolkken/kit#2311）」。
-
-**読み取りに限り、2 件以上のときだけ。** 書き込みは `read:files` の対象外なので除外し、読み取り 1 件は既に単発なので畳むものがない。
-
-**書き込み側も同じ地点で手渡す（joshuafolkken/kit#2366）。** 単発 `Edit` の連続でガードが発火したとき、通知はその編集を名指し、それらのファイルにわたる `pnpm josh edit:files` の畳み込みを添える（`write_fold_directive`）。読み取りはパスだけで畳めるが編集は本文を伴うので、貼り付け可能なのはコマンドとファイル名までで、プラン本体はモデルが書く — それでも並列 `tool_use` ブロックではなく 1 ターンで出せる単一呼び出しに落ちる。`Edit` だけを数え、content-address できない `Write`（既に独自の通知を持つ）は除く。
-
-## なぜ resident ではなく引き金つき配送に置くか（joshuafolkken/kit#1524）
-
-**この規則は常駐から外れている。** `pnpm josh batch:guard` が、単発呼び出しのターンが 3 つ続いた次の呼び出し（`Bash` / `Edit` / `Read`）を拒否し、そこで規則本文を突きつける — 規則が効く瞬間そのものである。配送の判定基準と機構は `rule-delivery.md` にある。
-
-常駐から外した根拠は `docs/maintainers/turn-batching-rationale.md` →「常駐から外した根拠（joshuafolkken/kit#1524）」。
-
-**引き金が発火しないターンでは何も起きず、それが正しい。** 発火しないということは往復あたりの呼び出し数が下限（1.50）を上回っているということであり、規則が守られている状態と一致する。
-
-配送文（`scripts/time-runtime/time-batch-guard.ts` の `REASON`、および `time-density.ts` の実行時 1 行）が運ぶのは次の 2 点である。常駐側に残していたのと同じ内容であり、削っていない。
-
-1. 別の呼び出しの結果に依存しない呼び出しは、同じターンに載せる
-2. 判断基準は「依存の有無」であって呼び出しの種類ではない（読み取りも編集も同じ）。かつ、往復を減らすことは仕事を減らすことではない
-
-実測値・却下した機構案・計測の読み方はこのファイルと `docs/maintainers/turn-batching-rationale.md` にあり、配送文からは落としている。
+単発の読み取り（2 件以上）の連続でガードが発火すると、通知はそれを畳む `pnpm josh read:files` を貼り付け可能な形で渡す。単発 `Edit` の連続では、それらのファイルにわたる `pnpm josh edit:files` を添える（プラン本体はモデルが書く）。渡されたら、その 1 呼び出しで出し直す。
 
 ## マーカーテスト
 
-`scripts/rules/turn-batching-rule.test.ts` が固定する。内訳は `docs/maintainers/turn-batching-rationale.md` →「マーカーテストが固定するもの」。
+`scripts/rules/turn-batching-rule.test.ts` が固定する。内訳は `docs/maintainers/turn-batching-rationale.md` → "What the marker test pins"。

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

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

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

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

package/prompts/collaboration-workflow.md

@@ -8,7 +8,7 @@
 
 **これは人間が読むための索引であり、規則を定める場所ではない。** 常駐の引き金は `CLAUDE.md` に、実行中の操作手順は `.claude/skills/workflow-commands/` に、各話題の規則は下の表のファイルにあり、それぞれが自分の規則の一次情報である。この索引はそれらを言い直さない。
 
-**話題ごとにファイルが分かれている。** 以前はこの内容が 1 本の 169KB のファイルにあり、1 つの節を確かめるだけでも全体を読む必要があった。読んだものはそのセッションの残り全ターンで積み上がった前置きとして課金され続けるため、確認 1 回の費用が会話の長さに比例して効いていた（joshuafolkken/kit#965）。**必要な 1 本だけを開くこと。この索引を入口に、下の表から選ぶ。**
+**必要な 1 本だけを開くこと。この索引を入口に、下の表から選ぶ。** 他の文書からこれらの話題を指すときは、索引を経由せず**本文があるファイルを直接指す**（[`residency.md`](./collaboration-workflow/residency.md)）。
 
 | 話題                                                                                              | ファイル                                                                  |
 | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
@@ -30,15 +30,3 @@
 | コマンド出力が文脈へ持ち込む量の上限                                                              | [`output-bounds.md`](./collaboration-workflow/output-bounds.md)           |
 | 運用ルール                                                                                        | [`operating-rules.md`](./collaboration-workflow/operating-rules.md)       |
 | 用語集 — lane・cut・hold・park などの定義と単一ソース                                             | [`glossary.md`](./collaboration-workflow/glossary.md)                     |
-
-**どの 1 本を開けばよいかを決めるのに必要なのは、この索引だけである。** バイト数はここに書かない — 手で保守した数字は本文より先に古くなり、古い数字は無いより悪い。実サイズは `ls -l prompts/collaboration-workflow/` が答える。
-
-## 参照の書き方
-
-`CLAUDE.md` と `.claude/skills/` からこれらの話題を指すときは、**本文があるファイルを直接指す**（話題ファイル、skill へ単一ソース化済みならその skill。[`residency.md`](./collaboration-workflow/residency.md)）。索引や指し先を経由させる形（`prompts/collaboration-workflow.md` → 「節名」）は、読み手に 2 回読みを強いるうえ、節名が変わると黙って行き止まりになる。
-
-```md
-See `prompts/collaboration-workflow/upstream-interrupt.md`.
-```
-
-`scripts/claude/collaboration-prompt-split.test.ts` が、文書と skill が指すファイルの実在と、この索引が全ファイルを列挙していることを検査する。

package/prompts/review-rubric.md

@@ -50,10 +50,8 @@ for every finding that passes test 1, and to say so when the attempt failed**: "
 is a skipped step.
 
 **A distributed artifact is on that list deliberately.** `CLAUDE.md`, `prompts/**`, `.claude/**` and
-`docs/**` are reviewed at the same level as runtime code: measured on real documentation-only diffs,
-a review found ten real defects each — dangling pointers into removed sections, citations naming the
-wrong file, in artifacts distributed to every consumer — that no test covered, because prose is what
-they were. A severity rule that ranked documentation below runtime code would contradict that.
+`docs/**` are reviewed at the same level as runtime code — a dangling pointer or a citation naming the
+wrong file reaches every consumer, and no test covers prose.
 
 **`high` and `low`.** A `high` is fixed before committing and blocks the merge regardless of round
 count; a `low` that does not reach the user may be skipped with a one-line reason. This section
@@ -214,73 +212,12 @@ allowed.
 
 ### 4. Project conventions (`CLAUDE.md`)
 
-**The gate has already run — do not re-verify what lint enforces.** `pnpm josh gate` precedes this
-review, and `pnpm josh format:edited` runs `eslint --fix` and `prettier --write` after every `Edit` /
-`Write`, so anything ESLint decides has already failed as an error or been corrected before you read
-the diff. Re-checking it inflates the first round's finding count.
-
-**Settled by lint, and therefore not checked here** — each one verified against the rule that
-enforces it, never assumed:
-
-- **Naming** — `@typescript-eslint/naming-convention` (`eslint/rules/naming-convention.js`).
-- **`export default`** — `import/no-default-export` is `error` project-wide (`eslint/rules/import.js`),
-  switched off only for `*.d.ts` in `eslint/base.js`.
-- **Individually named exports of function declarations, and of consts that are not `UPPER_CASE`** —
-  `no-restricted-syntax` in `eslint/rules/code-quality.js`. **Its selector exempts
-  `ArrowFunctionExpression`**, so `export const helper = (s: string): string => s` passes it; that
-  gap is a reader's job, below.
-- **File names** — kebab-case through `unicorn/filename-case`.
-- **The `*.spec.*` suffix, and a top-level `tests/` directory** — `eslint/rules/test-filename.js`,
-  wired into `eslint/base.js` itself, so it holds in kit and in every project built on that base
-  config. **Both bans cover every JS/TS extension** (`.ts` `.tsx` `.mts` `.cts` `.js` `.jsx` `.mjs`
-  `.cjs`) and neither covers `.svelte`. **A trailing block switching `no-restricted-syntax` off is
-  what can still take it away** — so read a diff that adds one as a gate defect, per the last
-  paragraph of this category.
-- **Magic numbers** — `@typescript-eslint/no-magic-numbers`; **`any`, unused vars, floating promises
-  and explicit param and return types** — `eslint/rules/typescript.js` and `eslint/rules/promise.js`.
-- **Identical functions and repeated string literals** — `eslint/rules/sonarjs.js`.
-- **Every quality limit below.**
-
-- **Quality limits**: a reference, enforced by `eslint/rules/code-quality.js` and
-  `eslint/rules/sonarjs.js` rather than re-checked here — function complexity ≤5, nesting ≤2,
-  function ≤25 lines, file ≤300 lines, params ≤4, statements per function ≤10,
-  cognitive complexity ≤4 — **the line counts are code lines, not physical lines**: `max-lines` and
-  `max-lines-per-function` run with `skipBlankLines` and `skipComments`, so read what
-  `pnpm josh lint` reports rather than `wc -l`, and test files (`*.test.ts` / `*.e2e.ts`) allow
-  35 code lines per function instead of 25 — **`*.spec.ts` is not on that list**, because the same
-  config bans the name outright.
-
-**What only a reader can see — check these:**
-
-- **`function` syntax rather than an arrow const** — **no rule enforces this**: there is no
-  `func-style` and no arrow selector anywhere in `eslint/`, and the named-export selector above
-  explicitly exempts `ArrowFunctionExpression`. So `const do_thing = (n: number): number => n + 1` and
-  `export const helper = (s: string): string => s` both lint clean, and this review is the only thing
-  between either and the default branch. The route-file exemption in `CLAUDE.md` covers the named
-  route handlers and nothing else.
-- **The early-return one-liner** — `curly` is configured `['error', 'multi-line']`, which requires
-  braces on a multi-line body and never requires the one-liner form. A short `if (x) { return y }`
-  passes lint, so "single `return` under 100 chars → one-liner `if (x) return y`" is a reader's check.
-- **Duplication that is not identical** — `sonarjs/no-identical-functions` sees only functions that
-  match. Two implementations of one idea in different shapes are invisible to it, and they are exactly
-  what "No clones — single-source" is about, package boundaries included.
-- **A name that satisfies the convention and says the wrong thing** — `naming-convention` checks the
-  shape, never the meaning. An `is_` prefix on a function that returns a parsed value passes lint and
-  misleads every caller.
-- **Grouping and layout** — a namespace object that collects unrelated functions, or a file whose
-  contents no longer match what its name says. Structure is not something lint judges.
-- **Svelte semantics** — `$state` reassignment, `Props` as an interface name, restricted DOM
-  manipulation, and `PascalCase.svelte` / `PascalCase.svelte.ts` file names where the project's lint
-  does not cover them.
-- **Test placement beyond the two banned patterns** — the ban above decides the `*.spec.*` suffix and
-  the top-level `tests/` directory, and nothing else. **A `tests/Foo.svelte` is outside both**, so it
-  is a reader's check. Colocation itself is what it cannot see: a test that avoids both and still sits
-  in a directory away from the code it exercises lints clean, and so does an `*.e2e.ts` placed outside
-  `src/routes/**`.
-
-**A gate finding that got through is still a finding.** If lint could have caught something and did
-not — a disabled rule, an ignored path, an `// eslint-disable` the change added — say so. That is a
-defect in the gate, and no other step is looking at it.
+**Do not re-check what lint enforces — the gate has already run; lint does not catch `function`
+syntax over an arrow const (outside named route handlers), the early-return one-liner, duplication
+that is not identical, a name whose shape passes but whose meaning misleads, grouping and file layout,
+Svelte semantics, or test placement beyond the `*.spec.*` / top-level `tests/` bans, so check those.**
+A lint gap the change opens — a disabled rule, an ignored path, an added `eslint-disable`, a block
+switching `no-restricted-syntax` off — is itself a finding.
 
 ### 5. i18n