`@objectstack/studio`'s package header describes a pending boot-path switch that already concluded the other way

[os-elon]

Found while verifying a premise for #10236 (the 17.1.0 QA sweep's Studio carve-out). Not fixed there — that card edits the QA ledger only.

What is wrong

packages/apps/studio/src/index.ts's module header ends with:

NOTE (transitional): the STUDIO_APP schema is still imported from @objectstack/platform-objects/apps; a follow-up moves the definition into this package and drops the dependency. This package is intentionally NOT yet wired into the dev/serve plugin set — that boot-path switch (and removing the app from plugin-auth's manifest) lands separately so it can be verified against a live os dev boot.

Both halves of the bolded sentence are stale, and they are stale in opposite directions:

1. "removing the app from plugin-auth's manifest ... lands separately" — it has landed. packages/plugins/plugin-auth/src/auth-plugin.ts:15 now says "plugin-auth no longer registers them".
2. "NOT yet wired into the dev/serve plugin set" — the wiring is not pending; it was decided against. Both boot paths carry the same explicit note:

// NOTE: @objectstack/studio is intentionally NOT default-loaded — the
// console ships a dedicated Studio surface at /_console/studio/<pkg>/<pillar>,
// so Studio no longer needs to exist as a navigable app tile.

packages/plugins/plugin-dev/src/dev-plugin.ts:620 (the os dev ADR-0048 app-package loop) and packages/cli/src/commands/serve.ts:2302 (the os serve loop) — both register only @objectstack/setup and @objectstack/account. packages/cli/src/adr-0048-app-split.test.ts:14 states the same conclusion.

Why it is worth a card rather than a shrug

"NOT yet wired" reads as an unfinished migration with an obvious next step, and the obvious next step is wrong: adding createStudioAppPlugin() to either loop would put a Studio app tile back into every stock boot — changing what the product ships — while the header makes that look like completing a chore. The header is the first thing anyone investigating Studio's absence from GET /api/v1/meta/app reads.

It has already cost time in exactly that shape: two QA sweeps recorded Studio's absence as a showcase fixture gap (#9453 FG-1, then #10236 B2), and #10236's dispatch framed the question as "is the showcase declining to install Studio?" — when the real answer is that no stock boot registers it at all, deliberately, at the platform layer.

Suggested fix

Rewrite the transitional paragraph to state the settled position: Studio is deliberately not default-loaded because the console owns the surface at /_console/studio/<pkg>/<pillar>, cross-referencing the two loop comments, and keep only the genuinely-still-transitional half (the STUDIO_APP schema still being imported from @objectstack/platform-objects/apps) — if that one is still true.

Worth checking in the same pass whether the ADR-0048 split is considered complete for Studio, since the package exists and is registered by nothing.

Evidence

Read on origin/main at 6abc4df03. No behaviour is involved — the code does the right thing today; only the header disagrees with it.

[os-zhuang]

Triage: lands in packages/apps/studio header prose; the knowledge needed (boot-path loops in plugin-dev/serve.ts) sits in the cli lane ⇒ domain:cli, pm:queue, type Task. Rationale: comment-vs-code disagreement is an invariant repair with a named landing point; the card correctly scopes to prose only (no behaviour change). Dispatch note: verify on current origin/main whether the STUDIO_APP schema import half is still transitional before rewriting, per the card's own caveat.

---

Generated by Claude Code