@joshuafolkken/kit 1.1455.0 → 1.1514.0

package/.claude/skills/workflow-commands/issue-comments.md

@@ -1,99 +1,82 @@
 # An Issue's comments are part of the Issue
 
-**The single source of the comment read**, read at its point of use — before implementing a `#N`
-Issue. Rationale and history: `docs/maintainers/issue-comments-rationale.md` → "Why comments are read".
+Read before implementing a `#N` Issue.
 
 **Every `#N` entry point reads the Issue's comments before it implements** — `fullrun`, `halfrun` and
-`kickoff`; a `backlogrun` named issue and epic child inherit it through `fullrun`'s procedure. The read
-is one call, made in the same turn as whatever else the run already needs:
+`kickoff`; a `backlogrun` named issue and epic child inherit it through `fullrun`. One call, in the same
+turn as whatever else the run needs:
 
 ```bash
 pnpm josh issue:read <N> [<N> ...]     # body and comments, one call per batch
 gh api repos/{owner}/{repo}/issues/<N>/comments --jq '.[] | {user: .user.login, created_at, body}'
 ```
 
-**The first line is the one to type**; `pnpm josh issue:read` answers the body and the comments for
-every number named, in one call, and **says when a comment listing could not be read rather than
-showing no comments**. The `gh api` form stays for a **cross-repository** read: the command takes no
-`--repo`. Never `gh issue view <N> --comments` — it is GraphQL-backed and a cloud session is answered
-`403`.
+**Type the first line**; it **says when a comment listing could not be read rather than showing no
+comments**. The `gh api` form is for a **cross-repository** read (the command takes no `--repo`). Never
+`gh issue view <N> --comments` — GraphQL-backed, `403` in a cloud session.
 
 **This repository writes its agreements into comments and then reads only bodies.** **What the
-reading is for**, so it is not skimmed: the boundary of the scope — work a comment moved to
-another Issue, or added to this one; the record of an auto-decision already made; a split or epic
-agreement reached after filing; a recorded stash or an in-flight branch; and a **correction of the
+reading is for**: the scope boundary — work a comment moved elsewhere or added here; an auto-decision
+already made; a split or epic agreement; a recorded stash or in-flight branch; a **correction of the
 body's own diagnosis**.
 
 ## When a comment contradicts the body
 
-**The later text is the agreement in force.** A body is written first and is not rewritten when a
-decision arrives, so of a body and a comment that disagree the comment is the newer of the two and
-wins. **This is settled by ordering, never by judging which reads better.** Name in the two-layer work
-summary which comment superseded what.
+**The later text is the agreement in force** — the comment is the newer, so it wins. **This is settled
+by ordering, never by judging which reads better.** Name in the work summary which comment superseded
+what.
 
 **Two answers are not the run's to make, and each is decided from what the comment says:**
 
-- **A comment that reassigns part of the scope to another Issue** takes that part out of scope: do not
-  implement it, whatever acceptance criteria the body still lists, and name the Issue it went to in the
-  completion report.
+- **A comment that reassigns part of the scope to another Issue** takes that part out of scope, whatever
+  the body's criteria say; name the Issue it went to in the completion report.
 - **A comment saying the Issue no longer has a reason to exist** — the defect does not reproduce, or it
-  was fixed elsewhere — takes the exit in the next subsection, "When the work turns out to be already
-  merged". Closing an Issue is Tier C.
+  was fixed elsewhere — takes the exit in "When the work turns out to be already merged". Closing an
+  Issue is Tier C.
 
-Everything else is the ordinary work of the run, **a widened scope included**: a widening large enough
-to be several separately-mergeable deliverables is the split assessment's business
-(`split-assessment.md`), not a second kind of stop.
+Everything else, **a widened scope included**, is ordinary work; a widening into several
+separately-mergeable deliverables is the split assessment's business (`split-assessment.md`).
 
 ## When the work turns out to be already merged
 
