@joshuafolkken/kit 1.972.0 → 1.983.0

package/dist/hooks/{chunk-NXL3SBXY.js → chunk-P3UX7SFN.js}

@@ -1,10 +1,10 @@
 import {
   lane_guard_policy,
   time_batch_guard
-} from "./chunk-2K52BRWV.js";
+} from "./chunk-ASUZGZFT.js";
 import {
   hook_decision
-} from "./chunk-KQG4776P.js";
+} from "./chunk-APVOACVT.js";
 
 // scripts/hooks/batch-guard.ts
 import { text } from "node:stream/consumers";

package/dist/hooks/{chunk-F6OM6SIG.js → chunk-RFPHKU7C.js}

@@ -1,16 +1,16 @@
 import {
   time_batch_guard
-} from "./chunk-2K52BRWV.js";
+} from "./chunk-ASUZGZFT.js";
 import {
   hook_decision
-} from "./chunk-KQG4776P.js";
+} from "./chunk-APVOACVT.js";
 import {
   cost_blocks,
   cost_transcript,
   time_bundle_call,
   time_shell,
   time_spans
-} from "./chunk-ZPLXLJ7O.js";
+} from "./chunk-47SPMGOD.js";
 
 // scripts/delegation/investigation-reads.ts
 import path from "node:path";
@@ -36,15 +36,15 @@ var DELEGATABLE_STEPS = [
   },
   {
     name: "followup-filing",
-    // The late-run follow-up filing chain — issue:scout → file the Issue → epic:bundle → epic --add
-    // — is a dependency chain `batch:guard` correctly keeps one call per step, and what makes it
-    // expensive is the ~340k context it runs in at the tail of a run, not the step count
-    // (joshuafolkken/kit#1892). A fresh unit runs the same chain at a small context, and the review
-    // round cap already composed the finding text, so what the unit is handed is mechanical: run the
-    // four commands and act on their deterministic answers. This is not `batch:guard`'s business —
-    // the chain stays one call per step; delegation only moves it to a cheaper context.
-    does: "run the late-run follow-up filing chain in an isolated unit \u2014 issue:scout, file the Issue, epic:bundle, epic --add \u2014 given the finding text the parent already composed, and return the new Issue number and the epic:bundle answer",
-    verifier: "the parent reads the filed Issue from GitHub with `pnpm josh issue:state <new>`, not the unit's summary; a follow-up reported filed but not created is still absent, the way `epic-child`'s reported-done-but-not-merged child is still open. The finding text came from the parent and `issue:scout` / `epic:bundle` are deterministic, so the unit's work is the mechanical execution `issue:state` confirms"
+    // The late-run follow-up filing chain — `issue:file` (which scouts, lints, labels and runs
+    // epic:bundle itself, joshuafolkken/kit#2808) → epic --add — is a dependency chain `batch:guard`
+    // correctly keeps one call per step, and what makes it expensive is the ~340k context it runs in
+    // at the tail of a run, not the step count (joshuafolkken/kit#1892). A fresh unit runs the same
+    // chain at a small context, and the review round cap already composed the finding text, so what
+    // the unit is handed is mechanical: run the commands and act on their deterministic answers. This
+    // is not `batch:guard`'s business — delegation only moves the chain to a cheaper context.
+    does: "run the late-run follow-up filing chain in an isolated unit \u2014 issue:file (scout, lint, labels, epic:bundle), then epic --add \u2014 given the finding text the parent already composed, and return the new Issue number and the epic:bundle answer",
+    verifier: "the parent reads the filed Issue from GitHub with `pnpm josh issue:state <new>`, not the unit's summary; a follow-up reported filed but not created is still absent, the way `epic-child`'s reported-done-but-not-merged child is still open. The finding text came from the parent and `issue:file`'s steps are deterministic, so the unit's work is the mechanical execution `issue:state` confirms"
   },
   {
     name: "implementation-unit",

package/dist/hooks/{chunk-ZYYSBNR6.js → chunk-ZT65LR3U.js}

@@ -1,16 +1,16 @@
 import {
   investigation_reads
-} from "./chunk-F6OM6SIG.js";
+} from "./chunk-RFPHKU7C.js";
 import {
   lane_guard_policy
-} from "./chunk-2K52BRWV.js";
+} from "./chunk-ASUZGZFT.js";
 import {
   hook_decision
-} from "./chunk-KQG4776P.js";
+} from "./chunk-APVOACVT.js";
 import {
   json_value,
   time_spans
-} from "./chunk-ZPLXLJ7O.js";
+} from "./chunk-47SPMGOD.js";
 
 // scripts/delegation/duplicate-read-guard.ts
 import { statSync } from "node:fs";

