@joshuafolkken/kit 1.1514.0 → 1.1784.0

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

@@ -6,24 +6,14 @@
 
 ラベルの有無、概要行の字数上限、コードフェンス囲み、概要へのファイルパス・CLI フラグの混入、ケース段と「壊れるとしたら」段の形は、サマリを標準入力で `pnpm josh report:lint` に渡して検査する（`ok` か違反行を印字する — joshuafolkken/kit#2123）。
 
-### 出力はコードフェンスで囲まない（必須）
+### 骨組みは `josh report:template` が印字する
 
-以下のテンプレートは**フェンスの中身だけ**をセッションに書く（空白での桁揃えと単独行の `---` も使わない）。
+作業前サマリと完了報告の骨組みは `pnpm josh report:template summary|done [<path>...]` で印字し、写さない。ラベルは `report:lint` と同じ 1 つのラベル表（`scripts/report/report-labels.ts`）から、`JOSH_SESSION_LANG` の言語で出る（`ja` 以外は英語）。渡したパスは「対象」「変更ファイル」と変更ごとの行を埋め、そのパスに `josh cases` が求める異常系を「壊れるとしたら」の先頭に置く。残る `<…>` だけを書く。
 
-### ラベルはセッション言語に訳し、注釈は付けない（必須）
-
-**(1) ラベルはセッション言語に訳す。** 日本語セッションでの対応:
-
-- `■ 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 つだけ。
-
-**(2) ラベルに注釈を付けない。** `■ 概要（平易な説明）` は誤り。注意書きはラベルの下の説明文に置く。
+- 出力はコードフェンスで囲まない（空白での桁揃えと単独行の `---` も使わない）
+- ラベルに注釈を付けない。`■ 概要（平易な説明）` は誤り。注意書きはラベルの下の説明文に置く
+- 成果物の散文（Issue 本文、Issue／PR コメント、Telegram 本文）のラベルも、このコマンドが印字するラベルで書く。英語のまま残るのは「出力の言語（`JOSH_SESSION_LANG`）」が挙げた 3 つだけ
+- 区切り（hand-off）のラベルも同じ表にあり、`pnpm josh run:report --handoff` が印字する
 
 ### 作業前サマリはいつ・どう出すか
 
@@ -34,37 +24,18 @@
 
 ### 作業前サマリ（セッション向け・`JOSH_SESSION_LANG` の言語）
 
-```md
-**■ 概要**
-
-- **今こうなっている**: <1文 — 利用者から見て何が起きているか>
-- **こう直す**: <1文 — 手段ではなく、直った後どうなるか>
-- **確かめ方**: <1文 — どう確認するか>
-
-**技術詳細**
-
-- 対象: <触るファイル / モジュール>
-- 方針: <アプローチとその理由>
-- 副作用 / スコープ外: <意図的にスコープ外にした点。なければ省略>
+`pnpm josh report:template summary <触るファイル...>` が印字する。各欄に書くこと:
 
-**変更とテスト**
-
-1. <変更内容> — Test: <Unit|E2E> — `<file path>` — <検証する挙動>
-   - ケース: 正常 / 空・0件 / 1件 / 多数 / 境界 / 不正入力 / 重複 / 順序 / null
-     - 該当しないものは消し、消した理由を添える（例:「重複: 該当なし — 入力は集合なので重複しない」）
-   - 壊れるとしたら:
-     1. <この変更に固有の、壊れうる条件>
-     2. <...>
-     3. <...>
-2. ...
-```
+- 概要の 3 行: 利用者から見て何が起きているか / 手段ではなく直った後どうなるか / どう確認するか
+- 方針はアプローチとその理由、副作用 / スコープ外は意図的に外した点（なければ省略）
+- 変更ごとの行は `<変更内容> — Test: <Unit|E2E> — <テストのファイルパス> — <検証する挙動>`
 
 テスト宣言はケース単位の 2 段で書く（joshuafolkken/kit#2246）。
 
-- 第 1 段（ケース）は固定語彙を並べ、**該当しないものは `該当なし` に続けて理由を書いて消す**
+- 第 1 段（ケース）は固定語彙を並べ、**該当しないものは `該当なし` に続けて理由を書いて消す**（例:「重複: 該当なし — 入力は集合なので重複しない」）
 - 第 2 段（壊れるとしたら）は、この変更に固有の壊れうる条件を**最低 3 件**書く。書けないときは `どう呼ばれても壊れない` と明示する
 - 複数ケースは `it.each` 1 本に畳んでよい
-- 差分が HTTP・プロセス起動・ファイル IO・時間の境界を跨ぐときは、`pnpm josh cases <path...>` が印字する異常系を第 2 段に載せる
+- 差分が HTTP・プロセス起動・ファイル IO・時間の境界を跨ぐとき、または共有状態（`.josh/` 配下・lock）や環境（`process.env`・常駐プロセス）に依存するときは、`pnpm josh cases <path...>` が印字する異常系を第 2 段に載せる。共有状態には同じ状態を読み書きする他のソースが `file:line` で付く
 
 ### 行数予算は編集前に読む
 
@@ -72,46 +43,46 @@
 
 ### 変更対象はまとめて読んでから編集する（joshuafolkken/kit#2202）
 
-**「変更とテスト」が変更対象ファイルを列挙したら、1 回の `pnpm josh read:files <path> [<path> ...]` で読み、続く独立した編集は 1 回の `pnpm josh edit:files -` で送る**（個別の `Edit` は依存する編集・1 件だけの編集・`Write` のとき）。詳細は [`turn-batching.md`](turn-batching.md) →「実装中の独立編集に効く合成コマンド」。
+`pnpm josh read:files` / `edit:files` で畳む — [`turn-batching.md`](turn-batching.md) →「実装中の独立編集に効く合成コマンド」。
 
 ### 完了報告（セッション向け）
 
-```md
-**■ 完了報告**
-
-- **原因**: <1文 — なぜそうなっていたか>
-- **対応**: <1文 — 何をしたか>
-- **結果**: <1文 — 利用者から見て何が変わったか>（v<version>）
+`pnpm josh report:template done <変更したファイル...>` が印字する。各欄に書くこと:
 
