@joshuafolkken/kit 1.1471.0 → 1.1784.0

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

@@ -4,18 +4,22 @@
   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>"`.
+  2. Derive a clear English 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>` →
+  4. **Record the plan** — written to a file in the session language (`JOSH_SESSION_LANG`, default
+     `ja`), then `pnpm josh issue:plan <N> --body-file <path> --title "<title>" --planned`: it renames
+     the issue, fills a blank body or comments otherwise, and applies `run:planned`, so the next
+     command's `run:entry` starts at the implementation. A target named in front of the reference
+     adds `--repo <owner/name>`. Before writing the plan, run `pnpm josh plan:consumers
+     <identifier...>` on what it adds or changes and finish the `### 影響を受ける既存の利用者` draft it
+     prints; `issue:plan` refuses a plan without it (`docs/josh-commands-backlog.md` → "`josh issue:plan`").
+  5. 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>
+  **Two or more separately-mergeable deliverables** take the split path instead of a plan: rename `#N`
+  to the step-2 title (`gh api -X PATCH repos/{owner}/{repo}/issues/<N> -f title="<title>"` — neither
+  `issue:plan` nor `epic --promote` runs here to apply it), 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.
@@ -41,13 +45,13 @@ gate must hold **together**. The rest of `split-assessment.md` is read when a sp
 - `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
+    "<title>" --body-file <body-file>` 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
+    <body-file> --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
@@ -57,19 +61,13 @@ gate must hold **together**. The rest of `split-assessment.md` is read when a sp
     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
+  **The epic itself is never implemented** — `backlogrun` runs its *children*, and it closes itself
+  once every child is closed, whichever josh path closes the last one. 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.
 
-  **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.
+  Without `josh`: `issue-template.md` → "複数 Issue に分割するときの epic Issue".
 
 `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.
@@ -83,7 +81,10 @@ An Issue a consumer can use only once it is published is filed with `--release`
 **Words after `new`** (`kickoff new high`) are read like `into <target>`, never inferred. Each adds its
 labels to the filing; a word not in the table is asked about:
 
-| Typed     | Added to `pnpm josh issue:file` |
-| --------- | ------------------------------- |
+| Typed      | Added to `pnpm josh issue:file` |
+| ---------- | ------------------------------- |
 | `auto ok` | nothing — `issue:file` judges it |
-| `high`    | `--label priority:high`         |
+| `critical` | `--label priority:critical`     |
+| `high`     | `--label priority:high`         |
+
+A typed priority wins: `issue:file` then skips the body's `- 優先度:` judgement (`scripts/issue/issue-priority.ts`).

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
 
@@ -28,26 +26,21 @@ judgement that the dependencies are probably still fresh.
 ## What runs when the answer is `required`
 
 ```bash
