@joshuafolkken/kit 1.1128.0 → 1.1166.0

package/prompts/collaboration-workflow/output-bounds.md

@@ -1,10 +1,6 @@
 # コマンド出力が文脈へ持ち込む量の上限（joshuafolkken/kit#1173）
 
-**上限は機構で決まり、実行側の判断には委ねられない。** どのコマンドが何行返すかは実行前には分からないので、「たぶん短いだろう」と推測して絞るかどうかを決める形は、費用の圧力が高いときほど「これくらいなら素通しでよい」へ倒れる。joshuafolkken/kit#1094 が「区切りを判断ではなく機構にする」と述べたのと同じ原則を、出力側へ適用したものである。
-
-## 何をしているか
-
-配布される `.claude/settings.json` の `env` ブロックが `BASH_MAX_OUTPUT_LENGTH` を宣言する。Claude Code は Bash ツールの出力がこの文字数を超えると真ん中を省略して渡すので、**1 回のコマンドが文脈へ持ち込む量に harness 側で上限が掛かる**。エージェントは何も判断しない。
+**上限は機構で決まり、実行側の判断には委ねられない。** 配布される `.claude/settings.json` の `env` ブロックが `BASH_MAX_OUTPUT_LENGTH` を宣言し、Claude Code は Bash ツールの出力がこの文字数を超えると真ん中を省略して渡す。
 
 ```json
 "env": {
@@ -12,96 +8,34 @@
 }
 ```
 
-**8,000 文字。** harness の既定は 30,000 文字、受け付ける最大は 150,000 文字である（`claude` バイナリ内の `default:30000, upperLimit:150000`）。
-
-## なぜ既定の 30,000 では足りないか
-
-直近 25 セッション・tool_result 2,333 件を実測した。**Bash の出力は tool_result トークンの 87.5%（1,848 件・1,241,642 トークン）**を占める。その 1,848 件のうち **30,000 文字を超えたものは 0 件**だった — 既定の上限はこのプロジェクトで一度も作動していない。存在するが届かない上限は、上限が無いのと同じである。
-
-Bash 出力の長さの分布（文字数）: p50 = 570 / p75 = 1,920 / p90 = 4,421 / p95 = 8,342 / p99 = 15,989 / 最大 = 28,908。
-
-上限ごとに、真ん中を省略したときに削れる量:
-
-| 上限（文字）   | 該当する呼び出し  | 削れる量（tool_result 全体に対して） |
-| -------------- | ----------------- | ------------------------------------ |
-| 4,000          | 218 件（11.8%）   | 26.6%                                |
-| 6,000          | 124 件（6.7%）    | 18.2%                                |
-| **8,000**      | **95 件（5.1%）** | **12.7%**                            |
-| 10,000         | 69 件（3.7%）     | 8.7%                                 |
-| 15,000         | 22 件（1.2%）     | 2.5%                                 |
-| 30,000（既定） | 0 件              | 0%                                   |
-
-**8,000 を採ったのは p95 だからである。** 20 回に 19 回はこれまでと何も変わらず、残る 1 回だけが範囲を指定して読み直す形になる。4,000 は削れる量こそ倍だが 8 回に 1 回が切り詰められ、読み直しの往復が上限で浮かせた分を食い返す。
-
-## 却下した案と、その理由
-
-- **非有界コマンドを PreToolUse guard が拒否する。** 実測が否定した。tool_result の上位には `cd`（5.4%）と `for`（4.4%）が入り、先頭語を見ても正体が分からない — 命令は `cd <dir> && …` や `for n in …; do …; done` の内側にある。さらに 2 位の `sed`（16.6%）は本 Issue が推奨する範囲指定の形そのもので、構文上は有界なのに 1 ブロック 8,000 トークンを運んでいる（`sed -n '30,400p'`）。**形で見分ける案は、実データ上で外れる。** 大きさで切る案にはこの弱点がない。
-- **共通ラッパで切り詰める（`josh` のサブコマンド等）。** ラッパを通すかどうかが実行側の判断になり、本 Issue が問題視した構造がそのまま残る。上限を機構にするという要件を満たさない。
+**8,000 文字**（harness の既定は 30,000、受け付ける最大は 150,000）。値の根拠となった分布と却下した案は `docs/maintainers/output-bounds-rationale.md` → "Why 8,000"。上限は **Bash ツールにだけ効き**、`Read` と `Agent` の結果には効かない。
 
 ## 切り詰められたときにどうするか
 
 **情報を落とすのではなく、必要な範囲に合わせて読み直す。** 同じコマンドを再実行しても上限は同じなので、絞り込んで読む:
 
 - ファイルなら範囲を指定する（`sed -n '120,180p' <file>`）か、`Read` ツールの `offset` / `limit` を使う
-- 一覧なら件数を絞る（`--limit`、`| head -30`）
-- JSON なら必要な項目だけ取り出す（`gh api … --jq '…'`）
+- 一覧なら件数を絞る（`--limit`、`| head -30`）、JSON なら必要な項目だけ取り出す（`gh api … --jq '…'`）
 - どうしても全量が要るときは、いったんファイルへ落として（`> <file>`）から範囲を読む
 
 ## 切り詰められた出力を、完全な出力として読まない
 