-**技術詳細**
-
-- 変更ファイル: <...>
-- テスト結果: <...>
-- 実行証跡: <実行可能な経路を触った変更では、実際に叩いたコマンドとその出力（UI ならスクリーンショット）。無いなら理由>
-- 捕まえられた検証: <不具合修正のみ。その検証の種類を 1 行（2 回目は台帳で昇格, #2448）>
-- 残課題: <なければ「なし」>
-```
+- 概要の 3 行: なぜそうなっていたか / 何をしたか / 利用者から見て何が変わったか（版を添える）
+- 実行証跡: 実行可能な経路を触った変更では、実際に叩いたコマンドとその出力（UI ならスクリーンショット）。無いなら理由
+- 捕まえられた検証: 不具合修正のみ。その検証の種類を 1 行（2 回目は台帳で昇格, #2448）
+- 残課題: なければ「なし」
 
 **実行証跡は「動くこと」の証拠であり、gate の緑ではない**（joshuafolkken/kit#2246）。同じ証跡を PR 本文の `## 実機証跡` 節（コマンド＋実出力のフェンス）にも置く。無い実行時の変更は `pnpm josh followup` がマージを拒否する（#2446）。
 
 ### PR 本文の受け入れ条件の対応表
 
-`## 受け入れ条件の対応` 節の行の形（`pnpm josh pr` が識別子つきの `未記入` 行を付け、`pnpm josh followup` が照合する — `scripts/review/acceptance-map.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`）:
 
 ```md
 - `ac-1a2b3c4d` <条件> — 満たした: <テスト名・`file:line`・実行出力のいずれか>
 - `ac-5e6f7a8b` <条件> — 見送り: #<切り出した Issue> <理由>
 ```
 
