@joshuafolkken/kit 1.2116.0 → 1.3000.0

package/prompts/collaboration-workflow/measurement.md

@@ -6,33 +6,28 @@
 
 ## 記録の読み方
 
-- CI のジョブとステップ: Actions の記録を読む。
+- CI のジョブとステップ: `pnpm josh ci:timing <pr|branch|run-id>`（最新コミットの各 run の job・step ごとの秒と結論、`--json` も可、`docs/josh-commands.md`）。
 
-  ```bash
-  gh api --method GET "repos/<owner>/<repo>/actions/runs?branch=<branch>&per_page=5" --jq '.workflow_runs[] | [.id, .name, .conclusion, .run_started_at, .updated_at] | @tsv'
-  gh api --method GET "repos/<owner>/<repo>/actions/runs/<run_id>/jobs?per_page=100" --jq '.jobs[] | [.name, .started_at, .completed_at] | @tsv'
-  gh api --method GET "repos/<owner>/<repo>/actions/runs/<run_id>/jobs?per_page=100" --jq '.jobs[] | select(.name == "<job>") | .steps[] | [.name, .started_at, .completed_at] | @tsv'
-  ```
-
-- 手元の gate とチェックごとの所要時間: `pnpm josh lane:stats --period <days>`（gate の記録、`docs/josh-commands-run.md`）。
+- 手元の gate とチェックごとの所要時間: `pnpm josh lane:stats --period <days>`（gate の記録、`docs/josh-commands-lane.md`）。
 
 ## 効果を測る後続 Issue
 
-PR の効果を測る後続 Issue を起票するとき:
+PR の効果を測る後続 Issue の起票:
 
-- 開始条件は日数でなく標本数で書く: `## 背景` に `- 実施可能条件: #<PR> のマージ後 <K> マージ`（`issue-template.md`）。`#<PR>` は元の PR の番号で、Issue の番号は `issue:file` が refuse する。元の PR がまだ無い（レーンが `josh ship` の前に起票する）→ `- 実施可能条件: #<Issue> を閉じる PR のマージ後 <K> マージ` と書く。`#<Issue>` を閉じたマージ済み PR から数える。`- 計測宣言:` のある Issue と、見積もりが 0 ファイルで受け入れ条件が `#<N>` の後・以降か記録（`lane:stats` 等）を読む Issue に条件が無いときも、`issue:file` が refuse する。
-- 判定は既定で `## 背景` の `- 計測宣言:` に書く（`issue-template.md`）。`lane:stats` の表の 1 セル → `pnpm josh lane:value cell`（`docs/josh-commands-run.md` → "`josh lane:value`"）。1 コマンドで出せない値 → `- 計測宣言なし: <理由>`。どちらも無ければ `issue:file` が refuse する。
-- K は測る値の種類で決める:
-  - 事象の回数の率（停止・再利用など）: 変更前の率で 10 件以上見込める最小のマージ数（K ≥ 10 ÷ 変更前の率）。変更前の標本数を上限の目安にする。
+- 開始条件は日数でなく標本数で書く: `## 背景` に `- 実施可能条件: #<PR> のマージ後 <K> マージ`（`issue-template.md`）。`#<PR>` は元の PR の番号で、Issue の番号は `issue:file` が refuse する。元の PR がまだ無い → `- 実施可能条件: #<Issue> を閉じる PR のマージ後 <K> マージ` と書く。`#<Issue>` を閉じたマージ済み PR から数える。`- 計測宣言:` のある Issue と、見積もりが 0 ファイルで受け入れ条件が `#<N>` の後・以降か記録（`lane:stats` 等）を読む Issue に条件が無いときも、`issue:file` が refuse する。
+- 判定は既定で `## 背景` の `- 計測宣言:` に書く（`issue-template.md`）。`lane:stats` の表の 1 セル → `pnpm josh lane:value cell`（`docs/josh-commands-lane.md` → "`josh lane:value`"）。1 コマンドで出せない値 → `- 計測宣言なし: <理由>`。どちらも無いか同じ宣言の open Issue があれば `issue:file` が refuse する（後者は `issue:comment <N>` で合流）。
+- K は値の種類で決め、迷ったら 10（30 超は `issue:file` が refuse）:
+  - 事象の回数の率（停止・再利用など）: K ≥ 10 ÷ 変更前の率、30 まで。超える見込み → 率でなく件数を宣言するか `- 計測宣言なし: <理由>`。
   - 連続値の平均・差（所要時間など）: 5〜10。
-  - 最大値・裾: 変更前の標本数と同程度。
-- 受け入れ条件の集計は固定日数でなく `pnpm josh lane:stats --period <days>` とし、`<days>` は元 PR のマージからの経過日数（小数可）にする。
+  - 最大値・裾: 20 まで。
+- 計測宣言のある本文の `- 実施可能日:` → 起票から 7 日以内、`- 実施可能条件:` と併記しない（`issue:file` が refuse）。
+- 受け入れ条件の集計は固定日数でなく `pnpm josh lane:stats --period <days>`、`<days>` は元 PR のマージからの経過日数（小数可）。
 
-計測を記録し終えた → `pnpm josh issue:measured <N> --evidence-file <path>`。`.claude/skills/workflow-commands/issue-comments.md` →「A measurement-only Issue」。
+計測を記録し終えた → `pnpm josh issue:measured <N> --evidence-file .josh/tmp/measured.md`。`.claude/skills/workflow-commands/issue-comments.md` →「A measurement-only Issue」。
 
 ## 期待効果に届かなかったとき
 
-- 計測が期待効果に届かなかった → `pnpm josh issue:measured <N> --unmet --evidence-file <path>`。
+- 計測が期待効果に届かなかった → 同じ `issue:measured` に `--unmet` を足す。
 - 届かなかった機構の撤去候補を起票する → `pnpm josh effect:audit --draft <元 Issue>`（元 Issue が 30 日より前に閉じたときは `--days <N>` を足す）、表示された `issue:file` の行で起票する（重複は scout が止める）。
 - 時間短縮 Issue の効果を一覧する → `pnpm josh effect:audit [--days <N>]`。
 
@@ -41,4 +36,5 @@ PR の効果を測る後続 Issue を起票するとき:
 記録で答えられない問い（記録の無い変更前後の比較など）に限る。
 
 - 1 回だけ実行する。lane 子は `pnpm josh reserved-run <weight> -- <command>` で包み、コア予算に数えさせる。ESLint は `--concurrency off` で走らせ、並列度の計測はレーン外で行う（`lane-direct-tool`）。
+- 1 ルールをリポジトリ全体に当てる → `pnpm josh lint:rule <rule>`（コアを自ら予約するので `reserved-run` で包まない）、違反は出力ファイルを読み直す（`docs/josh-commands.md` → "`josh lint:rule`"）。ルールや設定を直しながらの確認は `--paths <path>...` で数ファイルに絞り、全体実行は最後に 1 回。
 - 結果を Issue のコメントに残し、以後はそれを使い回す。

package/prompts/collaboration-workflow/operating-rules.md

@@ -7,8 +7,8 @@
 
 `pnpm josh followup` は Required チェックだけを待つが、Workers Builds（Cloudflare デプロイ）など**非 Required チェックの失敗もユーザーに報告する**。
 