-**検証ゲートと差分は、切り詰められた結果で判断しない。** 上限は harness が掛けるので、`pnpm josh gate` の出力も `git diff main...HEAD` も等しく対象になる。両者の性質は違い、危険なのは後者である。
+**検証ゲートと差分は、切り詰められた結果で判断しない。** 省略された箇所には harness がマーカーを残す — それは「短い出力」ではなく「一部しか読んでいない出力」である。
 
-- **`pnpm josh gate` は判定そのものは失わない。** 真ん中が省略されても先頭と末尾は残り、合否の 1 行（`✔ verification gate passed` / `✗ verification gate failed: …`）は末尾に出るので、赤いゲートが緑に見えることはない。**失われうるのは失敗の内訳だが、それはもうコンソールだけの存在ではない**（joshuafolkken/kit#1227）。ゲートは毎回、全チェックの全文を一時ディレクトリのファイルへ書き、その場所を合否行の直前に `full output: <path>` として出す。切り詰めのマーカーを見たらそのパスを読む — 個別のチェックを single で回し直すのは、機構が入る前の暫定の答えだった。記録済みの緑を再利用してスキップしたときはこの 2 行が出ず `✔ this tree is already green …` だけになるが、出力そのものが 2 行なので切り詰めの対象にならず、かつ緑のときにしか出ない（joshuafolkken/kit#1328）。
-- **差分には判定行が無い。** `git diff` が切り詰められると、抜けた hunk があること自体は省略マーカーで分かるが、抜けた内容は復元されない。自己レビューの対象が欠けたまま「指摘なし」と結論づけるのは、ゲートを弱めたのと同じである。**差分はファイルへ落としてから範囲で読む。**
-
-```bash
-git diff main...HEAD > /tmp/diff.patch && wc -l /tmp/diff.patch
-```
-
-**切り詰めは黙って起きない** — 省略された箇所には harness がマーカーを残す。マーカーを見たら、それは「短い出力」ではなく「一部しか読んでいない出力」である。
+- **`pnpm josh gate`** は合否の 1 行を末尾に出すので判定は失われない。失敗の内訳が切れたら、合否行の直前に出る **`full output: <path>` のファイルを読む**（joshuafolkken/kit#1227）
+- **差分には判定行が無い。** 欠けた差分で「指摘なし」とするのはゲートを弱めたのと同じなので、**差分はファイルへ落としてから範囲で読む**（`git diff main...HEAD > /tmp/diff.patch && wc -l /tmp/diff.patch`）
 
 ## 検証コマンドをパイプに繋がない（joshuafolkken/kit#1556）
 
-**パイプラインの終了コードは最後のコマンドのものである。** `pnpm josh gate 2>&1 | tail -40` は `tail` の終了コードで終わるので、**赤いゲートがシェルの上では成功として返る。**
-
-joshuafolkken/kit#1546 の実行中に実際に起きた。2 回目のゲートが `✗ verification gate failed` を印字しながら、パイプラインは 0 を返していた。失敗は本物（Prettier の整形と、マーカーテスト 1 件）で、**実行した子が出力を読んでいたから気づいた**。終了コードだけを見ていれば、赤いツリーがそのままコミットされていた。
+**パイプラインの終了コードは最後のコマンドのものである。** `pnpm josh gate 2>&1 | tail -40` は `tail` の終了コードで終わるので、**赤いゲートがシェルの上では成功として返る。** **これは `josh gate` の欠陥ではない。** POSIX どおりの挙動であり、直すべきは呼び出し方である。
 
-**これは `josh gate` の欠陥ではない。** 非ゼロは正しく返っており、パイプラインの終了コードが最後のコマンドのものになるのは POSIX シェルの規定どおりの挙動である。**直すべきはコマンドではなく、呼び出し方である。**
-
-### どう呼ぶか
-
-- **既定はパイプなしで実行する。** josh の各チェックは合否の 1 行を末尾に出すので、この文書の上限で真ん中が省略されても判定は残る（前節）。切り詰める理由がそもそも無い
-- **出力をどうしても絞るなら、ファイルへ落として範囲で読む**（`pnpm josh gate > /tmp/gate.log 2>&1; tail -40 /tmp/gate.log`）。リダイレクトは終了コードを奪わない
-- **パイプが避けられないなら `set -o pipefail` を前置する。** パイプラインが検証側の終了コードを運ぶ
+- **既定はパイプなしで実行する。** 判定行は末尾に出るので、上限で真ん中が省略されても残る
+- 絞るなら、ファイルへ落として範囲で読む（`pnpm josh gate > /tmp/gate.log 2>&1; tail -40 /tmp/gate.log`）。リダイレクトは終了コードを奪わない
+- パイプが避けられないなら `set -o pipefail` を前置する
 - **どの形でも、印字された判定行を読む。終了コードだけを答えにしない**
 
