fix(runtime): ship a declared api.projectResolution from the standalone boot path

[os-litant]

Fixes#11999

Route 2 of the card's two — migrate the runtime to a declared value — taken because the ruling's premise was tested first and held where it mattered. The measurement also found a second declared contract the card did not measure, which makes route 2 strictly stronger than the card frames it.

The premise, measured

Premise:enableProjectScoping: false already makes the resolution strategy moot on the standalone path, so 'none' and 'auto' are the same behaviour there.

I enumerated every reader of api.projectResolution in the repo and checked each one's gate:

Reader	Gated on enableProjectScoping?	With scoping false
rest-server.tsregisterRoutes	yes — if (enableProjectScoping)	takes the else arm, value never read
direct-mount-composition.ts	yes — ternary lives inside the true arm	mounts [versionedBase], value never read
dispatcher-plugin.ts (bridge routes)	yes — enableProjectScoping && … === 'required'	short-circuits
dispatcher-plugin.ts (mountAiRoute)	yes — same conjunction	short-circuits
dispatcher-plugin.tslogger.info	no	logged verbatim (observability only)
rest-server.ts discovery handler	no	copied verbatim into discovery.scoping.resolution

For routing the premise HOLDS — all four readers that act on the key are gated, so 'none' and 'auto' really do produce identical route tables on a standalone host. That is what licenses migrating the value instead of teaching the enum a fourth member.

For the advertisement it does not, and that is the user-visible half the card missed. The discovery handler's scoping block is attached with no enableProjectScoping guard, and DiscoverySchema (packages/spec/src/api/discovery.zod.ts) declares scoping.resolution as the same three-member enum. So GET /api/v1 on every os serve boot advertised a payload the platform's own schema rejects. Measured, not read:

RestApiConfigSchema {enableProjectScoping:false, projectResolution:'none'} REFUSED path=["projectResolution"] code=invalid_value
…'auto' ACCEPTED
DiscoverySchema.scoping.resolution 'none' REFUSED path=scoping.resolution code=invalid_value
'auto' ACCEPTED