-- `pnpm josh followup` が印字するチェック一覧から失敗をすべて列挙する。手で読み直すときは `gh api repos/{owner}/{repo}/commits/<head-sha>/check-runs --jq '.check_runs[] | {name, conclusion}'`（`gh pr checks` は GraphQL を通るためクラウドセッションで 403）
-- 修正できたら修正内容を、できなかったら失敗チェック名・原因・未解決である旨を `--notify-message` に書く。**完了コメントに失敗を隠してはならない**
+- 緑の `pnpm josh followup` → 一覧は `followup` が完了通知に書く（`docs/josh-commands-automation.md` → "`josh followup`"）。修正内容・原因は `--notify-message`
+- 赤の run・マージ済み PR の再実行 → 印字された失敗を全件、修正内容か「名前・原因・未解決」で `--notify-message` に書く。読み直しは `pnpm josh checks:failed [<PR|sha>]`（非 Required を含む失敗を check runs と commit statuses から一覧。`gh pr checks` はクラウドで 403）。**完了コメントに失敗を隠してはならない**
 - ユーザーへの報告でも失敗を「成功」として扱わない
 
 ### git-rules — コミット・共有状態・index・PR
@@ -17,8 +17,8 @@
 
 - **コミットは指示されたときだけ。** マージ・ブランチ削除・force push などの共有状態の変更は、そのターンで指示されたときだけ。例外は `fullrun` / `backlogrun` の起動で、`pnpm josh followup` 経由のマージを認める（`prrun` は認めない）。deny は規則より狭い — ツールが通したことを許可と読まない
 - **git index は自分の判断で変えない** — 明示の指示か `pnpm josh git` 経由だけ（下記 "no-self-staging"）
-- **コミットは `pnpm josh git`、PR は `pnpm josh pr`** — `gh pr create` の直接実行は `direct-pr-create` 行が拒否する。GitHub 操作は `gh api`（REST） — [`gh-rest.md`](./gh-rest.md)
-- **作業ツリーの前提で動く前に `git status`（と `git stash list`）をその場で実行する**
+- **コミットは `pnpm josh git`、PR は `pnpm josh pr`** — `gh pr create` の直接実行は `direct-pr-create` 行が拒否する。GitHub 操作は `gh api` — [`gh-rest.md`](./gh-rest.md)
+- **作業ツリーの前提で動く前に `pnpm josh tree:status` をその場で実行する** — branch・status・stash list・hold を 1 回で読む
 
 ### 指示されていない行動は取らない
 
@@ -34,7 +34,7 @@
 
 上記 "git-rules" の細則。index には履歴がなく、上書きされたステージ状態は復元できない。
 
-- **調査目的の staging はしない。** 読み取り専用コマンドを使う: `git status --short`、`git diff` / `git diff --stat` / `git diff HEAD`、`git diff --staged`、未追跡ファイルは `git diff --no-index /dev/null <new-file>` か直接読む
+- **調査目的の staging はしない。** 読み取り専用コマンドを使う: `pnpm josh tree:status`、`git diff` / `git diff --stat` / `git diff HEAD`、`git diff --staged`、未追跡ファイルは `git diff --no-index /dev/null <new-file>` か直接読む
 - staging してよいのは次の 2 ケースだけ。それ以外は実行せずに確認する:
   1. ユーザーがそのターンで明示的にステージを指示した
   2. 承認済みのコミットフロー（`pnpm josh git`、`fullrun` / `backlogrun` のコミット手順。`halfrun` は含まない）
@@ -48,7 +48,7 @@
 
   1〜3 は直後に `pnpm josh stash:pop "<メッセージ>"` で復元する（位置指定の pop は `worktree-mutation` 行が拒否する）。4 は復元しない — 代わりに stash を子の Issue にコメントで記録する（`prerequisite.md` の stash と同じく、記録だけが後で pop させる手がかり）
 
-- **会話で作った実装をランへ渡す「引き渡し用の stash」も `pnpm josh stash:pop "<メッセージ>"` で復元する。当てたあと stash は消える**
+- **既存の実装をランへ渡す「引き渡し用の stash」も `pnpm josh stash:pop "<メッセージ>"` で復元する。当てたあと stash は消える**。担当範囲は `principles.md` → "consult-vs-execute" に従う
   - 計画には復元手順としてこの 1 行だけを書く。`git stash apply` / `git stash pop` も「drop しない」という条件も書かない
   - 計画がガードの拒否する復元形を指していたら、実行側は `stash:pop` に読み替えて続行し、Issue コメントに残す（Tier A）。`needs-decision` では止まらない
   - stash を残すのは持ち主の判断だけ。持ち主が計画に理由を書き、ランはそこで止まって確認する
@@ -59,8 +59,11 @@
 `CLAUDE.md` → "Decision autonomy" の境界の細則。
 
 - **A と B の判定**: 確認するのは「差が僅差 かつ 後戻りしにくい／アーキテクチャに長く影響する」ときだけ。明確に優位な選択肢は自動で選び、僅差でも安価に巻き戻せる選択は決めて記録して進む
+- **判定規則のある Issue**: 子ランは背景の `- 判定規則:` が参照する計測 Issue の本文・コメントを読み、条件を適用し、選択・計測値・理由を Issue コメントに記録する。自然言語の条件はこの自律判断で評価する。参照を読めない、または必要な値が無い場合は未判定として停止理由を記録する
 - 起票した Issue の所属先は、候補が複数の epic に散っていても Tier A（`.claude/skills/epic-commands/epic-bundle.md`）
 - 自己修正（自分が公開した成果物の事実誤りの訂正、同じセッションで自分が特定した自分の作業の抜けの穴埋め）は Tier A。承認済みの作業の完了・修復に限り、目標の表明や問いで動いてよい意味ではない（→ `principles.md` → "consult-vs-execute"）
 - **Tier C との境界**: マージ・ブランチ削除・force push・スコープ外の変更は、自分が招いた問題でも Tier C。確認を外しても監査証跡は外さない
+- 既に merge 済みの Issue の close、CodeRabbit の rate limit の retrigger → コマンドが決める（`issue-comments.md` → "When the work turns out to be already merged"、`followup.md`）
+- blocked-by 関係の削除 → `pnpm josh backlog:triage --apply <N> --unblock <M> --reason <text>`。`--blocked-by` で戻せるので取り消し可能。生の `gh api -X DELETE …/dependencies/blocked_by/…` は `destructive-command` 行が拒否する（`scripts/rules/destructive-command.ts`）
 - **major のバージョン bump は Tier C**: `pnpm josh bump major` は自分の判断で実行も提案もしない。既定は minor / patch で、major はユーザーがそのターンで明示したときだけ（0.x の major は 1.0.0 になり戻せない）。`josh bump` が版を変えたら、変わった挙動の `docs/` をコミット前に更新する
-- 自動判断を記録する Issue コメントは `pnpm josh issue:comment <N> --body-file <path>` で投稿する
+- 自動判断を記録する Issue コメントは `pnpm josh issue:comment <N> --body-file .josh/tmp/comment.md` で投稿する

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

@@ -14,7 +14,7 @@
 
 **情報を落とすのではなく、必要な範囲に合わせて読み直す。** 再実行ではなく絞り込む:
 
-- ファイルは範囲を指定する（`sed -n '120,180p' <file>`、または `Read` の `offset` / `limit`）
+- ファイルは範囲を指定する（宣言 1 つは `pnpm josh code:symbol <file> <name>`、他は `sed -n '120,180p' <file>` か `Read` の `offset` / `limit`）
 - 一覧は件数を絞る（`--limit`、`| head -30`）、JSON は必要な項目だけ取り出す（`gh api … --jq '…'`）
 - 全量が要るときは、ファイルへ落として（`> <file>`）から範囲を読む
 - 退避された `tool-results/<id>.txt` → `grep -n` ／ `sed -n` で読む（`lane-spilled-read` 行、`pnpm josh rule:list`）
