@joshuafolkken/kit 1.872.0

package/scripts/rules/piped-verification.ts

@@ -0,0 +1,126 @@
+import { time_shell } from '#scripts/time-runtime/time-shell'
+import { shell_segments } from './shell-segments'
+
+// The rule delivered at the call that pipes a verification command (joshuafolkken/kit#1556).
+//
+// **A pipeline exits with its last command's status.** `pnpm josh gate 2>&1 | tail -40` therefore
+// answers success on a gate that printed `✗ verification gate failed`, and the failure that was
+// caught was caught by a child reading the output rather than by anything the shell reported. The
+// defect is not in `josh gate`, which returns non-zero correctly — it is in how the call is written,
+// and a call is composed fresh every turn.
+//
+// **Delivered rather than written down, and the count is what decided that.** A survey of every
+// document, prompt and skill in this repository found exactly one piped verification example, and it
+// was the repository's own explanation of this bug — so there were no examples to rewrite, and the
+// pipe is invented each time rather than copied. The other candidate, a calling convention, had
+// already been rejected in writing by `scripts/time/time-reported-failure.ts`: a convention is obeyed
+// or it is not. `prompts/collaboration-workflow/output-bounds.md` is the single source for the rule.
+//
+// It lives beside the enumeration rather than inside it because `delivered-rules.ts` is the list —
+// one row per rule — and a row's predicate and refusal text are that rule's own.
+
+// The josh subcommands whose result means pass or fail — the whole reach of the rule, and no more.
+// **The read-only answers are absent deliberately.** `latest:scope`, `review:level`,
+// `review:brief` and `issue:state` print an answer rather than a verdict, and `git log | head` or
+// `gh issue list | head` are not josh calls at all — narrowing a listing is the ordinary way to read
+// one. A trigger wide enough to reach those would refuse on the commonest shape in the transcript,
+// and the enumeration's own rule is that a hook firing on the wrong turn is worse than no hook.
+//
+// **Two more kinds are out, and for reasons rather than by omission.** `pre-commit-type-check` and
+// `pre-push-unit` are run by lefthook rather than typed by anyone, so no call of theirs is ever
+// composed here; and `e2e:retry-check` *reports* whether the preview server crashed rather than
+// passing or failing on it, which puts it with the answers above.
+//
+// **`eval` is in, even though its verdict is the last line rather than the exit code.** Piping it to
+// `tail -1` does keep that line — and throws away the scenario rows the same rule requires next, since
+// a `blocked` verdict has to be attributed before it blocks a merge and a red scenario may predate the
+// change. The Issue that filed this rule names `eval` for that reason.
+const VERIFICATION_COMMANDS: ReadonlySet<string> = new Set([
+	'check',
+	'cspell',
+	'cspell:dot',
+	'eval',
+	'gate',
+	'lint',
+	'lint:eslint',
+	'lint:prettier',
+	'lint:related',
+	'overrides',
+	'ranges',
+	'test',
+	'test:e2e',
+	'test:related',
+	'test:unit',
+])
+
+// **The canonical name of each check, and both spellings still match**: `pnpm josh ga | tail` masks a
+// gate exactly as the long spelling does, and since joshuafolkken/kit#1789 the alias is expanded where
+// the command is read rather than by widening this set with every alias standing for one of its names
+// (joshuafolkken/kit#1643 for the reading). The suite names `pnpm josh ga` for that reason: an
+// expansion that regressed would show up here rather than as a guard that quietly stopped firing.
+function is_verification_command(segment: string): boolean {
+	return shell_segments.is_josh_command(segment, VERIFICATION_COMMANDS)
+}
+
+// A pipeline reports its last command's status, so a check in any earlier segment has its verdict
+// thrown away. `time_shell.discarded_commands` is what decides which segments those are — the shell
+// reading is one rule kept in one place, not a second parser written here. It also decides the two
+// forms this rule stands down on: a pipeline under `set -o pipefail`, which carries the check's
+// status, and a command chain quoted inside a body, which is text rather than a call.
+function is_masked_verification(command: string): boolean {
+	return time_shell.discarded_commands(command).some((segment) => is_verification_command(segment))
+}
+
+// The masking, the two ways out of it and the boundary, in the shape a refusal can carry. **The way
+// out travels with the refusal rather than being named**, because a delivery saying only "do not pipe
+// it" leaves the caller with the same long output and no sanctioned way to read it, which is what put
+// the pipe there in the first place.
+const PIPED_VERIFICATION_REASON =
+	"⛔ piped verification: a pipeline exits with its last command's status, so `pnpm josh gate | " +
+	'tail` reports success on a gate that failed, and the verdict is discarded before anything reads ' +
+	'it. Run the check without the pipe — josh prints its verdict line last, so the harness output cap ' +
+	'keeps it even when the middle is elided. Where the output genuinely has to be narrowed, redirect ' +
+	'it to a file and read ranges from that file, or prefix `set -o pipefail` so the pipeline carries ' +
+	"the check's status. Read the printed verdict either way, never the exit code alone. Read-only " +
+	'listings are untouched — this fires only on a command whose result means pass or fail. The rule ' +
+	'is in `prompts/collaboration-workflow/output-bounds.md`. Reissue this call with no pipe — it ' +
+	'fires once per run and cannot repeat on the call in hand.'
+
+// Every command position on the line: the chain cut `shell_segments` makes, each piece of a pipeline
+// inside it taken on its own.
+//
+// **The quoted spans are blanked first, exactly as `time_shell.discarded_commands` blanks them.** A
+// command chain quoted inside a body is text rather than a call, and this repository's issue bodies
+// quote them constantly — without the blanking the two halves disagree, and
+// `gh issue comment 1 --body "… | pnpm josh gate | …"` reads as a check whose verdict survived.
+function command_pieces(command: string): Array<string> {
+	return shell_segments
+		.segments_of(time_shell.unquoted(command))
+		.flatMap((segment) => segment.split('|'))
+		.map((piece) => piece.trim())
+}
+
+// **The occasion this rule governs: a check whose result means pass or fail, run at all**
+// (joshuafolkken/kit#1643). The trigger fires only on the masked spelling, so a run that never piped
+// one would drop out of the reading entirely and the rate would be taken over runs that masked at
+// least once.
+function runs_verification(command: string): boolean {
+	return command_pieces(command).some((piece) => is_verification_command(piece))
+}
+
+// **Keeping the rule is running that check with its verdict intact** — no pipe, the last position in
+// one, or `set -o pipefail` in front. Judged over the whole command, so a line that masks one check
+// while running another unmasked is not credited for the half it got right.
+function keeps_verdict_intact(command: string): boolean {
+	return runs_verification(command) && !is_masked_verification(command)
+}
+
+const piped_verification = {
+	PIPED_VERIFICATION_REASON,
+	VERIFICATION_COMMANDS,
+	is_masked_verification,
+	keeps_verdict_intact,
+	runs_verification,
+}
+
+export { piped_verification }

package/scripts/rules/poll-loop.ts

@@ -0,0 +1,125 @@
+import { time_shell } from '#scripts/time-runtime/time-shell'
+import { bash_triggers } from './bash-triggers'
+
+// The trigger and the delivered text behind the `poll-loop` row of `delivered-rules.ts`
+// (joshuafolkken/kit#2371). The hand-written wait loop a lane child improvises over a backgrounded
+// command's output file.
+//
+// **The gap `early-heartbeat` left, on purpose.** joshuafolkken/kit#1570's rule refuses a bare
+// `sleep` — a clock timer arming a progress report — and it stands down the moment it sees a loop
+// keyword (`early-heartbeat.ts`'s `LOOP_KEYWORD`), because a loop that ends on a condition is waiting
+// on a thing rather than on a clock. This is that thing: a `while`/`until` loop that sleeps between
+// probes of a command's output file. It never appeared in the heartbeat reading, and it is the larger
+// half of the waste — six lanes lost about 45 minutes, 13% of their wall clock, to it.
+//
+// **The loop does not know when the command finished.** A regex over the output file that never
+// matches waits to the harness block limit; one that matches a mid-run line exits too early. Either
+// way the command's *exit* is not what ends the wait, and each pass spends a full-context round trip.
+// A command backgrounded with `run_in_background` re-invokes the run when it exits — the completion
+// notification is what ends the wait on the task itself, which is the mechanism this row hands back,
+// the same reading joshuafolkken/kit#1510 took for the foreground push (`run-tail.ts`).
+//
+// **It fires on every occurrence**, for the reason `git-force.ts` does: a poll loop wastes the same
+// round trips each time it is armed, so refused-once-and-free-after would put every loop but the first
+// back on the run's self-restraint — the thing that let these loops through in the first place.
+
+// A `while` or `until` header, in either spelling a poll loop reaches for. The trailing whitespace is
+// what separates the keyword from a path that merely begins with it (`until.txt`); a `for` loop is out
+// by omission — it iterates a fixed list rather than probing a state.
+const LOOP_KEYWORD = /\b(?:while|until)\s/u
+// A `sleep` command with any argument — the pause between probes that makes a loop a poll rather than
+// a stream reader. Read anywhere in the line rather than at a command position, because the loop body
+// puts it behind a `do` keyword (`; do sleep 30; done`), which no separator precedes. The argument is
+// matched as any non-space rather than a digit, so a variable duration (`sleep "$INTERVAL"`) is caught
+// as a literal one is — a poll with a configurable interval is still a poll (joshuafolkken/kit#2371,
+// review round 1).
+const SLEEP_COMMAND = /\bsleep\s+\S/u
+// **A loop with no `sleep` is still a poll — a worse one** (joshuafolkken/kit#2421). A lane child ran
+// `until [ -f /tmp/gate-done ]; do if ! kill -0 %1 …; then break; fi; done` for hours: a busy-wait
+// that spun a core on a marker nobody wrote, and slipped through because the rule required the
+// `sleep`. Two headers make a loop a poll with or without one. An `until` header waits for a state to
+// appear by definition — the keyword has no stream-reading or counting use. A `while` header whose
+// condition *probes* a state — a file test, a process probe, a quiet `grep` — is the same wait
+// spelled negatively. A `while` that counts or reads (`while [ "$i" -lt 5 ]`, `while read`) is not.
+// Both are read at a command position only — the start of the line, after a separator, or after a
+// keyword that opens a command list — because without `sleep` there is nothing else to tell a loop
+// header from the word in an argument: `git log --until yesterday` is not a loop (review round 1).
+const COMMAND_POSITION = String.raw`(?:^|[;&|({\n]|\b(?:do|then|else)\s)\s*`
+const UNTIL_HEADER = new RegExp(String.raw`${COMMAND_POSITION}until\s`, 'u')
+const WHILE_HEADER = String.raw`${COMMAND_POSITION}while\s+(?:!\s*)?`
+const PROBE_HEADERS: ReadonlyArray<RegExp> = [
+	String.raw`\[\[?\s+(?:!\s*)?-[defs]\s`,
+	String.raw`test\s+(?:!\s*)?-[defs]\s`,
+	String.raw`(?:kill\s+-0|pgrep)\b`,
+	String.raw`grep\s+-[A-Za-z]*q`,
+].map((probe) => new RegExp(`${WHILE_HEADER}${probe}`, 'u'))
+
+function is_state_wait(plain: string): boolean {
+	return UNTIL_HEADER.test(plain) || PROBE_HEADERS.some((header) => header.test(plain))
+}
+
+// **A `while read … done < file` is a stream reader, not a poll**, even when its body sleeps to
+// throttle processing (joshuafolkken/kit#2371, review round 1). Its condition consumes input rather
+// than probing for a state — a poll never reads its condition, it *tests* it (grep, wc, a file check)
+// — so the completion notification this rule points to has nothing to do with it. A `while read`
+// header is therefore always a stream reader; a line that also carried a separate `until` poll would
+// go un-refused, which fails safe (under-refusal) and is contrived enough not to warrant the added
+// regex the attempt to catch it needed (joshuafolkken/kit#2371, review round 2).
+const STREAM_READER = /\bwhile\s+read\b/u
+
+function is_stream_reader(plain: string): boolean {
+	return STREAM_READER.test(plain)
+}
+
+// **Quoted spans are blanked first, and here that is load-bearing rather than tidy.** This
+// repository's Issue bodies and commit messages quote these very loops constantly — this Issue's own
+// body does — so without the blanking `gh issue comment <N> --body "… until grep …; do sleep …; done"`
+// would read as the poll loop it only describes. `time_shell.unquoted` is the one removal shared with
+// every other trigger, so two readers of one command cannot disagree about a quoting form.
+function is_poll_loop(command: string): boolean {
+	const plain = time_shell.unquoted(command)
+
+	if (is_stream_reader(plain)) return false
+	if (is_state_wait(plain)) return true
+
+	return LOOP_KEYWORD.test(plain) && SLEEP_COMMAND.test(plain)
+}
+
+// The instruction in the shape a refusal can carry: what the loop is about to cost, why the command's
+// exit is the thing to wait on, and the one route that delivers that exit. The measurement is named
+// because it is what makes the rule believable — six lanes, about 45 minutes, 13% of their wall clock.
+const POLL_LOOP_REASON =
+	"⛔ output poll loop: this hand-writes a `while`/`until` wait loop over a command's output, a " +
+	'marker file or a process — with a `sleep` or, worse, without one — and the loop does not know ' +
+	'when the command finished. A regex that never matches waits to ' +
+	'the harness block limit; one that matches a mid-run line exits too early — either way the ' +
+	'command exit is not what ends the wait, and each pass spends a full-context round trip ' +
+	'(joshuafolkken/kit#2371 measured about 45 minutes, 13% of six lanes, lost to exactly this). Do ' +
+	'not poll the output file. A command known to take minutes — `pnpm josh gate`, `pnpm josh ' +
+	'followup`, `pnpm josh format` — is started detached from the first with `run_in_background` set, ' +
+	'and the harness re-invokes you when it exits: its completion notification is what ends the wait, ' +
+	'on the task exit rather than a regex or the block limit. So issue the long command in the ' +
+	'background and end the turn — do not arm a loop; the wake-up brings you back. To glance at ' +
+	'interim output, `Read` the output file once, never in a sleep loop. If you are waiting on CI, ' +
+	'`pnpm josh followup` waits on it for you. The procedure is ' +
+	'`.claude/skills/workflow-commands/background-commands.md`, "A command that can take minutes is ' +
+	'issued in the background". **This rule fires on every occurrence, not once per run.**'
+
+// The row itself, so `delivered-rules.ts` spreads one entry. `decide` returns true so it refuses every
+// occurrence; it declares no `keeps` — waiting on the task exit is the *absence* of a loop, not a
+// call, so the row is reported unmeasured rather than scored on an act that does not exist
+// (`git-force.ts`).
+const ROW = {
+	id: 'poll-loop',
+	is_trigger: bash_triggers.on_bash_command(is_poll_loop),
+	reason: POLL_LOOP_REASON,
+	decide: (): boolean => true,
+}
+
+const poll_loop = {
+	POLL_LOOP_REASON,
+	ROW,
+	is_poll_loop,
+}
+
+export { poll_loop }

package/scripts/rules/pre-gate-cut.ts

@@ -0,0 +1,207 @@
+import { cost_cli, type CostVerdict } from '#scripts/cost-runtime/cost-cli'
+import { cost_verdict } from '#scripts/cost-runtime/cost-verdict'
+import { lane_child_marker } from '#scripts/lane/lane-child-marker'
+import { lane_paths } from '#scripts/lane/lane-paths'
+import { run_cut, type RunCut } from '#scripts/run/run-cut'
+import type { GuardedCall } from '#scripts/time-runtime/time-batch-guard'
+import { bash_triggers } from './bash-triggers'
+import { shell_segments } from './shell-segments'
+
+// The pre-gate cut, delivered at the call it binds on (joshuafolkken/kit#1864).
+//
+// **The mechanism was there and nothing called it.** joshuafolkken/kit#1839 built the cut and
+// joshuafolkken/kit#1850 measured the result: across six lane children — #1853, #1849, #1855, #1854,
+// #1856 and #1847 — the cut was taken **0 times**. Four of the six issued the *entry* check
+// `pnpm josh run:cut --resume <N>` and were answered `fresh`; not one issued `pnpm josh run:cut <N>`,
+// the call that actually cuts. The procedure was read three to five times per run and remained one
+// step of prose in the middle of it, so joshuafolkken/kit#1839's fourth acceptance condition — the
+// drop in context per request — could not be judged at all.
+//
+// **This is the third time prose lost to a refusal.** joshuafolkken/kit#1344 measured three
+// consecutive runs in which resident text about batching moved the number not at all, and
+// joshuafolkken/kit#1460 measured the same for the investigation threshold; in both, a `PreToolUse`
+// refusal was what finally moved it. A step a run is free to skip is a step that gets skipped under
+// time pressure, and `run:hold` — the one boundary step that never gets missed — is the one that
+// refuses.
+
+const GATE_COMMANDS: ReadonlySet<string> = new Set(['gate'])
+const CUT_COMMANDS: ReadonlySet<string> = new Set(['run:cut'])
+// The three spellings that ask about a cut rather than take one: the fresh process's entry check, the
+// teardown, and the record read. **Excluding them is the whole point** — four of the six measured
+// children issued `--resume` and went straight on to the gate, so a predicate that counted any
+// `run:cut` would have been silent on exactly the runs this rule exists for.
+const CUT_MODE_FLAG = /(?:^|\s)--(?:resume|end|json)(?:[=\s]|$)/u
+// **The one entry call the resumed half never makes** (joshuafolkken/kit#1867).
+// `.claude/skills/workflow-commands/pre-gate-cut.md` sends a `fresh` verdict on to "claim the hold,
+// ask the session boundary, read the issue, implement", and tells a `resume` verdict to "skip the
+// title, the plan, the fresh hold claim and the implementation". So the hold claim is what a run made
+// on the near side of the pre-gate boundary carries and the process the cut produced does not.
+const HOLD_COMMANDS: ReadonlySet<string> = new Set(['run:hold'])
+// **A release is not a claim, and the subcommand name alone cannot tell the two apart.** `run:release`
+// is registered as the hold script under `--release`, so a segment naming the hold command may be
+// either — the same asymmetry `CUT_MODE_FLAG` exists for one command up. Reading a release as a claim
+// would put the resumed session, which releases at its merge, straight back into the denominator this
+// predicate exists to keep it out of.
+const HOLD_MODE_FLAG = /(?:^|\s)--release(?:[=\s]|$)/u
+
+// **Alias-expanded rather than matched as text**, so `pnpm josh ga` and `pnpm josh rct` are the same
+// calls as their canonical spellings. Segment-wise for the reason every other row here is: one shell
+// line carries several commands, and a name quoted inside a body is not the command being invoked.
+//
+// **One reading of that question rather than one per name set.** Four predicates here differ only in
+// which subcommands they look for and which mode flag turns the call into a different one, and a
+// second copy of the walk is the clone `CLAUDE.md` prohibits — the copy nobody corrected would be the
+// one that stops seeing an alias. `mode_flag` is optional because two of the four ask about the
+// subcommand whatever mode it was invoked in.
+function invokes_josh(command: string, names: ReadonlySet<string>, mode_flag?: RegExp): boolean {
+	return shell_segments
+		.segments_of(command)
+		.some(
+			(segment) =>
+				shell_segments.is_josh_command(segment, names) && mode_flag?.test(segment) !== true,
+		)
+}
+
+function runs_the_gate(command: string): boolean {
+	return invokes_josh(command, GATE_COMMANDS)
+}
+
+function takes_the_cut(command: string): boolean {
+	return invokes_josh(command, CUT_COMMANDS, CUT_MODE_FLAG)
+}
+
+// Whether this command claims the working tree, in either spelling and in neither release spelling.
+function claims_the_hold(command: string): boolean {
+	return invokes_josh(command, HOLD_COMMANDS, HOLD_MODE_FLAG)
+}
+
+// **One half of the occasion, never the whole of it** (joshuafolkken/kit#1867). Taken alone this
+// predicate enrols both processes of one obedient lane child: the cut relaunches a second session
+// which issues this same entry check byte for byte and can never take a cut of its own, so the row
+// read at half its true rate. `delivered-rules.ts` pairs it with `claims_the_hold`, which only the
+// near half of the boundary makes.
+//
+// **The occasion the rule governs, as far as a transcript can answer it.** A lane child issues
+// `pnpm josh run:cut --resume <N>` at its entry whatever it goes on to do, so a run that reaches for
+// the command in any spelling is one this rule could have bound on. Whether a checkout *is* a lane is
+// read from the working directory and appears nowhere in a transcript, so it cannot be the
+// denominator — and taking the gate as the occasion instead would enrol every ordinary non-lane run,
+// where the rule can never be kept, and `pnpm josh rule:value` would read the row low by
+// construction. joshuafolkken/kit#1643 names exactly that failure.
+function asks_about_the_cut(command: string): boolean {
+	return invokes_josh(command, CUT_COMMANDS)
+}
+
+// What the trigger has to know about the world, passed in so the decision itself is testable without
+// a lane on disk and without a git call. `marked_issue` is the dispatch mark read from the
+// environment — the fact that makes the human-or-child question mechanical rather than the model's to
+// judge (joshuafolkken/kit#1904).
+interface LaneCutState {
+	directory: string
+	carried: (now?: Date) => RunCut | undefined
+	marked_issue: string | undefined
+	// **The recent-window context verdict, read lazily** (joshuafolkken/kit#2312). It is a thunk, like
+	// `carried`, so `current_state` builds the object without pricing a session — the read happens only
+	// after the command and lane checks pass, off the handful of calls that actually run a lane's gate.
+	context_verdict: () => CostVerdict
+}
+
+function current_state(): LaneCutState {
+	return {
+		directory: process.cwd(),
+		carried: run_cut.carried_cut_sync,
+		marked_issue: lane_child_marker.marked_issue(),
+		context_verdict: cost_cli.session_verdict,
+	}
+}
+
+// **The dispatch mark is what tells a child apart from a person, and it counts only for this lane.**
+// A person working in the lane carries no mark, so the rule stays silent for them — the
+// human-or-child call is read from the environment, never left to the model. A mark that leaked in
+// from the parent session names some other issue, so requiring it to equal this lane's issue reads
+// that leak as a person too (joshuafolkken/kit#1904).
+//
+// **The resumed process must also stay silent, and the cut record is what says so.** After a cut,
+// `adopt_cut` leaves the record in place with `is_handed_off: false`, so a carried record naming this
+// issue means the process asking is the one the cut already produced. Without this half the rule
+// would fire on the fresh process too — refusing a gate call on a run that had kept the rule
+// perfectly, which `prompts/collaboration-workflow/rule-delivery.md` calls worse than no hook at all.
+function uncut_lane_issue(state: LaneCutState): string | undefined {
+	const issue = lane_paths.lane_issue_of(state.directory)
+
+	if (issue === undefined) return undefined
+
+	if (state.marked_issue !== issue) return undefined
+
+	return state.carried()?.issue === issue ? undefined : issue
+}
+
+// **The cut is taken only when the recent-window context is worth its resume** (joshuafolkken/kit#2312).
+// Below the shared `CONTEXT_CUT_THRESHOLD` a short lane has no accumulation a cut would drop, so the
+// gate runs uncut rather than paying for a relaunch; an unmeasurable session keeps the old
+// unconditional cut as the safety net joshuafolkken/kit#1933 relies on. The verdict is
+// `cost_cli.session_verdict`'s, the same statistic and threshold `run:cut` and the implementation-phase
+// cut read, so the guard and the command can never disagree about whether a cut was due.
+function warrants_the_cut(verdict: CostVerdict): boolean {
+	return verdict !== cost_verdict.UNDER_VERDICT
+}
+
+// **The command test comes first and the world is consulted second.** This predicate is asked of
+// every `Bash` call in the run, so the cheap string match is what keeps a git call — and, now, a
+// transcript read — off all of them but the handful that actually run the gate.
+function is_uncut_gate(command: string, state: LaneCutState = current_state()): boolean {
+	if (!runs_the_gate(command) || uncut_lane_issue(state) === undefined) return false
+
+	return warrants_the_cut(state.context_verdict())
+}
+
+// The instruction in the shape a refusal can carry: what the cut is for, what each verdict means, and
+// the reissue sentence every delivery needs. **The verdicts are spelled out rather than pointed at**,
+// because `cut` is the only one that ends the turn and a run told merely to "take the cut" would have
+// to go and read which of the other five leave it holding the run — the same reason the WIP cap's
+// delivery names its three interrupt tests instead of naming the file they live in.
+const PRE_GATE_CUT_REASON =
+	'⛔ pre-gate cut: this checkout is a lane dispatched for this issue and the gate is the boundary to ' +
+	'cut at, so take the cut before running it. `pnpm josh run:cut <N>` ends this process and ' +
+	'relaunches a fresh one that resumes from the gate, dropping the thinking built up while ' +
+	'implementing rather than carrying it on every later request — joshuafolkken/kit#1839 measured ' +
+	'176K of 204K output riding across that boundary, and joshuafolkken/kit#1864 measured the step ' +
+	'itself firing 0 times in 6 lane children while it was carried as prose. Issue ' +
+	'`pnpm josh run:cut <N>` now, and read the verdict: on `cut`, **end the turn immediately** — the ' +
+	'fresh process owns the run from there and must not be waited for; on `not-a-lane`, `unready`, ' +
+	'`busy`, `failed` or `unknown`, this process carries the run on and the gate is simply the next ' +
+	'call. Never relaunch a second process after `busy`. This fired because the dispatch mark names ' +
+	'this lane; a person working here carries no mark and sees no refusal, so there is no ' +
+	'human-or-child judgement left to make. The procedure is ' +
+	'`.claude/skills/workflow-commands/pre-gate-cut.md`. Reissue the gate once the cut has answered — ' +
+	'this fires once per run, so it cannot repeat on the call in hand.'
+
+// **The pre-gate cut is two acts, one call apart** (joshuafolkken/kit#2034), so its `rule:value`
+// denominator is only the runs that reached the boundary: a run that issues the cut's entry check and,
+// somewhere in the same run, claimed the working-tree hold — the near half of the boundary a fresh
+// process never makes. Read only by the offline measurement, never the live delivery path. Moved here
+// from `delivered-rules.ts` so the pre-gate row lives with its rule, as `implementation-cut.ts`'s does
+// (joshuafolkken/kit#2346).
+function reaches_the_pre_gate_boundary(
+	call: GuardedCall,
+	_turn: ReadonlyArray<GuardedCall>,
+	run: ReadonlyArray<GuardedCall>,
+): boolean {
+	if (!bash_triggers.on_bash_command(asks_about_the_cut)(call)) return false
+
+	return run.some((issued) => bash_triggers.on_bash_command(claims_the_hold)(issued))
+}
+
+const pre_gate_cut = {
+	PRE_GATE_CUT_REASON,
+	asks_about_the_cut,
+	claims_the_hold,
+	is_uncut_gate,
+	reaches_the_pre_gate_boundary,
+	runs_the_gate,
+	takes_the_cut,
+	uncut_lane_issue,
+}
+
+export type { LaneCutState }
+export { pre_gate_cut }

package/scripts/rules/prior-comment-read.ts

@@ -0,0 +1,106 @@
+import { cost_blocks } from '#scripts/cost-runtime/cost-blocks'
+import type { GuardedCall } from '#scripts/time-runtime/time-batch-guard'
+import { time_shell } from '#scripts/time-runtime/time-shell'
+import { tail_commands } from './tail-commands'
+
+// The stand-down that keeps the `issue-comments` rule from refusing a body read the run has already
+// earned (joshuafolkken/kit#1905). The rule exists so a run reads an Issue's comments before building
+// on its body — but a run that already read them, and later reads the body again (a post-merge state
+// check, a re-read), was refused a second time for a read it had already made. **The delivery path
+// sees only the raw transcript tail** — `delivered-rules.ts` names the reason the run's own calls are
+// not handed to it — so the earlier read is recovered by parsing that tail here, the same way
+// `time-batch-guard.ts` parses it, rather than from a call array that does not reach delivery.
+//
+// **It reads comments in the josh spelling too.** `pnpm josh issue:read <N>` prints the body and every
+// comment in one call, so a run that opened an Issue with it has read the comments as surely as one
+// that passed `--comments` — and that spelling is the one the workflow itself reaches for, so leaving
+// it out would refuse the reader that obeyed the rule most directly.
+
+// The path segment `…/issues/<N>` and `…/issues/<N>/comments` both name the Issue in the same capture.
+const ISSUE_PATH_NUMBER = /issues\/(\d+)/gu
+// The positional after `gh issue view`, past any flags that precede it.
+const ISSUE_VIEW_NUMBER = /\bissue\s+view\s+(?:-{1,2}\S+\s+)*(\d+)/u
+// The run of numbers `pnpm josh issue:read` takes as its positional arguments.
+const ISSUE_READ_ARGUMENTS = /\bissue:read\b([\s\d]*)/u
+const A_NUMBER = /^\d+$/u
+
+// A command that prints an Issue's comments: the comments endpoint, `gh issue view … --comments`, or
+// the josh command that reads body and comments together.
+const COMMENTS_ENDPOINT = /issues\/\d+\/comments\b/u
+const VIEW_WITH_COMMENTS = /\bissue\s+view\b[^\n]*--comments\b/u
+const ISSUE_READ_COMMAND = /\bissue:read\b/u
+
+function add_issue_read_numbers(command: string, numbers: Set<number>): void {
+	const match = ISSUE_READ_ARGUMENTS.exec(command)
+
+	if (match === null) return
+
+	const tokens = (match[1] ?? '').split(/\s+/u)
+
+	for (const token of tokens) {
+		if (A_NUMBER.test(token)) numbers.add(Number(token))
+	}
+}
+
+// Every Issue number a command names, across the three read spellings the refusal covers.
+function issue_numbers_of(command: string): Set<number> {
+	const numbers = new Set<number>()
+
+	for (const match of command.matchAll(ISSUE_PATH_NUMBER)) numbers.add(Number(match[1]))
+
+	const view = ISSUE_VIEW_NUMBER.exec(command)
+
+	if (view !== null) numbers.add(Number(view[1]))
+
+	add_issue_read_numbers(command, numbers)
+
+	return numbers
+}
+
+function fetches_comments(command: string): boolean {
+	return (
+		COMMENTS_ENDPOINT.test(command) ||
+		VIEW_WITH_COMMENTS.test(command) ||
+		ISSUE_READ_COMMAND.test(command)
+	)
+}
+
+function reads_target_comments(command: string, target: Set<number>): boolean {
+	if (!fetches_comments(command)) return false
+
+	for (const number of issue_numbers_of(command)) {
+		if (target.has(number)) return true
+	}
+
+	return false
+}
+
+// **Whether the run has already read the comments of the Issue this body read targets.** The tail is
+// scanned for a prior read of the same number, so a body read that names no Issue — and a run with no
+// earlier comment read — both answer false and are refused exactly as before.
+function already_read_comments_for(tail: string, command: string): boolean {
+	const target = issue_numbers_of(command)
+
+	if (target.size === 0) return false
+
+	return tail_commands
+		.prior_bash_commands(tail)
+		.some((prior) => reads_target_comments(prior, target))
+}
+
+// The `already_satisfied` predicate wired onto the issue-comments row of `delivered-rules.ts`: this
+// call's command against the tail, once the same tool-name gate `on_bash_command` applies has passed.
+function already_read_for_call(tail: string, call: GuardedCall): boolean {
+	if (call.name !== cost_blocks.BASH_TOOL) return false
+
+	return already_read_comments_for(tail, time_shell.bash_command(call.input))
+}
+
+const prior_comment_read = {
+	already_read_comments_for,
+	already_read_for_call,
+	fetches_comments,
+	issue_numbers_of,
+}
+
+export { prior_comment_read }

