@joshuafolkken/kit 1.1136.0 → 1.1166.0

package/prompts/collaboration-workflow/overview.md

@@ -15,28 +15,22 @@
 
 一括実行する場合は `fullrun new` で Step 1〜5 を通しで実行する。
 
-### 手順の置き場所（常時ロードとオンデマンドの分離）
-
-`kickoff` / `fullrun` / `halfrun` / `backlogrun` の**操作手順**は、常時ロードされる `CLAUDE.md` からは外され、`.claude/skills/workflow-commands/` に置かれている（joshuafolkken/kit#854）。`CLAUDE.md` に残るのはキーワードとスキルへの導線、およびスキルが読み込まれていない状態でも効く必要のある規則だけである。依存更新後の overrides / `devEngines` 検証手順も同様に `.claude/skills/dependency-update/` へ移した。**どの規則が「残す」側かは →「常駐ドキュメントと skill の分担（何を常駐に残すか）」が判定基準と全 4 件を定義する。**
-
-規則の本文は話題ファイルか skill のどちらか 1 か所にだけ置き（どちらに置くかは →「常駐ドキュメントと skill の分担」）、規則が使う数字はコードの定数と、それを述べる 1 文書にだけ置く。**他の文書はその置き場所を指すだけで言い直さない** — 同じ内容を 2 か所に書くと、片方を変えた瞬間にもう片方が古くなる（joshuafolkken/kit#2996）。
-
 ### 出力の言語（`JOSH_SESSION_LANG`）
 
 ワークフローの出力言語は、環境変数 `JOSH_SESSION_LANG`（例: `ja` / `en`）で決まる。対象は「開発者との対話」と「成果物の散文」の**両方**であり、**変数が未設定・空・`.env` なしのときはどちらも `ja` を既定とする**。英語で書くなら `JOSH_SESSION_LANG=en` を設定する。
 
-- **対話は `JOSH_SESSION_LANG` に従う**: セッション中の説明・質問、および `halfrun` などで提示する **`AskUserQuestion` の選択肢ラベル・説明**。未設定の場合は `ja` を既定とする（1 語のプロンプトでは言語を判定できず、周囲の英語に流れてしまうため）。
-- **成果物の散文も `JOSH_SESSION_LANG` に従う**: Issue 本文、Issue／PR コメント（Step 3 の計画コメント、`pnpm josh followup` が自動投稿する完了コメントを含む）、Telegram 通知の本文（`--body` / `--notify-message`）。**未設定の場合は `ja` を既定とする。**
+- **対話は `JOSH_SESSION_LANG` に従う**: セッション中の説明・質問、および `halfrun` などで提示する **`AskUserQuestion` の選択肢ラベル・説明**。
+- **成果物の散文も `JOSH_SESSION_LANG` に従う**: Issue 本文、Issue／PR コメント（Step 3 の計画コメント、`pnpm josh followup` が自動投稿する完了コメントを含む）、Telegram 通知の本文（`--body` / `--notify-message`）。
 - **設定に関わらず英語で固定するもの**（3 つ）:
-  1. **Issue／PR タイトル**: Step 1 のタイトル正規化ルールは変更しない。Issue 一覧の見通しを保ち、`pnpm josh git` が作るブランチ名を ASCII に保つため。
-  2. **コード内コメント、テストタイトル（`describe` / `it` / `expect`）、コミットメッセージ**: リポジトリのコード規約であり、開発者個人の言語設定とは別の軸で決まる。
-  3. **スクリプトが出力する固定文字列**: Telegram のヘッダーラベル（`Planning` / `Completion` など）、`Issue:` / `PR:` の URL ラベル、`--notify-message` 省略時の既定メッセージ。AI が書く文面ではなく、翻訳の仕組みも持たない。
+  1. **Issue／PR タイトル**: Step 1 のタイトル正規化ルールは変更しない。
+  2. **コード内コメント、テストタイトル（`describe` / `it` / `expect`）、コミットメッセージ**。
+  3. **スクリプトが出力する固定文字列**: Telegram のヘッダーラベル（`Planning` / `Completion` など）、`Issue:` / `PR:` の URL ラベル、`--notify-message` 省略時の既定メッセージ。
 