@@ -24,8 +24,8 @@
 **検証ゲートと差分は、切り詰められた結果で判断しない。**
 
 - 検証コマンド（`gate` ／ `check:related` ／ `lint:related` ／ `test:related`）の末尾を読む → 失敗と次のコマンド、`full output: <path>`（`lint:related` には無い）、最終行の合否の順（`scripts/gate/verification-tail.ts`）。内訳が切れたら `full output:` のファイルを読む（joshuafolkken/kit#1227）
-- `pnpm josh test:related` ／ `test:unit` が失敗した → 最後の `failed tests:` 一覧と `full output: <path>` を読む。読むための再実行はしない。直したら、まず要約の `rerun failed:` 行で失敗したファイルだけを回し、関連集合の全体は最後の `check:related` で 1 回だけ回す（`scripts/test/vitest-failure-summary.ts`）
-- 差分には判定行が無い。差分はファイルへ落としてから範囲で読む（`git diff main...HEAD > /tmp/diff.patch && wc -l /tmp/diff.patch`）
+- `pnpm josh test:related` ／ `test:unit` が失敗した → 最後の `failed tests:` 一覧と `full output: <path>` を読む。読むための再実行はしない。直したら、引数なしの `pnpm josh test:related` を回す → 失敗したのが引数なしの `test:related` なら、失敗したファイルとその後に動いたファイルだけを読み、緑なら到達範囲全体の緑として記録される（`scripts/test/test-related-red.ts`）。`rerun failed:` 行は失敗したファイルだけを回すが、緑の記録は残さない（`scripts/test/vitest-failure-summary.ts`）
+- 差分には判定行が無い → `pnpm josh diff:summary [<base>]` の表で範囲を決め、最終行の `full output:` を範囲で読む
 
 ## 検証コマンドをパイプに繋がない（joshuafolkken/kit#1556）
 

package/prompts/collaboration-workflow/overview.md

@@ -1,36 +1,27 @@
 ## Overview
 
-1. Issue を作成する
-2. Issue を元に実装提案を作る
-3. 計画コメントを Issue に残して Telegram 通知を送る
-4. 実装を進める
-5. 実装完了後に Issue へ完了コメントを投稿する
-
-### フェーズ分離
-
-- Planning phase（`kickoff`）: Step 1〜3 — Issue 作成・計画投稿・Telegram 通知で止まる。実装前にレビューや承認を挟むときに使う。
-- Execution phase（`fullrun #N`）: Step 4〜5 — 既存 Issue の計画に基づいて実装・PR 作成・完了通知を行う。
-
-`fullrun new` は Step 1〜5 を通しで実行する。
+`kickoff` / `fullrun` / `halfrun` / `prrun` / `backlogrun` の手順は `workflow-commands` skill。
 
 ### 出力の言語（`JOSH_SESSION_LANG`）
 
 開発者との対話と成果物の散文は、環境変数 `JOSH_SESSION_LANG`（例: `ja` / `en`）の言語で書く。**未設定・空・`.env` なしのときは `ja`**。
 
 - 対話: セッション中の説明・質問、`AskUserQuestion` の選択肢ラベル・説明
-- 成果物の散文: Issue 本文、Issue／PR コメント（Step 3 の計画コメント、`pnpm josh followup` の完了コメントを含む）、Telegram 通知の本文（`--body` / `--notify-message`）
-- **設定に関わらず英語で固定するもの**（3 つ）:
-  1. Issue／PR タイトル（Step 1 のタイトル正規化ルール）
+- 成果物の散文: Issue 本文、Issue／PR コメント（計画コメント、`pnpm josh followup` の完了コメントを含む）、Telegram 通知の本文（`--body` / `--notify-message`）
+- 設定に関わらず英語で固定するもの:
+  1. Issue／PR タイトル
   2. コード内コメント、テストタイトル（`describe` / `it` / `expect`）、コミットメッセージ
   3. スクリプトが出力する固定文字列: Telegram のヘッダーラベル（`Planning` / `Completion` など）、`Issue:` / `PR:` の URL ラベル、`--notify-message` 省略時の既定メッセージ
+- Issue 本文の見出し・宣言キー・固定値 → josh は設定の言語で書き出し、読み取りは日英どちらも受け付ける（`scripts/issue/issue-body-keys.ts`）
+- 文書が日本語で名指すキー・固定値・見出し → `JOSH_SESSION_LANG` の列で書く（対応表は `issue-template.en.md`）
 
-`JOSH_SESSION_LANG` は開発者個人の設定で、`.env`（gitignore 済み）に置く。設定値は毎ターン `UserPromptSubmit` フック（`scripts/hooks/run-hook.sh session-lang`、Codex は `.codex/hooks.json`）が差し込み、未設定なら出さない。フックが走らないハーネス（Gemini / Cursor）は `.env` を読む。
+`JOSH_SESSION_LANG` は `.env`（gitignore 済み）に置く。フックが走らないハーネスは `.env` を読む。
 
 ### 配布ドキュメントの層ごとの言語（joshuafolkken/kit#2997）
 
 ドキュメントは**層ごとに 1 つの言語**で書き、層の中で言語を混ぜない（`JOSH_SESSION_LANG` に依らない）。
 
-- 英語: `CLAUDE.md`、`AGENTS.md` / `GEMINI.md`、スキル（`.claude/skills/`）、フックが差し込む文、`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/collaboration-workflow/issue-template.en.md`
 - 日本語: それ以外の `prompts/` のトピックファイル
 
 英語の層から日本語のトピックファイルの節を指すときは、見出しの先頭の**英語 ID** を引く（例: `## no-clones — クローン禁止・…` を `principles.md` → "no-clones"。`pnpm josh doc:section` は前方一致で解決する）。ID の無い日本語見出しは原文のまま引く。

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

@@ -1,7 +1,7 @@
 ## Step 3: 計画コメントを記録して通知する
 
 1. 提案を人間が判断する
-2. 採用した計画をファイルに書き、`pnpm josh issue:plan <N> --body-file <path>` で Issue に記録する。書き込み権限のある作成者の body が空なら本文に、それ以外はコメントになる（本文はパスで渡す — `shell-body.md`）
+2. 採用した計画をファイルに書き、`pnpm josh issue:plan <N> --body-file .josh/tmp/plan.md` で Issue に記録する。書き込み権限のある作成者の body が空なら本文に、それ以外はコメントになる（本文はパスで渡す — `shell-body.md`）
    - 計画が stash の復元を含むときの書き方: `operating-rules.md` → "no-self-staging"
    - 計画には `### 影響を受ける既存の利用者` が必須（`pnpm josh plan:consumers <識別子...>` が下書きを出す。書き方: `kickoff.md` の手順 4）
 3. Telegram で計画開始を通知する:

package/prompts/collaboration-workflow/principles.md

@@ -4,10 +4,8 @@
 
 既存の非自明なロジック（別ファイル・別モジュール・上流依存を含む別パッケージにあるもの）を、ソースを変えずに済ませるために**コピー・移植・再実装しない**。複製したくなったら、全消費者が import する共有モジュール／export／パッケージへ単一ソース化する。
 