-### 対象は「結果が合否を意味するコマンド」だけ
-
-`gate` ／ `check` ／ `lint*` ／ `cspell*` ／ `test*` ／ `eval` — 合否を返すものに限る。
-
-**`git log | head` や `gh issue list | head` は対象外であり、意図的にそうしている。** 一覧を `| head` で絞るのは読み方として正しく、そこで拒否するフックは transcript の最頻形で発火することになる。**規則を広げると無視される方向に働き、無視される規則は無い規則より悪い**（`rule-delivery.md` →「誤ったターンで発火するフックは、フックが無いより悪い」）。
-
-**フックは 2 つの形にも黙る。** `set -o pipefail` を前置したパイプラインは検証側の終了コードを運ぶので握りつぶしていない。引用符の中のコマンド列（`--body "cd x && pnpm josh gate | tail"` のような Issue 本文）はテキストであって呼び出しではない。**どちらも「規則に従った呼び出しを拒否しない」ためである** — 配送はラン 1 回きりなので、従った呼び出しで 1 回を使い切ると、後から本当に握りつぶしている呼び出しが素通りする。
-
-`latest:scope` ／ `review:brief --level-only` ／ `review:brief` も対象外である。これらは**判定ではなく答えを印字する**コマンドで、`$(...)` で受けるのが正しい使い方である。コマンド置換そのものの無音の失敗は別の規則が扱う（`docs/josh-commands.md` →「`VAR=$(...) && cmd`」）。
-
-### 引き金つき配送で強制する —— 却下した 2 案
-
-- **手順書の実行例を書き換える。** 却下。**書き換える例が存在しない。** 文書・プロンプト・skill の全体を調べて、パイプ付きの検証例は `docs/josh-commands.md` の 1 件だけで、しかもそれはこの不具合の説明そのものだった。パイプは手本から写されているのではなく、**毎ターン新しく発明されている**
-- **呼び出し規約として書く**（「ゲートをパイプに繋ぐな」「`set -o pipefail` を前置しろ」）。却下。**同じ案が既に却下されている** — `scripts/time-runtime/time-reported-failure.ts` が「規約は守られるか守られないかのどちらかであり、図が捉えるべきは『そうすべきだったこと』ではなく『実際にしたこと』である」としてこれを退け、代わりに検出器を置いた。散文が数値を動かさなかった計測は joshuafolkken/kit#1344 と joshuafolkken/kit#1460 にもある
-
-採ったのは**引き金つき配送**である（`rule-delivery.md`）。`pnpm josh rule:guard` が、合否を意味する josh のチェックがパイプの手前に立った `Bash` 呼び出しを**その場で拒否する**。**拒否は読み飛ばせない。**
-
-**検出器は残る。** `scripts/time-runtime/time-reported-failure.ts` はゲート自身の `✗ verification gate failed:` 行を `is_error` の上に読む。フックが届くのは Claude Code だけで、停止スイッチを立てたセッションにも他の harness にも届かない — 検出器はその外側を覆い、かつ**規則が守られたかどうかを事後に測れる唯一の経路**である。配送と検出は代替ではなく、前者が防ぎ後者が数える。
-
-### 検査
-
-`scripts/rules/piped-verification-rule.test.ts` が、配送文が仕組み・逃げ道・境界の 3 つを運ぶこと、この節が規則と却下した 2 案を単一ソースとして持つこと、そして `rule-delivery.md` の列挙表に行があることを固定する。発火・非発火そのものは `scripts/rules/delivered-rules.test.ts` が両方向から固定する。
-
-## この上限が届かないもの
-
-`BASH_MAX_OUTPUT_LENGTH` は **Bash ツールにだけ効く**。実測では `Read` ツールが tool_result の 10.6%（単一最大 18,991 トークン）、`Agent` が 2.3% を占めており、どちらもこの上限の対象外である。別の量として別途扱う。
+**対象は結果が合否を意味するコマンドだけ** — `gate` ／ `check` ／ `lint*` ／ `cspell*` ／ `test*` ／ `eval`。**`git log | head` や `gh issue list | head` は対象外であり、意図的にそうしている。** `latest:scope` ／ `review:brief` も、判定ではなく答えを印字するので `$(...)` で受けてよい。`pnpm josh rule:guard` がパイプの手前に検証コマンドを置いた `Bash` をその場で拒否する（`rule-delivery.md`）。経緯・却下した案・検査は `docs/maintainers/output-bounds-rationale.md` → "Why the pipe rule is delivered by a trigger"。
 
 ## 検査
 
-`scripts/lib/bash-output-cap.test.ts` が、配布設定に上限が宣言されていること、値が harness の既定 30,000 より小さい（＝実際に作動する高さである）こと、受け付ける最大 150,000 を超えないこと、そしてこの文書が設定と同じ数値を書いていることを固定する。**「宣言されている」だけでは不十分**で、30,000 以上に戻された上限は宣言があっても作動しない — この文書が書かれた理由がそれである。
+`scripts/lib/bash-output-cap.test.ts` が、配布設定の上限がこの文書の値と一致し、harness の既定より小さく最大を超えないことを固定する（`docs/maintainers/output-bounds-rationale.md` → "What the tests pin"）。

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)）。