-`JOSH_SESSION_LANG` は **開発者個人の設定**であり、`.env`（gitignore 済み・非コミット）に置く。リポジトリ共有の設定ではないため、consumer ごと・開発者ごとに自由に変えてよい。`josh sync` で上書きされることもない。**解決値は毎ターン、`UserPromptSubmit` フック（`pnpm josh session:lang`）が 1 度だけコンテキストへ差し込む**ので、エージェントが `.env` を読まなくても言語を取り違えない（最初のターンで二重解決していたため `SessionStart` からは外した）。フック出力を表示しないハーネス（Codex / Gemini / Cursor）は従来どおり `.env` を読んで解決する。この変数がスクリプトの挙動を変えることはなく（`session:lang` が解決値を表示のために読むだけ）、制御するのは AI が書く文面の言語だけである。
+`JOSH_SESSION_LANG` は **開発者個人の設定**であり、`.env`（gitignore 済み・非コミット）に置く。**解決値は毎ターン、`UserPromptSubmit` フック（`pnpm josh session:lang`）がコンテキストへ差し込む。** フック出力を表示しないハーネス（Codex / Gemini / Cursor）は `.env` を読んで解決する。各既定の理由は `docs/maintainers/overview-rationale.md` → "Why the session language defaults the way it does" にある。
 
 ### 配布ドキュメントの層ごとの言語（joshuafolkken/kit#2997）
 
-`JOSH_SESSION_LANG` が決めるのはセッションと成果物の散文であり、配布ドキュメントそのものの言語ではない。ドキュメントは**層ごとに 1 つの言語**で書き、1 つの層の中で言語を混ぜない。
+ドキュメントは**層ごとに 1 つの言語**で書き、1 つの層の中で言語を混ぜない。`JOSH_SESSION_LANG` はこれを変えない。
 
 | 層                                                                                      | 言語   |
 | --------------------------------------------------------------------------------------- | ------ |

package/prompts/collaboration-workflow/plan-comment.md

@@ -1,7 +1,7 @@
 ## Step 3: 計画コメントを記録して通知する
 
 1. 提案を人間が判断する
-2. 採用した計画を Issue に記録する（Issue body が空の場合は `gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f body="<plan>"` で body に書き込む。body が既にある場合は `pnpm josh issue:comment <N> --body-file <path>` でコメント追加する）
+2. 採用した計画を Issue に記録する（Issue body が空の場合は計画をファイルに書き、`gh api -X PATCH repos/{owner}/{repo}/issues/<N> --field body=@<path>` で body に書き込む — 本文はパスで渡し、シェルの二重引用符には載せない（`shell-body.md`）。body が既にある場合は `pnpm josh issue:comment <N> --body-file <path>` でコメント追加する）
 3. Telegram で計画開始を通知する:
 
    ```bash
@@ -9,48 +9,34 @@
    ```
 
    - `--task-type` はヘッダーのアイコンを決める（`planning` 📋 / `completion` ✅ / `failure` ❌ / `warning` ⚠️ / `kickoff_retry` 🔄 / `confirmation` ⏸️）
-   - `warning` は **`pnpm josh followup` が自分で送る種別** であり、手で打つものではない（マージは成功したが実行記録を残せなかった場合など、`failure` と呼ぶと嘘になる事象のための種別: joshuafolkken/kit#1628）
+   - `warning` は **`pnpm josh followup` が自分で送る種別** であり、手で打つものではない（joshuafolkken/kit#1628）
    - `--repo-name` と `--issue-title` は未指定なら `gh` から自動取得される
-   - Issue URL を必ず含める
-   - 箇条書きの間に改行を入れて読みやすくする
+   - Issue URL を必ず含め、箇条書きの間に改行を入れる
    - `kickoff` コマンドの場合はここで **停止** する（実装に進まない）
 
