@joshuafolkken/kit 1.1010.0 → 1.1050.0

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

@@ -84,7 +84,7 @@ pnpm josh notify --task-type failure --issue-url "<issue-url>" --body "<the reas
 **The matching itself is unchanged, and so is the reason it is mechanical.** The instruction the mechanical read replaced was skipped in two runs out of three on the day it was measured, and one of those two could not have succeeded by eye at all: `AI_COPY_DIRECTORIES` holds directories, so a distributed path such as `.claude/skills/workflow-commands/backlogrun.md` appears in no list textually.
 
 ```bash
-pnpm josh sync:scope    # managed | clean, naming which list claimed each path; alias: josh sys
+pnpm josh sync:scope    # managed | clean, naming which list claimed each path
 ```
 
 - **There is no flag to pass and nothing to approve.** `--managed-config-ignore-reason` is gone with the stop it existed to get past.
@@ -99,7 +99,7 @@ pnpm josh sync:scope    # managed | clean, naming which list claimed each path;
 **The answer: `pnpm josh release:scope`.**
 
 ```bash
-pnpm josh release:scope          # → required | skip | unknown ; alias: josh res
+pnpm josh release:scope          # → required | skip | unknown
 pnpm josh release:scope --json   # the same answer as one JSON object
 ```
 

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

