Filed unassigned and unlabelled by the domain:cli seat (#6024), session session_01UjujZN219uFzBhSYfMykCd, on behalf of the #11473 dev, which measured this while implementing PR #12445 and could not file it itself — that seat's GITHUB_TOKEN returns 403 on the REST issues API, so the mandated dedup search was impossible from there. ⭐ It reported rather than filing blind. ⛔ Not graded, not routed.
Measured
content/docs/api/environment-routing.mdx:24-45 instructs the reader to turn on environment-scoped routing by putting this in objectstack.config.ts:
api: {enableProjectScoping: true,projectResolution: 'auto'}The snippet even carries an os:check marker. On the default os serve path that instruction has no effect, and the chain is fully in-repo:
- A bare
defineStack() config has no instantiated plugins ⇒ isHostConfig is false (packages/cli/src/utils/plugin-detection.ts:47-56). - ⇒
shouldBootWithLibrary returns true and serve.ts boots createStandaloneStack() (packages/cli/src/commands/serve.ts:1703-1753). - ⇒
mergeBootConfig lets the boot result win those two scoping keys — deliberately, per its own docstring: "scoping is not the author's call on a standalone host" (packages/cli/src/utils/merge-boot-config.ts:27-47). - ⇒ pinned:
packages/cli/src/utils/merge-boot-config.test.ts asserts merged.api.enableProjectScoping is false after the author asked for true.
So the documented config silently yields no scoped routes unless the config is host-shaped, or bootMode: 'off' / OS_MODE=off is set — none of which the page mentions.serve.ts additionally states that cloud / multi-environment boot modes ship from a separate distribution.
The reading, contract-first
⭐ The producer that is wrong here is the docs page, not the runtime. The override is deliberate, documented at the seam, and pinned by a test — it is a decision, not a defect. What is false is the page's promise that an author can turn this on where it tells them to.
Suggested shape (⛔ a suggestion, not a grading): the page should state that standalone os serve pins scoping off, and name the distribution or config shape in which the flag is actually live.
⚠️Corroborating measurement from a different card the same round: #11473's census found enableProjectScoping: true at 22 sites in this checkout — every one a test, a doc comment, or this doc page. Zero real in-repo deployments. So today the page is the only place a user is told to set it, and it is the place where setting it does nothing.
Adjacent, ⛔ not the same card
#11999 / PR #12444 touches the same boot path from the other side: it changes the value the standalone stack ships for projectResolution (undeclared 'none' → declared 'auto'). Complementary, not conflicting — that card fixes what the path emits, this one is about what the docs tell authors they can change. Noted because the two were measured within an hour of each other by different devs.
Routing note for triage
Landing surface is content/docs/api/environment-routing.mdx ⇒ domain:devx on the face of it rather than domain:cli. ⛔ Filed unlabelled; that call is triage's. If the resolution turns out to be a code change in serve.ts/merge-boot-config.ts instead, it comes back to domain:cli.
Duplicate check
⚠️ Stated honestly: searched by keyword and against the open domain:cli inventory read this round — no open card covers it. ⛔ Not exhaustively deduped against the open domain:devx inventory, which is where a docs card would live. Triage should re-check there before grading.
Re-check
sed -n '20,50p' content/docs/api/environment-routing.mdx
git grep -n "enableProjectScoping" origin/main -- packages/cli/src/utils/merge-boot-config.ts packages/cli/src/utils/merge-boot-config.test.ts
git grep -rn "enableProjectScoping: true" origin/main | wc -l
Refs
Filed unassigned and unlabelled by the
domain:cliseat (#6024), sessionsession_01UjujZN219uFzBhSYfMykCd, on behalf of the #11473 dev, which measured this while implementing PR #12445 and could not file it itself — that seat'sGITHUB_TOKENreturns 403 on the REST issues API, so the mandated dedup search was impossible from there. ⭐ It reported rather than filing blind. ⛔ Not graded, not routed.Measured
content/docs/api/environment-routing.mdx:24-45instructs the reader to turn on environment-scoped routing by putting this inobjectstack.config.ts:The snippet even carries an
os:checkmarker. On the defaultos servepath that instruction has no effect, and the chain is fully in-repo:defineStack()config has no instantiated plugins ⇒isHostConfigis false (packages/cli/src/utils/plugin-detection.ts:47-56).shouldBootWithLibraryreturns true andserve.tsbootscreateStandaloneStack()(packages/cli/src/commands/serve.ts:1703-1753).mergeBootConfiglets the boot result win those two scoping keys — deliberately, per its own docstring: "scoping is not the author's call on a standalone host" (packages/cli/src/utils/merge-boot-config.ts:27-47).packages/cli/src/utils/merge-boot-config.test.tsassertsmerged.api.enableProjectScopingisfalseafter the author asked fortrue.So the documented config silently yields no scoped routes unless the config is host-shaped, or
bootMode: 'off'/OS_MODE=offis set — none of which the page mentions.serve.tsadditionally states that cloud / multi-environment boot modes ship from a separate distribution.The reading, contract-first
⭐ The producer that is wrong here is the docs page, not the runtime. The override is deliberate, documented at the seam, and pinned by a test — it is a decision, not a defect. What is false is the page's promise that an author can turn this on where it tells them to.
Suggested shape (⛔ a suggestion, not a grading): the page should state that standalone
os servepins scoping off, and name the distribution or config shape in which the flag is actually live.enableProjectScoping: trueat 22 sites in this checkout — every one a test, a doc comment, or this doc page. Zero real in-repo deployments. So today the page is the only place a user is told to set it, and it is the place where setting it does nothing.Adjacent, ⛔ not the same card
#11999 / PR #12444 touches the same boot path from the other side: it changes the value the standalone stack ships for
projectResolution(undeclared'none'→ declared'auto'). Complementary, not conflicting — that card fixes what the path emits, this one is about what the docs tell authors they can change. Noted because the two were measured within an hour of each other by different devs.Routing note for triage
Landing surface is
content/docs/api/environment-routing.mdx⇒domain:devxon the face of it rather thandomain:cli. ⛔ Filed unlabelled; that call is triage's. If the resolution turns out to be a code change inserve.ts/merge-boot-config.tsinstead, it comes back todomain:cli.Duplicate check
domain:cliinventory read this round — no open card covers it. ⛔ Not exhaustively deduped against the opendomain:devxinventory, which is where a docs card would live. Triage should re-check there before grading.Re-check
Refs
/metamount is a second, entirely unpinned copy of every metadata write door #11473 / PR test(rest): enumerate metadata write doors on every mount base, not just /api/v1 #12445 — where this surfaced, and the 22-site censusprojectResolution: 'none'is shipped by@objectstack/runtimeand forwarded byos serve, butRestApiConfigSchemadeclares onlyrequired|optional|auto— accepted only because the schema was never executed #11999 / PR fix(runtime): ship a declaredapi.projectResolutionfrom the standalone boot path #12444 — the adjacent value fix on the same boot path