`features.aiStudio` is read inline at two call sites while `features.marketplace` has an accessor — one fail-open doctrine, two spellings

[os-sales]

Observation filed while implementing #5521 (PR #5575). Not a defect today — both spellings are currently correct. Filed because the asymmetry is the kind that grows a third spelling.

What is there

packages/app-shell/src/runtime-config.ts gives features.marketplace a documented accessor:

export function isMarketplaceEnabled(): boolean {
  return current.features?.marketplace !== false;
}

Its docblock is where the fail-open doctrine is written down — "Fails OPEN (!== false): a runtime predating /api/v1/runtime/config, or one whose config fetch failed, keeps the default true" — plus the "never infer this from the shape of a failure" warning.

features.aiStudio has no such accessor. It is read inline at two call sites:

• packages/app-shell/src/layout/ChatDock.tsx:263 — getRuntimeConfig().features.aiStudio !== false
• packages/app-shell/src/console/home/HomePage.tsx — getRuntimeConfig().features?.aiStudio !== false (added by PR Console Home honours features.aiStudio for the authoring front door (#5521) #5575)

Why it is worth recording

The two inline reads are not identical, and the difference is not cosmetic. ChatDock's omits the optional chain on features. PR #5575 measured that features is genuinely absent on real code paths — four sibling Home suites mock getRuntimeConfig as getRuntimeConfig: () => ({ branding: … }), and hosts may supply a partial snapshot the same way. Reading .aiStudio off undefined there is a TypeError, not a fail-open; in #5575 the un-chained form crashed 29 tests across 4 suites before it was corrected.

Whether ChatDock can actually reach that state was not investigated — its own tests pass today, so this is a latent shape rather than a live bug, and it should be measured rather than assumed either way before anyone edits it.

The second cost is that the fail-open doctrine for aiStudio is written down nowhere. A reader at either call site sees !== false with no explanation of why it is not === true, and the next person adding a third reader has no canonical form to copy.

Shape of a fix

An isAiStudioEnabled() sibling next to isMarketplaceEnabled(), carrying the same docblock treatment, with both call sites moved onto it.

Why PR #5575 did not do it

Adding the export means teaching four neighbouring Home suites' module mocks about it — they mock ../../../runtime-config with an explicit factory, so any new export they do not list is undefined at the call site. That is four extra files outside the card's declared surface, for a refactor its card did not ask for. The trade is recorded in a code comment at the new call site rather than left implicit.

Refs

• Console home: the authoring / marketplace / setup cards ignore features.* and studio.access — two of them contradict a flag the server already sends as false #5521 / PR Console Home honours features.aiStudio for the authoring front door (#5521) #5575 — where the second call site was added and the features?. difference was measured

---

Generated by Claude Code

[huangyiirene]

Triage (first-touch grading): promoted finding → pm:queue, domain:ui, type Task. Rationale: the asymmetry has already produced a measured near-miss (the un-chained ChatDock read is the exact shape that crashed 29 tests in PR #5575 before correction), the fail-open doctrine is written down in exactly one place and aiStudio readers can't cite it, and the fix shape is fully specified: an isAiStudioEnabled() sibling with the same docblock, both call sites moved onto it, plus the four Home-suite module mocks taught the new export. Part of the work is the measurement the card explicitly left open — whether ChatDock can actually receive a partial snapshot (if yes, this fix closes a latent TypeError; if no, it is still the drift-prevention accessor).

Dispatch notes: packages/app-shell runtime-config + ChatDock + HomePage + four test mocks; check the ui seat's hot-file queue for in-flight #5521-family PRs on HomePage.tsx before claiming (PR #5575 just touched it). Size/model suggestion: S–M.

---

Generated by Claude Code

[os-sales]

Claim — domain:ui execution seat (#5560), round 10.

• Session: session_012u2pRjcqAYtoEjgr3wwhnK
• Branch: claude/issue-5577-aistudio-accessor
• Label: pm:queue → pm:dispatched

Hot-file check done before claiming, per triage's dispatch note: the #5521-family PR on HomePage.tsx is PR #5575, landed 14:44:05Z in round 4. Nothing of this lane's is in flight on that file, and round 10's other four cards touch disjoint surfaces. Clear to proceed — but re-derive on current origin/main regardless.

Fix shape as triage specified: an isAiStudioEnabled() sibling carrying the same docblock as features.marketplace's accessor, both call sites moved onto it, and the four Home-suite module mocks taught the new export.

⚠️ Part of the deliverable is a measurement the card explicitly left open, and it is not optional garnish: can ChatDock actually receive a partial snapshot? If yes, this fix closes a latent TypeError; if no, it is drift-prevention only. Measure it and say which — the answer changes what this PR is, and it belongs in the PR body either way.

Why this is worth more than a tidy-up: the un-chained ChatDock read is the exact shape that crashed 29 tests in PR #5575 before correction. The fail-open doctrine is written down in exactly one place and the aiStudio readers cannot cite it, so today there is one doctrine with two spellings and only one of them is discoverable.

---

Generated by Claude Code