-4. ワークフロー開始時点で作業ツリーにステージング済みまたは変更済みのファイルが既にある場合（例: ユーザーが事前に kit/設定ファイルをステージングした場合）、先に変更を退避する:
+4. ワークフロー開始時点で作業ツリーにステージング済みまたは変更済みのファイルが既にある場合、先に変更を退避する:
    ```bash
-   git stash push -m "plan: pre-existing changes"
+   git stash push -u -m "plan: pre-existing changes"
    ```
 5. メインブランチへ切り替えて最新を取得する:
    ```bash
    git switch main && git pull
    ```
-6. 依存関係を最新化し、脆弱性を確認する（**必須—作業ツリーに変更があっても省略してはならない**。`pnpm latest` は内部で `pnpm audit` も実行する）:
-   ```bash
-   pnpm latest
-   # 脆弱性が見つかった場合: package.json の overrides に対象バージョンを追加して pnpm install 後に再確認
-   ```
-   ステップ 4 で stash した場合は、ここでメッセージ指定で復元する（位置指定や引数なしの `git stash pop` は使わない — stash は全 work tree が共有する 1 本のスタックで、別のレーンの stash を取り込む恐れがある。joshuafolkken/kit#2050）:
+6. 依存関係の更新はコマンドに問う — `pnpm josh latest:scope` が `required` と答えたときだけ `pnpm josh latest` を実行し、`dependency-update` スキルに従う（単一ソースは `.claude/skills/workflow-commands/latest-gate.md`）。脆弱性への override は `pnpm-workspace.yaml` の `overrides` に書く（pnpm 11/12 は `package.json` の `pnpm.overrides` を無視する）。
+   ステップ 4 で stash した場合は、ここでメッセージ指定で復元する（stash は全 work tree が共有するため、位置指定や引数なしの `git stash pop` は使わない — joshuafolkken/kit#2050）:
    ```bash
    pnpm josh stash:pop "plan: pre-existing changes"
    ```
-7. **作業サマリを提示してから**実装を開始する（`CLAUDE.md` の Code Change Rules Step 0）。書式は下記「報告フォーマット（平易な概要 ＋ 技術詳細）」に従う — `JOSH_SESSION_LANG` の言語で、平易な概要 3 行を先頭に置き、技術詳細（触るファイル / モジュール、アプローチとその理由、副作用・スコープ外、テスト宣言）はその下に置く。
-
-   `fullrun` / `halfrun` / `backlogrun` では Issue ごとに 1 回、実装に着手する直前に提示する。**Issue body が既に埋まっていて計画コメントを投稿しなかった場合も必ず提示する**（この場合ユーザーには他に作業内容が見えないため）。`kickoff` は既に計画を Issue に投稿するので対象外。
-
-   提示は説明のためであり、**確認待ちで停止する意味ではない**。同一ターンでそのまま実装へ進むこと（停止条件にはならず、`/code-review` → `followup` のチェーン規則にも影響しない）。セッション向け出力のみに留め、Issue コメントとしては投稿しない。
-
+7. **作業サマリを提示してから**実装を開始する（`CLAUDE.md` の Code Change Rules Step 0）。書式は `report-format.md` に従う。`fullrun` / `halfrun` / `backlogrun` では Issue ごとに 1 回、Issue body が既に埋まっていても必ず提示する（`kickoff` は計画を Issue に投稿するので対象外）。提示は説明のためであり、**確認待ちで停止しない** — 同一ターンでそのまま実装へ進み、Issue コメントとしては投稿しない。
 8. 実装完了後、**lint/test より前に** `prompts/refactoring.md` に従ってリファクタリングを適用する（高・中優先度項目が残らなくなるまで収束させる）
 9. 検証ゲート（`CLAUDE.md` の Completion gate）を実行する
 
