@joshuafolkken/kit 1.1035.0 → 1.1094.0

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

@@ -19,7 +19,7 @@ Tier C (`CLAUDE.md`). Name what was filed in the completion report. An observati
 on is dropped rather than filed.
 
 **The filing ceilings still apply.** Count this filing in the ten-Issue limit for the run. An
-observation is discretionary, so above 30 open Issues in the target repository, close one first or do
+observation is discretionary, so above the WIP cap in the target repository, close one first or do
 not file (`prompts/collaboration-workflow/wip-cap.md`). File it with `pnpm josh issue:file`
 (`issue-scout.md`), which lints the body against `prompts/collaboration-workflow/issue-template.md`,
 applies the classification labels it declares, runs the duplicate scan, and runs `epic:bundle` on the
@@ -32,13 +32,7 @@ The detail below is read at the filing decision, and the marker suite pins the r
 
 ### The depth test — a discretionary filing cites the product work it blocked
 
-**A run that has just spent an hour inside the workflow tooling files findings about the workflow
-tooling** (joshuafolkken/kit#1698). Measured on the `backlogrun` of 2026-09-09: 5 Issues shipped and
-15 filed, of which 13 were discretionary — and all 20 were about this package's own run
-orchestration or the tools that measure it, with not one change a consumer of the package would see.
-**A listing that measures itself has no natural stopping condition**, because every measurement
-creates something new to measure. So the condition comes from outside, and **depth is what supplies
-it — read off the subject rather than judged**:
+**Depth is read off the subject rather than judged** (joshuafolkken/kit#1698):
 
 | Depth | The subject | Where it lives |
 | --- | --- | --- |
@@ -48,7 +42,7 @@ it — read off the subject rather than judged**:
 
 **The depth is recorded on the Issue as a label, and the label is applied when the Issue is filed**
 (joshuafolkken/kit#1729). `depth:0`, `depth:1` and `depth:2` are the three, defined once in
-`scripts/git/issue-labels.ts` and carrying no definition of their own — **the table above is the
+`scripts/issue/issue-labels.ts` and carrying no definition of their own — **the table above is the
 single source**, and a label description that paraphrased it would be a second copy of the rule.
 **Every filing route applies one**, this route and the other three of §2d's table alike: a `new`
 entry point, a `route:tier-a` prerequisite, a `route:interrupt`, a split child and a review round
@@ -62,7 +56,7 @@ gh api repos/{owner}/{repo}/issues/<N>/labels -f 'labels[]=depth:1'   # an Issue
 
 **Create the three once per repository**, before the first filing that applies one — REST auto-creates
 a missing label with a generated color and no description, and the three lines below are what give
-each a stable color a reader can scan a listing by. `DEPTH_LABELS` in `scripts/git/issue-labels.ts`
+each a stable color a reader can scan a listing by. `DEPTH_LABELS` in `scripts/issue/issue-labels.ts`
 is the single source of the colors and descriptions, and `scripts/rules/issue-depth-label.test.ts` keys
 these lines to it so the two cannot drift.
 
@@ -75,16 +69,14 @@ gh api repos/{owner}/{repo}/labels -f name=depth:2 -f color=c5def5 -f descriptio
 - **It is read off the subject, exactly as the table is** — so applying it is not a judgement and not
   a person's to make, which is what separates it from `auto-ok` and `needs-human-review`. Those two
   decide what a run may do; this one records what an Issue is about and withholds nothing.
-- **Applied at filing, not at completion.** A depth assigned when the work finishes is assigned by
-  whoever happens to close it, and the share below is a question about the *open* backlog — an Issue
-  that never carried the label was never in the numerator's reach.
+- **Applied at filing, not at completion.**
 - **An Issue carrying more than one counts as the lowest depth present**, the one closest to the
-  consumer. It is a fixed tie-break rather than a preference: without one the same backlog measured
-  twice can answer twice, which is the whole defect joshuafolkken/kit#1729 was filed for.
+  consumer.
 - **An `epic` takes no depth label**, because it has no subject of its own to read one off — its
   children carry the subjects, and the share below excludes it from the denominator for that same
-  reason. A depth label present on an Issue the count skips is exactly the ambiguity this section
-  exists to remove.
+  reason.
+
+Rationale: `docs/maintainers/observation-filing-rationale.md` → "Why the depth label is applied at filing".
 
 - **A discretionary observation at depth 1 or deeper is filed only where it can cite the depth-0 work
   it stopped or delayed** — named as an Issue number or a run, never as "this would slow runs down".
@@ -96,12 +88,8 @@ gh api repos/{owner}/{repo}/labels -f name=depth:2 -f color=c5def5 -f descriptio
 - **`route:tier-a` and `route:interrupt` do not take it either**, at any depth: a filing the run
   cannot proceed without is already citing its own blockage.
 - **A depth-2 filing — one whose subject is what measures a run — carries a further requirement, on
-  top of the depth-0 citation above rather than in place of it** (joshuafolkken/kit#1975). The
-  citation the depth-0 gate asks for is one a slow run can always produce, so it barely bites on a
-  measurement Issue: "runs are slow" and "the diff is large" both name depth-0 work, while the number
-  the Issue proposes to produce changes nothing — and a listing that measures itself has no natural
-  stopping condition precisely there. So a discretionary depth-2 filing states two things the depth-0
-  citation does not force:
+  top of the depth-0 citation above rather than in place of it** (joshuafolkken/kit#1975). A
+  discretionary depth-2 filing states two things the depth-0 citation does not force:
   - **The decision the number would change, named** — the Issue number holding the choice it is
     waiting on, or a decision a person is about to make. "Slow", "large" and "worth knowing" are not a
     decision.
@@ -115,15 +103,15 @@ gh api repos/{owner}/{repo}/labels -f name=depth:2 -f color=c5def5 -f descriptio
   depth-0 observation does not take it because it is the product, and a review round cap's branch-2
   filing (below) clears its own bar and never reaches this one.
 
+Rationale: `docs/maintainers/observation-filing-rationale.md` → "Why depth gates a discretionary filing".
+
 **It governs this route only — the fourth row of §2d's table.** A review finding routed to branch 2
 of `prompts/review.md` → "Review round cap" is filed under that section's own bar — a confirmed
 defect reaching a runtime path, with a written failure scenario — and **does not take the depth
 test**: it has already cleared a bar this route has not, so gating it on a citation as well would
 drop the one kind of finding both documents agree is never dropped. **That bar is the reason, and the
-subject's depth is not** — the sentence here used to say that a defect in a `josh` command's behavior
-is depth 0 by construction, and joshuafolkken/kit#1694 and joshuafolkken/kit#1703 are both branch-2
-filings whose subject is the epic tooling, which the table above puts at depth 1
-(joshuafolkken/kit#1675).
+subject's depth is not.** Rationale: `docs/maintainers/observation-filing-rationale.md` → "Why a
+review branch-2 filing skips the depth test".
 
 **This is not the count cap that was rejected.** A cap is rationing — past the number the finding is
 lost, and nothing about it says which findings were worth having. This changes what counts as a
@@ -133,34 +121,26 @@ finding at all, so what it excludes is excluded for a reason a reader can check.
 a depth-2 Issue that *proposes* a measurement; a pull request that *adds* one — a new report column,
 section, scope or subcommand, a diagnostic step — states in its body the reader that consumes it: the
 Issue number that read the value to decide something, or the path of the rule that reads it. **A
-measurement with no reader is not added** — this is joshuafolkken/kit#2012's test, the one that
-retired every column no decision reads, moved to the moment a column is proposed so the retirement
-never has to be filed again. `route:tier-a` and `route:interrupt` carry over unchanged.
+measurement with no reader is not added** (joshuafolkken/kit#2012). `route:tier-a` and
+`route:interrupt` carry over unchanged.
 
 ### The depth-0 share — what is counted
 
-**joshuafolkken/kit#1698 set a measurable target: the share of open Issues at depth 0** — 3/23
-≈ 13% on 2026-09-09 (joshuafolkken/kit#1729). Counted by eye it is not reproducible: done again on
-2026-09-10 it produced 3/14 ≈ 21%, and the two figures **are not comparable**: they took different
-denominators, and neither said which. So the denominator is fixed here as a rule rather than left to
-the counter.
+**The depth-0 share is the share of open Issues at depth 0** (joshuafolkken/kit#1698,
+joshuafolkken/kit#1729).
 
 **The denominator is a rule, not a choice, and this is it:**
 
-- **Counted: every open Issue that does not carry `epic`.** An epic is a container for other Issues
-  rather than a deliverable of its own — counting one counts its children twice, and an epic has no
-  subject of its own to read a depth off.
+- **Counted: every open Issue that does not carry `epic`.**
 - **`route:tier-a` and `route:interrupt` are counted like anything else.** The depth test above
-  exempts them from its *citation* requirement; it never said they are not work. Excluded, a run
-  could improve the share by choosing a filing route.
-- **An Issue with no depth label is in the denominator**, counted separately as `unlabelled`. Left
-  out, the share would improve every time a filing skipped the label — the one direction a
-  measurement must never be able to move on its own.
+  exempts them from its *citation* requirement; it never said they are not work.
+- **An Issue with no depth label is in the denominator**, counted separately as `unlabelled`.
 - **The numerator is what is left**: open, non-epic Issues carrying `depth:0`.
 
-**Two readings of the same backlog give the same number**, which is what the hand counts could not
-do: the denominator is a rule rather than a choice, so nothing in the count is left to the counter's
-judgement.
+**Two readings of the same backlog give the same number**: nothing in the count is left to the
+counter's judgement.
+
+Rationale: `docs/maintainers/observation-filing-rationale.md` → "Why the depth-0 denominator is fixed".
 
 **What the number is for is not decided here.** Changing what `backlog:next` offers on the strength
 of it, and setting a target value, are both deliberately out of scope until the current value has
@@ -168,12 +148,9 @@ been measured the same way more than once (joshuafolkken/kit#1729 → 範囲外)
 
 ### The ledger — where an observation that cannot cite a blockage goes
 
-**"Not filed" used to mean "gone", and that is what walked the depth test past itself.** The
-completion report was the only place such an observation could land, and a completion report is
-read once and then scrolls away — so the next run met the same thing as a first sighting, forever.
-joshuafolkken/kit#1726 is the worked case: its own body says the depth test would not have filed it,
-and it was filed anyway, because **discarding it was the only alternative on offer**
-(joshuafolkken/kit#1728).
+**An observation the depth test turns away is recorded in the ledger, not discarded**
+(joshuafolkken/kit#1728). Rationale: `docs/maintainers/observation-filing-rationale.md` → "Why the
+ledger exists".
 
 - **The destination is the `docs/maintainers/observations/` directory in the repository the
   observation is about** — the same repository the Issue would have been filed into — **one file per
@@ -221,9 +198,8 @@ A sample, in the shape a real entry takes:
 
 **`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** because this skill is distributed to every repository that consumes
-the package and `docs/` is not — a rule that named a definition the reader never received would
-leave every consumer's ledger shaped by hand.
+here rather than in the ledger** (`docs/maintainers/observation-filing-rationale.md` → "Why the
+ledger exists").
 
 **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 count what the ledger already holds
@@ -244,27 +220,17 @@ rather than by editing the one already written.
 
 **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, and whose sole previous destination was nothing (joshuafolkken/kit#1698's gate stands
-unchanged).
+could not.
 
 ### The commit path — how an appended line reaches the default branch
 
-**An append nobody commits is an append nobody can count** (joshuafolkken/kit#1756). The ledger was
-given a destination and no route out of the working tree the line was written in, and **structurally
-nobody was going to commit one**: the parent session that appends never runs `pnpm josh git`, a child
-runs it inside a lane work tree that cannot see the parent's checkout, and in the primary checkout
-`git add -u` swept the line into whatever unrelated pull request that run was opening. Measured on
-the day the ledger shipped, `docs/observations.md` had exactly one commit — the one that created
-it — and seven lines had never left a working tree. **So the repeat count below was reading a file
-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 append nobody commits is an append nobody can count** (joshuafolkken/kit#1756). Rationale:
+`docs/maintainers/observation-filing-rationale.md` → "Why the ledger has a commit path".
 
 - **A run's appended lines ride its own commit** (joshuafolkken/kit#2763). `pnpm josh git` stages
   `docs/maintainers/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. 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.
+  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.
@@ -280,10 +246,7 @@ joshuafolkken/kit#1728 created the ledger to end.
   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** (joshuafolkken/kit#2919). 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. Lanes once wrote to the primary checkout's single file
-  instead (joshuafolkken/kit#2419) and a `backlogrun` flushed them all at `run:carry --end`
-  (joshuafolkken/kit#2492); another run's stash of that checkout took the lines before the flush saw
-  them, so neither route remains. **Nothing is held in the primary checkout for later.**
+  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
@@ -300,10 +263,9 @@ joshuafolkken/kit#1728 created the ledger to end.
 
 ### The second sighting is what files it
 
-**A repeat is the citation.** joshuafolkken/kit#1698 asked a discretionary filing to be pulled by a
-blockage rather than pushed by a sighting; an observation recorded twice has been pulled — it came
-back on its own, which no single sighting can demonstrate. So the gate has a second way through, and
-it is counted rather than judged:
+**A repeat is the citation**, so the gate has a second way through, and it is counted rather than
+judged (rationale: `docs/maintainers/observation-filing-rationale.md` → "Why a second sighting
+files"):
 
 - **On the count answering exactly `1`, the observation is filed**, at depth 1 or deeper, with no
   depth-0 citation — `1` and not "1 or more", because a higher count means the Issue was already
@@ -336,19 +298,12 @@ could bite later" line (`backlogrun-child.md` → "What the summary carries, and
 parent files what survives — under the depth test above, and inside the run's ceiling.
 
 **A delegated child does not append to the ledger either — the parent collapses the duplicates and
-appends what is left.** The ledger's whole value is that one key means one phenomenon, and a child
-holding one Issue's worth of context cannot tell its observation from the sibling lane's: eight
-children appending in parallel would write the same thing under eight keys, and every one of them
-would then read as a first sighting. The child's route is unchanged and is the only one it has —
+appends what is left.** The child's route is unchanged and is the only one it has —
 the summary's "Observations that could bite later" line — and the parent chooses the key, checks the
-count and writes the line.
-
-**Two reasons, and a child can solve neither for itself.** It holds one Issue's worth of context, so
-**it cannot tell its observation from the one a sibling filed twenty minutes earlier** — the 15
-filings of 2026-09-09 were collapsed to 12 within that same day, which means they were collapsible
-at the moment they were made. And **the 10-per-run ceiling for this route is the parent's to
-count**: six children counting two or three filings each never reach it, which is why it did not
-fire once on the run that filed fifteen.
+count and writes the line. **The 10-per-run ceiling for this route is the parent's to count.**
+
+Rationale: `docs/maintainers/observation-filing-rationale.md` → "Why a delegated child neither files
+nor appends".
 
 **This file is the single source of every procedure above**, and `SKILL.md` → §2i is the single
 source of the rule they carry out; nothing under `prompts/collaboration-workflow/` restates either

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

@@ -7,7 +7,7 @@ from the gate onward. Rationale: `docs/maintainers/pre-gate-cut-rationale.md`
 
 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 (joshuafolkken/kit#1933), at a context threshold _during_ implementation.
+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.
 
@@ -23,7 +23,7 @@ verification the fresh process runs on the tree.
 
 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).
+by the model reading the shape of its own prompt.
 
 ### The dispatch mark
 
@@ -44,16 +44,15 @@ checkout, a cut in a lane.
 
 ## Taking the cut
 
-**The order is fixed in the chain** (joshuafolkken/kit#2177): `chain-rule.md` step 1 issues
+**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
-(joshuafolkken/kit#2312), so a short lane with nothing to drop is answered `under-threshold` and walks on
+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:
 
 ```bash
-pnpm josh run:cut <N>          # alias: josh rct
+pnpm josh run:cut <N>
 ```
 
 - `cut` (0) — record written and handed to the lane's launch owner (OpenAI supervisor starts the
@@ -72,25 +71,25 @@ 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.** 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:
+**This step was carried as prose and fired exactly never.** In 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. 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
+- **It fires only when the recent-window 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 once per run.** A refusal that repeated would wedge the runs that obeyed.
+- **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`; `scripts/rules/pre-gate-cut.test.ts` pins it.
+`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".
 
 ## Resuming — the fresh process's entry check
 
@@ -106,8 +105,7 @@ pnpm josh run:cut --resume <N>
 - `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
-  (joshuafolkken/kit#1933). Skip the title, the plan, the fresh hold claim and the split assessment,
+- `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
   (joshuafolkken/kit#1935). This process was woken **after** its own cut. **End the turn quietly and do
@@ -154,7 +152,7 @@ decisions are read back from the issue. Rationale:
 
 ## The implementation-phase cut — a lane child cuts before the gate too
 
-The **implementation-phase cut** (joshuafolkken/kit#1933) caps the context accumulated _during_
+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**.
 
@@ -162,15 +160,15 @@ implementation**.
 
 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`, joshuafolkken/kit#2312), single-sourced at `backlogrun-progress.md` → "The
+`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.
 
 ### 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** — measured across five lanes, the cut fired
-**0 times** while 33.9% of their requests ran past 200,000 tokens. Rationale:
+**This step was carried as prose and fired exactly never** — the cut fired **0 times** while 33.9% of
+lane 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
@@ -185,7 +183,7 @@ 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
+- **It fires on every threshold crossing, not once per run** — 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
@@ -196,8 +194,8 @@ crossing one successor.
 - **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
+`scripts/rules/implementation-cut.ts` implements the trigger, 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.**
@@ -206,12 +204,10 @@ edits, not after each one.**
 
 **`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.
+(10) requests, not the whole session**. The value is computed by
+`scripts/cost-runtime/context-cut-payback.ts`, its single source.
 
-**The cut is conditional** (joshuafolkken/kit#2312): taken only when the recent-window per-request cost
+**The cut is conditional**: 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.
@@ -227,8 +223,8 @@ 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 is to park the Issue — measured
-on #2012 and #2011, whose questions reached only their final message. Rationale:
+(joshuafolkken/kit#2034). A headless child's only route to ask a person is to park the Issue (#2012,
+#2011). 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
@@ -255,21 +251,22 @@ lane child — the mark `JOSH_LANE_CHILD` names this lane's own issue — handin
   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
+the trigger, and the row joins the enumeration in
 `prompts/collaboration-workflow/rule-delivery.md`.
 
 ### The interactive ask is refused one call earlier
 
 (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.
+turn**, so the notify guard never fires (#2178 — 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. Rationale:
+`docs/maintainers/pre-gate-cut-rationale.md` → "Why the rules are guards, not prose".
 
 **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
-it into the park comment. `scripts/rules/lane-interactive-ask.ts` implements the trigger,
-`scripts/rules/lane-interactive-ask.test.ts` pins it, and `scripts/agent/interactive-ask.ts` is the
+it into the park comment. `scripts/rules/lane-interactive-ask.ts` implements the trigger, and
+`scripts/agent/interactive-ask.ts` is the
 shared extractor the guard and `run:ending` both read.
 
 This file is the single source of the rule.

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

@@ -31,7 +31,7 @@ pnpm josh issue:file "<title>" --body-file <body-file> --depth <n> --route tier-
 
 The command lints the body against `prompts/collaboration-workflow/issue-template.md`, applies the
 classification labels it declares, and runs the duplicate scan and `epic:bundle` itself
-(`docs/josh-commands.md` → `josh issue:file`).
+(`docs/josh-commands-automation.md` → `josh issue:file`).
 
 Every "file the prerequisite" 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

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

@@ -0,0 +1,36 @@
+# `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
+(joshuafolkken/kit#3023). **Read `fullrun.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, never a second copy of the procedure.
+
+## The difference — the entry
+
+`prrun #<N>` opens with `pnpm josh run:entry <N> --to prrun` where `fullrun` passes no `--to`
+(`SKILL.md` → §2k): a planned Issue starts at the implementation, a `halfrun` stop is adopted and
+resumes at the gate, and an Issue already stopped by a `prrun` is reached — report the stage line and
+stop. A merged Issue is reached too, but the `entry #<N>` line after the stage line answers it (§2k).
+
+## The difference — the end of the run
+
+Where `fullrun` runs `pnpm josh followup` and merges, `prrun` does three things and stops:
+
+1. **Watch the pull request to mergeable** — `pnpm josh followup "<title> #<N>" --no-merge`
+   (`followup.md` → "Run `pnpm josh followup`", read in the same turn): required CI green and the AI
+   review findings resolved. A failure stops the run exactly as it stops a `fullrun`.
+2. **Mark the stop — `pnpm josh run:hold <N> --prrun-stop`.** It records the commit the pull request is
+   on in this run's own hold, the record `fullrun #<N>` adopts (its prrun resume, `working-tree-hold.md`). **The hold and `in-progress` stay**: the run is not finished until the merge's tail runs.
+3. **Send a `confirmation` Telegram with the resume commands, then stop.** **`fullrun #<N>` first** —
+   its `run:entry` reads where the pull request stands and resumes from there; the direct command
+   follows for finishing without an agent:
+   `pnpm josh notify --task-type confirmation --issue-url "<issue-url>" --body=$'prrun ready to
+   merge: <pr-url>\nNext: fullrun #<N>\nAfter a manual merge, without an agent: pnpm josh followup
+   "<title> #<N>"'`. The stop report names the same two, in the same order.
+
+**Invoking `prrun` is _not_ authorization to merge** — never run `pnpm josh followup` without
+`--no-merge` in a `prrun`. After a person merges by hand, the same `pnpm josh followup "<title> #<N>"`
+runs only the post-merge tail (`followup.md`).
+
+`prrun new`: `fullrun new` up to the pull request, then the three steps above with the filed number.

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

@@ -65,7 +65,7 @@ Issue, as after any filing.
 input, so the next run picks the improvements up without waiting for a person. **`backlogrun-steps.md` →
 "What one invocation approves" is that carve-out'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
-ten-per-invocation ceiling, the WIP cap of 30, `--max`, the 150,000-token session budget and the 8-hour
+ten-per-invocation ceiling, the WIP cap, `--max`, the 150,000-token session budget and the 8-hour
 whole-run bound.
 
 **Close with `pnpm josh run:carry --retrospective --summary "<result>" --owner "$PPID"`.** It marks the

package/.claude/skills/workflow-commands/working-tree-hold.md

@@ -11,9 +11,9 @@ a `new` entry files its Issue**, because a run stopped after the filing has alre
 artifact it should not have created.
 
 ```bash
-pnpm josh run:hold <N>        # a `#N` entry point ; alias: josh rh
+pnpm josh run:hold <N>        # a `#N` entry point
 pnpm josh run:hold            # a `new` entry point, before the issue exists
-pnpm josh run:release <N>     # that same run releasing its own record ; alias: josh rr
+pnpm josh run:release <N>     # that same run releasing its own record
 pnpm josh run:release         # the bare form releases the unnumbered run's own record
 pnpm josh run:release --force # a record left behind by a run that has ended
 ```
@@ -63,12 +63,13 @@ or release once the work is done; only an expired record over a clean tree is re
 **The batch entry points claim per child, not per batch.** `backlogrun` never
 call it themselves; each child runs the `fullrun` procedure, so it claims on entry and `pnpm josh
 followup` releases it at that child's merge. The command's behavior and the answer table are
-`docs/josh-commands.md` → "`josh run:hold` / `josh run:release`"; this file is the single source of
+`docs/josh-commands-automation.md` → "`josh run:hold` / `josh run:release`"; this file is the single source of
 the procedure.
 
 ## The halfrun resume
 
-**`fullrun #<N>` after a `halfrun` stop resumes it instead of claiming** (joshuafolkken/kit#2796). The
+**`fullrun #<N>` or `prrun #<N>` after a `halfrun` stop resumes it instead of claiming**
+(joshuafolkken/kit#2796, #3042). The
 stop is **recorded, never inferred**: the `halfrun` ends with `pnpm josh run:hold <N> --halfrun-stop`,
 which marks its own record (re-keying a `halfrun new`'s unnumbered one to the filed issue) — a
 `halfrun` still implementing or a `backlogrun` child leaves the same hold over the same dirty tree, and
@@ -79,3 +80,22 @@ halfrun`. **Skip the title, the plan, the split assessment, `git switch main &&
 issue (`pnpm josh issue:read <N>`), then run the gate **in full** from the refactor (`chain-rule.md` →
 "Run the review-to-merge chain") — a fix made during the manual check has had no gate — and ship as
 any `fullrun` does.
+
+## The prrun resume
+
+**`fullrun #<N>` after a `prrun` stop resumes it the same way** (joshuafolkken/kit#3023). The `prrun`
+ends with `pnpm josh run:hold <N> --prrun-stop`, which writes the commit its pull request is on into its
+own record; only a record carrying that commit is adopted. `run:entry` asks the session budget, adopts
+the hold with the `fullrun` mark and prints one of three tokens — read, never inferred:
+
+- **`resume: prrun-merged`** — a person merged the pull request. Run `pnpm josh followup "<title>
+  #<N>"` alone: it detects the merge and runs only the post-merge tail.
+- **`resume: prrun-merge`** — the branch is still on the stop's commit, both here and on the pull
+  request, and the tree is clean, so what was verified is what would merge. Skip the gate and the
+  review; run `pnpm josh followup` to merge.
+- **`resume: prrun-gate`** — the branch moved (locally, or by a push made on GitHub), its pull request
+  could not be read, or the tree is dirty: a person changed something. Run the
+  gate **in full** and the review (`chain-rule.md` → "Run the review-to-merge chain"), then ship as any
+  `fullrun` does.
+
+All three skip the title, the plan, the split assessment and the implementation.