fix(oxlint): pin the version the gate enforces, and let a repo pin its own

[debuggingfuture]

The oxlint run fetched npx --yes oxlint@1. That made the registry, not this repo, the authority on what the flare-dispatch/oxlint check enforces — with no commit, no PR and no review on either side.

Problem & Insight

oxlint selects rules by category, and a minor release may move a rule into correctness. 1.79.0 (published 2026-08-18) moved five React rules in. Every consumer tracking @1 went red inside the hour, on every open PR at once, for findings that predated all of them — and no consumer could fix it, because the version was here.

The second half is worse than the outage: a consumer's own lint step runs its pinned devDependency, so it stayed green throughout. The two lanes had been enforcing different rule sets all along, and the only signal of that divergence is the day they disagree.

Same shape as an unpinned :latest image or a floating action tag, with one extra turn of the screw — it fails on everyone simultaneously and reads like their regression.

Take

VERSION_DEFAULT is now an exact version (oxlint.ts), never a range or dist-tag, and the pull_request trigger no longer restates a literal — pinning it there would pin every repo the dispatcher serves, unreachable from all of them.

Pinning alone is not enough: it moves the single point of failure from the registry to this repo, and a consumer a bump breaks is still stuck. So version resolves through the ladder offload-test already uses for command:

dispatch input → oxlint.version:<repo> → oxlint.version → VERSION_DEFAULT

One wrangler kv key put and a repo runs its own version, no deploy here. The run keeps its zero-config property — no command, no install, no .oxlintrc.json — since the default always answers; an unresolvable version is not a failure the way a missing offload-test command is.

resolve-version is a real checkpointed step, so it is skipped entirely when a dispatch carries a version and Action mode keeps the checkout → exec → upload-log shape the suite pins. Run version → 1.2.0.

pr-review's grounding block imported the same constant rather than keeping its own "1" — its quoted findings should be the findings that decide the check.

Alternative not taken: deriving the version from the consumer's own package.json. It reads as the real fix — the gate would enforce exactly what pnpm lint does — but the checkout runs install: false, and a ^1.74.0 range resolves no better than @1. Getting a concrete version means parsing three lockfile formats in the container. Worth its own issue, not this PR.

Verified

pnpm lint, pnpm typecheck, pnpm test all green (2285 passed, 1 skipped). Five new cases cover the ladder, the exact-version shape of the default, blank-KV fallthrough (so a stray empty value can never produce oxlint@), and that a dispatched version skips the resolve step.

Follow-up

• Consumers currently red should either take this default or pin oxlint.version:<repo> — pinning is the faster of the two and needs nothing from here.
• Bumping VERSION_DEFAULT can turn consumers red; it belongs in its own PR, never folded into an unrelated change.

🤖 Generated with Claude Code

[flaredispatch-fractalboxdev]

AI code review — ✅ Approve

Risk tier: full · 0 critical · 0 warnings · 0 suggestions

Reviewers: security ⚠️ · performance ⚠️ · code-quality ⚠️ · documentation 0 · release-management ⚠️ · compliance ⚠️ · agents-md 0

No findings.

📋 View full logs & reviewed diff ↗