-`pnpm josh git` の基本実行（`-y` で確認プロンプトをスキップ）。**子はバージョンを上げない**（joshuafolkken/kit#1486）。子の PR に `package.json` の version 変更は入らず、版を決めるのは main の履歴を読む `pnpm josh release` ただ 1 箇所である。
+`pnpm josh git` の基本実行（`-y` で確認プロンプトをスキップ）。**子はバージョンを上げない** — 版を決めるのは `pnpm josh release` ただ 1 箇所である（joshuafolkken/kit#1486）。Issue タイトルは実行前に整える（規則は `issue-template.md` の Step 1 冒頭）。
 
 ```bash
 pnpm josh git -y "<issue-title> #<issue-number>"
 ```
 
-> **Note**: Issue タイトルは `pnpm josh git` を実行する前に、簡潔で明瞭な英語に整えること。
-> 日本語で書かれている場合は英語に変換する。すでに英語で書かれている場合でも、文法・明確さ・簡潔さの観点で改善できるなら書き換えて良い（AI ツールは実装前にタイトル品質を判断する）。
-> いずれの場合も `gh api -X PATCH repos/{owner}/{repo}/issues/<number> -f title="<english-title>"` で GitHub Issue タイトルを合わせて更新する。
-
 ### Recovery after failed push (pre-push hook blocked)
 
 If `pnpm josh git -y` fails at the push step (e.g. blocked by the pre-push hook), fix the blocking issue and then recover with:
@@ -66,20 +52,6 @@ pnpm josh pr
 
 **Do not** run `gh pr create` directly — it bypasses `build_body` which generates `closes #N`, causing the Issue to remain open after merge.
 