-git stash push -u -m "josh latest"    # only if the working tree has staged or modified files
-pnpm josh ms
-pnpm josh latest     # on `required` only
-pnpm josh stash:pop "josh latest"     # only if you stashed above — by message, never a positional pop
+pnpm josh latest:if-required   # stash → josh latest → pop by message; nothing on `skip`
 ```
 
-**The pop is by message, never a bare `git stash pop`** — the stash is a repository-wide stack every
-work tree shares.
+It asks `latest:scope` itself, so a run reads `run:prep`'s `latest:` line and never asks again. A
+failed update or a conflicted pop stops with the stash kept and names the pop to run.
 
 Then **load the `dependency-update` skill and follow its procedure** — the overrides in **both**
 `pnpm-workspace.yaml` and `package.json`, and the one expected `devEngines` pnpm bump — in every run in
 which `josh latest` actually ran; never report the pins intact without having run it.
 
-**On `skip`, one line of that block goes away and no more.** `pnpm josh latest` does not run, and
-the `dependency-update` skill is not read, because nothing rewrote a pin for it to check.
+**On `skip`, the command does nothing** and the `dependency-update` skill is not read, because
+nothing rewrote a pin for it to check.
 
-**Two of those steps are not this gate's, and making either conditional breaks something.**
-`pnpm josh ms` runs per issue and per child either way — it brings the previous merge into the tree.
-The stash before it is the branch switch's, not the update's, so it is conditional on the **tree**,
-never on the answer.
+**`pnpm josh ms` is not this gate's** — it runs per issue and per child either way, bringing the
+previous merge into the tree, before the update.
 
 ## The vulnerability net is not what moved
 
@@ -59,8 +52,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**.
@@ -10,18 +8,18 @@ point reached it — `fullrun` or `backlogrun` — and the label may be applied
 - **Implementation and the verification gate run normally** — refactor, `pnpm josh gate`,
   `/code-review`, exactly as for any other child.
 - **Run `pnpm josh test:e2e` yourself before stopping.** With no pull request there is no CI E2E job,
-  and `pnpm josh followup` is never reached. This is `halfrun`'s situation exactly: you run it and read
-  what it prints. A printed skip is the answer for a project with no E2E suite; a skip nobody saw
-  printed is not.
+  and `pnpm josh followup` is never reached. A printed skip is the answer for a project with no E2E
+  suite.
 - **Nothing is committed, pushed, opened as a pull request or merged.** `pnpm josh bump`,
   `pnpm josh git` and `pnpm josh followup` are never reached.
 - **The working tree is left uncommitted, and nothing is stashed.**
-- **Send a `confirmation` Telegram and stop the whole run.** The remaining children are not started —
-  inside a `backlogrun` this is the one thing that is *not* park-and-continue.
-- The Telegram body carries the **resume command**, in the same form `halfrun`'s own stop uses.
+- **Mark the stop: `pnpm josh run:hold <N> --human-review-stop`, then stop the whole run.** It keeps
+  the hold, marks it as `halfrun`'s stop, and sends the `confirmation` Telegram with the resume command
+  and the lane directory — never compose one. It answers `e2e-owed` until `test:e2e` answered green on
+  this tree. The remaining children are not started — inside a `backlogrun` this is the one thing that
+  is *not* park-and-continue.
 - **Resuming is `halfrun`'s stop exactly**: a person looks at the working tree and, if it is right,
-  carries on from the commit themselves. The stop report carries that resume command too, not only the
-  Telegram.
+  carries on from the commit themselves. The stop report carries the resume command too.
 
 **Stopping is the specification, not a failure.**
 
@@ -36,18 +34,12 @@ pnpm josh issue:state <N> --repo <owner/repo>  # a child in another repository
 
 **Never apply or remove it**: a mark a run can clear for itself is
 not a mark. Everything but typing the command on an explicit instruction in the current turn is a
-proposal, written as an Issue comment and left for the person. The label itself is created once per
-repository, by a person:
-
-```bash
-gh api repos/{owner}/{repo}/labels -f name=needs-human-review -f color=d93f0b -f description="Implement and verify, but stop before committing so a person can look"
-```
+proposal, written as an Issue comment and left for the person. `josh sync` creates the label.
 
 **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.

package/.claude/skills/workflow-commands/observation-filing.md

@@ -23,12 +23,13 @@ report. Drop an observation nobody would act on.
 `pnpm josh run:event --append note "#<N> <text>"`, shown by `pnpm josh run:board`
 (`docs/josh-commands-run.md` → "`josh run:board`").
 
-**The filing ceilings still apply.** Count it in the run's ten-Issue limit; above the target
+**The filing ceilings still apply.** It counts toward the per-run cap (`prerequisite.md`); above the target
 repository's WIP cap, close one first or do not file (`prompts/collaboration-workflow/wip-cap.md`).
 File with `pnpm josh issue:file` (`issue-scout.md`): it lints the body, applies the classification
 labels, scans for duplicates and runs `epic:bundle` (an `auto-ok` epic adds it to the backlog pool —
 `backlogrun-steps.md` → "What one invocation approves"). On the second filing of the run it asks the fold
 question and holds a `fold` (`split-assessment.md` → "The same two questions decide the filing-time fold").
+A bug filing's origin line: `prompts/collaboration-workflow/issue-template.md` (`- 原因:`).
 
 ### The depth test — a discretionary filing cites the product work it blocked
 
@@ -40,26 +41,7 @@ question and holds a `fold` (`split-assessment.md` → "The same two questions d
 | **1** | The run orchestration that executes an Issue | `fullrun` / `backlogrun`, lanes, the `epic:*` commands, the filing routes themselves |
 | **2** | What measures a run | `josh cost` and the run-timing report |
 
-**The depth is recorded on the Issue as a label, and the label is applied when the Issue is filed.**
-`depth:0` / `depth:1` / `depth:2` are defined in `scripts/issue/issue-labels.ts` with no definition of
-their own — **the table above is the single source**. **Every filing route applies one**: each route
-of `prerequisite.md`'s table, a split child and a review branch-2 filing pass `--depth <n>` to
-`pnpm josh issue:file`, beside any `--route`.
-
-```bash
-pnpm josh issue:file "<title>" --body-file <body-file> --depth 1
-gh api repos/{owner}/{repo}/issues/<N>/labels -f 'labels[]=depth:1'   # an Issue already filed
-```
-
-`issue:file` creates any missing workflow label from `DEPTH_LABELS` before the create call.
-
-- **It is read off the subject, exactly as the table is** — not a judgement, unlike `auto-ok` and
-  `needs-human-review`; it withholds nothing.
-- **Applied at filing, not at completion.**
-- **An Issue carrying more than one counts as the lowest depth present.**
-- **An `epic` takes no depth label** and is excluded from the share's denominator.
-
-Rationale: `docs/maintainers/observation-filing-rationale.md` → "Why the depth label is applied at filing".
+**The depth is read, not recorded** — no label carries it.
 
 - **A discretionary observation at depth 1 or deeper is filed only where it can cite the depth-0 work
   it stopped or delayed** — an Issue number or a run, never "this would slow runs down". **Cannot cite
@@ -74,35 +56,14 @@ Rationale: `docs/maintainers/observation-filing-rationale.md` → "Why the depth
   - **Cannot write both, it is not filed** — it goes to the ledger.
 - **This narrows depth 2 alone, and the exemptions above carry over unchanged.**
 
-Rationale: `docs/maintainers/observation-filing-rationale.md` → "Why depth gates a discretionary filing".
-
 **It governs this route only — the fourth row of `prerequisite.md`'s table.** A review finding routed
 to branch 2 of `prompts/review.md` → "Review round cap" is filed under that section's own bar and
 **does not take the depth test**. **That bar is the reason, and the subject's depth is not.**
-Rationale: `docs/maintainers/observation-filing-rationale.md` → "Why a review branch-2 filing skips the depth test".
 
 **And a PR that *adds* a measurement names its reader in the same way** — the Issue that read the value
 to decide something, or the path of the rule that reads it. **A measurement with no reader is not
 added.** `route:tier-a` and `route:interrupt` carry over unchanged.
 
-### The depth-0 share — what is counted
-
-**The depth-0 share is the share of open Issues at depth 0.**
-
-**The denominator is a rule, not a choice, and this is it:**
-
-- **Counted: every open Issue that does not carry `epic`.**
-- **`route:tier-a` and `route:interrupt` are counted like anything else.**
-- **An Issue with no depth label is in the denominator**, counted separately as `unlabelled`.
-- **The numerator is what is left**: open, non-epic Issues carrying `depth:0`.
-
-**Two readings of the same backlog give the same number.**
-
-Rationale: `docs/maintainers/observation-filing-rationale.md` → "Why the depth-0 denominator is fixed".
-
-**What the number is for is not decided here** — no `backlog:next` change and no target value until it
-has been measured the same way more than once.
-
 ### A delegated child does not take this route
 
 **A delegated child files `route:tier-a` and `route:interrupt` only.** Its discretionary observations
@@ -111,13 +72,6 @@ summary carries, and how long it may be"); the parent files what survives the de
 run's ceiling.
 
 **A delegated child does not append to the ledger either — the parent collapses the duplicates and
-appends what is left.** **The 10-per-run ceiling for this route is the parent's to count.** **Lines
+appends what is left.** **Lines
 its own `review:record` and `measure:rerun` write are not this route** — they go to its issue's file in
 its lane (`observation-ledger.md` → "The ledger — where an observation that cannot cite a blockage goes").
-
-Rationale: `docs/maintainers/observation-filing-rationale.md` → "Why a delegated child neither files nor appends".
-
-**This file is the single source of every procedure above**; nothing under
-`prompts/collaboration-workflow/` restates it.
-
-Provenance: `docs/maintainers/observation-filing-rationale.md` → "Where each rule came from".

package/.claude/skills/workflow-commands/observation-ledger.md

@@ -1,14 +1,11 @@
 # The observation ledger — grammar, commit path and promotion
 
 **Read only when the depth test in `observation-filing.md` turns an observation away, or a user
-reports a bug** (its kind of miss, below), in the turn that appends the line. Single source of the
-ledger's grammar, commit path and second-sighting promotion. Provenance:
-`docs/maintainers/observation-ledger-rationale.md` → "Where each rule came from".
+reports a bug** (its kind of miss, below), in the turn that appends the line.
 
 ## The ledger — where an observation that cannot cite a blockage goes
 
-**An observation the depth test turns away is recorded in the ledger, not discarded.** Rationale:
-`docs/maintainers/observation-ledger-rationale.md` → "Why the ledger exists".
+**An observation the depth test turns away is recorded in the ledger, not discarded.**
 
 - **The destination is the `.josh/observations/` directory in the repository the observation is
   about**, **one file per issue**: `<N>.md` for the issue the run is executing (its branch's number,
@@ -60,8 +57,7 @@ blocked depth-0 work is filed as before.
 
 ## The commit path — how an appended line reaches the default branch
 
-**An append nobody commits is an append nobody can count.** Rationale:
-`docs/maintainers/observation-ledger-rationale.md` → "Why the ledger has a commit path".
+**An append nobody commits is an append nobody can count.**
 
 - **A run's appended lines ride its own commit** — `pnpm josh git` stages `.josh/observations/`
   (`scripts/git/git-staging.ts`). **Record before the commit, not after the merge:** a finding recorded
@@ -87,13 +83,12 @@ blocked depth-0 work is filed as before.
 
 ## The second sighting is what files it
 
-**A repeat is the citation** — counted, not judged (`docs/maintainers/observation-ledger-rationale.md`
-→ "Why a second sighting files"):
+**A repeat is the citation** — counted, not judged:
 
 - **On `observation:record` answering `file`, the observation is filed**, at depth 1 or deeper, with
   no depth-0 citation (only when exactly one earlier sighting exists).
 - **The Issue quotes the ledger's own dates — the first sighting's and this one's.**
-- **Both ceilings still apply** (`observation-filing.md`): the 10-per-run cap and the WIP cap.
+- **Both ceilings still apply** (`observation-filing.md`): the per-run filing cap and the WIP cap.
 
 **A third and later sighting appends a line and files nothing more** — `pnpm josh issue:scout` finds
 the open Issue.

package/.claude/skills/workflow-commands/pre-gate-cut.md

@@ -2,9 +2,9 @@
 
 The **pre-gate cut**: a dispatched lane child ends its process the moment implementation is done, and a
 **fresh** process resumes the same lane from the gate onward, without the implementation's accumulated
-context. Rationale: `docs/maintainers/pre-gate-cut-rationale.md` → "Why the cut exists".
+context.
 
-This file is the single source of the boundary: `run:cut` takes it, `run:cut --resume` is the fresh
+`run:cut` takes the boundary, `run:cut --resume` is the fresh
 process's entry check. A second boundary — the implementation-phase cut, _during_ implementation — is
 below; it states only what differs.
 
@@ -17,20 +17,12 @@ the fallback.
 ## It applies to a dispatched lane child, and to nothing else
 
 A person's interactive `fullrun` never relaunches itself. A dispatched child is told apart
-**mechanically, by a mark the dispatch sets** — never by reading its own prompt.
+**mechanically, by the `JOSH_LANE_CHILD` mark the dispatch sets** — never by reading its own prompt
+(`docs/josh-commands-run.md` → "`josh run:cut`").
 
-### The dispatch mark
-
-`lane:dispatch` starts each child generation with **`JOSH_LANE_CHILD`** set to the lane's issue number
-(`scripts/lane/lane-child-marker.ts`).
-
-- **Meaning**: "this session was launched for issue `<N>`, not typed by a person."
-- **Lifetime**: the child process — set at launch, never written by the run itself.
-- **Trust**: only where its value equals the lane's own issue; a leaked mark naming another issue, or
-  none, is read as a person. An interactive `fullrun` carries no mark.
-
-The name, meaning and lifetime are documented here and nowhere else. `run:cut` itself looks for an
-**open lane** for the issue instead (`not-a-lane` otherwise), so it is safe to issue unconditionally.
+An interactive `fullrun` carries no mark, and every
+guard in this file holds that boundary: **It fires for a marked child and nowhere else**. `run:cut`
+answers `not-a-lane` outside a lane, so it is safe to issue unconditionally.
 
 ## Taking the cut
 
@@ -54,20 +46,9 @@ pnpm josh run:cut <N>
 
 ### The gate refuses until the cut has been taken
 
-`pnpm josh rule:guard` **refuses `pnpm josh gate`** in a lane with no cut record carried, handing back
-the command above. Rationale: `docs/maintainers/pre-gate-cut-rationale.md` → "Why the rules are
-guards, not prose".
-
-- **It fires for a marked child and nowhere else**: the working directory is `<lane root>/<issue
-  number>` **and** `JOSH_LANE_CHILD` names that issue. `run:cut` uses an open-lane lookup instead, so
-  the guard and the command need not agree byte for byte.
-- **It fires only when the current context warrants a cut** (`cost_cli.session_verdict`, as `run:cut`).
-- **It is silent once the cut is carried**.
-- **It fires once per run.**
-- **`--resume`, `--end` and `--json` do not count as taking the cut.**
-
-Its row: `prompts/collaboration-workflow/rule-delivery.md`. Suites: `docs/maintainers/pre-gate-cut-rationale.md`
-→ "Which suites pin each guard".
+The `pre-gate-cut` row of `pnpm josh rule:list` **refuses `pnpm josh gate`** in a lane with no cut record carried, handing back
+the command above — run it. When the guard fires: `docs/josh-commands-run.md` → "`josh run:cut`"; its
+row: `prompts/collaboration-workflow/rule-delivery.md`.
 
 ## Resuming — the fresh process's entry check
 
@@ -92,8 +73,7 @@ pnpm josh run:cut --resume <N>
 ### The stage is passed to the resumed child, not reconstructed by it
 
 **Skip the entry it has already done**: do not re-read the workflow skill, repeat the split assessment
-or re-normalize the title; the plan and decisions are read back from the issue. Rationale:
-`docs/maintainers/pre-gate-cut-rationale.md` → "Why the resume carries what it carries".
+or re-normalize the title; the plan and decisions are read back from the issue.
 
 ## What is carried, and what is not
 
@@ -124,24 +104,24 @@ Same `cost_verdict.per_request_cost` through `cost_cli.session_verdict` as `back
 
 ### It is a guard, fired at the edit that crosses the threshold
 
