@joshuafolkken/kit 1.1455.0 → 1.1514.0

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

@@ -1,215 +1,161 @@
 # The pre-gate cut — a lane child ends its turn before the gate
 
-A lane child is a detached `fullrun #<N>` process, and the thinking it accumulates while implementing
-rides on every later API call in the same session. The **pre-gate cut** drops that accumulation: the
-child ends its process the moment implementation is done, and a **fresh** process resumes the same lane
-from the gate onward. Rationale: `docs/maintainers/pre-gate-cut-rationale.md` → "Why the cut exists".
+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.
 
-This file is the single source of the boundary. `run:cut` takes it, and `run:cut --resume` is the
-check a fresh process makes at its own entry. **A second boundary is added below** — the
-implementation-phase cut, at a context threshold _during_ implementation.
-Everything through "What is carried" describes the pre-gate cut; the later section states only what
-differs.
+`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.
 
 ## Where the boundary is
 
-**After implementation and the refactor, before `pnpm josh gate`**: implementation complete, nothing
-committed, the gate not started. Everything after it (gate → review → commit → push → merge) is
-verification the fresh process runs on the tree.
-
-**A lane child first hands it to a detached supervisor** (`chain-rule.md` step 0); the cut is the fallback.
+**After implementation and the refactor, before `pnpm josh gate`**: nothing committed, the gate not
+started. **A lane child first hands it to a detached supervisor** (`chain-rule.md` step 0); the cut is
+the fallback.
 
 ## It applies to a dispatched lane child, and to nothing else
 
-The cut is for a **detached** `fullrun` a lane dispatched; a person's interactive `fullrun` never
-relaunches itself. A dispatched child is told apart **mechanically, by a mark the dispatch sets** — never
-by the model reading the shape of its own prompt.
+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.
 
 ### The dispatch mark
 
-`lane:dispatch` starts each child generation with the environment variable **`JOSH_LANE_CHILD`** set
-to the lane's issue number. `scripts/lane/lane-child-marker.ts` is its one definition.
+`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, read at the gate, never written by the run itself.
-- **Trust**: only where its value equals the lane's own issue. A mark that leaked in from a parent
-  session — naming another issue, or none — is read as a person, so a leak cannot make the guard fire
-  on a checkout it does not belong to.
-
-The name, meaning and lifetime are documented here and nowhere else.
+- **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.
 
-`run:cut` decides the same fact its own way: it looks for an **open lane** for the issue, answering a
-checkout with none `not-a-lane`. So the command is safe to issue unconditionally — a no-op in the main
-checkout, a cut in a lane.
+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.
 
 ## Taking the cut
 
-**The order is fixed in the chain**: `chain-rule.md` step 1 issues
-`pnpm josh run:cut <N>` after `pnpm josh main:merge`, before the scoped pair and the gate. **The command
-is issued unconditionally**; `run:cut` itself decides whether the cut is warranted, so a short lane with nothing to drop is answered `under-threshold` and walks on
-to the gate rather than relaunching.
-
-At the pre-gate boundary, issue:
+`chain-rule.md` step 1 issues it after `pnpm josh main:merge`, before the scoped pair and the gate —
+**unconditionally**:
 
 ```bash
 pnpm josh run:cut <N>
 ```
 
 - `cut` (0) — record written and handed to the lane's launch owner (OpenAI supervisor starts the
-  successor after this process exits; Anthropic relaunches directly). **End the turn immediately** —
-  the fresh process owns the run.
-- `under-threshold` (0) — the newest request's billed input is under the shared `CONTEXT_CUT_THRESHOLD`,
-  so nothing was cut; **continue to the gate.**
-- `not-a-lane` (0) — no open lane for this issue, so not a dispatched child. **Continue to the gate.**
-- `unready` (1) — the tree is clean or on the default branch, nothing to carry. Continue to the gate.
-- `busy` (1) — a cut is already in flight for this tree (the double-cut guard). Do not relaunch.
+  successor after this process exits; Anthropic relaunches directly). **End the turn immediately.**
+- `under-threshold` (0) — the newest request's billed input is under `CONTEXT_CUT_THRESHOLD`; **continue to the gate.**
+- `not-a-lane` (0) — not a dispatched child. **Continue to the gate.**
+- `unready` (1) — the tree is clean or on the default branch. Continue to the gate.
+- `busy` (1) — a cut is already in flight for this tree. Do not relaunch.
 - `failed` (1) — no live OpenAI supervisor, or the Anthropic relaunch could not start. Continue.
 - `unknown` (1) — the git directory could not be read. Continue to the gate.
 
