@joshuafolkken/kit 1.953.0 → 1.972.0

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

@@ -56,7 +56,9 @@ Each step is a terse trigger and a pointer; the procedure is read on demand from
    opted-in pool, a run's own filings once bundled, and the brake (`--max`, ten filings, the WIP cap)
    that bounds the amount. `auto-ok` is a person's alone.
 4. **Report the plan before the first child** — `pnpm josh backlog:plan`, then resolve every
-   `needs-decision` issue decidable from its body in one pass. `backlogrun-steps.md` → "The plan,
+   `needs-decision` issue decidable from its body in one pass. In the same pass, record `blocked-by`
+   between issues that must land in order, and apply `run:solo` where the verification-path
+   enumeration holds, `run:lane` elsewhere. `backlogrun-steps.md` → "The plan,
    before the first child starts" and its "Resolve what the plan can resolve, before starting".
 5. **Named issues run first, in order** — `backlogrun-steps.md` → "Named issues run first, in order":
    the supervisor's driver dispatches each as a delegated `fullrun`, one at a time, then drains the

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

@@ -58,6 +58,9 @@ What one invocation does, in order:
   A run that stopped at the merge therefore has no Issue comment, and the missing comment is what a
   failed merge looks like from GitHub.
 - **Closes the epics the Issue completes**, on a merged run only.