-**The trigger**: `pnpm josh rule:guard` refuses an `Edit` / `Write` in a dispatched lane child over
+**The trigger**: the `implementation-cut` row of `pnpm josh rule:list` refuses an `Edit` / `Write` in a dispatched lane child over
 threshold, handing back `pnpm josh run:cut --impl <N> --handoff <path>`. `cut` ends the turn; the
 fresh process's `run:cut --resume <N>` answers `resume-impl` — **the implementation resume clears the
-record**, so the cut may fire again. **A cut that relaunches its successor owes no Telegram**. Outside a
+record**, so the cut may fire again. **A cut that relaunches its successor owes no Telegram** — the
+`Stop` hook reads the relaunch off the turn's own `run:cut` output, not off the record the resume
+clears. Outside a
 lane, `run:cut --impl` prints the held run's instruction: on `over`, keep the hold, send a
 `confirmation` Telegram naming `fullrun #<N>`, end the turn. **It fires on every threshold crossing,
 not once per run**; **An edit reissued right after a refusal passes**; **An unmeasurable session
-warrants the cut**; **It is silent between a cut and its resume**. Rationale:
-`docs/maintainers/pre-gate-cut-rationale.md` → "Why the rules are guards, not prose"
-(`scripts/rules/implementation-cut.ts`). A child that ended without cutting is detected by
+warrants the cut**; **It is silent between a cut and its resume** (`scripts/rules/implementation-cut.ts`).
+A child that ended without cutting is detected by
 `pnpm josh run:ending <N> --output <path>`.
 
 ## The threshold
 
 `CONTEXT_CUT_THRESHOLD` and `cost_verdict.per_request_cost` live in
 `scripts/cost-runtime/context-cut-payback.ts`; both cuts and the parent hand-off read the same verdict,