-**`cut` is the only verdict that ends the turn.** Every other one — `under-threshold` included — leaves
-the current process to carry the run on itself.
+**`cut` is the only verdict that ends the turn.**
 
 ### The gate refuses until the cut has been taken
 
-`pnpm josh rule:guard` **refuses `pnpm josh gate`** while this checkout is a lane and no cut record is
-carried, handing back the command above. Rationale:
-`docs/maintainers/pre-gate-cut-rationale.md` → "Why the rules are guards, not prose".
+`pnpm josh rule:guard` **refuses `pnpm josh gate`** in a lane with no cut record carried, handing back
+the command above.
 
-- **It fires for a marked child and nowhere else**: the working directory is a lane —
-  `<lane root>/<issue number>` — **and** `JOSH_LANE_CHILD` names that same issue. An interactive
-  `fullrun` carries no mark and runs its gate untouched. `run:cut` uses an open-lane lookup instead, so
+- **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**. The guard
-  reads the same `cost_cli.session_verdict` `run:cut` reads, so an `under`-threshold lane is let through
-  to the gate rather than refused.
-- **It is silent once the cut is carried**, so the resumed process goes straight to the gate.
+- **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.**
 
-The row, its trigger and the enumeration it joins are
-`prompts/collaboration-workflow/rule-delivery.md`. The suites that pin this and the three guards below:
-`docs/maintainers/pre-gate-cut-rationale.md` → "Which suites pin each guard".
+Its row: `prompts/collaboration-workflow/rule-delivery.md`.
 
 ## Resuming — the fresh process's entry check
 
-A fresh `fullrun #<N>` runs this **at its entry, before `run:hold` and the session-boundary check**,
-because whether it is fresh or resumed decides everything that follows:
+A fresh `fullrun #<N>` runs this **at its entry, before `run:hold` and the session-boundary check**:
 
 ```bash
 pnpm josh run:cut --resume <N>
 ```
 
-- `fresh` (0) — no cut record, an ordinary run. Proceed with the normal entry: claim the hold, ask the
-  session boundary, read the issue, implement.
-- `resume` (0) — a declared pre-gate cut whose tree matches was verified and taken over. **Skip the
-  title, the plan, the fresh hold claim and the implementation**; re-read the issue body and comments
-  for the plan and the recorded decisions, then go straight to `pnpm josh gate`.
-- `resume-impl` (0) — like `resume`, but the cut was taken **during** implementation. Skip the title, the plan, the fresh hold claim and the split assessment,
-  re-read the plan, then **continue implementation** — do **not** go straight to the gate.
-- `handed-off` (0) — a successor has already adopted this cut, `is_handed_off` is spent.
-  This process was woken **after** its own cut. **End the turn quietly and do
-  nothing**: a benign stop, no Telegram owed.
-- `stale` (1) — the record does not match the tree (wrong branch, a clean tree, an expired record, or
-  an unknown hand-off state). **A resume failure**: send a `confirmation` Telegram and stop; never gate
-  the wrong tree.
-- `busy` (1) — another process already owns the resume. Send a `confirmation` Telegram and stop.
-
-**A resume is never reported as a success it did not earn**: `stale` and `busy` stop the run rather
-than gating.
+- `fresh` (0) — an ordinary run; normal entry.
+- `resume` (0) — a verified pre-gate cut. **Skip the title, the plan, the fresh hold claim and the
+  implementation**; re-read the issue body and comments, then go straight to `pnpm josh gate`.
+- `resume-impl` (0) — the cut was taken **during** implementation. Skip the title, the plan, the
+  fresh hold claim and the split assessment, re-read the plan, then **continue implementation** — do
+  **not** go straight to the gate.
+- `handed-off` (0) — a successor already adopted this cut. **End the turn quietly and do nothing**;
+  no Telegram owed.
+- `stale` (1) — the record does not match the tree (branch, clean tree, expired, or unknown hand-off).
+  **A resume failure**: send a `confirmation` Telegram and stop; never gate the wrong tree.
+- `busy` (1) — another process owns the resume. Send a `confirmation` Telegram and stop.
 
 ### The stage is passed to the resumed child, not reconstructed by it
 
