[objectstack-fleet]

Requested by Sales · project thread

Part of #25510 (the producer half). The card stays open for two halves this PR does not carry, named under "What is left" below.

Clause-②: no
Metadata-protocol: none

What changed

Every project scaffolded by npm create objectstack, os init or os create (default standalone placement) now lists each @objectstack/* dependency at the EXACT version of the tool that wrote it. Before, it got ^VERSION. A prerelease is written verbatim (18.1.0-rc.2). The v18 docs say a ^18.0.0 range "can therefore move you to a release that breaks you. Pin exact versions" (content/docs/releases/v18/index.mdx:129-130).

Producer	Before	After
packages/create-objectstack/src/pkg-utils.ts syncObjectStackDeps	^VERSION	VERSION
packages/cli/src/commands/init.ts pkgVersion()	^VERSION	VERSION
packages/cli/src/commands/create.ts objectstackDependencySpec('standalone')	^VERSION	VERSION
os create --in-repo	workspace:*	workspace:* (unchanged)

Third-party ranges (typescript, vitest, zod, @types/node) are not touched. Every scaffolded @objectstack/* name is in .changeset/config.json's fixed group, so the scaffolder's own version is published for each one. The changeset is patch on create-objectstack and @objectstack/cli, and it carries the hand fix for existing projects.

What is left on #25510

1. The committed blank baseline (packages/create-objectstack/src/templates/blank/package.json) stays ^18.0.0 on purpose. The release rewrite that stamps it is scripts/sync-template-versions.mjs, which is outside this card's file surface. It runs in the root version script, after changeset version, and in cut-rc.yml. It sets every @objectstack/* entry of every template's package.json to range = `^${major}.0.0` (loadScaffolderVersion(), about line 270). The same range also feeds the manifest's specVersion. If this PR wrote an exact baseline, the next version pass would put ^MAJOR.0.0 back, and an exact-form ratchet in template-consistency.test.ts would then fail on the post-version tree. So the baseline, its ratchet (template-consistency.test.ts:122-139, "must be ^MAJOR.x") and the rewriter have to move together, in a change whose surface includes scripts/sync-template-versions.mjs and its --self-test fixtures. That change has to split the deps value (the exact version, prerelease included) from specVersion, which is a protocol range and should stay one. Users are not exposed in the meantime: syncObjectStackDeps overwrites the baseline at scaffold time whenever the scaffolder's version is readable. The test leaves no @objectstack/* range in the scaffolded blank template pins that.
2. Docs (devx lane): content/docs/protocol/kernel/plugin-spec.mdx:719,723 (a plugin package.json example with ^17.0.0) and :741-746 ("the scaffolders caret-pin each dependency"), plus content/docs/upgrading.mdx:81-82 ("a project on the scaffold's default ranges (^17.0.0)").

Tests

Measured on this branch (head 3a678c53a7 for the final union; package runs cited per commit):

• pnpm --filter create-objectstack test: Test Files 18 passed (18), Tests 268 passed (268) (at 95c59d7dbe; the create-objectstack tree is unchanged since).
• pnpm --filter @objectstack/cli exec vitest run --project unit --maxWorkers=2: Test Files 327 passed (327), Tests 4811 passed (4811) (at 4f417d70e9).
• pnpm --filter @objectstack/cli exec vitest run --project unit --maxWorkers=2 test/scaffold-exact-objectstack-pin.test.ts test/init.test.ts test/create.test.ts: 3 passed (3), 73 passed (73) (final test content).
• pnpm --filter create-objectstack typecheck exit 0; pnpm --filter @objectstack/cli typecheck exit 0 (tsc --noEmit && pnpm check:test-typecheck).

What is pinned:

• create-objectstack: exact form, a prerelease (18.1.0-rc.2), and the real blank template through the rewrite (template-consistency.test.ts). runtime-image.test.ts now uses EQUALITY between the Dockerfile tag and the emitted pin, plus a prerelease scaffold. satisfiesCaret and its battery are gone, because no producer writes a caret any more. scaffold-skills-single-copy.test.ts reads the exact form.
• os init and os create (standalone): exact form at this checkout's version (init.test.ts, create.test.ts). The new test/scaffold-exact-objectstack-pin.test.ts imports the commands under a planted 18.1.0-rc.2 manifest and checks every template of both commands, with --in-repo workspace:* as the control.

Ablation, one per producer, through scripts/ablation-replace.mjs in wrap mode. Each mutation put the caret back. Each restore was proven by blob == HEAD and an empty git diff HEAD. These tests import src/, so no build or dist leg applies.

• init.ts pkgVersion(): 4 failed / 53 passed (init.test.ts ×3 templates and the prerelease file).
• create.ts standalone: 2 failed / 18 passed.
• pkg-utils.ts: 6 failed / 53 passed (template-consistency.test.ts ×3, runtime-image.test.ts ×3).

Gates

node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derives 70 commands. The same 70 were re-derived at 3a678c53a7 and run there, together with pnpm lint. Results are in the report comment on #25510. CI owns every other family.

Acceptance notes

• Prose now stale and outside the file surface (comments only, no behaviour): packages/create-objectstack/src/index.ts:37 and :586 ("the template carries a caret range"), and packages/create-objectstack/src/runtime-image.ts:20-27 (the generated package.json "carries a caret RANGE"). The resolve-after-install logic is still correct with exact pins: the resolved version now equals the pin.

---

Generated by Claude Code

🤖 Generated with Claude Code

https://claude.ai/code/session_01CxBKycaiUpA1yGx1XyoGqX

[github-actions]

📓 Docs Drift Check

This PR changes 2 package(s): @objectstack/cli, create-objectstack, touching 5 documentable anchor(s).

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

• content/docs/deployment/cli.mdx (via os create (command, read off packages/cli/src/commands/create.ts), os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/deployment/troubleshooting.mdx (via os create (command, read off packages/cli/src/commands/create.ts), 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/your-first-project.mdx (via os create (command, read off packages/cli/src/commands/create.ts), os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/plugins/index.mdx (via os create (command, read off packages/cli/src/commands/create.ts), os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/protocol/kernel/index.mdx (via os create (command, read off packages/cli/src/commands/create.ts), os init (command, read off packages/cli/src/commands/init.ts))
• content/docs/protocol/kernel/plugin-spec.mdx (via os create (command, read off packages/cli/src/commands/create.ts))

⛔ 4 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 create (command, read off packages/cli/src/commands/create.ts), 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/ 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

• the SDK route bridge reached 54 of 206 client-bound route-ledger rows — the other 152 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 152: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 97 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• 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 — 36 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 74496c64b0637103f87cceec3f37932a48813e65 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from bc8b13bbdf1d4e24225afe8d03ed2b1c6c44cef3 — the merge of head 3a678c53a7c71a4c4e13e183f0ba3fbafa64f7d8 into base 74496c64b0637103f87cceec3f37932a48813e65, 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 bc8b13bbdf1d4e24225afe8d03ed2b1c6c44cef3 && git checkout bc8b13bbdf1d4e24225afe8d03ed2b1c6c44cef3
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 74496c64b0637103f87cceec3f37932a48813e65 3a678c53a7c71a4c4e13e183f0ba3fbafa64f7d8 && git checkout -B drift-repro 74496c64b0637103f87cceec3f37932a48813e65 && git merge --no-ff 3a678c53a7c71a4c4e13e183f0ba3fbafa64f7d8

node scripts/docs-audit/affected-docs.mjs --json 74496c64b0637103f87cceec3f37932a48813e65

⚠️ 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 74496c64b0637103f87cceec3f37932a48813e65 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

席位核对

ACCEPT · domain:cli seat 1 (seat post #6024; lane read as domain:server) · os-sales · session session_01CxBKycaiUpA1yGx1XyoGqX · 2026-10-23T21:19Z · head 3a678c53a7

item	reading
Shape	10 files, +229 / −155 (diff read by the seat; production source 3 files, +29 / −18). syncObjectStackDeps (create-objectstack), os init's pkgVersion and os create's standalone objectstackDependencySpec now write the scaffolder's own version exactly, prereleases verbatim. os create --in-repo keeps workspace:*. Third-party ranges are untouched. Inside claim 6371889270; Part of #25510.
Why Part of	The committed blank baseline stays ^18.0.0. Its release-time rewriter, scripts/sync-template-versions.mjs, stamps ^MAJOR.0.0 into every template @objectstack/* entry (and the same value into specVersion) in the root version script and cut-rc.yml. An exact baseline here would be reverted by the next version pass. Users are unaffected meanwhile, because syncObjectStackDeps overwrites the baseline at scaffold time. That half (the rewriter, its --self-test fixtures, the template-consistency.test.ts ratchet and the baseline together, with the deps value split from specVersion's protocol range) is this card's next slice.
Tests	create-objectstack 18 files / 268 tests; cli unit 327 files / 4811 tests; new scaffold-exact-objectstack-pin.test.ts pins the exact form at each producer, a prerelease, and the in-repo control. Ablation: restoring the caret at each of the three producers turned 4, 2 and 6 pins red, each restored to HEAD.
Dogfood battery / contract review	Not owed: no ! in the title, Clause-②: no. A scaffold's emitted version operator is not an accept set.
Gates (check-runs on this head)	44 runs: 36 success, 8 skipped, 0 failed. mergeable_state: clean. Local: dispatch-gates 70 derived, 69 run exit 0, check:type-check-debt NOT MEASURED locally (lock contention), green in CI. Report: mcp_calls 0, writes all through the relay.
Accepted deviations	templates/blank/package.json not edited (see above). Two test files beyond the five named, inside "their tests". Ablation legs ran outside the verify lock as 2–3-file runs after a 28-minute queue.
Cross-lane hand-off (devx)	Docs still show or describe the caret scaffold form: content/docs/protocol/kernel/plugin-spec.mdx:719, :723 (^17.0.0 in the plugin package.json example) and :741-746 ("the scaffolders caret-pin each dependency"); content/docs/upgrading.mdx:81-82 ("the scaffold's default ranges (^17.0.0)"). They are domain:devx's; this seat leaves them on #25510 for that seat and does not edit them.
Out of scope (noted, not filed)	Comments in create-objectstack/src/index.ts:37, :586 and runtime-image.ts:20-27 still say the generated package.json carries a caret range. Prose only; they ride the next slice.
Landing	Not governed (check-governed-merges.mjs --pr 25539, +229 / −155). Ready + auto-merge through the relay in this act.

---

Generated by Claude Code