@joshuafolkken/kit 1.1240.0 → 1.1370.0

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

@@ -1,65 +1,30 @@
 # `backlogrun` — lanes and concurrency
 
-**Read this file in full before the first lane opens** — in the turn that reaches
-`pnpm josh lane:open`. It is a point-of-use document, never an entry read: the entry procedure is
-`backlogrun.md`, which points here at that step. This file is the single source of the per-repository
-lane ceiling, the lane lifecycle, and how a merge conflict between lanes is resolved.
+Point-of-use, read one section at a time from `backlogrun.md` → "The route table".
 
 ## Concurrency: as many children per repository as it has free lanes
 
-**An `backlogrun` need not be a single session.** One session per repository; each calls
-`josh epic:next <E> --repo <owner/repo>` and runs only its own repository's children.
+**One session per repository**, each running only its own repository's children; the per-repository
+lane ceiling (`JOSH_LANE_LIMIT`, counted from the `in-progress` listing by `epic:next`) is
+`.claude/skills/epic-commands/SKILL.md` → "An `in-progress` issue occupies a lane", and a dependency that crosses a
+repository is `.claude/skills/epic-commands/SKILL.md` → "Epics that span repositories". Rationale:
+`docs/maintainers/backlogrun-lanes-rationale.md` → "Why the lane ceiling is shaped the way it is".
 
-```bash
-# In the kit checkout
-pnpm josh epic:next 858 --repo joshuafolkken/kit
-```
-
-A child in another repository is read against that repository through `gh api`, so no clone is needed
-to learn its state — only to implement it. A repository with no checkout here says so rather than being
-cloned.
-
-**A dependency that crosses a repository is not satisfied when the blocking issue closes.** Merging
-kit's issue does not publish kit, so such a dependency resolves only once the blocker is closed *and*
-its release has appeared in the registry — and while the blocker is still open the registry is never
-consulted. **Unless that repository publishes nothing** — no `package.json` on its default branch, or
-one declaring `private` — in which case a closed blocker there resolves. The answer is read from the
-blocker repository's manifest, never from the registry.
-
-**The lane count is per repository, and `epic:next` is what applies it.** When it has a child to offer,
-it first asks that repository **how many of its lanes are already running something**: every open issue
-carrying `in-progress` and not parked counts for one — whichever epic it belongs to. What is left of
-`JOSH_LANE_LIMIT` (**default 6**) is what gets offered, and at zero the answer is `wait`. It is asked
-**only when there is a candidate**. A **parked** issue does not hold a lane: `needs-decision` outranks
-`in-progress` here exactly as in the classification. A child stopped by `needs-human-review` is
-deliberately not parked and goes on holding its lane.
-
-**It is advisory and not atomic.** The label is applied when a child is dispatched — the parent claims
-it in `lane:dispatch` before the child process starts, and a standalone `fullrun` / `halfrun` claims it
-the moment `run:hold` answers `hold` — *after* this read. It is a guard, not a mutex.
-
-**It is scoped to the resource, not the epic.** A lane is its own checkout with its own branch and
-ports, so the repository-wide number is a **ceiling on how many lanes run at once**. How a session
-drives more than one child at a time is "Lanes — running more than one child at a time" below.
-
-**A stale label holds a lane, so the stale rule reaches past this epic's own children** — `backlogrun-park.md` →
-"`in-progress` is removed by whoever finds it stale" applies to **any** open issue in the repository. `epic:next`
-names the holders on standard error, and the 90-minute stale window bounds the wait.
-
-**A listing it could not read is not an idle repository.** `epic:next` answers `wait` there rather than
-offering the child. **A listing that was *cut short* is the same answer**: a short one with no visible
-holder is `wait`, with its own message.
+## A solo run
 