-`fullrun` フローでは、コミットの前に `/code-review` スキルを実行する（下記「レビュー工程は実装セッションがコミット前に実行する」と同じ時期であり、以前ここに書かれていた「コミット後」は誤りだった）。高・中優先度の指摘が見つかった場合は修正を行い、再度 `pnpm josh review:brief` と `/code-review <what it printed>` を実行してから次のステップへ進む（**2 周目は差分全体の読み直しではなく修正の検証パス**。下記「レビュー工程は実装セッションがコミット前に実行する」）。**レビューは合計 2 回まで**であり、2 回目を終えた時点で残る Low/Medium は follow-up Issue に切り出し、**現在の Issue が閉じる前に `pnpm josh epic:bundle <新規>` を実行して答えに従う** — `add_to_epic` / `create_epic` は Tier A で、対応する `pnpm josh epic --add` / `pnpm josh epic` を実行する（本文の手編集は不可）。`ask` も Tier A であり、推奨する epic を選んで追加し理由を記録する（停止も park もしない — joshuafolkken/kit#1339）。`none` は何もしない。**この起票と束ね直しは `pnpm josh git -y` の後・`pnpm josh followup` の前に置く** — コードを変えない作業なので CI 待ちの中に収まり、Issue が閉じるのはマージ時点なので期限も満たす（`prompts/review.md` → "Review round cap"、→「後追い Issue は起票した直後に EPIC へ束ね直す」）。
-
-**`/code-review` の出力で停止してはならない**という連鎖規則の本文は、`.claude/skills/workflow-commands/chain-rule.md` にある — 停止してよい 2 状況、決定表、アンチパターン集、ターン終端セルフチェックはすべてそこが単一ソースである（joshuafolkken/kit#1186）。
-
-### レビュー工程は実装セッションがコミット前に実行する
-
-ワークフロー内のレビュー工程（各フローの `pnpm josh review:brief` と `/code-review <what it printed>`）は、**実装したセッション自身が、コミットの前に**インラインで実行する。対象は `git diff main`、実行時期は検証ゲートの後半（refactor → **`pnpm josh gate` をレビューと同時に開始し、コミット前に join する** → `/code-review` with the brief `pnpm josh review:brief` prints）であり、`fullrun` / `halfrun` / `backlogrun` のいずれも同じ時期・同じ対象でレビューする。1 周目の High/Medium はその場で修正し、**指摘を潰し切ってから最初のコミットを作る**。ただし**2 周目は 1 周目の反復ではなく、修正の検証パスである** — 対象は差分全体ではなく 1 周目の修正が触った範囲（fix delta）で、問いは「各指摘は実際に閉じたか／修正自体が欠陥を入れていないか」に変わる。基準は変わらず、閉じていない指摘は元の severity のまま残る（`prompts/review-rubric.md` → "The second round is a verification pass, not a second full review"）。**再実行は 2 周まで**であり、2 周を終えた時点で残る High 以外の指摘は、**内容から機械的に決まる 3 分岐**に振り分ける（`prompts/review.md` → "Review round cap"）。分岐は、既に触れているファイル内で数行・設計判断なしに閉じるなら**その場で直す（新しいレビュー巡は起こさない）**、実行経路に届くか判断が要るなら**起票する**、利用者に届かない Low なら**PR に 1 行残して落とす**、の 3 つ。同じ根本判断に帰着する複数の指摘は**1 件の Issue にまとめる**。起票する場合、**切り出しは起票では終わらない** — 起票に続けて `pnpm josh epic:bundle <新規>` を実行し、`add_to_epic` / `create_epic` は確認せずに実行する。**ただし PR を開くフロー（`fullrun` / `backlogrun`）では、起票と束ね直しの実行位置はコミットの前ではなく `pnpm josh git -y` の後・`pnpm josh followup` の前**である。`halfrun` は PR を開かず、隠れる先の CI が無いので、振り分けが決まった時点で実行する（→「後追い Issue は起票した直後に EPIC へ束ね直す」）。したがって PR に貼るレビューコメントは発生しない。
-
-**PR を開く位置は 2 周の間である**（joshuafolkken/kit#1261）。1 周目の修正が入ったら `pnpm josh gate` → join → `pnpm josh git -y` の順で進め、**2 周目は そのコミットが起動した CI と並走させる**。join とコミットの間でツリーを書き換えるものは何も無い（joshuafolkken/kit#1486 で子のバージョン上げが消えた）ので、コミットが乗るゲートはそのツリーちょうどを覆い、2 周目のブリーフは `Already verified` のままである。2 周目がその場修正を出した場合だけ、同一ブランチへの追加コミットが 1 つ増え、そのコミットに対して CI が回り直す — マージが待つのはその結果である。1 周目が clean なら 2 周目自体が無いので、順序は従来どおり。単一ソースは `.claude/skills/workflow-commands/chain-rule.md` → "The pull request opens between the rounds, so CI runs beside round 2"。
-
-**その追加コミットは、ゲートより先に push する**（joshuafolkken/kit#1326）。修正が届く単一チェック（`pnpm josh lint:related` / `pnpm josh cspell:dot` / `pnpm josh test:related` / そのプロジェクト自身の型チェック）を回してから `pnpm josh git -y "<title> #<N>"` を打ち、`pnpm josh gate` はその push が起動した CI と並走させて **`pnpm josh followup` の前に join する**。先に push しても未検証のコードを送ることにはならない — commit / push フックがステージ済みファイルの lint・スペルチェックと型検査、そしてユニット全件を走らせ、CI 側の `Checks` ジョブは `pnpm josh gate --verbose` を実行するからである。それでも join を省いてよいわけではない: `followup` は PR のチェックだけを読み、ゲートの記録は読まない。ゲートが赤なら直して同じ単一チェックを回し直し、もう一度 `pnpm josh git -y` を打つ。追い越された CI は `ci.yml` の `concurrency: cancel-in-progress: true` によって打ち切られ、マージが待つのは常に HEAD コミットのチェックである。マージ条件（必須チェック全緑・ゲート緑・変更要求なし）は一切緩めない。単一ソースは `.claude/skills/workflow-commands/chain-rule.md` → "The round-2 fix commit is pushed before its gate"。
-
-**2 周目が clean なら、その結果を読んだターンでマージを打つ**（joshuafolkken/kit#1333）。joshuafolkken/kit#1326 の run（PR #1327）では、CI がレビュー 2 周目の内側に完全に隠れてもなお、全チェック緑（06:34:37）からマージ（06:36:51）まで 134 秒が残り、うち **19 秒はレビュー結果を読んだターンと `followup` を打つターンが別だっただけの空白**だった（同 run はモデル 1 往復あたり平均 10.1 秒・67 往復）。clean かどうかは判断ではなく機械的に決まり、条件は 2 つある — **確定した High が残っていないこと**と、3 分岐の 1（その場で直す）に振り分けた指摘が 1 件も無いこと。High はそもそも 3 分岐のいずれにも入らないので、branch 1 の条件だけでは High について何も言っていない — 2 周を終えてなお残る High は `confirmation` 通知を送って run を止める側であり、マージは打たない。**Low だけが出た周は clean である**（Low は分岐 2 か 3 に入り、どちらもコードを 1 行も変えない）。起票（分岐 2）と PR への 1 行注記（分岐 3）はコードを 1 行も変えないので、`pnpm josh epic:bundle` まで含めて**同じターンのマージ発行より前**に置き、最後の 1 つが返った時点でマージを打つ。**検証は何ひとつ省かない** — ゲートの join と緑、必須 CI チェックはいずれも従来どおり読み、`followup` が待つものも変わらない。縮むのは「読んでから打つまで」の空白だけである。2 周目がその場修正を出した場合はこの規則の対象外で、直前の段落が定める順序（単一チェック → push → ゲートを CI と並走 → join → マージ）に入る。単一ソースは `.claude/skills/workflow-commands/chain-rule.md` → "A clean second round issues the merge in the same turn"。
-
-**そのゲートは 1 ラン 1 回であって、1 編集 1 回ではない**（joshuafolkken/kit#1246）。kit#1242 が決めたのは 1 回のゲートを**いつ**開始するかであって、**何回**回るかには触れていない。実測（kit#1241）では 49.1 分のランでゲートが 10 回・合計 8.2 分を占め、うち 6 回はレビュー開始前の「いま入れた編集が通ったか」の確認で、答えを出したのは毎回 lint か cspell の 1 チェックだけだった。**実装中は、単一チェックを名前で回す**（`pnpm josh lint:related` / `pnpm josh cspell:dot` / `pnpm josh test:related` / そのプロジェクト自身の型チェック）。**そこでのユニットチェックは絞り込んだ側**である（joshuafolkken/kit#1257）— `pnpm josh test:related` は変更ファイルが到達するテストだけを走らせ、絞り込めないときは全件に戻ってその旨を印字する。全件を走らせる `pnpm josh test:unit` は、コミット前のゲートが回すものとして変わらない。一度ゲートを回した後は、各ブロックのヘッダが実際に走ったコマンドを印字しているので、そこからコピーすればよい。全ゲートか単一チェックかは**「レビューが始まったか」**だけで決まり、編集の大きさでは決まらない。レビューと同時にゲートを開始した後は、赤の修正も指摘の修正もツリーを変えて前の結果を陳腐化させるので、単一チェックに戻るのではなく全ゲートを回し直す。分岐表は `.claude/skills/workflow-commands/chain-rule.md` → "The gate runs beside this review, not in front of it" にある。
+### レビューからマージまで
 