-**A run can learn its Issue is already done in two ways, and both end here.** A **comment** says so —
-the bullet above — or the **run itself verifies it**, by reading the merged code and finding every
-acceptance criterion already satisfied. What is left to do afterwards is identical, so there is one
-procedure and not two. **Parking it is not the place**: `needs-decision` means "waiting for an answer
-nobody has given", and here the answer exists.
+**A comment says so, or the run itself verifies it** by finding every acceptance criterion already
+satisfied in merged code — one procedure either way. **Parking it is not the place**: `needs-decision`
+means "waiting for an answer", and here the answer exists.
 
-**The exit is the `already-done` label.** It is `needs-decision`'s counterpart: `epic:next`,
-`backlog:next` and `auto-ok:next` all stop offering the Issue (`scripts/issue/issue-labels.ts` →
-`NOT_DIRECTLY_RUNNABLE_LABELS`, `epic-classify.ts` → `human`), and `epic:busy` stops counting it as
-holding a lane. **Only a person removes it, by closing the Issue.**
+**The exit is the `already-done` label.** `epic:next`, `backlog:next` and `auto-ok:next` stop offering
+the Issue (`scripts/issue/issue-labels.ts` → `NOT_DIRECTLY_RUNNABLE_LABELS`, `epic-classify.ts` →
+`human`), and `epic:busy` stops counting it. **Only a person removes it, by closing the Issue.**
 
 ```bash
 gh api repos/{owner}/{repo}/labels -f name=already-done -f color=6f42c1 -f description="Verified already merged — a person closes it" --silent 2>/dev/null || true
 gh api repos/{owner}/{repo}/issues/<N>/labels -f 'labels[]=already-done'
 ```
 
-The procedure, in order:
-
-1. **Record the evidence as an Issue comment, before the label.** Name the pull request or commit that
-   merged the work and, for each acceptance criterion the Issue states, the file and lines that satisfy
-   it. **A claim with no citations is not the finding this exit is for.**
+1. **Record the evidence as an Issue comment, before the label**: the merging pull request or commit
+   and, per acceptance criterion, the file and lines that satisfy it. **A claim with no citations is not
+   the finding this exit is for.**
 2. **Apply `already-done`** — the two commands above.
-3. **Commit nothing, push nothing, open no pull request.** The tree is clean, so release the hold with
-   `pnpm josh run:release <N>`, which also removes `in-progress` — left on, it holds a lane against an
-   Issue nothing will ever run.
-4. **Then behave as the entry point does for a parked child.** A `fullrun` / `halfrun` a person typed
-   sends a `confirmation` Telegram naming the Issue and the merge that already covers it, and stops. An
-   `backlogrun` child is park-and-continue (`backlogrun-park.md` → "park and continue").
-5. **Never close the Issue.** That is Tier C at every entry point, and the label leaves the close one
-   click away for the person who owns it.
-
-**Nothing about this is a license to skip the work when it merely looks familiar.** The bar is step 1's
-citations: a criterion you cannot point at merged code for is a criterion this run still owes.
+3. **Commit nothing, push nothing, open no pull request.** Release the hold with
+   `pnpm josh run:release <N>`, which also removes `in-progress`.
+4. **Then behave as the entry point does for a parked child.** A typed `fullrun` / `halfrun` sends a
+   `confirmation` Telegram naming the Issue and the covering merge, and stops; a `backlogrun` child is
+   park-and-continue (`backlogrun-park.md` → "park and continue").
+5. **Never close the Issue** — Tier C at every entry point.
+
+**Looking familiar is no license to skip the work**: a criterion you cannot point at merged code for is
+one this run still owes.
 
 ## A long thread
 