+### PR 本文の消えたテストの処置
+
+`## 消えたテストの処置` 節の行の形（`pnpm josh review:brief` が `Removed tests` として一覧化し、`pnpm josh ship` と `pnpm josh followup` が照合する — `scripts/review/removed-tests.ts`。緑の `pnpm josh test:related` が、テスト名入りの `未記入` 行を ship 本文の下書きに足す — `scripts/run/ship/run-ship-removed-rows.ts`）:
+
+```md
+- `<describe> > <テスト名>` — 置き換え: <いまその振る舞いを守るテスト名>
+- `<describe> > <テスト名>` — 廃止: #<振る舞いの廃止を決めた Issue> <理由>
+```
+
 **`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）は完了報告ではない — **`原因` / `対応` / `結果` を使わない**。報告は `pnpm josh run:report --handoff` が印字し、手で書かない（[`.claude/skills/workflow-commands/backlogrun-handoff-report.md`](../../.claude/skills/workflow-commands/backlogrun-handoff-report.md)）。
 
 ### 概要 3 行の書き方（ここが本体）
 
-字数と内部識別子の混入は `report:lint` が検査する。平易にするために語彙と抽象度を制約する:
+平易にするために語彙と抽象度を制約する:
 
 - 専門用語は使わないか、`〜（＝…のこと）` の形でその場で言い換える
 - 変更点の羅列ではなく、原因 → 対応 → 効果の因果で書く
@@ -124,7 +95,7 @@
 - **何かが「古い」「壊れている」「変わらない」と書くときは、その対象を名指しする** — 対象パッケージ名・画面名・出力の種類のいずれかを含める
 - 主語のない「状況」「案内」「問題」「その処理」だけで済ませない
 - 書いてよい具体名: 利用者が画面で目にするもの — パッケージ名、表示されるコマンドの目的、画面名、メッセージの種類
-- 書いてはいけない具体名: 内部識別子 — ファイルパス、関数名・型名、CLI のオプションフラグ
+- 書いてはいけない具体名: 内部識別子（上記「作業前サマリはいつ・どう出すか」）
 
 悪い例は「古いままだと警告が出るのに、案内されたコマンドを実行しても状況が変わらない」（何の話か特定できない）。良い例:
 

package/prompts/collaboration-workflow/residency.md

@@ -24,7 +24,7 @@
 
 > **その規則が効き始める瞬間を、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 以外のエージェントでの読み替え」）。
+できるなら、規則本文を常駐から出し、配送ガードの行に説明（`about`）を持たせ、[`rule-delivery.md`](./rule-delivery.md) が指す `pnpm josh rule:list` の一覧に載せる（joshuafolkken/kit#1524）。**規則ごとのトリガ行は常駐に残さない** — `CLAUDE.md` には一覧への導線 1 行だけを置く。フックが走らないセッションは一覧を自己点検に使う（`principles.md` →「Claude Code 以外のエージェントでの読み替え」）。
 
 ### 第 2 問 — skill なしのターンでも効く必要があるか
 
@@ -36,6 +36,6 @@
 
 - **常駐規則は、トリガと導線の 2 つで書く。** **判定は、導線を一度も開かないターンでも常駐の記述だけで正しく振る舞えるかである。**
 - **削ることは移すことであり、削除は理由を示して初めて許される例外である。** 先に導線の先へ移し、マーカーテストも付け替える。移さず引退させてよいのは 3 条件がすべて揃うときだけ — 同じ文書に単一ソースが宣言された文の写しである・単一ソースと突き合わせてほかにない文を含まない・マーカーテストが固定していない。揃わなければ候補と証拠を記録して規則は残す
-- 経緯（Issue 番号・なぜ・計測・却下案）は `docs/maintainers/<topic>-rationale.md` に置き、その冒頭で説明する手順文書を名指しする。**参照の向きは根拠 → 手順だけ** — AI が読む文書から根拠文書は指さない（`scripts/document/rationale-documents.test.ts` が検出する）。Issue 番号引用の件数は `scripts/document/issue-citation-budget.ts` のラチェットに従う — 減らしたら記録も下げる
+- 経緯（Issue 番号・なぜ・計測・却下案）は `docs/maintainers/<topic>-rationale.md` に置き、その冒頭で説明する手順文書を名指しする。**参照の向きは根拠 → 手順だけ** — AI が読む文書から根拠文書は指さない（`scripts/document/rationale-documents.test.ts` が検出する）。Issue 番号引用の件数は `tools/document/issue-citation-budget.ts` のラチェットに従う — 減らしたら記録も下げる
 - 引用は本文があるファイルを直接指す
 - 予算が詰まったら回収で解く。**引き上げは Tier C として扱う** — `RESIDENT_CEILING_BYTES`・`RESIDENT_HEADROOM_BYTES`・`RE_INLINE_GUARD_HEADROOM_BYTES` の緩和は、3 条件（回収の余地が尽きたことを計測で示す・需要が 1 規則ではなく常駐すべき規則数の増加から来る・増やす量は需要と回収可能量の差だけで丸めない）を示し、ユーザーの明示指示を得てから行う。条件が揃うこと自体は指示ではない

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

@@ -1,22 +1,10 @@
 ## 本文をシェルの二重引用符に載せない（joshuafolkken/kit#1198）
 
-`CLAUDE.md` からは [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」を経て届く。[`file-edits.md`](./file-edits.md) が防ぐのはコストの二重払い、こちらが防ぐのは**テキストが実行されること**である。
-
-### 何が起きるのか
-
-二重引用符の中のバッククォートと `$` は実行前に評価される。次の呼び出しは `pnpm josh ms` を実行し、その出力を本文に埋め込む。
-
-```bash
-gh api repos/{owner}/{repo}/issues/1535/comments -f body="… `pnpm josh ms` は …"
-```
-
-`pnpm josh followup --notify-message "…"` も同じく壊れる。
-
-発火するのは `` ` `` と `$` で、`!` ではない。
+防ぐのは本文の**テキストが実行されること**である。二重引用符の中の `` ` `` と `$` は実行前に評価される（`!` は評価されない）。
 
 ### 安全な書き方
 
-**本文をファイルに書いて、パスで渡す。**
+**本文をファイルに書いて、パスで渡す。** `--body-file` の本文や計画メモは `.josh/tmp/` に置く（ignore 済みなのでコミットに混ざらない）。
 
 ```bash
 pnpm josh issue:comment <N> --body-file <path>
@@ -29,7 +17,9 @@ PR コメントも `pnpm josh issue:comment <N> --body-file <path>` で投稿す
 
 ### コメント投稿は `pnpm josh issue:comment` の 1 綴りだけ（joshuafolkken/kit#2304）
 
