guardrails: recover the PreToolUse spawn-reduction work from the closed #1385

[kyle-sexton]

Why this exists

PR #1385 tried to fix the PreToolUse fail-open in two halves: raise the timeouts, and make the guards
cheap enough to finish inside one. The timeout half landed separately as #1379. The performance
half did not land, and it is still worth recovering — closed with #1385 rather than merged, because
a fresh-context verification found the change unsafe in its then-current state.

Raising a timeout narrows the fail-open window; it does not remove it. If the residual load amplifier
is spawn-proportional — the natural reading, given a census of 65 process spawns per Bash tool call
through MSYS fork emulation under Defender — then the 60 s #1379 bought is consumed 2–3× faster than
it would be with the spawn reduction in place, because each guard stays 2–3× more expensive (7 spawns
versus 3 for the git guards, 14 versus 7 for hardcoded-path-check). Same cliff, proportionally less
margin.

What #1385 contained that is worth keeping

• A hook::jq_fields batched field extraction in lib/hook-utils.sh, replacing per-field jq
  invocations across eight guards, delivered correctly through scripts/sync-hook-utils.sh with all
  13 plugin copies verified identical.
• A strip_quoted_spans shell-builtin replacement for a printf | sed | sed pipeline in
  flag-commit-pr-skill-bypass.sh.
• A deferred git rev-parse --is-inside-work-tree probe in hardcoded-path-check.sh.
• A derivation for the 60 s budget from a measured 437 ms per-spawn unit price, which fix(guardrails): raise PreToolUse blocking-guard timeouts from 10/15s to 60s #1379's number
  does not carry.

Preconditions any revival must meet

These are the verifier's five, restated as acceptance criteria rather than as narrative:

1. Fix the four contract-test regressions, starting with the two that fail open. Measured on
   Windows against the post-change tree: block-no-verify 111/112 (git commit --no-<backslash newline>verify continuation — expected exit 2, got 0), block-convention-violation 30/31
   (violating PowerShell here-string subject — expected exit 2, got 0), block-hook-bypass 201/203,
   flag-commit-pr-skill-bypass 27/28. All four involve a multi-line command value; every guard whose
   payloads are single-line passed with the same extraction edit.
2. Attribute those failures before acting on them. The post-change numbers are first-hand; the
   pre-change baseline was fix(guardrails): raise PreToolUse blocking-guard timeouts from 10/15s to 60s #1379's reported figures, not an own measurement. The control arm is a
   three-way differential: A = live worktree at HEAD, B = HEAD through the extraction procedure,
   C = HEAD~1 through the same procedure. B is the control — only if B reproduces A is the
   extraction faithful and C comparable. Cheaper fallback if B diverges: invoke the single failing
   payload directly against both versions of the one guard.
3. Add regression tests for multi-line payloads — backslash-newline continuations, PowerShell
   here-strings, embedded and escaped quotes. fix(guardrails): restore PreToolUse enforcement — guards were killed at their timeout #1385 modified eight guards and added zero tests; the
   existing suite caught these four only by luck of prior coverage.
4. Commit or reproduce the claimed equivalence harness. fix(guardrails): restore PreToolUse enforcement — guards were killed at their timeout #1385's commit message claimed
   strip_literals was byte-identical on 20,041 inputs including 20,000 fuzzed; no harness, corpus,
   or output was committed anywhere in the diff, and a here-string test in that same guard fails.
5. Do not re-raise the advisory hooks' timeouts without a justification fix(guardrails): restore PreToolUse enforcement — guards were killed at their timeout #1385 did not carry.
   flag-commit-pr-skill-bypass and workflow-resilience-check never block, so raising them from
   10 s to 60 s buys up to 50 s of additional worst-case wait for zero enforcement value. fix(guardrails): raise PreToolUse blocking-guard timeouts from 10/15s to 60s #1379
   deliberately declined this.

The gate-design finding underneath all of it

CI has no Windows runner. Every lane in .github/workflows/ is runs-on: ubuntu-24.04, while the
defect being fixed is MSYS fork emulation under Defender — Windows-only — and the guards ship to
Windows users. A green plugin-gate is therefore uninformative about a change to this code on the
platform that produced the defect. This is a finding against the repository's gate design as much as
against any one PR, and it is why "CI is green" could not substitute for behavior-preservation
evidence here. It deserves its own ticket if one does not already exist.

Also unresolved from that PR

plugins/guardrails/scripts/hook_latency_report.py was added by #1385 and never reviewed — 120 lines,
no test, no CI wiring, and two open review findings on it (fan-out counts not filtered by the selected
hook event; percentile indices not computed by nearest rank). If the performance work is revived,
either bring that script with it under review or leave it out.

[kyle-sexton]

This was generated by AI during triage/admission.

Admission read. Carries work-class: scoped (C3) already. No prior ratification recorded on
this item (no attended triage <date>, operator-ratified marker, no ratify-c3 reply), and this
lane's own durable state has first_drain_complete: false. Per the admission gate's first-drain
rule this is queued, not dispatched.

Separately, this item's own scope pushes past a routine C3 read on its merits, independent of
ratification: it targets plugins/guardrails hook bodies (a hook-contract surface under this
repo's fresh-docs mandate), requires reconstructing an unreproduced equivalence-fuzzing harness
(20,041 inputs claimed, none committed), and its own "gate-design finding" section flags that CI has
no Windows runner to verify the Windows-only defect this fix targets — meaning green CI here would
not be trustworthy completion evidence the way it is for a typical C3 item. Recommend an operator
read the ratification decision and the scope question together rather than ratifying this one by
default alongside more routine C3 candidates.

Applying needs-human for the ratification gate; not a claim that the underlying fix is a bad idea.

[kyle-sexton]

This was generated by AI, delegated directly by the repository operator to resolve this blocker.

Reviewed this pass alongside #1402. Not ratified, not closed, needs-human stays.

This is not a duplicate of #1402. That pairing was assumed going into this pass and is wrong.
#1402 is a documentation-correctness regression in the review plugin. This item is the
guardrails PreToolUse spawn-reduction recovery from the closed #1385. They share nothing but a
ratify-c3 escalation comment posted by the same triage pass.

#1402 was ratified for autonomous dispatch. This item is deliberately not, and the prior
escalation comment's own reasoning is why — it named three blockers, and this pass turned up no
evidence against any of them:

1. Fresh-docs mandate. The change targets plugins/guardrails hook bodies — a hook-contract
   surface. Under this repo's CLAUDE.md that requires working off currently-fetched official
   documentation, not a revived diff from a closed PR. Is that satisfiable by the implementer, or
   does it need an operator to scope which contract surfaces are in play?

2. Unreproduced equivalence evidence. fix(guardrails): restore PreToolUse enforcement — guards were killed at their timeout #1385's commit message claimed strip_literals was
   byte-identical across 20,041 inputs (20,000 fuzzed). No harness, corpus, or output was committed
   anywhere in that diff, and a here-string test in the same guard fails. Does reviving this require
   rebuilding that harness from scratch and committing it, or is a narrower behavior-preservation
   argument acceptable?

3. No trustworthy completion evidence. Every lane in .github/workflows/ is runs-on: ubuntu-24.04. The defect is MSYS fork emulation under Defender — Windows-only — and the guards
   ship to Windows users. Green CI here is uninformative for this change. What counts as done? That
   is a gate-design question this item cannot answer for itself, and it is the reason a routine C3
   ratification does not fit.

Each of the three is an operator decision, not a scoping detail an implementing agent can settle. A
blanket ratification would dispatch work whose completion criteria are undefined.

What would unblock this: answers to 1–3 above, written back as a comment, then needs-human →
agent-ready. Alternatively, split the item — the four contract-test regressions in precondition 1
(block-no-verify, block-convention-violation, block-hook-bypass,
flag-commit-pr-skill-bypass, all multi-line-payload cases) are independently valuable and are not
blocked by any of the three questions above. That split would be a separate agent-ready item, with
this one continuing to hold the performance work.

The item's own "gate-design finding" (no Windows CI runner) also reads as a standalone repository
concern independent of whether this fix is ever revived; it deserves its own ticket if one does not
already exist.

Labels unchanged: needs-human, priority: high, work-class: scoped.

[kyle-sexton]

This was generated by AI during a gated-item triage pass; lane claim only, no decision recorded yet.

[kyle-sexton]

This was generated by AI during an automated gate audit of this item's kind=ratify-c3 escalation. No labels changed.

Verdict: not ratified. needs-human stays. This is a delta on the 2026-07-25 decision-ready summary — it is not restated here. Four things changed.

1. The recovery is real work, not a no-op close

Checked against origin/main — none of #1385's four artifacts landed:

Artifact	On main?
hook::jq_fields (batched extraction)	No — only hook::jq_field (singular), plugins/guardrails/hooks/hook-utils.sh:474
strip_quoted_spans	No — strip_literals still at flag-commit-pr-skill-bypass.sh:199, block-hook-bypass.sh:116
Deferred rev-parse --is-inside-work-tree probe	No — still the early unconditional form, hardcoded-path-check.sh:91
hook_latency_report.py	No — absent from the tree

#1379 (timeouts) is MERGED; #1385 is CLOSED, unmerged, 50 files / +1272 −90. Its branch fix/guardrails-pretooluse-latency still exists at d54180fe, so the diff is recoverable. Precondition 5 is currently satisfied on main — the two advisory hooks are still at timeout: 10.

2. The Windows-CI question is already ticketed — operator questions drop from three to two

Question 3 of the prior summary ("what counts as done, given no Windows runner") is #1414 — open, needs-human, status: needs-decision, work-class: structural. Confirmed still true: all 23 runs-on: entries across the workflows are ubuntu-24.04. This item cannot define its own completion evidence until #1414 is decided, so #1403 is effectively blocked by #1414 and carries no native dependency edge today.

3. The prior summary's split proposal was wrong — corrected target

That comment offered splitting out "the four contract-test regressions in precondition 1" as an agent-ready item. Those regressions do not exist on main. They were measured against the post-change #1385 tree; on main those tests pass — they are what caught #1385. Splitting them out would file a no-op.

The genuinely splittable piece is precondition 3: add multi-line-payload regression tests (backslash-newline continuations, PowerShell here-strings, embedded/escaped quotes) against the current guards. Test-only, no guard body edit, single surface, reversible — and it builds exactly the coverage whose absence let #1385 through. No existing issue tracks it.

4. Scope has grown since the item was written

scripts/sync-hook-utils.sh now fans hook-utils.sh out to 14 plugin materializations, not the 13 the body states, and --check-bump requires a version bump in every carrying plugin manifest — so the shared-lib edit forces 14 plugin releases, not one.

Panel

Three seats, each given only this item's title and body. The ratify-c3 marker, the work-class label, and all prior lane conclusions were withheld from both external seats.

Seat	Class	(a) security-surface	(c) cross-cutting	Autonomous PR without human approval	Confidence
Fresh Claude reviewer (grounded in the real hook sources)	C4	YES	YES	NO	high
OpenAI Codex (gpt-5.6-sol), alternate vendor	C4	YES	YES	NO	high
This agent's own read	C4	YES	YES	NO	high

Unanimous on class, on (a), on (c), and on the dispatch question. (b) dependency-pin: unanimous NO. Seats diverged only on (d) — two read it as VCS-revertible, one as effectively irreversible because a fail-open emits no signal — and on (e), where two called the residual scope calls ordinary engineering and one called the evidence-standard rulings operator calls. Neither divergence affects the outcome.

The fresh reviewer added the mechanism the prior passes did not have: batched extraction must re-delimit N fields inside one jq stream, and newline-delimiting silently truncates a multi-line .tool_input.command to its first line — so the guard scans a fragment and permits. All four #1385 failures were multi-line payloads. The fail-open is by construction, not incidental, and it is invisible at runtime.

Adjudication. The gate ratifies only on consensus that the work is C2/C3 and not security-surface, dependency-pin, cross-cutting, hard-to-reverse, or a human call. It fails three of those conjuncts unanimously. Ratification is refused on the merits — independent of the first-drain earn-trust rule that queued it.

Weighing the safety-surface nuance explicitly rather than reflexively: the intent here is security-positive (fewer timeout-kill fail-opens). The mechanism is a rewrite of the shared field-extraction and quote-stripping primitives from which every guard's block/allow decision is computed, and its demonstrated failure mode is permit-more, not crash. Intent does not carry the classification; mechanism does.

---

Options for the operator

1. Split out precondition 3 only, and leave this item gated. — RECOMMENDED
File a separate item: multi-line-payload regression tests against the current guards (continuations, here-strings, embedded/escaped quotes). Test-only, no guard body change, genuinely agent-ready. It is unblocked by both open questions, it is the highest-value piece independent of whether the performance work is ever revived, and it converts "caught by luck of prior coverage" into a real gate. #1403 keeps the performance work and stays needs-human behind #1414.

2. Answer the two remaining questions inline, then ratify.
(i) Is the fresh-docs mandate satisfiable by the implementer for these hook-contract surfaces, or does an operator scope which are in play? (ii) Must the 20,041-input equivalence harness be rebuilt and committed, or does a narrower behavior-preservation argument suffice? Note that even answered, all three seats say a human should approve the approach before a PR — so this ratifies dispatch, not unattended merge.

3. Decide #1414 first, then revisit.
Defensible ordering — #1414 owns "what counts as done" for this whole change class — but it parks a priority: high item behind a work-class: structural decision with no committed date.

4. Close as not-worth-recovering.
Only if the operator judges the residual spawn-proportional risk acceptable now that #1379's 60 s landed. Not recommended without the measurement, and no agent should close this.

Housekeeping suggested, not applied

• work-class: scoped → work-class: structural. Three independent seats classified this C4; the current label is the reason it entered the C3 ratification lane at all. Existing label, no creation needed.
• Add a native blocked-by edge from this item to ci: no Windows runner anywhere — green checks carry no signal for platform-sensitive shell changes #1414.

Labels unchanged: needs-human, priority: high, work-class: scoped.

[kyle-sexton]

This was generated by AI; the triage lane claim on this item is released. Item remains gated on needs-human; no labels were changed.

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Close as not planned for this drain wave (frontier consensus).

Dual-panel drain ruling: advisory, superseded, folded into a program umbrella, or blocked on a host/design carrier without an actionable in-repo slice this session. Re-open with a concrete acceptance brief if a consumer needs the work.

KEEP set for this wave: standing telemetry; host-physical Class C (#631 family); program umbrellas #530/#531/#532/#535; live design carriers #1500/#1553/#1668/#1695/#1716/#1681/#1718; #1360.