@joshuafolkken/kit 1.1455.0 → 1.1471.0

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

@@ -1,39 +1,26 @@
 # 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.
-A run that files outright, or finds nothing, never reads it. This file is the single source of the ledger's grammar, its commit path and the
-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. 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".
 
 ## 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".
-
-- **The destination is the `.josh/observations/` directory in the repository the
-  observation is about** — the same repository the Issue would have been filed into — **one file per
-  issue**: append to `<N>.md` for the issue the run is executing (the number
-  its branch leads with, a lane's included), or to `<YYYY-MM-DD>.md` for a line written on the
-  default branch outside any issue's run. Parallel lanes therefore write different files, and their
-  pull requests never conflict on the ledger. **The count and the append are both run in that
-  repository's checkout** — in this repository, the work tree the run is in, a lane's inside a lane —
-  resolved the way `target-repository.md` resolves any cross-repository target, and the
-  directory is created on the first append where that repository has none. **The subject decides, never the
-  working directory**: an observation about this package's own orchestration, seen while a run is
-  inside a repository that consumes it, is recorded here rather than there — the append follows the
-  subject, never the working directory. **A third-party target gets no line either** — Tier C covers
-  the ledger exactly as it covers the Issue that would otherwise have been filed there.
-- **It is append-only.** A line is never edited and never deleted, because the count of lines
-  carrying one key is what says whether an observation has recurred; a second sighting is a second
-  line, not a rewrite of the first. **A merge conflict in it is resolved by keeping both sides** —
-  one file per issue should keep it from arising, but a repeated key is the whole signal, so
-  dropping either side destroys exactly what the ledger is for.
-- **The completion report keeps its line too.** The ledger is what the next run can read; the report
-  is what this run's reader sees. Neither replaces the other.
-- **The append is not the end of it** — a line only becomes readable to anyone else once it has
-  merged, and "The commit path" below is how it gets there.
+**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".
+
+- **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,
+  a lane's included), or `<YYYY-MM-DD>.md` on the default branch outside any issue's run. **The count
+  and the append are both run in that repository's checkout** (resolved as `target-repository.md`
+  resolves a target). **The subject decides, never the working directory.** **A third-party target
+  gets no line either** (Tier C).
+- **It is append-only.** Never edit or delete a line; a second sighting is a second line. **A merge
+  conflict in it is resolved by keeping both sides.**
+- **The completion report keeps its line too.**
+- **The append is not the end of it** — → "The commit path — how an appended line reaches the
+  default branch" below.
 
 **One observation is one line: five fields, each separated from the next by a vertical bar with one
 space on either side.**
@@ -44,118 +31,76 @@ space on either side.**
 
 | Field          | What it holds                                                                                                             |
 | -------------- | ------------------------------------------------------------------------------------------------------------------------- |
-| `k:<slug>`     | The identity key — lowercase letters and digits, in words joined by `-`. This is what makes a repeat machine-readable      |
-| `d<n>`         | The depth of the subject — `d1`, `d2`, or whatever deeper depth `observation-filing.md`'s depth table may one day name. **There is no `d0` line**: a depth-0 observation is filed outright and never reaches the ledger |
+| `k:<slug>`     | The identity key — lowercase letters and digits, in words joined by `-`                                                    |
+| `d<n>`         | The depth of the subject — `d1`, `d2`, or deeper. **There is no `d0` line**: depth 0 is filed outright                     |
 | `<YYYY-MM-DD>` | The date of **this** sighting                                                                                             |
 | `<where>`      | One file path or one command — where the thing was seen                                                                   |
 | `<what>`       | The phenomenon, one sentence, carrying no vertical bar of its own                                                         |
 
-A sample, in the shape a real entry takes:
-
 ```
 - k:example | d1 | 2026-09-10 | pnpm josh run:progress | The report printed a fill-in placeholder where a clock time belonged
 ```
 