-**フレッシュコンテキストのサブエージェントに委譲する方式（kit#752）と、PR 作成後に実行して結果を PR コメントとして投稿する方式（kit#758）は、これを置き換えるものではなく、これに置き換えられた。** 別コンテキストのレビュアーは実装者のバイアスを持ち込まない利点があったが、毎ラウンド変更を読み直し、指摘のたびに修正コミット・push・必須チェック 6 件の CI 再実行が走るため、PR 作成からレビュー確定まで 10 分を超えるのが常態だった（kit#758 の PR 自身が 3 ラウンドで 10 分 53 秒）。**レビュアーが実装者と同一コンテキストである点は、この方式が受け入れているトレードオフである** — 作者の思い込みが素通りする確率は上がるが、コミット前セルフレビュー（`prompts/review.md`）は従来どおり必須のゲートとして残る。
+レビューは実装したセッションが**コミットの前に** `pnpm josh review:brief` で始め、`/code-review` は `Agent` ツールのサブエージェントが実行する。ゲートとの重ね方、2 周の上限と 2 周目の検証パス、2 周の間で PR を開く位置、残った指摘の振り分けと `pnpm josh epic:bundle`、マージを打つターンは、すべて `.claude/skills/workflow-commands/chain-rule.md` が単一ソースである — "Run the review-to-merge chain"、"The review runs in a subagent, never a main-line skill load"、方針は `prompts/review.md` → "Review round cap"。**`/code-review` の出力で停止しない。**