-**The fetch is one call however long the thread is; what costs is carrying it afterwards** — which is
-why the call above projects each comment down to its author, its timestamp and its body. Once the
-thread runs longer than the Issue itself it is exactly the pre-implementation reading `delegation.md` describes:
-brief a delegated unit to return **the agreements in force plus the comment URLs that carry them**,
-never the comment text.
+**The fetch is one call; what costs is carrying it** — hence the projection to author, timestamp and
+body. A thread longer than the Issue is the pre-implementation reading `delegation.md` describes: brief
+a unit to return **the agreements in force plus the comment URLs that carry them**, never the text.
 
-**`pnpm josh rule:guard` refuses the body-only read** and hands over the reissue and the conflict rule
-at the moment they bind (`prompts/collaboration-workflow/rule-delivery.md`). **This file is the rule,
-not the hook** — a session that runs no hooks still owes the read.
+**Under Claude Code the hook prepends the comments to a line that opens with a body-only `gh api` read
+and refuses every other body-only read; the Codex adapter refuses them all** (`prompts/collaboration-workflow/rule-delivery.md`).
+**This file is the rule, not the hook** — a session without hooks still owes the read.
 
 ## A person's update mid-run
 
-When the hook, `review:attest --check` or `followup` shows an Issue update, read it as above — the
-later text is in force — fix what it changes, then `pnpm josh issue:ack <N>`. The watch and what it
-does not catch: `docs/josh-commands-backlog.md` → "`josh issue:ack`".
+When the hook, `review:attest --check` or `followup` shows an Issue update, read it as above, fix what it
+changes, then `pnpm josh issue:ack <N>`. The watch: `docs/josh-commands-backlog.md` → "`josh issue:ack`".

package/.claude/skills/workflow-commands/issue-scout.md

@@ -28,8 +28,9 @@ pnpm josh issue:file "<title>" --body-file <complete-draft.md> --depth <n> --dis
   `add_to_epic` / `create_epic` Tier A and `ask` a stop, in exactly the reading `into-target.md`'s
   `into <target>` suffix would have given by hand. Where the user typed `into <target>`, that naming wins.
 - **`Epic: not asked` is not `Epic: none`.** The epic half decides from the issue numbers the body
-  names. **Cite `#N` in the body whenever the work follows an existing Issue** — one line is enough,
-  and naming the epic itself (`part of epic #<E>`) is answered with that epic.
+  names in its acceptance criteria or its `parent: #N` line; a background mention does not count.
+  **Cite `#N` there whenever the work follows an existing Issue** — one line is enough, and naming
+  the epic itself (`parent: #<E>`) is answered with that epic.
 - **`epic:bundle` then runs on the new Issue, in the same call.** Act on its printed answer; a `⚠`
   means rerun `pnpm josh epic:bundle <N>` — the Issue exists, so never refile; a placing answer
   reads the `epic-commands` skill.

package/.claude/skills/workflow-commands/kickoff.md

@@ -1,92 +1,83 @@
 # `kickoff` — Planning phase only (plan → Issue → Telegram notify → stop)
 
 - `kickoff #<N>`: **First `pnpm josh run:entry <N> --to kickoff`** (`docs/how-to/run-issues.md`) — it claims
