Merge pull request #100 from objectstack-ai/claude/issue-79-retire-console-name

docs: retire "Console" as the end-user surface name; keep Setup for administration

Author: os-zhuang

content/docs/build/agents.mdx

@@ -47,7 +47,7 @@ export const tier1Support = defineAgent({
 });
 ```
 
-Or in Console: **Console → Agents → New Agent**.
+Or in the UI: **Agents → New Agent**.
 
 Or — and this is the point — say to the AI Builder:
 
@@ -114,7 +114,7 @@ POST /api/v1/ai/chat   { context: { appName: 'crm' }, ... }
 
 When `context.appName` resolves to an app that declares a
 `defaultAgent`, the runtime auto-selects that agent — the user never
-picks from a list. Console's built-in AI panel uses this. The runtime
+picks from a list. The built-in AI panel uses this. The runtime
 resolves:
 
 1. The **default agent** for the active app (the app's `defaultAgent`),

content/docs/build/ai-builder.mdx

@@ -1,10 +1,10 @@
 ---
 title: AI Builder
-description: The in-Console chat that turns plain-language requirements into running metadata.
+description: The built-in chat that turns plain-language requirements into running metadata.
 ---
 
 The AI Builder is the **primary way customers extend ObjectOS**. Open
-Console, talk to the assistant in plain language, and it builds the
+ObjectOS, talk to the assistant in plain language, and it builds the
 metadata for you — packages, objects, fields, actions, flows. Every
 change is queued in a Human-in-the-Loop (HITL) approval list before it
 goes live.
@@ -33,7 +33,7 @@ AI:  ✓ Package created
      Done. Try it: /support_ticket
 ```
 
-You now have a working ticketing app — REST endpoints, Console views,
+You now have a working ticketing app — REST endpoints, generated views,
 audit log entries, permission checkpoints, the works. No file was
 edited; no restart happened.
 
@@ -132,11 +132,11 @@ Verified patterns, with one-liner prompts:
 | Translation | *"Translate the support_ticket labels and picklists to Spanish."* |
 
 If the AI can't do it, it says so — and points you at the manual path
-(usually a 30-line `*.ts` file or a Console form).
+(usually a 30-line `*.ts` file or a form).
 
 ## Live preview
 
-After each approved change, Console re-renders the affected views in
+After each approved change, ObjectOS re-renders the affected views in
 place. No reload needed. The runtime hot-loads the touched package's new
 metadata; subsequent requests use it.
 

content/docs/build/ai-skills.mdx

@@ -3,7 +3,7 @@ title: IDE Skills (Claude Code / Cursor / Copilot)
 description: Install ObjectOS skills into your coding agent so Claude Code, Cursor, Copilot, Codex and friends know how to author ObjectOS metadata correctly.
 ---
 
-The [AI Builder](./ai-builder) lives inside Console and talks to your
+The [AI Builder](./ai-builder) lives inside ObjectOS and talks to your
 tenant's database. But sometimes you want the same domain knowledge
 inside your IDE — when you're hand-editing `*.object.ts`, designing a
 flow, or asking Cursor to write a CEL predicate.
@@ -89,7 +89,7 @@ disappear once the skills are installed.
 
 |  | [AI Builder](./ai-builder) | IDE Skills |
 |:--|:--|:--|
-| Where it runs | Console (browser) | Your IDE / coding agent |
+| Where it runs | Your browser | Your IDE / coding agent |
 | What it changes | Live metadata in your tenant | Files in your repo |
 | Acts on behalf of | Your end users / admins | Your developers |
 | Approval model | HITL queue (`ai:approve`) | Pull request review |
@@ -108,6 +108,6 @@ helpers, and metadata vocabulary.
 
 ## Related
 
-- [AI Builder](./ai-builder) — the in-Console counterpart
+- [AI Builder](./ai-builder) — the in-browser counterpart
 - [Agents](./agents) — declare server-side agents that run *inside* ObjectOS
 - [Templates](./templates) — every official template is built with these skills loaded

content/docs/build/automation/approvals.mdx

@@ -287,7 +287,7 @@ reject, reassign, send-back for revision (`/revise`), request-info, remind,
 recall, resubmit — is declared as `type: 'api'` actions on
 `sys_approval_request`, with typed params, pending-only visibility gates, and
 submitter-vs-approver predicates (e.g. `record.submitter_id == ctx.user.id`).
-The Console approvals inbox renders those declared actions instead of
+The approvals inbox renders those declared actions instead of
 hand-written buttons, so new decision capabilities ship as metadata — no
 client release required.
 

content/docs/build/automation/flows.mdx

@@ -6,7 +6,7 @@ description: Declarative business logic — described to AI or written in TypeSc
 Flows are how you express business logic without writing a server.
 Every flow is declarative metadata that the runtime executes — same
 as objects and views. That means flows show up in `os diff`, the
-audit log, Console's flow builder, and the [AI Builder](/docs/build/ai-builder)
+audit log, the flow builder, and the [AI Builder](/docs/build/ai-builder)
 all at once.
 
 Most customers create flows by asking the AI:
@@ -33,7 +33,7 @@ export default defineStack({
 | **Autolaunched** | A record change (insert/update/delete) | "Send welcome email when user registers" |
 | **Scheduled** | Cron expression or interval | "Mark stale tasks every night at 2am" |
 | **Time-relative** *(16.0)* | A date field's proximity to today, via a daily sweep | "Remind me 60 days before the contract ends" |
-| **Manual** | User clicks a button in Console, or an API call | "Approve invoice" actions |
+| **Manual** | User clicks a button, or an API call | "Approve invoice" actions |
 
 ## Autolaunched: react to a record change
 
@@ -202,7 +202,7 @@ export const approveInvoice = defineFlow({
 });
 ```
 
-Surface it in Console as a button on the Invoice view, or call it via
+Surface it as a button on the Invoice view, or call it via
 REST:
 
 ```bash
@@ -276,7 +276,7 @@ auditable in the flow builder.
 
 ## Visual builder
 
-Console ships a visual flow builder that round-trips with the
+ObjectOS ships a visual flow builder that round-trips with the
 declarative metadata — non-engineers can edit a flow, and it serializes
 back to the same shape as the TypeScript you'd hand-author.
 

content/docs/build/data/index.mdx

@@ -4,7 +4,7 @@ description: Objects, fields, relationships, validation, indexes — described t
 ---
 
 The data model is the single source of truth for your app. Once an
-object exists, ObjectOS gives you REST APIs, a Console view, RBAC
+object exists, ObjectOS gives you REST APIs, a generated view, RBAC
 checkpoints, audit log entries, and AI tool exposure — for free.
 
 **Most customers never write the schema by hand.** They describe what
@@ -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."* |
-| **Console click-build** | Console → Objects → New Object → forms |
+| **Click-build** | **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
@@ -74,7 +74,7 @@ export default defineStack({
 ```
 
 That's all you need. `os dev` recompiles, and `/api/v1/data/todo_task`,
-the Console Task view, and the Console permission row all appear.
+the generated Task view, and its permission row all appear.
 
 ## Field types
 
@@ -167,7 +167,7 @@ ObjectSchema.create({
 });
 ```
 
-Validation runs on every write — REST, Console, ObjectQL — so there's
+Validation runs on every write — REST, the UI, ObjectQL — so there's
 no "back door."
 
 ## Indexes & performance
@@ -187,7 +187,7 @@ The driver creates real DB indexes on schema sync.
 
 ## Field groups
 
-For long forms, group fields in Console:
+For long forms, group fields:
 
 ```ts
 ObjectSchema.create({

content/docs/build/data/relationships.mdx

@@ -5,7 +5,7 @@ description: Connect objects with lookups and master-detail — cascade rules, f
 
 **A relationship is just a field.** Point a `lookup` or `masterDetail`
 field at another object and ObjectOS wires up everything on top:
-foreign-key integrity, the record picker in Console, related lists on
+foreign-key integrity, the record picker, related lists on
 the parent page, and `expand` in queries.
 
 | Type | Cardinality | Delete default | Use for |
@@ -118,7 +118,7 @@ that loops back on itself is not automatically rejected.
 
 > **Tip:** Pair a `tree` / self-lookup field with a
 > [tree list view](/docs/build/interface/views) to render the hierarchy
-> as nested rows in Console.
+> as nested rows.
 
 ## Related lists
 

content/docs/build/data/validation-rules.mdx

@@ -3,7 +3,7 @@ title: Validation Rules
 description: Required fields, unique constraints, and CEL-powered rules that stop bad data at the platform level — with error messages you control.
 ---
 
-**Validation runs on every write path.** REST, Console forms, ObjectQL
+**Validation runs on every write path.** REST, forms, ObjectQL
 — the same rules fire everywhere, so there is no back door for bad
 data. Since 16.0 that includes multi-row updates: a bulk update
 evaluates the rules once per matched row. A validation rule is a deterministic, synchronous, side-effect-free
@@ -193,7 +193,7 @@ lifecycle hook, and delete-time guards in a `beforeDelete` hook.
 ## Custom error messages
 
 The `message` is what the user sees when the rule fires — in the
-Console form and in the API error response. Make it actionable:
+form and in the API error response. Make it actionable:
 
 | Weak | Strong |
 |---|---|

content/docs/build/index.mdx

@@ -1,6 +1,6 @@
 ---
 title: Build
-description: How apps come to life in ObjectOS — by chatting with AI, by clicking in Console, or by forking a template.
+description: How apps come to life in ObjectOS — by chatting with AI, by clicking through forms, or by forking a template.
 ---
 
 In ObjectOS the customer doesn't write metadata. **They describe what
@@ -10,7 +10,7 @@ most people actually use the platform:
 | Path | Who's it for | Output |
 |---|---|---|
 | **[AI Builder](/docs/build/ai-builder)** (primary) | Business users, product owners, anyone | Live metadata in your tenant, queued for approval |
-| **Console click-build** (fallback) | Admins who prefer forms | The same live metadata |
+| **Click-build** (fallback) | Admins who prefer forms | The same live metadata |
 | **[Template fork](/docs/build/templates)** (dev path) | Engineers who want code under source control | A TypeScript package shipped via the marketplace |
 
 All three paths produce **the same artifact shape** — packages of
@@ -26,14 +26,14 @@ Every app is composed from the same primitives. Learn these once.
 | **[Package](/docs/build/packages)** | The unit of organization — `com.acme.crm`, versioned, installable | Packages |
 | **[Data model](/docs/build/data)** | Objects + fields + relationships + state machines | Data Model |
 | **[Interface](/docs/build/interface)** | Apps, views, forms, dashboards, and pages — what your users see | Interface |
-| **[Actions](/docs/build/interface/actions)** | Named operations callable from REST, Console buttons, flows, or AI agents | Actions |
+| **[Actions](/docs/build/interface/actions)** | Named operations callable from REST, buttons, flows, or AI agents | Actions |
 | **[Flows](/docs/build/automation/flows)** | Declarative business logic (autolaunched / scheduled / manual) | Flows |
 | **[Agents](/docs/build/agents)** | End-user AI assistants — Agent → Skill → Tool | Agents |
 | **[Marketplace](/docs/build/marketplace)** | Ready-made packages anyone can install in one click | Marketplace |
 
 ## Where to start
 
-1. **Just exploring?** → Open Console, start the [AI Builder](/docs/build/ai-builder),
+1. **Just exploring?** → Open ObjectOS, start the [AI Builder](/docs/build/ai-builder),
    say *"I need to track customer support tickets with priority, status, and assignee."*
    You'll have a working object in under 30 seconds.
 
@@ -49,12 +49,12 @@ Every app is composed from the same primitives. Learn these once.
 ## What you'll never have to do
 
 - Write a REST endpoint. The platform generates one per object.
-- Wire a Console form. The form renders from the schema.
+- Wire a form. The form renders from the schema.
 - Write RBAC checks. Permissions are declared, not coded.
-- Build an admin UI. Console + Account cover both system and business admin.
+- Build an admin UI. Setup and Account cover system administration and sign-in.
 - Generate types. `@objectstack/spec` derives them from the schema.
 
 ObjectOS is opinionated about this on purpose: **once metadata
-exists, every surface (REST, Console, ObjectQL, audit, AI tools)
+exists, every surface (REST, the UI, ObjectQL, audit, AI tools)
 appears for free.** That's why the AI Builder works — it only needs
 to produce metadata, and the platform handles the rest.

content/docs/build/interface/actions.mdx

@@ -1,13 +1,13 @@
 ---
 title: Actions
-description: Named operations the platform exposes as REST endpoints, Console buttons, flow steps, and AI tools — from one declaration.
+description: Named operations the platform exposes as REST endpoints, buttons, flow steps, and AI tools — from one declaration.
 ---
 
 An **Action** is a named operation on an object. Declare it once and
 it appears as:
 
 - a **REST endpoint** at `/api/v1/actions/<object>/<action>`
-- a **button** in Console's record detail
+- a **button** on the record detail page
 - a **flow step** (`type: 'action'`) for automation
 - an **AI tool** (`action_<name>`) for Agents and the AI Builder
 
@@ -58,7 +58,7 @@ export const approveInvoice = Action.create({
 After `os dev` recompiles:
 
 - `POST /api/v1/actions/invoice/approve_invoice` works
-- The Invoice record page in Console shows an **Approve Invoice** button
+- The Invoice record page shows an **Approve Invoice** button
 - A flow can include `{ type: 'action', action: 'approve_invoice', inputs: { note: '…' } }`
 - The AI assistant can call `action_approve_invoice` if its skills allow
 
@@ -109,9 +109,9 @@ either as a trailing path segment (`.../approve_invoice/:recordId`) or in
 the body. The response is your script body's return value (or the call
 result for `api`-type actions).
 
-### Console
+### From the UI
 
-By default, Console shows actions as buttons on the record detail page,
+By default, actions appear as buttons on the record detail page,
 filtered by the action's `visible` predicate. Override placement
 in your view config:
 
@@ -152,7 +152,7 @@ Actions run with the calling user's permissions. The platform checks:
    must have write access (FLS).
 3. **UI gating** — the `visible` and `disabled` predicates (CEL,
    evaluated against `record`, `os.user`, and params) control whether the
-   button renders or is greyed out in Console.
+   button renders or is greyed out.
 
 Failed permission checks return `403` with a `PERMISSION_DENIED` error.
 
@@ -192,7 +192,7 @@ This is your first stop for *"who pushed the button?"* questions.
 
 The [AI Builder](/docs/build/ai-builder) generates the action metadata and
 queues the change for approval. After approval, the action is callable from
-REST, Console, flows, and — recursively — the AI itself.
+REST, the UI, flows, and — recursively — the AI itself.
 
 ## Where to go next