package/scripts/rules/raw-field-body.ts

@@ -0,0 +1,56 @@
+import { bash_triggers } from './bash-triggers'
+
+// The trigger and the delivered text behind the `raw-field-body` row of `delivered-rules.ts`
+// (joshuafolkken/kit#2304). Its sibling `shell-body` refuses a body a run passed *inline* so the shell
+// evaluates it; this one refuses a body a run passed *by path with the wrong flag*, so the path is
+// posted as text.
+//
+// **`gh api` has two spellings of "pass this by path" and one silently breaks.** `-F` / `--field`
+// reads the file when the value opens with `@`; `-f` / `--raw-field` sends the value verbatim, so
+// `-f body=@<path>` posts the literal string `@<path>`. The two differ by a single character, `gh`
+// exits 0 and returns a comment URL either way, and the break is invisible until a person reads the
+// issue — joshuafolkken/kit#2304 recorded two park comments (`@/tmp/2294-park.md` and a decision
+// record) lost exactly this way, which was the only place the reason for a stopped child was written.
+//
+// **The trigger is the raw-field flag with an `@`-opening body, not `@` alone.** `-F` / `--field
+// body=@<path>` is the spelling the rule *asks* for and stays silent; a `-f body="plain text"` with no
+// `@` is not a file reference and stays silent; a `-f 'labels[]=needs-decision'` names no body and
+// stays silent. Only a raw field whose `body=` value begins with `@` is the misfire.
+//
+// **It fires on every occurrence** (`git-force.ts`): each misfire posts a broken comment of its own,
+// so refused-once-and-free-after would let the second one through.
+
+// A raw field flag — `-f` or `--raw-field`, never the file-reading `-F` / `--field` — carrying a
+// `body=` value that opens with `@`. The flag is anchored to a word boundary so the `-f` inside
+// `--field` is not mistaken for the short raw flag, and the opening quote may sit on either side of
+// `body=` (`-f "body=@…"` and `-f body="@…"` are one command to the shell), matching the shapes
+// `shell-body-trigger.ts` reads.
+const RAW_FIELD_BODY_AT = /(?:^|\s)(?:-f|--raw-field)[\s=]+['"]?body=['"]?@/u
+
+function posts_at_path_literally(command: string): boolean {
+	return RAW_FIELD_BODY_AT.test(command)
+}
+
+// The instruction in the shape a refusal can carry: what the flag is doing, the one-character trap
+// that hides it, and the single command that cannot take the wrong flag. The damage is named because
+// it reads as unbelievable — the call succeeds and returns a URL while posting the path as text.
+const RAW_FIELD_BODY_REASON =
+	'⛔ literal @path body: this passes `body=@<path>` to `gh api` with a raw field flag (`-f` / ' +
+	'`--raw-field`), which sends the value verbatim — the string `@<path>` is posted as the comment, ' +
+	'not the file it points at. `-F` / `--field` is the flag that reads the file, and the two spellings ' +
+	'differ by one character while `gh` exits 0 and returns a comment URL either way, so the break is ' +
+	'invisible until a person reads the issue (joshuafolkken/kit#2304 lost two park comments this way). ' +
+	'Post an issue or PR comment with `pnpm josh issue:comment <N> --body-file <path>` — the one ' +
+	'spelling, which cannot take the wrong flag. The rule and the safe forms are in ' +
+	'`prompts/collaboration-workflow/shell-body.md`. This rule fires on every occurrence, not once per run.'
+
+const ROW = {
+	id: 'raw-field-body',
+	is_trigger: bash_triggers.on_bash_command(posts_at_path_literally),
+	reason: RAW_FIELD_BODY_REASON,
+	decide: (): boolean => true,
+}
+
+const raw_field_body = { RAW_FIELD_BODY_REASON, ROW, posts_at_path_literally }
+
+export { raw_field_body }