test(create-objectstack,metadata): make two version-sensitive tests hold across the 17.5.0 version pass

[hotlong]

Fixes #20560

Unblocks the 17.5.0 Version Packages PR #17076 (changeset-release/main). Its required Test Core (1/6) is red on head de35e567 (CI run 36510180528):

AssertionError: scaffolded Dockerfile pins :17.4.2 but the scaffolded package.json asks for "^17.5.0" — the generated app would run a runtime image that is not the CLI building its artifact (#9017): expected false to be true

Both changes are test-only. No runtime code moves, and neither file ships: both packages publish only dist, README.md and CHANGELOG.md, and neither file is a tsup entry. So there is no changeset and the PR carries skip-changeset.

1. create-objectstack: the runtime-image fixture (the reported failure)

runtime-image.test.ts planted the npm-resolved @objectstack/cli as the literal ${major}.4.2. The scaffolder writes a caret range on its own version, so that literal is inside the range only while the minor is 4 or lower. At 17.5.0 it falls below the floor, and the agreement test blamed the scaffolder for what was a fixture defect.

• resolved is now derived from the package's own version: same major, own minor + 1, patch 2 (17.4.0 gives 17.5.2, 17.5.0 gives 17.6.2). It is always inside the caret range and always above its floor, which is what the fixture's own comment says it is for.
• A new precondition test, plants a resolved version inside the scaffolded range and above its floor, makes future fixture drift point at the fixture rather than at the scaffolder.

I checked the other create-objectstack tests for a current-minor assumption. They key on the major only (template-consistency), use fixed literals unrelated to the package version (the readResolvedCliVersion cases, banner-version), or carry a fixture version of their own (template-version-stamps). The whole suite passes on the versioned tree (table below).

2. metadata: artifact-door notice wording (found by running the unreached shard-1 packages on the versioned tree)

Turbo stopped shard 1 at the failure above, so ten scheduled packages never ran against 17.5.0. Running them found one more failure of the same class:

FAIL src/plugin-artifact-forward-conversion-retired-after.test.ts > [#20390] artifact door — a 17.4.0-built artifact boots on unreleased main > logs one conversion summary per retired entry it replayed, naming the site count
AssertionError: expected '[MetadataPlugin] artifact \'forward-p…' not to contain 'predates this runtime\'s spec'

The fixture is a 17.4.0-built artifact (engines.protocol: ^17.4.0). While packages/spec carries the 17.4.0 label, the floor is not below the label. The per-entry half of the window opens (converted-retired-after), and its clause deliberately avoids "predates". The version pass moves the label to 17.5.0 and the floor falls below it. The label half opens instead (converted-forward), and the door correctly prints predates this runtime's spec (authored engines.protocol floor 17.4.0, runtime spec 17.5.0). The runtime behaves as designed; the assertion had the pre-release label built in.

The assertion now reads the running spec label the same way the door does, with resolveInstalledSpecVersion(). plugin-artifact-forward-conversion.test.ts already uses that pattern. The test then pins the exact clause of whichever half that label selects. Both halves were exercised: the per-entry clause on main (label 17.4.0), and the predates clause with the exact floor and runtime version on the versioned tree (label 17.5.0).

Verification on the versioned tree

I made a throwaway worktree at origin/changeset-release/main = de35e567, the #17076 head that the failing run tested, and copied both fixes in. Then:

1. pnpm install --frozen-lockfile.
2. pnpm turbo run build over each package's dependency closure (--filter='PKG^...'; 61 tasks, 0 cached).
3. Each package's own script via pnpm --filter PKG run SCRIPT, with the env Test Core sets (OS_TEST_TIERS=queue, CI=true).

Package	Script	Result on de35e56 + this PR
create-objectstack	test	pass: 16 files / 234 tests. Without the fix: 1 failed, the assertion quoted above
@objectstack/spec	test	pass: 573 / 16846, 1 todo
@objectstack/spec	test:repo	pass: 40 / 716
@objectstack/verify	test	pass: 15 / 116
@objectstack/metadata	test	pass: 55 / 826. Without the fix: 1 failed, the assertion quoted in section 2
@objectstack/plugin-audit	test	pass: 25 / 363
@objectstack/example-todo	test	pass: 7 / 238
@objectstack/trigger-record-change	test	pass: 10 / 101
@objectstack/formula	test	pass: 42 / 1227
@objectstack/downstream-contract	test	pass: 3 / 31
@objectstack/service-cluster-redis	test	pass: 3 / 37
@objectstack/knowledge-ragflow	test	pass: 1 / 10

Of shard 1's other scheduled packages, @objectstack/types had already passed in that run, and shards 2–6 were green. So every package that run scheduled has now passed against the de35e567 tree.

Checks on this branch (base b0574343)

• pnpm --filter create-objectstack test: 16 files / 234 tests pass; typecheck clean.
• pnpm --filter @objectstack/metadata test: 55 / 826 pass (the per-entry half); typecheck clean.
• eslint on both changed files: clean.

main has since moved to f6ceddc3, six commits on. None of them touches packages/create-objectstack, packages/metadata or packages/metadata-core.

A wider gap is tracked separately in #20562 and not addressed here: a version-sensitive test is only exercised after pnpm run version.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• 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 — 0 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 f6ceddc3c4deb9d56025fff9fae03d65b62e95a7 → packageMentionDocs.