-**Two children of one repository may run at once, and the section below is how.** The guard is a
-ceiling rather than a prohibition, scoped to the lane rather than to the epic. **Do not read this as
-"concurrency needs no coordination"**: the coordination is this section plus the one below, and
-switching the guard off is not one of the ways to get parallelism.
-
-Parallelism only helps children that do not depend on each other. When app-kit's child needs kit's new
-feature, that is recorded as `blocked-by` and `epic:next` makes it wait.
-
-Rationale: `docs/maintainers/backlogrun-lanes-rationale.md` → "Why the lane ceiling is shaped the way
-it is".
+**One kind of child takes no lane beside anything: a defect in kit's own verification that makes
+unrelated PRs answer wrongly on `main` today.** It runs alone, and the batch resumes only once it has
+merged. **Decide it from three conditions that must all hold, never from how serious it looks** — is
+it a defect (not an improvement, refactor, removal or feature)? Is it in kit's own verification gate
+(lint / type check / spell check / unit tests), the code review, the pre-push hook, or the merge
+checks — not a consumer repository's CI or template? Does it, on `main` now, make unrelated PRs
+answer wrongly (a false green or a false red)? All three, and the issue carries `run:solo`; any one
+missing, and it carries `run:lane`. `backlog:next` and `epic:next --lanes` answer `triage` for an issue
+with neither, so an issue a run files carries one of the two from its
+filing. **It stops the other lanes for one reason only: a batch run on broken verification leaves
+nobody's result trustworthy.** This section is the rule's single source; rationale:
+`docs/maintainers/wip-cap-rationale.md` → "Why a solo run"; provenance:
+`docs/maintainers/backlogrun-lanes-rationale.md` → "Where each rule came from".
 
 ## Lanes — running more than one child at a time
 
@@ -76,21 +41,6 @@ verification are `pre-gate-cut.md`, the single source. **The child is told apart
 resume stage is handed to it, by a mark the dispatch sets** — `JOSH_LANE_CHILD`, the lane's issue
 number (`pre-gate-cut.md` → "The dispatch mark" and "The stage is passed to the resumed child").
 
