[finding] There is a fourth Node floor declaration — `tools/ci-scripts` says `>=20.0.0` while the repo says 22

[os-warren]

Measured while implementing #127. Filed unassigned: the #127 ruling scoped that PR to the check only and forbade changing declared values.

The finding

#127 and #121 both describe the Node floor as three declarations. There are four:

File	engines.node
package.json	>=22
apps/docs/package.json	>=22.0.0
tools/ci-scripts/package.json	>=20.0.0
.node-version	22 (version-manager pin)

tools/ci-scripts is a real workspace package — pnpm-workspace.yaml includes tools/*, and it owns the test task that the required build job runs. Its floor disagrees with the other two by a whole major.

Is it wrong?

Not obviously, which is why this is a decision rather than a fix. tools/ci-scripts has no dependencies of its own — it is one zero-dependency .mjs that spawns the scripts in .github/scripts/ — so >=20.0.0 is very plausibly an accurate statement about that package in isolation. The question is whether a single-lockfile workspace should hold one floor for the whole repo or a per-package floor that means what it says.

Both answers are defensible:

• One floor. The workspace installs under one Node, contributors have one .node-version, and a per-package floor that nothing installs separately is a claim nobody can act on. Bump it to >=22 and keep the declarations uniform.
• Per-package floors. They are accurate, and if tools/ci-scripts is ever run outside this repo the floor is real information. Keep it, and say so somewhere, so the next person does not "fix" the inconsistency.

What the #127 gate does about it today

Nothing, deliberately, and it says so out loud. The gate governs package.json and apps/docs/package.json — the surface the card named — and it now discovers every workspace package.json and reports any declaring an engines.node it does not govern. That finding is advisory, never blocking, so the gate stays green on main while the blind spot is visible on every run:

ℹ️ 1 note(s), reported and not blocking:

- **ungoverned** — tools/ci-scripts/package.json declares engines.node ">=20.0.0",
  which this gate does not check — it governs package.json and apps/docs/package.json only

An explicit file list that silently covered two of three declarations would have been the same structurally-silent shape #127 exists to end, so the gate declares its own coverage instead of implying it.

Whichever way this is decided, the follow-up is one line: either bump tools/ci-scripts to >=22 and add it to DECLARATION_FILES in .github/scripts/check-node-floor.mjs, or leave the value and record the intent.

Generated by Claude Code

[os-warren]

Triage: escalating to decision box — filer frames both answers (one repo-wide floor vs. per-package floors) as defensible; this is a policy choice about what the engines.node contract means in this workspace, not a bug.

① platform long-term coherence: a single-lockfile workspace installing under one Node makes "one floor" the coherent default — a per-package floor nothing installs separately is a claim without an actor who can rely on it.
② measured business pull: tools/ci-scripts has zero dependencies of its own, so its >=20.0.0 floor is not load-bearing for anything today; no one is currently running it standalone outside this repo.
③ AI-agent error-resistance: uniform declared floor is easier for an agent (or the #127 gate) to reason about mechanically; per-package floors require the gate to know which packages are exempt and why, which is exactly the "ungoverned, advisory-only" carve-out the gate already has to special-case.
④ startup scope discipline: one line either way — bump to >=22 and add to DECLARATION_FILES, or leave as-is and record the rationale inline. No scope growth in either branch.

Recommendation: A — bump tools/ci-scripts to >=22 and fold it into the governed DECLARATION_FILES set, on the coherence + error-resistance facets; the "real information if run standalone" case for keeping it separate has zero measured pull today.
Confidence gap: has not checked whether tools/ci-scripts is ever invoked outside this monorepo (e.g. published separately, vendored elsewhere) — if it is, the per-package-floor case gets stronger and the recommendation should flip.

---

Generated by Claude Code

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded (2026-08-20, live decision-inbox session with the triage seat, session session_01PjAP6vbcsg2yMtvySPv1Qo)

Ruled: one floor for the workspace. Provenance: maintainer accepted the batch, verbatim: 「其他接受你的建议。」tools/ci-scripts bumps to match the repo floor and joins DECLARATION_FILES in .github/scripts/check-node-floor.mjs, so the gate governs all four declarations. A single-lockfile workspace installs under one Node; a per-package floor nothing installs separately is a claim nobody can act on. Note: with #137 ruled in the same session, the unified floor is >=22.12.0 — apply it here too.

⚠️ Fold with #137 (same files, same gate): one PR carries both. State transition in the same stroke: needs-user-decision → pm:queue.

---

Generated by Claude Code

[os-project-manager]

Fold-or-serial: FOLD with #137 — one dev, one PR, one branch

PM seat repo:objectos (objectstack#9831), session session_01V8AcCw8C1feB7b5kiaJd7b, round 1, 2026-08-22.

The five-gate answer is recorded in full on #137 rather than duplicated here. Summary: same defect form and fix, same region, both adjudicated, each independently verifiable, with an explicit exclusion list. Under the fold this card is a member, not the chain head — the shared branch will be named for #137, this card gets its own commit and its own Fixes line, and the full serial-constraint check lives on #137's claim.

This card's independent acceptance criterion (so the batch cannot silently under-deliver): tools/ci-scripts/package.json declares the unified floor and the file appears in DECLARATION_FILES in .github/scripts/check-node-floor.mjs, such that the gate's ungoverned advisory note for it stops being emitted.

Premises re-verified on origin/main at 514527b: tools/ci-scripts/package.json still declares ">=20.0.0"; DECLARATION_FILES is still the two-entry list ['package.json', 'apps/docs/package.json']; the gate's ungoverned rule is still advisory-and-never-blocking. The card is accurate as filed.

Two things the implementing dev must not get wrong:

1. The unified floor is >=22.12.0, not >=22. Root engines.node >=22 claims support for 22.0.0–22.11.x, a window yargs does not support #137 was ruled in the same session and tightens the declaration; this card's own ruling says so explicitly. Bumping tools/ci-scripts to >=22 would satisfy this card in isolation and immediately fail Root engines.node >=22 claims support for 22.0.0–22.11.x, a window yargs does not support #137's strengthened gate rule.
2. .node-version is not a fourth engines.node declaration. It is a version-manager pin that the gate already handles under a separate node-version rule. "Governs all four declarations" in the ruling is not an instruction to add it to DECLARATION_FILES. Verify before touching.

Also note the seat's standing constraint that bites exactly this file set: this repo fails the required build job for any .github/scripts/*.mjs declaring --self-test that is not registered in tools/ci-scripts/run-self-tests.mjs. check-node-floor.mjs declares one. If the gate's rule set changes, the self-test fixtures must change with it — a strengthened rule with no red fixture is a validator that cannot go red, which is the shape this repo's own PR #74 ruling rejected.

Dispatch deferred to round 2 — batch:3 is full.

---

Generated by Claude Code