From 51c2d77c21f60a5e5db19bd5dfdd3557e133228f Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 29 Aug 2026 13:57:15 +0000 Subject: [PATCH] docs: name Studio as the authoring destination in the five remaining sites PR #100 retired the noun `Console` corpus-wide. In five places it removed a metadata-authoring destination and put nothing in its place. The 2026-08-20 ruling landed by PR #151 settled how such a site is repaired -- name Studio as the destination, never reintroduce `Console` -- and applied it to its own four sites. This transcribes the same ruling to the five it could not cover. - build/index.mdx frontmatter `description`: "by clicking through forms" -> "by clicking through forms in Studio" (119 chars, still a usable meta description; it renders in ``, `og:description` and the JSON-LD block). - build/index.mdx click-build table row: the destination goes in the audience cell, "Admins who prefer Studio's forms". This table has THREE columns (Path / Who's it for / Output) where the model row at build/data/index.mdx:21 has two, so the row is not copied literally -- copying it would corrupt the table. The path name stays bare `**Click-build**`, exactly as the model leaves it. - build/index.mdx "What you'll never have to do": "Wire a form." -> "Wire a Studio form.", the same noun restoration the ruling applied elsewhere. - automation/flows.mdx:9: "the flow builder" -> "Studio's flow builder", matching "Studio's **Access** pillar" from the ruling's own output. - automation/flows.mdx visual-builder section: an ADDITION, not a replacement. "ObjectOS ships a visual flow builder" is true as it stands -- the product does ship it -- it is merely unlocated, so the sentence is kept and "It is Studio's **Automations** pillar." follows it. The claim that flow authoring is Studio's was re-verified by content on objectui `origin/main` (107babef, not the stale 6ff0eb1 the card cites): StudioDesignSurface.tsx routes /studio/:packageId/{data|automations| interfaces}, PILLAR_FOR_SURFACE_TYPE still maps `flow` -> `automations`, and AutomationsPillar renders the flow preview with `editing: true`. Everything else PR #100 dropped is the end-user/rendering sense of the word and stays dropped. `Console` occurs zero times in both files after this change. English only; locale siblings untouched and reported stale by design. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_016TUrhcggSFrYctvp5dsV1A --- content/docs/build/automation/flows.mdx | 5 +++-- content/docs/build/index.mdx | 6 +++--- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/content/docs/build/automation/flows.mdx b/content/docs/build/automation/flows.mdx index d7d967e..3e047e5 100644 --- a/content/docs/build/automation/flows.mdx +++ b/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, the flow builder, and the [AI Builder](/docs/build/ai-builder) +audit log, Studio's flow builder, and the [AI Builder](/docs/build/ai-builder) all at once. Most customers create flows by asking the AI: @@ -278,7 +278,8 @@ auditable in the flow builder. 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. +back to the same shape as the TypeScript you'd hand-author. It is +Studio's **Automations** pillar. ## Testing flows diff --git a/content/docs/build/index.mdx b/content/docs/build/index.mdx index 5dee113..3d84c73 100644 --- a/content/docs/build/index.mdx +++ b/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 through forms, or by forking a template. +description: How apps come to life in ObjectOS — by chatting with AI, by clicking through forms in Studio, 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 | -| **Click-build** (fallback) | Admins who prefer forms | The same live metadata | +| **Click-build** (fallback) | Admins who prefer Studio's 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 @@ -49,7 +49,7 @@ 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 form. The form renders from the schema. +- Wire a Studio form. The form renders from the schema. - Write RBAC checks. Permissions are declared, not coded. - Build an admin UI. Setup and Account cover system administration and sign-in. - Generate types. `@objectstack/spec` derives them from the schema.