-  nothing and prints the stage line alone; `start: reached` means the Issue is already planned or further
-  up the ladder, so report the stage line and **stop**. Otherwise read existing Issue #N **and every comment on it** — `pnpm josh issue:read <N>`; a
-  decision recorded after the body was written lives only in a comment, and the later text is the
-  agreement in force (`issue-comments.md`, which also carries the two answers that stop the run instead) →
-  **normalize the title**: if the title is not in English or can be phrased more clearly, derive a
-  better English title and run `gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f title="<title>"` →
-  analyze requirements → **scope assessment per `split-assessment.md`** → post the plan to the Issue (if
-  body is blank, `gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f body="<plan>"`; otherwise
-  `pnpm josh issue:comment <N> --body-file <path>`) → **apply the `run:planned` label** — the mark the next
-  command's `run:entry` reads to start at the implementation, provisioned by `josh sync` (`gh api
-  repos/{owner}/{repo}/issues/<N>/labels -f 'labels[]=run:planned' --silent`) → send Telegram
-  notification, its last line `Next: halfrun #<N> | prrun #<N> | fullrun #<N>` → **stop**
-  (do not implement). **When the assessment finds two or more separately-mergeable deliverables**, take
-  the split path instead of posting a plan: create the children as in `kickoff new`, then either
-  **promote `#N`** with `pnpm josh epic --promote <N> <N1> <N2> ... [--ordered] [--rationale-file
-  <path|->]` — the right choice when `#N` is a request, a discussion or a container — or, when `#N` is
-  itself one of the deliverables, keep `#N` as a child and create a new epic with `pnpm josh epic`. That
-  branch is Tier A: choose it and record the reasoning on the Issue without asking. Present `backlogrun #<E> --only` and stop. Plan comments are written in the session language (`JOSH_SESSION_LANG`, default `ja`).
-  Telegram notification: `pnpm josh notify --task-type planning --issue-url "<issue-url>" --body=$'-
-  <bullet1>\n- <bullet2>\n...'`. `--task-type` controls the header icon (`planning` 📋 / `completion` ✅
-  / `failure` ❌ / `kickoff_retry` 🔄 / `confirmation` ⏸️). `--repo-name` and `--issue-title` are
-  auto-fetched from `gh` when not supplied. The Issue URL must be included.
+  nothing and prints the stage line alone; on `start: reached` report the stage line and **stop**. Then:
+  1. Read Issue #N **and every comment on it** — `pnpm josh issue:read <N>`; the later text is the
+     agreement in force (`issue-comments.md`, which also carries the answers that stop the run).
+  2. **Normalize the title** to clear English: `gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f title="<title>"`.
+  3. Analyze requirements → **scope assessment per `split-assessment.md`**.
+  4. Post the plan — a blank body takes `gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f body="<plan>"`,
+     otherwise `pnpm josh issue:comment <N> --body-file <path>` — in the session language
+     (`JOSH_SESSION_LANG`, default `ja`).
+  5. **Apply the `run:planned` label** — the next command's `run:entry` starts at the implementation
+     (`gh api repos/{owner}/{repo}/issues/<N>/labels -f 'labels[]=run:planned' --silent`).
+  6. Send the Telegram notification, its last line `Next: halfrun #<N> | prrun #<N> | fullrun #<N>` →
+     **stop** (do not implement).
+
+  **Two or more separately-mergeable deliverables** take the split path instead of a plan: create the
+  children as in `kickoff new`, then either **promote `#N`** with `pnpm josh epic --promote <N> <N1> <N2>
+  ... [--ordered] [--rationale-file <path|->]` (when `#N` is a request, a discussion or a container), or
+  keep `#N` as a child and create a new epic with `pnpm josh epic`. That branch is Tier A: choose and
+  record the reasoning on the Issue. Present `backlogrun #<E> --only` and stop.
+
+  Telegram: `pnpm josh notify --task-type planning --issue-url "<issue-url>" --body=$'-
+  <bullet1>\n- <bullet2>\n...'`. `--task-type` sets the icon (`planning` 📋 / `completion` ✅ /
+  `failure` ❌ / `kickoff_retry` 🔄 / `confirmation` ⏸️); `--repo-name` and `--issue-title` are
+  auto-fetched. The Issue URL must be included.
 
 **`kickoff` does not claim the working-tree hold, and does not release one** — it touches GitHub, never
-the tree. `working-tree-hold.md` is the single source.
+the tree (`working-tree-hold.md`).
 
 **The target repository is named in front of the Issue reference** — `kickoff kit#new`,