-**One kind of child takes no lane beside anything: a defect in kit's own verification that makes
-unrelated PRs answer wrongly on `main` today.** It runs alone, and the batch resumes only once it has
-merged. **Decide it from three conditions that must all hold, never from how serious it looks** — is
-it a defect (not an improvement, refactor, removal or feature)? Is it in kit's own verification gate
-(lint / type check / spell check / unit tests), the code review, the pre-push hook, or the merge
-checks — not a consumer repository's CI or template? Does it, on `main` now, make unrelated PRs
-answer wrongly (a false green or a false red)? All three, and the issue carries `run:solo`; any one
-missing, and it carries `run:lane` and fills a lane like any other child. `backlog:next` and `epic:next --lanes` enforce both (joshuafolkken/kit#2776,
-#2779), and an issue a run files (an interrupt, a split child, a prerequisite) carries one of the
-two from its filing, because an issue with neither answers `triage` and nothing starts. **It stops
-the other lanes for one reason only: a batch run on broken verification leaves nobody's result
-trustworthy** — that the issue's own verification sits under the defect is the issue's own concern,
-checked by the verification after the fix. This paragraph is the rule's single source; rationale:
-`docs/maintainers/wip-cap-rationale.md` → "Why a solo run".
-
 **A lane's review does not inherit the lane, and `pnpm josh review:brief` is what closes that.**
 `pnpm josh review:brief` prints the lane's absolute root, branch and HEAD, hands over targets written
 `git -C <root> …`, and prints a nonce the review attests with `pnpm josh review:attest <nonce>` from
@@ -112,69 +62,36 @@ costs a resolution, a re-run gate and a review (`backlogrun-recovery.md` → "Co
 
 ### Once per repository, before the first lane opens
 
-In the **primary checkout**, in this order, and never again per lane:
-
-1. `git switch main && git pull` — every lane branches from this ref.
-2. `pnpm josh latest:scope`, and the update on `required` — `backlogrun-child.md` → "`josh latest`
-   runs once per session, not once per child".
-3. `pnpm josh lane:prune` — closes lanes left without a work tree, sweeps unregistered leftovers.
-4. `pnpm josh run:tidy` — sweeps merged lanes and stashes (as `run:hold` does).
-
-**`pnpm josh latest` is never run inside a lane, whatever `latest:scope` answers there** — the command
-enforces it: `latest:scope` answers `skip` in a lane and `pnpm josh latest` refuses outright, fronted
-by `pnpm josh latest:guard`. Ask it in the primary checkout, per step 2 above.
-
-**The rewritten lock file still has to reach a pull request**, and with lanes no child runs in the
-primary checkout to carry it. `git stash` is a repository-level ref shared by every work tree:
+In the **primary checkout**, in this order, never again per lane: `pnpm josh ms`; `pnpm josh
+latest:scope` and the update on `required` (`backlogrun-child.md` → "`josh latest` runs once per
+session, not once per child"); `pnpm josh lane:prune`; `pnpm josh run:tidy`.
 
-```bash
-git stash push -u -m "backlogrun: josh latest before lanes"   # primary checkout, only if the update rewrote anything
-```
-
-Record it on that first child's Issue — the comment is what gets it popped if the run dies in between.
-**The first lane's `pnpm josh lane:launch "$n" --stash "backlogrun: josh latest before lanes"` pops it
-by message, after `lane:open`'s own install** — never a positional `git -C "$dir" stash pop`: the stash
-is a repository-wide stack every lane shares, so a positional pop would take whichever lane last pushed.
-**Under the supervisor's `backlog:drive` the driver passes it, never you**:
-each launch asks whether a stash under that message is on the stack and, if one is, hands it to
-`lane:launch --stash` — the pop consumes it, so the first lane takes it and every later one launches
-without. The push above stays the parent's, before the driver starts.
+**The rewritten lock file reaches a pull request through the first lane.** In the primary checkout,
+only if the update rewrote anything, `git stash push -u -m "backlogrun: josh latest before lanes"`, and
+record it on that first child's Issue. **The first lane's `pnpm josh lane:launch "$n" --stash
+"backlogrun: josh latest before lanes"` pops it by message** — never a positional `stash pop` on the
+shared stack. **Under `backlog:drive` the driver passes `--stash`, never you**; the push stays the
+parent's, before the driver starts.
 
 ### Opening one lane and dispatching its child
 
-**One command opens the lane, prepares it, and dispatches the child — `pnpm josh lane:launch`.** It
-runs `lane:open`, then — only when `--stash` is given, which is the first lane alone — pops that stash
-into the lane and re-installs against the lock it brought in, then `lane:dispatch`:
+**One command opens the lane, prepares it, and dispatches the child — `pnpm josh lane:launch`** (over
+`lane:open`, `stash:pop` and `lane:dispatch`, each guard unchanged; rationale:
+`docs/maintainers/backlogrun-lanes-rationale.md` → "Why `lane:launch` folds the lane steps into one"):
 
 ```bash
 pid=$(pnpm josh lane:launch "$n") || exit 1   # the child's pid on stdout, nothing else
-pid=$(pnpm josh lane:launch "$n" --stash "backlogrun: josh latest before lanes") || exit 1   # the first lane only, and only if `josh latest` stashed
 ```
 
-`lane:launch` is a thin layer over `lane:open`, `stash:pop` and `lane:dispatch`, so each of their
-guards, refusals and messages holds unchanged; the bullets below describe the steps it runs.
-Rationale: `docs/maintainers/backlogrun-lanes-rationale.md` → "Why `lane:launch` folds the lane steps
-into one".
-
-- **A refusal is an empty capture beside a non-zero exit**, with the reason on standard error: `full`,
-  `already-open`, and a **failed install** — which leaves a real work tree behind holding its seat, so
-  the next launch answers `already-open` and never retries. **Park that child and name
-  `pnpm josh lane:close <N>`** — a lock the lane cannot build is a state a person fixes. A refused
-  `lane:open`, a pop that refused, or a failed re-install each **stop the launch before the child is
-  dispatched**.
-- **`lane:open` installs; the `--stash` lane re-installs, and only that lane needs it.** A failed
-  install fails `lane:open`, so `lane:launch` reaching `lane:dispatch` is the guarantee the lane runs.
-  **A pop that fails stops the lane** rather than re-installing anyway.
-- **A `<N>-lane` that already exists is attached to, and `lane:open` says so on standard error** — the
-  way back to a child parked after it pushed: a local branch of that name gets the work tree put on it,
-  and where there is none the **remote** is asked (`ls-remote`, fetched first) and the lane cut from
-  `origin/<N>-lane` where the branch survives — otherwise from the default branch. **A reused branch is
-  not a fresh lane.** Nothing deletes a branch to open a lane, so a reopen cannot cost the pushed work.
-- **Nothing switches the lane's branch.**
-- **`pnpm josh run:hold`'s preflight check is not asked in a lane; `lane:open`'s own answer replaces it.**
-  What a leftover looks like here is `lane:open` answering `already-open`.
-- **`pnpm josh run:hold` is unchanged, and is claimed inside the lane** — it keys on
-  `git rev-parse --absolute-git-dir` (`.git/worktrees/<name>`), so each lane holds independently.
+| It answers | What the run does |
+| --- | --- |
+| a pid | The child runs; poll it |
+| empty, non-zero, `full` | No free lane; wait for one |
+| empty, non-zero, `already-open` or a failed install | **Park that child and name `pnpm josh lane:close <N>`** — a lock the lane cannot build is a person's to fix |
+| `lane:open` reports a reused `<N>-lane` on stderr | The way back to a child parked after it pushed — **a reused branch is not a fresh lane** |
+
+**Nothing switches the lane's branch.** In a lane `lane:open`'s answer replaces `pnpm josh run:hold`'s
+preflight, and the child claims `run:hold` inside the lane, keyed on its own git directory.
 
 ### Handing the child over
 
@@ -200,14 +117,11 @@ The bullets below describe that dispatch:
   `.claude/settings.json` to decide; a headless child reaches `gh` and merges through `pnpm josh
   followup` without the flag, and the run reports what stopped rather than loosening it.
 
-**Start each child without blocking on it, and poll them all.** That is `backlogrun-child.md` → "A
-delegated unit that stopped without reporting" applied N times, and `pnpm josh run:liveness <N>
---output <path> --process alive` is read **in that child's lane**. **Run
-`pgrep -laf "(fullrun|run-ship-cli\.ts .*) #<N>$"` first and pass what it found** — `alive` where the
-child is there, `none` where it is not, and never `alive` merely because the child was dispatched. The
-command line carries no path; the `$` anchor keeps `#12` from matching a running `#123`.
+**Start each child without blocking on it, and poll them all** — a silent one is
+`backlogrun-recovery.md` → "A delegated unit that stopped without reporting", read in that child's
+lane.
 
-**`git switch main && git pull` is the parent's now, not the child's.** No lane can switch to the
+**`pnpm josh ms` is the parent's now, not the child's.** No lane can switch to the
 default branch, so the refresh moves to the primary checkout **before each `lane:open`** — the ref the
 lane is cut from.
 

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

@@ -3,9 +3,9 @@
 **Read this file in full when a child cannot finish** — before parking it, before a
 `needs-human-review` stop, or before recording a mid-run prerequisite or split. It is a point-of-use
 document, never an entry read: the entry procedure is `backlogrun.md`, which points here at that
-moment (joshuafolkken/kit#2010). This file is the single source of park-and-continue, the
+moment. This file is the single source of park-and-continue, the
 `needs-human-review` stop, a stale `in-progress`, a prerequisite discovered mid-run, and a mid-run
-split.
+split. Provenance of each rule: `docs/maintainers/backlogrun-park-rationale.md` → "Where each rule came from".
 
 ## What happens to a child that cannot finish
 
@@ -16,11 +16,9 @@ authorization, whether it came from a named epic or from the opted-in pool:
   and continue", which is that rule's single source, including what happens to the issue's lane.
 - **A prerequisite discovered mid-run is recorded as a dependency rather than parked** —
   → "A prerequisite discovered mid-run", and `prerequisite.md` for the three-way
-  distinction between a prerequisite, a split and an upstream defect. **One thing is genuinely
-  different**: with no epic, there is no `pnpm josh epic --add` to record the ordering into, so the
-  prerequisite is filed with `route:tier-a` and the blocked issue is parked with `needs-decision`
-  naming it. The parked issue returns to the pool when a person clears the label, and the
-  prerequisite is offered on the next ask if it carries `auto-ok`.
+  distinction between a prerequisite, a split and an upstream defect. With no epic there is no
+  `pnpm josh epic --add` to record the ordering into, so the `blocked-by` relation is written on the
+  issue itself (step 3 below) — still a dependency, never a `needs-decision` park.
 - **A split found mid-run** files the children and the epic and does not stop the batch, because the
   keyword already authorized a batch — `split-assessment.md` for the assessment, → "Splitting a child
   mid-run" for the branch. The split child is not parked or counted as a failure; its new children
@@ -28,15 +26,15 @@ authorization, whether it came from a named epic or from the opted-in pool:
 - **`in-progress` left behind by an interrupted run** is → "`in-progress` is removed by
   whoever finds it stale".
 - **A child released from `needs-decision` is re-dispatched to a lane, never implemented by the
-  parent.** The parent is an orchestrator: → "The parent orchestrates and never
-  implements a child in its own context" is the single source, and → "Removing the label
-  is Tier A" carries the re-dispatch itself. A released child takes a lane exactly as any batch child
+  parent.** The parent is an orchestrator: `backlogrun.md` → "Claim nothing at the entry — this
+  parent orchestrates and never implements" is the single source, and "Removing the label
+  is Tier A" below carries the re-dispatch itself. A released child takes a lane exactly as any batch child
   does.
 
 ## The parent does not investigate a lane failure itself
 
 **A lane failure whose reason is not on its Issue is read by a unit** — `pnpm josh delegate
-lane-failure-investigation` (joshuafolkken/kit#2947); the parent checks the cited lines and
+lane-failure-investigation`; the parent checks the cited lines and
 `pnpm josh issue:state` before it parks, re-dispatches or files.
 
 ## `needs-human-review` — the one stop that is not a park
@@ -46,17 +44,14 @@ there** — implementation and the verification gate run, nothing is committed,
 dirty and unstashed, a `confirmation` Telegram carrying the resume command goes out, and the remaining
 children are not started.
 
-**This is the exception to park-and-continue below, and it is not an oversight.** Parking works because
-the parked child leaves the checkout clean; this child does not. Its uncommitted work is the artifact a
-person has to look at — which is why the alternative that kept the batch running (commit, open a PR,
-merge nothing) was rejected: it satisfies "a person approves publication" and fails "a person chooses".
+**This is the exception to park-and-continue below** — rationale:
+`docs/maintainers/backlogrun-park-rationale.md` → "Why `needs-human-review` ends the run instead of parking".
 
 **The child goes on holding its repository.** `needs-decision` outranks `in-progress` in the
 per-repository exclusion so a parked child releases the checkout; this label deliberately does not,
 because releasing it would start the next child on top of uncommitted work. **Its lane is left open and
-untouched**, for the same reason. **Name the lane directory in the stop report and in the Telegram** — a
-person told to look at a working tree and not told which one has been told nothing. The lanes already in
-flight finish; no new lane is opened.
+untouched**, for the same reason. **Name the lane directory in the stop report and in the Telegram.** The lanes
+already in flight finish; no new lane is opened.
 
 **Never apply or remove the label** — a person's alone. Full definition and the
 `needs-decision` comparison: `needs-human-review.md`, which is the single source.
@@ -75,37 +70,25 @@ pnpm josh issue:comment <N> --body-file <path>   # what needs deciding, and the
 `needs-decision` precedence over `in-progress`, so the next child is offered normally. Then return to
 step 1; the other children are unaffected unless they depend on this one.
 
-**A parked child's lane is kept, whether or not it had committed.** **Parked before its commit**, the
-uncommitted work stays in the lane's tree — never in the stash, which every work tree shares — and
-`lane:close` would remove it by force. **Parked after its commit and push**, closing would delete the
-local branch the resume needs. **A lost merge race is not one of
-these rows** — it resolves in its lane (`backlogrun-recovery.md` → "Conflicts are not predicted"), and parks only under that
-section's four conditions, which take the after-commit row. Both rows and the `pnpm josh run:release
-<N>` every parked ending owes are "What happens to a lane" above, the single source.
+**A parked child's lane is kept, whether or not it had committed**, and every parked ending owes
+`pnpm josh run:release <N>` — `backlogrun-lanes.md` → "What happens to a lane", the single source. A
+lost merge race resolves in its lane instead (`backlogrun-recovery.md` → "Conflicts are not predicted").
 
-**Parking replaces stopping the session, not the rule that produced the stop.** An upstream defect is
-still filed immediately and unconditionally (Tier A for a first-party target), and a workaround is still
-forbidden. **A placement choice is not one of the things this run may not decide.** `epic:bundle`'s
-`ask` is Tier A: choose the epic you recommend, add it with `pnpm josh epic --add <E> <N> --after <M>`,
-and record the decision on both the new Issue and that epic's `## Decisions`. What remains a park is a
-genuine toss-up between two equally apt epics, and that is rare.
+**Parking replaces stopping the session, not the rule that produced the stop** — an upstream defect is
+still filed at once, and a workaround is still forbidden. `epic:bundle`'s `ask` is Tier A, not a park:
+add the epic you recommend with `pnpm josh epic --add <E> <N> --after <M>` and record it on both
+Issues' `## Decisions`.
 
-**Removing the label is Tier A — do it without asking.** When the decision is recorded (to the epic's
-`## Decisions`), remove the label; the state is on GitHub, so the run picks up where it left off.
+**Removing the label is Tier A — do it without asking**, once the decision is recorded; without it the
+parked child never runs again:
 
 ```bash
 gh api -X DELETE repos/{owner}/{repo}/issues/<N>/labels/needs-decision 2>/dev/null || true
 ```
 
-**The released child goes back to a lane, never into the parent's own context.** A parent that is
-*already* running, and clears a label mid-run because a person just answered, dispatches it the same way
-rather than picking up its diff itself — `pnpm josh lane:launch <N>`, which dispatches into the lane the
-park kept, or opens one where none is. A
-parent that implements the released child inline is the failure the orchestrator rule is written against:
-"The parent orchestrates and never implements a child in its own context" above.
-
-Without removing the label the parked child never runs again — it is the second half of the
-human-in-the-loop cycle, not an optional tidy-up.
+**The released child goes back to a lane, never into the parent's own context** — `pnpm josh
+lane:launch <N>` (`backlogrun.md` → "Claim nothing at the entry — this parent orchestrates and never
+implements").
 
 ## Only a person's judgement carries `needs-decision`
 
@@ -123,10 +106,10 @@ It never carries:
 - a defect in the running repository's own run tooling — the run fixes it and resumes
   (`prompts/collaboration-workflow/upstream-interrupt.md` → "実行中のリポジトリ自身のラン機構の不具合").
 
-**When in doubt, it is Tier A**: decide, comment the decision, and continue. A label a person has to
-clear for nothing spends their attention and stalls the child. **A label a mechanical step applied** — a
+**When in doubt, it is Tier A**: decide, comment the decision, and continue. **A label a mechanical step applied** — a
 failed or abandoned child, a lost merge race's four conditions — is read against this list once its
-reason is known, and removed (Tier A, above) when the reason is not on it.
+reason is known, and removed (Tier A, above) when the reason is not on it. Rationale:
+`docs/maintainers/backlogrun-park-rationale.md` → "Why a run spends no attention on a non-finding".
 
 ## `in-progress` is removed by whoever finds it stale
 
@@ -150,9 +133,7 @@ start a second child on top of that work.
 
 **A closed issue's labels are neither a finding nor something to clean up.** A closed issue holds no lane
 (`epic-busy.ts` counts holders from the open listing alone) and `epic:next` never offers it, so
-`in-progress` left behind on one changes nothing. **Do not report it, and do not strip it** — a report is
-read as something that needs attention, so a run that lists non-findings is a run whose real findings are
-harder to see.
+`in-progress` left behind on one changes nothing. **Do not report it, and do not strip it.**
 
 ```bash
 gh api -X DELETE repos/{owner}/{repo}/issues/<N>/labels/in-progress 2>/dev/null || true
@@ -170,7 +151,7 @@ source; what follows is this entry's branch.
 1. File the prerequisite Issue `<N>` with the `route:tier-a` label — Tier A for a first-party
    repository, no confirmation. It is filed **first** because the next step names it.
 2. **Stash the work in progress.** A child is implemented on the default branch with an uncommitted tree,
-   so `<M>`'s half-finished edits are sitting there, and the next child's `git switch main && git pull`
+   so `<M>`'s half-finished edits are sitting there, and the next child's `pnpm josh ms`
    would refuse or carry them into the prerequisite's branch and PR.
 
    ```bash
@@ -181,22 +162,24 @@ source; what follows is this entry's branch.
    **`-u` is not optional** (a new `*.test.ts` is untracked). The comment makes the paused state
    auditable and tells the session that resumes `<M>` a stash is waiting. **Pop it by message, never by
    position** — `pnpm josh stash:pop "backlogrun: paused #<M> for prerequisite #<N>"` — when `epic:next`
-   offers `<M>` again, after its `git switch main && git pull`. The stash is a repository-wide stack
+   offers `<M>` again, after its `pnpm josh ms`. The stash is a repository-wide stack
    every lane shares, so a bare `git stash pop` would take whichever lane last pushed; the message
    targets this one. The prerequisite has merged by then, so expect to resolve conflicts.
 
 3. `pnpm josh epic --add <E> <N> --before <M>` — one command writes the task-list row, the declaration
    and the `blocked-by` relation together. Never edit the body by hand: the declaration and the relations
    then disagree, `epic:next` returns `error`, and the unattended run stops.
+   **With no epic** (a pool child), record the relation alone, `<M>` blocked by `<N>`, with the
+   `gh api …/dependencies/blocked_by` call in `prompts/collaboration-workflow/issue-template.md` →
+   "複数 Issue に分割するときの epic Issue", step 4.
 4. **Remove `in-progress` from `<M>`** — `pnpm josh run:release <M>`, which removes the label with the hold.
    This is what lets `<M>` run again: `epic:next` classifies a child carrying `in-progress` as waiting on
    time **before** it looks at any blocker, so a child left labelled is never offered again.
 5. **Do not park.** Go back to step 1 of the loop. `epic:next` classifies the original child as resolving
    on its own and hands back the prerequisite first, so the order is kept with no human input.
 
-**Parking is only for a prerequisite that cannot be expressed as a dependency** — one that needs a design
-decision nobody has made, or that is a Tier B toss-up or a Tier C action. Parking one that *can* be
-expressed inverts the whole point: `needs-decision` is cleared by a person.
+**A stop a dependency can express is never parked**, and a defect in this repository's own gate or run
+tooling is such a stop — `prerequisite.md` holds that rule and what the driver does with it.
 
 ## Splitting a child mid-run