-- 既存の重複は再重複の理由にならない（例: josh-game が kit をコピー）。3 つ目のコピーを足さず、重複を surface する
-- 「上流を参照する」は再利用することで、コードを貼り付けることではない
-- 「X を触るな」という制約でクローンを黙って正当化しない。「クリーンな修正は kit の変更が必要、代替はクローン、どちらにする？」と先に提示する
-- 複製は、単一ソース化の代替案とコストを提示し、ユーザーの明示承認を得た後にのみ行う
+- 既存の重複は再重複の理由にならない。3 つ目のコピーを足さず、重複を surface する
+- 「X を触るな」という制約でクローンを黙って正当化しない。単一ソース化の代替案とコストを先に提示し、ユーザーの明示承認を得た後にのみ複製する
 
 計測は `pnpm josh clone:scan`（`pnpm josh oracle:list` の決定オラクル）。リポジトリ内と `JOSH_REPO_PATHS` の他リポジトリを跨いだ複製の件数と各 `file:line`（`[same-file|cross-file|cross-repo]`、なしは `clean`）を印字する。
 
@@ -15,8 +13,6 @@
 
 フック・ガード・ルール・抽象化を足す前に、**原因側を直せばその仕組みが要らなくならないか**を問う。要らなくなるなら足さず、原因を直す。検出・通知・叱責を強化する前に、その入力を生んでいる側を断つ。
 
-書かれたコードの可読性は `prompts/coding-standards.md` の担当で、ここはどの仕組みをどこへ足すかの規則である。互いの本文を写さず、指すだけにする。
-
 ## automate-first — 判断の要らない手順は AI に渡さず自動化する
 
 AI の判断が要らない手順は、AI に読ませて実行させない。規則を足すときは、次の順で最初に成り立つ形を選ぶ。
@@ -51,6 +47,10 @@ AI の判断が要らない手順は、AI に読ませて実行させない。
 - 機能や最適化の追加を止める・凍結する・後回しにする案を出さない。順序は優先度ラベルが決める
 - 進化を続けたまま不具合を防ぐ仕組み（単一ソース化、層の統合、不変条件のテスト）を提案する
 
+## measured-figures — 判断に使う数値は出典を添える
+
+- 起票・引き渡し・報告（相談セッション・調査ユニットを含む）で数値を判断に使うとき → 測ったコマンドをバッククォートで添える。未測定なら `予測` と書き、実装の前に測る。`pnpm josh issue:lint` が出典の無い数値行を警告する。前提の宣言行は `issue-template.md` → `- 前提:`
+
 ## concise-prose — 文章は条件と動作だけを書く
 
 docs・prompts・skills・拒否文・Issue・PR の文章に適用する。
@@ -72,23 +72,23 @@ docs・prompts・skills・拒否文・Issue・PR の文章に適用する。
 
 ## consult-vs-execute — 相談と実行を区別する
 
-ユーザーが進め方・理由を尋ねたり目標を述べたりした（「どうすべき？」「how should we…」「なぜ」「〜したい」「〜の方が良い？」）ときは、**分析と推奨のみ**を返し、ファイル編集・Issue 作成などのアクションは取らない。目標の表明は計画の依頼であって、実行の承認ではない。
+進め方・理由の質問や目標の表明（「〜したい」等）には分析と推奨のみ返し、編集・起票しない。実装可否は launcher の `JOSH_AGENT_ROLE` を読む `agent_session_role.can_implement` に従う。worker のみ実装可、scheduler・reviewer・未設定・不明値は不可。モデル名や会話から補完せず、文書・レビュー結果の記録は別扱いにする。
 
-- アクションを取るのは、明示的な命令（「do it」「書き換えて」「作成して」「implement」）かワークフローキーワード（`kickoff` / `halfrun` / `prrun` / `fullrun` / `backlogrun`）があるときだけ
-- 判別できないときは相談として扱う。実行が指示された後の判断点は `CLAUDE.md` → "Decision autonomy" の Tier で決まる
+- **相談の主セッションは相談・起票・運用を担当する。実装は実装レーンが担当し、主セッション自身で実装を開始しない。** 「起票して」は起票を実行し、「対応してください」は合意した起票・Issue 更新・レーン操作として処理する。実装が必要なら Issue に範囲と計画を残し、既存の実装レーンへ引き渡す
+- 明示されたワークフローキーワード（`kickoff` / `halfrun` / `prrun` / `fullrun` / `backlogrun`）は `workflow-commands` skill の既存手順へ渡す。主セッションが実装する根拠には読み替えない。`kickoff` は起票・計画で停止し、実装系の実行は実装レーンへ引き渡す
+- 判別できないときは相談として扱う。承認済みの起票・Issue 更新・レーン操作と、実装レーン内の Tier A 判断は再確認せず進める。実行が指示された後の判断点は `CLAUDE.md` → "Decision autonomy" の Tier で決まる
+- 相談スコープのシェルは、取り消せない操作（git・GitHub・依存・共有状態への書き込み）と runtime ファイルへの見える書き込みだけを実行前に拒否し、それ以外の呼び出しが変えた runtime ファイルは実行後に戻す（`scripts/hooks/bash-revert.ts`）。拒否は `scripts/hooks/implementation-shell.ts` が強制する
 
 ## latest-first — 最新優先・fix-forward（pin-back は最終手段）
 
-依存・ツールチェーンは**既定で最新版を採用する**。`dependency-update` skill → "4. When the bump breaks something — fix forward" はこの節を指す。
+依存・ツールチェーンは**既定で最新版を採用する**。古い版に留まらず、戻さない。
 
-1. 適応の手間を避けるために古いバージョンに留まったり戻したりしない
-2. バンプで lint クラッシュ・新規ルール・型エラー等が出たら fix-forward で解消する:
+1. バンプ起因の破壊（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 の裏に先送りしない
+   - first-party パッケージ起因なら、そこに Issue を立てて直す（→ `upstream-interrupt.md`）
+2. pin-back は fix-forward が不可能／ブロックされているときだけ。理由を記録し、最新へ戻すトラッキング Issue を立てる
+3. overrides と `devEngines` は fix-forward でも黙って書き換えない → `CLAUDE.md` → "Decision autonomy"
 
 ## durable-rules — 恒久ルールは MEMORY ではなくプロンプト／ドキュメントに書く
 
@@ -105,9 +105,7 @@ docs・prompts・skills・拒否文・Issue・PR の文章に適用する。
 
 ## エージェント規則の単一ソースは `CLAUDE.md`（`AGENTS.md` / `GEMINI.md` / `.cursorrules` は導線）
 
-**規則の本体は `CLAUDE.md` にしか無い。** `AGENTS.md`・`GEMINI.md`・`.cursorrules` は「規則は `CLAUDE.md` にある。作業前に全文を読むこと」と「規則を書き戻さない」だけを書いた導線である（`.cursorrules` は Svelte MCP の案内だけを足す）。
-
-- 規則の追加・変更・節の追加は `CLAUDE.md` に 1 回だけ書き、導線文書には書き戻さない
+**規則の本体は `CLAUDE.md` にしか無い。** 規則は `CLAUDE.md` に 1 回だけ書き、導線の `AGENTS.md`・`GEMINI.md`・`.cursorrules` には書き戻さない。
 
 ### Claude Code 以外のエージェントでの読み替え
 

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

@@ -18,6 +18,7 @@
 ### 作業前サマリはいつ・どう出すか
 
 - **いつ**: 実装コードを書く前に、Issue ごとに 1 回出す。`fullrun` / `halfrun` / `prrun` / `backlogrun` で必須、`kickoff` は対象外。確認のための停止ではない — 出したらそのまま実装に進む