-`kickoff joshuafolkken/kit#<N>`. The definition is `target-repository.md`. `kickoff` is the entry that needs
-no checkout: name the target repository in the path of every `gh api` call — reads included — and never
-clone. The one exception is the split path's epic, since `pnpm josh epic` writes only the repository it
-runs in — and the promote arm has no remote fallback at all, so it stops when that repository is not
-checked out here. A target whose owner is not this session's is third-party: Tier C, so it stops rather
-than filing.
+`kickoff joshuafolkken/kit#<N>` (`target-repository.md`). `kickoff` needs no checkout: name the target in
+every `gh api` path, reads included, and never clone. The exception is the split path's epic — `pnpm josh
+epic` writes only the repository it runs in, and the promote arm stops when that repository is not
+checked out here. A third-party owner is Tier C: stop rather than file.
 
 **Read `split-assessment.md` → "The question" first** — `kickoff #N` assesses scope exactly as
-`kickoff new` does. Its default is not to split: separability and a scope that clearly exceeds what one
-verification gate can confirm in one pass have to hold **together**. The rest of `split-assessment.md`
-is read on demand when a split is found.
+`kickoff new` does. The default is not to split: separability and a scope clearly over one verification
+gate must hold **together**. The rest of `split-assessment.md` is read when a split is found.
+
+- `kickoff new` or `kickoff new "<title>"`: (0) **Scope assessment** per `split-assessment.md` — one
+  deliverable takes the **single-issue path**, several the **multi-issue split path**.
+  - **Single-issue path**: (1) Derive an English title, or use the one given. (2) `pnpm josh issue:file
+    "<title>" --body-file <body-file> --depth <n>` plus the labels the words typed after `new` name
+    ("Words typed after `new`", below; body per `prompts/collaboration-workflow/issue-template.md`) —
+    its duplicate scan runs first, and a candidate covering the same work stops the run (`SKILL.md` →
+    `issue-scout.md`). Capture `<N>`. (3) Post the plan as `kickoff #<N>` does. (4) Telegram. (5)
+    **Stop**.
+  - **Multi-issue split path**: (1) Per deliverable, `pnpm josh issue:file "<sub-title>" --body-file
+    <body-file> --depth <n> --route split` plus the labels the words after `new` name (duplicate scan
+    per `issue-scout.md`). A split filed into another repository gives every child body the `## Origin`
+    backlink, the epic the same link as prose (never a checkbox row, which disables its auto-close), and
+    the originating Issue lists children and epic under `## Upstream issues`. (2) **Epic — always, for
+    every split into two or more Issues**: `pnpm josh epic "<epic-title>" <N1> <N2> ... [--ordered]
+    [--rationale-file <path|->] [--origin <owner/repo#N>]`, capturing `<E>`. It builds the `epic` label,
+    the task-list rows (`- [ ] #N`), the machine-readable `Dependencies` and the `backlogrun` line; check
+    a hand-edited epic with `pnpm josh epic:check <E>`. (3) Telegram listing every created Issue. (4)
+    Present `backlogrun #<E> --only`. (5) **Stop**.
+
+  **The epic itself is never implemented** — `backlogrun` runs its *children*, and `pnpm josh followup`
+  closes it once every child is closed. Children with no required order take `None — the children are
+  independent; any execution order works.` under `Dependencies`. **Only when the execution order
+  matters** (`execution-waves.md` → "When a wave may be declared") pass `--ordered`, which treats the
+  argument order as the dependency order.
 