-`gh api` の `-f body=@<path>` ／ `--raw-field body=@<path>` は `@<path>` というリテラルを黙って投稿する。**Issue／PR コメントの投稿は `pnpm josh issue:comment <N> --body-file <path>` ただ 1 綴りに寄せる。** `-f body=@…` は `pnpm josh rule:guard` が実行前に拒否する（`raw-field-body` 行、`scripts/rules/raw-field-body.ts`）。Issue body 書き換えの `-X PATCH ... --field body=@<path>` は `-F` 側で安全なのでそのまま使う。
+自リポジトリへの `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>` は安全なのでそのまま使う。
 
 `--body-file` / `--notify-message-file` は `-` で標準入力を読む（実装は `scripts/josh/cli-body.ts`）。`--body` と `--body-file` の同時指定は拒否される。
 
@@ -37,4 +27,4 @@ PR コメントも `pnpm josh issue:comment <N> --body-file <path>` で投稿す
 
 ### 引き金つき配送
 
-`pnpm josh rule:guard` は、二重引用符の本文値にバッククォートか `$` を含む `Bash` 呼び出しを拒否する。拒否されたら本文をファイルに移して出し直す。**引き金が見えない綴り（`-b`・`-f title=` など）でも、フックが走らないエージェントでも規則は同じく拘束する。**
+`shell-body` 行が強制する。引き金が見えない綴り（`-b`・`-f title=` など）でも規則は同じく拘束する。

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

@@ -1,7 +1,5 @@
 # 独立した呼び出しは同じターンに載せる（joshuafolkken/kit#1304）
 
-常駐側には [`rule-delivery.md`](./rule-delivery.md) →「配送されている規則」への導線だけが残り、規則本文は `pnpm josh batch:guard` が効く瞬間に配送する。
-
 ## 何を求めているか
 
 > **この呼び出しの入力は、いま出していない別の呼び出しの結果に依存しているか。**

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

@@ -14,7 +14,7 @@
 
 **実行中のリポジトリ自身はこの手順の対象外である。** kit の中で kit のラン機構（`backlog:drive`、`run:wake`、`run:carry`、レーン、分類、カウンタ、ガードなど）の不具合を見つけたら、上流 Issue で停止する代わりに、このリポジトリの割り込みとして次を行う。
 
-1. **起票する** — `pnpm josh issue:file "<title>" --body-file <path> --depth <n> --route interrupt --label priority:high`。上限は効かない（`wip-cap.md` →「割り込み起票 — 上限が効かない側」の条件 2）
+1. **起票する** — `pnpm josh issue:file "<title>" --body-file <path> --route interrupt --label priority:high`。上限は効かない（`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 が現れることを確かめて報告する
 4. **人に打ち直しを求めるのは再開の手段が無いときだけ** — `mismatch`（別の起動の記録）、別の生きた所有者の `busy`。新しい承認を宣言するのは人だけ
@@ -22,15 +22,25 @@
 
 手順:
 
-1. **現在の作業を退避する**: `git stash push -u -m "upstream-interrupt: paused #<N>"`（WIP コミットでも可）
+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> --depth <n> --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` 形式で書く
+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 と何が止まっているかを書く（→ `CLAUDE.md` → "Mid-workflow stop notification (`confirmation`)"）
 5. **元の作業を再開する**: 上流の修正がマージされた、またはユーザーが先送りを明示判断した後に `pnpm josh stash:pop "upstream-interrupt: paused #<N>"` で復元する（`operating-rules.md` → "no-self-staging"）。上流 Issue を割り込みで実装するかもユーザーが決める
 
+### first-party の Issue・PR への書き込みは確認不要
+
+`pnpm josh repo:party` が `first-party` と答えたリポジトリの Issue・PR への書き込みは Tier A で、ユーザーに確認しない。起票、コメント、ラベル、本文の編集、`@dependabot rebase` などの Dependabot へのコマンドコメントを含む。
+
+- 頼まれていない観察の起票はこの節で許可しない: この節が外すのは書き込み先の確認だけ。起票するかは `.claude/skills/workflow-commands/observation-filing.md` に従う
+- `unknown` はこの節の対象外: first-party と判定できないので、書き込む前にユーザーに確認する
+
+- **「外部への書き込み」は third-party への書き込みだけを指す**。first-party への書き込みをそう呼ばない
+- マージ・ブランチ削除などの共有状態の操作は書き込みに含まれず、Tier C のまま（`CLAUDE.md` → "Git Rules"）
+
 ### 第三者リポジトリへの書き込みは Tier C（明示指示が必要）
 
-「起票は確認なし」は first-party だけに成り立つ。
+「起票は確認なし」も「書き込みは確認不要」も first-party だけに成り立つ。
 
 - **判定は `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 のユーザーの明示指示なしに行わない。正しい診断も許可ではない

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

@@ -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> --depth <n> --route interrupt
+   pnpm josh issue:file "<title>" --body-file <body-file> --route interrupt
    ```
 
 2. 超過している事実と当たった条件の番号を、両方とも本文に 1 行書く（例:「オープン 37 件で起票。3 条件のうち 2（文書化された手順が完了できない）に該当」）。

package/prompts/collaboration-workflow.md

@@ -1,13 +1,8 @@
 # Issue-Driven Collaboration Workflow
 