-and an unmeasurable session is always cut. Rationale: `docs/maintainers/pre-gate-cut-rationale.md` →
-"Why the threshold is a break-even". Both cuts end the turn **before** the gate, so the push is never a
+and an unmeasurable session is always cut. Both cuts end the turn **before** the gate, so the push is never a
 turn boundary (`chain-rule.md`).
 
 ## A lane child records its park before it stops
@@ -149,18 +129,16 @@ turn boundary (`chain-rule.md`).
 **The trigger**: a dispatched lane child about to stop for a decision (Tier B, Tier C, an upstream
 defect) parks its own Issue first — `backlogrun-park.md` → "park and continue" — so `pnpm josh
 run:liveness` reads it `settled`. A `needs-human-review` or `already-done` stop already carries its
-label. `pnpm josh rule:guard` refuses `pnpm josh notify --task-type confirmation` from a marked child
-until then — **It fires once per run.** (`scripts/rules/lane-park.ts`).
+label. The `lane-park` row of `pnpm josh rule:list` refuses `pnpm josh notify --task-type confirmation` from a marked child
+until `pnpm josh run:park` has recorded the park — **It fires once per run.** (`scripts/rules/lane-park.ts`).
 
 **A split is not a park**: a child that promoted its Issue to an `epic` stops without
