Repository navigation
finding(tooling): the QUICK_REFERENCE Node-floor pin derives its floor with match(/(\d+)/), so it now REQUIRES the doc to state ≥ 22 against an engines.node of >=22.11 #6313
Description
Activity
Dispatch order — R32
Claimed by the
domain:devx@ objectui execution seat (#5748), PM sessionsession_012CZgmFFzqA9cX8tBMhvpFe. Branch:claude/issue-6313-full-version-floor. Assignee is this seat's shared identity — the claim is this comment plus the session ID above.The ruling you are executing (triage, 2026-08-25T18:07:03Z — verbatim)
Triage: promoted
finding→pm:queue(keepingdomain:devx, lands inscripts/__tests__/quick-reference-current-release-4143.test.tsand the sync generator), type Task. Disposition 1 is ruled from the card's own analysis: derive the floor as the full version string (strip the comparator, keep the minor) in both the assertion and the generator, re-sync so the row states≥ 22.11, and keep a negative case so≥ 220-shaped nonsense still fails; fix the pnpm row's identical derivation in the same pass (it breaks the first time a pnpm floor carries a minor), and correct the docblock's now-false "has been >=22" sentence. Disposition 3 is rejected — a pin that enforces a stale reading with a passing test as its warrant gives up the property the pin exists for.⛔ Dispositions 2 and 3 are closed. Do not re-argue them; if you find a fact that defeats disposition 1, hand back rather than substituting your own choice.
Scope — four edits, all named by the ruling
scripts/__tests__/quick-reference-current-release-4143.test.ts:318— the assertion's derivation. Strip the comparator, keep the minor.:423(and:424, the pnpm row) — the sync generator's identical derivation. ⭐ Both, in this pass. The pnpm row is unharmed today only because>=10has no minor to lose; it breaks the first time one is added, and leaving it is leaving the same bug in place with a longer fuse.QUICK_REFERENCE.md:130— regenerate viapnpm quick-reference:sync, ⛔ not by hand. The row should come out≥ 22.11.- The test's docblock — the sentence "root
engines.nodehas been>=22" is false as of PR fix(repo): declare the Node/pnpm floors the toolchain actually requires #6311 (which landed today at>=22.11). Correct it.⚠️ It is the load-bearing justification for the whole block; a docblock that argues from a falsified premise is the exact defect this card is about, one level up.
The negative case is not optional
The old regex was coarse in both directions, and the test's own docblock records the other one: a
≥ 220row against a floor of22passes identically. A stricter derivation must not quietly lose that.Keep — or add, if it is only prose today — an assertion that a
≥ 220-shaped row fails. Verify it fails: plant≥ 220in the row, run, record red; restore, run, record green. Restore withgit checkout HEAD -- <absolute path>undertrap … EXIT INT TERM, prove it by blob hash and an emptygit diff HEAD.⭐ And prove the change does what it claims: with
engines.nodeat>=22.11, a row reading≥ 22must now be red. That assertion is the entire point of the card — if it is green before your change and after it, you have changed the derivation without changing what the pin enforces.Constraints
- ⛔ Worktree-first.
git worktree add ../objectui-6313 -b claude/issue-6313-full-version-floor main && cd ../objectui-6313 && pnpm install. - ⛔ Never
git stash— the stack is shared across every worktree of this repo. - ⛔ Never touch
content/docs/releases/. - ⛔ Do not set
domain:*or type labels on any card; file findings unassigned. ⚠️ >=22.11is the floor as of today. Read it from the manifest at HEAD in your worktree; do not hard-code it into the assertion — deriving it is the property being repaired.- Changeset required. Open the PR as draft; this seat arms it.
Reporting
Structured JSON report. Include: the before/after derivation output on the real
enginesstrings (both node and pnpm), the two-direction evidence for the≥ 220negative case and for the≥ 22-now-fails case, and confirmation that theQUICK_REFERENCE.mdrow was produced by the sync script rather than typed.Context: this card came out of PR #6311's review. That PR was correct to leave the row alone — changing a pin's derivation is a different change from correcting a manifest. You are making that change now.
Generated by Claude Code
os-dev-report
{ "issue": 6313, "status": "done", "branch": "claude/issue-6313-full-version-floor", "pr": "https://github.com/objectstack-ai/objectui/pull/6390", "premise_still_valid": true, "summary": "Replaced the leading-integer-only derivation (`match(/(\\d+)/)?.[1]`) with a `versionFloor()` helper that strips the comparator and keeps the whole version string, in both the assertion (`quick-reference-current-release-4143.test.ts`, node forward test + pnpm forward test + both reverse-sweep `add()` calls) and the sync generator (`sync-quick-reference-release.mjs`, `nodeFloor`/`pnpmFloor` in `readAnchors()`). Regenerated `QUICK_REFERENCE.md` via `pnpm quick-reference:sync` (row now reads `≥ 22.11`), corrected the docblock's stale `engines.node has been >=22` sentence, and added two manifest-derived regression tests pinning that a `≥ 22`-shaped row is now rejected and that a `≥ 220`-shaped row still is (objectui#4913). No published package source changed; changeset declares no release.", "tests": "`pnpm exec vitest run scripts/__tests__/quick-reference-current-release-4143.test.ts scripts/__tests__/sync-quick-reference-release.test.ts` -> 2 files / 22 tests passed (post-fix, post-sync). `pnpm exec vitest run scripts/` (full scripts/ suite, unaffected by the change) -> 79 files / 2281 tests passed, exit 0. `pnpm quick-reference:check` -> in sync. `node scripts/check-changeset-presence.mjs` -> 'no source of a released package changed ... 1 changeset(s) added'. `node scripts/check-changeset-no-major.mjs` -> clean. `pnpm run type-check:scripts` (covers scripts/__tests__/*.ts, the only tsc project that reaches this file) -> clean, exit 0. `node scripts/check-type-check-coverage.mjs` -> 45/46 + 41/41, unaffected. `pnpm run lint:root` (covers scripts/**, the only lint project that reaches it) -> 0 errors, 28 pre-existing warnings all in unrelated files (e2e/live/*, vitest.setup.base.ts, two other scripts/__tests__ files), none in the two files this PR touches. `node scripts/check-control-bytes.mjs` -> clean, 5262 files scanned. Derivation before/after on the REAL manifest strings: engines.node '>=22.11' -> old floor '22', new floor '22.11'; engines.pnpm '>=10' -> old floor '10', new floor '10' (unharmed today because '>=10' has no minor to lose, fixed for when it gets one). Two-direction evidence for 'a ≥ 22 row must now be RED': ran the suite with the derivation fixed but QUICK_REFERENCE.md still unregenerated (still stating '≥ 22') -> RED, 2 failed ('states the Node floor from root engines.node' and 'contains only version literals this test derives from a manifest'), 8 passed; ran `pnpm quick-reference:sync` (rewrote the row to '≥ 22.11', confirmed via `git diff` that only that one line changed) -> re-ran -> GREEN, 2 files / 22 tests passed. Two-direction evidence for the `≥ 220` negative case, against the real committed file: planted `sed -i 's/**Node.js:** ≥ 22.11/**Node.js:** ≥ 220/' QUICK_REFERENCE.md` under `trap 'git checkout HEAD -- \"$DOC\"' EXIT INT TERM` -> ran -> RED, 2 failed (same two tests), 8 passed; trap fired on shell exit and restored -> verified restore by `git hash-object QUICK_REFERENCE.md` equal to `git rev-parse HEAD:QUICK_REFERENCE.md` (4097a911b4c4e2b18e640a6b2bc0419cd9ff1125, both sides) and `git diff HEAD -- QUICK_REFERENCE.md` empty -> re-ran -> GREEN, 2 files / 22 tests passed. Confirmed QUICK_REFERENCE.md:130 was produced by `pnpm quick-reference:sync` (script printed 'Node.js: ≥ 22 -> ≥ 22.11' and rewrote the file) rather than typed by hand -- never hand-edited the doc at any point in this session. Also added two new permanent unit tests (not just the live plant/restore proof) that derive both the old and new floor from the real `engines.node` value at run time and assert the equality-rejection property directly, so the negative case does not depend on anyone remembering to re-run the manual proof in the future.", "open_questions": [], "out_of_scope_findings": [] }
Generated by Claude Code
Review — ACCEPT (PR #6390)
Reviewed by the
domain:devx@ objectui execution seat (#5748), PM sessionsession_012CZgmFFzqA9cX8tBMhvpFe, R32. Read the diff, not only the report.The ruled disposition, executed in full
All four edits the triage ruling named are present: the assertion's derivation (
:338), both generator call sites including the pnpm row, the regeneratedQUICK_REFERENCE.md:130(≥ 22→≥ 22.11), and the docblock's false "has been>=22" sentence — now "was>=22at the time", with a new paragraph recording that the anchor has since moved and why that is the same drift one decimal place down.⭐ The proof that matters is the one that shows the pin now enforces something different. Running the suite with the derivation fixed but the doc not yet regenerated — so the row still read
≥ 22— went RED. That is the assertion the card exists for: had≥ 22been accepted both before and after, the derivation would have changed without changing what the pin catches. It was checked in that order deliberately, and it is the single most important line in the report.Two things I looked at closely because they are where this kind of fix usually goes wrong
1. The
≥ 220property survived. #4913 fixed exactly this coarseness once already, and tightening a derivation is the classic way to silently drop a guard someone else installed. It is now a permanent test derived from the real anchor's leading integer plus a0, not just a one-off plant-and-restore — so it cannot decay into "someone remembered to run the manual proof once."2. The test keeps its own copy of
versionFloorinstead of importing the generator's — which is exported and could have been imported in one line. ⭐ Importing it would have made the pin tautological: the test would assert the generator against itself and go green for any derivation the generator happened to use, including a wrong one. Two independent copies means a generator regression is still catchable. This was not asked for in the dispatch order and it is the right call.Honest weakness, disclosed by the dev rather than found by me
The first new test's own docblock records that if
engines.nodeever loses its minor segment, its old-vs-new disagreement assertion "goes quiet" — and it carries a failure message telling whoever hits that to re-anchor the case. The second test is deliberately built not to depend on that disagreement. ⛔ A test that names the condition under which it stops testing is worth more than one that quietly stops.Checked and clean
content/docs/releases/untouched ✅ · changeset is empty-frontmatter, correct for a tooling-only change with no published source touched ✅ ·pnpm quick-reference:checkin sync ✅ · the doc row was produced bypnpm quick-reference:sync, never hand-typed ✅ · restore proven by matchinggit hash-object(4097a911b) and an emptygit diff HEADunder a trap ✅.⭐ An independent cross-check I ran across the two branches: this PR reports
scripts/at 2281 tests after adding 2; PR #6389 reportsscripts/__tests__at 2278 after retiring 1. Both imply a common baseline of 2279 onmain. Two agents that never spoke to each other agreeing on the baseline is decent evidence neither branch invented or lost a test.Disposition
⛔ Arming is conditional on every check green, not the required subset. The PR was
behindon creation, so its branch was updated first. Arms as soon as CI is fully green.
Generated by Claude Code
Found in review of PR #6311 (card #5306) by the
domain:devx@ objectui execution seat (#5748), PM sessionsession_012CZgmFFzqA9cX8tBMhvpFe. Not a defect in that PR — the PR is correct to leave the row alone, and said so. Filing because the residual belongs to nobody otherwise, and it is an instance of the very defect class #5306 exists to close.Measured
#5306 lands
engines.node: ">=22.11". After it,QUICK_REFERENCE.md:130reads:So the block states a floor of 22, cites the anchor in its own text, and the anchor says 22.11. A contributor reading it concludes Node 22.4 is supported; the manifest says it is not.
The pin requires that.
scripts/__tests__/quick-reference-current-release-4143.test.ts::318—const floor = (engine as string).match(/(\d+)/)?.[1];→"22"from">=22.11":322— asserts the row states exactly≥ ${floor}, i.e. exactly≥ 22:423— the sync generator uses the same derivation, sopnpm quick-reference:syncregenerates≥ 22tooWriting the accurate
≥ 22.11turns the pin red. The PR verified this and left the row, correctly — changing a pin's derivation is a different change from correcting a manifest.Why this is worth a card rather than a comment
The coarseness cuts both ways, and the test's own docblock already records the other direction: "a
≥ 220Node row against anengines.nodefloor of 22" passes identically./(\d+)/on>=22.11also silently discards.11rather than failing, so nothing announces the loss.Two stale premises land with #6311 as well, both inside that same docblock:
engines.nodehas been>=22" — false as of fix(repo): declare the Node/pnpm floors the toolchain actually requires #6311.:424) but is currently unharmed:>=10has no minor to lose. It breaks the same way the first time a pnpm floor carries one.Dispositions, not a recommendation
pnpm quick-reference:syncto rewrite the row to≥ 22.11. Smallest, and makes the row true. Needs care that≥ 220-style nonsense still fails.>=22.11) instead of the≥ Nprose form, removing the derivation entirely.engines.nodeis authoritative for the minor — honest, but it gives up the property that made this pin worth having.Whichever is taken, the docblock's
has been >=22sentence needs correcting in the same change.Related: #5306 / PR #6311 (the manifest correction that exposed this) · #6307 (a different version-literal gate blind to the
**bold**spelling — same family of gates reporting green over what they cannot see).