@joshuafolkken/kit 1.1453.0 → 1.1471.0

package/prompts/collaboration-workflow/overview.md

@@ -8,34 +8,29 @@
 
 ### フェーズ分離
 
-ワークフローは 2 つのフェーズに分けて実行できる。
+- Planning phase（`kickoff`）: Step 1〜3 — Issue 作成・計画投稿・Telegram 通知で止まる。実装前にレビューや承認を挟むときに使う。
+- Execution phase（`fullrun #N`）: Step 4〜5 — 既存 Issue の計画に基づいて実装・PR 作成・完了通知を行う。
 
-- **Planning phase（`kickoff`）**: Step 1〜3 — Issue 作成・計画投稿・Telegram 通知で止まる。実装前にレビューや承認を挟みたい場合に使う。
-- **Execution phase（`fullrun #N`）**: Step 4〜5 — 既存 Issue の計画に基づいて実装・PR 作成・完了通知を行う。
-
-一括実行する場合は `fullrun new` で Step 1〜5 を通しで実行する。
+`fullrun new` は Step 1〜5 を通しで実行する。
 
 ### 出力の言語（`JOSH_SESSION_LANG`）
 
-ワークフローの出力言語は、環境変数 `JOSH_SESSION_LANG`（例: `ja` / `en`）で決まる。対象は「開発者との対話」と「成果物の散文」の**両方**であり、**変数が未設定・空・`.env` なしのときはどちらも `ja` を既定とする**。英語で書くなら `JOSH_SESSION_LANG=en` を設定する。
+開発者との対話と成果物の散文は、環境変数 `JOSH_SESSION_LANG`（例: `ja` / `en`）の言語で書く。**未設定・空・`.env` なしのときは `ja`**。
 
-- **対話は `JOSH_SESSION_LANG` に従う**: セッション中の説明・質問、および `halfrun` などで提示する **`AskUserQuestion` の選択肢ラベル・説明**。
-- **成果物の散文も `JOSH_SESSION_LANG` に従う**: Issue 本文、Issue／PR コメント（Step 3 の計画コメント、`pnpm josh followup` が自動投稿する完了コメントを含む）、Telegram 通知の本文（`--body` / `--notify-message`）。
+- 対話: セッション中の説明・質問、`AskUserQuestion` の選択肢ラベル・説明
+- 成果物の散文: Issue 本文、Issue／PR コメント（Step 3 の計画コメント、`pnpm josh followup` の完了コメントを含む）、Telegram 通知の本文（`--body` / `--notify-message`）
 - **設定に関わらず英語で固定するもの**（3 つ）:
-  1. **Issue／PR タイトル**: Step 1 のタイトル正規化ルールは変更しない。
-  2. **コード内コメント、テストタイトル（`describe` / `it` / `expect`）、コミットメッセージ**。
-  3. **スクリプトが出力する固定文字列**: Telegram のヘッダーラベル（`Planning` / `Completion` など）、`Issue:` / `PR:` の URL ラベル、`--notify-message` 省略時の既定メッセージ。
+  1. Issue／PR タイトル（Step 1 のタイトル正規化ルール）
+  2. コード内コメント、テストタイトル（`describe` / `it` / `expect`）、コミットメッセージ
+  3. スクリプトが出力する固定文字列: Telegram のヘッダーラベル（`Planning` / `Completion` など）、`Issue:` / `PR:` の URL ラベル、`--notify-message` 省略時の既定メッセージ
 
-`JOSH_SESSION_LANG` は **開発者個人の設定**であり、`.env`（gitignore 済み・非コミット）に置く。**設定値は毎ターン `UserPromptSubmit` フック（`scripts/hooks/run-hook.sh session-lang`）が差し込み、未設定なら出さない。** Codex も `.codex/hooks.json` で同じフックを実行する。フックが走らないハーネス（Gemini / Cursor）は `.env` を読む。各既定の理由は `docs/maintainers/overview-rationale.md` → "Why the session language defaults the way it does" にある。
+`JOSH_SESSION_LANG` は開発者個人の設定で、`.env`（gitignore 済み）に置く。設定値は毎ターン `UserPromptSubmit` フック（`scripts/hooks/run-hook.sh session-lang`、Codex は `.codex/hooks.json`）が差し込み、未設定なら出さない。フックが走らないハーネス（Gemini / Cursor）は `.env` を読む。既定の理由は `docs/maintainers/overview-rationale.md` → "Why the session language defaults the way it does"。
 
 ### 配布ドキュメントの層ごとの言語（joshuafolkken/kit#2997）
 
-ドキュメントは**層ごとに 1 つの言語**で書き、1 つの層の中で言語を混ぜない。`JOSH_SESSION_LANG` はこれを変えない。
+ドキュメントは**層ごとに 1 つの言語**で書き、層の中で言語を混ぜない（`JOSH_SESSION_LANG` に依らない）。
 
-| 層                                                                                      | 言語   |
-| --------------------------------------------------------------------------------------- | ------ |
-| `CLAUDE.md`、`AGENTS.md` / `GEMINI.md`、スキル（`.claude/skills/`）、フックが差し込む文 | 英語   |
-| `prompts/` のトピックファイル（次の行の 3 文書を除く）                                  | 日本語 |
-| `prompts/review.md`、`prompts/review-rubric.md`、`prompts/sonar-hotspot-handling.md`    | 英語   |
+- 英語: `CLAUDE.md`、`AGENTS.md` / `GEMINI.md`、スキル（`.claude/skills/`）、フックが差し込む文、`prompts/review.md`、`prompts/review-rubric.md`、`prompts/sonar-hotspot-handling.md`
+- 日本語: それ以外の `prompts/` のトピックファイル
 
-英語の層から日本語のトピックファイルの節を指すポインターは、見出しの先頭に置いた**英語 ID** を引く（例: 見出し `## no-clones — クローン禁止・…` を `principles.md` → "no-clones" で指す）。`pnpm josh doc:section` は見出しの前方一致で節を引くので、ID だけで解決し、`JOSH_SESSION_LANG=en` の利用者や日本語を読まないエージェントにも参照先が読める。ID の無い日本語見出しは原文のまま引く。
+英語の層から日本語のトピックファイルの節を指すときは、見出しの先頭の**英語 ID** を引く（例: `## no-clones — クローン禁止・…` を `principles.md` → "no-clones"。`pnpm josh doc:section` は前方一致で解決する）。ID の無い日本語見出しは原文のまま引く。

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

@@ -1,8 +1,8 @@
 ## Step 3: 計画コメントを記録して通知する
 
 1. 提案を人間が判断する
-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>` でコメント追加する）
-   - **計画が stash の復元を含むとき（会話で先に作った実装を stash でランへ渡す場合を含む）、復元手順には `pnpm josh stash:pop "<メッセージ>"` だけを書く。** `git stash apply` / `git stash pop` と「drop しない」という条件は書かない — 単一ソースは `operating-rules.md` → "no-self-staging"
+2. 採用した計画を Issue に記録する。body が空なら計画をファイルに書き `gh api -X PATCH repos/{owner}/{repo}/issues/<N> --field body=@<path>` で書き込む（本文はパスで渡す — `shell-body.md`）。body があれば `pnpm josh issue:comment <N> --body-file <path>` でコメントする
+   - 計画が stash の復元を含むときの書き方: `operating-rules.md` → "no-self-staging"
 3. Telegram で計画開始を通知する:
 
    ```bash
