docs: define Studio in the glossary, make the Setup/Studio split canonical (#151)

Executes the 2026-08-20 maintainer ruling on #102 (option 1: Studio
survives as the named metadata-authoring surface).

- resources/glossary.mdx gains a `Studio` entry in alphabetical position
  that DEFINES the surface -- route, gate, what is authored there, and
  its relation to Setup -- rather than describing it. Describing without
  deciding is how this corpus grew two mutually-referential `Console`
  entries (#89), which the card forbids explicitly.
- configure/index.mdx promotes "Permissions are designed in Studio,
  assigned in Setup" from a page callout to `## Setup and Studio`: the
  canonical statement of the split, with both names' routes,
  capabilities and audiences side by side.
- The four PR #100 rewrites that dropped the noun now name Studio as the
  destination: build/data/index.mdx, build/packages.mdx,
  build/agents.mdx, configure/permissions/index.mdx.

Every product fact asserted here was measured on the sibling repos'
origin/main (objectstack 2866d5f97e, objectui 6ff0eb1), not composed:
the route (`/studio/:packageId/:tab` inside the `/_console/` SPA), the
entry gate (`studio.access`, STUDIO_ENTRY_CAPABILITY), the four pillars
(Data, Automations, Interfaces, Access) and the five metadata kinds
Studio creates (package, app, object, flow, permission).

English only; locale siblings left alone and report stale, per AGENTS.md.


Claude-Session: https://claude.ai/code/session_01V8AcCw8C1feB7b5kiaJd7b

Co-authored-by: Claude <noreply@anthropic.com>

Author: os-project-manager

content/docs/build/agents.mdx

@@ -47,7 +47,7 @@ export const tier1Support = defineAgent({
 });
 ```
 
-Or in the UI: **Agents → New Agent**.
+Or in the UI: **Studio → Agents → New Agent**.
 
 Or — and this is the point — say to the AI Builder:
 

content/docs/build/data/index.mdx

@@ -18,7 +18,7 @@ is generating and can edit it directly when you want to.
 | Path | Looks like |
 |---|---|
 | **AI Builder** (primary) | *"Create a `support_ticket` object with subject, description, priority, status, assignee."* |
-| **Click-build** | **Objects → New Object** → forms |
+| **Click-build** | **Studio → Objects → New Object** → forms |
 | **TypeScript (`*.object.ts`)** | The TS shown below — typically inside a forked [template](/docs/build/templates) |
 
 All three produce the same schema. The schema is canonical; everything

content/docs/build/packages.mdx

@@ -51,7 +51,7 @@ pnpm dev
 
 ### From the UI
 
-**Packages → New Package** — name, id, version, namespace.
+**Studio → Packages → New Package** — name, id, version, namespace.
 
 ## Active package
 

content/docs/configure/index.mdx

@@ -10,9 +10,24 @@ You manage people and their permissions day to day; the applications,
 objects, and permission sets themselves ship with the platform and the
 app packages you install.
 
-> **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.
+## Setup and Studio
+
+**Permissions are designed in Studio, assigned in Setup.** That
+sentence is the canonical statement of a split that runs through the
+whole product, not a rule about permissions alone: Setup *operates* a
+running deployment, Studio *authors* the metadata that deployment runs.
+Both live inside the same UI at `/_console/`; neither is a surface of
+its own.
+
+| | Setup | Studio |
+|---|---|---|
+| Answers | Who is here, and what may they do? | What does this app consist of? |
+| Where | `/_console/apps/setup` | `/_console/studio` |
+| Gated by | `setup.access` | `studio.access` |
+| For | System administrators | Implementers and developers |
+
+Most administration never leaves Setup — you enter Studio only to
+author permission sets or to run the explain engine.
 
 ## The Setup app
 

content/docs/configure/permissions/index.mdx

@@ -161,9 +161,9 @@ applies uniformly across REST, ObjectQL, and the UI.
 - The **explain engine** (`explain(principal, object, operation)`)
   reports the verdict of every layer in order — required permissions,
   object CRUD, field security, OWD baseline, sharing, row-level
-  security — with per-layer attribution. It surfaces as the
-  "Why can this user access?" panel. Explaining another user requires
-  the `manage_users` capability.
+  security — with per-layer attribution. Studio's **Access** pillar
+  surfaces it as the "Why can this user access?" panel. Explaining
+  another user requires the `manage_users` capability.
 - `/_console/` shows the effective permissions of any user as they're
   evaluated.
 - Audit log (`sys_audit_log`) records permission-sensitive changes —

content/docs/resources/glossary.mdx

@@ -199,6 +199,19 @@ query time, compiled into row-level filters. A rule stored **without**
 criteria shares nothing — it is not a match-all. See
 [Record Access](/docs/configure/permissions/record-access#both-switches-fail-closed).
 
+### Studio
+
+The built-in metadata-authoring surface, at `/studio` inside the UI
+served at `/_console/`, gated by the `studio.access` permission.
+Where the metadata itself is *designed* — packages, objects, apps,
+flows and permission sets — one package at a time, across four pillars:
+Data, Automations, Interfaces, Access. Peer of **Setup**, not part of
+it: Setup operates a running deployment (its people, their grants, its
+configuration), Studio authors what that deployment runs — hence
+**permissions are designed in Studio, assigned in Setup**. Unlike
+Setup it is not an app under `/apps/`; the UI serves it as its own
+route subtree. See [Administration](/docs/configure#setup-and-studio).
+
 ### Surface
 
 One of the HTTP entry points a running ObjectOS exposes: `/` (REST API)