-`needs-decision` — `backlogrun-park.md` → "Splitting a child mid-run". `pnpm josh rule:guard` refuses a
+`needs-decision` — `backlogrun-park.md` → "Splitting a child mid-run". The `lane-split-park` row of `pnpm josh rule:list` refuses a
 `needs-decision` write onto that epic, on every occurrence (`scripts/rules/lane-split-park.ts`).
 
 ### The interactive ask is refused one call earlier
 
 **The trigger**: a headless session ends the turn on an interactive ask, so the notify guard never
-fires; `pnpm josh rule:guard` refuses `AskUserQuestion` for a marked lane child on every occurrence — park the question instead.
+fires; the `lane-interactive-ask` row of `pnpm josh rule:list` refuses `AskUserQuestion` for a marked lane child on every occurrence — park the question instead.
 `pnpm josh run:ending` lifts a slipped ask into the park basis (`scripts/rules/lane-interactive-ask.ts`,
 `scripts/agent/interactive-ask.ts`).
-
-Provenance of each rule: `docs/maintainers/pre-gate-cut-rationale.md` → "Where each rule came from".

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

@@ -1,8 +1,7 @@
 # A prerequisite discovered mid-run — a dependency, not a park
 
 **The single source of the prerequisite branch**, read at its point of use — the moment a run
-discovers that another Issue in this repository has to land first. History:
-`docs/maintainers/prerequisite-rationale.md` → "Where each rule came from".
+discovers that another Issue in this repository has to land first.
 
 **A prerequisite discovered mid-run is a dependency, not a park** — the Issue in hand is still one
 deliverable, it just needs another one before it.
@@ -30,7 +29,7 @@ offer hands it back once its blockers merge.
 
 **A wait for the next published release is a dependency too** — never `needs-decision`. Record it
 with `pnpm josh issue:release <M> --wait` (`<M>` blocked by the release Issue, filed when none is
-open), then stash, comment and `pnpm josh run:release <M>` as for a prerequisite below; `fullrun` /
+open), then `pnpm josh run:pause <M> --for <the release Issue>` as for a prerequisite below; `fullrun` /
 `halfrun` stop, `backlogrun` continues. Closing the release Issue once a person has published it hands
 `<M>` back to `backlog:next` (`docs/josh-commands-backlog.md` → `josh issue:release`).
 
@@ -38,7 +37,7 @@ open), then stash, comment and `pnpm josh run:release <M>` as for a prerequisite
 so the observation row carries no `route:` label (`observation-filing.md`):
 
 ```bash
-pnpm josh issue:file "<title>" --body-file <body-file> --depth <n> --route tier-a
+pnpm josh issue:file "<title>" --body-file <body-file> --route tier-a
 ```
 
 The command lints the body against `prompts/collaboration-workflow/issue-template.md`, applies the
@@ -51,24 +50,18 @@ later steps name its number. **Its duplicate scan is read exactly as it is for a
 
 **Each entry point's own branch stays in that entry's file:**
 
-- **A named epic under `backlogrun`** files without confirmation, records the dependency with
-  `pnpm josh epic --add <E> <N> --before <M>` — `<E>` the epic, `<N>` the prerequisite just filed,
-  `<M>` the child in hand — and the run **continues rather than parking it** (`backlogrun-park.md` → "A
-  prerequisite discovered mid-run"). A child outside any epic records the same relation on itself
-  directly; that branch is the same section's.
+- **A named epic under `backlogrun`** files without confirmation, sets `<M>` — the child in hand —
+  aside with `run:pause` below, and the run **continues rather than parking it** (`backlogrun-park.md` →
+  "A prerequisite discovered mid-run").
 - **`fullrun` / `halfrun`** file the same way without asking, insert the prerequisite into the epic
   that already tracks the Issue or create one over both, and then **stop**, leaving the person one
   command to type (`fullrun.md` / `halfrun.md`). Typing `fullrun` approved implementing **one** Issue;
   a batch is a different authorization, so the stop stays.
 
-**Two steps every entry's procedure turns on:**
+**Once the prerequisite is filed, every entry sets `<M>` aside with `pnpm josh run:pause <M> --for <N>`**
+— the stash, the comment naming its `stash:pop`, the blocked-by and the release; a failure is rerun as
+is (`docs/josh-commands-run.md` → `josh run:pause`). Name the comment's pop in the Telegram too.
 
-- **`git stash push -u` — the `-u` is not optional.** The work in progress almost always includes a
-  new, untracked `*.test.ts`, which a stash without `-u` leaves for the next `pnpm josh ms` to refuse.
-- **The Issue comment is what gets the stash popped, not the Telegram.** The run that picks the Issue up
-  reads it and pops before implementing — **by message, `pnpm josh stash:pop "<the -m message>"`, never
-  a positional `git stash pop`** (the stack is shared by every lane). Say it in the Telegram too.
-
-**Automatic filing is capped at 10 Issues per run** at every entry point; `pnpm josh rule:guard`
-refuses the eleventh filing (`prompts/collaboration-workflow/rule-delivery.md`). On reaching it, stop
+**Automatic filing is capped at 10 Issues per run** at every entry point; the `filing-cap` row of
+`pnpm josh rule:list` refuses the eleventh filing (`prompts/collaboration-workflow/rule-delivery.md`). On reaching it, stop
 and report. `kickoff` is exempt — it never implements, so it never discovers one.

package/.claude/skills/workflow-commands/progress-watcher.md

@@ -40,7 +40,6 @@ silence clock (`docs/josh-commands-run.md` → "`josh run:progress`").
 `JOSH_PROGRESS_INTERVAL_MINUTES` moves both sides; `josh` → `progress_interval_minutes` in
 `package.json` sits one step below it. **`--interval` moves the watcher alone** — quieter, never the
 guard stricter.
-Rationale: `docs/maintainers/progress-watcher-rationale.md` → "Why the heartbeat reads as it does".
 
 ### What a report says
 
@@ -54,15 +53,14 @@ missing, say so. **A field's empty value is an observation, never a state** (`re
 
 **The heartbeat is ambient, never a Telegram.** `pnpm josh run:board` is its reader, in a pane of the
 person's own; **no session relays the stream** — name the board command once, at the first cut or when
-asked; `.vscode/tasks.json` starts it on folder open once VSCode's automatic-task prompt is allowed.
+asked; the person starts it, or the `josh: run board` task in `.vscode/tasks.json`, by hand.
 `pnpm josh run:event --watch` stays for following the raw events one by one. `pnpm josh run:wake --list` is the one-line read for a person who types for it.
 **A request for periodic progress is never a CronCreate job** — on screen, name `pnpm josh run:board`;
 off-screen, start `pnpm josh run:board --every <minutes>` in the background (`docs/josh-commands-run.md`).
 
 **A stop is the only interrupt**: a `backlogrun` that has stopped ends with
 `pnpm josh run:carry --end --stopped "<reason>"`, which sends one ⏸️ confirmation; a parked child sends
-its own (`backlogrun-park.md`). Rationale: `docs/maintainers/progress-watcher-rationale.md` → "Why the
-signal tiers are split this way".
+its own (`backlogrun-park.md`).
 
 ### Who starts it, and what counts as a report
 
@@ -85,7 +83,4 @@ tool result only you read is not one.** `--output` is omitted there, and `record
 **A run that merges needs no teardown; a run that stops has to end the reporting itself** — **no
 further `--wait` is started** after the stop notification, and the running one is stopped in the same
 turn: `halfrun`'s stop before commit, a `needs-human-review`, split or prerequisite stop, a
-`backlogrun` named issue's failure stop. Rationale: `docs/maintainers/progress-watcher-rationale.md` →
-"Why the watcher runs where it does".
-
-Provenance of each rule: `docs/maintainers/progress-watcher-rationale.md` → "Where each rule came from".
+`backlogrun` named issue's failure stop.

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

@@ -1,10 +1,8 @@
 # `prrun` — the manifest (plan → implement → PR → green → stop, a person merges)
 
-`prrun` sits between `halfrun` (stop before commit) and `fullrun` (auto-merge). It runs `fullrun`
-up to a green, mergeable pull request and **stops before the merge**, so a person merges by hand.
-**Read `fullrun.md` and `entry-sequence.md` for every step** — the entry
-sequence, the step lists, the gate, the review and the stop branches are `fullrun`'s, unchanged. This
-file names only the difference.
+`prrun` runs `fullrun` up to a green, mergeable pull request and **stops before the merge**, so a
+person merges by hand. **Read `fullrun.md` and `entry-sequence.md` for every step** — the entry
+sequence, the step lists, the gate, the review and the stop branches are `fullrun`'s, unchanged.
 
 ## The difference — the entry
 
@@ -22,13 +20,9 @@ Where `fullrun` runs `pnpm josh followup` and merges, `prrun` does three things
    review findings resolved. A failure stops the run exactly as it stops a `fullrun`.
 2. **Mark the stop — `pnpm josh run:hold <N> --prrun-stop`.** It records the commit the pull request is
    on in this run's own hold, the record `fullrun #<N>` adopts (its prrun resume, `working-tree-hold.md`). **The hold and `in-progress` stay**: the run is not finished until the merge's tail runs.
-3. **Send a `confirmation` Telegram with the resume commands, then stop.** **`fullrun #<N>` first** —
-   its `run:entry` reads where the pull request stands and resumes from there; the direct command
-   follows for finishing without an agent:
-   `pnpm josh notify --task-type confirmation --issue-url "<issue-url>" --body=$'prrun ready to
-   merge: <pr-url>\nNext: fullrun #<N>\nAfter a manual merge, without an agent: pnpm josh followup
-   "<title> #<N>"' --recommended "fullrun #<N>" --alternative "Merge by hand, then pnpm josh
-   followup"`. The stop report names the same two, in the same order.
+3. **Stop.** The mark has already sent the `confirmation` Telegram, its resume line `Next: fullrun
+   #<N>` — never compose one. The stop report names `fullrun #<N>` (recommended) and a manual merge followed by
+   `pnpm josh followup "<title> #<N>"`, in that order.
 
 **Invoking `prrun` is _not_ authorization to merge** — never run `pnpm josh followup` without
 `--no-merge` in a `prrun`. After a person merges by hand, the same `pnpm josh followup "<title> #<N>"`