-- `kickoff new` or `kickoff new "<title>"`: No Issue exists yet. Steps: (0) **Scope assessment** per
-  `split-assessment.md`. If multiple → the **multi-issue split path**; if single → the **single-issue
-  path**. **Single-issue path**: (1) Derive an English title from the conversation, or use the provided
-  title. (2) Create Issue: `pnpm josh issue:file "<title>" --body-file <body-file> --depth <n>` plus the labels the words typed after `new` name ("Words typed after `new`", below) (body
-  per `prompts/collaboration-workflow/issue-template.md`) — its duplicate scan runs first, and a
-  candidate that covers the same work stops the run rather than filing a second Issue (`SKILL.md` →
-  `issue-scout.md`). Capture `<N>`. (3)
-  Post the plan in the session language, using the same body/comment logic as `kickoff #<N>`. (4) Send
-  Telegram notification. (5) **Stop** — do not implement. **Multi-issue split path**: (1) For each
-  independent deliverable, derive a focused English title and create a separate Issue with the
-  `route:split` label (its duplicate scan is read per `issue-scout.md`): `pnpm josh issue:file
-  "<sub-title>" --body-file <body-file> --depth <n> --route split` plus the labels the words typed after `new` name. Capture each Issue number. **When the split is filed into a repository other than
-  the one this session is running in**, every child body gets the `## Origin` backlink described in the
-  cross-package rule the AI documents keep resident, the epic body carries the same link as prose or a
-  plain bullet (never as a checkbox row, which would disable its auto-close), and the originating Issue
-  lists the children and the epic under `## Upstream issues`. (2) **Epic — always, for every split into
-  two or more Issues.** There is no count or ordering condition. **Create it with `pnpm josh epic
-  "<epic-title>" <N1> <N2> ... [--ordered] [--rationale-file <path|->] [--origin <owner/repo#N>]`**,
-  capturing its number `<E>` from the printed URL. The command satisfies the epic's four mechanical
-  requirements by construction — the `epic` label, the task-list rows (`- [ ] #N`), the machine-readable
-  `Dependencies`, and the printed `backlogrun` line. Check an epic you wrote or edited by hand with `pnpm
-  josh epic:check <E>`. Only where `josh` is unavailable, fall back to the manual procedure: ensure the
-  label exists (`gh api repos/{owner}/{repo}/labels -f name=epic -f color=5319e7 -f description="Tracks
-  a batch of child issues from one split" --silent 2>/dev/null || true`), then create the epic with `gh
-  api repos/{owner}/{repo}/issues -f title="<epic-title>" -f 'labels[]=epic' -F body=@<body-file>`. Its body
-  follows the epic format in `prompts/collaboration-workflow/issue-template.md` — split rationale,
-  dependencies, the `backlogrun` command, and a child task list in task-list syntax (`- [ ] #N`). The epic
-  exists as the **non-closing home for the split rationale**. When the children have no required order,
-  write `None — the children are independent; any execution order works.` under `Dependencies`. **The
-  epic itself is never implemented** — a `backlogrun` takes a named epic and runs its *children*. `pnpm josh
-  followup` closes it automatically once every child is closed. **Only when the execution order
-  matters** — the criterion is `execution-waves.md` → "When a wave may be declared" — record it natively: `pnpm josh epic --ordered` treats the argument order as the dependency
-  order; on the manual fallback path, after the child Issues exist, `gh api
-  repos/{owner}/{repo}/issues/<N2>/dependencies/blocked_by -F issue_id="$(gh api
-  repos/{owner}/{repo}/issues/<N1> --jq .id)"` for each dependent pair (the endpoint takes the blocker's
-  **database id**, not its issue number; a failure here is non-fatal). Never fold the relation into the
-  creation call. (3) Send Telegram notification listing all created issues. (4) Present the command
-  `backlogrun #<E> --only`. (5) **Stop** — do not implement.
+  **Only where `josh` is unavailable**, the manual fallback: `gh api repos/{owner}/{repo}/labels -f
+  name=epic -f color=5319e7 -f description="Tracks a batch of child issues from one split" --silent
+  2>/dev/null || true`, then `gh api repos/{owner}/{repo}/issues -f title="<epic-title>" -f
+  'labels[]=epic' -F body=@<body-file>` with the epic format of `issue-template.md`; an order is
+  recorded per pair with `gh api repos/{owner}/{repo}/issues/<N2>/dependencies/blocked_by -F
+  issue_id="$(gh api repos/{owner}/{repo}/issues/<N1> --jq .id)"` (the blocker's **database id**; a
+  failure is non-fatal), never folded into the creation call.
 