-A resumed child arrives with `JOSH_LANE_CHILD` still set and `run:cut --resume` reads the record the cut
-left, so it learns _where to resume from_ at its entry. **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".
+**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.
 
 ## What is carried, and what is not
 
-- **The working tree is not in the record, because it never left the disk.** The record carries only
-  what a fresh process cannot recover — the issue, the branch, the invocation, and that a **declared
-  cut** put it here. **The conversation is not carried**; the fresh process reads the plan and
-  auto-decisions back off GitHub.
-- **The hold is kept, not released** — the resumed process adopts the `run:hold` record and
-  `pnpm josh followup` releases it at the merge.
-- **The dispatch mark is re-applied, not inherited**: the relaunch strips the parent's environment and
-  sets `JOSH_LANE_CHILD` afresh from the lane's issue.
+- **The working tree is not in the record, because it never left the disk.** The record carries the
+  issue, branch, invocation, and that a **declared cut** put it there. **The conversation is not
+  carried**; plan and auto-decisions are read back off GitHub.
+- **The hold is kept, not released** — `pnpm josh followup` releases it at the merge.
+- **The dispatch mark is re-applied, not inherited.**
 
 ## Verification, uniqueness and double-launch
 
-- **The resume verifies the tree against the record**: the branch matches, the tree is dirty, the
-  issue matches, and the tree is still under the cutting run's hold. Any mismatch is `stale`.
-- **No owner is recorded on the cut** — the cut is the stage hand-off alone (OpenAI keeps its
-  supervisor owner separately).
-- **The cut is exclusive** — `run:cut` writes the record with an exclusive create, so a second cut on
-  the same tree is refused `busy`.
-- **The resume is unique.** Taking the hand-off over spends it — a second `run:cut --resume` reads a
-  spent record and is answered `handed-off`, and the take-over is itself an
-  exclusive create, so two resumes racing cannot both win. One lane crosses the pre-gate boundary
-  exactly once.
+- **The resume verifies the tree against the record**: branch, dirty tree, issue, and the cutting
+  run's hold. Any mismatch is `stale`.
+- **No owner is recorded on the cut** (OpenAI keeps its supervisor owner separately).
+- **The cut is exclusive** — a second cut on the same tree is `busy`.
+- **The resume is unique** — a spent record answers `handed-off`, and the take-over is an exclusive
+  create. One lane crosses the pre-gate boundary exactly once.
 
 ## The implementation-phase cut — a lane child cuts before the gate too
 
-The **implementation-phase cut** caps the context accumulated _during_
-implementation — the child ends mid-implementation and a fresh one resumes the lane **back into
-implementation**.
+The child ends mid-implementation and a fresh one resumes **back into implementation**.
 
 ### The measurement is the parent hand-off's, never a second one
 
-The guard below refuses on the same measurement the parent uses between children —
-`cost_verdict.per_request_cost`, read through `cost_cli.session_verdict` (the read-only form of
-`pnpm josh cost --cut`), single-sourced at `backlogrun-progress.md` → "The
-hand-off". The parent's seam and the child's `run_cut.IMPLEMENTATION_CONTEXT_THRESHOLD` share the
-**135_000** `CONTEXT_CUT_THRESHOLD` (aliased so the tests cannot drift). No separate measurement is
-built for the lane child.
+Same `cost_verdict.per_request_cost` through `cost_cli.session_verdict` as `backlogrun-progress.md` →
+"The hand-off"; `run_cut.IMPLEMENTATION_CONTEXT_THRESHOLD` aliases the **135_000**
+`CONTEXT_CUT_THRESHOLD`.
 
 ### 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 whose