package/dist/hooks/codex-hook-adapter.js

@@ -1,25 +1,25 @@
 #!/usr/bin/env tsx
 import {
   pretool_guard
-} from "./chunk-BNWIOJFU.js";
-import "./chunk-WWTMHHZU.js";
+} from "./chunk-LBXQHXMC.js";
+import "./chunk-IM3KM25Y.js";
 import {
   build_envelope,
   compose_context,
   format_edited_payload
-} from "./chunk-CRGJTD6E.js";
+} from "./chunk-ERXMJJOV.js";
 import "./chunk-3V37IID6.js";
-import "./chunk-NXL3SBXY.js";
-import "./chunk-BVMSPG3M.js";
-import "./chunk-ZYYSBNR6.js";
-import "./chunk-F6OM6SIG.js";
-import "./chunk-2K52BRWV.js";
+import "./chunk-P3UX7SFN.js";
+import "./chunk-5JX6HXDX.js";
+import "./chunk-ZT65LR3U.js";
+import "./chunk-RFPHKU7C.js";
+import "./chunk-ASUZGZFT.js";
 import {
   hook_decision
-} from "./chunk-KQG4776P.js";
+} from "./chunk-APVOACVT.js";
 import {
   time_density_hook
-} from "./chunk-ZPLXLJ7O.js";
+} from "./chunk-47SPMGOD.js";
 import "./chunk-WPALEIRX.js";
 import "./chunk-RKUAD3I6.js";
 

package/dist/hooks/duplicate-read-guard.js

@@ -9,11 +9,11 @@ import {
   is_enabled,
   notice_refusal_path,
   refusal_path
-} from "./chunk-ZYYSBNR6.js";
-import "./chunk-F6OM6SIG.js";
-import "./chunk-2K52BRWV.js";
-import "./chunk-KQG4776P.js";
-import "./chunk-ZPLXLJ7O.js";
+} from "./chunk-ZT65LR3U.js";
+import "./chunk-RFPHKU7C.js";
+import "./chunk-ASUZGZFT.js";
+import "./chunk-APVOACVT.js";
+import "./chunk-47SPMGOD.js";
 import "./chunk-WPALEIRX.js";
 import "./chunk-RKUAD3I6.js";
 export {

package/dist/hooks/format-edited.js

@@ -15,9 +15,9 @@ import {
   relative_to_root,
   resolve_invocations,
   select_invocation
-} from "./chunk-CRGJTD6E.js";
+} from "./chunk-ERXMJJOV.js";
 import "./chunk-3V37IID6.js";
-import "./chunk-ZPLXLJ7O.js";
+import "./chunk-47SPMGOD.js";
 import "./chunk-RKUAD3I6.js";
 export {
   ESLINT_DAEMON,

package/dist/hooks/investigation-guard.js

@@ -10,11 +10,11 @@ import {
   is_enabled,
   load_environment_file,
   refusal_path
-} from "./chunk-BVMSPG3M.js";
-import "./chunk-F6OM6SIG.js";
-import "./chunk-2K52BRWV.js";
-import "./chunk-KQG4776P.js";
-import "./chunk-ZPLXLJ7O.js";
+} from "./chunk-5JX6HXDX.js";
+import "./chunk-RFPHKU7C.js";
+import "./chunk-ASUZGZFT.js";
+import "./chunk-APVOACVT.js";
+import "./chunk-47SPMGOD.js";
 import "./chunk-WPALEIRX.js";
 import "./chunk-RKUAD3I6.js";
 export {

package/dist/hooks/pretool-guard.js

@@ -3,16 +3,16 @@ import {
   pretool_guard,
   pretool_outcome,
   pretool_outcome_async
-} from "./chunk-BNWIOJFU.js";
-import "./chunk-WWTMHHZU.js";
+} from "./chunk-LBXQHXMC.js";
+import "./chunk-IM3KM25Y.js";
 import "./chunk-3V37IID6.js";
