@joshuafolkken/kit 1.1453.0 → 1.1471.0

package/.claude/skills/epic-commands/execution-waves.md

@@ -1,19 +1,16 @@
 # Execution waves — parallel, then one alone, then the rest
 
-**Read this when an epic's children need an order between groups** — a wave boundary, or one child
-that must run alone. It is a reference of the `epic-commands` skill (`SKILL.md`), which carries the
-commands themselves; the dependency declaration this file builds on is `SKILL.md` → "`josh epic:next
-<E…>` — what is runnable".
+Read this when an epic's children need an order between groups — a wave boundary, or one child that
+must run alone. It builds on `SKILL.md` → "`josh epic:next <E…>` — what is runnable". Reasons:
+`docs/maintainers/epic-commands-rationale.md` → "Execution waves — why a wave is not a mechanism".
 
-**A wave is not a mechanism, and there is nothing to add for one.** "Run #A, #B and #C together, then
-#D by itself, then the rest together" is already expressible with the dependency declaration
-`SKILL.md` describes.
+**A wave is not a mechanism, and there is nothing to add for one** — the dependency declaration
+already expresses it.
 
 ## The shape
 
-**A wave boundary is drawn by chaining every child of the later wave to every child of the earlier
-one.** Wave 1 `{#A, #B, #C}` → wave 2 `{#D}` → wave 3 `{#X, #Y, #Z}` is written in the epic's
-`## Dependencies` as three chain lines:
+**Chain every child of the later wave to every child of the earlier one.** Wave 1 `{#A, #B, #C}` →
+wave 2 `{#D}` → wave 3 `{#X, #Y, #Z}` in the epic's `## Dependencies`:
 
 ```
 #A -> #D -> #X
@@ -21,85 +18,51 @@ one.** Wave 1 `{#A, #B, #C}` → wave 2 `{#D}` → wave 3 `{#X, #Y, #Z}` is writ
 #C -> #D -> #Z
 ```
 
-- **#A #B #C are blocked by nobody, so they start together** — as many at once as there are free lanes.
-- **#D is `time` until all three have closed**, and becomes runnable the moment the last one does.
+- **#A #B #C are blocked by nobody, so they start together** — as many as there are free lanes.
+- **#D is `time` until all three have closed**, then runnable.
 - **#X #Y #Z are blocked by #D, so #D necessarily runs alone.**
-- **#D closing releases wave 3**, which again runs as wide as the lanes allow.
-
-**The block above is an illustration, not something to paste.** `parse_dependency_chains` strips
-fenced blocks before it matches, so a `## Dependencies` section whose chains sit inside a fence reads
-as **no declaration at all** rather than as an error — and `#A` / `#B` are not issue numbers anyway.
-The lines go into the epic body unfenced, with real numbers.
-
-**Deleting a declared order is `pnpm josh epic --remove <E> <M> <N> [<N2> …]`, and never a hand edit
-either.** The arguments are a path, so each consecutive pair is one order and a whole chain goes in
-one call; the body's declaration and the `blocked-by` relations are written from that one input,
-exactly as `--add` writes them. **The ends are never reconnected** — `#A -> #B -> #C` minus
-`#B -> #C` leaves `#A -> #B`, and taking out a middle child's two links leaves `#A` and `#C`
-unordered rather than declaring `#A -> #C`. Deleting the last link writes the unordered sentence, so
-the section never ends up with no machine-readable declaration. Pass `--decision-file` to record why;
-the record lands on the epic's `## Decisions` and on both ends of every deleted order. Doing either
-half by hand is the `declaration_mismatch` below, arrived at from the other direction.
-
-**Write the boundary with `pnpm josh epic --add`, not by hand.** A declared link with no recorded
-`blocked-by` relation is the `declaration_mismatch` that `find_anomalies` reports, and it stops
-`epic:next` and the run that consumes it outright; the rule `epic-bundle.md` ends on — record the order in `blocked-by` **and**
-in `Dependencies` — is what a wave has to satisfy, and editing the body alone satisfies half of it.
-**`--before <hub>` and `--after <hub>` are both refused while the hub sits in more than one chain
-with nothing after it** — which is exactly what a hub is the moment the earlier wave has been chained
-into it. **The first child of the next wave therefore goes into the declaration by hand**, with its
-`blocked-by` recorded to match. Once the hub has a successor, `--after <hub>` branches a new line and
-the rest of that wave goes in with it.
-
-**Any number of chain lines is allowed, and one child may be an endpoint of several of them.** The
-consistency check rejects exactly two things, a **cycle** and a **disagreement between the
-declaration and the recorded `blocked-by`**; a fan-in and a fan-out are neither.
-
-**The number of lines is the size of the widest wave**, because a one-child wave is a hub and the
-chains through it collapse into one line each. Where both sides of a boundary hold several children
-the count grows — and that is the moment to ask whether the boundary is real, rather than to go
-looking for a shorter notation.
+- **#D closing releases wave 3.**
+
+**The block above is an illustration, not something to paste**: chains inside a fence read as no
+declaration at all. Write the lines unfenced, with real numbers.
+
+**Write the boundary with `pnpm josh epic --add`, not by hand** — a declared link with no recorded
+`blocked-by` is a `declaration_mismatch` that stops `epic:next` and the run. **`--before <hub>` and
+`--after <hub>` are both refused while the hub sits in more than one chain with nothing after it**, so
+**the first child of the next wave goes into the declaration by hand**, with its `blocked-by` recorded
+to match; after that, `--after <hub>` branches the rest.
+
+**Delete a declared order with `pnpm josh epic --remove <E> <M> <N> [<N2> …]`, never a hand edit.**
+Each consecutive pair is one order. **The ends are never reconnected** (`#A -> #B -> #C` minus
+`#B -> #C` leaves `#A -> #B`). Deleting the last link writes the unordered sentence.
+`--decision-file` records why on the epic and on both ends.
+
+**Any number of chain lines is allowed**; only a **cycle** and a **disagreement between the
+declaration and the recorded `blocked-by`** are rejected. The line count is the widest wave; when both
+sides of a boundary hold several children, ask whether the boundary is real.
 
 ## Running one child alone is a wave of one
 
-**There is no `solo` mechanism, and none is needed.** "This one must not run beside anything" is the
-shape above with a wave of size one: chain into it every child that must not overlap it, and out of
-it every child that must not precede it.
+**There is no `solo` mechanism.** Chain into it every child that must not overlap it, and out of it
+every child that must not precede it.
 
 ## When a wave may be declared
 
-**Declare a boundary only where the later wave needs the earlier wave's artifact.** That is the whole
-condition, and it is narrower than it sounds:
-
-- **A mere preference of order is not a dependency.** Wanting one child to go first — to see its
-  result early, to get the risky one out of the way — is presentation order, and the task-list order
-  is where that belongs. Substituting a dependency for it buys the order and pays with the stall below.
-  **Write it with `--order-before <M>` / `--order-after <M>`**, which move the task-list row and
-  declare nothing; `--before` / `--after` are for an order that really is a dependency. Neither of the
-  order-only flags helps at a **wave boundary**, which is a dependency by definition — the hub case
-  above stays what it is.
-- **Two children that merely edit the same file are not a dependency.** A textual conflict resolves
-  inside the lane: every run merges `origin/main` before its gate (`pnpm josh main:merge`), and an
-  overlap that lands after it is resolved where it surfaces (`backlogrun-recovery.md` → "Conflicts are
-  not predicted"). Run them in parallel; the per-conflict price is `backlogrun-lanes.md` → "Lanes —
-  running more than one child at a time".
-- **Two children that would each build the same mechanism are a dependency.** No merge reconciles two
-  implementations of one thing — the later child must build on the earlier one's, so the boundary stays.
-- **No reason to wait means no declaration.** An epic whose children are mostly independent says so in
-  prose and leaves the graph empty.
+**Only where the later wave needs the earlier wave's artifact.**
 
-## What a jam does, and how it is cleared
+- **A preference of order is not a dependency** — use task-list order: `--order-before <M>` /
+  `--order-after <M>` move the row and declare nothing. They do not help at a wave boundary.
+- **Two children editing the same file are not a dependency** — run them in parallel; conflicts
+  resolve in the lane (`pnpm josh main:merge`; `backlogrun-recovery.md` → "Conflicts are not
+  predicted"; `backlogrun-lanes.md` → "Lanes — running more than one child at a time").
+- **Two children that would each build the same mechanism are a dependency.**
+- **No reason to wait means no declaration** — say so in prose and leave the graph empty.
 
-**Declare a boundary and one stuck child in the earlier wave stops every wave behind it.**
-`from_blockers` in `scripts/epic/epic-classify.ts` propagates `human`: a wave-1 child labelled
-`needs-decision` makes every child behind it "waiting on a person" rather than "waiting on time".
+## What a jam does, and how it is cleared
 
-**The park itself is not the halt.** `backlogrun` parks that child and goes on running the rest of
-wave 1 exactly as it always does; the session stops once those close and nothing is runnable,
-because every later wave has been classified `human`. So a boundary is paid for at the *end* of the
-wave rather than at the moment one child parks. **Clearing it is removing that child's
-`needs-decision`** once the decision has been recorded — the removal recording a decision already
-requires — after which the waves behind it become runnable on the next round.
+**One stuck child in an earlier wave stops every wave behind it**: a `needs-decision` child makes
+every child behind it "waiting on a person" (`from_blockers` in `scripts/epic/epic-classify.ts`).
+`backlogrun` parks it and runs the rest of the wave; the session stops once nothing is runnable.
+**Clear it by removing that child's `needs-decision`** once the decision is recorded.
 
-**A wave is declared for a real wait and removed when the wait ends; it is not the standing shape of
-an epic.**
+**A wave is declared for a real wait and removed when the wait ends.**

package/.claude/skills/verify-ui/SKILL.md

@@ -6,84 +6,59 @@ argument-hint: '[route] [route...]'
 
 # Verify the rendered screen
 
-The completion gate in `CLAUDE.md` says a change that affects the rendered UI is not done until
-someone has looked at the rendered result; passing unit and E2E tests are not that look. This skill is
-the look. Rationale: `docs/maintainers/verify-ui-rationale.md` → "Why the skill reads as it does".
+A rendered-UI change is not done until someone has looked at it (`CLAUDE.md` → completion gate);
+passing tests are not that look. Rationale: `docs/maintainers/verify-ui-rationale.md` → "Why the skill
+reads as it does".
 
 ## 1. Decide which routes to capture
 
-In order:
-
 1. The routes given as arguments (`/verify-ui / /blog`).
-2. Otherwise, derive the candidates with `pnpm josh ui:routes`: it reads the
-   change (the branch diff, or the staged diff with `--staged`) and lists the routes it touches,
-   tracing a changed shared component to the routes that render it. From that list **pick the ones a
-   reader would notice** — that narrowing is the judgement the command leaves to you.
-3. If it derives no route — it prints that plainly rather than guessing — ask which screen to look
-   at. Do not guess.
+2. Otherwise `pnpm josh ui:routes` (branch diff, or `--staged`) lists the routes the change touches;
+   **pick the ones a reader would notice**.
+3. If it derives none, ask which screen to look at. Do not guess.
 
-State the list before capturing, so a wrong route is caught before the build.
+State the list before capturing.
 
 ## 2. Find this project's screenshot command
 
-The command belongs to the application layer, not to this package, and it differs per project type.
-Look for it in this order and stop at the first hit:
+Stop at the first hit:
 
 1. `pnpm josh-app shot` — the SvelteKit application toolkit (`@joshuafolkken/app-kit`).
 2. `pnpm josh-game shot` — the game toolkit (`@joshuafolkken/game-kit`).
 3. A project-local script named `shot`, `screenshot` or `verify:ui` in `package.json`.
 
-Option 1 exists since app-kit 0.86.0; game-kit carries no `shot` yet, so a game project lands on
-option 3 or the fallback below. Both are true of a version, and
+Option 1 exists since app-kit 0.86.0; game-kit carries no `shot` yet —
 the version a project has installed is the only thing that decides.
 
-**Decide by the printed command list, not by whether the toolkit is installed.** Run the toolkit
-with no subcommand (`pnpm josh-app`) and read the usage line it prints; `shot` exists only if that
-list names it. An unknown subcommand exits non-zero with the same usage line, so a toolkit that is
-present but has no `shot` command and a toolkit that is absent are told apart by reading the list,
-not by whether the invocation succeeded.
+**Decide by the printed command list, not by whether the toolkit is installed.** Run the toolkit with
+no subcommand (`pnpm josh-app`) and read its usage line; an absent toolkit and one without `shot` both
+exit non-zero.
 
 ### When there is no screenshot command
 
-The gate still has to be met, so fall back in this order.
-
-**Capture through the project's own E2E suite.** If it has Playwright specs, add a
-`await page.screenshot({ path: … })` to the spec that already covers the affected screen — or a new
-spec if none does — and run it.
-
-**Otherwise stop and say so.** Report, in the session language:
+**Capture through the project's own E2E suite**: add `await page.screenshot({ path: … })` to the
+Playwright spec covering the screen (or a new spec) and run it.
 
-- that this project has neither a screenshot command nor an E2E suite to capture through, naming
-  what you looked for;
-- that the UI verification gate is therefore **not** closed by this run;
-- that the change needs a human to look at the screen, and ask the user to do it.
+**Otherwise stop and say so**, in the session language: what you looked for, that the UI verification
+gate is **not** closed by this run, and ask the user to look at the screen.
 
 Never report the gate as satisfied on tests alone. Never stand up a preview server by hand and drive
-it from a throwaway script left outside the repository. If the project should have the command and
-does not, that is an issue to file against the application toolkit.
+it from a throwaway script. A project that should have the command and does not is an issue against
+the application toolkit.
 
 ## 3. Capture
 
-Run the command once for every route in a single invocation (`pnpm josh-app shot / /blog`). Wait for
-it to finish and note the output directory it prints. On the E2E fallback, run the spec and note where its
-`path` option wrote the images.
-
-If it exits non-zero, report the failure as the result. A failed capture is not a passed gate.
+Run the command once for every route (`pnpm josh-app shot / /blog`) and note the output directory (on
+the E2E fallback, the `path` option). A non-zero exit is the result. A failed capture is not a passed gate.
 
 ## 4. Look at the images
 
-Read every produced image with the Read tool. Actually look at each one — capturing files without
-opening them does not close the gate.
-
-Check what the change was supposed to do to the screen: the element is present, in the right place,
-at the right size, with the intended spacing, color and text; nothing that used to be there has
-disappeared or moved; the layout is not broken at the captured viewport.
+Read every produced image with the Read tool — capturing without opening does not close the gate.
+Check the change's intent: element present, placed, sized, spaced, colored and worded as intended;
+nothing else disappeared or moved; the layout holds at the captured viewport.
 
 ## 5. Report
 
-- **Matches the intent**: say what you looked at, route by route, and what you checked on each. Name
-  the image paths so the user can open the same files.
-- **Does not match**: for each mismatch give the route, what the change was supposed to produce,
-  what the image actually shows, and the image path. Then fix and capture again. Do not report the
-  work as done with a known mismatch outstanding.
+- **Matches the intent**: route by route, what you checked, with the image paths.
+- **Does not match**: route, intended result, what the image shows, image path. Fix and capture again.
 - **Could not capture**: the report from step 2 or step 3, unchanged. This is not a pass.

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

@@ -21,69 +21,58 @@ Where each rule came from: `docs/maintainers/background-commands-rationale.md`
 
 ## How the wait ends — the task's exit, never a regex over its output
 
-**Background it from the first, then end the turn.** A command issued with `run_in_background` set
-re-invokes the run when it exits, and that completion notification is what ends the wait — on the
-task's *exit*, not on a regex match and not on the harness block limit. So the moment you background
-a long command there is nothing to wait *on*: end the turn, and the wake-up brings you back with the
-command finished.
-
-**Never hand-write a `while`/`until` … `sleep` loop over the output file.** The loop does not know
-when the command finished: a regex that never matches waits to the block limit, and one that matches
-a mid-run line exits too early. `pnpm josh rule:guard` refuses the poll loop and hands back this route
-(`prompts/collaboration-workflow/rule-delivery.md`). Rationale:
-`docs/maintainers/background-commands-rationale.md` → "Why a poll loop is refused".
-
-**To glance at interim output, `Read` the output file once** — the notification names its path — and
-never in a sleep loop. If what you are waiting on is CI, `pnpm josh followup` waits on it for you in
-the foreground; a bare `sleep` that arms a progress heartbeat is `run:progress --wait`'s job, refused
-in front of a hand-armed timer by `early-heartbeat`.
+**Background it from the first, then end the turn.** A `run_in_background` command re-invokes the run
+when it *exits* — that completion notification is what ends the wait, not a regex match or the block
+limit.
+
+**Never hand-write a `while`/`until` … `sleep` loop over the output file** — a regex that never matches
+waits to the block limit, one that matches a mid-run line exits early. `pnpm josh rule:guard` refuses it
+(`prompts/collaboration-workflow/rule-delivery.md`; `docs/maintainers/background-commands-rationale.md`
+→ "Why a poll loop is refused").
+
+**To glance at interim output, `Read` the output file once**, never in a sleep loop. CI is waited on by
+`pnpm josh followup`; a progress heartbeat is `run:progress --wait`'s job (`early-heartbeat` refuses a
+hand-armed timer).
 
 ## The tail and what overlaps each wait
 
-**Never give a foreground call a timeout above the harness cap** — the cap decides how long a
-foreground call waits, so a larger number detaches the call without the completion notification.
-Rationale: `docs/maintainers/background-commands-rationale.md` → "Why the tail collects idle time".
+**Never give a foreground call a timeout above the harness cap** — a larger number detaches it without
+the completion notification (`docs/maintainers/background-commands-rationale.md` → "Why the tail
+collects idle time").
 
-**The tail is emptied before `followup` is issued, rather than worked through after it returns.**
-One question decides each step, and it is asked of the step rather than judged: **does it read the
+**The tail is emptied before `followup` is issued.** Each step is asked one question: **does it read the
 merge result?**
 
-- **It does — the step stays after `followup`.** `pnpm josh ms`, `pnpm josh issue:state <N>`,
-  `pnpm josh epic:next`, `pnpm josh backlog:next --exclude <N>`, and `pnpm josh lane:close` /
-  `pnpm josh lane:list`. **De-duplicating a step is not removing it**: none of these may be dropped or
-  answered from memory.
-- **It does not — the step is composed in the turn that issues `followup`.** The epic progress
-  comment's counter *values* and the completion report body (placed beside `pnpm josh git -y` in the
-  table below). **Only the write follows the merge.**
-- **`pnpm josh cost --cut` stays after the merge, and reads nothing from it** — its answer grows with
-  the session, so it keeps its documented seam (`backlogrun-progress.md` → "The check is asked at
-  every merge").
-
-**What runs beside a backgrounded command is the work that writes nothing to the working tree** — a
-step that edits makes the background command's result stale. Applied to the three waits a run
-actually has:
+- **It does — it stays after `followup`**: `pnpm josh ms`, `pnpm josh issue:state <N>`,
+  `pnpm josh epic:next`, `pnpm josh backlog:next --exclude <N>`, `pnpm josh lane:close` /
+  `pnpm josh lane:list`. **De-duplicating a step is not removing it** — none is dropped or answered
+  from memory.
+- **It does not — it is composed in the turn that issues `followup`**: the epic progress counter
+  *values* and the completion report body. **Only the write follows the merge.**
+- **`pnpm josh cost --cut` stays after the merge**, though it reads nothing from it (`backlogrun-progress.md`
+  → "The check is asked at every merge").
+
+**Beside a backgrounded command runs only work that writes nothing to the working tree**:
 
 | While this runs | Do this beside it |
 | --------------- | ----------------- |
 | `pnpm josh gate` | a subagent running `/code-review` with the brief `pnpm josh review:brief` prints |
 | `pnpm josh git -y` | Write the completion notification body to a file for `--notify-message-file`, and settle the three-way disposition of any remaining non-High finding |
 | CI, after the push | The second review round where one is due, the branch-2 filing through `pnpm josh issue:file`, which runs `epic:bundle` itself (`prompts/review.md` → "Review round cap") |
-| `pnpm josh followup` | Nothing — it is foreground and holds the session. **The post-merge tail is what overlaps here, and it is taken before the call rather than beside it**: compose the epic progress counters first, and leave after the merge only the steps that read its result, plus `pnpm josh cost --cut` |
+| `pnpm josh followup` | Nothing — it is foreground. **The post-merge tail is taken before the call**: compose the epic progress counters first, and leave after the merge only the steps that read its result, plus `pnpm josh cost --cut` |
 
-**The turn never ends at the push.** The completion notification for `pnpm josh git -y` is what
-resumes the run, and the turn that reads it goes straight through any branch-2 filing and
-`pnpm josh epic:bundle` to `pnpm josh followup`. `pnpm josh rule:guard` refuses the foreground push
-step and states both halves at that call (`prompts/collaboration-workflow/rule-delivery.md`); the push
-reissued detached is not refused again. Rationale: `docs/maintainers/background-commands-rationale.md`
-→ "Why the push is guarded".
+**The turn never ends at the push.** The `pnpm josh git -y` completion resumes the run, and that turn
+goes straight through any branch-2 filing and `pnpm josh epic:bundle` to `pnpm josh followup`. `pnpm
+josh rule:guard` refuses the foreground push (`prompts/collaboration-workflow/rule-delivery.md`); the
+push reissued detached is not refused again (`docs/maintainers/background-commands-rationale.md` → "Why
+the push is guarded").
 
-**One turn does end before the push, and only one: a dispatched lane child's pre-gate cut.** It ends
-the turn before the gate and relaunches a fresh process in the same act — `pre-gate-cut.md` → "Taking
-the cut" is its single source.
+**One turn does end before the push: a dispatched lane child's pre-gate cut** — `pre-gate-cut.md` →
+"Taking the cut".
 
 **A headless lane child (`claude -p`) is where "a background command re-invokes the run" does not
-hold: its background Bash tasks are killed when its turn ends.** It hands the gate-to-merge region to
-a foreground `pnpm josh ship --detach` instead (`chain-rule.md` step 0); `pnpm josh rule:guard` refuses a
+hold: its background Bash tasks are killed when its turn ends.** It hands the gate-to-merge region to a
+foreground `pnpm josh ship --detach` (`chain-rule.md` step 0); `pnpm josh rule:guard` refuses a
 backgrounded `josh gate` / `git` / `followup` / `ship` there, and the `Stop` hook sends a child with a
 task still running back to wait.
 

package/.claude/skills/workflow-commands/backlogrun-child.md

@@ -1,113 +1,106 @@
 # `backlogrun` — running a child (shared mechanics, delegation, liveness, session setup)
 
-Point-of-use, read one section at a time from `backlogrun.md` → "The route table" (rationale: `docs/maintainers/backlogrun-child-rationale.md` → "Why the file is read by section").
+Point-of-use, read one section at a time from `backlogrun.md` → "The route table". Reasons:
+
+- `docs/maintainers/backlogrun-child-rationale.md` → "Why the file is read by section"
+- `docs/maintainers/backlogrun-child-rationale.md` → "Why a bare Issue promotes itself under `backlogrun` but not under `fullrun`"
+- `docs/maintainers/backlogrun-child-rationale.md` → "Why each child runs in a delegated unit"
+- `docs/maintainers/backlogrun-child-rationale.md` → "Why the summary is bounded the way it is"
+- `docs/maintainers/backlogrun-child-rationale.md` → "Why the audit runs before the first child"
+- `docs/maintainers/backlogrun-child-rationale.md` → "Why `josh latest` is hoisted to the session"
+- `docs/maintainers/backlogrun-child-rationale.md` → "Why the preflight is part of the claim"
 
 ## Running a child — the shared mechanics
 
-Everything below runs **one child** — of a named epic, or of the opted-in backlog. A single-issue named item, a named epic's child and a bare backlog child all run the same `fullrun` in the same way, and this part is the single source of how. A named epic runs these mechanics over its own children until every one is processed, then the run advances to the next named item.
+This file is the single source of how **one child** runs — a named single-issue item, a named epic's
+child and a bare backlog child all run the same `fullrun`. A named epic runs these mechanics over its
+children until every one is processed, then the run advances to the next named item.
 
 ## When `#N` is not an epic
 
-`backlogrun` accepts an ordinary Issue as well as an epic. `backlogrun #<N>` on an Issue with no task list
-runs `#<N>` as a `fullrun` and then finishes. Inside `backlogrun #<N>`, a prerequisite or a split found
-mid-run does **not** stop the run (rationale: `docs/maintainers/backlogrun-child-rationale.md` → "Why a
-bare Issue promotes itself under `backlogrun` but not under `fullrun`"):
-
-1. File the new Issue(s) with the matching route label — `route:split` for a split, `route:tier-a`
-   for a prerequisite — no confirmation.
-2. **Stash the work in progress and remove `in-progress` from `#<N>`**, exactly as steps 2 and 4 of
-   "A prerequisite discovered mid-run" do — `git stash push -u -m "..."` with the `-u`, the
-   `gh api repos/{owner}/{repo}/issues/<N>/comments` post that records the stash, and
-   `pnpm josh run:release <N>`, which removes the label with the hold.
+`backlogrun #<N>` on an Issue with no task list runs `#<N>` as a `fullrun` and finishes. A prerequisite
+or a split found mid-run does **not** stop it:
+
+1. File the new Issue(s) — `route:split` for a split, `route:tier-a` for a prerequisite — no
+   confirmation.
+2. **Stash and remove `in-progress`**, as steps 2 and 4 of "A prerequisite discovered mid-run" do:
+   `git stash push -u -m "..."`, a `gh api repos/{owner}/{repo}/issues/<N>/comments` post recording the
+   stash, and `pnpm josh run:release <N>`.
 3. **Ask `pnpm josh epic:bundle <N>` whether an epic already tracks `#<N>` before creating one.**
 
    | Answer | What to do |
    | --- | --- |
-   | An epic `#<E>` already tracks `#<N>` | `pnpm josh epic --add <E> <P> --before <N>` for a prerequisite, or `--add <E> <N1> ...` for a split. **Do not create a second epic.** Continue the loop against `#<E>` |
-   | No epic tracks it | Create one — the command depends on what was found (table below) |
-   | **The command could not answer** — a non-zero exit, `Could not confirm which epic already tracks these — do not place this issue in one.`, or a ⚠ warning about a truncated listing (beginning `⚠ The epic listing …`, in either form `hit its …-epic cap` / `stopped at the …-issue page ceiling`) above a `Nothing to bundle.` verdict; `⚠ Could not read #N.` is one failed relation read and voids nothing, and a definitive answer stands even beside a warning | Park `#<N>` with `needs-decision` and report. "Could not tell" is not "no epic tracks it" |
+   | An epic `#<E>` already tracks `#<N>` | `pnpm josh epic --add <E> <P> --before <N>` (prerequisite) or `--add <E> <N1> ...` (split). **Do not create a second epic**; continue against `#<E>` |
+   | No epic tracks it | Create one (table below) |
+   | **The command could not answer** | Park `#<N>` with `needs-decision` and report — "could not tell" is not "no epic" |
+
+   "Could not answer" is a non-zero exit, `Could not confirm which epic already tracks these — do not
+   place this issue in one.`, or a `⚠ The epic listing …` truncation warning (`hit its …-epic cap` /
+   `stopped at the …-issue page ceiling`) above `Nothing to bundle.`. `⚠ Could not read #N.` voids
+   nothing, and a definitive answer stands beside a warning.
 
-   When creating one, `#<N>` is itself one of the deliverables — this path always takes the
-   keep-as-a-child arm of `split-assessment.md`'s promote-or-create branch. Which command depends on
-   what was found, because `--ordered` makes the argument order the dependency chain:
+   `#<N>` is itself one of the deliverables (the keep-as-a-child arm of `split-assessment.md`).
+   `--ordered` makes the argument order the dependency chain:
 
    | Found | Command |
    | --- | --- |
-   | A prerequisite `<P>` | `pnpm josh epic "<title>" <P> <N> --ordered` — the prerequisite comes **first** |
+   | A prerequisite `<P>` | `pnpm josh epic "<title>" <P> <N> --ordered` — the prerequisite **first** |
    | A split into independent children | `pnpm josh epic "<title>" <N> <N1> ...` — **no `--ordered`** |
-   | A split whose children do have an order | `pnpm josh epic "<title>" ... --ordered`, arguments in that order |
-
-4. **Run `pnpm josh epic:audit <E>` now**, not earlier — there is no epic to audit until step 3.
-5. **Do not stop.** Continue into the loop below against the new epic `#<E>`.
-
-**Nothing found means no epic.** If `#<N>` reaches its merge without a prerequisite or a split turning
-up, the run finishes there. An epic is created only when there is a second child to put in it.
+   | A split whose children do have an order | `pnpm josh epic "<title>" ... --ordered`, in that order |
 
-**Every guard below applies on this path unchanged** — 30 children, 10 Issues filed, 3 consecutive
-failures.
+4. **Run `pnpm josh epic:audit <E>` now** — there is no epic to audit before step 3.
+5. **Do not stop.** Continue into the loop against `#<E>`.
 
-**This does not let `fullrun` promote itself.** A `fullrun` that discovered a split still files the
-children and the epic and then **stops** (`split-assessment.md` → "Finding a split mid-run stops the
-run").
+- **Nothing found means no epic** — the run finishes at `#<N>`'s merge.
+- **Every guard applies unchanged** — 30 children, 10 Issues filed, 3 consecutive failures.
+- **`fullrun` does not promote itself** — it files and **stops** (`split-assessment.md` → "Finding a
+  split mid-run stops the run"). `josh epic:next` still refuses an Issue with no task list.
+- **A bare Issue named beside an epic is a mistyped command.** Named alone, the refusal is the answer;
+  among several, it is **skipped** — `backlogrun #<E> --only #<N>` exits 0, notes the skip on stderr
+  and **never runs `#<N>`**. To do both, type `backlogrun #<N>` after the epic.
 
-**`josh epic:next` is not changed by any of this.** It still refuses an Issue with no task list; the
-acceptance of a bare Issue belongs to `backlogrun`.
-
-**Naming a bare Issue beside an epic is a mistyped command rather than a second entry.** Where one
-reference is named, the refusal is the whole answer. Where several are, a task-listless reference is
-**skipped** so the other epics keep running — `backlogrun #<E> --only #<N>` with `#<N>` an ordinary Issue exits
-0, notes the skip on standard error, and **never runs `#<N>`**. A run that means to do both types
-`backlogrun #<N>` on its own after the epic.
 ## Each child runs in a delegated unit
 
-**A child is not run in the parent loop's context** — **whatever offers a child — the loop, or a
-person clearing a label — the child is handed to a lane, never to the parent.** `pnpm josh delegate
-epic-child` answers `delegate`; in a lane the unit is a detached process started by `pnpm josh
-lane:launch` (`backlogrun-lanes.md` → "Opening one lane and dispatching its child"), with the invoking
-CLI's `worker` profile — Claude Code defaults to Anthropic `claude-opus-5-5` / `medium`
-(`docs/josh-commands-run.md` → "`josh lane:dispatch`", the single source).
-Where no isolated unit exists, run the child in the parent's context; the hand-off is still asked at
-every merge. Rationale: `docs/maintainers/backlogrun-child-rationale.md` → "Why each child runs in a
-delegated unit".
-
-**The parent reads GitHub, never the summary** — `pnpm josh issue:state <N>` (or `run:merge`) is the
-verifier; **never advance the loop on the summary alone**.
+**Whatever offers a child — the loop, or a person clearing a label — the child is handed to a lane,
+never run in the parent's context.** `pnpm josh delegate epic-child` answers `delegate`; the unit is a
+detached process from `pnpm josh lane:launch` (`backlogrun-lanes.md` → "Opening one lane and
+dispatching its child") with the CLI's `worker` profile — Claude Code defaults to Anthropic
+`claude-opus-5-5` / `medium` (`docs/josh-commands-run.md` → "`josh lane:dispatch`"). With no isolated
+unit, run the child in the parent's context and still ask the hand-off at every merge.
 
-**The brief names the invocation it descends from** — e.g. `backlogrun #<E> --only`, the child number,
-and that the child runs as `fullrun #<N>` under that authorization; the unit refuses a brief without it.
+- **The parent reads GitHub, never the summary** — `pnpm josh issue:state <N>` (or `run:merge`)
+  verifies; **never advance the loop on the summary alone**.
+- **The brief names the invocation it descends from** — e.g. `backlogrun #<E> --only`, the child
+  number, and that it runs as `fullrun #<N>` under that authorization; the unit refuses a brief without
+  it.
 
 ### What the summary carries, and how long it may be
 
-**The summary carries only what GitHub does not, in at most 25 lines; the brief states the bound.**
-Rationale: `docs/maintainers/backlogrun-child-rationale.md` → "Why the summary is bounded the way it is".
+**Only what GitHub does not, in at most 25 lines; the brief states the bound.**
 
-- **Kept**: `Cause` / `Fix` / `Result`; every verification result not closed the ordinary way, named
-  as such; observations that could bite later — **the only route a child's discretionary observation
-  has** (`observation-filing.md` → "A delegated child does not take this route"); decisions not already
-  logged; what was left undone, and under whose authority.
-- **Cut**: the changed-file list, per-round review detail, and restated rules.
+- **Kept**: `Cause` / `Fix` / `Result`; every verification not closed the ordinary way, named as such;
+  observations that could bite later — **a child's only route for one** (`observation-filing.md` → "A
+  delegated child does not take this route"); decisions not yet logged; what was left undone, on whose
+  authority.
+- **Cut**: the changed-file list, per-round review detail, restated rules.
 
 The person-facing report (`prompts/collaboration-workflow/report-format.md` → 「完了報告（セッション向け）」)
 is unchanged.
 
 ## A delegated unit that stopped without reporting
 
-**Hand the child to the unit without blocking on its return, and poll** — a stopped unit leaves no
-notification behind. Once its output has been unchanged for the silent-unit window, read
-`backlogrun-recovery.md` → "A delegated unit that stopped without reporting" and ask
-`pnpm josh run:liveness`.
+**Hand the child off without blocking, and poll** — a stopped unit leaves no notification. Once its
+output is unchanged for the silent-unit window, read `backlogrun-recovery.md` → "A delegated unit that
+stopped without reporting" and ask `pnpm josh run:liveness`.
 
 ## Audit before the first child
 
-Run `pnpm josh epic:audit <E>` before step 1 below. **When the run began from a bare Issue there is
-nothing to audit yet** — that path runs the audit at the moment it creates the epic instead. Errors
-stop the run; warnings are read and carried on past. Fixing what it finds is Tier A. Rationale:
-`docs/maintainers/backlogrun-child-rationale.md` → "Why the audit runs before the first child".
+Run `pnpm josh epic:audit <E>` before the first child; a run begun from a bare Issue audits when it
+creates the epic. Errors stop the run; warnings are read and passed. Fixing a finding is Tier A.
 
 ## `josh latest` runs once per session, not once per child
 
-`josh latest` belongs to the **session**, not to a child. Ask once, the first time the loop below hands
-back a child number — before implementing that child — and never again:
+Ask once, the first time the loop hands back a child number, before implementing it:
 
 ```bash
 pnpm josh latest:scope   # → required | skip ; the reason on stderr
@@ -117,20 +110,14 @@ pnpm josh latest         # on `required` only
 pnpm josh stash:pop "backlogrun: josh latest #<N>"         # only if you stashed above — by message, not a positional pop
 ```
 
-On `required`, load the `dependency-update` skill; `latest-gate.md` is the single source. **Session,
-not run** — each session updates its own checkout, and a resumed `backlogrun` asks again. **The lock
-file lands with the first child's `pnpm josh git -y`**; fix a failing bump forward. **`josh latest` is
-never run inside a lane** (`pnpm josh latest:guard` refuses it) — with lanes the parent runs it in the
-primary checkout (`backlogrun-lanes.md` → "Once per repository, before the first lane opens").
-
-Rationale: `docs/maintainers/backlogrun-child-rationale.md` → "Why `josh latest` is hoisted to the
-session".
+On `required`, load the `dependency-update` skill; `latest-gate.md` is the single source. A resumed
+`backlogrun` asks again. **The lock file lands with the first child's `pnpm josh git -y`**; fix a
+failing bump forward. **Never inside a lane** (`pnpm josh latest:guard` refuses) — the parent runs it
+in the primary checkout (`backlogrun-lanes.md` → "Once per repository, before the first lane opens").
 
 ## Preflight — the child's claim asks it
 
-`pnpm josh run:hold <N>`, the first call of the child's `fullrun`, checks for an interrupted run's
-leftovers before it claims the tree, and prints the step for each answer (`reclaim` / `resume` /
-`park`) on stderr — follow it, and report a reclaim or resume with its stash reference. The answers are
-`docs/josh-commands-run.md` → "`josh run:hold`"; rationale:
-`docs/maintainers/backlogrun-child-rationale.md` → "Why the preflight is part of the claim".
-
+`pnpm josh run:hold <N>`, the child's first call, checks for an interrupted run's leftovers before
+claiming the tree and prints the step for each answer (`reclaim` / `resume` / `park`) on stderr —
+follow it, and report a reclaim or resume with its stash reference (`docs/josh-commands-run.md` →
+"`josh run:hold`").