This does not open the fork the ruling reserved. 'none' does not mean anything 'auto' does not; it propagates the same unrecognised string into a second declared enum that also lacks it. Route 1 would have to widen twopackages/spec enums and give 'none' a branch in four readers; route 2 fixes both in one literal. packages/spec/** was not touched.

What changed

• packages/runtime/src/standalone-stack.ts — StandaloneStackResult['api'] declares, and the factory emits, projectResolution: 'auto'. (createDefaultHostConfig delegates here, so this is the single emit site.)
• packages/cli/src/utils/merge-boot-config.ts — the doc block that quotes the boot api object.
• Both sibling tests — the pin the card asks for, below.

packages/cli/src/commands/serve.ts was not touched: it is card #12151's surface, and it needed no edit — apiConfig.projectResolution ?? 'auto' forwards the now-declared value unchanged.

The pin that did not exist

The card is right that the missing check is the valuable half. Both sides are now parsed against the declared schema rather than described:

• standalone-stack.test.ts parses the api block the factory actually returns — not a restatement of it.
• merge-boot-config.test.ts parses the CLI's boot block, and the merged block that serve really forwards, plus the discovery field's enum.
• Each case asserts the refusal of 'none' next to the acceptance of 'auto', on the offending path and issue code — a pin that cannot say no is not a pin.
• BOOT_API is now typed StandaloneStackResult['api'] instead of as const, so the CLI copy can no longer drift from the producer. Hand-copies are exactly how three packages disagreed here.

Reverse verification

Predicted red on both legs before running; ran with a restore trap on absolute paths. Reverting the runtime literal to 'none', confirmed on disk (2 injected / 0 remaining) and confirmed to reach dist/ via ablation-dist-preflight (marker present in 2 built files):

LEG A packages/cli tsc --noEmit EXIT=1
merge-boot-config.test.ts(21,79): error TS2322: Type '"auto"' is not assignable to type '"none"'.
LEG B packages/runtime vitest EXIT=1 Tests 1 failed | 18 passed code: "invalid_value"

Restore leg rebuilt and verified too — git diff HEAD empty, and ablation-dist-preflight --absent confirms the marker is gone from all 6 built files, so no later reading measured the mutated tree.

Note for reviewers: packages/runtime's typecheck program does not include standalone-stack.test.ts (0 hits under tsc --listFiles), so "runtime typecheck clean" says nothing about that file. It is covered by vitest and by leg B instead. packages/cli's program does include its test file (1 hit), which is what makes the BOOT_API type pin live.

Verification — all at 163cb3454

pnpm --filter @objectstack/cli exec vitest run src/utils/merge-boot-config.test.ts 11 passed (11)
pnpm --filter @objectstack/runtime exec vitest run src/standalone-stack.test.ts 19 passed (19)
pnpm --filter @objectstack/cli run typecheck clean
pnpm --filter @objectstack/runtime run typecheck clean
pnpm lint (repo-wide, eslint . --no-inline-config) VERDICT command-exit 0

Gate families re-derived in this worktree with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack over the real change set (5 paths), not from the dispatch order. All green:

check:cross-package-test-inputs · check:test-source-alias · check:type-source-resolution · check:engine-double-contract · check:where-matcher · check:query-options-erasure · check:nul-bytes · check:changeset-gate-self-tests · check:objectui-changeset · check:published-files · check:page-declaration-shape · check:slot-lookup · check:type-check-coverage · check:type-check-debt · check:i18n · check:i18n-coverage · check-empty-changeset · check-changeset-no-major · check-adr-0087-registration · check-ci-filter-parity · check-comment-mask-adoption · check-plugin-teardown-shape · docs-audit/check-affected-docs · docs-audit/check-drift-comment · release-rehearsal-clone --self-test

check:i18n, check:i18n-coverage and check:type-check-debt first exited 1 with explicit prerequisite refusals ("Nothing was checked", "cannot run") — not measurements. Re-run green after turbo run build --filter='./packages/*' --filter='./packages/*/*'.

Deliberately not done here

• fix(rest): parse the declared api config at the RestServer seam instead of casting to it #11985's .omit({ projectResolution: true }) in rest-server.ts:719 is left in place — the card names its removal as the landing note for a different PR, and packages/rest/src/rest-server.ts is held by PR State SaveReportInput's requirements at the reports.save door #12421.
• packages/rest/src/rest-config-parse-not-cast.test.ts's case titled "KEEPS projectResolution: 'none' — the value this platform actually ships" still passes (it constructs directly), but its rationale goes stale the moment this lands: the platform stops shipping 'none'. Same follow-up, outside this surface.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

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

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

• content/docs/data-modeling/drivers.mdx(via createStandaloneStack (symbol))
• content/docs/deployment/single-project-mode.mdx(via createStandaloneStack (symbol))
• content/docs/plugins/index.mdx(via createStandaloneStack (symbol))

What this run could not see

• 1 changed file(s) yielded no anchor (packages/cli/src/utils/merge-boot-config.ts) — pages documenting those are invisible to this run
• 1 name(s) were too generic to anchor anything (single lowercase words)
• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 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.

Coarse fallback — 37 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 8515954fb6dd4102e120b59ce6410f94600d5710 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from da58ae89fc32ea5a756715bfabbbe9274cb1b0cd — the merge of head 163cb345408ed3fec897b745977e7238f8edc52d into base 8515954fb6dd4102e120b59ce6410f94600d5710, 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 da58ae89fc32ea5a756715bfabbbe9274cb1b0cd && git checkout da58ae89fc32ea5a756715bfabbbe9274cb1b0cd
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 8515954fb6dd4102e120b59ce6410f94600d5710 163cb345408ed3fec897b745977e7238f8edc52d && git checkout -B drift-repro 8515954fb6dd4102e120b59ce6410f94600d5710 && git merge --no-ff 163cb345408ed3fec897b745977e7238f8edc52d
node scripts/docs-audit/affected-docs.mjs --json 8515954fb6dd4102e120b59ce6410f94600d5710

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