The probe asked whether node could load ESM, while the notice promised a
Node 22 floor and package.json engines declares >=22.12.0. Reviewers kept
flagging the gap, and they were right to: a 14.18-to-21 runtime passed the
probe on the strength of one import while the hook and its detector bundle
are only ever exercised on the engines floor, so "can load our code" was a
weaker claim than the one being made for it.
Check the floor directly: parseInt(process.versions.node) >= 22, in
ES5-only syntax that parses on any node old enough to fail it. Probe and
notice now derive from one NODE_MAJOR_FLOOR constant, so they cannot
disagree, and the archaeology about node: scheme support and pre-15
unhandled-rejection semantics goes with the import it explained.
Add the missing contract test: every generated hook command carries the
probe, the notice appears exactly where a harness can render it (Claude
and Codex, project and plugin), and the expected floor is read from
package.json engines rather than repeated by hand.
Verified against a fake pre-22 node, no node, and a real node: one notice
then the marker holds it silent, exit 0 in every failure shape, and the
hook's own exit code still passes through on a supported runtime.
Co-Authored-By: Claude Fable 5 (via Cursor) <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Greptile flagged that the probe does not enforce the Node 22 engines floor.
Two parts to that, and they land differently.
The real defect is narrower and worse than stated: the hook closure imports
`node:fs`, `node:os`, `node:path` and `node:url`, and the `node:` scheme needs
14.18, so a bare `import('fs')` probe passed on 12 and 13 and those runtimes
then died on the real import, which is the banner this branch exists to remove.
Probing `node:fs` closes that. The added `.catch(()=>process.exit(1))` is load
bearing rather than tidiness: before Node 15 an unhandled rejection is only a
warning and the process still exits 0, so a rejected probe would have read as a
pass on exactly the versions in question.
Not enforcing 22 is deliberate and stays. The probe asks whether this runtime
can load our code, not whether it is a supported one, so a 14.18-to-21 runtime
that works today keeps working rather than being silently switched off. The
notice names 22 because that is the version worth installing, and it only ever
reaches someone whose runtime already failed the probe, so no user is shown a
threshold that contradicts what ran.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bugbot caught the Codex plugin builder still invoking node directly, and the
same reasoning covers GitHub Copilot and Grok Build: all three shipped the
exact failure this branch exists to stop, and sat visibly inconsistent with
their guarded siblings.
Route them through guardedNode with no notice, matching Codex and Cursor.
GitHub gains a second property from it: outside a git repository
`$(git rev-parse --show-toplevel)` expands to nothing, so the old command
handed node a path that could not exist and failed the turn. The file test
now short-circuits that to exit 0.
Every builder carries the probe; only the two Claude manifests carry the
notice, which is the only harness whose response shape is confirmed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both bots caught the same false report: the summarize step ran off the
initial drift flag, so the no-drift-after-rebuild exit still claimed a
commit landed on main. The commit step now records pushed=true/false in
its step output and the summary reads it.
Prepared with AI assistance (Claude Code), directed by @pbakaus.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Copilot's two review points: the fifth attempt performed a full
reset + install + rebuild + 25s backoff that nothing would ever consume
before the job failed, and the retry message blamed "main advanced"
when the combined condition also fails on push errors (network, auth).
The loop now breaks before recovery on the final attempt, and both the
retry and terminal messages name the two possible causes.
Prepared with AI assistance (Claude Code), directed by @pbakaus.
Co-Authored-By: Claude Code <noreply@anthropic.com>
The sync workflow built once from the checked-out main and aborted when
a human commit landed during the ~30s build window (about 10% of runs
per the evidence in issue #388), leaving generated provider output
stale until the next unrelated push re-triggered it.
The commit step now loops up to five times: on a lost race it resets
hard to the fresh origin/main (source included), re-installs and
rebuilds, and pushes again with linear backoff. Every attempt therefore
builds from the main it will land on, which is the invariant the old
abort guard protected; the merge-base check stays inside the loop as
the pre-push verification. When the rebuilt output shows no drift (the
racing commit was another sync, or the new source produces identical
output) the step exits cleanly instead of committing an empty sync.
Validated by yaml-lint, bash -n, and a local three-repo simulation
(bare origin + worker + racer) confirming the lost race rebuilds
against the racer's source and lands matching output on attempt two.
Retry design proposed by @mktdgtbrz in #388; implemented from the
description with the no-drift early exit added.
Prepared with AI assistance (Claude Code), directed by @pbakaus.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Bump plugin + marketplace to 4.0.1 and sync the regenerated provider
output: the guarded hook commands from issue #399 (a missing hook file
exits 0 instead of crashing every turn of a user-level install), the
canon standing exit, the visualize flow, the two shipped subagents, and
the interactive-spine fixes from today's live testing. Detector count
validates at 59 with undersized-ui-text.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
github-actions[bot]
Paul BakausandClaude Fable 5