+- **Confirms the Issue itself closed**, on a merged run only. GitHub has left merged runs' Issues
+  open despite `closes #N` (joshuafolkken/kit#2770), so an Issue still open a few seconds after the
+  merge is closed with a comment saying why, and the repair is printed as a warning.
 - **Takes the `in-progress` label back off the Issue**, on a merged run only. A run that merged nothing
   keeps it. The removal reads the Issue's labels and sends back the spelling GitHub stored, so an
   `In-Progress` repository is not missed, and an Issue that never carried the label is never written to.

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

@@ -58,11 +58,10 @@ call reports `hold`.
   ambient surface is the run's event stream, followed identically before and after a cut, so nothing
   about the reporter moves when execution hands off (`backlogrun-progress.md` → "The invariant is a
   tier, not a mechanism").
-- **A dispatched lane child asks whether it is a resume first — `pnpm josh run:cut --resume <N>`**; on
-  `resume` it skips the title, plan, hold and implementation and goes to the gate. At the pre-gate
+- **A lane child asks whether it is a resume first — `pnpm josh run:cut --resume <N>`** (`run:entry` asks it
+  before the hold, joshuafolkken/kit#2760); on `resume` it skips the title, plan, hold and implementation and goes to the gate. At the pre-gate
   boundary — immediately after `pnpm josh main:merge`, before the gate — it takes the cut with
-  `pnpm josh run:cut <N>` (the ordered step in `chain-rule.md`, so the cut is taken before the gate
-  rather than after a refusal), and it records any park on the Issue before the stop notify.
+  `pnpm josh run:cut <N>` (the ordered step in `chain-rule.md`), and it records any park on the Issue before the stop notify.
   `pre-gate-cut.md` is the single source of both.
 
 ## The stop branches

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

@@ -254,37 +254,43 @@ it — and seven lines had never left a working tree. **So the repeat count belo
 that is empty on every other machine**, and every sighting was a first one, which is the state
 joshuafolkken/kit#1728 created the ledger to end.
 
-- **An ordinary run never commits the ledger, and that is enforced rather than remembered.**
-  `pnpm josh git` stages with `docs/maintainers/observations.md` excluded, in the one staging step every entry
-  point goes through (`scripts/git/git-staging.ts`), so a `fullrun` in the primary checkout **cannot**
-  carry a ledger line into an Issue that has nothing to do with it. It is not a rule a run has to
-  remember at the commit — a run that had to would be the run that forgets.
-- **The parent flushes the ledger as a pull request of its own** — `pnpm josh observations:flush`. It
-  stages that one path 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. **Nothing is committed to the default branch directly**, which
-  is the constraint this route had to satisfy.
-- **`pnpm josh followup` runs the flush itself, so no run has to remember to** (joshuafolkken/kit#1810).
-  The flush is the ledger's only commit path, and until it was wired into `followup` nothing called
-  it — an appended line stayed in the working tree until a person ran the command by hand, the same
-  defect the staging exclusion above was built to avoid. After the merge and before it releases the working-tree
-  hold, `followup` reads the tree, and **only when the ledger holds a pending append** returns the
-  checkout to the default branch (`pnpm josh ms`) and flushes. A run that appended nothing pays
-  nothing, and a lane skips it (next bullet). A flush that fails is reported and does not take the merge, the
-  epic close or the hold release down with it. **A side effect: on a run that did flush, `followup`
-  ends on the default branch.**
+- **A run's appended lines ride its own commit** (joshuafolkken/kit#2763). `pnpm josh git` stages
+  `docs/maintainers/observations.md` 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. Until
+  #2763 the ledger was excluded there (joshuafolkken/kit#1756) and every run that appended a line
+  paid a second branch, CI wait and merge after its own — 144 ledger-only pull requests in one month.
+  **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** (joshuafolkken/kit#2123). The staging step parses
+  the ledger first — after moving lines still on the old path (joshuafolkken/kit#2724) — and on a
+  broken line leaves the ledger out of the commit and says so; the commit itself goes ahead.
+- **What no run's commit carried is flushed as a pull request of its own** — `pnpm josh
+  observations:flush`: a lane's lines (next bullets) and a line appended after the commit, such as a
+  second review round's record. It stages that one path 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. **Nothing is committed to the
+  default branch directly.**
+- **`pnpm josh followup` runs that flush itself, so no run has to remember to** (joshuafolkken/kit#1810).
+  After the merge and before it releases the working-tree hold, `followup` reads the tree, and **only
+  when the ledger still holds a pending append** returns the checkout to the default branch
+  (`pnpm josh ms`) and flushes. A run whose lines rode its commit pays nothing, and a lane skips it
+  (next bullet). A flush that fails is reported and does not take the merge, the epic close or the
+  hold release down with it. **A side effect: on a run that did flush, `followup` ends on the default
+  branch.**
 - **A lane's writers use the primary checkout's ledger** (joshuafolkken/kit#2419): a lane refuses
   `pnpm josh ms`, so its own copy had no way out. `pnpm josh observations:flush` acts on the primary
   checkout from a lane. **A dispatched lane child does not flush at all** (joshuafolkken/kit#2492): its
   `run:tail` skips the step, and the `backlogrun` flushes every lane's lines once, in one pull request,
   at `pnpm josh run:carry --end`.
-- **Mixing the lines into a child's pull request was considered and is refused.** That is the
-  contamination the exclusion above exists to end, and adopting it would turn the defect into the
-  specification: a ledger line in an unrelated diff is a line no reviewer of that diff has a reason
-  to question.
+- **A lane child's pull request does not carry the lines, and that is deliberate.** Lanes run side by
+  side, and two pull requests that each append at the ledger's tail conflict with each other the
+  moment the first merges — a conflict ends the other's CI wait. The batch's single flush at
+  `run:carry --end` is already one pull request per batch, not one per child.
 - **Run by hand it goes in the primary checkout, once per cycle rather than once per observation** —
-  but with `pnpm josh followup` now flushing automatically (above), a hand run is the exception rather
-  than the rule. It refuses off the default branch and refuses a working tree holding anything besides
+  but with the lines riding the run's commit and `pnpm josh followup` flushing the rest (above), a hand
+  run is the exception rather than the rule. 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, and a lane's checkout is never
   the one it acts on.
 - **Nothing to flush is an answer, not a failure.** With the ledger matching the commit it sits on

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

@@ -1,32 +1,29 @@
 # 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 (measured at **176K of 204K output tokens** on
-joshuafolkken/kit#1837). 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.
+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".
 
 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. The rule is reached only **during** a lane child's run,
-after the workflow skill has been read, so it is not an entry read — `fullrun.md`, `chain-rule.md` and
-`backlogrun.md` name it with a plain mention and route here. **A second boundary is added below** — the
+check a fresh process makes at its own entry. **A second boundary is added below** — the
 implementation-phase cut (joshuafolkken/kit#1933), at a context threshold _during_ implementation.
 Everything through "What is carried" describes the pre-gate cut; the later section states only what
 differs.
 
 ## Where the boundary is
 
-**After implementation and the refactor, before `pnpm josh gate`** — the same boundary
-joshuafolkken/kit#1837 puts the `origin/main` merge at: implementation complete, nothing committed,
-the gate not started. Everything before it produced the thinking to be dropped; everything after it
-(gate → review → commit → push → merge) is verification the fresh process runs on the tree.
+**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.
 
 ## 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` must not
-relaunch itself, so a dispatched child is told apart **mechanically, by a mark the dispatch sets** —
-never by the model reading the shape of its own prompt (joshuafolkken/kit#1904).
+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 (joshuafolkken/kit#1904).
 
 ### The dispatch mark
 
@@ -34,8 +31,7 @@ never by the model reading the shape of its own prompt (joshuafolkken/kit#1904).
 to the lane's issue number. `scripts/lane/lane-child-marker.ts` is its one definition.
 
 - **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 (a
-  mark a run could set for itself would be no mark at all).
+- **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.
@@ -48,13 +44,11 @@ checkout, a cut in a lane.
 
 ## Taking the cut
 
-**The order is fixed in the chain, not left to the refusal to enforce** (joshuafolkken/kit#2177).
-`chain-rule.md` step 1 issues `pnpm josh run:cut <N>` after `pnpm josh main:merge`, before the scoped
-pair and the gate, so the default path takes the cut before anything reads the tree — removing the
-wasted round trip joshuafolkken/kit#2160 measured (an uncut gate refused, its batched `review:brief`
-cancelled, then cut and resume). **The command is still issued unconditionally**; `run:cut` itself
-decides whether the cut is warranted (joshuafolkken/kit#2312), so a short lane with nothing to drop is
-answered `under-threshold` and walks on to the gate rather than relaunching.
+**The order is fixed in the chain** (joshuafolkken/kit#2177): `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
+(joshuafolkken/kit#2312), 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:
 
@@ -65,9 +59,8 @@ pnpm josh run:cut <N>          # alias: josh rct
 - `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 recent-window per-request cost is under the shared `CONTEXT_CUT_THRESHOLD`
-  (joshuafolkken/kit#2312), so the accumulation a cut would drop is not worth a resume's cost. Nothing
-  was cut; **continue to the gate.**
+- `under-threshold` (0) — the recent-window per-request cost 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.
@@ -79,29 +72,22 @@ the current process to carry the run on itself.
 
 ### The gate refuses until the cut has been taken (joshuafolkken/kit#1864)
 
-**This step was carried as prose and fired exactly never.** joshuafolkken/kit#1850 measured six lane
-children and the cut was taken **0 times**: four issued the *entry* check
-`pnpm josh run:cut --resume <N>` and were answered `fresh`, not one issued the call above. A step a run
-is free to skip is the step skipped under time pressure — so `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. With the ordered step above (joshuafolkken/kit#2177) the refusal is insurance, not the primary
-trigger.
-
-- **It fires for a marked child and nowhere else** (joshuafolkken/kit#1904). The `PreToolUse` hook
-  reads two facts: 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` draws its own line its own way — an open-lane lookup — which is why the guard and
-  the command need not agree byte for byte; the mark makes the guard's half mechanical.
+**This step was carried as prose and fired exactly never.** Across six measured lane children the cut
+was taken **0 times**. So `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. With the ordered step above the
+refusal is insurance, not the primary trigger. 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
+  the guard and the command need not agree byte for byte.
 - **It fires only when the recent-window context warrants a cut** (joshuafolkken/kit#2312). 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 — the guard and the command never disagree about whether a cut was
-  due. The context read is lazy, after the command and lane checks, so an ordinary run pays nothing for
-  it.
+  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 once per run.** Five of the six verdicts leave this process holding the run, each needing
-  the reissued gate call to pass — a refusal that repeated would wedge exactly the runs that obeyed.
-- **`--resume`, `--end` and `--json` do not count as taking the cut**, because they ask about one
-  rather than take it — counting them would have credited four of the six measured children.
+- **It fires once per run.** A refusal that repeated would wedge the runs that obeyed.
+- **`--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`; `scripts/rules/pre-gate-cut.test.ts` pins it.
@@ -131,34 +117,34 @@ pnpm josh run:cut --resume <N>
   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, so a cut that lost its work, or one two processes reached at once, is caught.
+**A resume is never reported as a success it did not earn**: `stale` and `busy` stop the run rather
+than gating.
 
 ### The stage is passed to the resumed child, not reconstructed by it
 
-(joshuafolkken/kit#1904) 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. This removes the
-reconstruction a stopped child redid on every resume (2.6 minutes / ~150K tokens, joshuafolkken/kit#1876).
+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".
 
 ## 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** (joshuafolkken/kit#1567 found compaction does
-  not reduce billing); the fresh process reads the plan and auto-decisions back off GitHub.
-- **The hold is kept, not released** — the uncommitted work is what a second run would trample, so 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** (joshuafolkken/kit#1904): the relaunch strips the
-  parent's environment and sets `JOSH_LANE_CHILD` afresh from the lane's issue.
+  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.
 
 ## 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.** OpenAI keeps a separate per-worktree supervisor owner and
-  generation state; the cut is the stage hand-off alone.
+- **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
@@ -168,11 +154,8 @@ reconstruction a stopped child redid on every resume (2.6 minutes / ~150K tokens
 
 ## The implementation-phase cut — a lane child cuts before the gate too
 
-**The pre-gate cut drops the thinking accumulated _before_ the gate; it does nothing about the thinking
-accumulated _during_ implementation** (joshuafolkken/kit#1933). A lane child re-reads its whole
-conversation on every request, so a long implementation is billed like a long `backlogrun` parent (which
-on 2026-09-13 measured **208k–386k** median context per request). The **implementation-phase cut** caps
-that growth — the child ends mid-implementation and a fresh one resumes the lane **back into
+The **implementation-phase cut** (joshuafolkken/kit#1933) caps the context accumulated _during_
+implementation — the child ends mid-implementation and a fresh one resumes the lane **back into
 implementation**.
 
 ### The measurement is the parent hand-off's, never a second one
@@ -186,106 +169,67 @@ built for the lane child.
 
 ### It is a guard, fired at the edit that crosses the threshold (joshuafolkken/kit#2310)
 
-**This step was carried as prose and fired exactly never** — the fate the pre-gate cut met before
-joshuafolkken/kit#1864. joshuafolkken/kit#1933 reasoned it *could not* be a guard, because the
-per-request cost was read **asynchronously**; but `cost_cli.session_verdict` is synchronous and is the
-exact verdict `pnpm josh cost --cut` prints. joshuafolkken/kit#2310 measured the child-side check across
-five lanes: the verdict was read once each at session entry, before the context grew, so the cut fired
-**0 times** while 33.9% of their requests ran past 200,000 tokens.
+**This step was carried as prose and fired exactly never** — measured across five lanes, the cut fired
+**0 times** while 33.9% of their requests ran past 200,000 tokens. Rationale:
+`docs/maintainers/pre-gate-cut-rationale.md` → "Why the rules are guards, not prose".
 
 So `pnpm josh rule:guard` **refuses an `Edit` / `Write`** while this checkout is a dispatched lane child
-whose recent-context cost is over threshold, handing back `pnpm josh run:cut --impl <N> --handoff <path>` — a
-`PreToolUse` refusal lands *before* the edit, so the tree is at the state the previous edit left it. `cut`
-ends the turn, the rest leave this process implementing; a fresh process's `pnpm josh run:cut --resume
-<N>` then answers **`resume-impl`**, so it **skips the title, plan, hold claim and split assessment** and
-**continues implementation** rather than gating. Unlike the pre-gate cut, **the implementation resume
-clears the record** (joshuafolkken/kit#2310): the pre-gate cut fires once per lane so its record must
-survive to answer a second resume `handed-off` (joshuafolkken/kit#1935), but this one may fire again, so
-its record is removed on resume. A double cut stays impossible — `begin_cut`'s exclusive create prevents
-it — so a lane crosses this boundary several times, each with exactly one successor.
-
-- **It fires for a marked child and nowhere else** — the dispatch mark names this lane's own issue, so a
-  person's own `fullrun` carries no mark and sees no refusal.
-- **It fires on every threshold crossing, not once per run** (joshuafolkken/kit#2385) — once per run
-  silenced the row after its first refusal, so a `busy` / `failed` / `unready` verdict, or an edit
-  reissued unchanged, left the context to grow unwatched (joshuafolkken/kit#2382 ran to 282,747 tokens,
-  the cut never taken). The row now carries `decide` and re-asks on each over-threshold edit.
-- **An edit reissued right after a refusal passes** (joshuafolkken/kit#2385) — so a `busy` / `failed` cut
-  cannot wedge the run: the reissue lands inside a short window and goes through, a genuinely new crossing
-  past it refuses again.
-- **An unmeasurable session warrants the cut** (joshuafolkken/kit#2385) — the `verdict !== UNDER_VERDICT`
-  reading matches the pre-gate cut's `warrants_the_cut`, so they never disagree.
+whose recent-context cost is over threshold, handing back `pnpm josh run:cut --impl <N> --handoff <path>` — the
+refusal lands _before_ the edit. `cut` ends the turn, the rest leave this process implementing; a fresh
+process's `pnpm josh run:cut --resume <N>` then answers **`resume-impl`**, so it **skips the title, plan,
+hold claim and split assessment** and **continues implementation** rather than gating. Unlike the
+pre-gate cut, **the implementation resume clears the record** — it may fire again, unlike the
+once-per-lane pre-gate cut (joshuafolkken/kit#1935); `begin_cut`'s exclusive create still gives each
+crossing one successor.
+
+- **It fires for a marked child, or a run held outside a lane on a measured `over`**
+  (joshuafolkken/kit#2760); a person's tree holds no run. Outside a lane `cut` relaunches nothing: keep
+  the hold, send a `confirmation` Telegram naming `fullrun #<N>`, end the turn.
+- **It fires on every threshold crossing, not once per run** (joshuafolkken/kit#2385) — it re-asks on
+  each over-threshold edit, including after a `busy` / `failed` / `unready` verdict.
+- **An edit reissued right after a refusal passes** — so a `busy` / `failed` cut cannot wedge the run:
+  the reissue lands inside a short window and goes through, a genuinely new crossing past it refuses
+  again.
+- **An unmeasurable session warrants the cut** in a lane, as the pre-gate cut's does.
 - **It is silent between a cut and its resume** — a carried record naming this issue keeps it quiet; the
   resume clears it, and the fresh process reads its own transcript under threshold.
-- **The verdict read is reused over a short window** (joshuafolkken/kit#2385) — the whole-transcript
-  price is a candidate on every edit now, so it is cached per checkout for a few seconds: a turn's burst
-  of edits shares one read.
+- **The verdict read is reused over a short window** — cached per checkout for a few seconds, so a
+  turn's burst of edits shares one read.
 
 `scripts/rules/implementation-cut.ts` implements the trigger, `scripts/rules/implementation-cut.test.ts`
 pins it, and the row joins `prompts/collaboration-workflow/rule-delivery.md`. **A child that ended
 without cutting is still detected after the fact by `pnpm josh run:ending <N> --output <path>`**
 (joshuafolkken/kit#2139). **A single check (`lint:related` / `test:related`) is run after a batch of
-edits, not after each one** — every check is a request too (joshuafolkken/kit#1383).
+edits, not after each one.**
 
 ## The threshold, and the statistic it is measured against
 
-**The `CONTEXT_CUT_THRESHOLD` (135_000) is one value; what joshuafolkken/kit#2295 changed is the
-statistic — `cost_verdict.per_request_cost` now averages the most recent `RECENT_REQUEST_WINDOW` (10)
-requests rather than the whole session.** It is still *one* measurement both read. This supersedes
-joshuafolkken/kit#2282, which kept the whole-session average and rejected this option on the batch it
-measured — short-lived lane children with no parent session, for which the two averages nearly coincide.
-
-- **The safety net now fires.** Built (joshuafolkken/kit#1933) for a pathological regime a typical lane
-  never enters, 135_000 sits below the 208k floor of that regime, so a runaway implementation still trips
-  it — and joshuafolkken/kit#2310 made the guard trip actively at the crossing edit.
-- **The recent window catches the long parent the whole-session average missed.** The 2026-09-21
-  parent `567f8eac` (186 requests, 7 hours) first crossed 200k at request 65, but its whole-session
-  average did not until request 150 — **85 requests (~4 hours) later**, ~$7.88 supervising an oversized
-  parent past the point a cut was due. The recent-10 average removes that lag.
-- **It is not the forbidden second measurement.** joshuafolkken/kit#1933 forbids the child pricing its
-  cut on a statistic the parent does not share; #2295 keeps one statistic both read and redefines it.
-
-### The value is a break-even, not a chosen number (joshuafolkken/kit#2406)
-
-**The threshold is derived.** joshuafolkken/kit#2374 set 150_000; joshuafolkken/kit#2406 replaced the
-hand-picked number with the arithmetic behind it. A cut costs one preamble rewrite
-(`POST_CUT_CONTEXT`, ~60_000 tokens) and saves the dropped context's cache read on every later request,
-so it turns on a rate, not a ceiling: `context-cut-payback.ts` computes the per-request context at which a
-cut pays back over the expected remaining requests, from the cache multipliers in `cost-pricing.ts` (no
-second price list). At a 10-request horizon that is **135_000**, in #2374's band; the horizon is the knob
-a before/after lane measurement tunes (#2406 PR).
-
-### The cut is conditional, and the resume side is why (joshuafolkken/kit#2312)
-
-**Until joshuafolkken/kit#2312 the pre-gate cut was _unconditional_, and its case recorded only the
-gain** — the context reduction it carries (~130k → ~60k per request). **The resume side was never
-priced.** A cut relaunches a fresh process that re-reads the plan and decisions off GitHub before the
-gate — a fixed ramp of ~12 requests per session. That ramp was **$81.01 of $435.09 (19%)**
-across the 32 lanes of 2026-09-21, falling hardest on the short lanes with the least to drop: #2282 spent
-**58%** of its billing on it at 60k median context, #2295 **39%** at 74k, #2289 **37%** at 81k — each
-with **0%** of its requests over 200k.
-
-**So the cut is now taken only when the recent-window per-request cost is over `CONTEXT_CUT_THRESHOLD`**
-— the same statistic and threshold the implementation-phase cut reads, so **no second threshold is
-introduced**. Below it `run:cut` answers `under-threshold` and the gate runs uncut; the guard reads the
-same verdict and stays silent. A lane like #2298 (31% of requests over 200k) still cuts as before, and an
-**unmeasurable** session keeps the old unconditional cut so it is never left uncut.
+**`CONTEXT_CUT_THRESHOLD` (135_000) is one value, and `cost_verdict.per_request_cost` — the one
+statistic the parent and the lane child both read — averages the most recent `RECENT_REQUEST_WINDOW`
+(10) requests, not the whole session** (joshuafolkken/kit#2295). The value is a derived break-even, not a
+chosen number (joshuafolkken/kit#2406): `scripts/cost-runtime/context-cut-payback.ts` computes it from a
+cut's one-time preamble rewrite (`POST_CUT_CONTEXT`, ~60_000 tokens — a cut carries a request from ~130k
+down to ~60k), the cache multipliers in `cost-pricing.ts`, and a 10-request horizon.
+
+**The cut is conditional** (joshuafolkken/kit#2312): taken only when the recent-window per-request cost
+is over `CONTEXT_CUT_THRESHOLD` — the same statistic and threshold the implementation-phase cut reads, so
+no second threshold exists. Below it `run:cut` answers `under-threshold` and the gate runs uncut; the
+guard reads the same verdict and stays silent. An **unmeasurable** session is always cut.
+Rationale: `docs/maintainers/pre-gate-cut-rationale.md` → "Why the threshold is a break-even".
 
 ## Consistency with the chain rule
 
 The chain forbids ending a turn at the push, with CI in flight and nothing set to resume. **The pre-gate
 cut and the detached hand-off end it _before_ the gate** and start what carries the run on in the same
 act — a fresh process, or the supervisor — so the push is never a turn boundary. The implementation-phase
-cut is the same pattern one boundary earlier (joshuafolkken/kit#1933).
+cut is the same pattern one boundary earlier.
 
 ## A lane child records its park before it stops
 
 **A dispatched lane child records its park on the Issue before it stops for a decision**
-(joshuafolkken/kit#2034). A headless child's only route to ask a person anything is to park the Issue —
-`needs-decision` and a comment carrying the question. Measured twice on 2026-09-14: **#2012**'s child had
-its `AskUserQuestion` refused and **#2011** wrote a Tier B decision, both only to their final message, so
-the parent found an OPEN Issue with `in-progress` and no question. The child is the only process that
-knows the question, so it records the park itself rather than leaving the parent to reconstruct it.
+(joshuafolkken/kit#2034). A headless child's only route to ask a person is to park the Issue — measured
+on #2012 and #2011, whose questions reached only their final message. Rationale:
+`docs/maintainers/pre-gate-cut-rationale.md` → "Why the rules are guards, not prose".
 
 **The record, before the Telegram, is the park procedure exactly** — `needs-decision` plus a comment
 carrying the question, the options, and whether work was stashed. Its single source is
@@ -299,18 +243,16 @@ would otherwise leave the Issue bare.
 
 ### The stop notify refuses until the park is recorded
 
-**This was prose that would have fired never**: a step a child is free to skip under time pressure is
-the step it skips. So `pnpm josh rule:guard` **refuses `pnpm josh notify --task-type confirmation`**
-while this checkout is a lane child — the mark `JOSH_LANE_CHILD` names this lane's own issue — handing
-back the park commands.
+`pnpm josh rule:guard` **refuses `pnpm josh notify --task-type confirmation`** while this checkout is a
+lane child — the mark `JOSH_LANE_CHILD` names this lane's own issue — handing back the park commands.
 
 - **It fires for a marked child and nowhere else.** A person's own `fullrun` carries no mark and sends
   its stop notify untouched.
 - **It fires once per run.** The child records the park and reissues the same notify; a
   `needs-human-review` or `already-done` stop reissues after the one delivery, its label already on the
   Issue.
-- **The park state is not readable synchronously.** A `PreToolUse` guard makes no network call and the
-  park is a GitHub label, so the delivery is a checklist — one wasted reissue on the compliant path is safe.
+- **The park state is not readable synchronously**, so the delivery is a checklist — one wasted reissue
+  on the compliant path is safe.
 
 This section is the single source of the lane-child park rule; `scripts/rules/lane-park.ts` implements
 the trigger, `scripts/rules/lane-park.test.ts` pins it, and the row joins the enumeration in
@@ -318,18 +260,11 @@ the trigger, `scripts/rules/lane-park.test.ts` pins it, and the row joins the en
 
 ### The interactive ask is refused one call earlier
 
-**The stop-notify guard fired one tool-call too late** (joshuafolkken/kit#2201). A child that reaches
-for `AskUserQuestion` never reaches the notify: the harness refuses an interactive ask in a headless
-session by **ending the turn**, so the notify guard never fires and the question dies in the exit
-record's `permission_denials`. Measured on 2026-09-20 inside `backlogrun #2163 --only`: **#2178**'s
-child hit a Tier B branch, called `AskUserQuestion`, was refused, and left an OPEN Issue with
-`in-progress` and no question — the failure joshuafolkken/kit#2034 set out to prevent, one call
-upstream.
-
-So `pnpm josh rule:guard` **refuses `AskUserQuestion` for a marked lane child**, one call before the
-stop it would have reached. A hook deny returns to the model rather than ending the turn, so the
-refusal becomes an instruction — park the question. It fires on **every occurrence** and stays silent
-for a person working in a lane.
+(joshuafolkken/kit#2201) The harness refuses an interactive ask in a headless session by **ending the
+turn**, so the notify guard never fires — #2178's child did exactly that, the failure
+joshuafolkken/kit#2034 set out to prevent, one call upstream. So `pnpm josh rule:guard` **refuses
+`AskUserQuestion` for a marked lane child**; the deny returns to the model, and the instruction is to
+park the question. It fires on **every occurrence** and stays silent for a person working in a lane.
 
 **A child that slips past it is still recoverable** — `pnpm josh run:ending` lifts the refused ask out
 of the exit record's `permission_denials` into the `abandoned` verdict's park basis, so the parent puts

package/.github/workflows/pr-classification.yml

@@ -15,6 +15,13 @@ on:
 # nothing here needs it: every run reads the pull request's labels as they stand when it runs, not as
 # its event carried them, so whichever suite GitHub counts as newest holds a current verdict.
 
+# The same safe-chain installer pin as ci.yml — the release and its install-safe-chain.sh SHA-256.
+# `pnpm dlx … setup-ci` left only shims, so the install below ran without a scan (joshuafolkken/kit#2765).
+# `josh latest` moves both together, in this file and in ci.yml.
+env:
+  SAFE_CHAIN_INSTALLER_VERSION: 1.5.20
+  SAFE_CHAIN_INSTALLER_SHA256: 0ad25efe15d1fa56105157a454d647223e78eb0c53d1f85e3d10afcd722e7bfd
+
 jobs:
   classification:
     name: Release classification
@@ -63,7 +70,11 @@ jobs:
             ${{ runner.os }}-pnpm-store-
 
       - name: Setup safe-chain
-        run: pnpm dlx @aikidosec/safe-chain@1.5.20 setup-ci
+        run: |
+          installer="$RUNNER_TEMP/install-safe-chain.sh"
+          curl --proto '=https' -fsSL "https://github.com/AikidoSec/safe-chain/releases/download/$SAFE_CHAIN_INSTALLER_VERSION/install-safe-chain.sh" -o "$installer"
+          echo "$SAFE_CHAIN_INSTALLER_SHA256  $installer" | sha256sum -c -
+          sh "$installer" --ci
 
       - name: Install dependencies
         env:

package/CLAUDE.md

@@ -89,7 +89,7 @@ Read from a `.env` file at the project root by the AI scripts, `josh port` and `
 
 ### Dependency overrides (`pnpm-workspace.yaml` / `package.json`)
 
-- **Effective overrides live in `pnpm-workspace.yaml`.** pnpm 11 and 12 ignore `pnpm.overrides` in `package.json` (verified with pnpm 12.6.0). Check both files for existing declarations, but never count the ignored package field as an effective override. **An absent or empty `pnpm.overrides` is not evidence that the project has no overrides.**
+- **Effective overrides live in `pnpm-workspace.yaml`.** pnpm 11 and 12 ignore `pnpm.overrides` in `package.json`. Check both files for existing declarations, but never count the ignored package field as an effective override. **An absent or empty `pnpm.overrides` is not evidence that the project has no overrides.**
 - **NEVER** remove or modify entries in **either** location without explicit user approval.
 - **NEVER** modify the `devEngines` field in `package.json` without explicit user confirmation. It pins the development toolchain (e.g. pnpm version); silently changing it can break CI or other contributors' environments.
 - **The check is a command you run, not a conclusion you reach.** After `pnpm update`, `josh latest`, or any dependency-update command, **load the `dependency-update` skill** and follow its procedure before reporting anything about the pins.
@@ -144,7 +144,7 @@ Before every `git commit` (follow-up commits included), self-review against `pro
 
 ## Doc Sync Rules
 
-**`CLAUDE.md` is the single source for every agent rule.** `AGENTS.md` and `GEMINI.md` carry no rules — a rule addition, spec change or wording fix is written **once**, here (joshuafolkken/kit#963). The structural test [scripts/document/ai-document-pointers.test.ts](https://github.com/joshuafolkken/kit/blob/main/scripts/document/ai-document-pointers.test.ts) fails if a rule body reappears in either, or if a pointer loses the sentence that sends an agent here.
+**`CLAUDE.md` is the single source for every agent rule.** `AGENTS.md` and `GEMINI.md` carry no rules — a rule addition, spec change or wording fix is written **once**, here (joshuafolkken/kit#963).
 
 **docs/ must stay in sync with the package.** When `josh bump` changes the version, review `docs/` and update any section describing changed behavior (new/renamed commands, `josh init` / `josh sync` behavior, new config files) before committing.
 
@@ -166,7 +166,7 @@ Before every `git commit` (follow-up commits included), self-review against `pro
 
 `kickoff`, `fullrun`, `halfrun` and `backlogrun` are the Issue-driven shorthand commands. **Their procedures are not resident** — they live in the `workflow-commands` skill. **What stays here is decided by one question: must the rule fire on a turn where no skill was loaded?** Explicit invocation, the mid-workflow stop notification, the `overrides` / `devEngines` prohibitions, the UI-verification gate and the three `epic:*` rules below all do; everything a run reaches only after reading the skill is routed to, never restated (`SKILL.md` → "What stays resident, and what is read from here").
 
-**Read the skill before running any part of a command — including the first `gh` call.** Acting from the table below alone is not enough: the table says which command was typed, not how to run it.
+**Read the skill before running any part of a command — including the first `gh` call.**
 
 | Typed keyword            | What it does                                                                                                                                                          | Read first                                                       |
 | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |