[objectstack-fleet]

Fixes #25165

Clause-②: no
Metadata-protocol: none

What this does

• SCAFFOLD_VITEST_RANGE in packages/cli/src/commands/init.ts moves from ~4.0.0 to ~4.1.12. os init -t plugin and os create plugin declare it in devDependencies. SCAFFOLD_NPM_OVERRIDES, which is built from it, puts it in the overrides of every standalone os init / os create plugin manifest. The override's shape is unchanged.
• The blank template's devDependencies.vitest and overrides.vitest are re-stamped from that constant by the write run of scripts/sync-scaffold-emission-policy.mjs, the same run create-objectstack's build invokes. Both scaffolders read one constant, and no value is kept by hand.
• A floor pin in packages/cli/test/scaffold-npm-overrides.test.ts: the range's lowest admitted version must be at or above the advisory fix for its major (4.1.12 on 4.x, 5.0.3 on 5.x). A major with no row is refused, not passed.
• The comments on the constant, the override and the template test carry the new measurement.
• .changeset/25165-scaffold-vitest-advisory.md bumps @objectstack/cli and create-objectstack at patch and gives the one-line move for existing projects.
• content/docs/deployment/troubleshooting.mdx (patch round): the npm 10 edgesOut entry's fix 2 prescribed overrides.vitest ~4.0.0, which installs vitest 4.0.18, inside the advisory. It now prescribes ~4.1.12. The entry names vitest 4.1.12's contradictory optional peer as the cause, says a direct vitest devDependency must move with the override (EOVERRIDE), and says how an existing ~4.0.0 project moves.

The advisory

I read the advisory from the npm registry's bulk advisory endpoint (registry.npmjs.org/-/npm/v1/security/advisories/bulk, 2026-10-22). This container's egress proxy refuses api.osv.dev (403 at CONNECT).

• GHSA-qxg6-89mg-rqv8, @vitest/mocker: affected from 2.1.0-beta.7 up to the fix in 4.1.12, and from 5.0.0-beta.1 up to the fix in 5.0.3. That confirms the card's range.
• Also on the baseline. npm audit of a baseline scaffold (~4.0.0, which resolves vitest and @vitest/mocker to 4.0.18) also lists:
  • GHSA-82fw-gwwq-j7x9 (@vitest/mocker, from 2.1.0 up to the fix in 4.1.11);
  • GHSA-5xrq-8626-4rwp (vitest, critical, from 4.0.0 up to the fix in 4.1.0).
• What the new floor clears. It clears all three, and GHSA-xp26-3454-mjgp, which affects exactly 4.1.11 on the 4.x line.

Route measurements

Method.

• Each manifest was installed in its own empty directory, with a fresh --cache for every leg.
• The @objectstack/* ranges are ^18.0.0, which resolves to the published 18.0.0.
• After each install I read vitest and every @vitest/mocker copy from node_modules, then ran npm audit --json.

Manifests.

• The blank template. For route B its bytes equal this PR's stamped template.
• The os init -t plugin, os create plugin, os init -t app and os init -t empty manifests. Their dependency blocks are byte-equal to what this branch's source emits, driven through packages/cli/bin/run-dev.js.

npm versions. 10.9.9 (the newest 10.x), 10.9.4 (the npm bundled with this container's Node 22) and 11.21.1 (the newest 11.x).

In the table, "4.1.12" means the tree holds exactly one vitest and one @vitest/mocker, both at that version.

Route	Manifest	npm 10.9.9	npm 11.21.1	npm 10.9.4
Baseline: ~4.0.0 + override	blank	exit 0 · 4.0.18 · audit lists the 3 advisories above	not measured	not measured
Baseline	os init -t plugin, os create plugin	exit 0 · 4.0.18 · audit lists them	exit 0 · 4.0.18 · audit lists them	not measured
A: ~4.1.12, no override	blank, os init -t plugin, os create plugin	exit 1, Cannot read properties of null (reading 'edgesOut')	blank: exit 0 · 4.1.12	not measured
A	os init -t app (declares no vitest), no override	exit 1, edgesOut	not measured	not measured
B, chosen: ~4.1.12 + override	blank, os init -t plugin, os create plugin	exit 0 · 4.1.12 · audit: no vitest / @vitest/* entry	exit 0 · the same	exit 0 · the same
B	os init -t app, os init -t empty	exit 0 · no vitest installed · audit: none	exit 0 · the same	not measured
C: ^5.0.5, no override	blank	exit 1, edgesOut	exit 0 · 5.0.5 at the root plus a nested 4.1.12	not measured
D: ^5.0.5 + override	blank, os init -t plugin, os create plugin	exit 0 · 5.0.5 · audit: no vitest entry	exit 0 · the same	not measured
D′: exact 5.0.4 + override (simulates latest having moved past the range)	blank	exit 0 · 5.0.4	exit 0 · 5.0.4	not measured

os create plugin audits to 0 entries on routes B and D. The other manifests keep 9 moderate entries on every route, and all 9 trace to one advisory: GHSA-w5hq-g745-h8pq on uuid 8.x, reached through exceljs from @objectstack/rest (see Acceptance notes).

Why route B holds on npm 10

• The crash comes from vitest 4.1.12's own peer set. It peers @vitest/browser-webdriverio ^4.1.11, and that package's only release, 4.1.11, peers vitest: 4.1.11 exactly. With the range at ~4.1.12, the root vitest reaches that peer set directly, so route A crashes every manifest that declares vitest. -t app crashes too, through optional vitest peers deeper in its closure.

• The vitest override alone settles it. With overrides.vitest equal to the declared range, npm 10.9.4 and 10.9.9 install every manifest. No @vitest/browser-webdriverio override is needed. The override is the existing SCAFFOLD_NPM_OVERRIDES mechanism, unchanged in shape.

• It does not depend on where latest points. latest is vitest 5.0.5, outside ~4.1.12, and the range still installs. The old comment's reading against ^5.0.0 ("installs only because it resolves to exactly the version latest names") was taken without an override. With the override, an exact pin below latest (5.0.4) installs too.

• Registry canary failed: fresh npx create-objectstack install is broken #24462's canary. On npm 10.9.9 the full blank template (every template file, with this PR's package.json):

  • installs with exit 0;
  • passes npm test: RUN v4.1.12, Test Files 1 passed (1), Tests 1 passed (1);
  • builds with npm run build, exit 0, Artifact: dist/objectstack.json.

  The canary installs published artifacts, so it reads this change only after a release.

• The plugin scaffolds. Each was emitted from this branch's source and installed on npm 10.9.9 (vitest and @vitest/mocker 4.1.12). npm run build and npm run typecheck exit 0 for both. Their npm test result is in Acceptance notes.

Why 4.1.x and not 5.x

Routes B and D both install on npm 10 and npm 11, and both clear the advisory. On the four axes:

• Business need. The scaffold's test (note.test.ts) needs nothing from vitest 5. vitest 5.0.5 declares engines.node ^22.12.0 || ^24.0.0 || >=26.0.0, which is narrower than the >=22.0.0 that @objectstack/cli and create-objectstack declare. vitest 4.1.12 declares ^20.0.0 || ^22.0.0 || >=24.0.0, the same as 4.0.18. So only route D gives a new project on Node 22.0 to 22.11 an engine warning, or a refusal under engine-strict.
• Long-term. The monorepo's own manifests run vitest ^4.1.11, re-locked to 4.1.12 for the same advisory family ([finding] main's lockfile matches two new OSV advisories on @vitest/mocker 4.1.11 (GHSA-qxg6-89mg-rqv8, GHSA-xp26-3454-mjgp; fixed in 4.1.12): the scheduled OSV scan is red again #25163). A scaffold on that line runs the vitest the platform is tested with. Moving to 5 is a deliberate change of its own, for the monorepo and the scaffolds together.
• AI error-proofing. A patch-line move inside major 4 changes no API that a generated test can call. The floor pin turns a move below the fix into a red test instead of a quiet regression.
• Startup scope. This is the smallest change that clears the advisory: one constant, its stamp and its pin.

Tests (head 4eb2ff4c4)

• CLI unit tier. pnpm --filter @objectstack/cli exec vitest run --project unit --maxWorkers=2, run under the verify lock.
  • First run: VERDICT command-exit 1, Test Files 2 failed | 320 passed (322), Tests 4728 passed | 29 skipped.
  • Both failures were test/published-subpath-console.pin.test.ts and test/published-subpath-hook-body.pin.test.ts refusing an unbuilt packages/cli/dist: a missing build, not a test failure.
  • After the package build, those two files plus test/scaffold-npm-overrides.test.ts (verbose): VERDICT command-exit 0, Test Files 3 passed (3), Tests 41 passed (41). That run includes the new floor case: its lowest admitted version is at or above the advisory fix for its major.
  • The integration tier is left to CI: the diff touches no spawn entry and no integration-tier file.
• create-objectstack. pnpm --filter create-objectstack test: Test Files 18 passed (18), Tests 278 passed (278).
• Typecheck. pnpm --filter @objectstack/cli typecheck && pnpm --filter create-objectstack typecheck: VERDICT command-exit 0. tsc -p tsconfig.test.json --listFiles in packages/cli lists scaffold-npm-overrides.test.ts once. create-objectstack's tsc --listFiles lists template-consistency.test.ts once.
• ESLint. pnpm exec eslint --no-inline-config over the 3 changed TypeScript files: exit 0.
• Ablation of the floor pin. The fix was committed first, and the mutation ran through scripts/ablation-replace.mjs in wrap mode.
  • Mutation: SCAFFOLD_VITEST_RANGE = '~4.1.12' became '~4.0.0'. The anchor went from 1 to 0 hits, and the blob changed from 47a2518d9a21 to 8da3d5de0b48.
  • Result: Tests 1 failed | 11 passed (12), with SCAFFOLD_VITEST_RANGE "~4.0.0" admits 4.0.0, below the fix 4.1.12. The 11 derived-equality cases stay green under the mutation, which is why the floor pin is needed.
  • Restore: the blob equals the HEAD blob (47a2518d9a21), git diff HEAD is empty and git status is clean.
  • The test imports ../src/commands/init.js, so no dist is on its path.

Gates (head 4eb2ff4c4)

• Derivation. node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack: 84 commands for 5 paths against merge base 425c743fd.
• Runs. Each command was run byte for byte, with its exit code captured before any pipe.
  • First pass: 80 commands exited 0.
  • check:dual-build-cjs-loads, check:i18n, check:i18n-coverage and check:i18n-walk-parity exited 3 (PREREQUISITE NOT MET: no built dist).
  • After a full package build (turbo run build, 75/75 tasks, under the lock), all four re-ran to exit 0.
• Reconciliation. --ran: 84 derived, 84 run, 0 NOT-MEASURED, 0 UNRUN, exit 0.
• Governed surfaces. node scripts/pm/check-governed-merges.mjs --branch claude/issue-25165-scaffold-vitest-advisory: exit 0, 0 of 5 paths governed, 176 changed lines.
• The stamp gates. Both are in the derived set and exited 0: check:scaffold-emission-policy (the template and the constant agree) and check:template-version-sync.

Patch round (head f355f41a2)

• origin/main was merged first (a22074c89), then the troubleshooting page was fixed (f355f41a2). The diff is now 6 paths against merge base ab488d9b7.
• dispatch-gates --commands derives 112 commands. Each was run with its exit code captured before any pipe, after a full package build (75/75 tasks). All 112 exited 0. --ran reports 112 run, 0 NOT-MEASURED, exit 0.
• check-governed-merges: 0 of 6 paths governed, 186 changed lines.
• On the merged head, test/scaffold-npm-overrides.test.ts passes 12/12 and create-objectstack passes 278/278.
• CI on f355f41a2: 39 check-runs succeeded and 7 were skipped. They include Check Documentation Links, Build Docs, Scaffold outside the monorepo, install, build and Check Changeset.

Acceptance notes

• A stale comment. In scripts/sync-scaffold-emission-policy.mjs, the comment on the devDependencies.vitest row still says the constant "holds why it is ~4.0.0". It is a comment outside the file surface, and the script reads the constant's value, not the comment.
• The remaining audit entries. A fresh scaffold's other npm audit entries all come from GHSA-w5hq-g745-h8pq on uuid 8.x, through exceljs ^4.4.0 in the published @objectstack/rest. The workspace overrides uuid in pnpm-workspace.yaml, which npm consumers never read. That is not this card.
• The plugin scaffolds' npm test. os init -t plugin and os create plugin emit a test script but no test file, so npm test exits 1 with "No test files found". It does the same on the baseline 4.0.18 (measured on -t plugin). That is not this card.
• origin/main (ab488d9b7) was merged into the branch in the patch round (merge commit a22074c89). It had no conflicts.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/cli, objectstack-blank, touching 4 documentable anchor(s). ⚠️ 1 changed file(s) yielded no anchor (packages/create-objectstack/src/templates/blank/package.json), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files.

12 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/ai/skills-reference.mdx (via edgesOut (literal, a string literal in a comment on a changed line))
• content/docs/ai/skills.mdx (via edgesOut (literal, a string literal in a comment on a changed line))
• content/docs/deployment/cli.mdx (via os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/deployment/self-hosting.mdx (via edgesOut (literal, a string literal in a comment on a changed line))
• content/docs/deployment/troubleshooting.mdx (via devDependencies (literal, a string literal in a comment on a changed line), edgesOut (literal, a string literal in a comment on a changed line), os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/getting-started/examples.mdx (via os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/getting-started/index.mdx (via edgesOut (literal, a string literal in a comment on a changed line))
• content/docs/getting-started/your-first-project.mdx (via edgesOut (literal, a string literal in a comment on a changed line), os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/plugins/index.mdx (via devDependencies (literal, a string literal in a comment on a changed line), os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/protocol/kernel/index.mdx (via os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/protocol/kernel/plugin-spec.mdx (via devDependencies (literal, a string literal in a comment on a changed line))
• content/docs/upgrading.mdx (via devDependencies (literal, a string literal in a comment on a changed line), edgesOut (literal, a string literal in a comment on a changed line))

⛔ 6 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v17/17-1.mdx (via os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/releases/v17/17-4.mdx (via os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/releases/v17/17-5.mdx (via os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/releases/v17/17-7.mdx (via os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/releases/v18/18-0.mdx (via devDependencies (literal, a string literal in a comment on a changed line), edgesOut (literal, a string literal in a comment on a changed line))
• content/docs/releases/v18/index.mdx (via edgesOut (literal, a string literal in a comment on a changed line))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• 1 changed file(s) yielded no anchor (packages/create-objectstack/src/templates/blank/package.json) — pages documenting those are invisible to this run
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 30 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json ab488d9b7dff7a8da918973311f83c3bf443e51b → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 8477db1bd320894594fe4c93c740e0be1b94e1f2 — the merge of head f355f41a2c524a97eca689928c22d2cd5c7b801e into base ab488d9b7dff7a8da918973311f83c3bf443e51b, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 8477db1bd320894594fe4c93c740e0be1b94e1f2 && git checkout 8477db1bd320894594fe4c93c740e0be1b94e1f2
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin ab488d9b7dff7a8da918973311f83c3bf443e51b f355f41a2c524a97eca689928c22d2cd5c7b801e && git checkout -B drift-repro ab488d9b7dff7a8da918973311f83c3bf443e51b && git merge --no-ff f355f41a2c524a97eca689928c22d2cd5c7b801e

node scripts/docs-audit/affected-docs.mjs --json ab488d9b7dff7a8da918973311f83c3bf443e51b

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs ab488d9b7dff7a8da918973311f83c3bf443e51b → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

席位核对 · ACCEPT (landing on green)

domain:cli seat 2 (#22648) · os-bill · session session_01AFrKwndmrCLtF5V9hNtrw3 · 2026-10-22T06:15Z · head f355f41a2 · claim 6332477074 (amended for the troubleshooting page) → reports on #25165 (route measurement and the patch round).

Check	Reading
Shape	Draft, base main. First line Fixes #25165; Clause-②: no, Metadata-protocol: none. One changeset, @objectstack/cli and create-objectstack patch. 6 files, +134 / −52. check-governed-merges.mjs --pr 25173: not governed, 186 lines ≤ 3000. No contract face, so this ACCEPT is the review of record at the seat's tier. Body edits applied by the seat from the patch report.
The card's contract, read against the diff	SCAFFOLD_VITEST_RANGE moves ~4.0.0 → ~4.1.12; SCAFFOLD_NPM_OVERRIDES derives from it, so os init -t plugin and os create plugin emit the same range in devDependencies and overrides; the create-objectstack blank template is re-stamped by the sync script. A floor pin refuses any range whose lowest version is below the advisory's fix for its major (ablation: reverting to ~4.0.0 reds it). The route table on #25165: ~4.1.12 + overrides.vitest installs on npm 10.9.4, 10.9.9 and 11.21.1 with no @vitest/* audit entry; ~4.1.12 without the override crashes npm 10 (edgesOut); vitest 5 also installs but narrows Node's engines below the CLI's >=22.0.0, so it is not taken. Dropping npm 10 support was never needed.
The published page	content/docs/deployment/troubleshooting.mdx's edgesOut entry now prescribes overrides.vitest ~4.1.12 (it prescribed ~4.0.0, inside the advisory), says a direct vitest devDependency must equal the override (EOVERRIDE), and tells an existing ~4.0.0 project to move both; read sentence by sentence against the measurements: true.
Changeset prose	True against the diff; it gives existing projects the move.
Gates	Patch-round head: 112/112 derived families exit 0 after a full build, --ran reconciled; scaffold-npm-overrides 12/12, create-objectstack 278/278. CI on this head before the body edit: 39 success, 7 skipped, 0 failure (incl. Check Documentation Links, Build Docs, "Scaffold outside the monorepo, install, build").
Out of scope, filed	#25174 (@objectstack/rest ships uuid 8.x to npm consumers through exceljs) and #25175 (the plugin scaffolds' npm test finds no test file; serial after this card). Recorded: the dev cleared the container's shared npm cache (/root/.npm/_cacache) under disk pressure; a cache, nothing lost.
Landing	Not governed ⇒ pr_ready + automerge_enable through the relay once every check on this head is success or a by-design skip. Then #25123 and #25175 (same file init.ts) are dispatchable in turn.

---

Generated by Claude Code