@joshuafolkken/kit 1.1136.0 → 1.1166.0

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
 

package/prompts/review.md

@@ -15,17 +15,10 @@ points to them rather than restating them:
 
 ## When to run
 
-- **Pre-commit self-review** (implementing session, inline): before every `git commit` on a feature
-  branch — scope: the staged diff (`git diff --staged`), level from
-  `pnpm josh review:brief --level-only`.
-- **Workflow review step** (same session, inline): the last stage of the verification gate in `fullrun`
-  / `halfrun` / `backlogrun`, driven by the brief `pnpm josh review:brief` prints. Round 1 runs before the
-  commit — scope: `git diff main`. Round 2 runs after it, beside the CI the commit started
-  (`.claude/skills/workflow-commands/chain-rule.md` → "The pull request opens between the rounds, so CI
-  runs beside round 2").
-
-The workflow review uses the `reviewer` role profile printed by `pnpm josh review:brief`. Pass its
-model and effort explicitly to the review subagent; do not substitute the review level for effort.
+When a review runs is `CLAUDE.md` → "Pre-commit Self-Review"; inside a workflow, round 1 runs before
+the commit and round 2 beside CI (`.claude/skills/workflow-commands/chain-rule.md`). Pass the
+`reviewer` profile's model and effort that `pnpm josh review:brief` prints to the review subagent;
+do not substitute the review level for effort.
 
 Re-run after applying fixes until **no high or medium findings remain — or until the round cap below is
 reached, the first review included — whichever comes first.** The cap below is not optional. The second round
@@ -46,10 +39,8 @@ 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.** "This one is small" is a judgement
-made under cost pressure, and cost pressure resolves it toward "small" exactly when a defect is most
-likely to be shipped. A rule an agent applies from memory is a rule an agent can talk itself out of;
-one it has to run answers the same way every time.
+**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                  |
 | ---------------------------------------------------------------------------------------- | -------- | ----------------------- |
@@ -64,13 +55,8 @@ would hand a reduced level to a caller that failed to read the diff.
 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, and that is deliberate.** `CLAUDE.md`, `prompts/**`, `.claude/**`
-and `docs/**` are all reviewed at `medium`. The "Non-runtime updates" exception in `CLAUDE.md` exempts
-them from _testing_ — which asks whether an automated test could have caught the defect — while this
-asks whether a human reading the diff is the only thing that can. Measured on joshuafolkken/kit#963 and
-#965, both documentation-only by that classification: a `medium` review found ten real defects in each
-— pointers into sections that had been removed, and citations naming the wrong file, in artifacts
-distributed to every consumer — that nothing else would have caught.
+**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.
 
@@ -78,26 +64,19 @@ distributed to every consumer — that nothing else would have caught.
 
 ## Review round cap (2 rounds)
 
-The severity rule in the rubric is not a stopping condition on its own. Every fix creates new surface,
-and a review whose scope is the whole change finds something in it — so the loop is bounded by how much
-new code the fixes produce, which is unbounded.
+The severity rule in the rubric is not a stopping condition on its own: every fix creates new surface a
+further round would find something in.
 
 **Two rounds is the ceiling, not the schedule.** Whether the second one is due at all is
 `pnpm josh review:round2`'s answer — "When round 2 is skipped entirely, and when it is not" below is
-the single source of that condition (joshuafolkken/kit#1433).
-
-This is measured, not theorized. On joshuafolkken/kit#854 four rounds produced 18 findings; on #855
-two rounds produced 19. Almost none of them was a repeat: each round found new things, and many of
-those were about code the **previous round's fix** had just written. Two rounds of that is diligence; a
-third is the review chasing its own tail.
+the single source of that condition.
 
 ### A merge-conflict resolution review is not one of the two
 
 **When `pnpm josh followup` reports `PR checks failed (merge conflict)`, the child resolves the conflict
-in its own lane and reviews the resolution — and that round does not count against the cap**
-(joshuafolkken/kit#1623). The cap bounds re-reading _the change under review_; a resolution review reads
+in its own lane and reviews the resolution — and that round does not count against the cap**. The cap bounds re-reading _the change under review_; a resolution review reads
 a different subject — not the change, but what merging a moved `main` into it did.
-`.claude/skills/workflow-commands/backlogrun-lanes.md` → "Conflicts are not predicted" is the single source of
+`.claude/skills/workflow-commands/backlogrun-recovery.md` → "Conflicts are not predicted" is the single source of
 the procedure and of the four conditions under which the run steps back instead of resolving.
 `pnpm josh review:attest --check` must answer `ok` before the merge is re-issued, and a confirmed High
 parks the child rather than buying it a further round.
@@ -105,7 +84,7 @@ parks the child rather than buying it a further round.
 ### When round 2 is skipped entirely, and when it is not
 
 **Two rounds is the ceiling; whether the second round runs at all is a command's answer, not a reading
-of a list** (joshuafolkken/kit#1433):
+of a list**:
 
 ```bash
 pnpm josh review:round2 --round-1-closed   # → required | skip ; the reason on stderr
@@ -116,8 +95,7 @@ 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**
-(joshuafolkken/kit#1222 — the round exists because round 1's fix code is otherwise unreviewed):
+**`skip` has exactly two arms, and both are states in which round 1's fix code needs no review**:
 
 | Arm                    | What it is                                                                                                                   |
 | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
@@ -126,9 +104,7 @@ what the command answers to every uncertainty it meets, a missing round-1 snapsh
 
 **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.
-**The wider line joshuafolkken/kit#1433 proposed — exempting anything that is not a runtime code path —
-is not adopted**: a documentation-only diff is exactly where the review is the only detector (the #963 /
-#965 measurement above), so a prompt fix answers `required`.
+A documentation-only fix delta is not inert, so a prompt fix answers `required`.
 
 **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:
@@ -142,7 +118,7 @@ a defect is later traced to a skipped delta:
 ### Three-way disposition after the cap
 
 **After the second round, place every remaining non-High finding in exactly one of three exits, decided
-from what the finding is rather than from the filer's discretion** (joshuafolkken/kit#1469). **The
+from what the finding is rather than from the filer's discretion**. **The
 default exit is branch 3, and branch 2 has to be earned**. Read them in order — branch 1 where the fix is
 trivial and local, branch 2 only where the finding clears the bar it names, branch 3 for everything
 left, which is most of them. "It might matter later" is branch 3.
@@ -167,12 +143,6 @@ left, which is most of them. "It might matter later" is branch 3.
    suspicion included. **The note is not optional**: one line naming the finding and why it was dropped
    is what keeps a dropped finding auditable rather than invisible.
 
-**What it costs, and why that is the right trade.** A dropped finding that later turns out to matter is
-re-found by the next review of that code, at the price of one round it would have paid anyway. A filed
-finding that never mattered is carried forever — placed in an epic, offered by `epic:next`, read by
-everyone who scans the backlog. The two errors are not symmetric, and the old default was on the
-expensive side of them.
-
 **Findings that reduce to one root judgement are filed as one Issue, not several** — a single follow-up
 Issue with a section per symptom (`## 現象 1` / `## 現象 2`).
 
@@ -187,7 +157,7 @@ Only branch 2 files an Issue. What follows applies to that branch.
   the commit.** Where the run opens a pull request — `fullrun`, `backlogrun` — they go after
   `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` (joshuafolkken/kit#1892).
+  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
@@ -204,13 +174,13 @@ Only branch 2 files an Issue. What follows applies to that branch.
      write command yourself — never a hand edit of the epic body, which leaves the task list and the
      `blocked-by` relations disagreeing and `epic:next` returning `error`.
 
-  | Answer                                                                                            | Do                                                                                                                                                                                                                                                                                                                                | Tier                    |
-  | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- |
-  | `add_to_epic`                                                                                     | `pnpm josh epic --add <E> <new>` — add `--before <M>` / `--after <M>` when the relation carries an order                                                                                                                                                                                                                          | **A — no confirmation** |
-  | `create_epic`                                                                                     | `pnpm josh epic "<title>" <new> <other> [--ordered]`                                                                                                                                                                                                                                                                              | **A — no confirmation** |
-  | `ask` — candidates spread across two or more epics                                                | **Choose the epic you recommend, run its write command, and record the decision** — what was taken, what was rejected, why — on both the new Issue and that epic's `## Decisions`. This does not stop a run and does not park a child (joshuafolkken/kit#1339); stop only where the two epics are genuinely too close to separate | **A — no confirmation** |
-  | `none`                                                                                            | Nothing                                                                                                                                                                                                                                                                                                                           | —                       |
-  | **The command could not answer** — non-zero exit, or **any** ⚠ warning above `Nothing to bundle.` | Stop and report, naming what it said. **A `none` printed after such a warning is not "nothing to bundle"** — the search was incomplete                                                                                                                                                                                            | —                       |
+  | Answer                                                                                            | Do                                                                                                                                                                                                                                                                                                       | Tier                    |
+  | ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- |
+  | `add_to_epic`                                                                                     | `pnpm josh epic --add <E> <new>` — add `--before <M>` / `--after <M>` when the relation carries an order                                                                                                                                                                                                 | **A — no confirmation** |
+  | `create_epic`                                                                                     | `pnpm josh epic "<title>" <new> <other> [--ordered]`                                                                                                                                                                                                                                                     | **A — no confirmation** |
+  | `ask` — candidates spread across two or more epics                                                | **Choose the epic you recommend, run its write command, and record the decision** — what was taken, what was rejected, why — on both the new Issue and that epic's `## Decisions`. This does not stop a run and does not park a child; stop only where the two epics are genuinely too close to separate | **A — no confirmation** |
+  | `none`                                                                                            | Nothing                                                                                                                                                                                                                                                                                                  | —                       |
+  | **The command could not answer** — non-zero exit, or **any** ⚠ warning above `Nothing to bundle.` | Stop and report, naming what it said. **A `none` printed after such a warning is not "nothing to bundle"** — the search was incomplete                                                                                                                                                                   | —                       |
 
 - **A confirmed High is never deferred.** A real defect does not ship because a round counter ran out,
   so a standing High blocks the merge — never fixed-in-place, filed, or dropped as one of the three

package/prompts/testing-guide.md

@@ -22,7 +22,8 @@ Req N: ...
 ### Rules
 
 - **Every user-facing behavior change** (UI interaction, keyboard shortcut, visible state change) must have a corresponding E2E test.
-- **Every logic/utility change** (pure functions, filters, transforms) must have a unit test.
+- **Every logic/utility change** (pure functions, filters, transforms) must have a unit test. A bug fix takes a regression test; a refactor takes tests pinning the existing behavior BEFORE the change (`prompts/refactoring.md`).
+- **Non-runtime updates (pre-approved manual-only exception):** a change touching no executable runtime code path — docs, non-executable config, editor/IDE files, cosmetic asset swaps with no selector/path change — may be verified by hand; declare it in Step 0 with the reason. The mechanically exempt (`*.md`, `.editorconfig`, `.idea/**`, `.vscode/**`, `prompts/**`) need no declaration. A runtime change whose test is infeasible needs the reason and user approval.
 - **basic で kit がテストできない言語だけの変更:** `package.json` に `josh.profile: basic`（改名前の `static` も同じ）が記録され、変更が HTML/CSS や Lua などのソースだけなら自動テストは不要。HTML/CSS はブラウザーで対象ページを開き、想定する画面幅でレイアウト・リンク・HTML 内の操作を確認する。そのほかのソースは変更した処理を実際に動かす。どちらも結果を記録する。同じ変更に JavaScript または TypeScript のファイルが含まれれば自動テストを行う。
 - If a test is genuinely infeasible (e.g., native OS date-picker popup cannot be driven by Playwright), write a comment in the test file explaining why and test the closest observable behavior instead (e.g., that the editor remains open after the `change` event fires).
 - Do **not** report a requirement as done if its test is missing.
@@ -59,7 +60,7 @@ There is exactly **one** convention for every test file — never choose between
 - **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. Left as an export a consumer had to remember to wire in, the ban reached only the projects that did — and never the repository distributing it (joshuafolkken/kit#1233). This was chosen over tightening the vitest `{test,spec}` matchers to `{test}` only, because matcher-tightening causes **silent non-execution** of stray `*.spec.ts` files whereas a lint rule fails loudly. (Doc-only guidance had already failed to prevent this drift twice.)
+> **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`).
 
 ---
 
@@ -177,19 +178,8 @@ test('returns expected values in sequence', () => {
 
 ## 6. Closing the E2E gate without a human run
 
-The completion gate used to end by asking the user to run `pnpm josh test` and paste the output.
-That step is gone (joshuafolkken/kit#902). It is the rule below that replaces it, and the
-replacement is **not** a relaxation — nothing that a red local run stopped is allowed through.
-
-### Why it existed, and why it no longer does
-
-The reason was never that a human reads E2E output better. It was that `followup` waited 180
-seconds for CI, which no suite containing E2E can finish in — so the command exited red beside a CI
-that was still running, and the only reliable E2E signal left was a person's terminal. That budget
-is now derived from the distributed `templates/workflows/ci.yml` rather than picked as a round
-number: 1920 seconds, the longest run its `needs` graph permits plus runner-queue headroom, with a
-unit test that fails if a declared job budget outgrows it (joshuafolkken/kit#851). CI can now be
-waited on, so it can be relied on.
+No human E2E run closes the gate, and nothing a red local run stopped is let through
+(`docs/maintainers/testing-guide-history.md`).
 
 ### Which result closes the gate
 
@@ -219,60 +209,21 @@ a **defined** outcome, not an accident: a project with no E2E suite has nothing
 read, and the run says so out loud. **A skip you did not see printed is not one** — it is an unread
 result, and it falls under the previous paragraph.
 
-**CI decides the same question, and now by the same rule.** The `e2e-detect` job in
+**CI decides the same question by the same rule.** The `e2e-detect` job in
 `templates/workflows/ci.yml` enables the `e2e` job when any `*.e2e.{ts,js}` exists outside
-`node_modules` — the guard's own glob, dot-directories left out the way the guard's default leaves
-them out — and it does not look at the config's filename at all (joshuafolkken/kit#991). Before
-that it required a file named exactly `playwright.config.ts` **and** an `*.e2e.{ts,js}` under `tests` or
-`src/routes`, so a suite kept anywhere else, or a config named `playwright.config.js`, read as
-"no E2E" in CI while `josh test:e2e` ran it locally: the job's `if:` went false, GitHub recorded it
-as `skipped`, the rollup parser counted the skip as passing exactly as it does for every other
-conditional job, and the first row of the table above closed the gate on a suite nobody ran.
-**Where the specs live was a precondition on the CI signal; it is now a property of the workflow.**
-The agreement is executed rather than described — `scripts/ci/ci-yml-e2e-detect.test.ts` runs the
-workflow's own script against each layout and compares its verdict to the guard's, and asserts over
-the whole matrix that no layout containing specs can yield `enabled=false`. § 1's placement
-convention still stands on its own merits (`eslint/rules/test-filename.js` bans a top-level
-`tests/` directory outright), but the CI signal no longer depends on following it.
-
-**One difference from the guard remains, and it is deliberate and one-sided.** The guard also skips
-when `@playwright/test` is not installed, which is what keeps that optional peer optional for the
-pre-push hook; CI enables the job on the spec alone, so a spec that cannot run ends red rather than
-silently green. Enabling more than the guard costs a failed job, enabling less costs a merge — so
-the difference may widen in that direction and never narrow.
+`node_modules` — the guard's own glob — whatever the config's filename;
+`scripts/ci/ci-yml-e2e-detect.test.ts` pins the agreement. CI enables the job on the spec alone, even
+where the guard skips for a missing `@playwright/test`, so a spec that cannot run ends red rather than
+silently green.
 
 ### The gate is not weakened
 
-Two properties carry the verification the human step used to carry, and both are asserted by tests
-rather than left to prose:
-
 - **A non-passing check keeps the merge closed.** `evaluate_pr_state` returns `success` only when
-  GitHub reports the pull request `CLEAN` **and** every required check passes. A failing E2E job
-  makes GitHub report `UNSTABLE`, and the one opening in that wall — `is_unstable_only_from_coderabbit`,
-  the temporary kit#753 policy — applies only when _every_ non-passing check is CodeRabbit's. So a
-  red E2E can never reach `success`, and `followup` exits non-zero instead of merging.
-- **Weakening the gate is a workaround, and the workaround rules apply to it.** Filtering,
-  narrowing or reinterpreting E2E output to get past it is the violation `CLAUDE.md` names under
-  "Cross-package problems"; reporting the filtered result honestly does not make it compliant.
-
-**`E2E` stays off the required-check list, and that is a decision rather than an oversight**
-(joshuafolkken/kit#991). A required check is satisfied by a _skipped_ job — the rollup parser maps
-`SKIPPED` to `pass` — so requiring `E2E` would have passed on exactly the skipped job described
-above, which is the failure it looks like it would have caught. It adds nothing to the failure path
-either: a red E2E already ends the wait on the poll that sees it. What it would add is a cost —
-a repository whose CI reports no `E2E` context at all resolves the required entry to `missing`,
-which is never `pass`, so the evaluation stays `pending` until the 32-minute wait times out with
-nothing actually wrong. What guarantees the job runs is the detection rule above, not the required
-list. A project that wants it required opts in through `JOSH_REQUIRED_CHECKS`, which
-`scripts/gh/git-pr-checks-eval.test.ts` covers; the decision itself — `E2E` off the default list,
-and a repository reporting no `E2E` check still mergeable — is pinned in
-`scripts/gh/git-pr-checks-e2e-gate.test.ts`.
-
-**A red E2E is reported as soon as it goes red, and by name.** `E2E` is not on the required list, so
-until joshuafolkken/kit#990 nothing ended the wait when it failed: the rollup read as pending,
-`followup` ran out its 32-minute budget, and the run ended in `Timed out while waiting for PR checks
-to complete.` — a message naming neither the job nor the cause. Any failing check now ends the wait
-on the poll that sees it, and the error names it (`PR checks failed (failed checks: E2E).`).
-The poll loop keeps CodeRabbit exempt under the temporary kit#753 policy. **This is a change to how fast the gate
-reports, never to what it lets through** — no failing check gained a path to `success`, which
-`scripts/gh/git-pr-checks-e2e-gate.test.ts` continues to assert.
+  GitHub reports the pull request `CLEAN` **and** every required check passes; the only exception is a
+  non-passing set made entirely of CodeRabbit checks (the temporary kit#753 policy). A failing check
+  ends the wait on the poll that sees it, by name (`PR checks failed (failed checks: E2E).`).
+- **Filtering, narrowing or reinterpreting E2E output to get past it is a workaround** —
+  `CLAUDE.md` → "Cross-package problems"; reporting the filtered result honestly does not make it
+  compliant.
+- **`E2E` stays off the default required-check list**; a project opts in through
+  `JOSH_REQUIRED_CHECKS`. `scripts/gh/git-pr-checks-e2e-gate.test.ts` pins both properties.

package/scripts/agent/agent-role-profile.ts

@@ -74,7 +74,7 @@ const PROVIDER_PROFILES = { anthropic: DEFAULT_PROFILES, openai: OPENAI_PROFILES
 
 // **Effort as a function of the run phase, not the role alone** (joshuafolkken/kit#2382). For the first
 // merge only the mechanical ship/bookkeeping region is lowered: the pre-gate resume drives the gate,
-// commit, PR and merge, applying fixes the gate has already named — work SKILL.md §2b calls the opposite
+// commit, PR and merge, applying fixes the gate has already named — work delegation.md calls the opposite
 // of judgement. The design-judgment implementation phases keep the role default, as does any role/phase
 // with no entry, and the review's own judgement is the reviewer role's (`high`), untouched by lowering
 // the worker here. The investigation phase — highest output density — is left for a later merge, once