-import "./chunk-NXL3SBXY.js";
-import "./chunk-BVMSPG3M.js";
-import "./chunk-ZYYSBNR6.js";
-import "./chunk-F6OM6SIG.js";
-import "./chunk-2K52BRWV.js";
-import "./chunk-KQG4776P.js";
-import "./chunk-ZPLXLJ7O.js";
+import "./chunk-P3UX7SFN.js";
+import "./chunk-5JX6HXDX.js";
+import "./chunk-ZT65LR3U.js";
+import "./chunk-RFPHKU7C.js";
+import "./chunk-ASUZGZFT.js";
+import "./chunk-APVOACVT.js";
+import "./chunk-47SPMGOD.js";
 import "./chunk-WPALEIRX.js";
 import "./chunk-RKUAD3I6.js";
 export {

package/dist/hooks/stop-guard.js

@@ -19,20 +19,20 @@ import {
   run_hold,
   run_invocation,
   run_watcher_guard
-} from "./chunk-WWTMHHZU.js";
+} from "./chunk-IM3KM25Y.js";
 import {
   session_language
 } from "./chunk-6V5OPIUU.js";
 import {
   hook_decision,
   lane_child_marker
-} from "./chunk-KQG4776P.js";
+} from "./chunk-APVOACVT.js";
 import {
   PROJECT_ROOT,
   stamp_file,
   time_density_hook,
   time_hook_transcript
-} from "./chunk-ZPLXLJ7O.js";
+} from "./chunk-47SPMGOD.js";
 import "./chunk-WPALEIRX.js";
 import "./chunk-RKUAD3I6.js";
 
@@ -1161,7 +1161,7 @@ function build_citation_reason(references) {
   const command = `pnpm josh issue:cite ${issue_citation.cite_arguments(references).join(" ")}`;
   return `\u26D4 issue citation: your reply names an Issue as a bare \`#N\` (${numbers}). Run \`${command}\` to print the paste-ready citation lines, then print the corrected citation lines alone \u2014 do not repeat your previous reply. ${ISSUE_CITATION_REASON}`;
 }
-var FILING_OFFER_REASON = '\u26D4 filing offer: your reply offers to file an Issue instead of filing it. Filing into a first-party repository is Tier A \u2014 the trigger is the judgement that it is worth filing, not the run\'s progress (`.claude/skills/workflow-commands/SKILL.md` \u2192 \xA72i, `observation-filing.md`). Run `pnpm josh issue:scout "<title>"`, file it, run `pnpm josh epic:bundle <new>`, then end with the one-line citation of what was filed \u2014 do not repeat your previous reply. If it is not worth filing after all, say so in one line instead.';
+var FILING_OFFER_REASON = '\u26D4 filing offer: your reply offers to file an Issue instead of filing it. Filing into a first-party repository is Tier A \u2014 the trigger is the judgement that it is worth filing, not the run\'s progress (`.claude/skills/workflow-commands/SKILL.md` \u2192 \xA72i, `observation-filing.md`). Run `pnpm josh issue:file "<title>" --body-file <path> --depth <0|1|2>` \u2014 it scouts, lints, labels and runs `epic:bundle` itself \u2014 then end with the one-line citation of what was filed; do not repeat your previous reply. If it is not worth filing after all, say so in one line instead.';
 var HEADLESS_WAIT_MARKER = "\u26D4 headless parent:";
 var HEADLESS_REFUSAL_CAP = 3;
 var HEADLESS_WAIT_CALLS = ['"command":"pnpm josh lane:await', '"command":"pnpm josh run:progress'];

package/dist/josh.js

@@ -447,6 +447,16 @@ var ISSUE_COMMANDS = {
     description: "Post one comment to an issue from a file, so no shell expands the body",
     category: "AI tools",
     reference: ["<issue> --body <text> | --body-file <path>", "automation", ["network"]]
+  },
+  "issue:file": {
+    script: "scripts/issue/issue-file-cli.ts",
+    description: "File an Issue with every filing step: lint, Origin, duplicate scout, labels, then epic:bundle",
+    category: "AI tools",
+    reference: [
+      "<title> --body-file <path> --depth <0|1|2> [--route <route>] [--label <name>] [--repo <owner/repo>] [--distinct <N,\u2026>]",
+      "automation",
+      ["network"]
+    ]
   }
 };
 