+- **材料**: `pnpm josh plan:scaffold <N> [<path>...]` 1 回で集める（骨組み・`lines`・`test:declared`・`cases`・`plan:consumers`）。骨組みで埋めるのはテスト名（`docs/josh-commands-run.md` → "`josh run:prep`"）
 - **概要**: `Now` / `Change` / `Check` を各 1 文、セッション言語で、プログラマでない人にも追える文で書く。各行に具体的な主語を書き、主語のない文は不可（下記「具体的な主語を必ず書く」）。ファイルパス・関数名や型名・CLI のオプションフラグは書かない — 禁じるのは内部識別子だけである
 - **技術詳細**: すべての変更をそのテストとともに `<変更内容> — Test: <Unit|E2E> — <file path> — <検証する挙動>` の形で並べる
 - **完了報告**は `Cause` / `Fix` / `Result` を先頭に置く
@@ -35,11 +36,11 @@
 - 第 1 段（ケース）は固定語彙を並べ、**該当しないものは `該当なし` に続けて理由を書いて消す**（例:「重複: 該当なし — 入力は集合なので重複しない」）
 - 第 2 段（壊れるとしたら）は、この変更に固有の壊れうる条件を**最低 3 件**書く。書けないときは `どう呼ばれても壊れない` と明示する
 - 複数ケースは `it.each` 1 本に畳んでよい
-- 差分が HTTP・プロセス起動・ファイル IO・時間の境界を跨ぐとき、または共有状態（`.josh/` 配下・lock）や環境（`process.env`・常駐プロセス）に依存するときは、`pnpm josh cases <path...>` が印字する異常系を第 2 段に載せる。共有状態には同じ状態を読み書きする他のソースが `file:line` で付く
+- 差分が HTTP・プロセス起動・ファイル IO・時間の境界を跨ぐとき、または共有状態（`.josh/` 配下・lock）や環境（`process.env`・常駐プロセス）に依存するときは、`plan:scaffold` の `cases` 節（単独では `pnpm josh cases <path...>`）が印字する異常系を第 2 段に載せる。共有状態には同じ状態を読み書きする他のソースが `file:line` で付く
 
 ### 行数予算は編集前に読む
 
-**「対象」に書くファイルは、書き始める前に `pnpm josh lines <path> [<path>...]` に渡し、上限に近いと言われたファイルには分割方針を「対象」に書く**（joshuafolkken/kit#1425）。行数は `wc -l` で数えない。関数単位の上限は `pnpm josh lint` が報告する。
+**「対象」に書くファイルは、書き始める前に `plan:scaffold` の `lines` 節（単独では `pnpm josh lines <path> [<path>...]`）で読み、上限に近いと言われたファイルには分割方針を「対象」に書く**（joshuafolkken/kit#1425）。行数は `wc -l` で数えない。関数単位の上限は `pnpm josh lint` が報告する。
 
 ### 変更対象はまとめて読んでから編集する（joshuafolkken/kit#2202）
 
@@ -50,15 +51,15 @@
 `pnpm josh report:template done <変更したファイル...>` が印字する。各欄に書くこと:
 
 - 概要の 3 行: なぜそうなっていたか / 何をしたか / 利用者から見て何が変わったか（版を添える）
-- 実行証跡: 実行可能な経路を触った変更では、実際に叩いたコマンドとその出力（UI ならスクリーンショット）。無いなら理由
+- 実行証跡: 実行可能な経路を触った変更では、PR 本文の `## 実機証跡` 節を指す 1 行（出力は貼り直さない。UI ならスクリーンショット）。無いなら理由
 - 捕まえられた検証: 不具合修正のみ。その検証の種類を 1 行（2 回目は台帳で昇格, #2448）
 - 残課題: なければ「なし」
 
-**実行証跡は「動くこと」の証拠であり、gate の緑ではない**（joshuafolkken/kit#2246）。同じ証跡を PR 本文の `## 実機証跡` 節（コマンド＋実出力のフェンス）にも置く。無い実行時の変更は `pnpm josh followup` がマージを拒否する（#2446）。
+**実行証跡は「動くこと」の証拠であり、gate の緑ではない**（joshuafolkken/kit#2246）。証跡は PR 本文の `## 実機証跡` 節（コマンド＋実出力のフェンス）に一度だけ置く — `pnpm josh ship:evidence <N> -- <command...>` がコマンドを実行し、呼び出し行と出力の末尾を ship 本文の下書きのその節に追記する（手で書く道も残る）。無い実行時の変更は `pnpm josh followup` がマージを拒否する（#2446）。
 
 ### PR 本文の受け入れ条件の対応表
 
-`## 受け入れ条件の対応` 節の行の形（`pnpm josh pr` が識別子つきの `未記入` 行を付け、`pnpm josh followup` が照合する — `scripts/review/acceptance-map.ts`）。`pnpm josh ship` の経路では、同じ識別子つきの `未記入` 行を `pnpm josh run:prep` / `pnpm josh run:step` の ship 事前要求が出し、同じ行と `## 実機証跡` 見出しを ship 本文の下書き（作業ツリーの git ディレクトリの `josh-ship-body-<N>.md`）にも書く。`--body-file` を省いた ship はこの下書きを本文として読む（`scripts/run/ship/run-ship-body-draft.ts`）:
+`## 受け入れ条件の対応` 節の行の形（`pnpm josh pr` が識別子つきの `未記入` 行を付け、`pnpm josh followup` が照合する — `scripts/review/acceptance-map.ts`）。`pnpm josh ship` の経路では、同じ識別子つきの `未記入` 行を `pnpm josh run:prep` / `pnpm josh run:step` の ship 事前要求が出し、同じ行と `## 実機証跡` 見出しを ship 本文の下書き（作業ツリーの git ディレクトリの `josh-ship-body-<N>.md`）にも書く。`--body-file` を省いた ship はこの下書きを本文として読む（`scripts/run/ship/run-ship-body-draft.ts`）。追加テストのタイトルが条件の識別子（`(ac-1a2b3c4d)`）を含むと、緑の `pnpm josh test:related` がその `未記入` 行をテスト名で `満たした` にする（`acceptance_map.with_test_rows`、記入済みの行は変えない）:
 
 ```md
 - `ac-1a2b3c4d` <条件> — 満たした: <テスト名・`file:line`・実行出力のいずれか>

package/prompts/collaboration-workflow/residency.md

@@ -37,6 +37,7 @@
 - **常駐規則は、トリガと導線の 2 つで書く。** **判定は、導線を一度も開かないターンでも常駐の記述だけで正しく振る舞えるかである。**
 - **削ることは移すことであり、削除は理由を示して初めて許される例外である。** 先に導線の先へ移し、マーカーテストも付け替える。写しを移さず引退させてよいのは 3 条件がすべて揃うときだけ — 同じ文書に単一ソースが宣言された文の写しである・単一ソースと突き合わせてほかにない文を含まない・マーカーテストが固定していない。揃わなければ候補と証拠を記録して規則は残す
 - 写しのほかに、`pnpm josh rule:value --fresh` の `candidates:` 節も引退（`retire`）・導線 1 行への縮約（`condense`）の根拠になる。判定は `scripts/rules/rule-value-candidates.ts`。候補ごとに Issue を分け、残すなら理由を記録する
+- `pnpm josh rule:value --prose` が `文章だけ` と分類した規則は、違反が観測された順に、hook 化する・設計で不要にする・削除する、のどれかに決める。「残す」は選ばない
 - 経緯（Issue 番号・なぜ・計測・却下案）は `docs/maintainers/<topic>-rationale.md` に置き、その冒頭で説明する手順文書を名指しする。**参照の向きは根拠 → 手順だけ** — AI が読む文書から根拠文書は指さない（`scripts/document/rationale-documents.test.ts` が検出する）。Issue 番号引用の件数は `scripts/document/issue-citation-budget.ts` のラチェットに従う — 減らしたら記録も下げる
 - 引用は本文があるファイルを直接指す
 - 予算が詰まったら回収で解く。**引き上げは Tier C として扱う** — `RESIDENT_CEILING_BYTES`・`RESIDENT_HEADROOM_BYTES`・`RE_INLINE_GUARD_HEADROOM_BYTES` の緩和は、3 条件（回収の余地が尽きたことを計測で示す・需要が 1 規則ではなく常駐すべき規則数の増加から来る・増やす量は需要と回収可能量の差だけで丸めない）を示し、ユーザーの明示指示を得てから行う。条件が揃うこと自体は指示ではない

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

@@ -2,34 +2,26 @@
 
 規則の届け方は**常駐**（`CLAUDE.md` に書き毎ターン読み込ませる）と**引き金つき配送**（効く瞬間にフックが本文を突きつける）の 2 つ。
 
-## 判定基準 — 引き金を特定できるか
-
-どの規則を配送へ移すかは [`residency.md`](./residency.md) →「第 1 問」に従う。
-
 ## 機構 — 1 本だけ、新規に作らない
 
 入口は `PreToolUse` の `pnpm josh pretool:guard`（バッチング ／ 調査 ／ 規則の 3 ガード）と Stop フックの `pnpm josh stop:guard` の 2 つ。**2 本目の配送経路を作るのは `CLAUDE.md` →「No clones」が禁じるクローン**である。配送は呼び出しの書き換え（`updatedInput`）でもよい — 規則の結果そのものを機械的に作れる形に限る。書き換えは `pnpm josh rule:value` が `rewritten` として数える。どのガードが書き換えるかは `scripts/rules/guard-remedy.ts` の分類表が単一ソース。
 
 ## 配送されている規則
 
-一覧は `pnpm josh rule:list` が `scripts/rules/delivered-rules.ts` から生成する（joshuafolkken/kit#3399）。各項目は規則の単一ソース・発火点・発火しないときを持ち、フックが走らないエージェントはその出力を自己適用のチェックリストにする（`principles.md`）。
+一覧は `pnpm josh rule:list`（`scripts/rules/delivered-rules.ts`）。フックが走らないエージェントはその出力を自己適用のチェックリストにする。
 
-**引き金はシェルのコマンド文字列しか見えない**（node 内の REST は掛からず、`gh api --input <file>` のファイルの中身を読むのは `credential-body` だけ）ので、常駐側にトリガ 1 行を残す。
+**引き金はシェルのコマンド文字列しか見えない**ので、node 内の REST のように引き金が掛からない経路を持つ規則は、常駐側にトリガ 1 行を残す。各項目の発火しない状態は「規則が守られている状態」と一致させ、一致が取れない規則は常駐に残す。
 
-引き金が発火しないターンでは何も起きないのが仕様で、各項目の発火しない状態は「規則が守られている状態」と一致させる。一致が取れない規則は常駐に残す。
+- 相談スコープのシェルが拒否される → `scripts/hooks/implementation-shell.ts`（拒否リストは `implementation-shell-deny.ts`）。それ以外の runtime 書き込みは `scripts/hooks/bash-revert.ts` が戻す。
 
 ## stop-notify — 途中停止の通知（`confirmation`）
 
-`CLAUDE.md` → "Mid-workflow stop notification" の本文（`pnpm josh rule:list` の `stop-notify` 行）。保持中のランが判断待ちで止まるとき、Stop フックの `pnpm josh stop:guard` が `confirmation` を送る — 理由を先頭に、末尾は `Recommended: <choice>`。フックが停止を拒否したときだけ自分で送る:
+保持中のランが判断待ちで止まるとき、Stop フックの `pnpm josh stop:guard` が `confirmation` を送る — 理由を先頭に、末尾は `Recommended: <choice>`。フックが停止を拒否したときだけ自分で送る:
 
 ```bash
 pnpm josh notify --task-type confirmation --issue-url "<url>" --body=$'<reason>' --recommended "<choice>" --alternative "<other>"
 ```
 
-## concise-reply — 回答の長さ
-
-`principles.md` → "concise-reply"（`pnpm josh rule:list` の `concise-reply` 行）。散文が上限を超えた回答の Stop で、`pnpm josh stop:guard` が節の本文付きで 1 度だけ書き直させる。
-
 ## 配送は 1 ラン 1 回
 
 配送文はラン 1 回につき 1 度しか出ないので、**「同じ呼び出しをもう一度出せ」と明記する**。例外: 繰り返す行為を止める項目は毎回発火し（joshuafolkken/kit#1570）、前提の行為を求める項目は前提が末尾に現れるまで毎回拒否する（joshuafolkken/kit#2807）— その配送文にはそれぞれ「これは毎回発火する」「前提が末尾に現れるまで拒否する」と明記する。バッチングと調査の 2 ガードは違反が間隔分続けば再び発火する（joshuafolkken/kit#2164）。前提の証拠を読めないときは拒否する。

package/prompts/collaboration-workflow/shell-body.md

@@ -4,22 +4,22 @@
 
 ### 安全な書き方
 
-**本文をファイルに書いて、パスで渡す。** `--body-file` の本文や計画メモは `.josh/tmp/` に置く（ignore 済みなのでコミットに混ざらない）。
+**本文をファイルに書いて、パスで渡す。** `*-file` に渡す本文や計画メモは `.josh/tmp/` に書く（ignore 済みなのでコミットに混ざらない）。作業ツリー内で git-ignore されていない本文ファイル（`scratchpad/` など）は、`cli_body` で読む `*-file` が拒否する（`scripts/josh/cli-body.ts`）。
 
 ```bash
-pnpm josh issue:comment <N> --body-file <path>
-gh api -X PATCH repos/{owner}/{repo}/issues/<N> --field body=@<path>
-pnpm josh followup "<title> #<N>" --notify-message-file <path>
-pnpm josh notify --task-type confirmation --issue-url "<url>" --body-file <path> --recommended "<choice>"
+pnpm josh issue:comment <N> --body-file .josh/tmp/comment.md
+pnpm josh issue:body <N> --body-file .josh/tmp/body.md
+pnpm josh followup "<title> #<N>" --notify-message-file .josh/tmp/notify.md
+pnpm josh notify --task-type confirmation --issue-url "<url>" --body-file .josh/tmp/notify.md --recommended "<choice>"
 ```
 
-PR コメントも `pnpm josh issue:comment <N> --body-file <path>` で投稿する（REST では PR コメントは issue コメント）。`gh issue comment` / `gh pr comment` は使わない。
+PR コメントも `pnpm josh issue:comment <N> --body-file .josh/tmp/comment.md` で投稿する（REST では PR コメントは issue コメント）。`gh issue comment` / `gh pr comment` は使わない。
 
 ### コメント投稿は `pnpm josh issue:comment` の 1 綴りだけ（joshuafolkken/kit#2304）
 
 自リポジトリへの `gh issue comment` / `gh api` コメント投稿 → `direct-issue-comment` 行が拒否する（`scripts/rules/direct-issue-comment.ts`）。
 
-`-f body=@<path>` は `@<path>` というリテラルを投稿するので、`raw-field-body` 行が拒否する。Issue body 書き換えの `--field body=@<path>` は安全なのでそのまま使う。
+`-f body=@<path>` は `@<path>` というリテラルを投稿するので、`raw-field-body` 行が拒否する。Issue 本文の書き換えは `pnpm josh issue:body`（エピック以外は `issue:lint` を通った本文だけ書く）。コンサルセッションは GET 以外の `gh api` を拒否するので、`gh api -X PATCH` では書けない。
 
 `--body-file` / `--notify-message-file` は `-` で標準入力を読む（実装は `scripts/josh/cli-body.ts`）。`--body` と `--body-file` の同時指定は拒否される。
 

package/prompts/collaboration-workflow/turn-batching.md

@@ -7,7 +7,7 @@
 - no → その呼び出しは、依存していない他の呼び出しと同じターンに載せる
 - yes → 結果を待つ。別のターンになるのが正しい
 
-ファイル 3 つを 3 ターンで読む、`git status` と `pnpm josh issue:state` を別ターンに分ける — いずれも禁止。**費用は仕事の量ではなく往復の回数にある。**
+ファイル 3 つを 3 ターンで読む、`pnpm josh tree:status` と `pnpm josh issue:state` を別ターンに分ける — いずれも禁止。**費用は仕事の量ではなく往復の回数にある。**
 
 ## 判断基準は「依存の有無」であって、呼び出しの種類ではない
 
@@ -27,4 +27,4 @@ round trip は 1 ターンがまとめて出した呼び出しのかたまり 1
 
 ## 実装中の独立編集に効く合成コマンド（joshuafolkken/kit#2202）
 
-**Step 0 が対象ファイルを列挙したら、`pnpm josh read:files <path> …` で読み取りを 1 回に畳み、続く独立した編集は `pnpm josh edit:files` の 1 呼び出しで送る**（`old` が 1 箇所に一致しなければ拒否される）。ガードが `read:files` / `edit:files` を手渡したら、その 1 呼び出しで出し直す。形式は `docs/josh-commands-run.md` →「`josh read:files`」と「`josh edit:files`」。
+**Step 0 が対象ファイルを列挙したら、`pnpm josh read:files <path> …` で読み取りを 1 回に畳み、続く独立した編集は `pnpm josh edit:files` の 1 呼び出しで送る**（`old` が 1 箇所に一致しなければ拒否される）。ガードが `read:files` / `edit:files` を手渡したら、その 1 呼び出しで出し直す。形式は `docs/josh-commands-session.md` →「`josh read:files`」と「`josh edit:files`」。

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

@@ -14,19 +14,19 @@
 
 **実行中のリポジトリ自身はこの手順の対象外である。** kit の中で kit のラン機構（`backlog:drive`、`run:wake`、`run:carry`、レーン、分類、カウンタ、ガードなど）の不具合を見つけたら、上流 Issue で停止する代わりに、このリポジトリの割り込みとして次を行う。
 
-1. **起票する** — `pnpm josh issue:file "<title>" --body-file <path> --route interrupt --label priority:high --blocks-finder`。上限は効かない（`wip-cap.md` →「割り込み起票 — 上限が効かない側」の条件 2）
+1. **起票する** — `pnpm josh issue:file "<title>" --body-file .josh/tmp/issue.md --route interrupt --label priority:high --blocks-finder`。上限は効かない（`wip-cap.md` →「割り込み起票 — 上限が効かない側」の条件 2）
 2. **止まらずに直す** — 壊れた機構を迂回せず、検証ゲートも緩めない。`backlogrun` の中では割り込みを次の子にし、着地後に塞がれていた子へ戻る（プールでは `priority:high` が先頭、epic の下では `wip-cap.md` の手順 3 で挿入、名前指定のランでは `pnpm josh lane:launch <N>` で自分で dispatch）。バッチの外では `wip-cap.md` の手順 4 どおり、打つべき `fullrun #<N>` を報告して止まる
-3. **再開できるなら自分で再開し、動くことを確かめる** — 修正のマージ後、手渡し済み・所有者が死んだ記録・監督プロセスの停止（`warning` Telegram）には `pnpm josh run:wake --start`、`run:carry` の `standing` には `pnpm josh run:carry --resume "<invocation>" --owner "$PPID"` を打つ。`pnpm josh run:wake --list` が監督プロセスを示し、ログに次の子の dispatch が現れることを確かめて報告する
+3. **再開できるなら自分で再開し、動くことを確かめる** — 修正のマージ後、手渡し済み・所有者が死んだ記録・監督プロセスの停止（`warning` Telegram）には `pnpm josh run:wake --start`、`run:carry` の `standing` には `pnpm josh run:carry --resume "<invocation>"` を打つ。`pnpm josh run:wake --list` が監督プロセスを示し、ログに次の子の dispatch が現れることを確かめて報告する
 4. **人に打ち直しを求めるのは再開の手段が無いときだけ** — `mismatch`（別の起動の記録）、別の生きた所有者の `busy`。新しい承認を宣言するのは人だけ
 5. **`needs-decision` を付けない**（`.claude/skills/workflow-commands/backlogrun-park.md` → "Only a person's judgement carries `needs-decision`"）
 
 手順:
 
-1. **現在の作業を退避する**: `pnpm josh stash:push "upstream-interrupt: paused #<N>"`（WIP コミットでも可）
-2. **進行中の Issue に状況を書く**: `pnpm josh issue:comment <N> --body-file <path>` で、stash したこと、中断理由（どの別パッケージのどんな問題か）、新 Issue へのリンク（`## Upstream issues` 見出しの下に `owner/repo#N` 形式、→「起票元へのバックリンク」）
-3. **対象パッケージのリポジトリに Issue を作成する（確認なし）**: `pnpm josh issue:file "<root-cause title>" --body-file <body-file> --route tier-a --repo <owner>/<repo>`（joshuafolkken/kit#1083）。検査・分類ラベル・重複探し・`epic:bundle` はコマンドが行う（`docs/josh-commands-backlog.md` → `josh issue:file`）。根本原因・再現・期待結果を `prompts/collaboration-workflow/issue-template.md` の Step 1 のテンプレで書き、`## Origin` 節に起票元 Issue を `owner/repo#N` 形式で書く
-4. **`confirmation` Telegram を送って停止する**: 上流 Issue の URL と何が止まっているかを書く（→ `rule-delivery.md` → "stop-notify"）
-5. **元の作業を再開する**: 上流の修正がマージされた、またはユーザーが先送りを明示判断した後に `pnpm josh stash:pop "upstream-interrupt: paused #<N>"` で復元する（`operating-rules.md` → "no-self-staging"）。上流 Issue を割り込みで実装するかもユーザーが決める
+1. **本文を書く**: 根本原因・再現・期待結果を `prompts/collaboration-workflow/issue-template.md` の Step 1 のテンプレで書き、`## Origin` 節に起票元 Issue を `owner/repo#N` 形式で書く
+2. **1 コマンドで止まる（確認なし）**: `pnpm josh upstream:interrupt <N> "<root-cause title>" --repo <owner>/<repo> --body-file .josh/tmp/issue.md [--blocks-finder]`。退避・`issue:file --route interrupt` での起票・起票元への `## Upstream issues` バックリンク・`confirmation` Telegram をこの順に行う（`docs/josh-commands-run.md` → `josh upstream:interrupt`）
+   - 失敗した手順で止まり、打ち直すコマンドを出す
+   - third-party なら起票せず、本文を `## Upstream candidate` の下書きとして起票元に残す（→「第三者リポジトリへの書き込みは Tier C」）
+3. **元の作業を再開する**: 上流の修正がマージされた、またはユーザーが先送りを明示判断した後に、バックリンクにある `pnpm josh stash:pop "upstream-interrupt: paused #<N>"` で復元する（`operating-rules.md` → "no-self-staging"）。上流 Issue を割り込みで実装するかもユーザーが決める
 
 ### first-party の Issue・PR への書き込みは確認不要
 
