`Studio` is a third surface name the #79 naming decision does not cover

[os-zhuang]

Found while executing #79. Filed rather than folded in: #79's decision defines exactly two outcomes and inventing a third would be the "grow a category mid-sweep" failure that card's ⛔ #5 forbids.

What is there

#79 decided: the end-user surface gets no name, the administration surface is Setup. Two outcomes. But the corpus already carries a third live surface name, and #79 says nothing about it:

• content/docs/configure/index.mdx:13 — "Permissions are designed in Studio, assigned in Setup. Most administration never leaves Setup — you enter Studio only to author permission sets or to run the explain engine."
• content/docs/configure/permissions/managing-access.mdx:124 — "Permissions are designed in Studio, assigned in Setup."
• content/docs/build/interface/apps.mdx:98 — "| Builder / admin | Setup / Studio, raw object tables | Capabilities: setup.access, studio.access, manage_metadata |"
• docs/TRANSLATION.md lists Studio in the never-translate product-noun glossary, alongside Setup.
• content/docs/reference/cli.mdx:74 documents an os studio command.

So the product has at least three named places: the unnamed end-user surface, Setup for administration, and Studio for authoring metadata. studio.access is a real capability next to setup.access, so this is not stale vocabulary the way Console was — it is a live, gated surface.

Where it bit during #79

Several Console occurrences named a metadata-authoring destination, which today's corpus places in Studio rather than Setup:

Occurrence on origin/main	What it points at
build/data/index.mdx:21 — "Console → Objects → New Object → forms"	authoring an object
build/packages.mdx:54 — "Console → Packages → New Package"	authoring a package
build/agents.mdx:50 — "Or in Console: Console → Agents → New Agent"	authoring an agent
configure/permissions/index.mdx:164 — "Console surfaces it as the 'Why can this user access?' panel"	the explain engine, which configure/index.mdx:14 places in Studio

Neither of #79's two outcomes fits: these are not the unnamed end-user surface, and calling them Setup would contradict the page that says permissions are designed in Studio. PR #100 dropped the noun in all four rather than substitute a third name — "Objects → New Object → forms", "It surfaces as the 'Why can this user access?' panel" — which is correct under the card but leaves the reader without a destination.

Why it is worth recording

The rename #79 performed was worth doing because one word addressed both a business user and an administrator. If Studio and Setup are two names for two audiences, that is the same split done right and the docs should route readers to the correct one. If Studio is itself a leftover — or if Setup and Studio are being merged — then the four occurrences above are pointing readers at a surface that will not be there.

Either way the answer is a product decision, not something a docs sweep can transcribe. Cost of leaving it: the four rewrites above tell a reader what to click without telling them where, and the next person who greps for surface names finds Setup, Studio and no rule relating them.

What settling it looks like

1. Does Studio survive as a named surface? If yes, say so where Setup is defined — resources/glossary.mdx now has a Setup entry and no Studio entry.
2. If yes, the four occurrences above should name Studio rather than drop the noun, and configure/index.mdx's "designed in Studio, assigned in Setup" line becomes the canonical statement of the split rather than an aside in one page's callout.
3. If no, configure/index.mdx:13, managing-access.mdx:124, apps.mdx:98, TRANSLATION.md and the os studio command reference all need the same treatment Retire "Console" as the name of the end-user surface; keep a name only for the admin surface (Setup) #79 gave Console.

⛔ Do not settle this by adding a Studio glossary entry that describes it without deciding 1. That is how the corpus arrived at two Console entries each "Distinct from Console" (#89).

Checked for duplicates first: no open issue in this repository mentions Studio as a naming question.

Related: #79, #89.

---

Generated by Claude Code

[os-warren]

Triage: standard facet block backfill (decision-inbox duty; the card predates the block standard on this repo). Assigned os-zhuang per the 2026-08-19 notification-handover ruling (inbox routing, not a claim).

<!-- os-decision-facets -->
① platform long-term coherence: the undecided third surface name IS the incoherence — either keep-and-define (Studio joins the glossary; "designed in Studio, assigned in Setup" becomes the canonical statement of the split) or retire it the way #79 retired Console; both are coherent, silence is not.
② measured business pull: studio.access is a live gated capability and os studio a documented CLI command; four #79-sweep rewrites currently tell readers what to click without saying where.
③ AI-agent error-resistance: a closed glossary of surface names is exactly the closed-enumeration-over-free-structure axis — every docs-writing agent needs one rule relating Setup and Studio, or the corpus regrows Console-style duplicate entries (#89).
④ startup scope discipline: the decision is one sentence; execution is either 4 line-edits + 1 glossary entry (keep) or a #79-style sweep (retire). Keep is the cheaper branch.
Recommendation: 1 = yes, Studio survives — it is anchored by a live capability key and a shipped CLI command, which docs cannot retire on their own; define it in the glossary and let the four occurrences name it.
Confidence gap: whether the product roadmap intends to merge Setup and Studio into one surface is invisible from the docs corpus — if a merge is planned, flip to the #79 treatment instead.

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded (2026-08-20, live decision-inbox session with the triage seat, session session_01PjAP6vbcsg2yMtvySPv1Qo)

Ruled: 1 — Studio survives as the named metadata-authoring surface. Provenance: maintainer accepted the batch, verbatim: 「其他接受你的建议。」The product's named places are: the unnamed end-user surface · Setup (administration) · Studio (authoring). Per the card's own settling steps: 「designed in Studio, assigned in Setup」 is promoted from a page aside to the canonical statement of the split; resources/glossary.mdx gains a Studio entry alongside Setup (defining, not merely describing — per the card's ⛔); the four PR #100 rewrites that dropped the noun now name Studio as the destination.

State transition in the same stroke: needs-user-decision → pm:queue.

---

Generated by Claude Code