-複数の AI ツール（Claude / Cursor / Gemini）で共通に使う Issue 駆動ワークフローの**索引**。
+複数の AI ツール（Claude / Cursor / Gemini）で共通に使う Issue 駆動ワークフローの**索引**。人間が読むための索引であり、規則を定める場所ではない。必要な 1 本だけを開く。
 
-## この索引の使い方
-
-人間が読むための索引であり、規則を定める場所ではない。常駐の引き金は `CLAUDE.md`、実行中の手順は `.claude/skills/workflow-commands/`、各話題の規則は下表のファイルが一次情報である。
-
-- 下表から必要な 1 本だけを開く。
-- 他の文書から話題を指すときは、索引でなく**本文があるファイルを直接指す**（[`residency.md`](./collaboration-workflow/residency.md)）。
+他の文書から話題を指すときは、索引でなく**本文があるファイルを直接指す**（[`residency.md`](./collaboration-workflow/residency.md)）。
 
 | 話題                                                       | ファイル                                                                  |
 | ---------------------------------------------------------- | ------------------------------------------------------------------------- |
@@ -27,6 +22,7 @@
 | 常駐ドキュメントと skill の分担                            | [`residency.md`](./collaboration-workflow/residency.md)                   |
 | 引き金つき配送 — 規則を効く瞬間に届ける                    | [`rule-delivery.md`](./collaboration-workflow/rule-delivery.md)           |
 | コマンド出力が文脈へ持ち込む量の上限                       | [`output-bounds.md`](./collaboration-workflow/output-bounds.md)           |
+| 所要時間は記録から測る                                     | [`measurement.md`](./collaboration-workflow/measurement.md)               |
 | 運用ルール                                                 | [`operating-rules.md`](./collaboration-workflow/operating-rules.md)       |
 | 用語集 — lane・cut・hold・park など                        | [`glossary.md`](./collaboration-workflow/glossary.md)                     |
 | headless のレーン子・レビューの起動時の規則セット          | [`lane-instructions.md`](./collaboration-workflow/lane-instructions.md)   |

package/prompts/refactoring.md

@@ -90,4 +90,4 @@ lint が一部の面しか見ない項目だけを挙げる。コーディング
 
 ## 実装後の品質保証（絶対遵守）
 
-実装後は `read_lints` → `pnpm run lint` の順で全関与ファイルを確認し、エラー0件になるまで修正する。エラーが残ったまま完了報告しない。
+実装後は `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）。

package/prompts/review-rubric.md

@@ -171,7 +171,7 @@ switching `no-restricted-syntax` off.
 ### 6. Tests
 
 - Every code change has a corresponding test (unit or E2E) per `CLAUDE.md` Code Change Rules Step 0
-- Test titles are English only and describe behavior, not implementation
+- Test titles describe behavior, not implementation
 - **Mutation check**: for the most critical test added or changed — if the key assertion/condition in
   the implementation were inverted or removed, would it fail? If no or uncertain, rewrite it.
 - **Requirement check**: does the test verify the behavior the issue/task describes, or only that code
@@ -179,7 +179,6 @@ switching `no-restricted-syntax` off.
 
 ### 7. Comments & content
 
-- Comments are English only
 - No narration comments (`// Added for issue #123`, `// TODO: refactor later`) — only non-obvious _why_
 - No duplicated logic that should be extracted
 

package/prompts/review.md

@@ -24,9 +24,10 @@ first review counts), whichever comes first. Round 2 is a verification pass over
 
 ## Before round 1 — the implementer's self-check
 
-Answer these five over your own diff before the scoped pair that precedes round 1, and fix what an
-answer turns up (about two in three of 135 sampled round-1 High/Medium findings fell under one). The
-review, its severity tests and the round cap are unchanged.
+Answer these nine over your own diff before the scoped pair that precedes round 1, and fix what an
+answer turns up (about four in five of 100 sampled High/Medium findings that stopped lane reviews
+fell under one; `pnpm josh lane:stats` counts the kinds that still stop). The review, its severity
+tests and the round cap are unchanged.
 
 1. **Tests pin the change** — for each condition, branch or call added or changed, name the test that
    turns red when it is deleted or inverted, and check its fixture reaches that branch (no assert on a
@@ -38,8 +39,24 @@ review, its severity tests and the round cap are unchanged.
    path returns something a caller can tell apart from `false`, `undefined` or "nothing found".
 4. **Every caller moved with it** — grep every reference to a changed function, list or command, and
    update each sibling path (the other CLI, the registry, the consumer side) in the same change.
+   The readers outside the diff: `pnpm josh review:brief` → `## Readers outside the diff`.
 5. **The Issue is met on HEAD** — the premises you relied on hold on the current tree, and each
    acceptance criterion is checked against the diff.
+6. **State is read fresh** — for every record, stamp, snapshot, memo or ledger a decision reads, name
+   its writer and check it cannot be older than the decision (a past `success`, a tick's shared
+   snapshot, a sync before the commit) or written by another run in between.
+7. **The rule covers its whole input space** — list every kind of input a scan, pattern, matcher or
+   lookup must accept or reject (the sibling file type, the consumer's config beside the root, quoted
+   text, a subshell, a pipe, a heredoc) and pin one test row per kind.
+8. **Edge inputs and environments** — say what the change does when its input is empty, absent or
+   new, and outside a TTY, a lane or the default agent runtime.
+9. **Claims about other components are checked in their code** — for every claim your code or a
+   comment makes about another component's behavior (what a stage does, who enforces a limit, which
+   repository it runs in), open that component's code and confirm it; then name each context the
+   change runs in — kit and a consumer, and a predecessor that died midway leaving its record behind.
+
+The brief lists `Removed tests` → each needs a `## 消えたテストの処置` row in the PR body, or the
+merge is refused: `prompts/collaboration-workflow/report-format.md` → "PR 本文の消えたテストの処置".
 
 ---
 