@@ -44,7 +44,7 @@
 
 - **判定は `pnpm josh repo:party [<owner/repo>]` が答える**: `first-party` / `third-party` / `unknown`（unknown は third-party 扱いしない）。fork や contribute しているだけの org リポジトリも third-party
 - **third-party への書き込みは種別を問わず Tier C**: Issue・コメント・PR・Discussion・レビュー、既存 Issue のクローズ・編集も、その turn のユーザーの明示指示なしに行わない。正しい診断も許可ではない
-- third-party と判明したら: (1) 自分たちの側の Issue に証拠込みで所見を `## Upstream candidate` 見出しで記録する（`## Upstream issues` は使わない）。(2) 報告本文の下書きをその Issue 内に用意する。(3) 対象プロジェクト名と報告内容を書いた `confirmation` Telegram を送って停止する
+- third-party と判明したら: (1) 自分たちの側の Issue に証拠込みで所見を `## Upstream candidate` 見出しで記録する（`## Upstream issues` は使わない）。(2) 報告本文の下書きをその Issue 内に用意する。(3) 対象プロジェクト名と報告内容を書いた `confirmation` Telegram を送って停止する。(1)〜(3) は `pnpm josh upstream:interrupt` が third-party の `--repo` で行う
 - 下書きの前に揃える証拠: 自プロジェクトの外で成立する最小再現（無ければ「プロジェクト組み込みの再現しかない」と明記）、全主張の検証、既存 Issue の検索
 
 ### 検証ゲートを緩めることも「回避策」である

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

@@ -8,9 +8,9 @@
 
 **件数は `pnpm josh issue:file` が起票の前に数える**（joshuafolkken/kit#3181、`docs/josh-commands-backlog.md` → "`josh issue:file`"）。手や記憶で数えない。
 
-- **上限は 30。** 一次情報は `scripts/issue/issue-wip.ts` の `WIP_CAP`（他の文書にこの数字を書かない）。
+- **上限は既定 30。** 一次情報は `scripts/issue/issue-wip.ts` の `DEFAULT_WIP_CAP`（他の文書にこの数字を書かない）。env `JOSH_WIP_CAP` が正の整数なら上限をその値に、`off` なら上限を無効にする。それ以外の値は既定に戻さず、起票を拒否する（`docs/environment-variables.md`）。
 - コマンドは起票先（`--repo` 指定時はそのリポジトリ）のオープン Issue を epic 込みで数えて `wip:` 行に印字し、超過して免除が無ければ何も送らずに保留し、免除の問いを印字する。
-- 免除の宣言: `--route interrupt`（下の 3 条件）、`--route split` / `--route tier-a`（実行が詰まる起票）はルート自体が宣言になる。ルートの無い実行が詰まる起票（利用者が `new` と打った入口など）は `--over-cap` を付けて出し直す。裁量起票（`--route review-cap` を含む）に `--over-cap` を付けてはならない。
+- 免除の宣言: `--route interrupt`（下の 3 条件）、`--route split` / `--route tier-a`（実行が詰まる起票）はルート自体が宣言になる。利用者が `new` と打った入口は、手順書の起票コマンドが最初から `--over-cap` を付ける。そのほかのルートの無い実行が詰まる起票は `--over-cap` を付けて出し直す。裁量起票（`--route review-cap` を含む）に `--over-cap` を付けてはならない。
 
 ## 超過時の手順
 
@@ -55,7 +55,7 @@
 1. **上限に関係なく起票する。** 1 件閉じることを条件にしない。本文の検査、分類ラベルの付与、重複探し、`epic:bundle` はコマンドが行う（`docs/josh-commands-backlog.md` → `josh issue:file`）。
 
    ```bash
-   pnpm josh issue:file "<title>" --body-file <body-file> --route interrupt
+   pnpm josh issue:file "<title>" --body-file .josh/tmp/issue.md --route interrupt
    ```
 
    `--blocks-finder` は付けない。発見したランを塞がない割り込みに起票元の `blocked-by` を書くと、偽の依存関係になる。

package/prompts/refactoring.md

@@ -15,10 +15,11 @@ pnpm josh refactor:scan
 
 - 対象ファイル: 作業ツリーの変更＋main との差分＋未追跡ファイル。いずれも無ければ `scripts/` 配下。`demo`・`src/routes/stories`・先頭に `/* @refactor-ignore */` を持つファイルは除外。
 - スコープ拡張: import グラフを双方向に最大3段階たどり、新規0件で止める。拡張後の集合を印字する。
-- **候補の集計**: eslint の件数と file:line — 行数・複雑度（`max-lines` / `max-lines-per-function` / `complexity` / `sonarjs/cognitive-complexity`）、型の安全性（`@typescript-eslint/no-explicit-any`）、名前空間エクスポート（`local/namespace-object-export`）、重複コード（`sonarjs/no-identical-functions`）、変数名の書式（`@typescript-eslint/naming-convention`）、重複文字列（`sonarjs/no-duplicate-string`）、マジックナンバー（`@typescript-eslint/no-magic-numbers`）、未使用コード（低優先度: `@typescript-eslint/no-unused-vars`）。件数は `pnpm josh gate` の eslint と同一。
+- **候補の集計**: eslint の件数と file:line — <!-- lint: refactor-scan-rules -->lines & complexity（`max-lines` / `max-lines-per-function` / `complexity` / `sonarjs/cognitive-complexity`）、type safety（`@typescript-eslint/no-explicit-any`）、namespace-object export（`local/namespace-object-export`）、duplicate code（`sonarjs/no-identical-functions`）、duplicate string（`sonarjs/no-duplicate-string`）、magic number（`@typescript-eslint/no-magic-numbers`）、variable naming（`@typescript-eslint/naming-convention`）、unused code（低優先度: `@typescript-eslint/no-unused-vars`）<!-- /lint -->。件数は `pnpm josh gate` の eslint と同一。
+- inline config: gate と同じ設定を使い、外部形式のキーなどに付けた有効な例外は候補に数えない。抑制されていない規約違反は引き続き報告する。
 - 収束判定: 高・中優先度の候補が0件なら `verdict: clear`、残れば `verdict: candidates`。低優先度は報告のみで数えない。
 
-行数はコード行数（`max-lines` / `max-lines-per-function` は `skipBlankLines` と `skipComments` 有効）。`wc -l` ではなくこのコマンドの報告で判断する。
+行数はコード行数（<!-- lint: line-counting -->`max-lines` / `max-lines-per-function`<!-- /lint --> は `skipBlankLines` と `skipComments` 有効）。`wc -l` ではなくこのコマンドの報告で判断する。
 
 ---
 
@@ -90,4 +91,4 @@ lint が一部の面しか見ない項目だけを挙げる。コーディング
 
 ## 実装後の品質保証（絶対遵守）
 
-実装後は `pnpm josh lint:related` → `pnpm josh gate` の順で全関与ファイルを確認し、エラー0件になるまで修正する。エラーが残ったまま完了報告しない。レーン子の gate は `josh ship` が回す（`.claude/skills/workflow-commands/chain-rule.md` → "Run the review-to-merge chain" step 0）。
+実装後は `pnpm josh lint:related` → `pnpm josh gate` の順で全関与ファイルを確認し、エラー0件になるまで修正する。エラーが残ったまま完了報告しない。レーン子の gate は `josh ship` が回す（`.claude/skills/workflow-commands/chain-rule.md` → "A lane child"）。