package/prompts/collaboration-workflow/principles.md

@@ -70,14 +70,13 @@
 
 - **規則の追加・仕様変更・文言修正・節の追加は `CLAUDE.md` に 1 回だけ書く。** 他の 2 本には触れない
 - **導線文書に規則を書き戻さない。** そこに書かれた規則は、次の改訂で更新し忘れる 4 つ目の置き場になる
-- `scripts/document/ai-document-pointers.test.ts` が機械的に守る。導線文書に規則本体が再出現した場合、導線の一文が消えた場合、`CLAUDE.md` が単一ソースであることの記述が消えた場合に落ちる
-- 経緯は `docs/maintainers/principles-rationale.md` → "Why AGENTS and GEMINI are pointers"、`@CLAUDE.md` 行と他ツールでの未検証は `docs/maintainers/principles-rationale.md` → "The include line, and what has not been verified"
+- 経緯と機械的な検査は `docs/maintainers/principles-rationale.md` → "Why AGENTS and GEMINI are pointers"、`@CLAUDE.md` 行と他ツールでの未検証は `docs/maintainers/principles-rationale.md` → "The include line, and what has not been verified"
 
 ### Claude Code 以外のエージェントでの読み替え
 
-`CLAUDE.md` は Claude Code 向けに書かれており、その機能を名指しする。Codex・Gemini CLI など別のエージェントは次のように読み替える。導線文書が持つのはツール固有の 1 行だけで、共通の読み替えはこの節にしか無い（joshuafolkken/kit#3079）。
+`CLAUDE.md` は Claude Code 向けに書かれており、その機能を名指しする。Codex・Gemini CLI など別のエージェントは次のように読み替える（joshuafolkken/kit#3079）。
 
-- **フック**: フックが走らない、または出力が見えないツールでは、フックが届ける規則を自分で適用する。その一覧は手書きせず、[`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」の表を正とする — 表の各行が、そのツールでは自分で守る規則である。表の外でフックが担う 3 つも同じく自分で行う — 最初の実行時コード編集の前に Step 0 の作業サマリを提示する、編集ごとの整形フックに頼らず編集後に `pnpm josh lint:related` と `pnpm josh cspell:dot` を走らせる、`JOSH_SESSION_LANG` は注入を待たずに `.env` から解決する。フックの全体は `.claude/settings.json` の `hooks` が正である
+- **フック**: フックが走らない、または出力が見えないツールでは、フックが届ける規則を自分で適用する。その一覧は手書きせず、[`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」の一覧を正とする — 一覧の各項目が、そのツールでは自分で守る規則である。一覧の外でフックが担う 3 つも同じく自分で行う — 最初の実行時コード編集の前に Step 0 の作業サマリを提示する、編集ごとの整形フックに頼らず編集後に `pnpm josh lint:related` と `pnpm josh cspell:dot` を走らせる、`JOSH_SESSION_LANG` は注入を待たずに `.env` から解決する。フックの全体は `.claude/settings.json` の `hooks` が正である
 - **Skill・`/verify-ui`・`/code-review`**: `CLAUDE.md` が skill のロードやサブエージェントでの実行を指示する箇所では、その skill の `SKILL.md` を読み、自分のセッションで従う
 - **`.claude/settings.json` の deny list** は効かない。それが裏付ける規則 — 指示なしのコミット・マージ・ステージングその他の共有状態変更をしない — はそのまま拘束する
 - **`AskUserQuestion`** は、ユーザーに平文で尋ねることを指す

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

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

package/prompts/collaboration-workflow/residency.md

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