@@ -10,12 +10,12 @@
    ```
 
    - `--task-type` はヘッダーのアイコンを決める（`planning` 📋 / `completion` ✅ / `failure` ❌ / `warning` ⚠️ / `kickoff_retry` 🔄 / `confirmation` ⏸️）
-   - `warning` は **`pnpm josh followup` が自分で送る種別** であり、手で打つものではない（joshuafolkken/kit#1628）
+   - `warning` は `pnpm josh followup` が自分で送る種別で、手で打たない（joshuafolkken/kit#1628）
    - `--repo-name` と `--issue-title` は未指定なら `gh` から自動取得される
    - Issue URL を必ず含め、箇条書きの間に改行を入れる
-   - `kickoff` コマンドの場合はここで **停止** する（実装に進まない）
+   - `kickoff` はここで**停止**する（実装に進まない）
 
-4. ワークフロー開始時点で作業ツリーにステージング済みまたは変更済みのファイルが既にある場合、先に変更を退避する:
+4. 作業ツリーに変更（ステージ済みを含む）が既にあれば退避する:
    ```bash
    git stash push -u -m "plan: pre-existing changes"
    ```
@@ -23,16 +23,16 @@
    ```bash
    pnpm josh ms
    ```
-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）:
+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 したら、ここでメッセージ指定で復元する（位置指定や引数なしの `git stash pop` は使わない — joshuafolkken/kit#2050）:
    ```bash
    pnpm josh stash:pop "plan: pre-existing changes"
    ```
-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` に従ってリファクタリングを適用する（高・中優先度項目が残らなくなるまで収束させる）
+7. **作業サマリを提示してから**実装を開始する（`report-format.md` → "作業前サマリはいつ・どう出すか"）。Issue body が埋まっていても提示し、Issue コメントとしては投稿しない。
+8. 実装完了後、lint/test より前に `prompts/refactoring.md` に従い、高・中優先度項目が残らなくなるまでリファクタリングする
 9. 検証ゲート（`CLAUDE.md` の Completion gate）を実行する
 
-`pnpm josh git` の基本実行（`-y` で確認プロンプトをスキップ）。**子はバージョンを上げない** — 版を決めるのは `pnpm josh release` ただ 1 箇所である（joshuafolkken/kit#1486）。Issue タイトルは実行前に整える（規則は `issue-template.md` の Step 1 冒頭）。
+`pnpm josh git` を実行する（`-y` で確認プロンプトをスキップ）。**子はバージョンを上げない** — 版を決めるのは `pnpm josh release` だけ（joshuafolkken/kit#1486）。Issue タイトルは実行前に `issue-template.md` の Step 1 冒頭に沿って整える。
 
 ```bash
 pnpm josh git -y "<issue-title> #<issue-number>"
@@ -40,7 +40,7 @@ pnpm josh git -y "<issue-title> #<issue-number>"
 
 ### 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:
+If `pnpm josh git -y` fails at the push step, fix the blocking issue and recover with:
 
 ```bash
 # 1. Push manually after fixing the issue
@@ -51,8 +51,8 @@ pnpm josh pr
 # equivalent: pnpm josh git -y --skip-commit --skip-push
 ```
 
-**Do not** run `gh pr create` directly — it bypasses `build_body` which generates `closes #N`, causing the Issue to remain open after merge.
+Do not run `gh pr create` directly — it bypasses `build_body`, which writes `closes #N`.
 
 ### レビューからマージまで
 