@@ -59,10 +76,20 @@ pnpm josh review:brief --level-only --staged   # the staged diff
 
 ---
 
+## Interaction review
+
+After round 1 and its record, `pnpm josh review:brief --interaction` answers whether the change takes
+the interaction review and prints its brief; hand it to a reviewer subagent, dispose of the findings
+by the three-way disposition below, and record the pass with
+`pnpm josh review:record --interaction --issue <N> [<category>:<severity>:<file> ...]`.
+
+`pnpm josh followup` refuses a due change with none recorded; `pnpm josh ship --review` runs it itself.
+
 ## Review round cap (2 rounds)
 
 Two rounds is the ceiling, not the schedule: every fix creates new surface a further round would find
-something in. Whether round 2 is due is `pnpm josh review:round2`'s answer (below).
+something in. Whether round 2 is due is `pnpm josh review:round2`'s answer (below). The interaction
+review is not one of the two.
 
 ### A merge-conflict resolution review is not one of the two
 
@@ -95,13 +122,8 @@ deferred. Without the flag, and on any uncertainty (a missing round-1 snapshot i
 One path outside that set makes it `required` — `.claude/**`, `CLAUDE.md`, a test, configuration, a
 code line, or a source file whose comment-free text cannot be read.
 
-Record a skipped round on the Issue:
-
-1. Label the Issue `review-round2-skipped`, created once per repository:
-   `gh api repos/{owner}/{repo}/labels -f name=review-round2-skipped -f color=c5def5 -f description="Review round 2 was skipped under the condition in prompts/review.md" --silent 2>/dev/null || true`,
-   then `gh api repos/{owner}/{repo}/issues/<N>/labels -f 'labels[]=review-round2-skipped'`.
-2. Comment under `## Round 2 skipped`, naming which arm fired and quoting the command's reason line
-   verbatim.
+Record a skipped round on the Issue with a comment under `## Round 2 skipped`, naming which arm fired
+and quoting the command's reason line verbatim.
 
 ### Three-way disposition after the cap
 
@@ -139,19 +161,17 @@ Branch 2 only:
   a `fold`; the first filing asks nothing.
 
   1. Before the current Issue closes, file it tagged `route:review-cap`:
-     `pnpm josh issue:file "<title>" --body-file <body-file> --depth <n> --route review-cap`. It lints
+     `pnpm josh issue:file "<title>" --body-file <body-file> --route review-cap`. It lints
      the body, applies the declared labels, runs the duplicate scan and `epic:bundle`
      (`docs/josh-commands-backlog.md` → `josh issue:file`). `epic:bundle` reads open issues only, so
      after the parent closes it answers `none` permanently.
-  2. Act on the printed `epic:bundle` answer by running the write command yourself — `epic:bundle`
-     writes nothing, and a hand edit of the epic body leaves the task list and `blocked-by` relations
-     disagreeing (`epic:next` returns `error`). Tier A, no confirmation:
-     - `add_to_epic` → `pnpm josh epic --add <E> <new>`, with `--before <M>` / `--after <M>` when the
-       relation carries an order.
-     - `create_epic` → `pnpm josh epic "<title>" <new> <other> [--ordered]`.
-     - `ask` (candidates across two or more epics) → run the recommended epic's write command and record
-       what was taken, what was rejected and why on the new Issue and that epic's `## Decisions`. Stop
-       only where the two epics are genuinely too close to separate.
+  2. Act on the printed `epic:bundle` answer with `pnpm josh epic:bundle <new> --apply` — never a
+     hand edit of the epic body, which leaves the task list and `blocked-by` relations disagreeing
+     (`epic:next` returns `error`). Tier A, no confirmation:
+     - `add_to_epic` / `create_epic` → `--apply` writes it, with any recorded order.
+     - `ask` (candidates across two or more epics) → `--apply` writes nothing; place it in the
+       recommended epic with `pnpm josh epic --add <E> <new> --decision-file <path>`
+       (`.claude/skills/epic-commands/epic-bundle.md`).
      - `none` → nothing.
      - Non-zero exit, or any ⚠ warning above `Nothing to bundle.` → stop and report what it said; a
        `none` after such a warning is not "nothing to bundle".

package/prompts/testing-guide.md

@@ -2,20 +2,7 @@
 
 ## 0. Per-Requirement Test Coverage (MANDATORY)
 
-Before any implementation code, **list every requirement from the user's request and assign a test to each one**.
-
-### Planning template
-
-```text
-Req 1: "Label chip shown immediately"
-  → E2E: open editor, type new label, press Enter → chip visible without blurring
-
-Req 2: "Down arrow moves to next row"
-  → E2E: open editor on row 1, press ↓ → row 2 enters edit mode
-
-Req N: ...
-  → Unit/E2E: ...
-```
+Every requirement gets a test (`CLAUDE.md` → "Code Change Rules" Step 0); the declaration's form is `prompts/collaboration-workflow/report-format.md` → "作業前サマリはいつ・どう出すか". This section decides which test.
 
 ### Rules
 
@@ -24,7 +11,6 @@ Req N: ...
 - **Non-runtime updates (pre-approved manual-only exception):** a change touching no executable runtime code path — docs, non-executable config, editor/IDE files, cosmetic asset swaps with no selector/path change — may be verified by hand; declare it in Step 0 with the reason. The mechanically exempt (`*.md`, `.editorconfig`, `.idea/**`, `.vscode/**`, `prompts/**`) need no declaration. A runtime change whose test is infeasible needs the reason and user approval.
 - **basic で kit がテストできない言語だけの変更:** `package.json` に `josh.profile: basic`（改名前の `static` も同じ）があり、変更が HTML/CSS や Lua などのソースだけなら自動テストは不要。HTML/CSS はブラウザーで対象ページを開き、想定する画面幅でレイアウト・リンク・HTML 内の操作を確認する。そのほかのソースは変更した処理を実際に動かす。どちらも結果を記録する。JavaScript または TypeScript のファイルを含む変更は自動テストを行う。
 - Test infeasible (e.g., a native OS date-picker Playwright cannot drive) → comment why in the test file and test the closest observable behavior (e.g., the editor stays open after `change`).
-- A requirement without its test is not done.
 
 ### Verification checklist (add to the completion gate)
 
@@ -58,10 +44,7 @@ Req N: ...
 
 ## 2. Test Guidelines
 
-### Naming
-
-- Variables/functions: `snake_case` | Constants: `UPPER_SNAKE_CASE`
-- Boolean prefix: `is_`, `has_`, `should_`, `can_`, `will_`, `did_`
+Naming, imports, `any`, `@ts-ignore`, magic numbers, template `String()` and the 10-statement limit are lint-enforced (`eslint/base.js`); this section holds only what lint cannot see.
 
 ### Test Functions
 
@@ -73,15 +56,6 @@ Req N: ...
 - Playwright: `for` loop; Vitest: `test.each` / `it.each`
 - Cases: a `cases` or `*_cases` array at file top, outside test functions
 
-### Constants
-
-- Magic numbers/strings except `0`, `1`, `-1` → `UPPER_SNAKE_CASE` constants after the imports
-
-### Imports
-
-- Always the `.js` extension: `import { foo } from './bar.js'`
-- Type imports: `import { type Foo } from '...'`
-
 ### Playwright
 
 - Select with `page.getByTestId('id')`; add `data-testid` to the implementation
@@ -102,17 +76,6 @@ When tests leave persistent state behind:
 ### Error Messages
 
 - State expected and actual values
-- Wrap `number` in template literals with `String()`
-- No `?? ''` unless the value can be `undefined`
-
-### Type Safety
-
-- No `any`; use every loop variable
-- `@ts-expect-error`, not `@ts-ignore`
-
-### Statement Limit
-
-- Max 10 statements per test function; split beyond that
 
 ### No live network
 
@@ -122,15 +85,15 @@ When tests leave persistent state behind:
 
 ### A josh command that writes state runs through the integration harness (kit only)
 
-- A new or changed state-writing josh command needs a test in all three environments of `scripts/test/josh-harness.ts` — kit, a consumer without `docs/`, a lane worktree (joshuafolkken/kit#2402). Packed suite: `vitest.harness.config.ts`
+- A new or changed state-writing josh command needs a test in all three environments of `tools/test/josh-harness.ts` — kit, a consumer without `docs/`, a lane worktree (joshuafolkken/kit#2402). Packed suite: `vitest.harness.config.ts`
 
 ---
 
 ## 3. Checklist
 
-- [ ] `pnpm josh gate`, then E2E per § 6: the CI E2E job where a pull request is open; where there is none, run `pnpm josh test:e2e` with `CI` unset (DEV: `pnpm run dev` on the port `playwright.config.ts` derives from `PORT_SEED`); no `pnpm build` or `CI=true` unless asked. Playwright cannot run here → report the E2E result missing and the gate not closed
-- [ ] `read_lints`: 0 errors on touched files; Playwright: no failures and no flaky runs
-- [ ] § 2 holds: constants, `.js` imports, `data-testid` selectors, correct `async`/`await`, no `any`, ≤10 statements, `String()` / no needless `?? ''`
+- [ ] `pnpm josh gate`, then the E2E gate per § 6
+- [ ] `pnpm josh lint:related`: 0 errors on touched files; Playwright: no failures and no flaky runs
+- [ ] § 2 holds: `data-testid` selectors, `async` Playwright tests, expected/actual in error messages
 
 ---
 
@@ -161,6 +124,8 @@ Decided by whether a pull request is open:
 
 **Never ask the user to run it**, in either row, and never report completion on an unread E2E result — unread is not a pass.
 
+Second row: run with `CI` unset (DEV: `pnpm run dev` on the port `playwright.config.ts` derives from `PORT_SEED`); no `pnpm build` or `CI=true` unless asked. Playwright cannot run here → report the E2E result missing and the gate not closed.
+
 Second row: prefer an integrated gate when the installed toolkit's printed command list has one (not by toolkit or version) — `@joshuafolkken/app-kit`'s `pnpm josh-app verify` builds and boots once for E2E and the DAST scan, delegating E2E to `josh test:e2e` (so the skip below applies).
 
 ### A project with no E2E suite

package/scripts/agent/agent-event.ts

@@ -1,15 +1,11 @@
 import { json_value } from '#scripts/lib/json-value'
+import { transcript_record, type TranscriptRecord } from '#scripts/lib/transcript-record'
 import { z } from 'zod'
 import type { AgentProvider } from './agent-role-profile'
 import { claude_result_event } from './claude-result-event'
 
-const TEXT_BLOCK_SCHEMA = z.looseObject({ type: z.literal('text'), text: z.string() })
-const CLAUDE_MESSAGE_SCHEMA = z.looseObject({ content: z.array(z.unknown()).optional() })
+const ASSISTANT_TYPE = 'assistant'
 const CLAUDE_INIT_SCHEMA = z.looseObject({ type: z.literal('system'), subtype: z.literal('init') })
-const CLAUDE_ASSISTANT_SCHEMA = z.looseObject({
-	type: z.literal('assistant'),
-	message: CLAUDE_MESSAGE_SCHEMA,
-})
 const USAGE_SCHEMA = z.looseObject({
 	input_tokens: z.number().optional(),
 	cached_input_tokens: z.number().optional(),
@@ -58,12 +54,16 @@ function usable_text(value: unknown): string | undefined {
 	return typeof value === 'string' && value.trim() !== '' ? value : undefined
 }
 
-function claude_progress(content: ReadonlyArray<unknown>): string | undefined {
-	return content
-		.map((block) => TEXT_BLOCK_SCHEMA.safeParse(block))
-		.filter((parsed) => parsed.success)
-		.map((parsed) => parsed.data.text)
-		.findLast((text) => text.trim() !== '')
+function claude_progress(record: TranscriptRecord): string | undefined {
+	return transcript_record
+		.blocks_of(record)
+		.filter((block) => block.type === transcript_record.TEXT_TYPE)
+		.map((block) => usable_text(block.text))
+		.findLast((text) => text !== undefined)
+}
+
+function is_claude_assistant(record: TranscriptRecord | undefined): record is TranscriptRecord {
+	return record?.type === ASSISTANT_TYPE && record.message !== undefined && record.message !== null
 }
 
 function claude_result(value: unknown, state: AgentEventState): AgentEventState | undefined {
@@ -80,9 +80,9 @@ function claude_result(value: unknown, state: AgentEventState): AgentEventState
 }
 
 function claude_assistant(value: unknown, state: AgentEventState): AgentEventState | undefined {
-	const assistant = CLAUDE_ASSISTANT_SCHEMA.safeParse(value)
-	if (!assistant.success) return undefined
-	const progress = claude_progress(assistant.data.message.content ?? []) ?? state.progress
+	const record = transcript_record.read(value)
+	if (!is_claude_assistant(record)) return undefined
+	const progress = claude_progress(record) ?? state.progress
 
 	return { ...state, provider: 'anthropic', progress }
 }

package/scripts/agent/agent-exit-record.ts

@@ -42,6 +42,18 @@ function is_mid_turn(transcript: string): boolean {
 	return TURN_TYPES.has(last)
 }
 
-const agent_exit_record = { is_mid_turn, read_exit_record }
+// Whether the transcript's last line is its exit record. A log appended across launches keeps an
+// earlier session's record, so a later session that died before finishing — inside a turn, or on a
+// start-up error that is not JSON — leaves something else last and its own ending unread.
+function ends_on_exit_record(transcript: string): boolean {
+	const last = transcript.split('\n').findLast((line) => line.trim() !== '')
+
+	return (
+		last !== undefined &&
+		claude_result_event.decode(json_value.parse_or_undefined(last)) !== undefined
+	)
+}
+
+const agent_exit_record = { ends_on_exit_record, is_mid_turn, read_exit_record }
 
 export { agent_exit_record }