@@ -1225,7 +1235,11 @@ var PROJECT_COMMANDS = {
     script: "scripts/propagate/propagate.ts",
     description: "Carry the published release into every consumer repository next to this one",
     category: "Project",
-    reference: ["[--dry-run] [--skip-publish-wait]", "maintainer", ["files", "network"]]
+    reference: [
+      "[--dry-run] [--skip-publish-wait] [--target <repo>]",
+      "maintainer",
+      ["files", "network"]
+    ]
   },
   adopt: {
     script: "scripts/adopt/adopt.ts",
@@ -1472,6 +1486,7 @@ var ALIASES = {
   ird: "issue:read",
   ist: "issue:state",
   isc: "issue:scout",
+  ifl: "issue:file",
   isf: "issue:fold",
   isfe: "issue:fold-existing",
   dfr: "defect:rate",

package/package.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.972.0",
+  "version": "1.983.0",
   "name": "@joshuafolkken/kit",
   "description": "Development toolkit for AI-assisted projects: formatting, AI assistant rules and a Git/GitHub Issue workflow for any repository, plus lint, type check, tests and hooks for Node projects",
   "keywords": [
@@ -193,7 +193,7 @@
     "@stylistic/eslint-plugin": "^5.10.0",
     "@types/node": "^26.6.3",
     "@types/semver": "^7.8.0",
-    "cspell": "^10.3.5",
+    "cspell": "^10.3.6",
     "esbuild": "^0.28.2",
     "eslint": "^10.11.0",
     "eslint-config-prettier": "^10.1.8",

package/prompts/collaboration-workflow/epic-bundle.md

@@ -12,18 +12,18 @@
 
 **Issue を新規に起票した直後**に、既存の open Issue を調べる。`kickoff` / `fullrun` / `halfrun` が起票したとき、および実装中に Tier A で起票したとき（`backlogrun` 実行中を含む）。
 
-`pnpm josh epic:bundle <N>`（エイリアス `eb`）が候補を探して推奨を表示する。**このコマンドは何も書き込まない** — 候補を出すのが機械、束ねるかを決めるのは AI である。
+`pnpm josh epic:bundle <N>`（エイリアス `eb`）が候補を探して推奨を表示する。起票は `pnpm josh issue:file` で行い、このコマンドが最終段として `epic:bundle` を実行して答えを表示するので、別に呼ぶのは `⚠` で再実行を案内されたときだけである。**このコマンドは何も書き込まない** — 候補を出すのが機械、束ねるかを決めるのは AI である。
 
 ### 起票の「前」に答えるのは `issue:scout`
 
 `pnpm josh issue:scout "<title>"`（エイリアス `isc`）は、まだ存在しない Issue について同じ配属先の問いに答える（joshuafolkken/kit#1252）。**配属の判定は `epic:bundle` のものをそのまま呼んでおり、実装は 1 つしかない。** 加えて、`epic:bundle` が意図的に採らないシグナル — タイトルの語の重なりによる**重複候補** — を返す。既存 Issue の束ね直しに似た見出しが立つのは強シグナルだけで十分だからだが、「もう起票されていないか」は起票前にしか意味を持たない別の問いであり、しきい値を混ぜていない。
 
-**両方を実行する。順番が違うだけである。**
+**両方を実行する。順番が違うだけである。** どちらも `pnpm josh issue:file` が 1 回の呼び出しの中で実行する。
 
-| いつ                       | コマンド                | 何について答えるか                                 |
-| -------------------------- | ----------------------- | -------------------------------------------------- |
-| `gh api … issues` の**前** | `issue:scout "<title>"` | まだ番号を持たない下書き。タイトルと要約だけがある |
-| 起票の**直後**             | `epic:bundle <N>`       | 実在する Issue。番号と、それに記録された関係がある |
+| いつ           | コマンド                | 何について答えるか                                 |
+| -------------- | ----------------------- | -------------------------------------------------- |
+| 起票の**前**   | `issue:scout "<title>"` | まだ番号を持たない下書き。タイトルと本文がある     |
+| 起票の**直後** | `epic:bundle <N>`       | 実在する Issue。番号と、それに記録された関係がある |
 
 手順上の位置づけと、重複候補が見つかったときに起票せず止まる規則は `.claude/skills/workflow-commands/SKILL.md` → §2e が単一ソースである。
 
@@ -41,8 +41,8 @@
 
 **これは「レビューを CI と並走させる」ではない。**（ここで言うレビューは 1 周目のことであり、2 周目については下の段落で別に扱う。） joshuafolkken/kit#1216 の (b) は不採用と決定済みであり、却下の理由は規則ではなく仕組みである — あちらは**コードを変える作業**を CI と重ねるため、修正を push するたびに CI がやり直しになり、重ねた分をそのまま払い戻す。起票はコードを 1 行も変えないので、走っている CI がそのまま使える。**1 周目のレビュー**はコミットの前のままで、「コミット前セルフレビュー」は書き換えていない。**2 周目だけは CI と並走する**（joshuafolkken/kit#1261）— 同じ仕組みを逆から読んだ結果であり、2 周目は fix delta しか読まず、通常はコードを 1 行も変えない。変えた場合は同一ブランチへの追加コミット 1 つと CI のやり直し 1 回を払う。単一ソースは `.claude/skills/workflow-commands/chain-rule.md` → "The pull request opens between the rounds, so CI runs beside round 2"。
 
-1. 残指摘を後追い Issue として起票し、現在の Issue を参照する
-2. **現在の Issue が閉じる前に** `pnpm josh epic:bundle <新規>` を実行する。候補探索は open Issue しか読まないため、親が閉じた後では恒久的に `none` になる（joshuafolkken/kit#947）
+1. 残指摘を後追い Issue として起票し、現在の Issue を参照する。起票は `pnpm josh issue:file "<title>" --body-file <本文ファイル> --depth <n> --route review-cap` で行う
+2. **現在の Issue が閉じる前に**起票する。`issue:file` が新規 Issue について `epic:bundle` を実行する。候補探索は open Issue しか読まないため、親が閉じた後では恒久的に `none` になる（joshuafolkken/kit#947）
 3. 答えに従う。**`epic:bundle` は推奨するだけで何も書き込まない**ので、「実行する」とは書き込みコマンドを自分で打つことである。**epic 本文の手編集は禁止** — タスクリストと `blocked-by` が食い違い、`epic:next` が `error` を返す
 
    | 答え                                                                                                                                                                                                                                                                                                                                                                                                                                                                               | すること                                                                                                                                                                                                                                            | Tier             |

package/prompts/collaboration-workflow/issue-template.md

@@ -71,14 +71,14 @@ Issue には次の要素を必ず含める。
 
 - **起票前に不具合かどうかを必ず選ぶ。** `## 背景` の直下に、不具合なら `- 種別: 不具合`、非不具合なら `- 種別: 非不具合` を置く。両方の併記も省略も `pnpm josh issue:lint` が拒否する。故障を述べる本文でも単語から自動判定せず、起票者が判断する。振る舞い変更、機能改善、互換性の宣言はこの判断と併記できる
 - **不具合修正の Issue は `- 種別: 不具合` を宣言する。** この宣言がある Issue では、`pnpm josh git -y` が追加・変更したテストを修正前のツリー（merge-base）に当てて `pnpm josh test:red` で実行し、1 本も赤にならない（`green`）ときはコミットを拒否する。修正前でも緑の回帰テストは、報告された症状を再現していないためである（joshuafolkken/kit#2448）。回帰テストは、利用者が症状を見たのと同じ粒度で書く
-- **起票時の `bug` ラベルは本文の宣言から決める。** `pnpm josh issue:lint <本文ファイル>` の後、同じファイルを `gh api …/issues -F body=@<本文ファイル>` で送る。`labels:` に `bug` が含まれたら `-f 'labels[]=bug'` を同じ作成呼び出しに追加する。`depth`・`route` は併記する。`bugfix` は PR のリリース分類であり、Issue の `bug` の代わりにしない
-- **機能追加・機能改善は目的を本文で宣言する。** `## 背景` の直下に `- 目的: 機能追加` または `- 目的: 機能改善` を書く。`pnpm josh issue:lint <本文ファイル>` が `labels: enhancement` を返したら、同じ作成呼び出しに `-f 'labels[]=enhancement'` を付ける。不具合修正、文書のみ、依存更新、保守作業はタイトルの単語から推測して宣言しない。目的が曖昧なら起票文案の期待結果と受け入れ条件を具体化してから分類する
-- **互換性を壊す変更は影響を本文で宣言する。** 既存の利用者、API、設定の契約を変える場合は、`## 背景` の直下に `- 互換性: 破壊的変更` を書き、廃止対象と影響を説明する。移行措置や事前案内があっても破壊的変更なら宣言する。`pnpm josh issue:lint <本文ファイル>` が `labels: breaking-change` を返したら、同じ作成呼び出しに `-f 'labels[]=breaking-change'` を付ける。互換性を保つ変更には付けない。影響が曖昧なら起票文案で対象の利用者と契約を明確にしてから分類する
-- **`issue:lint` が返す分類ラベルをすべて起票時に指定する。** `bug`、`enhancement`、`breaking-change` は組み合わせて表示されることがある。`depth`・`route` など既存のラベルを残し、`labels: none` のときは分類ラベルを付けない。Issue が `enhancement` と `breaking-change` の両方を持つとき、PR のリリース分類は `breaking-change` 一つにする。Issue の目的の分類と PR のリリース分類を区別する
+- **起票時の `bug` ラベルは本文の宣言から決める。** 起票は `pnpm josh issue:file "<title>" --body-file <本文ファイル> --depth <n>` で行い、このコマンドが `issue:lint` と同じ検査をしたうえで、`- 種別: 不具合` の宣言があれば `bug` ラベルを同じ作成リクエストに付ける。`depth`・`route` も同じ呼び出しで付く。`bugfix` は PR のリリース分類であり、Issue の `bug` の代わりにしない
+- **機能追加・機能改善は目的を本文で宣言する。** `## 背景` の直下に `- 目的: 機能追加` または `- 目的: 機能改善` を書く。この宣言があれば `pnpm josh issue:file` が `enhancement` ラベルを同じ作成リクエストに付ける。不具合修正、文書のみ、依存更新、保守作業はタイトルの単語から推測して宣言しない。目的が曖昧なら起票文案の期待結果と受け入れ条件を具体化してから分類する
+- **互換性を壊す変更は影響を本文で宣言する。** 既存の利用者、API、設定の契約を変える場合は、`## 背景` の直下に `- 互換性: 破壊的変更` を書き、廃止対象と影響を説明する。移行措置や事前案内があっても破壊的変更なら宣言する。この宣言があれば `pnpm josh issue:file` が `breaking-change` ラベルを同じ作成リクエストに付ける。互換性を保つ変更には付けない。影響が曖昧なら起票文案で対象の利用者と契約を明確にしてから分類する
+- **本文が宣言する分類ラベルは `pnpm josh issue:file` がすべて起票時に付ける。** `bug`、`enhancement`、`breaking-change` は組み合わせて付くことがある。`depth`・`route` などのラベルと併せて 1 回の作成リクエストで付け、宣言が無いとき（`issue:lint` の `labels: none`）は分類ラベルを付けない。Issue が `enhancement` と `breaking-change` の両方を持つとき、PR のリリース分類は `breaking-change` 一つにする。Issue の目的の分類と PR のリリース分類を区別する
 - **`## 発火点`** には、その規則が破れる瞬間に最初に呼ばれるツールコール名を 1 つ書く。名前は `prompts/collaboration-workflow/rule-delivery.md` の配送表に載る、フックで配送可能なツール（`Bash` / `Edit` / `Read` / `Write` / `AskUserQuestion`）と突き合わせる。**表に無い名前**（そもそもツールコール名でない）と**不一致**（既知のツールだが配送できない）は区別して印字され、joshuafolkken/kit#2201 の「規則は正しいが名指ししたコールが実際に破れるコールの 1 つ後ろ」を起票時に検出する
 - **`## ベースライン`** は **「コマンド + 値」** で書く。``- `<測定コマンド>` → <現在の値>`` の形に限り、自然文だけの測定説明は受け付けない（再実行できないため）。マージ後に `pnpm josh measure:rerun` が同じコマンドをやり直し、**before / after の対**を印字する。値が動かなかったとき、反証された前提として `docs/maintainers/observations.md` に 1 行追記される（既存の append-only 台帳を使い、別の台帳は作らない）
 - **`## 再現`** は **「コマンド + 実際の出力」** で書く。コマンドを backtick、出力をフェンス（``` または ~~~）で囲む。自然文の「確認した」は再実行できないため受け付けない（`## ベースライン` と同じ理由）。読みだけの起票を起票時に弾くためである
-- **検査は `pnpm josh issue:lint <path>` が行う。** 対象判定・3 見出しの有無・発火点の配送可否・ベースラインが「コマンド + 値」か・再現が「コマンド + 実際の出力」かと、起票時に必要な分類ラベルを、起票前の本文ファイルからまとめて答える（未リントの起票は `pnpm josh rule:guard` が拒否する）
+- **検査は `pnpm josh issue:lint <path>` が行う。** 対象判定・3 見出しの有無・発火点の配送可否・ベースラインが「コマンド + 値」か・再現が「コマンド + 実際の出力」かと、起票時に必要な分類ラベルを、起票前の本文ファイルからまとめて答える（`pnpm josh issue:file` は起票前に同じ検査を行い、問題があれば起票しない）
 
 ### 起票元へのバックリンク（`## Origin` / `## Upstream issues`）