-レビューは実装したセッションが**コミットの前に** `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` の出力で停止しない。**
+レビューは実装したセッションがコミットの前に `pnpm josh review:brief` で始め、`/code-review` は `Agent` ツールのサブエージェントが実行する。周回の上限、残った指摘の振り分けと `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

@@ -1,38 +1,35 @@
 # 原則
 
-**このファイルは、`CLAUDE.md` の Communication 節が指す原則の単一ソースである。** 各節は `CLAUDE.md` から `prompts/collaboration-workflow/principles.md` → "見出し" の形で引かれ、`pnpm josh doc:section` で解決する。経緯と適用例は各節が指す [`docs/maintainers/principles-rationale.md`](../../docs/maintainers/principles-rationale.md) の節にあり、実行中には読まない。
+経緯と適用例は [`docs/maintainers/principles-rationale.md`](../../docs/maintainers/principles-rationale.md) の各節にあり、実行中には読まない。
 
 ## no-clones — クローン禁止・単一ソース化
 
-既存の非自明なロジックを「ソースを変えずに済ませる」ために**コピー・移植・再実装することは既定で禁止**する。すでにどこか（別ファイル・別モジュール・別**パッケージ＝上流依存を含む**）に存在するロジックを複製しようとした瞬間が、**単一ソース化**（全消費者が import する共有モジュール／export／パッケージ）のシグナルである。コピーではなく単一ソース化する。
+既存の非自明なロジック（別ファイル・別モジュール・上流依存を含む別パッケージにあるもの）を、ソースを変えずに済ませるために**コピー・移植・再実装しない**。複製したくなったら、全消費者が import する共有モジュール／export／パッケージへ単一ソース化する。
 
-- **既存の重複は再重複の免罪符にならない**: すでに一度クローンされている（例: josh-game が kit をコピー）なら、共有抽象化はとっくに必要だったということ。3 つ目のコピーを足さず、重複の存在を surface する
-- **「上流を参照する」は「再利用する」の意**であって、「そのコードを貼り付ける」ではない
-- **「X を触るな」という制約はクローンを黙って正当化しない**: クリーンな修正には上流（kit）の変更が要る／代替はクローン、というトレードオフを先にユーザーへ提示する（「クリーンな修正は kit の変更が必要、代替はクローン、どちらにする？」）
-- 複製は、単一ソース化の代替案とそのコストを提示し、**ユーザーの明示承認を得た後にのみ**行う
+- 既存の重複は再重複の理由にならない（例: josh-game が kit をコピー）。3 つ目のコピーを足さず、重複を surface する
+- 「上流を参照する」は再利用することで、コードを貼り付けることではない
+- 「X を触るな」という制約でクローンを黙って正当化しない。「クリーンな修正は kit の変更が必要、代替はクローン、どちらにする？」と先に提示する
+- 複製は、単一ソース化の代替案とコストを提示し、ユーザーの明示承認を得た後にのみ行う
 
-**計測は `pnpm josh clone:scan`。** 同一リポジトリ内および `JOSH_REPO_PATHS` の他リポジトリを跨いだ複製を検出し、**件数**と各複製の `file:line`（`[same-file|cross-file|cross-repo]` 分類つき、複製なしは `clean`）を印字する。`pnpm josh oracle:list` に載る決定オラクルでもある（導入の経緯は `docs/maintainers/principles-rationale.md` → "Why clone:scan exists"）。
+計測は `pnpm josh clone:scan`（`pnpm josh oracle:list` の決定オラクル）。リポジトリ内と `JOSH_REPO_PATHS` の他リポジトリを跨いだ複製の件数と各 `file:line`（`[same-file|cross-file|cross-repo]`、なしは `clean`）を印字する（`docs/maintainers/principles-rationale.md` → "Why clone:scan exists"）。
 
 ## elegant-design — 設計はエレガント・シンプルを第一目標にする
 
-新しい仕組み（フック・ガード・ルール・抽象化）を足す前に、**原因側を直せばその仕組みが要らなくならないか**を先に問う。要らなくなるなら、足さない。症状を叱る仕組みを重ねるのではなく、症状を生んでいる材料を断つ。
+フック・ガード・ルール・抽象化を足す前に、**原因側を直せばその仕組みが要らなくならないか**を問う。要らなくなるなら足さず、原因を直す。検出・通知・叱責を強化する前に、その入力を生んでいる側を断つ。適用例は `docs/maintainers/principles-rationale.md` → "An application of simplicity-first"。
 
-- **問いは 1 つ**: 「この仕組みは、どこかの原因を直せば不要にならないか」。答えが「不要になる」なら、仕組みではなく原因を直す。
-- **足す前に断つ**: 検出・通知・叱責を強化する前に、その入力を生んでいる側を探す。入力が消えれば、それを捌く仕組みそのものが消える。適用例は `docs/maintainers/principles-rationale.md` → "An application of simplicity-first"。
-
-**書かれたコードの可読性**（意図が伝わる命名、過度な抽象化を避ける、など）は `prompts/coding-standards.md` の担当で、こちらは**設計時にどの仕組みを足すか・どこへ置くかを決める**規則。両者は別レイヤーなので、片方の本文をもう片方へ写さず、互いを指すだけにする。
+書かれたコードの可読性は `prompts/coding-standards.md` の担当で、ここはどの仕組みをどこへ足すかの規則である。互いの本文を写さず、指すだけにする。
 
 ## quality-priority — 品質目標が衝突したときの優先順位
 
-品質目標は 3 段に分かれる。上の段は、下の段のために犠牲にしない。
+上の段は、下の段のために犠牲にしない。
 
-1. **正しさ** — 仕様どおりに動き、検証ゲートが緑であること。ほかのどの目標のためにも犠牲にしない
+1. **正しさ** — 仕様どおりに動き、検証ゲートが緑であること
 2. **同列で、どれも悪化させない** — 次の 4 つに上下はない
-   - **複雑さ**（読みやすさを含む）— 初見の読み手が、前提知識なしに意図を追えること。部品や間接層を足すのは、それで読む量が減るときだけにする
-   - **冗長さ**（重複を含む）— 同じ知識を 1 か所に置く（no-clones）。既存の非自明なロジックを複製するときは、no-clones どおり代替案を提示して明示承認を得てから行う
+   - **複雑さ**（読みやすさを含む）— 初見の読み手が前提知識なしに意図を追えること。部品や間接層は読む量が減るときだけ足す
+   - **冗長さ**（重複を含む）— 同じ知識を 1 か所に置く（no-clones）
    - **パフォーマンス** — gate・CI・josh 起動・テストの所要時間
    - **AI コスト** — エージェントが読み込み・出力するトークン量
-3. **コメント最小** — コメントを書きたくなったら、まず命名・分割・型で表現できないかを試す。残すのは「なぜ」だけにする
+3. **コメント最小** — まず命名・分割・型で表現する。残すのは「なぜ」だけ
 
 2 段目の目標同士が衝突したら、次の順で決める。
 
@@ -40,63 +37,63 @@
 2. **1 つを悪くするなら、同じ変更の中で別の場所を削って埋め合わせる** — 合計を悪化させない
 3. **それでも両立しないときは、数字を示して利用者に聞く**（Tier B）— 何をどれだけ悪くして、何を得るか
 
-## consult-vs-execute — 相談と実行を区別する
+## concise-prose — 文章は条件と動作だけを書く
 
-ユーザーが「どう進めるべきか」「何をすべきか」「なぜそうなったか」を尋ねたり、目標・願望を述べたりした（「どうすべき？」「how should we…」「なぜ」「理由を知りたい」「〜したい」「〜の方が良い？」）ときは、**分析と推奨のみ**で応答する。ファイル編集・Issue 作成・その他の具体的アクションは取らない。
+docs・prompts・skills・拒否文・Issue・PR の文章に適用する。
 
-- 具体的アクションを取ってよいのは、明示的な命令（「do it」「書き換えて」「作成して」「implement」）またはワークフローキーワード（`kickoff` / `halfrun` / `prrun` / `fullrun` / `backlogrun`）があるときだけ
-- 発言が相談か実行の指示か判別できないときは、相談として扱う — 分析と推奨を返し、実行の指示を待つ。実行が指示されたあとの判断点で確認するかどうかは、この規則ではなく `CLAUDE.md` → "Decision autonomy" の Tier で決まる
-- **目標の表明は「計画の依頼」であって「実行の承認」ではない**
+- 本文には、いつ何をするか（条件と動作）だけを書く
+- 理由と経緯は rationale 文書に置き、本文からは見出しで指す
+- 太字は 1 節に 1 つまで。箇条書き先頭の見出し語は数えない。`→ "…"` で引かれている太字は消さない
+- 同じ内容を言い換えて繰り返さない
+- ファイルや節が自分自身を説明する文（「このファイルは〜である」）を書かない
 
-## latest-first — 最新優先・fix-forward（pin-back は最終手段）
+導入時のベースラインは `docs/maintainers/principles-rationale.md` → "Why concise-prose exists"。
 
-依存パッケージ・ツールチェーンは**既定で最新版を採用する**。バンプが lint クラッシュ・新規有効化ルール・型エラーなどの破壊を引き起こしても、古いバージョンへ留まる／戻すことを既定の「安全策」にしてはならない。破壊は**前向きに（fix-forward）速やかに**解消する。
+## consult-vs-execute — 相談と実行を区別する
 
-この節が単一ソースで、`dependency-update` skill → "4. When the bump breaks something — fix forward" はここを指す。
+ユーザーが進め方・理由を尋ねたり目標を述べたりした（「どうすべき？」「how should we…」「なぜ」「〜したい」「〜の方が良い？」）ときは、**分析と推奨のみ**を返し、ファイル編集・Issue 作成などのアクションは取らない。目標の表明は計画の依頼であって、実行の承認ではない。
 
-1. **最新優先（latest-first）**: 依存・ツールチェーンは新しいバージョンを既定で採用する。適応の手間を避けるためだけに古いバージョンに留まったり戻したりしない
-2. **破壊は fix-forward**: バンプで lint クラッシュ・新規ルール・型エラー等が出たら、前向きに解消する:
-   - 新ルール／エラーが正当なら **消費者コードを直す**
-   - ルール上書きが要るなら **正しいレイヤー**（kit / app-kit の共有設定）でスコープする。消費者リポジトリでの場当たり的な一回限りの disable にしない
-   - 破壊が first-party パッケージ（kit / app-kit）起因なら、**そこに Issue を立てて適切な altitude で直す**。消費者側の回避だけで済ませない（→ `upstream-interrupt.md`）
-3. **pin-back は最終手段**: fix-forward が本当に不可能／ブロックされている（例: 未リリースの上流修正待ち）ときだけ、古いバージョンへ固定する。固定するときは **理由を記録し、最新へ戻すためのトラッキング Issue を立てる**。pin-back を既定の推奨として提示してはならない
-4. **既存の保護を尊重する**: fix-forward は保護された pin を黙って書き換える許可ではない。overrides と `devEngines` の承認ゲートの単一ソースは `CLAUDE.md` → "Decision autonomy" と `dependency-update` skill である
-5. **タイムリーに**: バンプ起因の破壊は、可能な限り同じ作業セッション内で速やかに対処し、pin の裏に先送りしない
+- アクションを取るのは、明示的な命令（「do it」「書き換えて」「作成して」「implement」）かワークフローキーワード（`kickoff` / `halfrun` / `prrun` / `fullrun` / `backlogrun`）があるときだけ
+- 判別できないときは相談として扱う。実行が指示された後の判断点は `CLAUDE.md` → "Decision autonomy" の Tier で決まる
 
-## durable-rules — 恒久ルールは MEMORY ではなくプロンプト／ドキュメントに書く
+## latest-first — 最新優先・fix-forward（pin-back は最終手段）
+
+依存・ツールチェーンは**既定で最新版を採用する**。`dependency-update` skill → "4. When the bump breaks something — fix forward" はこの節を指す。
 
-今後のセッションでも守るべき恒久的な振る舞いのルールに気付いたときは、**kit が配布するプロンプト／ドキュメント**（`CLAUDE.md` / `prompts/*`）への変更として記述する。プロジェクト単位の自動 MEMORY（例: `~/.claude/projects/<repo-slug>/memory/`）への保存で済ませてはならない。
+1. 適応の手間を避けるために古いバージョンに留まったり戻したりしない
+2. バンプで lint クラッシュ・新規ルール・型エラー等が出たら fix-forward で解消する:
+   - 新ルール／エラーが正当なら消費者コードを直す
+   - ルール上書きが要るなら kit / app-kit の共有設定でスコープする。消費者リポジトリで一回限りの disable にしない
+   - first-party パッケージ（kit / app-kit）起因なら、そこに Issue を立てて直す（→ `upstream-interrupt.md`）
+3. **pin-back は最終手段**: fix-forward が不可能／ブロックされている（例: 未リリースの上流修正待ち）ときだけ固定し、理由を記録して最新へ戻すトラッキング Issue を立てる。pin-back を既定の推奨にしない
+4. fix-forward は保護された pin を黙って書き換える許可ではない。overrides と `devEngines` の承認ゲートは `CLAUDE.md` → "Decision autonomy" と `dependency-update` skill に従う
+5. バンプ起因の破壊は同じセッション内で対処し、pin の裏に先送りしない
 
-- **プロンプト／ドキュメントが正である理由**: バージョン管理下でレビューでき、`josh sync` で全消費者リポジトリ・別の PC・別の AI ツールに届き、`git log` で経緯を追える
-- **MEMORY は 1 台のマシン × 1 つのリポジトリ**にスコープされたローカルストアで、コミットされない。保存は最小限に留め、用途は本質的にローカルな文脈（マシン固有のパス、個人の環境の癖など）だけ。どこでも適用されるべきルールの唯一の置き場所にしてはならない
+## durable-rules — 恒久ルールは MEMORY ではなくプロンプト／ドキュメントに書く
 
-運用:
+共有価値のある恒久ルールに気付いたら、**kit が配布するプロンプト／ドキュメント**（`CLAUDE.md` / `prompts/*`）の変更として書き、自動 MEMORY（`~/.claude/projects/<repo-slug>/memory/`）で済ませない。MEMORY はマシン固有のパスなど本質的にローカルな文脈だけに使う。
 
-1. 恒久ルールに気付いたら、まず「これは kit のドキュメント／プロンプトに書くべきか？」を判定する。共有価値があるなら答えは常に yes
-2. 現在のターンがドキュメント変更を承認していない（相談中など）場合は、**MEMORY に黙って保存せず、プロンプト／ドキュメント変更を提案する**（→「相談と実行を区別する」「配布ドキュメント・設定の変更は kit に上流化する」）
-3. 消費者リポジトリで気付いた場合は、ローカル編集ではなく kit 側へ Issue／PR として上流化する
-4. 既に MEMORY にあるルールが実は共有すべきものだと分かったときは、プロンプト／ドキュメントへ移し、MEMORY 側の重複エントリは削除する
+- ターンがドキュメント変更を承認していない（相談中など）なら、MEMORY に黙って保存せず変更を提案する
+- 消費者リポジトリで気付いたら、kit 側へ Issue／PR として上流化する
+- MEMORY にあるルールが共有すべきものなら、プロンプト／ドキュメントへ移し、MEMORY 側を削除する
 
 ## upstream-to-kit — 配布ドキュメント・設定の変更は kit に上流化する
 
-`CLAUDE.md` および kit が配布する他のドキュメント／設定は、kit から単一ソースで配布される。
-
-- **消費者リポジトリ（app-kit / game-kit）ではこれらをローカル編集しない**: `josh sync` が編集を上書きするうえ、変更は本来上流（kit）に属する。ドキュメント／設定を編集する前に、それが配布物かどうかを確認し、配布物なら kit 側に変更を提案（Issue／PR）する
-- **kit リポジトリ自身ではあなたが配布元**なので、ここでは編集してよい。編集先は `CLAUDE.md` 1 本である（次節）
+- 消費者リポジトリ（app-kit / game-kit）では、kit が配布する `CLAUDE.md` や他のドキュメント／設定をローカル編集しない（`josh sync` が上書きする）。編集前に配布物か確認し、配布物なら kit 側に Issue／PR で提案する
+- kit リポジトリ自身では編集してよい。編集先は `CLAUDE.md` 1 本である（次節）
 
 ## エージェント規則の単一ソースは `CLAUDE.md`（`AGENTS.md` / `GEMINI.md` / `.cursorrules` は導線）
 
-**規則の本体は `CLAUDE.md` にしか無い。** `AGENTS.md`・`GEMINI.md`・`.cursorrules` は「規則は `CLAUDE.md` にある。作業前に全文を読むこと」と「規則を書き戻さない」だけを書いた短い導線文書であり、規則を 1 行も持たない（`.cursorrules` は Svelte MCP の使い方の案内だけを足す）。
+**規則の本体は `CLAUDE.md` にしか無い。** `AGENTS.md`・`GEMINI.md`・`.cursorrules` は「規則は `CLAUDE.md` にある。作業前に全文を読むこと」と「規則を書き戻さない」だけを書いた導線である（`.cursorrules` は Svelte MCP の案内だけを足す）。
 
-- **規則の追加・仕様変更・文言修正・節の追加は `CLAUDE.md` に 1 回だけ書く。** 導線文書には触れない
-- **導線文書に規則を書き戻さない。** そこに書かれた規則は、次の改訂で更新し忘れる 4 つ目の置き場になる
+- 規則の追加・変更・節の追加は `CLAUDE.md` に 1 回だけ書き、導線文書には書き戻さない
 - 経緯と機械的な検査は `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 など別のエージェントは次のように読み替える（joshuafolkken/kit#3079）。
+Codex・Gemini CLI など別のエージェントは `CLAUDE.md` を次のように読み替える（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` が正である
-- **Skill・`/verify-ui`・`/code-review`**: `CLAUDE.md` が skill のロードやサブエージェントでの実行を指示する箇所では、その skill の `SKILL.md` を読み、自分のセッションで従う
-- **`.claude/settings.json` の deny list** は効かない。それが裏付ける `CLAUDE.md` → "Git Rules" はそのまま拘束する
+- **フック**: フックが走らない・出力が見えないツールでは、[`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」の各項目を自分で守る。加えて、最初の実行時コード編集の前に Step 0 の作業サマリを提示し、編集後に `pnpm josh lint:related` と `pnpm josh cspell:dot` を走らせ、`JOSH_SESSION_LANG` を `.env` から解決する。フックの全体は `.claude/settings.json` の `hooks`
+- **Skill・`/verify-ui`・`/code-review`**: その skill の `SKILL.md` を読んで自分のセッションで従う
+- **`.claude/settings.json` の deny list** は効かないが、`CLAUDE.md` → "Git Rules" はそのまま拘束する
 - **`AskUserQuestion`** は、ユーザーに平文で尋ねることを指す

package/prompts/collaboration-workflow/proposal-request.md

@@ -1,14 +1,6 @@
 ## Step 2: 提案依頼（AI 共通）
 
-Issue URL を渡して、次の観点で提案を依頼する。
-
-- 要件の分解
-- 実装候補（複数案がある場合は比較）
-- 影響ファイル
-- テスト方針（unit/e2e）
-- リスクと回避策
-
-最小プロンプト:
+Issue URL を渡して、次の最小プロンプトで提案を依頼する。
 
 ```md
 Issue: <issue-url>

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

@@ -1,37 +1,32 @@
 ## 報告フォーマット（平易な概要 ＋ 技術詳細）
 
-作業前サマリ（Step 7）と完了報告（Step 5）は、**平易な概要を先頭に置き、技術詳細をその下に降格する 2 層構造**で書く。ここが横断ドキュメント（`CLAUDE.md`）のカノニカル参照。
+作業前サマリ（Step 7）と完了報告（Step 5）は、**平易な概要を先頭に置き、技術詳細をその下に置く 2 層構造**で書く。
 
 ### 機械的な半分は `josh report:lint` が検査する
 
-ラベルの有無、概要行の字数上限、コードフェンス囲みでないこと、概要へのファイルパス・CLI フラグの混入、ケース段と「壊れるとしたら」段の形は、サマリを標準入力で `pnpm josh report:lint` に渡して検査する（`ok` か違反行を印字する。判定の一次ソースはコマンド側の定数 — joshuafolkken/kit#2123）。この文書に残るのは、テンプレートと、機械には答えられない判断（下記「具体的な主語を必ず書く」）である。
+ラベルの有無、概要行の字数上限、コードフェンス囲み、概要へのファイルパス・CLI フラグの混入、ケース段と「壊れるとしたら」段の形は、サマリを標準入力で `pnpm josh report:lint` に渡して検査する（`ok` か違反行を印字する — joshuafolkken/kit#2123）。
 
 ### 出力はコードフェンスで囲まない（必須）
 
-以下のテンプレートは **フェンスの中身だけ**をセッションに書く（空白での桁揃えと単独行の `---` も使わない）。
+以下のテンプレートは**フェンスの中身だけ**をセッションに書く（空白での桁揃えと単独行の `---` も使わない）。
 
 ### ラベルはセッション言語に訳し、注釈は付けない（必須）
 
-**(1) ラベルはセッション言語に訳す。** 英語のまま残すのは誤り。日本語セッションでの対応:
+**(1) ラベルはセッション言語に訳す。** 日本語セッションでの対応:
 
-| 英語ドキュメントのラベル                                 | 日本語セッションでの表記                                              |
-| -------------------------------------------------------- | --------------------------------------------------------------------- |
-| `■ Overview`                                             | `■ 概要`                                                              |
-| `Now` / `Change` / `Check`                               | `今こうなっている` / `こう直す` / `確かめ方`                          |
-| `Details`                                                | `技術詳細`                                                            |
-| `Changes and tests`                                      | `変更とテスト`                                                        |
-| `Cause` / `Fix` / `Result`（完了報告）                   | `原因` / `対応` / `結果`                                              |
-| `■ Hand-off`（区切り）                                   | `■ 区切り`                                                            |
-| `Done` / `Remaining` / `Why it stopped` / `Next command` | `終わったこと` / `残っていること` / `止めた理由` / `次に打つコマンド` |
+- `■ Overview` → `■ 概要`
+- `Now` / `Change` / `Check` → `今こうなっている` / `こう直す` / `確かめ方`
+- `Details` → `技術詳細`、`Changes and tests` → `変更とテスト`
+- `Cause` / `Fix` / `Result`（完了報告）→ `原因` / `対応` / `結果`
+- `■ Hand-off`（区切り）→ `■ 区切り`
+- `Done` / `Remaining` / `Why it stopped` / `Next command` → `終わったこと` / `残っていること` / `止めた理由` / `次に打つコマンド`
 
-成果物の散文（Issue 本文、Issue／PR コメント、Telegram 本文）の中のラベルもこの表に従って訳す。英語のまま残るのは「出力の言語（`JOSH_SESSION_LANG`）」が挙げた 3 つだけである。
+成果物の散文（Issue 本文、Issue／PR コメント、Telegram 本文）のラベルもこの表で訳す。英語のまま残るのは「出力の言語（`JOSH_SESSION_LANG`）」が挙げた 3 つだけ。
 
-**(2) ラベルに注釈を付けない。** `■ 概要（平易な説明）` は誤り。注意書きはラベルではなく、ラベルの下の説明文に置く。
+**(2) ラベルに注釈を付けない。** `■ 概要（平易な説明）` は誤り。注意書きはラベルの下の説明文に置く。
 
 ### 作業前サマリはいつ・どう出すか
 
-`CLAUDE.md` → "Code Change Rules" の Step 0 が指す細目の単一ソース。
-
 - **いつ**: 実装コードを書く前に、Issue ごとに 1 回出す。`fullrun` / `halfrun` / `prrun` / `backlogrun` で必須、`kickoff` は対象外。確認のための停止ではない — 出したらそのまま実装に進む
 - **概要**: `Now` / `Change` / `Check` を各 1 文、セッション言語で、プログラマでない人にも追える文で書く。各行に具体的な主語を書き、主語のない文は不可（下記「具体的な主語を必ず書く」）。ファイルパス・関数名や型名・CLI のオプションフラグは書かない — 禁じるのは内部識別子だけである
 - **技術詳細**: すべての変更をそのテストとともに `<変更内容> — Test: <Unit|E2E> — <file path> — <検証する挙動>` の形で並べる
@@ -64,20 +59,20 @@
 2. ...
 ```
 
-**テスト宣言はケース単位の 2 段で書く（joshuafolkken/kit#2246）。**
+テスト宣言はケース単位の 2 段で書く（joshuafolkken/kit#2246）。
 
-- **第 1 段（ケース）** は固定語彙を並べ、**該当しないものは `該当なし` に続けて理由を書いて消す**。効くのは消した行で、漏れが「考えなかった」から「考えて外した」に変わる
-- **第 2 段（壊れるとしたら）** は、この変更に固有の壊れうる条件を**最低 3 件**書く。書けないときは `どう呼ばれても壊れない` と明示する
-- 1 ケース＝1 テスト関数ではない。複数ケースは `it.each` 1 本に畳んでよい
-- **境界の必須異常系はコマンドが答える。** 差分が HTTP・プロセス起動・ファイル IO・時間の境界を跨ぐとき、`pnpm josh cases <path...>` が印字する異常系を第 2 段に載せる（ユニットスイートはネットワークを遮断しているため、宣言の側で突きつけるしかない）
+- 第 1 段（ケース）は固定語彙を並べ、**該当しないものは `該当なし` に続けて理由を書いて消す**
+- 第 2 段（壊れるとしたら）は、この変更に固有の壊れうる条件を**最低 3 件**書く。書けないときは `どう呼ばれても壊れない` と明示する
+- 複数ケースは `it.each` 1 本に畳んでよい
+- 差分が HTTP・プロセス起動・ファイル IO・時間の境界を跨ぐときは、`pnpm josh cases <path...>` が印字する異常系を第 2 段に載せる
 
 ### 行数予算は編集前に読む
 
-**「対象」に書くファイルは、書き始める前に `pnpm josh lines <path> [<path>...]` に渡し、上限に近いと言われたファイルには、その場で分割方針を「対象」に書く**（事後の `max-lines` 対応は run 時間の約 2 割を食っていた — joshuafolkken/kit#1425）。近いかどうかと行数はコマンドの答えであり、`wc -l` では数えない。関数単位の上限は `pnpm josh lint` が報告する。
+**「対象」に書くファイルは、書き始める前に `pnpm josh lines <path> [<path>...]` に渡し、上限に近いと言われたファイルには分割方針を「対象」に書く**（joshuafolkken/kit#1425）。行数は `wc -l` で数えない。関数単位の上限は `pnpm josh lint` が報告する。
 
 ### 変更対象はまとめて読んでから編集する（joshuafolkken/kit#2202）
 
-**「変更とテスト」が変更対象ファイルを列挙した直後、それらを 1 回の `pnpm josh read:files <path> [<path> ...]` で読み、続く独立した編集は 1 回の `pnpm josh edit:files -` で送る**（個別の `Edit` に戻すのは依存する編集・1 件だけの編集・`Write` のとき）。単一ソースは [`turn-batching.md`](turn-batching.md) →「実装中の独立編集に効く合成コマンド」。
+**「変更とテスト」が変更対象ファイルを列挙したら、1 回の `pnpm josh read:files <path> [<path> ...]` で読み、続く独立した編集は 1 回の `pnpm josh edit:files -` で送る**（個別の `Edit` は依存する編集・1 件だけの編集・`Write` のとき）。詳細は [`turn-batching.md`](turn-batching.md) →「実装中の独立編集に効く合成コマンド」。
 
 ### 完了報告（セッション向け）
 
@@ -97,42 +92,32 @@
 - 残課題: <なければ「なし」>
 ```
 
-**実行証跡は「動くこと」の証拠であり、gate の緑ではない（joshuafolkken/kit#2246）。** 同じ証跡を PR 本文の `## 実機証跡` 節（コマンド＋実出力のフェンス）にも置く。無い実行時の変更は `pnpm josh followup` がマージを拒否する（#2446）。
+**実行証跡は「動くこと」の証拠であり、gate の緑ではない**（joshuafolkken/kit#2246）。同じ証跡を PR 本文の `## 実機証跡` 節（コマンド＋実出力のフェンス）にも置く。無い実行時の変更は `pnpm josh followup` がマージを拒否する（#2446）。
 
-**`run:carry` の実行証跡は `JOSH_TEMP_ROOT` を新しい一時ディレクトリに向けて取る（必須）。** run の状態レコードは、走っている本物の run と共有の 1 か所にあり、作業ディレクトリを移しても `pnpm --dir` を使っても切り離せない。変数は起動時に読まれるので、`JOSH_TEMP_ROOT="$(mktemp -d)" pnpm josh run:carry --begin …` のように各コマンドの頭に付ける（`docs/environment-variables.md` → "Runs"）。**`run:merge` はこれで切り離せない** — レコードの他に main の同期・lane の close・GitHub への書き込みを行うため、一時ルートを変えても本物の run の共有状態に触れる。
+**`run:carry` の実行証跡は `JOSH_TEMP_ROOT` を新しい一時ディレクトリに向けて取る（必須）。** 状態レコードは本物の run と共有なので、`JOSH_TEMP_ROOT="$(mktemp -d)" pnpm josh run:carry --begin …` のように各コマンドの頭に付ける（`docs/environment-variables.md` → "Runs"）。`run:merge` は main の同期・lane の close・GitHub への書き込みを行うため、これでは切り離せない。
 
 ### 区切りの報告（完了報告と区別する・必須）
 
-`backlogrun` の**区切り**（hand-off）は完了報告ではない — **`原因` / `対応` / `結果` を使わない**。書式は [`.claude/skills/workflow-commands/backlogrun-handoff-report.md`](../../.claude/skills/workflow-commands/backlogrun-handoff-report.md)。
+`backlogrun` の区切り（hand-off）は完了報告ではない — **`原因` / `対応` / `結果` を使わない**。書式は [`.claude/skills/workflow-commands/backlogrun-handoff-report.md`](../../.claude/skills/workflow-commands/backlogrun-handoff-report.md)。
 
 ### 概要 3 行の書き方（ここが本体）
 
-字数と内部識別子の混入は `report:lint` が検査する。長さ制限だけでは平易にならないので、**語彙と抽象度を制約する**:
+字数と内部識別子の混入は `report:lint` が検査する。平易にするために語彙と抽象度を制約する:
 
 - 専門用語は使わないか、`〜（＝…のこと）` の形でその場で言い換える
-- 変更点の羅列ではなく **原因 → 対応 → 効果の因果**で書く
-- 主語は利用者・システムの振る舞い。「利用者から見て何が違うか」が書けないなら、その行はまだ技術詳細のまま
+- 変更点の羅列ではなく、原因 → 対応 → 効果の因果で書く
+- 主語は利用者・システムの振る舞い。「利用者から見て何が違うか」が書けない行は技術詳細に置く
 
-**送信前セルフチェック**: コードを見ていない読み手が、概要 3 行だけで**どれの話か特定できるか**。できないなら具体的な名詞を 1 つ足す。
+**送信前セルフチェック**: コードを見ていない読み手が、概要 3 行だけでどれの話か特定できるか。できないなら具体的な名詞を 1 つ足す。
 
 ### 具体的な主語を必ず書く（禁止と対になる要求）
 
-「書かない」規則だけを守ると、**何の話か特定できない**概要になる。そこで禁止と対になる要求を置く:
-
-- **何かが「古い」「壊れている」「変わらない」と書くときは、その対象を名指しする。** 対象パッケージ名・画面名・出力の種類のいずれかを必ず含める
-- **主語のない「状況」「案内」「問題」「その処理」だけで済ませない。**
-- **書いてよい具体名**: 利用者が画面で目にするもの — パッケージ名、表示されるコマンドの目的、画面名、メッセージの種類
-- **書いてはいけない具体名**: 内部識別子のみ — ファイルパス、関数名・型名、CLI のオプションフラグ
+- **何かが「古い」「壊れている」「変わらない」と書くときは、その対象を名指しする** — 対象パッケージ名・画面名・出力の種類のいずれかを含める
+- 主語のない「状況」「案内」「問題」「その処理」だけで済ませない
+- 書いてよい具体名: 利用者が画面で目にするもの — パッケージ名、表示されるコマンドの目的、画面名、メッセージの種類
+- 書いてはいけない具体名: 内部識別子 — ファイルパス、関数名・型名、CLI のオプションフラグ
 
-**悪い例**（何の話か特定できない）:
-
-```md
-- **今こうなっている**: 古いままだと警告が出るのに、案内されたコマンドを実行しても状況が変わらないことがある。
-- **こう直す**: 効き目のない案内は理由の説明に置き換え、同じ案内が何度も並ぶのもやめる。
-- **確かめ方**: 自動テストで、無駄な案内が消え・重複が消え・従来の表示は変わらないことを確かめる。
-```
-
-**良い例**（同じ内容で、対象を名指ししている）:
+悪い例は「古いままだと警告が出るのに、案内されたコマンドを実行しても状況が変わらない」（何の話か特定できない）。良い例:
 
 ```md
 - **今こうなっている**: バージョン確認が「全体で使う app-kit が古い」と警告するのに、一緒に出る更新コマンドは既に入っている版を指していて、実行しても何も変わらず同じ警告がまた出る。
@@ -140,8 +125,6 @@
 - **確かめ方**: 自動テストで、効かないコマンドが説明に置き換わり、重複が 1 行になり、通常の表示は変わらないことを確かめる。
 ```
 
-違いは長さではなく、**名指ししているかどうか**にある。良い例には内部識別子は 1 つも出てこない。
-
 ### 成果物（Issue / PR / Telegram）側
 
-言語は「出力の言語（`JOSH_SESSION_LANG`）」に従い、**構造も**セッション向けと同じ 2 層にする。`--notify-message` は `Added ... / Changed ...` の羅列ではなく、`Cause / Fix / Result` の 3 行を先頭に置き、変更点の箇条書きを `Details:` 以下にまとめる（実例は [`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,37 +1,37 @@
 ## 常駐ドキュメントと skill の分担（何を常駐に残すか）
 
-**規則をどこに書くか、常駐にどこまで残すかの判定は、このファイルが単一ソースである**（joshuafolkken/kit#2891）。`CLAUDE.md` はすべてのエージェント規則の入口で、`AGENTS.md` / `GEMINI.md` / `.cursorrules` はそこへの導線である。規則のトリガは `CLAUDE.md` に **1 度だけ**、手順と数値は導線の先に **1 度だけ**書く。`CLAUDE.md` の経緯は `docs/maintainers/claude-md-history.md` にある。**規則を散文で書く前に**、下の問いで置き場所を決める — 計算できる答えは `pnpm josh oracle:list` のコマンドへ、順序は `pnpm josh run:step` へ。**読むのは規則を置く・移す・引退させるターンだけ**である。`CLAUDE.md` は毎ターン全文が読み込まれ、上限は `scripts/document/resident-budget.ts` の `RESIDENT_CEILING_BYTES`（残りは `pnpm josh bytes CLAUDE.md`）。**置き場所は書き手の重要度判断ではなく、下の 4 つの問いを順に当てて決める。** 経緯・一覧・作例は `docs/maintainers/residency-rationale.md` にある。
+規則を置く・移す・引退させるターンに読む（joshuafolkken/kit#2891）。規則のトリガは `CLAUDE.md` に 1 度だけ、手順と数値は導線の先に 1 度だけ書く。`CLAUDE.md` の上限は `scripts/document/resident-budget.ts` の `RESIDENT_CEILING_BYTES`（残りは `pnpm josh bytes CLAUDE.md`）。**置き場所は重要度ではなく、下の問いを順に当てて決める。** 経緯は `docs/maintainers/claude-md-history.md` と `docs/maintainers/residency-rationale.md`。
 
 ### 第 0 問（先に問う）
 
 > **その規則の答えは、機械的に読める入力だけから計算できるか。**
 
-**できるなら、コマンドが答える。** 文書には「このコマンドに聞け」の導線 1 行だけを置く。既存のオラクルは `pnpm josh oracle:list`、単一ソースは `scripts/rules/decision-oracle.ts`。
+できるなら、コマンドが答え、文書には導線 1 行だけを置く。既存のオラクルは `pnpm josh oracle:list`、単一ソースは `scripts/rules/decision-oracle.ts`。
 
 ### 順序の問い（第 0 問の次に問う）
 
 > **その規則は「何を」ではなく「いつ・どの順で・どの引数で」を決めているか。**
 
-**そうであれば、規則はドライバの状態遷移に書き、散文には書かない。** `pnpm josh run:step <N>` が次の 1 手を計算する（`scripts/run/run-step.ts`、joshuafolkken/kit#2248）。文書は導線 1 行を張るだけである。
+そうであれば、規則はドライバの状態遷移に書き、文書は導線 1 行だけにする。`pnpm josh run:step <N>` が次の 1 手を計算する（`scripts/run/run-step.ts`、joshuafolkken/kit#2248）。
 
 ### 第 1 問 — 引き金を名指しできるか
 
 > **その規則が効き始める瞬間を、1 件のツール呼び出しとして名指しできるか。**
 
-**名指しできる規則は、規則本文を常駐から出し、配送ガードの行に `scripts/rules/rule-registry.ts` の項目を添え、[`rule-delivery.md`](./rule-delivery.md) が指す `pnpm josh rule:list` の一覧に載せる**（joshuafolkken/kit#1524）。**規則ごとのトリガ行は常駐に残さない** — `CLAUDE.md` が持つのは一覧への導線 1 行だけで、フックが走らないセッションはその一覧を自己点検に適用する（`principles.md` →「Claude Code 以外のエージェントでの読み替え」）。根拠は `docs/maintainers/residency-rationale.md` → "Why a delivered rule leaves no resident line"。
+できるなら、規則本文を常駐から出し、配送ガードの行に `scripts/rules/rule-registry.ts` の項目を添え、[`rule-delivery.md`](./rule-delivery.md) が指す `pnpm josh rule:list` の一覧に載せる（joshuafolkken/kit#1524）。**規則ごとのトリガ行は常駐に残さない** — `CLAUDE.md` には一覧への導線 1 行だけを置く。フックが走らないセッションは一覧を自己点検に使う（`principles.md` →「Claude Code 以外のエージェントでの読み替え」）。根拠は `docs/maintainers/residency-rationale.md` → "Why a delivered rule leaves no resident line"。
 
 ### 第 2 問 — skill なしのターンでも効く必要があるか
 
 > **その規則は、skill がロードされていないターンでも効く必要があるか。**
 
-**`CLAUDE.md` に残るのは、skill がロードされていないターンでも効く必要がある規則だけである。** 入力は「最初に効くのはコマンド開始の前か後か」の 1 点で、規則の重要さは入力に含まれない。後なら `CLAUDE.md` から導線を張り、再掲しない。
+**`CLAUDE.md` に残るのは、skill がロードされていないターンでも効く必要がある規則だけである。** 入力は「最初に効くのはコマンド開始の前か後か」の 1 点。後なら `CLAUDE.md` から導線を張り、再掲しない。
 
 ### 残すときの書き方と予算
 
 - **常駐規則は、トリガと導線の 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 条件を示した上でユーザーの明示指示を得てから行う。
+- **削ることは移すことであり、削除は理由を示して初めて許される例外である。** 先に導線の先へ移し、マーカーテストも付け替える。引退の 3 条件は `docs/maintainers/residency-rationale.md` → "Trigger and pointer, and the narrow retirement route"
+- 経緯（Issue 番号・なぜ・計測・却下案）は `docs/maintainers/<topic>-rationale.md` に置く。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` → "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"。
+常駐に残る規則と配送へ移した規則の一覧は `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"。

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

@@ -1,31 +1,31 @@
 # 引き金つき配送 — 規則を「効く瞬間」に届ける（joshuafolkken/kit#1524）
 
-規則の届け方は 2 つある。**常駐**（`CLAUDE.md` に書き、毎ターン読み込ませる）と、**引き金つき配送**（規則が効く瞬間にフックが本文を突きつける）である。この文書は後者の単一ソースである。配線・判定の細部と経緯は `docs/maintainers/rule-delivery-rationale.md` にあり、ランの途中で読む必要はない。
+規則の届け方は**常駐**（`CLAUDE.md` に書き毎ターン読み込ませる）と**引き金つき配送**（効く瞬間にフックが本文を突きつける）の 2 つ。
 
 ## なぜ配送が要るのか
 
-常駐の経路は実効上限で詰まっており、配送は該当する瞬間だけのコストで届き、拒否は読み飛ばせず、発火を単体テストで固定できる。経緯: `docs/maintainers/rule-delivery-rationale.md` → "Why delivery is needed"。
+`docs/maintainers/rule-delivery-rationale.md` → "Why delivery is needed"。
 
 ## 判定基準 — 引き金を特定できるか
 
-どの規則を配送へ移すかの単一ソースは [`residency.md`](./residency.md) →「第 1 問」であり、ここには写さない。
+どの規則を配送へ移すかは [`residency.md`](./residency.md) →「第 1 問」に従う。
 
 ## 機構 — 1 本だけ、新規に作らない
 
-配送はすべて 1 つの土台に載り、入口はイベントごとに 2 つある。`PreToolUse` の入口が `pnpm josh pretool:guard`（バッチング ／ 調査 ／ 規則の 3 ガードを 1 プロセスで合成）、Stop フックの入口が `pnpm josh stop:guard` である。**2 本目の配送経路を作るのは `CLAUDE.md` →「No clones」が禁じるクローン**である。**配送は拒否とは限らず、呼び出しの書き換え（`updatedInput`）でもよい** — 規則の結果そのものを機械的に作れる形に限る。書き換えはフックが添える注記で記録され、`pnpm josh rule:value` が `rewritten` として数える。配線・停止スイッチ・拒否の優先順位: `docs/maintainers/rule-delivery-rationale.md` → "The mechanism"。
+入口は `PreToolUse` の `pnpm josh pretool:guard`（バッチング ／ 調査 ／ 規則の 3 ガード）と Stop フックの `pnpm josh stop:guard` の 2 つ。**2 本目の配送経路を作るのは `CLAUDE.md` →「No clones」が禁じるクローン**である。配送は呼び出しの書き換え（`updatedInput`）でもよい — 規則の結果そのものを機械的に作れる形に限る。書き換えは `pnpm josh rule:value` が `rewritten` として数える。配線・停止スイッチ・拒否の優先順位: `docs/maintainers/rule-delivery-rationale.md` → "The mechanism"。
 
 ## 配送されている規則
 
-一覧は `pnpm josh rule:list` が `scripts/rules/delivered-rules.ts` の行から生成する（joshuafolkken/kit#3399）。各項目は規則の単一ソース・発火点・発火しないときを持ち、フックが走らないエージェントはその出力を自己適用のチェックリストにする（`principles.md`）。
+一覧は `pnpm josh rule:list` が `scripts/rules/delivered-rules.ts` から生成する（joshuafolkken/kit#3399）。各項目は規則の単一ソース・発火点・発火しないときを持ち、フックが走らないエージェントはその出力を自己適用のチェックリストにする（`principles.md`）。
 
-**引き金はシェルのコマンド文字列しか見えない**（node 内の REST や `gh api --input <file>` は掛からない）。だから常駐側にトリガ 1 行を残し、配送はそれを効く瞬間に補強する。経緯: `docs/maintainers/rule-delivery-rationale.md` → "Shell evaluation of a body is one more row of the same mechanism"。
+**引き金はシェルのコマンド文字列しか見えない**（node 内の REST や `gh api --input <file>` は掛からない）ので、常駐側にトリガ 1 行を残す（`docs/maintainers/rule-delivery-rationale.md` → "Shell evaluation of a body is one more row of the same mechanism"）。
 
-**「引き金が発火しないターンでは何も起きない」ことは仕様である。** 各項目の発火しない状態は「規則が守られている状態」と一致する。一致が取れない規則は常駐に残す。**誤ったターンで発火するフックは、フックが無いより悪い。**
+引き金が発火しないターンでは何も起きないのが仕様で、各項目の発火しない状態は「規則が守られている状態」と一致させる。一致が取れない規則は常駐に残す。
 
 ## 配送は 1 ラン 1 回
 
-配送文は**ラン 1 回につき 1 度**しか出ないので、**「同じ呼び出しをもう一度出せ」と明記する**。例外は 2 つで、繰り返す行為を止める項目は毎回発火し（joshuafolkken/kit#1570）、前提の行為を求める項目は前提が末尾に現れるまで毎回拒否する（joshuafolkken/kit#2807）。その配送文にはそれぞれ「これは毎回発火する」「前提が末尾に現れるまで拒否する」と明記する。バッチングと調査の 2 ガードは違反が間隔分続けば再び発火する（joshuafolkken/kit#2164）。前提の証拠を読めないときは拒否を基本とする。経緯: `docs/maintainers/rule-delivery-rationale.md` → "One delivery per run"。
+配送文はラン 1 回につき 1 度しか出ないので、**「同じ呼び出しをもう一度出せ」と明記する**。例外: 繰り返す行為を止める項目は毎回発火し（joshuafolkken/kit#1570）、前提の行為を求める項目は前提が末尾に現れるまで毎回拒否する（joshuafolkken/kit#2807）— その配送文にはそれぞれ「これは毎回発火する」「前提が末尾に現れるまで拒否する」と明記する。バッチングと調査の 2 ガードは違反が間隔分続けば再び発火する（joshuafolkken/kit#2164）。前提の証拠を読めないときは拒否する。経緯: `docs/maintainers/rule-delivery-rationale.md` → "One delivery per run"。配送文の長さの上限と経緯の置き場所: `docs/maintainers/rule-delivery-rationale.md` → "Why a refusal is the action and the next command"。
 
 ## マーカーテスト
 
-各項目を固定するスイートの一覧: `docs/maintainers/rule-delivery-rationale.md` → "Marker tests"。
+`docs/maintainers/rule-delivery-rationale.md` → "Marker tests"。