-**`k:example` is reserved for this sample and is never used by a real observation**, so the count
-below can be run over the whole ledger without the sample answering for one. **The grammar is defined
-here rather than in the ledger** (`docs/maintainers/observation-ledger-rationale.md` → "Why the
-ledger exists").
+**`k:example` is reserved for this sample and is never used by a real observation.**
 
 **The identity key is the whole of the repeat test — never a similarity judgement about the prose.**
-Choose the key from the phenomenon rather than from the run, then record the sighting with one
-command — it counts what the ledger already holds for the key, appends the line and prints the
-verdict:
+Choose it from the phenomenon, not the run, and record with one command:
 
 ```bash
 pnpm josh observation:record <slug> d<n> '<where>' '<what>' [--checkout <that repository's checkout>]
 ```
 
-Standard output is one token: `file` (this is the second sighting — file it, below) or `ledger` (the
-line is the record, nothing to file); standard error lists the earlier sightings and the file
-appended to. A line that breaks the grammar, or uses `k:example`, is refused with exit 1 and nothing
-appended. **Every
-file of the directory is counted**, in the named checkout rather than the working directory, because
-a recurrence is a recurrence whichever issue's file each sighting sits in; a missing directory is a
-first sighting, and the append creates it.
-
-Free-text comparison is what the key exists to replace, so two lines that read alike under different
-keys are two observations, and a mis-keyed entry is corrected by appending a correctly-keyed line
-rather than by editing the one already written.
+Standard output is one token: `file` (second sighting — file it, below) or `ledger` (nothing to file);
+standard error lists earlier sightings and the file appended to. A broken line, or `k:example`, exits
+1 with nothing appended. **Every file of the directory is counted**, in the named checkout. A
+mis-keyed entry is corrected by appending a correctly-keyed line.
 
-**The depth gate is not withdrawn, and this is not a way around it.** An observation that *can* cite
-the depth-0 work it stopped is filed exactly as it was before — this route is only for the ones that
-could not.
+**The depth gate is not withdrawn, and this is not a way around it** — an observation that *can* cite
+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".
 
-- **A run's appended lines ride its own commit.** `pnpm josh git` stages
-  `.josh/observations/` with the run's other changes, in the one staging step every entry
-  point goes through (`scripts/git/git-staging.ts`), so the lines are reviewed and merged with the
-  pull request of the run that recorded them, and the run's CI is the only wait they cost.
-  **Record before the commit, not after the merge:** a finding recorded with `pnpm josh review:record`
-  before `pnpm josh git -y` is carried; the time while CI runs is for the records that need no CI
-  result — filing an observation Issue, drafting the completion report.
-- **A line that breaks the grammar is not carried.** The staging step parses
-  every file of the ledger first — after moving lines still on an old single-file path — and on a broken line leaves the ledger out of the
-  commit and says so; the commit itself goes ahead.
+- **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
+  with `pnpm josh review:record` before `pnpm josh git -y` is carried.
+- **A line that breaks the grammar is not carried** — the ledger is left out of the commit, which
+  goes ahead.
 - **A review round that passes after the pull request opened is recorded on the Issue, not in the
-  ledger** — `pnpm josh review:record --issue <N> --comment` posts the same `- rf:` lines as a comment
-  and appends nothing. That round reads only, so no commit of the run's follows it; a line in the tree
-  would be pushed onto the open pull request and its CI would start over. `pnpm josh ship --review`
-  does this for a passing round 2. **A round 2 that blocks records in the tree as before** — the fix it
-  stops for is pushed anyway and carries the lines. Once the Issue is closed, the next round recorded
-  to the ledger carries the comment's lines into `<N>-comment-rounds.md` with its own commit, so
-  `pnpm josh review:findings` and the retrospective count them (`review-comment-round.ts`).
+  ledger** — `pnpm josh review:record --issue <N> --comment` (`pnpm josh ship --review` does this for a
+  passing round 2), so CI does not restart. **A round 2 that blocks records in the tree as before.**
+  Once the Issue closes, the next ledger round carries the comment's lines into
+  `<N>-comment-rounds.md` (`review-comment-round.ts`).
 - **`pnpm josh followup` commits any other line appended after the run's commit onto the pull request,
-  before the merge** — the residual path, for an observation recorded between the commit and the
-  merge. After the merge gates and before the CI wait, `followup` reads the tree and, **only when the
-  ledger holds a pending append**, stages the ledger paths alone, commits them and pushes the branch;
-  that push restarts the pull request's CI, and the wait that follows covers it. A broken line refuses
-  the merge, because the line would otherwise be lost with the branch. A run whose lines rode its
-  commit pays nothing.
-- **A lane carries its own lines, in its own pull request.** Its writers
-  append to its own tree's `<N>.md`, so the two steps above take them to the default branch exactly as
-  they do for a run in the primary checkout. **Nothing is held in the primary checkout for later.**
-- **`pnpm josh observations:flush` is left for a line written outside any issue's run** — the
-  date-named file a retrospective or a hand append on the default branch writes. It stages the ledger
-  and nothing else, commits it on a branch of its own, opens a docs-only pull request, waits on the
-  same required checks every other pull request waits on, merges it and returns the checkout to the
-  default branch; a single run's `run:tail` runs it after the merge. It refuses off the default branch
-  and refuses a working tree holding anything besides the ledger, so a run in progress cannot be
-  flushed out from under. **Nothing is committed to the default branch directly.**
-- **Nothing to flush is an answer, not a failure.** With the ledger matching the commit it sits on
-  the command prints `clean` and exits 0.
+  before the merge** — only when the ledger holds a pending append; a broken line refuses the merge.
+- **A lane carries its own lines, in its own pull request.**
+  **Nothing is held in the primary checkout for later.**
+- **`pnpm josh observations:flush` is left for a line written outside any issue's run**: it commits the
+  ledger alone on its own branch, opens a docs-only pull request, waits on the required checks, merges
+  and returns to the default branch (a single run's `run:tail` runs it). It refuses off the default
+  branch or with anything besides the ledger in the tree. **Nothing is committed to the default branch
+  directly.**
+- **Nothing to flush is an answer, not a failure** — `clean`, exit 0.
 - **The count the promotion below reads is a count of the default branch.**
 
 ## The second sighting is what files it
 
-**A repeat is the citation**, so the gate has a second way through, and it is counted rather than
-judged (rationale: `docs/maintainers/observation-ledger-rationale.md` → "Why a second sighting
-files"):
+**A repeat is the citation** — counted, not judged (`docs/maintainers/observation-ledger-rationale.md`
+→ "Why a second sighting files"):
 
 - **On `observation:record` answering `file`, the observation is filed**, at depth 1 or deeper, with
-  no depth-0 citation. It answers `file` only when exactly one earlier sighting exists — a higher
-  count means the Issue was already opened by the sighting before. The line is appended either way,
-  because the ledger stays append-only.
-- **The Issue quotes the ledger's own dates — the first sighting's and this one's**, both on the
-  command's standard error — so the reader can check the promotion against the file instead of
-  taking the run's word for it.
-- **Both ceilings still apply**, exactly as `observation-filing.md` states them: the 10-per-run cap counts a promoted
-  filing, and the WIP cap still bites, since a promoted observation blocks nothing and is therefore
-  still discretionary.
-
-**A third and later sighting appends a line and files nothing more.** The Issue from the second one
-is already open, and `pnpm josh issue:scout` is what finds it; the extra lines are evidence for that
-Issue, not new ones.
+  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.
+
+**A third and later sighting appends a line and files nothing more** — `pnpm josh issue:scout` finds
+the open Issue.
 
 ## A user-found bug is recorded by its kind of miss (user-found)
 
 **A user-reported bug is fixed or filed as always; this records the *kind of miss* alongside so the
-category never recurs as a first sighting.** The key is the **category of
-oversight** — `k:missed-case-worktree` — so a second bug of the same kind counts against the first.
-**Depth `d1`, never `d0`**: the *kind of miss* is what a run fails to enumerate, which the table puts
-at depth 1. Nothing else changes; the `<what>` field leads with `User-reported:`, and no second
-ledger, format or threshold is added.
+category never recurs as a first sighting.** The key is the **category of oversight** —
+`k:missed-case-worktree`. **Depth `d1`, never `d0`**. The `<what>` field leads with `User-reported:`;
+nothing else changes.

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

@@ -1,215 +1,166 @@
 # 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. Rationale: `docs/maintainers/pre-gate-cut-rationale.md` → "Why the cut exists".
 
-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.
+This file is the single source of the boundary: `run:cut` takes it, `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. 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 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`. Suites: `docs/maintainers/pre-gate-cut-rationale.md`
+→ "Which suites pin each guard".
 
 ## 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:
+**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".
 
 ## 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**. 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>`.
+`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
+`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. 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
+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.
+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`).
 
 Provenance of each rule: `docs/maintainers/pre-gate-cut-rationale.md` → "Where each rule came from".

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

@@ -34,10 +34,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 +45,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 +61,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