-`pnpm josh issue:file` lints the body and applies the classification labels it declares, following `prompts/collaboration-workflow/issue-template.md` for classification (`docs/josh-commands-backlog.md` → `josh issue:file`).
+`pnpm josh issue:file` lints the body and applies the classification labels it declares (`issue-template.md`; `docs/josh-commands-backlog.md` → `josh issue:file`).
 An Issue a consumer can use only once it is published is filed with `--release` (`kickoff new`), or linked with `pnpm josh issue:release <N>` (`kickoff #N`) — either makes it a blocker of the repository's `release` Issue, which never gets `auto-ok` on its own.
 
 ## Words typed after `new`
 
-**`auto-ok` is judged by `pnpm josh issue:file`, never typed** — by the same criteria as every
-filing: the excluded labels and the body's `- 人の判断:` declaration, and a `不要` declaration also needs a run label
-(`issue-template.md`).
+**`auto-ok` is judged by `pnpm josh issue:file`, never typed** — the excluded labels and the body's
+`- 人の判断:` declaration; a `不要` declaration also needs a run label (`issue-template.md`).
 `auto ok` typed after `new` adds nothing.
 
 **Words after `new`** (`kickoff new high`) are read like `into <target>`, never inferred. Each adds its

package/.claude/skills/workflow-commands/latest-gate.md

@@ -1,9 +1,7 @@
 # The dependency update — when `josh latest` runs
 
 `josh latest` updates every dependency, the published ranges, `pnpm audit` and pnpm, in that
-order and over the network. This file is the **single source** of when it runs; every entry point
-references it and none restates it. History: `docs/maintainers/latest-gate-rationale.md` → "Where
-each rule came from".
+order and over the network.
 
 ## Ask the command; do not decide
 
@@ -59,8 +57,6 @@ merge is CI**: the `Security Audit` job runs on every pull request and is one of
 
 **The lock file the update rewrites lands with whichever issue ran it.** `josh latest` leaves
 `pnpm-lock.yaml` modified and that issue's `pnpm josh git -y` commits it. Should the issue then fail
-CI on a bump rather than on its own change, fix it forward before parking the issue for it. Rationale
-for the elapsed-time window: `docs/maintainers/latest-gate-rationale.md` → "Why an elapsed-time
-window rather than once per batch".
+CI on a bump rather than on its own change, fix it forward before parking the issue for it.
 
 `docs/josh-commands-automation.md` documents the command itself.

package/.claude/skills/workflow-commands/needs-human-review.md

@@ -1,8 +1,6 @@
 # `needs-human-review` — the child that stops before its commit
 
-**The single source of the label**, read at its point of use — the moment `pnpm josh issue:state <N>`
-answers `human_review: yes`. Rationale and history: `docs/maintainers/needs-human-review-rationale.md`
-→ "Why the label exists".
+Read the moment `pnpm josh issue:state <N>` answers `human_review: yes`.
 
 An issue carrying **`needs-human-review`** is degraded to a `halfrun`-shaped stop, whichever entry
 point reached it — `fullrun` or `backlogrun` — and the label may be applied **only by a person**.
@@ -46,8 +44,7 @@ gh api repos/{owner}/{repo}/labels -f name=needs-human-review -f color=d93f0b -f
 **It is not `needs-decision`**: `needs-decision` withholds a run's *start*; this withholds its *end*.
 So a `needs-human-review` issue is still offered, and a child stopped by it **goes on holding its
 repository** — `scripts/issue/issue-labels.ts` keeps it out of `NOT_DIRECTLY_RUNNABLE_LABELS` and
-`scripts/epic/epic-busy.ts` keeps it out of the parked set (`docs/maintainers/needs-human-review-rationale.md`
-→ "Why it is not `needs-decision`").
+`scripts/epic/epic-busy.ts` keeps it out of the parked set.
 
 Each entry point's own branch stays in its own file — `fullrun.md`, `halfrun.md`,
 `backlogrun.md` — and routes here for the definition.