Recording, not claiming — filed unlabelled and unassigned from the #11614 run (PR #12149), which single-sourced the resolution-path spelling and deliberately stopped there.
Fact
#11614 moved the package name serve actually resolves onto one declaration, Serve.ORGANIZATIONS_RUNTIME_PKG, and pinned it against PLATFORM_PLUGIN_WIRED_RUNTIMES' key space. Both loading uses read it (importFromHost, readHostDeclaration).
packages/cli/src/commands/serve.ts still contains the literal string @objectstack/organizations at eight further sites, measured at 2ba4329:
- three inside comments (harmless);
- five inside operator-facing message text — the two-branch install remedy, the FATAL refusal when a walled tenancy posture cannot load the runtime, the degraded-boot warning, the stage-2 mount refusal, and the
--help-adjacent tier description near the bottom of the file.
None of the five is under any pin.
Why it might be worth a follow-up
Two of them are instructions the operator acts on — "add @objectstack/organizations to THIS APP", "this app DECLARES @objectstack/organizations". If the roster key is ever renamed, those sentences keep naming the old package while boot resolves the new one, and every gate stays green: the roster pin only sees the declaration, and no test reads the message text.
Why it was NOT done in #11614
Deliberate, and stated in that PR's body rather than left silent. Interpolating the constant into those strings is a provable no-op today (the declared value is byte-identical to the literal), but it is churn across a fatal-path message that an operator reads at the worst possible moment, and a whitespace slip there is a real regression in the one text that has to be right. The card's scope was the resolution path.
Shape, if someone takes it
Interpolate Serve.ORGANIZATIONS_RUNTIME_PKG into the five message sites and cover the rendered output with a test, so the substitution is checked rather than eyeballed. A source-scan pin asserting "no bare literal outside the declaration" is the tempting stronger form, but it would have to exclude comments, which is where that shape usually goes wrong.
Refs: #11614 · PR #12149 · #10921 (why the roster exists) · #11263 (the roster's landing).
Recording, not claiming — filed unlabelled and unassigned from the #11614 run (PR #12149), which single-sourced the resolution-path spelling and deliberately stopped there.
Fact
#11614 moved the package name
serveactually resolves onto one declaration,Serve.ORGANIZATIONS_RUNTIME_PKG, and pinned it againstPLATFORM_PLUGIN_WIRED_RUNTIMES' key space. Both loading uses read it (importFromHost,readHostDeclaration).packages/cli/src/commands/serve.tsstill contains the literal string@objectstack/organizationsat eight further sites, measured at2ba4329:--help-adjacent tier description near the bottom of the file.None of the five is under any pin.
Why it might be worth a follow-up
Two of them are instructions the operator acts on — "add
@objectstack/organizationsto THIS APP", "this app DECLARES@objectstack/organizations". If the roster key is ever renamed, those sentences keep naming the old package while boot resolves the new one, and every gate stays green: the roster pin only sees the declaration, and no test reads the message text.Why it was NOT done in #11614
Deliberate, and stated in that PR's body rather than left silent. Interpolating the constant into those strings is a provable no-op today (the declared value is byte-identical to the literal), but it is churn across a fatal-path message that an operator reads at the worst possible moment, and a whitespace slip there is a real regression in the one text that has to be right. The card's scope was the resolution path.
Shape, if someone takes it
Interpolate
Serve.ORGANIZATIONS_RUNTIME_PKGinto the five message sites and cover the rendered output with a test, so the substitution is checked rather than eyeballed. A source-scan pin asserting "no bare literal outside the declaration" is the tempting stronger form, but it would have to exclude comments, which is where that shape usually goes wrong.Refs: #11614 · PR #12149 · #10921 (why the roster exists) · #11263 (the roster's landing).