@@ -55,7 +55,8 @@ that covers the same work stops the run rather than filing a second Issue (`SKIL
 `<N>`. (3) Add
 `in-progress` (as above). (4) Post the agreed plan in the session language: fill the body if blank,
 otherwise add a comment. (5) If the working tree already has staged or modified files,
-`git stash push -m "fullrun new: pre-existing changes"` first. (6) `git switch main && git pull`. (7)
+`git stash push -m "fullrun new: pre-existing changes" -- ':!docs/maintainers/observations'` first
+(joshuafolkken/kit#2919). (6) `git switch main && git pull`. (7)
 `pnpm josh latest:scope`; on `required` run `josh latest` and load the `dependency-update` skill; on
 `skip` neither runs (`latest-gate.md` is the single source). If you stashed in (5),
 `pnpm josh stash:pop "fullrun new: pre-existing changes"` — by message, never a positional `git stash
@@ -78,8 +79,8 @@ release:scope` and close the completion summary with what it answered** (`follow
 ## The release ask — the last step of either form
 
 **One call folds the post-merge bookkeeping** (joshuafolkken/kit#2372): after the merge, `pnpm josh
-run:tail <N>` commits the observation ledger (`observations:flush` — skipped by a dispatched lane child,
-whose `backlogrun` flushes once at `run:carry --end`; joshuafolkken/kit#2492), reads the completion citations
+run:tail <N>` commits ledger lines written outside any issue's run (`observations:flush`,
+joshuafolkken/kit#2919), reads the completion citations
 (`issue:cite`, given the closed issue and any follow-ups filed this run) and decides the release scope
 (`release:scope`) in one round trip, joining each under its own header. **On the clean path `run:tail`
 runs inside `pnpm josh ship`** as its report step (joshuafolkken/kit#2398), so it is a standalone call

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

@@ -46,7 +46,7 @@ call reports `hold`.
    `pnpm josh latest:scope` — update dependencies only on `required` (`latest-gate.md`), never on every
    run. `run:step` names every later action in order — the verification gate, `pnpm josh followup`,
    `pnpm josh ms`, the release ask — each read at the point-of-use doc the header lists, never
-   re-narrated here (`residency.md` → ordering question).
+   re-narrated here (`residency.md` → "順序の問い").
 
 ## The progress step and the lane-child seam
 

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

@@ -59,7 +59,8 @@ back with fixes, treat each as a new round: implement, re-run `pnpm josh gate`,
 mirror `fullrun new` (1)–(8): derive an English title (or use the provided one) → create the Issue
 (`pnpm josh issue:file "<title>" --body-file <body-file> --depth <n>`, body per
 `prompts/collaboration-workflow/issue-template.md`; its duplicate scan is read per `SKILL.md` → §2e) → add `in-progress` → post the agreed plan → stash
-any pre-existing changes with `git stash push -m "halfrun new: pre-existing changes"`, popped by
+any pre-existing changes with `git stash push -m "halfrun new: pre-existing changes" -- ':!docs/maintainers/observations'`
+(the pathspec keeps the observation ledger in the tree for this run's commit; joshuafolkken/kit#2919), popped by
 message with `pnpm josh stash:pop "halfrun new: pre-existing changes"`, never a positional `git stash pop` →
 `git switch main && git pull` → `pnpm josh latest:scope` → implement → run the gate (as above, `pnpm
 josh test:e2e` run by **you**) → `pnpm josh run:hold <N> --halfrun-stop` → send the `confirmation`

package/.claude/skills/workflow-commands/into-target.md

@@ -39,7 +39,7 @@ new epic" when what gets created is often a single Issue.
   applies depends on what the target is, and promoting rewrites someone else's Issue into a container.
 - **A cross-repository target is written `owner/repo#N`** and inserted from that repository's
   checkout; run there, since `epic --add` reads and writes only the repository it runs from
-  (`prompts/collaboration-workflow/cross-repo-epic.md`). A bare `#N` resolves to this repository's
+  (`.claude/skills/epic-commands/SKILL.md` → "Epics that span repositories"). A bare `#N` resolves to this repository's
   issue of that number.
 - **No suffix leaves the behavior exactly as it was.**
 

package/.claude/skills/workflow-commands/issue-comments.md

@@ -12,7 +12,7 @@ delegated unit executing `fullrun`'s procedure, and the hook keys its once-per-r
 same turn as whatever else the run already needs:
 
 ```bash
-pnpm josh issue:read <N> [<N> ...]     # body and comments, one call per batch; alias: josh ird
+pnpm josh issue:read <N> [<N> ...]     # body and comments, one call per batch
 gh api repos/{owner}/{repo}/issues/<N>/comments --jq '.[] | {user: .user.login, created_at, body}'
 ```
 

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

@@ -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 |
 | --- | --- | --- |
@@ -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,17 +148,19 @@ 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).
-
-- **The destination is `docs/maintainers/observations.md` in the repository the observation is about** — the same
-  repository the Issue would have been filed into. **The count and the append are both run in that
-  repository's checkout**, resolved the way §2c (`target-repository.md`) resolves any cross-repository target, and the file is
-  created on the first append where that repository has none. **The subject decides, never the
+**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
+  issue** (joshuafolkken/kit#2919): 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 §2c (`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
@@ -186,8 +168,8 @@ and it was filed anyway, because **discarding it was the only alternative on off
 - **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** —
-  two lanes appending at once is the ordinary case, and a repeated key is the whole signal, so
-  dropping either side destroys exactly what the file is for.
+  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
@@ -215,21 +197,21 @@ 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 file 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.
+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-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
-for it, in that repository's checkout rather than the working directory. **The `|| true` is not
-decoration**: `grep -c` exits non-zero on a count of zero, which is the first-sighting branch and the
-common one, so without it the step reads as a failed command wherever an exit status is being
-watched. **A missing file is not a count of zero, though** — there `grep` exits 2 and prints no
-number at all, so an empty answer means create the ledger, never that this is a first sighting.
+for it, in that repository's checkout rather than the working directory. **Every file of the
+directory is counted**, because a recurrence is a recurrence whichever issue's file each sighting
+sits in. **The `|| true` is not decoration**: `grep -c` exits non-zero on a count of zero, which is
+the first-sighting branch and the common one, so without it the step reads as a failed command
+wherever an exit status is being watched. **A missing directory is still a first sighting** — `cat`
+complains on standard error and the count is zero; the append below creates the directory.
 
 ```bash
-grep -c '^- k:<slug> |' <that repository's checkout>/docs/maintainers/observations.md || true
+cat <that repository's checkout>/docs/maintainers/observations/*.md | grep -c '^- k:<slug> |' || true
 ```
 
 Free-text comparison is what the key exists to replace, so two lines that read alike under different
@@ -238,60 +220,40 @@ 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.md` with the run's other changes, in the one staging step every entry
+  `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.
 - **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`.
-- **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 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.
+  every file of the ledger first — after moving lines still on an old single-file path
+  (joshuafolkken/kit#2724, joshuafolkken/kit#2919) — and on a broken line leaves the ledger out of the
+  commit and says so; the commit itself goes ahead.
+- **`pnpm josh followup` commits a line appended after the run's commit onto the pull request, before
+  the merge** (joshuafolkken/kit#2919) — a second review round's record is the usual case. 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; the CI wait
+  that follows covers the pushed commit. 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** (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. **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 — most cycles append nothing, and a command that errored
   there would be one nobody runs.
@@ -301,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
@@ -337,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

@@ -18,7 +18,7 @@ another is the failure this section exists to prevent:
 | A defect originating in **another package**                                 | File the upstream Issue and **stop** — Tier A for a first-party target; a third-party one is Tier C, recorded and drafted rather than filed (`CLAUDE.md` → "Cross-package problems"; `prompts/collaboration-workflow/upstream-interrupt.md`) |
 | This Issue was really **several** (a split)                                 | File the children and the epic and **stop** — except under `backlogrun`, whose authorization already covers a batch, so the children are filed and run through (`split-assessment.md`) |
 | Another Issue in **this** repository has to land first (**a prerequisite**) | This section                                                                                                            |
-| Something worth filing that is **none of the three** (**an observation**)   | File it **without asking** — Tier A for a first-party target — and **carry the run straight on**: nothing is stashed, nothing is parked (§2i). **A delegated child does not file here**, and a filing at depth 1 or deeper cites the depth-0 work it blocked; one that cannot cite it goes to `docs/maintainers/observations.md` and is filed on its second sighting — all of them §2i's |
+| Something worth filing that is **none of the three** (**an observation**)   | File it **without asking** — Tier A for a first-party target — and **carry the run straight on**: nothing is stashed, nothing is parked (§2i). **A delegated child does not file here**, and a filing at depth 1 or deeper cites the depth-0 work it blocked; one that cannot cite it goes to the run's own `docs/maintainers/observations/<N>.md` and is filed on its second sighting — all of them §2i's |
 
 **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