-recent-context cost is over threshold, handing back `pnpm josh run:cut --impl <N> --handoff <path>`.
-`cut` ends the turn; a fresh process's `run:cut --resume <N>` answers `resume-impl` and continues
-implementation — **the implementation resume clears the record**, so the cut may fire again. **A cut
-that relaunches its successor owes no Telegram**, the pre-gate cut as much as this one: nobody has
-anything to act on, and a resume answering `stale` / `busy` sends its own. Outside a lane nothing is
-relaunched, so `run:cut --impl` prints the held run's instruction — on a measured `over` that run
-keeps the hold, sends a `confirmation` Telegram naming `fullrun #<N>` and ends the turn. The refusal states the rest — **It fires on every threshold crossing,
+**The trigger**: `pnpm josh rule:guard` 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** — 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` implements it. A child that ended without cutting is detected
-after the fact by `pnpm josh run:ending <N> --output <path>`.
+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` (the newest request's billed input)
-are computed by `scripts/cost-runtime/context-cut-payback.ts`, their
-single source; 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, in the same act that starts the successor, so
-the push is never a turn boundary (`chain-rule.md`).
+`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. 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
 
-**The trigger**: a dispatched lane child about to stop for a decision (a Tier B toss-up, a Tier C
-action, an upstream defect) parks its own Issue first — `backlogrun-park.md` → "park and
-continue" — so the parent's `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.**, and a person's own `fullrun` is never refused
-(`scripts/rules/lane-park.ts`).
+**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`).
 
-**A split is not a park**: the parent reads an open Issue carrying `epic` as
-a split, so a child that promoted its Issue stops without `needs-decision` — `backlogrun-park.md` →
-"Splitting a child mid-run". `pnpm josh rule:guard` refuses a `needs-decision` write onto the epic
-the child promoted this run, on every occurrence (`scripts/rules/lane-split-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` 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` therefore refuses `AskUserQuestion` for a marked lane child on
-every occurrence — park the question instead.
-A child that slips past is recovered by `pnpm josh run:ending`, which lifts
-the refused ask into the park basis; `scripts/rules/lane-interactive-ask.ts` and the shared
-`scripts/agent/interactive-ask.ts` implement it.
-
-Provenance of each rule: `docs/maintainers/pre-gate-cut-rationale.md` → "Where each rule came from".
+fires; `pnpm josh rule:guard` 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`).

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.
@@ -34,10 +33,8 @@ open), then stash, comment and `pnpm josh run:release <M>` as for a prerequisite
 `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`).
 
-**File the prerequisite with the `route:tier-a` label**, so a Tier A filing made during implementation
-stays countable by filing route afterwards. **This paragraph belongs to the prerequisite row, not to
-the table** — the label means a filing the run is *blocked by*, so the observation row carries no
-`route:` label of its own (`observation-filing.md`):
+**File the prerequisite with the `route:tier-a` label** — it means a filing the run is *blocked by*,
+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
@@ -47,9 +44,9 @@ The command lints the body against `prompts/collaboration-workflow/issue-templat
 classification labels it declares, and runs the duplicate scan and `epic:bundle` itself
 (`docs/josh-commands-backlog.md` → `josh issue:file`).
 
-Every *file the prerequisite* step below means that labelled filing, and it always happens **first**: the
-steps after it name a number that does not exist until it is. **Its duplicate scan is read exactly as
-it is for a `new` entry** (`issue-scout.md`): a filing made mid-run is the one most likely to duplicate something.
+Every *file the prerequisite* step below means that filing, and it always happens **first** — the
+later steps name its number. **Its duplicate scan is read exactly as it is for a `new` entry**
+(`issue-scout.md`).
 
 **Each entry point's own branch stays in that entry's file:**
 
@@ -63,16 +60,13 @@ it is for a `new` entry** (`issue-scout.md`): a filing made mid-run is the one m
   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**, both load-bearing rather than tidy-up:
+**Two steps every entry's procedure turns on:**
 
 - **`git stash push -u` — the `-u` is not optional.** The work in progress almost always includes a
-  new `*.test.ts`, which is untracked, and a stash without `-u` leaves exactly those files in the tree
-  for the next child's `pnpm josh ms` to refuse.
-- **The Issue comment is what gets the stash popped, not the Telegram.** The run that later picks the
-  paused Issue up reads that comment and pops before implementing — **by message,
-  `pnpm josh stash:pop "<the -m message>"`, never a positional `git stash pop`**, because the stash is
-  a repository-wide stack every lane shares and a positional pop takes whichever lane last pushed. Say
-  it in the Telegram too — the comment is the record.
+  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

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

@@ -13,9 +13,8 @@ point-of-use document, never an entry read, and the single source of the heartbe
 pnpm josh run:progress --wait --output <the transcript path of each delegated unit>   # in the background
 ```
 
-**Start it once; it reports by itself.** Each silence interval appends the
-five labelled lines to the run's event stream as a heartbeat and to the ambient log, prints nothing to
-standard output and keeps running — so a scheduled report never wakes the session, and the session
+**Start it once; it reports by itself.** Each silence interval appends the five labelled lines to the
+event stream and the ambient log, prints nothing to standard output and keeps running — the session
 relays none. **It exits only on one of three, and the command computes which:**
 
 | Exit                                                    | What the session does                                                  |
@@ -27,23 +26,20 @@ relays none. **It exits only on one of three, and the command computes which:**
 **A report is not an exit, and neither is a decline** — with no run recorded it keeps waiting, and the
 `--hours` exit says so on standard error.
 
-**`pnpm josh run:watcher:guard` detects a missed restart**: wired into
-`pretool-guard`, it refuses the next tool call while lane children are in
-flight and the watcher's life record has gone stale — once per run, so the restart is not blocked.
+**`pnpm josh run:watcher:guard` detects a missed restart** — via `pretool-guard` it refuses the next
+tool call while lane children are in flight and the watcher's record is stale, once per run.
 
-**`--mark` at every real report.** Whenever the run reports something of its own, run
-`pnpm josh run:progress --mark` in the same turn to restart the silence clock. The clock is silence,
-never a timer (`docs/josh-commands-run.md` → "`josh run:progress`").
+**`--mark` at every real report** — `pnpm josh run:progress --mark` in the same turn restarts the
+silence clock (`docs/josh-commands-run.md` → "`josh run:progress`").
 
-**Do not keep a progress clock of your own** — the hook refuses the arm rather than asking
+**Do not keep a progress clock of your own** — the hook refuses the arm
 (`scripts/rules/early-heartbeat.ts` → `decide`), though a single correctly-spaced arm is allowed.
 `--wait` is not a wait timer.
 
 **The default interval is twenty minutes, overridable — by the person, not the run.**
-`JOSH_PROGRESS_INTERVAL_MINUTES` moves both sides (the guard reads it through the watcher's reader);
-`josh` → `progress_interval_minutes` in `package.json` sits one step below the variable. **`--interval`
-moves the watcher alone** — it makes the watcher quieter than the floor, never the guard stricter.
-Rationale: `docs/maintainers/progress-watcher-rationale.md` → "Why the heartbeat reads as it does".
+`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.
 
 ### What a report says
 
@@ -64,8 +60,7 @@ off-screen, start `pnpm josh run:board --every <minutes>` in the background (`do
 
 **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
 
@@ -75,22 +70,17 @@ signal tiers are split this way".
 `JOSH_LANE_CHILD` mark** — it still runs `--mark` for the parent's clock, but every reporting form
 (`--wait`, `--once`, the default watch) exits at once with a notice.
 
-**It is started in the target repository's checkout, and `--mark` is run there too.** A heartbeat is
-emitted from the moment a run has started — a registered lane, a held work tree or a carried budget —
-even before any child carries `in-progress`; only a checkout with no run recorded stays silent.
+**It is started in the target repository's checkout, and `--mark` is run there too.** It beats from the
+moment a run has started — a registered lane, a held work tree or a carried budget; only a checkout
+with no run recorded stays silent.
 
 **In a single-issue run, a real report is any turn that puts a progress statement in front of the
-person** — four of them, `--mark` run in the same turn as each: **the Step 0 work summary, the pull
-request opening, each review round's verdict, and any `confirmation` / `failure` / `completion`
-notification or stop.** **A tool result only you read is not one** — a gate run, a `gh` read, an edit.
-`--output` is omitted there, and `record` reads `unread`. In a `backlogrun`, a child merged, parked or
-stopped is the report.
-
-**A run that merges needs no teardown; a run that stops has to end the reporting itself.** A stop
-keeps the `in-progress` label on purpose, so **no further `--wait` is started** after the stop
-notification, and the running `--wait` is stopped in the same turn, since no report ends it. That
-covers `halfrun`'s stop before commit, a `needs-human-review` stop, a split or prerequisite stop, and 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".
+person** — `--mark` in the same turn as each: **the Step 0 work summary, the pull request opening, each
+review round's verdict, and any `confirmation` / `failure` / `completion` notification or stop.** **A
+tool result only you read is not one.** `--output` is omitted there, and `record` reads `unread`. In a
+`backlogrun`, a child merged, parked or stopped is the report.
+
+**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.

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
 

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

@@ -1,75 +1,56 @@
 # The end-of-run retrospective
 
-**This is the retrospective's procedure, and it is read when `run:step` prints the retrospective step —
-not at the entry.** `SKILL.md` → §2's table keeps the rule itself: run what `run:step` prints once,
-file the improvements worth carrying into the next run, stack the rest, and mark the step done.
-Everything that decides *how* — what the four sections mean, how the top two are chosen, the
-exclusions, and the `auto-ok` judgement — is here. Read it in full, in the same turn, before filing.
+**Read it when `run:step` prints the retrospective step — not at the entry.** `SKILL.md` → §2's table
+keeps the rule: run what `run:step` prints once, file the improvements worth carrying, stack the rest,
+mark the step done. Read this file in full, in the same turn, before filing.
 
-**When it fires is not this file's, and not a judgement.** The run driver prints the step the moment the
-backlog drains — `backlog:offer` marks that drain on the event stream and `run:step` fires the
-retrospective at it, *before* the idle watch, so the improvement issues it files are what the watch then
-picks up; a run that stops without draining — the failure guard, `--idle 0` — still prints it at the
-stop position. It is kit-only — `run:step` prints the step only in the kit repository.
-
-Rationale: `docs/maintainers/retrospective-rationale.md` → "Why the retrospective is read at its step";
-provenance: `docs/maintainers/retrospective-rationale.md` → "Where each rule came from".
+**When it fires is not a judgement.** `run:step` prints the step when `backlog:offer` marks the backlog
+drained, *before* the idle watch, so the watch picks up what it files; a run that stops without
+draining — the failure guard, `--idle 0` — still prints it at the stop position. Kit-only.
 
 ## The digest is read, not skimmed
 
-The command `run:step` prints folds four measurements that already exist into one digest — it adds no
-new measurement (the observation-filing rule against readerless numbers). Read each section for what it
-is for:
+The command `run:step` prints folds four existing measurements into one digest — it adds none:
 
-- **Run cost & time by role.** A role whose share of the wall clock runs ahead of its share of the cost
-  is marked `waiting-heavy` — the run spent that time waiting rather than working. That gap is a
-  candidate improvement, not a verdict: a role that waits by design is not a defect.
-- **Recurring review findings.** A category that keeps coming back across rounds is friction in the
-  code or the rules the reviews keep catching; the zero-finding denominator tells a genuinely quiet
-  category apart from one nobody looked at.
-- **Observation ledger.** How many observations are already held without being filed — a reminder to
-  promote one a second sighting has now earned, rather than a fresh finding.
-- **Run events.** The parks, outages, cuts and review rounds the run hit — where it did not run
-  straight through.
+- **Run cost & time by role.** A role whose wall-clock share runs ahead of its cost share is marked
+  `waiting-heavy` — a candidate improvement, not a verdict: some roles wait by design.
+- **Recurring review findings.** A category that keeps coming back is friction the reviews keep
+  catching; the zero-finding denominator separates a quiet category from an unexamined one.
+- **Observation ledger.** Observations held without being filed — promote one a second sighting earned.
+- **Run events.** The parks, outages, cuts and review rounds — where the run did not run straight through.
 
-The digest closes by pointing back here; the two targets it names are **the run itself** (the first,
-third and fourth sections) and **the repository** (the second, and anything the run surfaced that lives
-outside it).
+The two targets are **the run itself** (sections one, three, four) and **the repository** (section two,
+and anything the run surfaced that lives outside it).
 
 ## What to file, and how the top two are chosen
 
-**The filing condition is the existing depth test, unchanged** — a filing cites the product work it
-improves, and a `depth:2` finding names which decision it turns on (`observation-filing.md` → "The depth
-test"). An improvement that cannot pass the test is not filed; it is not a shortfall of the two-item
-count, it simply is not yet a finding.
+**The filing condition is the existing depth test, unchanged** (`observation-filing.md` → "The depth
+test"). What cannot pass it is not filed — not a shortfall, just not yet a finding.
+
+**A cost regression is filed.** The digest's `File a cost regression: …` line passes the depth test as
+printed — measured, with the command it names as the reproduction — and ranks first: one Issue names
+every regressed row, and the scout keeps a repeat sighting from filing twice.
 
 **Order what passes by effect, and file the top two.** **The third onward is stacked in the observation
-ledger**, on the same append path `pnpm josh observations:flush` already drains. **File nothing when
-nothing passes** — a run whose measurements show no improvement worth carrying files zero Issues.
-`docs/maintainers/retrospective-rationale.md` → "Why the top two are a selection, not a ration".
+ledger** (drained by `pnpm josh observations:flush`). **File nothing when nothing passes.**
 
-**Exclude what is already filed or already done, through the existing scout** (`issue-scout.md`). File
-each with `pnpm josh issue:file`, which runs the scout before creating anything: an **open** candidate
-covering the same work means do not file it, and a `(closed)` candidate covering it means the work is
-already merged. Neither exclusion is a new mechanism. The same call runs `epic:bundle` on each new
-Issue, as after any filing.
+**Exclude what is already filed or already done, through the existing scout** (`issue-scout.md`): file
+with `pnpm josh issue:file`, which scouts first — an **open** candidate covering it means do not file, a
+`(closed)` one means already merged. It also runs `epic:bundle` on each new Issue.
 
 ## `auto-ok`, and closing the step
 
-**What a retrospective files is judged for `auto-ok`** — an improvement that needs no person's
-judgement declares `- 人の判断: 不要`, so `issue:file` applies the label (with the run label `prompts/collaboration-workflow/issue-template.md` requires) and the next run picks it up
-without waiting for a person. **`backlogrun-steps.md` → "What one invocation approves" is that
-judgement's single source**; it is written there, beside the brakes that bound it, rather than restated here. Every brake still counts a retrospective's filings: the
+**What a retrospective files is judged for `auto-ok`** — one needing no person's judgement declares
+`- 人の判断: 不要`, so `issue:file` applies the label (with the run label
+`prompts/collaboration-workflow/issue-template.md` requires). **`backlogrun-steps.md` → "What one
+invocation approves" is that judgement's single source.** Every brake still counts these filings: the
 ten-per-invocation ceiling, the WIP cap, `--max` and the 150,000-token session budget.
 
 **Close with `pnpm josh run:carry --retrospective --summary "<result>" --owner "$PPID"`.** It marks the
-retrospective run on the carry record, so `run:step` prints `stop` from then on rather than the step a
-second time. The mark rides the record across a session cut and is removed with the record at
-`pnpm josh run:carry --end`, so one invocation runs the retrospective exactly once whether or not it was
-cut. **`--summary` is required** — the same close writes it as one `retrospective` event on the event
-stream, so a zero-filing retrospective differs from one that never ran; name
-the issues filed (or that none were) and the candidates dropped with why.
+carry record so `run:step` prints `stop` from then on; the mark survives a session cut and is removed at
+`pnpm josh run:carry --end`, so one invocation runs it exactly once. **`--summary` is required** — it is
+written as a `retrospective` event, so a zero-filing retrospective differs from one that never ran; name
+the issues filed (or none) and the candidates dropped with why.
 
-**A dispatched lane child never reaches any of this** — the batch runs the retrospective at its own end,
-never a child's, exactly as it asks `release:scope` once at the batch's end. `run:step` already answers
-`stop` for a lane child at the stop position, so a child never prints the step to begin with.
+**A dispatched lane child never reaches any of this** — the batch runs it at its own end; `run:step`
+answers `stop` for a lane child at the stop position.