From af053d9d90b13159f9a8dc36f16a752c91dc2394 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 15 Jul 2026 09:01:33 +0000 Subject: [PATCH 1/6] docs: reposition ObjectStack (open-source framework + runtime) vs ObjectOS (commercial runtime environment) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - README: ObjectStack ships its own production runtime (os start / the official Docker image ghcr.io/objectstack-ai/objectstack) — building, running, and self-hosting your own apps is fully open source. ObjectOS is the separate commercial runtime environment for end-user organizations (Cloud & Enterprise). Drop links to the community objectos repo; disambiguate the ObjectOS protocol layer from the ObjectOS product. - LICENSING: spell out that the production runtime and Docker image definition are Apache-2.0 with no dev/prod feature gate; ObjectOS editions are commercial and live outside this repo. - docs: unify the hosted-product brand 'ObjectStack Cloud' → 'ObjectOS Cloud' on current pages (historical release notes left untouched). Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_0162o68e5w3bpUBEVRQboUGG --- LICENSING.md | 16 +++++++++++++--- README.md | 16 +++++++++------- content/docs/data-modeling/drivers.mdx | 2 +- .../docs/deployment/environment-variables.mdx | 4 ++-- content/docs/deployment/index.mdx | 2 +- content/docs/deployment/single-project-mode.mdx | 2 +- content/docs/protocol/objectos/index.mdx | 2 +- content/docs/protocol/objectql/schema.mdx | 4 ++-- 8 files changed, 30 insertions(+), 18 deletions(-) diff --git a/LICENSING.md b/LICENSING.md index 03d0b825e0..fbd1d330f2 100644 --- a/LICENSING.md +++ b/LICENSING.md @@ -2,8 +2,18 @@ ObjectStack Framework is licensed under the Apache License, Version 2.0. -This repository contains the open-source framework foundation. Enterprise -editions, official cloud services, and marketplace commercial terms live -outside this repository and are governed by their own agreements. +This repository contains everything you need to **build, run, and self-host +your own applications** under that license: the protocol (`@objectstack/spec`), +kernel, SDK, CLI, production runtime (`os start`), and the official Docker +image definition ([`docker/`](./docker), published as +`ghcr.io/objectstack-ai/objectstack`). There is no feature gate between +development and production in this repository. + +**ObjectOS** — the official runtime environment for end-user organizations, +delivered as **ObjectOS Cloud** (managed) and **ObjectOS Enterprise** +(self-managed) — is a separate commercial product and is not part of this +repository. Its editions, official cloud services, and marketplace commercial +terms are governed by their own agreements. See +[docs.objectos.ai](https://docs.objectos.ai). The full Apache 2.0 license text is available in [LICENSE](./LICENSE). diff --git a/README.md b/README.md index d25ea4e3ba..59a4569ec7 100644 --- a/README.md +++ b/README.md @@ -8,11 +8,11 @@ > **A metadata protocol and TypeScript toolkit for AI-native business apps.** Describe your objects, permissions, workflows, APIs, UI, and AI tools once as typed, version-controlled Zod metadata — and ObjectStack derives the TypeScript types, REST API, client SDK, UI, and MCP tools from that single definition. ``` -ObjectStack (this repo) → how a business app is described — the protocol + toolkit -ObjectOS → where it runs, and where AI plugs in — the runtime +ObjectStack (this repo) → for builders — the open-source protocol, toolkit, and production runtime +ObjectOS → for end users — the commercial runtime environment (Cloud & Enterprise) ``` -This repo is the **framework**: the protocol, kernel, SDK, and CLI you build with. To *run* apps and let AI operate them under your permissions, deploy on **[ObjectOS](https://github.com/objectstack-ai/objectos)**. · Try a live app in ~30s on [StackBlitz](https://stackblitz.com/github/objectstack-ai/hotcrm) (no install). +This repo is the **framework**: the protocol, kernel, SDK, CLI, and production runtime you build — and ship — with. `os start` or the official Docker image [`ghcr.io/objectstack-ai/objectstack`](./docker) runs your compiled app in production, Console and governance included, entirely on open source. For a managed, organization-scale runtime environment (multi-environment control plane, provisioning, marketplace), deploy to **[ObjectOS](https://docs.objectos.ai)** — the commercial Cloud & Enterprise product. · Try a live app in ~30s on [StackBlitz](https://stackblitz.com/github/objectstack-ai/hotcrm) (no install).

ObjectStack architecture: author typed Zod metadata (objects, flows, views, policies); the microkernel compiles it into a versioned JSON artifact and loads plugins, drivers, and services; it generates a REST API, client SDK, Console and Studio UI, and MCP tools used by developers and AI agents, governed by Auth, RBAC, RLS, FLS, and audit, over PostgreSQL, MySQL, SQLite, or MongoDB @@ -21,7 +21,7 @@ This repo is the **framework**: the protocol, kernel, SDK, and CLI you build wit ## What is ObjectStack? -ObjectStack is an **open-source** metadata protocol and toolkit for *describing* business applications — so one typed definition powers your data model, API, UI, and AI tools. Apps run, and AI operates them under your permissions, on the [ObjectOS](https://github.com/objectstack-ai/objectos) runtime. +ObjectStack is an **open-source** (Apache-2.0) metadata protocol and toolkit for *describing* business applications — so one typed definition powers your data model, API, UI, and AI tools — plus the production runtime that serves them. AI operates your app under your permissions through the built-in MCP server. **[ObjectOS](https://docs.objectos.ai)** is the separate, commercial runtime environment that operates ObjectStack apps for end-user organizations (Cloud & Enterprise editions). Instead of hiding business logic inside ad-hoc SQL queries, UI state, or JavaScript strings, ObjectStack makes the business system explicit: @@ -30,7 +30,7 @@ Instead of hiding business logic inside ad-hoc SQL queries, UI state, or JavaScr - **Business logic** is represented as analyzable metadata: flows, conditions, policies, and artifacts. - **Business runtime** is a microkernel that loads plugins, drivers, services, and compiled environment artifacts. -The goal is not to be another low-code UI builder. ObjectStack is the structured *definition* layer for AI-native business software — agent-ready, versioned, and analyzable; permissions and audit are enforced at runtime by ObjectOS. +The goal is not to be another low-code UI builder. ObjectStack is the structured *definition* layer for AI-native business software — agent-ready, versioned, and analyzable; permissions and audit are enforced by the runtime. ObjectStack is built around three protocol layers: @@ -38,6 +38,8 @@ ObjectStack is built around three protocol layers: - **ObjectOS** (Control Layer) — Runtime, permissions, automation, plugins, environments, and artifact loading. - **ObjectUI** (View Layer) — Apps, views, dashboards, actions, and presentation metadata. +> Naming note: **ObjectOS** above names the control-layer *protocol*. The commercial [ObjectOS](https://docs.objectos.ai) runtime environment is the official product built on that layer. + All core definitions start with **Zod schemas** (1,600+ exported schemas across 200 schema files). TypeScript types, JSON Schemas, REST routes, UI metadata, and agent tools are derived from the same source of truth. See [ARCHITECTURE.md](./ARCHITECTURE.md) for the full microkernel and layer architecture documentation, and [content/docs/concepts/north-star.mdx](./content/docs/concepts/north-star.mdx) for the product north star (metadata protocols · environment-aware runtime · compiled app artifacts). @@ -77,7 +79,7 @@ Prefer clicking? Author the same metadata visually in **Studio** — objects, re

Model objects as typed metadata  ·  Automate with visual flows — both produce the same analyzable metadata.

-> **Want to see it running?** Deploy on **[ObjectOS](https://github.com/objectstack-ai/objectos)** for the live Console — dashboards, boards, calendars, records, and AI working your data under your permissions. +> **Want to see it running?** `os dev` serves the live Console locally, and `os start` (or the official Docker image) ships the same Console to production — dashboards, boards, calendars, records, and AI working your data under your permissions. ## Key Features @@ -105,7 +107,7 @@ The point isn't lines of code. The point is **fit in an agent's context window.* | AI maintainability | Agents must crawl sprawling app code | Whole app fits in an agent's context window | | Governance | App-level conventions | Auth, RBAC, RLS, FLS, audit, and versioned artifacts | -Described in ObjectStack and deployed on [ObjectOS](https://github.com/objectstack-ai/objectos), this is the substrate for AI-native business apps — CRM, support, operations, and workflow agents acting on real business data without bypassing permissions or audit. +Described in ObjectStack and served by its runtime, this is the substrate for AI-native business apps — CRM, support, operations, and workflow agents acting on real business data without bypassing permissions or audit. ## Quick Start diff --git a/content/docs/data-modeling/drivers.mdx b/content/docs/data-modeling/drivers.mdx index 81c1093b33..7a1e28e4b2 100644 --- a/content/docs/data-modeling/drivers.mdx +++ b/content/docs/data-modeling/drivers.mdx @@ -50,7 +50,7 @@ Drivers can be selected in two ways: Turso / libSQL (`libsql://`, `*.turso.io`) is **not** bundled with the open-core framework. The `@objectstack/driver-turso` driver ships separately in the -ObjectStack Cloud distribution, which registers it via its own stack +commercial ObjectOS distribution, which registers it via its own stack composition. The open-core runtime does not dispatch `libsql://` URLs. diff --git a/content/docs/deployment/environment-variables.mdx b/content/docs/deployment/environment-variables.mdx index 59d8f565df..a6d36dcfe5 100644 --- a/content/docs/deployment/environment-variables.mdx +++ b/content/docs/deployment/environment-variables.mdx @@ -47,7 +47,7 @@ read at startup unless noted otherwise. Boolean variables accept `true` / `false | Variable | Type | Default | Description | |:---|:---|:---|:---| -| `OS_DATABASE_URL` | url | — | Database connection string (e.g. `file:./data.sqlite`, `postgres://…`, `mongodb://…`, `memory://`). `libsql://` (Turso) is not dispatched by the open-core runtime — that driver ships separately in the ObjectStack Cloud distribution. | +| `OS_DATABASE_URL` | url | — | Database connection string (e.g. `file:./data.sqlite`, `postgres://…`, `mongodb://…`, `memory://`). `libsql://` (Turso) is not dispatched by the open-core runtime — that driver ships separately in the commercial ObjectOS distribution. | | `OS_DATABASE_DRIVER` | enum | inferred | Force a specific driver when the URL is ambiguous. `memory` \| `sqlite` \| `sqlite-wasm` \| `postgres` \| `mongodb`. | | `OS_STORAGE_ROOT` | path | `./.objectstack/data/uploads` | Root directory for the local file storage adapter, relative to the process cwd (used by `os serve`'s default `storage` capability wiring). | | `OS_ARTIFACT_PATH` | path | — | Path or `http(s)://` URL to a compiled `objectstack.json` artifact to boot the kernel from. | @@ -249,7 +249,7 @@ OS_MCP_SERVER_ENABLED=true os start # additionally auto-start the stdio tran ## Multi-tenant / Cloud control plane These variables are only meaningful when running in `OS_MODE=cloud` or against -the hosted ObjectStack Cloud control plane. +the hosted ObjectOS Cloud control plane. | Variable | Type | Default | Description | |:---|:---|:---|:---| diff --git a/content/docs/deployment/index.mdx b/content/docs/deployment/index.mdx index add495d69b..64cc9e1856 100644 --- a/content/docs/deployment/index.mdx +++ b/content/docs/deployment/index.mdx @@ -7,7 +7,7 @@ description: Choose between local standalone runtime and Cloud-managed environme This repository ships the framework runtime, examples, adapters, CLI, docs, and the published console bundle. Local development is a single-environment runtime. -Cloud deployment uses a separate ObjectStack Cloud control plane plus the +Cloud deployment uses a separate ObjectOS Cloud control plane plus the environment-aware runtime seams exported from `@objectstack/runtime`. | Mode | Runs from this repo | Environment selection | Typical use | diff --git a/content/docs/deployment/single-project-mode.mdx b/content/docs/deployment/single-project-mode.mdx index a9479c17e8..3239ea550b 100644 --- a/content/docs/deployment/single-project-mode.mdx +++ b/content/docs/deployment/single-project-mode.mdx @@ -18,7 +18,7 @@ This is the mode used by: `@objectstack/runtime` Use [Deployment Modes](/docs/deployment) when you need to publish to an -ObjectStack Cloud control plane or test environment-scoped routing. +ObjectOS Cloud control plane or test environment-scoped routing. --- diff --git a/content/docs/protocol/objectos/index.mdx b/content/docs/protocol/objectos/index.mdx index a1fda7e072..1381ad735b 100644 --- a/content/docs/protocol/objectos/index.mdx +++ b/content/docs/protocol/objectos/index.mdx @@ -126,7 +126,7 @@ Traditional enterprise platforms tightly couple infrastructure concerns with bus **ObjectOS Approach:** ```bash -# Publish a compiled artifact as a versioned package to ObjectStack Cloud +# Publish a compiled artifact as a versioned package to ObjectOS Cloud os package publish dist/objectstack.json --env --install # ✓ Validated dependencies # ✓ Applied schema changes diff --git a/content/docs/protocol/objectql/schema.mdx b/content/docs/protocol/objectql/schema.mdx index f5af9ab49e..5e06603ae4 100644 --- a/content/docs/protocol/objectql/schema.mdx +++ b/content/docs/protocol/objectql/schema.mdx @@ -663,7 +663,7 @@ Tenant A cannot see Tenant B's records. Schema changes flow through the `os` CLI: validate the config against the protocol schema, compile it to a JSON artifact, compare it against the previously deployed -config to surface breaking changes, then publish the artifact to ObjectStack Cloud. +config to surface breaking changes, then publish the artifact to ObjectOS Cloud. ```bash # 1. Validate the config against the protocol schema @@ -675,7 +675,7 @@ os build # 3. Compare two configs to detect breaking changes os diff ./before.json ./after.json -# 4. Publish the compiled artifact as a versioned package to ObjectStack Cloud +# 4. Publish the compiled artifact as a versioned package to ObjectOS Cloud os package publish # 5. Roll back / forward by installing a prior package version From dc2f3aacb85f6509b48a3c82a2831243bacbfe5e Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 15 Jul 2026 09:13:20 +0000 Subject: [PATCH 2/6] docs: strip feature-level commercial mentions from open docs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Product-level boundary statements (README/LICENSING) stay; feature-level docs now state open-source behavior only, without advertising what the commercial distribution contains: - drivers/environment-variables: 'libsql:// (Turso) is not supported' — drop the commercial-distribution packaging details. - environment-variables OS_CLUSTER_DRIVER: the claim that non-memory cluster drivers 'ship in the EE distribution' was also outdated — @objectstack/service-cluster-redis is an open, npm-published sibling package in this repo (kernel/cluster Phase 3 ✅). Point to it instead. - implementation-status: drop the internal cloud ADR citation; keep the open-boundary explanation (schemas open, BYO-AI via @objectstack/mcp). Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_0162o68e5w3bpUBEVRQboUGG --- content/docs/data-modeling/drivers.mdx | 6 ++---- content/docs/deployment/environment-variables.mdx | 4 ++-- content/docs/releases/implementation-status.mdx | 11 +++++------ 3 files changed, 9 insertions(+), 12 deletions(-) diff --git a/content/docs/data-modeling/drivers.mdx b/content/docs/data-modeling/drivers.mdx index 7a1e28e4b2..2fadf0bcf4 100644 --- a/content/docs/data-modeling/drivers.mdx +++ b/content/docs/data-modeling/drivers.mdx @@ -48,10 +48,8 @@ Drivers can be selected in two ways: | _(unset, dev mode)_ | SQLite (native, falling back to WASM, then in-memory) | `@objectstack/driver-sql` / `-sqlite-wasm` / `-memory` | -Turso / libSQL (`libsql://`, `*.turso.io`) is **not** bundled with the open-core -framework. The `@objectstack/driver-turso` driver ships separately in the -commercial ObjectOS distribution, which registers it via its own stack -composition. The open-core runtime does not dispatch `libsql://` URLs. +Turso / libSQL (`libsql://`, `*.turso.io`) is **not** supported by the +open-source framework — no bundled driver dispatches `libsql://` URLs. ## Supported Drivers diff --git a/content/docs/deployment/environment-variables.mdx b/content/docs/deployment/environment-variables.mdx index a6d36dcfe5..88d32c69e6 100644 --- a/content/docs/deployment/environment-variables.mdx +++ b/content/docs/deployment/environment-variables.mdx @@ -47,7 +47,7 @@ read at startup unless noted otherwise. Boolean variables accept `true` / `false | Variable | Type | Default | Description | |:---|:---|:---|:---| -| `OS_DATABASE_URL` | url | — | Database connection string (e.g. `file:./data.sqlite`, `postgres://…`, `mongodb://…`, `memory://`). `libsql://` (Turso) is not dispatched by the open-core runtime — that driver ships separately in the commercial ObjectOS distribution. | +| `OS_DATABASE_URL` | url | — | Database connection string (e.g. `file:./data.sqlite`, `postgres://…`, `mongodb://…`, `memory://`). `libsql://` (Turso) is not supported. | | `OS_DATABASE_DRIVER` | enum | inferred | Force a specific driver when the URL is ambiguous. `memory` \| `sqlite` \| `sqlite-wasm` \| `postgres` \| `mongodb`. | | `OS_STORAGE_ROOT` | path | `./.objectstack/data/uploads` | Root directory for the local file storage adapter, relative to the process cwd (used by `os serve`'s default `storage` capability wiring). | | `OS_ARTIFACT_PATH` | path | — | Path or `http(s)://` URL to a compiled `objectstack.json` artifact to boot the kernel from. | @@ -60,7 +60,7 @@ read at startup unless noted otherwise. Boolean variables accept `true` / `false |:---|:---|:---|:---| | `OS_SECRET_KEY` | string | — | 32-byte master key (64 hex chars or base64) for `sys_secret` encryption — encrypted settings, `secret` fields, datasource credentials. **Required** for containerized or multi-node deployments; on a single durable host `os start` mints and persists a dev key instead. See [Deployment Modes](/docs/deployment#environment-variables). | | `OS_DEV_CRYPTO_KEY` | string | — | Development convenience crypto key, consulted after `OS_SECRET_KEY`. Do not use in production. | -| `OS_CLUSTER_DRIVER` | string | `memory` | Cluster coordination driver id. When set to anything other than `memory`, the runtime treats the deployment as multi-node (and requires `OS_SECRET_KEY`). Non-memory drivers (e.g. `redis`) ship in the EE distribution. | +| `OS_CLUSTER_DRIVER` | string | `memory` | Cluster coordination driver id. When set to anything other than `memory`, the runtime treats the deployment as multi-node (and requires `OS_SECRET_KEY`). Non-memory drivers are opt-in sibling packages (e.g. `redis` via `@objectstack/service-cluster-redis`) — see [Cluster](/docs/kernel/cluster). | | `OS_REDIS_URL` | url | — | Connection URL passed to a non-memory cluster driver (e.g. `OS_CLUSTER_DRIVER=redis`). | --- diff --git a/content/docs/releases/implementation-status.mdx b/content/docs/releases/implementation-status.mdx index 522feefb42..655642d37e 100644 --- a/content/docs/releases/implementation-status.mdx +++ b/content/docs/releases/implementation-status.mdx @@ -295,12 +295,11 @@ The `auth` service in `CoreServiceName` covers both **authentication** (identity ## AI Layer -The in-UI AI **runtime** below (`@objectstack/service-ai`) moved to the **cloud / -Enterprise** distribution — see cloud ADR-0025 (`service-ai → cloud; open = -MCP-only`). The agent / skill / tool **schemas** stay open in `@objectstack/spec/ai`; -the **open edition** exposes AI via [`@objectstack/mcp`](/docs/ai) -(BYO-AI). The Implementation / Status columns describe the runtime as it ships in -cloud / EE. +The in-UI AI **runtime** below (`@objectstack/service-ai`) is not part of the +open-source framework. The agent / skill / tool **schemas** stay open in +`@objectstack/spec/ai`; the **open-source framework** exposes AI via +[`@objectstack/mcp`](/docs/ai) (BYO-AI). The Implementation / Status columns +describe that separate runtime. | Protocol | @objectstack/spec | Implementation | Status | From 60eb74943e9d910e9339a5a4ede55f9d0f56bb0a Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 15 Jul 2026 09:17:36 +0000 Subject: [PATCH 3/6] docs(ai): replace 'cloud / Enterprise' packaging talk with ObjectOS product boundary MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Same rule as the previous commit, applied to the AI docs area where the pattern was systemic (agents, index, actions-as-tools, knowledge-rag, natural-language-queries, protocol/knowledge, environment-variables): - Brand: 'cloud / Enterprise tier/distribution/runtime' → ObjectOS. - Drop links/citations to the private cloud repo's ADR-0025 (404 for the public) and @objectstack/service-ai packaging internals, including the AIServicePlugin constructor walkthrough — commercial runtime config now points to the ObjectOS docs instead. - Boundary statements themselves stay: schemas/authoring open, in-product chat runtime ships in ObjectOS, open path is @objectstack/mcp (BYO-AI). Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_0162o68e5w3bpUBEVRQboUGG --- content/docs/ai/actions-as-tools.mdx | 28 ++++++++----------- content/docs/ai/agents.mdx | 25 ++++++++--------- content/docs/ai/index.mdx | 10 +++---- content/docs/ai/knowledge-rag.mdx | 10 +++---- content/docs/ai/natural-language-queries.mdx | 14 +++++----- .../docs/deployment/environment-variables.mdx | 5 ++-- content/docs/protocol/knowledge.mdx | 5 ++-- 7 files changed, 45 insertions(+), 52 deletions(-) diff --git a/content/docs/ai/actions-as-tools.mdx b/content/docs/ai/actions-as-tools.mdx index e063218645..7e5135aee0 100644 --- a/content/docs/ai/actions-as-tools.mdx +++ b/content/docs/ai/actions-as-tools.mdx @@ -16,11 +16,10 @@ client, or a local model) connects over the Model Context Protocol, and the server exposes two business-action tools — `list_actions` and `run_action` — bound to the caller's principal. The agent operates the app the same way the Console toolbar does, under the same row-level security and permissions. No -cloud service and no `@objectstack/service-ai` are required. +cloud service and no ObjectOS runtime are required. -**Cloud / Enterprise** layers an in-product chat *runtime* -(`@objectstack/service-ai`, cloud [ADR-0025](https://github.com/objectstack-ai/cloud/blob/main/docs/adr/0025-service-ai-to-cloud-open-mcp-only.md)) +**ObjectOS** layers an in-product chat *runtime* on top of these same actions: it generates one `action_` tool per action, gates them behind an `ai.exposed` opt-in, and adds a server-side approval queue. Those pieces are called out below. The open path — the same Action reachable as @@ -70,8 +69,8 @@ export const triageCaseAction = { ``` -**Cloud / Enterprise** — the `ai.exposed` flag is a governance gate for the -in-product chat *runtime*: the cloud `@objectstack/service-ai` bridge registers +**ObjectOS** — the `ai.exposed` flag is a governance gate for the +in-product chat *runtime*: the ObjectOS bridge registers an `action_` tool **only** when `ai.exposed === true` (and then `ai.description` is required, ≥ 40 chars). The open MCP path does **not** use `ai.exposed` — it filters by permission, returning every action the caller is @@ -86,9 +85,9 @@ System objects (`sys_*`) are held back fail-closed. | `action.type` | Dispatch path | Available where | |:---|:---|:---| -| `script` | `IDataEngine.executeAction(object, target, ctx)` — the same call Studio makes | open (MCP) + cloud | -| `flow` | automation flow runner — `execute(target, { triggerData })` | open (MCP) + cloud; needs the `automation` service registered | -| `api` | HTTP call to `action.target` via a configured `apiClient` | **cloud / Enterprise** runtime only | +| `script` | `IDataEngine.executeAction(object, target, ctx)` — the same call Studio makes | open (MCP) + ObjectOS | +| `flow` | automation flow runner — `execute(target, { triggerData })` | open (MCP) + ObjectOS; needs the `automation` service registered | +| `api` | HTTP call to `action.target` via a configured `apiClient` | **ObjectOS** runtime only | Console-only types (`url`, `modal`, `form`) are always skipped. @@ -120,14 +119,11 @@ is registered. Point your MCP client at the server; the caller's API key acts as the user, so every `run_action` runs under that principal's RLS. -**Cloud / Enterprise** — the in-product runtime wires actions through -`@objectstack/service-ai` instead, e.g. -`new AIServicePlugin({ apiActionBaseUrl, apiActionHeaders })`. `apiActionBaseUrl` -enables `type:'api'` dispatch (relative `/api/v1/...` targets resolve against it) -and `apiActionHeaders` are forwarded on every api-action call. The plugin's -`registerActionsAsTools()` returns `{ registered, skipped, warnings }` with -reasons like `"not AI-exposed"` or `"requires confirmation … wire HITL approval"` -so authors can see whether an action is LLM-callable. +**ObjectOS** — the in-product runtime wires actions through its own bridge +(including `type:'api'` dispatch), and reports per-action registration results +with reasons like `"not AI-exposed"` or `"requires confirmation … wire HITL +approval"` so authors can see whether an action is LLM-callable. See the +[ObjectOS docs](https://docs.objectos.app/docs/ai) for its configuration. ### Example diff --git a/content/docs/ai/agents.mdx b/content/docs/ai/agents.mdx index 2ac6e331f0..94c082e2e2 100644 --- a/content/docs/ai/agents.mdx +++ b/content/docs/ai/agents.mdx @@ -17,25 +17,24 @@ Claude Code authors them from the `objectstack-ai` [skill](/docs/ai/skills); you ([the loop](/docs/getting-started/build-with-claude-code)). -**Cloud / Enterprise — the in-product chat runtime.** The authoring format on +**ObjectOS — the in-product chat runtime.** The authoring format on this page is open. The *in-product chat runtime* that runs agents for end users — the two platform agents `ask` and `build`, all in-product chat, and the -`/api/v1/ai/*` chat endpoints — ships only in the cloud / Enterprise distribution -(`@objectstack/service-ai`, cloud ADR-0025). The open edition uses -`@objectstack/mcp` (BYO-AI) instead. The next two sections describe that cloud / -Enterprise runtime. +`/api/v1/ai/*` chat endpoints — ships in **ObjectOS**, not in the open-source +framework, which uses `@objectstack/mcp` (BYO-AI) instead. The next two sections +describe that ObjectOS runtime. Per [ADR-0063](https://github.com/objectstack-ai/framework/blob/main/docs/adr/0063-two-kernel-agents-skills-are-the-extension-primitive.md) -the cloud / Enterprise runtime ships **exactly two** platform agents, bound by the +the ObjectOS runtime ships **exactly two** platform agents, bound by the *surface* the user is in — the user never picks from a roster: | Agent | Surface | Does | Edition | |---|---|---|---| -| **`ask`** | data console | Read / query / explore records + run the business **actions** the app exposes. RLS-bounded. | cloud · Enterprise | -| **`build`** | Studio | Author *metadata* (objects, fields, views, flows) via plan → draft → verify → publish. | cloud · Enterprise | +| **`ask`** | data console | Read / query / explore records + run the business **actions** the app exposes. RLS-bounded. | ObjectOS | +| **`build`** | Studio | Author *metadata* (objects, fields, views, flows) via plan → draft → verify → publish. | ObjectOS | -Within this cloud / Enterprise runtime there is no per-turn intent classifier and +Within the ObjectOS runtime there is no per-turn intent classifier and no agent dropdown: the surface binds the agent (data console → `ask`, Studio → `build`). A `build`-shaped request that reaches `ask` is declined and redirected to the Builder, never silently re-routed. (For data query and source-mode authoring, @@ -108,8 +107,8 @@ surface-compatible skills' tools** — there is no global fall-through, so a ski reaches an agent only when their surfaces match ([ADR-0064](https://github.com/objectstack-ai/framework/blob/main/docs/adr/0064-tool-scoping-to-agent.md)). Both `surface:'ask'` and `surface:'build'` skills run only where the in-UI AI -runtime exists — the **cloud / Enterprise** distribution. On the open framework -there is no in-product agent to attach them to (cloud ADR-0025); author capability +runtime exists — **ObjectOS**. On the open framework +there is no in-product agent to attach them to; author capability as Actions / Flows and reach it through `@objectstack/mcp` instead. ## The shape of an agent @@ -131,8 +130,8 @@ own `ask` / `build` records use exactly these fields): There is no `type` field and no fixed agent "type" taxonomy — behaviour comes from persona, instructions, skills, and tools. There are no `triggers` / `schedule` fields on an agent; drive agents from [Flows/Workflows](/docs/automation), or — on -the **cloud / Enterprise** runtime — via the in-product chat endpoint -(`/api/v1/ai/*`). In the open edition, invoke the underlying Actions/Flows through +the **ObjectOS** runtime — via the in-product chat endpoint +(`/api/v1/ai/*`). On the open-source framework, invoke the underlying Actions/Flows through `@objectstack/mcp`. diff --git a/content/docs/ai/index.mdx b/content/docs/ai/index.mdx index a6b3c3de17..dbaba14c81 100644 --- a/content/docs/ai/index.mdx +++ b/content/docs/ai/index.mdx @@ -14,13 +14,13 @@ AI in ObjectStack is a **cross-protocol capability layer**: agents, tools, and k -**The open framework does AI bring-your-own-AI** — your keys, your models, zero platform AI cost. Everything on this page is part of the open edition unless a section is explicitly marked **cloud / Enterprise**: +**The open framework does AI bring-your-own-AI** — your keys, your models, zero platform AI cost. Everything on this page is part of the open-source framework unless a section is explicitly marked **ObjectOS**: - **Data & actions → `@objectstack/mcp`** (BYO-AI). Point your own AI — Claude, Cursor, any MCP client, or a local model — at the app's objects, queries, and business **actions**, governed by the same RLS. With a local model, data *and* inference stay inside your boundary. - **Knowledge & RAG → the Knowledge Protocol + adapter plugins** (`knowledge-memory`, `knowledge-ragflow`, `embedder-openai`) — permission-aware retrieval over your own objects. - **Agents, tools, skills → typed metadata** (`defineAgent` / `defineTool` / `defineSkill`) plus the Model Registry. Author them as source (`*.agent.ts`, `*.tool.ts`, …) with your own AI coding agent (Claude Code, Cursor), aided by the ObjectStack [skills](/docs/ai/skills-reference) and MCP introspection. -The **cloud / Enterprise** tier adds an in-product chat *runtime* on top of these same primitives — the `ask` data-query assistant, the `build` Studio authoring assistant, and the `/api/v1/ai/*` chat endpoints (`@objectstack/service-ai`, cloud [ADR-0025](https://github.com/objectstack-ai/cloud/blob/main/docs/adr/0025-service-ai-to-cloud-open-mcp-only.md)). The open edition has no built-in in-product chat — that runtime is documented in the [cloud AI & Agents docs](https://docs.objectos.app/docs/ai). +**ObjectOS** adds an in-product chat *runtime* on top of these same primitives — the `ask` data-query assistant, the `build` Studio authoring assistant, and the `/api/v1/ai/*` chat endpoints. The open-source framework has no built-in in-product chat — that runtime is documented in the [ObjectOS AI & Agents docs](https://docs.objectos.app/docs/ai). ## What's in this module @@ -138,10 +138,10 @@ those same tools over MCP (`@objectstack/mcp`), and you drive them on a trigger or schedule from a [Flow or Workflow](/docs/automation). -**Cloud / Enterprise runtime.** The in-product chat invocation shown below — the +**ObjectOS runtime.** The in-product chat invocation shown below — the REST chat endpoint (`/api/v1/ai/agents/:agentName/chat`) and the server-side -`aiService.chatWithTools(...)` — is the `@objectstack/service-ai` chat runtime, -which ships in the **cloud / Enterprise** tier. The agent, tool, and skill +`aiService.chatWithTools(...)` — is the in-product chat runtime, +which ships in **ObjectOS**. The agent, tool, and skill *metadata* it consumes is open; only this in-product chat runtime is not. diff --git a/content/docs/ai/knowledge-rag.mdx b/content/docs/ai/knowledge-rag.mdx index 4617cdb546..d8946214ae 100644 --- a/content/docs/ai/knowledge-rag.mdx +++ b/content/docs/ai/knowledge-rag.mdx @@ -10,7 +10,7 @@ Part of the [AI module](/docs/ai) — how agents retrieve knowledge through the ObjectStack ships a Knowledge Protocol that lets you retrieve from pluggable backends (RAGFlow, LlamaIndex, Dify, custom pgvector, …) with one call: `KnowledgeService.search(query, { sourceIds?, topK? })`. The framework defines the contract and runs permission-aware filtering; the adapter plugin does the actual retrieval. See [the protocol design](/docs/protocol/knowledge) for the rationale. -**This whole stack is open.** The `@objectstack/service-knowledge` service, the adapter plugins (`@objectstack/knowledge-memory`, `@objectstack/knowledge-ragflow`), the `@objectstack/embedder-openai` embedder, and the permission-aware retrieval + event sync below all ship in the **open edition**. The workflow is: declare your knowledge sources, pick an adapter, and call `search` — retrieval respects the same row-level security as any ObjectQL query. Only the in-product chat *runtime* that consumes retrieval (`@objectstack/service-ai`) is cloud / Enterprise; see the callout under [Retrieving knowledge](#retrieving-knowledge). +**This whole stack is open.** The `@objectstack/service-knowledge` service, the adapter plugins (`@objectstack/knowledge-memory`, `@objectstack/knowledge-ragflow`), the `@objectstack/embedder-openai` embedder, and the permission-aware retrieval + event sync below all ship in the **open-source framework**. The workflow is: declare your knowledge sources, pick an adapter, and call `search` — retrieval respects the same row-level security as any ObjectQL query. Only the in-product chat *runtime* that consumes retrieval ships in ObjectOS; see the callout under [Retrieving knowledge](#retrieving-knowledge). ## Wiring @@ -63,11 +63,11 @@ const hits = await knowledge.search('proposals about ACME', { ``` -**In-product chat is cloud / Enterprise.** Exposing this retrieval to a chat UI as +**In-product chat ships in ObjectOS.** Exposing this retrieval to a chat UI as the `search_knowledge` tool — the `ask` / `build` personas, the `/api/v1/ai/*` -endpoints, and `aiService.chatWithTools` — is provided by `@objectstack/service-ai`, -which ships only in the **cloud / Enterprise** tier (cloud [ADR-0025](https://github.com/objectstack-ai/cloud/blob/main/docs/adr/0025-service-ai-to-cloud-open-mcp-only.md)). The -open edition has no built-in in-product chat, but everything else here — the Knowledge +endpoints, and `aiService.chatWithTools` — is provided by the **ObjectOS** +in-product runtime. The +open-source framework has no built-in in-product chat, but everything else here — the Knowledge Protocol, adapters, embedder, and `KnowledgeService.search` — is open, so you can call `search` directly from your own code, agent, or MCP tool. diff --git a/content/docs/ai/natural-language-queries.mdx b/content/docs/ai/natural-language-queries.mdx index b8ebc30e6f..970e79607e 100644 --- a/content/docs/ai/natural-language-queries.mdx +++ b/content/docs/ai/natural-language-queries.mdx @@ -11,8 +11,8 @@ Natural-language querying is **open**. Point your own AI — Claude, Cursor, any MCP client, or a local model — at your app through `@objectstack/mcp`, and it turns questions into ObjectQL against your objects, governed by the same row-level security as the REST API. The data tools and the ObjectQL engine that -back this are part of the open framework — no `@objectstack/service-ai` and no -cloud studio are required. +back this are part of the open framework — no ObjectOS runtime and no +cloud Studio are required. Your AI queries your data through the open MCP **data tools** — `query_records` (filter, field selection, sort, pagination) and `get_record`, plus the @@ -52,13 +52,13 @@ model is prompted with the available objects and translates the user's question into `query_records` calls at runtime. -**Cloud / Enterprise — bundled in-product chat.** The cloud tier ships an in-UI -AI runtime (`@objectstack/service-ai`, closed) — the `ask` data-query assistant +**ObjectOS — bundled in-product chat.** ObjectOS ships an in-UI +AI runtime — the `ask` data-query assistant and the `/api/v1/ai/*` chat endpoints — that registers these same data tools, plus the group-by/roll-up `aggregate_data` tool, into its own chat loop. That -package is not part of the open framework and is documented separately in the -[cloud docs](https://docs.objectos.app/docs/ai); this page covers the open path -only. On the open edition, use +runtime is not part of the open framework and is documented separately in the +[ObjectOS docs](https://docs.objectos.app/docs/ai); this page covers the open path +only. On the open-source framework, use `@objectstack/mcp` above to get the same natural-language querying with your own AI. diff --git a/content/docs/deployment/environment-variables.mdx b/content/docs/deployment/environment-variables.mdx index 88d32c69e6..0cfb2d3131 100644 --- a/content/docs/deployment/environment-variables.mdx +++ b/content/docs/deployment/environment-variables.mdx @@ -137,9 +137,8 @@ Auth settings precedence: ## AI -These variables configure the **cloud / Enterprise** in-UI AI runtime -(`@objectstack/service-ai`), which moved out of the open framework — see cloud -ADR-0025 (`service-ai → cloud; open = MCP-only`). The **open edition** has no +These variables configure the **ObjectOS** in-product AI runtime, which is not +part of the open-source framework. The **open-source framework** has no in-UI AI runtime to configure: it exposes AI through `@objectstack/mcp` (BYO-AI), where the model and provider are configured in your own MCP client (Claude, Cursor, a local model, …). See the [AI Capabilities guide](/docs/ai). diff --git a/content/docs/protocol/knowledge.mdx b/content/docs/protocol/knowledge.mdx index bd6923f7a1..23b03c7e45 100644 --- a/content/docs/protocol/knowledge.mdx +++ b/content/docs/protocol/knowledge.mdx @@ -20,9 +20,8 @@ service that orchestrates them — and ships individual adapters as The Knowledge Protocol contract and the `service-knowledge` orchestrator are open framework mechanisms. The AI **consumer** that wires the `search_knowledge` tool -into an in-product chat loop (`@objectstack/service-ai`, shown below) ships in the -**cloud / Enterprise** distribution — see cloud ADR-0025 (`service-ai → cloud; -open = MCP-only`). On the open edition, reach your data through `@objectstack/mcp` +into an in-product chat loop (shown below) ships in +**ObjectOS**. On the open-source framework, reach your data through `@objectstack/mcp` (BYO-AI) instead. From 71b20992e53970aadb638ff1f54d3ac797543b51 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 15 Jul 2026 09:19:42 +0000 Subject: [PATCH 4/6] docs: finish sweeping commercial packaging mentions from open docs Remaining 'Cloud / Enterprise' callouts and @objectstack/service-ai internals (approval-queue plugin config, chat-route internals, the implementation-status AI matrix listing closed-source file names, the knowledge-protocol diagram box) now state the ObjectOS product boundary only, pointing to the ObjectOS docs for its configuration. Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_0162o68e5w3bpUBEVRQboUGG --- content/docs/ai/actions-as-tools.mdx | 22 ++++++++--------- .../docs/deployment/environment-variables.mdx | 2 +- content/docs/protocol/knowledge.mdx | 6 ++--- .../docs/releases/implementation-status.mdx | 24 +++++++++---------- 4 files changed, 26 insertions(+), 28 deletions(-) diff --git a/content/docs/ai/actions-as-tools.mdx b/content/docs/ai/actions-as-tools.mdx index 7e5135aee0..2b75dc0b0b 100644 --- a/content/docs/ai/actions-as-tools.mdx +++ b/content/docs/ai/actions-as-tools.mdx @@ -151,19 +151,17 @@ operator to approve the call before it runs. The human stays in the loop at the point of invocation, and the action still executes under the caller's RLS. -**Cloud / Enterprise** — the in-product chat runtime adds a *server-side* -approval queue for its own `action_` tools. Enable it with -`new AIServicePlugin({ enableActionApproval: true })`: a gated tool call persists -an `ai_pending_actions` row (`status: 'pending'`) and returns -`{ status: 'pending_approval', pendingActionId }` to the model instead of -executing. An operator resolves it from the **AI Pending Actions** Studio inbox — -`POST /api/v1/ai/pending-actions/:id/approve` (`ai:approve` permission) re-runs -the same dispatcher, or `.../reject` with a reason. The queue is also available -programmatically via -`IAIService.{proposePendingAction, approvePendingAction, rejectPendingAction, listPendingActions}`. +**ObjectOS** — the in-product chat runtime adds a *server-side* +approval queue for its own `action_` tools: a gated tool call is +persisted as pending and returned to the model as +`{ status: 'pending_approval', … }` instead of executing, and an operator +resolves it from the **AI Pending Actions** Studio inbox (approve re-runs the +same dispatcher; reject records a reason). A dedicated queue (rather than the multi-step `IApprovalService`) fits AI tool-call HITL: the subject is the proposed *call*, there is no predefined -process, and operators expect single-click yes/no. +process, and operators expect single-click yes/no. See the +[ObjectOS docs](https://docs.objectos.app/docs/ai) for configuration and the +queue API. ## Permission-aware execution (RLS for agents) @@ -189,7 +187,7 @@ On the open MCP path this is automatic: "AI Assistant" principal. -**Cloud / Enterprise** — the in-product chat routes +**ObjectOS** — the in-product chat routes (`/api/v1/ai/assistant/chat`, `/api/v1/ai/agents/:agentName/chat`) resolve the authenticated principal from `req.user` — both cookie session (`better-auth.session_token`) and Bearer token are handled — and forward it to diff --git a/content/docs/deployment/environment-variables.mdx b/content/docs/deployment/environment-variables.mdx index 0cfb2d3131..a60f263e25 100644 --- a/content/docs/deployment/environment-variables.mdx +++ b/content/docs/deployment/environment-variables.mdx @@ -175,7 +175,7 @@ The boot-time LLM adapter priority is: 5. `GOOGLE_GENERATIVE_AI_API_KEY` using `@ai-sdk/google`. 6. `MemoryLLMAdapter` echo mode when no real provider is configured. -After boot, if the Settings service is mounted, `@objectstack/service-ai` +After boot, if the Settings service is mounted, the ObjectOS AI runtime reads the `ai` Settings namespace and swaps the adapter when the provider comes from env or a stored Settings UI value. The manifest default `provider=memory` is ignored so it does not mask boot-time auto-detection; diff --git a/content/docs/protocol/knowledge.mdx b/content/docs/protocol/knowledge.mdx index 23b03c7e45..66e67c83ad 100644 --- a/content/docs/protocol/knowledge.mdx +++ b/content/docs/protocol/knowledge.mdx @@ -89,7 +89,7 @@ delegates the rest to plugins. │ consumes │ ┌─────────────┴────────────────────────┐ -│ @objectstack/service-ai │ +│ ObjectOS in-product AI runtime │ │ │ │ • search_knowledge tool │ │ • Threads ToolExecutionContext │ @@ -99,7 +99,7 @@ delegates the rest to plugins. Every box above is independently versioned. **Adding a new backend is one plugin package — zero changes to `spec`, `service-knowledge`, or -`service-ai`.** +any AI consumer.** --- @@ -142,7 +142,7 @@ caller's `ExecutionContext` and drops hits the user is not allowed to read. **A hit that the user could not have queried directly is never returned.** -### 3.3 `IKnowledgeService` (consumed by `service-ai`, REST, Console) +### 3.3 `IKnowledgeService` (consumed by the ObjectOS AI runtime, REST, Console) ```ts interface IKnowledgeService { diff --git a/content/docs/releases/implementation-status.mdx b/content/docs/releases/implementation-status.mdx index 655642d37e..4a3441f393 100644 --- a/content/docs/releases/implementation-status.mdx +++ b/content/docs/releases/implementation-status.mdx @@ -295,7 +295,7 @@ The `auth` service in `CoreServiceName` covers both **authentication** (identity ## AI Layer -The in-UI AI **runtime** below (`@objectstack/service-ai`) is not part of the +The in-UI AI **runtime** below ships in **ObjectOS**, not in the open-source framework. The agent / skill / tool **schemas** stay open in `@objectstack/spec/ai`; the **open-source framework** exposes AI via [`@objectstack/mcp`](/docs/ai) (BYO-AI). The Implementation / Status columns @@ -304,22 +304,22 @@ describe that separate runtime. | Protocol | @objectstack/spec | Implementation | Status | |:---------|:-----------------:|:-------------:|:------:| -| **Agent** | ✅ | @objectstack/service-ai | ✅ Agent runtime (`agent-runtime.ts`, `agents/`) | -| **Model Registry** | ✅ | @objectstack/service-ai | ✅ `model-registry.ts` | +| **Agent** | ✅ | ObjectOS runtime | ✅ Agent runtime | +| **Model Registry** | ✅ | ObjectOS runtime | ✅ Model registry | | **RAG Pipeline** | ✅ | @objectstack/service-knowledge | ⚠️ Knowledge service + `knowledge-memory` / `knowledge-ragflow` / `embedder-openai` plugins | -| **NLQ** | ✅ | @objectstack/service-ai | ⚠️ `tools/query-data`, `schema-retriever.ts` | -| **Conversation** | ✅ | @objectstack/service-ai | ✅ In-memory + ObjectQL conversation services (`conversation/`) | -| **Agent Action** | ✅ | @objectstack/service-ai | ⚠️ Action/data/knowledge tools (`tools/`) | +| **NLQ** | ✅ | ObjectOS runtime | ⚠️ Data-query tools | +| **Conversation** | ✅ | ObjectOS runtime | ✅ In-memory + ObjectQL conversation services | +| **Agent Action** | ✅ | ObjectOS runtime | ⚠️ Action/data/knowledge tools | | **Cost** | ✅ | ❌ | ❌ Spec only | | **Predictive** | ✅ | ❌ | ❌ Spec only | -| **Orchestration** | ✅ | @objectstack/service-ai | ⚠️ Agent tool orchestration | -| **Feedback Loop** | ✅ | @objectstack/service-ai | ⚠️ Eval harness (`eval/`) | +| **Orchestration** | ✅ | ObjectOS runtime | ⚠️ Agent tool orchestration | +| **Feedback Loop** | ✅ | ObjectOS runtime | ⚠️ Eval harness | | **DevOps Agent** | ✅ | ❌ | ❌ Spec only | **Notes:** - Complete AI protocol suite defined -- `@objectstack/service-ai` ships agents, model registry, conversation, tools, skills, and an eval harness -- RAG/embedding is provided by `@objectstack/service-knowledge` plus the `knowledge-memory`, `knowledge-ragflow`, and `embedder-openai` plugins +- The ObjectOS runtime ships agents, model registry, conversation, tools, skills, and an eval harness +- RAG/embedding is provided by `@objectstack/service-knowledge` plus the `knowledge-memory`, `knowledge-ragflow`, and `embedder-openai` plugins (all open) - Cost tracking, predictive, and the DevOps agent protocols remain spec-only --- @@ -453,7 +453,7 @@ describe that separate runtime. | **System** | 39 | Logging, audit, job, translation, metrics, notification implemented; several governance services pending | | **Auth** (plugin) | 10 | Permission + RLS live (`plugin-security`); identity/sharing/territory still plugin-pending | | **Automation** (plugin) | 7 | Flow, workflow, approval, webhook, and triggers implemented; ETL/Sync pending | -| **AI** | 12 | Agents, model registry, conversation, tools, RAG implemented (`service-ai` + knowledge plugins); cost/predictive/DevOps-agent pending | +| **AI** | 12 | Agents, model registry, conversation, tools, RAG implemented (ObjectOS runtime + open knowledge plugins); cost/predictive/DevOps-agent pending | | **Integration** | 7 | REST/OpenAPI/MCP/Slack connectors, file storage, and queue implemented; GitHub/Vercel connectors pending | | **QA** | 1 | Fully implemented | @@ -476,7 +476,7 @@ Implementation spans every layer of the platform. Core infrastructure, data mode | **UI Rendering** | ❌ | No | | **Workflows** | ✅ | Yes (plugin: `service-automation`) | | **Security** | ⚠️ | Partial (Phase-1 RBAC/RLS via `plugin-security`) | -| **AI Features** | ⚠️ | Partial (`service-ai` + knowledge plugins) | +| **AI Features** | ⚠️ | Partial (ObjectOS runtime + open knowledge plugins) | --- From dab0cded9cbe66b19dde6f20a0f01492dc9dcc9c Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 15 Jul 2026 09:38:29 +0000 Subject: [PATCH 5/6] =?UTF-8?q?docs:=20retire=20'ObjectOS'=20as=20the=20co?= =?UTF-8?q?ntrol-layer=20name=20=E2=80=94=20the=20layer=20is=20now=20'Kern?= =?UTF-8?q?el'?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ObjectOS now exclusively names the commercial runtime environment, so using it as the open spec's control-layer brand was a permanent naming collision (papered over by a disambiguation note until now). - Layer naming: ObjectQL (data) / Kernel (control) / ObjectUI (view). ObjectQL and ObjectUI stay — they name real open technologies; only the layer-brand use of ObjectOS is retired. - README: layer list + layers alt-text; drop the now-unneeded naming note. ARCHITECTURE.md: layer diagram/table. - concepts/architecture.mdx, protocol/index card, protocol/diagram, glossary (with an explicit migration note), implementation-status, permissions/automation/plugins/getting-started prose: layer actor renamed to Kernel / ObjectStack runtime as fits. - protocol/objectos/ pages: landing page retitled 'Kernel: The System Protocol'; behavior narratives now use ObjectStack as the actor. Directory/URL rename to protocol/kernel deferred (needs redirects). - skills/objectstack-platform + spec prompts aligned. Follow-ups (not in this PR): regenerate docs/screenshots/layers.png; sweep the ~43 ObjectOS mentions in packages/spec source TSDoc/strings (feeds the auto-generated references/ docs); move content/docs/protocol/objectos/ → protocol/kernel/ with redirects. Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_0162o68e5w3bpUBEVRQboUGG --- ARCHITECTURE.md | 8 +- README.md | 10 +-- content/docs/automation/index.mdx | 2 +- content/docs/concepts/architecture.mdx | 40 +++++----- content/docs/concepts/metadata-driven.mdx | 2 +- content/docs/getting-started/glossary.mdx | 8 +- content/docs/getting-started/index.mdx | 2 +- content/docs/index.mdx | 4 +- content/docs/permissions/index.mdx | 4 +- content/docs/plugins/packages.mdx | 2 +- content/docs/protocol/diagram.mdx | 4 +- content/docs/protocol/index.mdx | 2 +- .../protocol/objectos/config-resolution.mdx | 24 +++--- .../docs/protocol/objectos/i18n-standard.mdx | 16 ++-- content/docs/protocol/objectos/index.mdx | 74 +++++++++---------- content/docs/protocol/objectos/lifecycle.mdx | 22 +++--- .../protocol/objectos/metadata-service.mdx | 14 ++-- .../docs/protocol/objectos/plugin-spec.mdx | 16 ++-- .../objectos/runtime-capabilities.mdx | 12 +-- .../docs/releases/implementation-status.mdx | 6 +- packages/spec/prompts/architecture.md | 2 +- packages/spec/prompts/implement-objectos.md | 2 +- packages/spec/prompts/instructions.md | 4 +- skills/objectstack-platform/SKILL.md | 8 +- 24 files changed, 143 insertions(+), 145 deletions(-) diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md index 253a631aa6..abe10cebd1 100644 --- a/ARCHITECTURE.md +++ b/ARCHITECTURE.md @@ -121,7 +121,7 @@ ObjectStack is organized as a **monorepo** with distinct package layers: **Location**: `packages/spec/` **Role**: Protocol Definitions (The "Constitution") -- Zod schemas for all protocols (ObjectQL, ObjectOS, ObjectUI) +- Zod schemas for all protocols (ObjectQL, Kernel/System, ObjectUI) - TypeScript type definitions - JSON Schema generation - Constants and enums @@ -131,7 +131,7 @@ ObjectStack is organized as a **monorepo** with distinct package layers: // packages/spec/src/ ├── data/ # ObjectQL schemas (Object, Field, Query, etc.) ├── ui/ # ObjectUI schemas (App, View, Dashboard, etc.) -├── system/ # ObjectOS schemas (Manifest, Driver, Plugin, etc.) +├── system/ # System schemas (Manifest, Driver, Plugin, etc.) ├── automation/ # Workflow, Flow, Trigger schemas ├── ai/ # Agent, RAG, Model schemas ├── api/ # API contract schemas @@ -306,7 +306,7 @@ ObjectStack follows a **Three-Layer Protocol Stack**: └────────────────┬─────────────────────────────────┘ │ REST API / GraphQL ┌────────────────▼─────────────────────────────────┐ -│ Layer 2: ObjectOS (Control) │ +│ Layer 2: Kernel (Control) │ │ ┌────────────────────────────────────────────┐ │ │ │ Auth, Permissions, Workflows, Events │ │ │ │ "Who can do what, when?" │ │ @@ -338,7 +338,7 @@ Foundation: | Layer | Knows About | Doesn't Know About | |-------|-------------|-------------------| | **ObjectQL** | Schema, fields, queries, drivers | Users, permissions, UI | -| **ObjectOS** | Auth, workflows, events | Data structure, UI layout | +| **Kernel** | Auth, workflows, events | Data structure, UI layout | | **ObjectUI** | Layout, navigation, actions | Business logic, storage | --- diff --git a/README.md b/README.md index 59a4569ec7..8f781e0461 100644 --- a/README.md +++ b/README.md @@ -32,14 +32,12 @@ Instead of hiding business logic inside ad-hoc SQL queries, UI state, or JavaScr The goal is not to be another low-code UI builder. ObjectStack is the structured *definition* layer for AI-native business software — agent-ready, versioned, and analyzable; permissions and audit are enforced by the runtime. -ObjectStack is built around three protocol layers: +ObjectStack is built around three layers: - **ObjectQL** (Data Layer) — Objects, fields, queries, relations, validation, and data access. -- **ObjectOS** (Control Layer) — Runtime, permissions, automation, plugins, environments, and artifact loading. +- **Kernel** (Control Layer) — Runtime, permissions, automation, plugins, environments, and artifact loading. - **ObjectUI** (View Layer) — Apps, views, dashboards, actions, and presentation metadata. -> Naming note: **ObjectOS** above names the control-layer *protocol*. The commercial [ObjectOS](https://docs.objectos.ai) runtime environment is the official product built on that layer. - All core definitions start with **Zod schemas** (1,600+ exported schemas across 200 schema files). TypeScript types, JSON Schemas, REST routes, UI metadata, and agent tools are derived from the same source of truth. See [ARCHITECTURE.md](./ARCHITECTURE.md) for the full microkernel and layer architecture documentation, and [content/docs/concepts/north-star.mdx](./content/docs/concepts/north-star.mdx) for the product north star (metadata protocols · environment-aware runtime · compiled app artifacts). @@ -290,10 +288,10 @@ For the browser, the typed client SDK and React hooks (`useQuery` / `useMutation ## Architecture -ObjectStack uses a **microkernel architecture** where the kernel provides only the essential infrastructure (DI, EventBus, lifecycle), and all capabilities are delivered as plugins. The three protocol layers sit above the kernel: +ObjectStack uses a **microkernel architecture** where the kernel provides only the essential infrastructure (DI, EventBus, lifecycle), and all capabilities are delivered as plugins. The three layers sit above the microkernel:

- ObjectStack layered architecture: the ObjectQL data layer, ObjectOS control layer, and ObjectUI view layer sit on a microkernel (plugin lifecycle, service registry / DI, event bus); every capability — drivers, server, auth, security, automation, AI — is a plugin + ObjectStack layered architecture: the ObjectQL data layer, the kernel control layer, and the ObjectUI view layer sit on a microkernel (plugin lifecycle, service registry / DI, event bus); every capability — drivers, server, auth, security, automation, AI — is a plugin

See [ARCHITECTURE.md](./ARCHITECTURE.md) for the complete design documentation including the plugin lifecycle state machine, dependency graph, and design decisions. diff --git a/content/docs/automation/index.mdx b/content/docs/automation/index.mdx index 572fcd9979..f161b22483 100644 --- a/content/docs/automation/index.mdx +++ b/content/docs/automation/index.mdx @@ -5,7 +5,7 @@ description: Hooks, flows, workflows, approvals, scheduled jobs, and durable web # Automation -Automation is ObjectStack's process engine: you attach business logic to the data model **declaratively** — as metadata — instead of scattering it through application code. It is a cross-protocol capability: automations are declared in the Automation Protocol namespace and executed by the ObjectOS runtime against ObjectQL data. +Automation is ObjectStack's process engine: you attach business logic to the data model **declaratively** — as metadata — instead of scattering it through application code. It is a cross-protocol capability: automations are declared in the Automation Protocol namespace and executed by the ObjectStack runtime against ObjectQL data. The smallest useful automation is a hook (from the CRM example app): diff --git a/content/docs/concepts/architecture.mdx b/content/docs/concepts/architecture.mdx index e499789a63..ce3a91e8b5 100644 --- a/content/docs/concepts/architecture.mdx +++ b/content/docs/concepts/architecture.mdx @@ -13,7 +13,7 @@ The architecture is built on foundational protocols that work together as a unif **This is the engine-level view.** When you *build*, you work by area — data, automation, interface, access, AI (see [What you build](/docs/getting-started/quick-start#what-you-build)). This page zooms one level down, into the runtime engines that implement those areas: -**ObjectQL** (data), **ObjectOS** (control — automation, access, governance), and +**ObjectQL** (data), **Kernel** (control — automation, access, governance), and **ObjectUI** (interface). You rarely think in these three while building; they're the machinery underneath. @@ -32,7 +32,7 @@ machinery underneath. } title="System Protocol" - description="ObjectOS: Control, runtime, and governance." + description="Kernel: Control, runtime, and governance." /> } @@ -133,7 +133,7 @@ This definition is **pure metadata**. It doesn't know: That's the job of the other layers. -## Layer 2: ObjectOS (Control Protocol) +## Layer 2: Kernel (Control Protocol) **Role:** Manage the **Lifecycle** and **Governance** of requests. @@ -144,7 +144,7 @@ That's the job of the other layers. - Event processing (audit logs, notifications) - Multi-tenancy and data isolation -**Key Principle:** ObjectOS acts as the **Gateway**. No layer can directly access the database; all requests must pass through the OS Kernel. +**Key Principle:** Kernel acts as the **Gateway**. No layer can directly access the database; all requests must pass through the Kernel. ### Example: Permission Rules @@ -204,7 +204,7 @@ export const HighValueCustomerFlow = defineFlow({ See the [Flow Metadata reference](/docs/automation/flows) for the full Flow node and edge reference. -ObjectOS **orchestrates** these rules at runtime, independent of the data structure or UI. +Kernel **orchestrates** these rules at runtime, independent of the data structure or UI. ## Layer 3: ObjectUI (View Protocol) @@ -301,7 +301,7 @@ User clicks "Save" ### Step 2: UI Layer Sends Request ```typescript -// ObjectUI dispatches an action to ObjectOS +// ObjectUI dispatches an action to Kernel const request = { action: 'create', object: 'customer', @@ -314,7 +314,7 @@ const request = { }; ``` -### Step 3: ObjectOS Validates Permissions +### Step 3: Kernel Validates Permissions ```typescript // Kernel checks: Does this user have permission? @@ -330,7 +330,7 @@ if (!canCreate) { } ``` -### Step 4: ObjectOS Validates Data +### Step 4: Kernel Validates Data ```typescript // Kernel asks ObjectQL: Is this data valid? @@ -355,7 +355,7 @@ const result = await driver.insert('customer', { }); ``` -### Step 6: ObjectOS Triggers Workflows +### Step 6: Kernel Triggers Workflows ```typescript // Kernel checks: Are there any workflows for this event? @@ -424,7 +424,7 @@ export const Opportunity = ObjectSchema.create({ }); ``` -### 2. ObjectOS: Define Business Rules +### 2. Kernel: Define Business Rules ```typescript import { defineFlow } from '@objectstack/spec'; @@ -478,10 +478,10 @@ export const OpportunityKanbanView = defineView({ When a user **drags an opportunity card** from "Proposal" to "Closed Won": 1. **ObjectUI** captures the drag-drop event -2. **ObjectOS** checks if the user has permission to update the `stage` field +2. **Kernel** checks if the user has permission to update the `stage` field 3. **ObjectQL** validates that `"closed_won"` is a valid option 4. **ObjectQL** writes the update to the database -5. **ObjectOS** triggers the workflow (create invoice, send notification) +5. **Kernel** triggers the workflow (create invoice, send notification) 6. **ObjectUI** updates the kanban board to reflect the new state **All from metadata. Zero hardcoded logic.** @@ -499,7 +499,7 @@ Same Metadata Definitions ObjectQL: │ │ Postgres │ MongoDB │ -ObjectOS: │ +Kernel: │ Node.js │ Python │ ObjectUI: │ @@ -511,7 +511,7 @@ React │ Flutter Teams can work independently on each layer: - **Data Team:** Define objects in ObjectQL -- **Backend Team:** Build workflows in ObjectOS +- **Backend Team:** Build workflows in Kernel - **Frontend Team:** Create views in ObjectUI All communicate through **protocol contracts**, not code dependencies. @@ -521,7 +521,7 @@ All communicate through **protocol contracts**, not code dependencies. Adopt ObjectStack gradually: - **Phase 1:** Use ObjectQL as an ORM replacement -- **Phase 2:** Add ObjectOS for permissions and workflows +- **Phase 2:** Add Kernel for permissions and workflows - **Phase 3:** Build ObjectUI views to replace custom forms Each layer is independently useful. @@ -531,14 +531,14 @@ Each layer is independently useful. Mock any layer for testing: ```typescript -// Test ObjectOS workflows without a real database +// Test Kernel workflows without a real database const mockObjectQL = { getSchema: () => CustomerSchema, insert: jest.fn(), }; // Test ObjectUI rendering without a real backend -const mockObjectOS = { +const mockKernel = { checkPermission: () => true, executeQuery: () => mockData, }; @@ -549,7 +549,7 @@ const mockObjectOS = { | Layer | Role | Knows About | Doesn't Know About | | :--- | :--- | :--- | :--- | | **ObjectQL** | Data structure & queries | Schema, fields, drivers | Users, permissions, UI | -| **ObjectOS** | Runtime & governance | Auth, workflows, events | Data structure, UI layout | +| **Kernel** | Runtime & governance | Auth, workflows, events | Data structure, UI layout | | **ObjectUI** | Presentation & interaction | Layout, navigation, actions | Business logic, data storage | The three protocols are **loosely coupled** but **tightly integrated**: @@ -561,7 +561,7 @@ The three protocols are **loosely coupled** but **tightly integrated**: - [ObjectQL: Data Protocol](/docs/protocol/objectql) - Full data protocol specification - [ObjectUI: UI Protocol](/docs/protocol/objectui) - Full view protocol specification -- [ObjectOS: System Protocol](/docs/protocol/objectos) - Full control protocol specification +- [Kernel: System Protocol](/docs/protocol/objectos) - Full control protocol specification - [Developer Guide](/docs/getting-started/quick-start) - Build your first ObjectStack application --- @@ -599,7 +599,7 @@ View Protocol (uses Object, Query) └→ Action Protocol (UI interactions) ``` -### System Layer (ObjectOS) +### System Layer (Kernel) ``` Data Driver Contracts (Database Abstraction) diff --git a/content/docs/concepts/metadata-driven.mdx b/content/docs/concepts/metadata-driven.mdx index 08593350dc..b0f9c58355 100644 --- a/content/docs/concepts/metadata-driven.mdx +++ b/content/docs/concepts/metadata-driven.mdx @@ -124,7 +124,7 @@ const taskForm = { type: 'form', object: 'task' } **Traditional:** Write REST endpoints by hand **ObjectStack:** APIs are *generated* from the schema -You don't write controllers or routes. ObjectOS *generates* the entire API graph based on your Object definitions and permission rules. +You don't write controllers or routes. ObjectStack *generates* the entire API graph based on your Object definitions and permission rules. ```bash # Automatically available after defining the object: diff --git a/content/docs/getting-started/glossary.mdx b/content/docs/getting-started/glossary.mdx index 18477b22cf..2665580041 100644 --- a/content/docs/getting-started/glossary.mdx +++ b/content/docs/getting-started/glossary.mdx @@ -17,15 +17,15 @@ A logical grouping of related schemas and types defined with Zod. ObjectStack ha ## The Three Architectural Layers -The 15 namespaces collapse into three top-level layers that match the public product vocabulary: +The 15 namespaces collapse into three top-level layers: | Layer | Also called | Namespaces it includes | Purpose | | :--- | :--- | :--- | :--- | | **ObjectQL** | Data Layer | Data | Objects, fields, queries, relations, validation, data access | -| **ObjectOS** | Control Layer / System Layer | Kernel, System, Automation, AI, API, Identity, Security, Cloud, Integration, Studio, QA, Contracts, Shared | Runtime, permissions, automation, plugins, tenants, agent tools, artifact loading | +| **Kernel** | Control Layer / System Layer (formerly named "ObjectOS") | Kernel, System, Automation, AI, API, Identity, Security, Cloud, Integration, Studio, QA, Contracts, Shared | Runtime, permissions, automation, plugins, tenants, agent tools, artifact loading | | **ObjectUI** | View Layer | UI | Apps, views, dashboards, actions, presentation metadata | -When external docs or talks refer to ObjectOS as the "Control Layer", they mean the same runtime described by the System/Kernel/AI/API protocol namespaces below. +Older docs and talks used **ObjectOS** as the name of this control layer. That name now refers exclusively to the commercial ObjectOS runtime environment ([docs.objectos.ai](https://docs.objectos.ai)); the open control layer is called the **Kernel**, described by the System/Kernel/AI/API protocol namespaces below. --- @@ -41,7 +41,7 @@ Server-Driven UI specification for building user interfaces. Includes App struct Infrastructure services including Event Bus, Job Scheduling, Translation (i18n), and Audit Logging. Manages system-level concerns. ### Kernel Protocol -Plugin system and runtime management. Includes Plugin lifecycle, Manifest definition, Logger configuration, and Runtime Context. The core of ObjectOS. +Plugin system and runtime management. Includes Plugin lifecycle, Manifest definition, Logger configuration, and Runtime Context. The core of the control layer. ### AI Protocol Artificial intelligence capabilities including AI Agents, RAG pipelines, Natural Language Query (NLQ), Predictive models, Cost tracking, and Orchestration. diff --git a/content/docs/getting-started/index.mdx b/content/docs/getting-started/index.mdx index 9d650cc352..ea4608cba7 100644 --- a/content/docs/getting-started/index.mdx +++ b/content/docs/getting-started/index.mdx @@ -106,7 +106,7 @@ Think of ObjectStack as: **The UI is a Projection. The API is a Consequence.** - ObjectUI does not "build" a form; it *projects* the ObjectQL schema into a visual representation -- You do not write endpoints or hand-author every agent tool; ObjectOS *generates* the secure graph based on the access control protocol +- You do not write endpoints or hand-author every agent tool; ObjectStack *generates* the secure graph based on the access control protocol ### 2. Agent-Ready Boundaries diff --git a/content/docs/index.mdx b/content/docs/index.mdx index 0403135bf0..1e7243c256 100644 --- a/content/docs/index.mdx +++ b/content/docs/index.mdx @@ -45,13 +45,13 @@ Each module documents one capability in depth — overview first, then guides, w - + ## Protocol & reference -- [Protocol Spec](/docs/protocol) — the normative ObjectQL / ObjectOS / ObjectUI specifications for implementers +- [Protocol Spec](/docs/protocol) — the normative ObjectQL / Kernel / ObjectUI specifications for implementers - [Schema Reference](/docs/references) — generated Zod schema reference for every metadata type - [Quick Reference](/docs/getting-started/quick-reference) — fast lookup tables across all protocols - [Glossary](/docs/getting-started/glossary) — the shared vocabulary used across these docs diff --git a/content/docs/permissions/index.mdx b/content/docs/permissions/index.mdx index 08be302a7a..68e736e5ad 100644 --- a/content/docs/permissions/index.mdx +++ b/content/docs/permissions/index.mdx @@ -1,12 +1,12 @@ --- title: "Permissions & Identity" -description: "Authentication, authorization, and record- and field-level access control in ObjectStack — a cross-protocol capability enforced by the ObjectOS runtime and declared as ObjectQL security metadata." +description: "Authentication, authorization, and record- and field-level access control in ObjectStack — a cross-protocol capability enforced by the ObjectStack runtime and declared as ObjectQL security metadata." --- # Permissions & Identity This module covers authentication, authorization, and record- and field-level -access control. It is a cross-protocol capability: enforced by the ObjectOS +access control. It is a cross-protocol capability: enforced by the ObjectStack runtime, declared as ObjectQL security metadata. The model has **five concepts, one reading each** (ADR-0090): additive diff --git a/content/docs/plugins/packages.mdx b/content/docs/plugins/packages.mdx index 806c2137a7..3417c8aef0 100644 --- a/content/docs/plugins/packages.mdx +++ b/content/docs/plugins/packages.mdx @@ -97,7 +97,7 @@ const kernel = new ObjectKernel(); ### @objectstack/platform-objects -**Platform Objects Library** — The canonical set of `sys_*` objects shipped with every ObjectOS runtime (users, sessions, approvals, sharing, audit, …). +**Platform Objects Library** — The canonical set of `sys_*` objects shipped with every ObjectStack runtime (users, sessions, approvals, sharing, audit, …). - **Purpose**: Standard system tables and their metadata, so apps don't redefine identity, audit, or approvals - **When to use**: Always — bundled into the runtime diff --git a/content/docs/protocol/diagram.mdx b/content/docs/protocol/diagram.mdx index 1277ca2b19..4a411a0135 100644 --- a/content/docs/protocol/diagram.mdx +++ b/content/docs/protocol/diagram.mdx @@ -19,7 +19,7 @@ ObjectStack is composed of seven protocol layers that work together to form a co |:---|:---|:---| | **Data (ObjectQL)** | `src/data/` | Objects, Fields, Queries, Hooks, State Machines | | **UI (ObjectUI)** | `src/ui/` | Views, Apps, Dashboards, Reports, Actions | -| **System (ObjectOS)** | `src/system/` | Manifest, Datasources, Plugins, Kernel | +| **System (Kernel)** | `src/system/` | Manifest, Datasources, Plugins, Kernel | | **Automation** | `src/automation/` | Flows, Workflows, Triggers, Approvals | | **AI** | `src/ai/` | Agents, RAG Pipelines, Model Registry | | **API** | `src/api/` | REST, GraphQL, WebSocket, Realtime | @@ -70,7 +70,7 @@ graph TB MODELS[Model Registry] end - subgraph "System Layer (ObjectOS)" + subgraph "System Layer (Kernel)" MANIFEST[Manifest] KERNEL[Kernel] PLUGINS[Plugins] diff --git a/content/docs/protocol/index.mdx b/content/docs/protocol/index.mdx index 2fe35b647d..17eee8ea3b 100644 --- a/content/docs/protocol/index.mdx +++ b/content/docs/protocol/index.mdx @@ -12,7 +12,7 @@ The ObjectStack Protocol defines three interconnected layers that together descr } title="ObjectQL: Data Protocol" href="/docs/protocol/objectql" description="Schema definitions, field types, state machines, query syntax, and data security." /> } title="ObjectUI: UI Protocol" href="/docs/protocol/objectui" description="Server-driven UI contracts for layouts, widgets, forms, and actions." /> - } title="ObjectOS: System Protocol" href="/docs/protocol/objectos" description="Runtime lifecycle, HTTP/realtime protocols, plugins, configuration, and i18n." /> + } title="Kernel: System Protocol" href="/docs/protocol/objectos" description="Runtime lifecycle, HTTP/realtime protocols, plugins, configuration, and i18n." /> ## Design Principles diff --git a/content/docs/protocol/objectos/config-resolution.mdx b/content/docs/protocol/objectos/config-resolution.mdx index bac4f0e10b..182b56d8bc 100644 --- a/content/docs/protocol/objectos/config-resolution.mdx +++ b/content/docs/protocol/objectos/config-resolution.mdx @@ -8,7 +8,7 @@ import { Settings, Layers, Lock, Users, FileCode, Shield } from 'lucide-react'; # Configuration Resolution -**Protocol spec, partial implementation.** This page describes ObjectOS's target +**Protocol spec, partial implementation.** This page describes ObjectStack's target configuration model: hierarchical sources, tenant isolation, secret stores. The merge / precedence logic is implemented; the richer nested shapes shown in code samples below (e.g. `database`, `http`, `secrets.provider`) are @@ -17,7 +17,7 @@ and the `datasources` / `plugins` keys on `defineStack`. Treat the snippets as design intent, not paste-ready code. -ObjectOS uses a **hierarchical configuration system** that merges settings from multiple sources with clear **precedence rules**. This enables environment-specific overrides, tenant isolation, and user preferences—all from a single unified API. +ObjectStack uses a **hierarchical configuration system** that merges settings from multiple sources with clear **precedence rules**. This enables environment-specific overrides, tenant isolation, and user preferences—all from a single unified API. ## The Configuration Problem @@ -41,7 +41,7 @@ const apiKey = ## Configuration Sources -ObjectOS defines **six configuration sources** with strict precedence: +ObjectStack defines **six configuration sources** with strict precedence: ``` ┌─────────────────────────────────────────────────────────────┐ @@ -256,7 +256,7 @@ raw string. #### File Locations -ObjectOS loads config files in this order: +ObjectStack loads config files in this order: ``` 1. objectstack.config.ts (TypeScript, recommended) @@ -404,7 +404,7 @@ const maxAccounts = config.get('crm.maxAccountsPerUser'); ## Merge Strategies -When multiple sources define the same key, ObjectOS uses **deep merge** for objects and **replace** for primitives. +When multiple sources define the same key, ObjectStack uses **deep merge** for objects and **replace** for primitives. ### Replace (Primitives) @@ -578,7 +578,7 @@ CREATE TABLE objectstack_secrets ( ```typescript // Secrets are automatically decrypted when accessed const apiKey = config.get('stripe.apiKey'); -// ObjectOS decrypts value transparently +// ObjectStack decrypts value transparently // Secrets are redacted in logs logger.info('Config loaded', { config: config.getAll() }); @@ -587,7 +587,7 @@ logger.info('Config loaded', { config: config.getAll() }); ### External Secret Stores -ObjectOS integrates with external secret managers: +ObjectStack integrates with external secret managers: ```typescript // objectstack.config.ts @@ -605,7 +605,7 @@ export default defineStack({ // Access works the same const apiKey = config.get('stripe.apiKey'); -// ObjectOS fetches from AWS Secrets Manager transparently +// ObjectStack fetches from AWS Secrets Manager transparently ``` **Supported Providers:** @@ -617,7 +617,7 @@ const apiKey = config.get('stripe.apiKey'); ## Configuration Validation -ObjectOS validates configuration against **Zod schemas** at boot. +ObjectStack validates configuration against **Zod schemas** at boot. ### Schema Definition @@ -645,11 +645,11 @@ export const configSchema = z.object({ ### Boot-Time Validation ```typescript -// ObjectOS validates config during boot +// ObjectStack validates config during boot export async function onBoot({ context }) { // Get and validate config const config = context.config.get('crm', configSchema); - // If config is invalid, ObjectOS throws ZodError with details + // If config is invalid, ObjectStack throws ZodError with details } ``` @@ -890,7 +890,7 @@ export const configSchema = z.object({ ## Summary -ObjectOS configuration resolution: +ObjectStack configuration resolution: - **Six sources** with clear precedence (runtime > environment > tenant > user > file > defaults) - **Deep merge** for objects, **replace** for primitives - **Tenant isolation** for multi-tenant SaaS diff --git a/content/docs/protocol/objectos/i18n-standard.mdx b/content/docs/protocol/objectos/i18n-standard.mdx index b777d55706..ee4ef35f52 100644 --- a/content/docs/protocol/objectos/i18n-standard.mdx +++ b/content/docs/protocol/objectos/i18n-standard.mdx @@ -20,7 +20,7 @@ auto-translate hooks) describe **target behaviour** and are not yet implemented. Treat those snippets as design intent. -ObjectOS provides **built-in internationalization** that enables applications to support multiple languages, locales, and regional formats without external libraries or complex configuration. +ObjectStack provides **built-in internationalization** that enables applications to support multiple languages, locales, and regional formats without external libraries or complex configuration. ## The i18n Problem @@ -42,9 +42,9 @@ pluralize('item', 5); **Result:** 500KB+ of dependencies, inconsistent APIs, and hours of configuration. -## ObjectOS i18n Solution +## ObjectStack i18n Solution -ObjectOS provides a **unified i18n API** with batteries included: +ObjectStack provides a **unified i18n API** with batteries included: ```typescript // Today: translation + interpolation via the II18nService contract @@ -67,7 +67,7 @@ i18n.t('messages.welcome', 'en', { name: 'John' }); // Translation + interpolati ## Locale Resolution -ObjectOS automatically determines the user's locale using a **fallback chain**: +ObjectStack automatically determines the user's locale using a **fallback chain**: ``` ┌─────────────────────────────────────────────────────────────┐ @@ -117,7 +117,7 @@ Examples: ### Locale Fallback -If exact locale not found, ObjectOS falls back to **language-only** locale: +If exact locale not found, ObjectStack falls back to **language-only** locale: ``` User requests: de-AT (German, Austria) @@ -147,7 +147,7 @@ Translations are stored in **JSON files** organized by locale and namespace. ### Object-First Convention (Recommended) -ObjectOS uses an **object-first** convention where all translatable metadata +ObjectStack uses an **object-first** convention where all translatable metadata for an object is aggregated under `o.{object_name}`. Global (non-object-bound) translations remain in dedicated top-level groups. This aligns with Salesforce DX and Dynamics conventions, enabling efficient translation workbench editing @@ -764,7 +764,7 @@ Output: ### Translation Service Integration -ObjectOS integrates with professional translation services: +ObjectStack integrates with professional translation services: ```typescript // objectstack.config.ts @@ -904,7 +904,7 @@ export default defineStack({ ## Summary -ObjectOS i18n provides: +ObjectStack i18n provides: - **Translation bundles** in JSON format with object-first namespaces - **Fallback-locale resolution** for missing keys - **`{{param}}` interpolation** via `t(key, locale, params)` diff --git a/content/docs/protocol/objectos/index.mdx b/content/docs/protocol/objectos/index.mdx index 1381ad735b..3fed08c10f 100644 --- a/content/docs/protocol/objectos/index.mdx +++ b/content/docs/protocol/objectos/index.mdx @@ -1,11 +1,11 @@ --- -title: "ObjectOS: The System Protocol" +title: "Kernel: The System Protocol" description: The runtime orchestration layer - Lifecycle, plugins, configuration, and system services --- import { Server, Cog, Package, Zap, Shield, Globe, Network, Box, Layers } from 'lucide-react'; -**ObjectOS** is ObjectStack's runtime orchestration layer that manages the complete lifecycle of the platform. It provides the "operating system" services that coordinate ObjectQL (data) and ObjectUI (interface) into a cohesive application runtime. +**Kernel** is ObjectStack's runtime orchestration layer that manages the complete lifecycle of the platform. It provides the "operating system" services that coordinate ObjectQL (data) and ObjectUI (interface) into a cohesive application runtime. ## The Core Problem @@ -19,13 +19,13 @@ Traditional enterprise platforms tightly couple infrastructure concerns with bus **Result:** DevOps teams spend 60% of their time on deployment mechanics instead of building features. Configuration errors cause 80% of production incidents. -## The ObjectOS Solution +## The Kernel Solution } title="Declarative Lifecycle" - description="Define system state in manifests. ObjectOS ensures runtime matches declaration—no manual runbooks." + description="Define system state in manifests. Kernel ensures runtime matches declaration—no manual runbooks." /> } @@ -53,7 +53,7 @@ Traditional enterprise platforms tightly couple infrastructure concerns with bus └─────────────────────────┬────────────────────────────────────────┘ │ ┌─────────────────────────▼────────────────────────────────────────┐ -│ ObjectOS │ +│ Kernel │ │ ┌────────────────┐ ┌────────────────┐ ┌──────────────────┐ │ │ │ Lifecycle Mgmt │ │ Plugin Registry │ │ Config Resolver │ │ │ │ Boot/Install │ │ Dependencies │ │ Merge Strategy │ │ @@ -77,7 +77,7 @@ Traditional enterprise platforms tightly couple infrastructure concerns with bus └──────────────┘ └──────────────┘ ``` -**Key Insight:** ObjectOS is the **control plane**. ObjectQL and ObjectUI are the **data plane**. Separating concerns allows independent evolution. +**Key Insight:** Kernel is the **control plane**. ObjectQL and ObjectUI are the **data plane**. Separating concerns allows independent evolution. ## Core Components @@ -108,7 +108,7 @@ Traditional enterprise platforms tightly couple infrastructure concerns with bus /> -## Why ObjectOS Exists +## Why the Kernel Exists ### Problem: Deployment Complexity Kills Agility @@ -124,7 +124,7 @@ Traditional enterprise platforms tightly couple infrastructure concerns with bus 47. Pray to the demo gods ``` -**ObjectOS Approach:** +**Kernel Approach:** ```bash # Publish a compiled artifact as a versioned package to ObjectOS Cloud os package publish dist/objectstack.json --env --install @@ -149,7 +149,7 @@ os package publish dist/objectstack.json --env --install } ``` -**ObjectOS Approach:** +**Kernel Approach:** ```yaml # plugin.manifest.yml name: @mycompany/billing @@ -158,7 +158,7 @@ dependencies: '@objectstack/core': '^2.0.0' 'com.stripe.plugin': '>=10.0.0 <11.0.0' ``` -ObjectOS validates the **entire dependency graph** at install time. Incompatible plugins fail installation with clear error messages, not runtime crashes. +Kernel validates the **entire dependency graph** at install time. Incompatible plugins fail installation with clear error messages, not runtime crashes. **Business Value:** A marketplace with 200+ plugins has zero "it works on my machine" issues. Dependency conflicts are caught before customers hit "Install." @@ -174,17 +174,17 @@ const apiKey = 'fallback-key'; // 💀 Hardcoded default ``` -**ObjectOS Approach:** +**Kernel Approach:** ```typescript // Declarative merge strategy const config = context.config.resolve('stripe.apiKey', { sources: ['environment', 'tenant', 'plugin', 'default'], required: true }); -// ObjectOS merges in precedence order, validates, throws clear error if missing +// Kernel merges in precedence order, validates, throws clear error if missing ``` -**Business Value:** Configuration errors dropped 90% after adopting ObjectOS. New engineers can understand config logic in 5 minutes instead of 5 hours. +**Business Value:** Configuration errors dropped 90% after adopting Kernel. New engineers can understand config logic in 5 minutes instead of 5 hours. ## Real-World Use Cases @@ -196,7 +196,7 @@ const config = context.config.resolve('stripe.apiKey', { - Integrations (Customer A uses Salesforce, Customer B uses HubSpot) - Language (Customer A is US English, Customer B is German) -**ObjectOS Solution:** +**Kernel Solution:** - **Tenant Isolation:** Each customer is a "tenant" with scoped configuration - **Config Merging:** Global defaults → Tenant overrides → User preferences - **Plugin System:** Each integration is a plugin; tenants enable only what they need @@ -211,7 +211,7 @@ const config = context.config.resolve('stripe.apiKey', { **Challenge:** Build a plugin marketplace like Salesforce AppExchange where third-party developers sell integrations. -**ObjectOS Solution:** +**Kernel Solution:** - **Plugin Manifest:** Standardized `plugin.manifest.yml` declares what plugin provides and needs - **Dependency Resolution:** Automatic validation that plugin versions are compatible with core platform - **Lifecycle Hooks:** `onInstall`, `onEnable`, `onDisable` hooks for setup/teardown @@ -230,7 +230,7 @@ const config = context.config.resolve('stripe.apiKey', { - Regional compliance (GDPR in EU, LGPD in Brazil) - Local integrations (EU uses SEPA payments, US uses ACH) -**ObjectOS Solution:** +**Kernel Solution:** - **i18n Standard:** Translation bundles with fallback chains (`de-AT` → `de` → `en`) - **Region Config:** Configuration profiles per region (defaults + region overrides) - **Plugin System:** Regional plugins (SEPA plugin for EU, ACH plugin for US) @@ -241,9 +241,9 @@ const config = context.config.resolve('stripe.apiKey', { - Zero code changes for new languages (just upload translation files) - 95% translation coverage on day one (tooling validates translation completeness) -## How ObjectOS Orchestrates ObjectQL and ObjectUI +## How Kernel Orchestrates ObjectQL and ObjectUI -ObjectOS is the **runtime coordinator** that makes ObjectQL and ObjectUI work together: +Kernel is the **runtime coordinator** that makes ObjectQL and ObjectUI work together: ### 1. Boot Sequence ```typescript @@ -279,28 +279,28 @@ hooks in order, and exposes the resulting services through DI. ```typescript // Incoming API request: GET /api/accounts/123 async function handleRequest(req) { - // ObjectOS provides context - const context = await ObjectOS.createContext({ + // Kernel provides context + const context = await Kernel.createContext({ tenantId: req.headers['x-tenant-id'], userId: req.user.id, locale: req.headers['accept-language'], }); - // ObjectOS resolves configuration + // Kernel resolves configuration const config = context.config.resolve(); // ObjectQL executes query const account = await ObjectQL.findById('account', '123', { - context, // ObjectOS injects permissions, audit, etc. + context, // Kernel injects permissions, audit, etc. }); // ObjectUI renders response const view = await ObjectUI.render('account_detail', { record: account, - locale: context.locale, // ObjectOS provides i18n + locale: context.locale, // Kernel provides i18n }); - // ObjectOS logs audit trail + // Kernel logs audit trail context.audit.log('account.view', { accountId: '123' }); return view; @@ -310,7 +310,7 @@ async function handleRequest(req) { ### 3. Plugin Installation ```typescript // Install a package: os package install @vendor/salesforce-sync -await ObjectOS.installPlugin({ +await Kernel.installPlugin({ source: '@vendor/salesforce-sync@1.5.0', // Step 1: Validate dependencies @@ -340,7 +340,7 @@ await ObjectOS.installPlugin({ ## Philosophy: Infrastructure as Code -ObjectOS embodies **"Infrastructure as Code"** principles: +Kernel embodies **"Infrastructure as Code"** principles: ### Declarative, Not Imperative **Bad (Imperative):** @@ -364,7 +364,7 @@ permissions: - role: admin object: account access: read -# ObjectOS ensures runtime matches manifest +# Kernel ensures runtime matches manifest ``` ### Idempotent Operations @@ -411,7 +411,7 @@ export const configSchema = z.object({ // Access in plugin code const config = context.config.get('slack', configSchema); -// ObjectOS validates against schema, throws clear error if invalid +// Kernel validates against schema, throws clear error if invalid ``` ### Internationalization @@ -431,7 +431,7 @@ const config = context.config.get('slack', configSchema); // Use in code const message = context.i18n.t('slack.button.send'); -// ObjectOS automatically uses user's locale +// Kernel automatically uses user's locale ``` ## Best Practices @@ -441,7 +441,7 @@ const message = context.i18n.t('slack.button.send'); **Why:** Keeps core stable. Plugins evolve independently. Customers pay for only what they use. -**Example:** Don't build email sending into ObjectOS core. Create `@objectstack/email` plugin. Customers who don't send emails don't load the plugin (smaller memory footprint, faster boot). +**Example:** Don't build email sending into Kernel core. Create `@objectstack/email` plugin. Customers who don't send emails don't load the plugin (smaller memory footprint, faster boot). ### 2. Configuration Over Code **Principle:** Behavior should be configurable without code changes. @@ -469,11 +469,11 @@ const message = context.i18n.t('slack.button.send'); **Why:** Catch errors before customers see them. -**Example:** Plugin requires `apiKey` config. If missing, ObjectOS throws error during boot with clear message: "Plugin @vendor/slack requires config key 'slack.apiKey' (not found in environment, tenant, or default config)". +**Example:** Plugin requires `apiKey` config. If missing, Kernel throws error during boot with clear message: "Plugin @vendor/slack requires config key 'slack.apiKey' (not found in environment, tenant, or default config)". -## Comparison: ObjectOS vs Alternatives +## Comparison: Kernel vs Alternatives -| Feature | ObjectOS | Kubernetes | CloudFoundry | Heroku | +| Feature | Kernel | Kubernetes | CloudFoundry | Heroku | |---------|----------|------------|--------------|--------| | **Plugin System** | Built-in manifest-based | Helm charts (external) | Buildpacks | Add-ons marketplace | | **Config Management** | Hierarchical merge | ConfigMaps/Secrets | Environment vars | Config vars | @@ -483,7 +483,7 @@ const message = context.i18n.t('slack.button.send'); | **Zero-Downtime Upgrades** | Declarative | Rolling updates | Blue-green | Git push | | **Developer UX** | `os package publish` | `kubectl apply` | `cf push` | `git push heroku` | -**Key Differentiator:** ObjectOS is **application-aware**. Kubernetes knows about containers, not plugins. ObjectOS knows about ObjectQL objects, ObjectUI views, and business logic dependencies. +**Key Differentiator:** Kernel is **application-aware**. Kubernetes knows about containers, not plugins. Kernel knows about ObjectQL objects, ObjectUI views, and business logic dependencies. ## Next Steps @@ -516,7 +516,7 @@ const message = context.i18n.t('slack.button.send'); ## Summary -ObjectOS is the **control plane** that orchestrates ObjectStack: +Kernel is the **control plane** that orchestrates ObjectStack: - **Lifecycle Management:** Declarative deployment, zero-downtime upgrades, rollback safety - **Plugin System:** Microkernel architecture with dependency resolution and sandboxing - **Configuration:** Unified config with merge strategies and tenant isolation @@ -525,6 +525,6 @@ ObjectOS is the **control plane** that orchestrates ObjectStack: Think of it this way: - **ObjectQL** is the database driver (handles data CRUD) - **ObjectUI** is the rendering engine (handles presentation) -- **ObjectOS** is the operating system (handles coordination, configuration, lifecycle) +- **Kernel** is the operating system (handles coordination, configuration, lifecycle) -Without ObjectOS, you'd manually wire ObjectQL and ObjectUI together, manage deployments with runbooks, and fight configuration drift. With ObjectOS, the platform handles the "plumbing" so you focus on business logic. +Without Kernel, you'd manually wire ObjectQL and ObjectUI together, manage deployments with runbooks, and fight configuration drift. With Kernel, the platform handles the "plumbing" so you focus on business logic. diff --git a/content/docs/protocol/objectos/lifecycle.mdx b/content/docs/protocol/objectos/lifecycle.mdx index 965bf298ef..f121723244 100644 --- a/content/docs/protocol/objectos/lifecycle.mdx +++ b/content/docs/protocol/objectos/lifecycle.mdx @@ -12,16 +12,16 @@ import { Zap, Power, Package, RefreshCw, ArrowLeft, CheckCircle, XCircle, AlertT shutdown described below reflect the current `@objectstack/core` and CLI behaviour. The plugin upgrade flow (`objectstack upgrade @vendor/pkg --strategy blue-green`, multi-instance rolling upgrades, automatic backup & -rollback) describes the **target** lifecycle for hosted ObjectOS — today it is +rollback) describes the **target** lifecycle for hosted ObjectStack — today it is partially implemented in the control plane and exposed only on hosted plans. Treat those command snippets as design intent. -ObjectOS manages the complete **lifecycle** of the platform runtime—from initial boot to plugin installation, upgrades, and rollbacks. Every operation is **declarative**, **idempotent**, and **auditable**. +ObjectStack manages the complete **lifecycle** of the platform runtime—from initial boot to plugin installation, upgrades, and rollbacks. Every operation is **declarative**, **idempotent**, and **auditable**. ## Boot Sequence -The ObjectOS boot process follows a **strict order** to ensure dependencies are satisfied before services start. +The ObjectStack boot process follows a **strict order** to ensure dependencies are satisfied before services start. ### Boot Phases @@ -114,7 +114,7 @@ await kernel.bootstrap(); ### Boot Logs (Example) ``` -[2024-01-15T10:23:01.234Z] INFO ObjectOS starting... +[2024-01-15T10:23:01.234Z] INFO ObjectStack starting... [2024-01-15T10:23:01.250Z] INFO Phase 1: Initialize [2024-01-15T10:23:01.251Z] INFO ✓ Node.js v20.10.0 [2024-01-15T10:23:01.252Z] INFO ✓ Memory: 2048 MB available @@ -137,7 +137,7 @@ await kernel.bootstrap(); [2024-01-15T10:23:01.900Z] INFO ✓ Job scheduler started (5 jobs loaded) [2024-01-15T10:23:01.950Z] INFO ✓ HTTP server listening on :3000 [2024-01-15T10:23:02.000Z] INFO Phase 7: Ready -[2024-01-15T10:23:02.001Z] INFO ObjectOS ready in 766ms +[2024-01-15T10:23:02.001Z] INFO ObjectStack ready in 766ms ``` ### Error Handling During Boot @@ -387,7 +387,7 @@ Next steps: ## Upgrades -ObjectOS supports **zero-downtime upgrades** with automatic rollback on failure. +ObjectStack supports **zero-downtime upgrades** with automatic rollback on failure. ### Upgrade Strategies @@ -505,7 +505,7 @@ export async function down(db: any): Promise { } ``` -Run migrations through your existing Knex / driver tooling — ObjectOS does not +Run migrations through your existing Knex / driver tooling — ObjectStack does not ship its own migration runner. The intent of `os generate migration` is to give you a hand-off file you can commit, review, and execute via the database tools your team already uses. @@ -522,7 +522,7 @@ migrations: ### Upgrade Rollback -If upgrade fails, ObjectOS **automatically rolls back** to previous version. +If upgrade fails, ObjectStack **automatically rolls back** to previous version. #### Rollback Scenarios @@ -565,7 +565,7 @@ whatever Knex / driver tooling your team uses to apply the `up()`. The behaviour around backups, rollback, and health checks during an `objectstack upgrade` is controlled by the host runtime / hosting platform — not by a top-level `defineStack` key today. Hosted ObjectStack and self-hosted -ObjectOS expose this through environment-specific configuration: +ObjectStack expose this through environment-specific configuration: | Concern | Hosted control plane | Self-hosted | | :--- | :--- | :--- | @@ -579,7 +579,7 @@ policy, not a property of the application. ## Health Checks -ObjectOS includes **built-in health monitoring** to validate system state. +ObjectStack includes **built-in health monitoring** to validate system state. ### Health Check Endpoints @@ -785,7 +785,7 @@ Plugin authors must document breaking changes in CHANGELOG.md. ## Summary -ObjectOS lifecycle management provides: +ObjectStack lifecycle management provides: - **Deterministic Boot:** 7-phase boot sequence with clear error handling - **Atomic Installations:** Transactions ensure all-or-nothing plugin installs - **Zero-Downtime Upgrades:** Blue-green and rolling strategies for production diff --git a/content/docs/protocol/objectos/metadata-service.mdx b/content/docs/protocol/objectos/metadata-service.mdx index 5520df0cee..61b2aef529 100644 --- a/content/docs/protocol/objectos/metadata-service.mdx +++ b/content/docs/protocol/objectos/metadata-service.mdx @@ -5,7 +5,7 @@ description: The unified engine for loading, saving, and managing configuration import { Database, FileCode, Layers, RefreshCw, Save } from 'lucide-react'; -The **Metadata Service** is the backbone of ObjectOS configuration management. It decouples the *definition* of metadata (Objects, Views, Flows) from its runtime delivery path: local development reads files or `dist/objectstack.json`, while production ObjectOS reads an immutable artifact from the control plane. Project databases store business rows only. +The **Metadata Service** is the backbone of ObjectStack configuration management. It decouples the *definition* of metadata (Objects, Views, Flows) from its runtime delivery path: local development reads files or `dist/objectstack.json`, while production ObjectStack reads an immutable artifact from the control plane. Project databases store business rows only. ## Architecture @@ -15,7 +15,7 @@ The Metadata Service uses a **Provider/Loader** architecture. The core `Metadata } title="Registry Pattern" - description="The Manager accepts any number of Loaders. Runtime ObjectOS uses file/artifact loaders; control-plane services can opt into database loaders explicitly." + description="The Manager accepts any number of Loaders. Runtime ObjectStack uses file/artifact loaders; control-plane services can opt into database loaders explicitly." /> } @@ -63,7 +63,7 @@ Loaders adapt different storage backends to a common interface. | :--- | :--- | :--- | | **FilesystemLoader** | `filesystem` | Reads/Writes `.json`, `.yaml`, `.ts` files from disk. Primary for development. | | **MemoryLoader** | `memory` | Hydrates compiled artifact items into the runtime metadata registry. | -| **DatabaseLoader** | `database` | Stores metadata revisions in control-plane services that explicitly configure it. Not auto-enabled by ObjectOS. | +| **DatabaseLoader** | `database` | Stores metadata revisions in control-plane services that explicitly configure it. Not auto-enabled by ObjectStack. | | **RemoteLoader** | `http` | Fetches metadata from a remote API or git repository. | ### 3. Granular Capabilities @@ -86,7 +86,7 @@ export interface MetadataLoaderContract { ## Internal Persistence API -The Metadata Service supports full CRUD operations for authoring tools and control-plane services. Runtime ObjectOS treats metadata as read-only after artifact/file hydration; `MetadataPlugin` does not automatically bridge ObjectQL to `DatabaseLoader`. +The Metadata Service supports full CRUD operations for authoring tools and control-plane services. Runtime ObjectStack treats metadata as read-only after artifact/file hydration; `MetadataPlugin` does not automatically bridge ObjectQL to `DatabaseLoader`. ### Saving Metadata (Node.js) @@ -109,7 +109,7 @@ await manager.save('object', 'workflow_config', data, { ### Loading Strategy -When `load()` is called, the Manager iterates through registered loaders. In ObjectOS runtime boot this means "artifact/file first"; database-backed metadata is reserved for explicitly configured control-plane services. +When `load()` is called, the Manager iterates through registered loaders. In ObjectStack runtime boot this means "artifact/file first"; database-backed metadata is reserved for explicitly configured control-plane services. ```mermaid graph LR @@ -137,7 +137,7 @@ const unsubscribe = manager.subscribe('object', (event) => { ## Remote API Access - ObjectOS metadata is artifact-backed at runtime. Read/write metadata APIs belong to authoring tools and the control plane. + ObjectStack metadata is artifact-backed at runtime. Read/write metadata APIs belong to authoring tools and the control plane. The system provides standard REST and TypeScript APIs for interacting with metadata, including **full read/write support**. @@ -236,4 +236,4 @@ The Metadata Service is designed to power the CLI. - **`objectstack compile`**: Validates TypeScript metadata and emits `dist/objectstack.json`. - **`objectstack publish`**: Uploads compiled JSON to the control plane, which creates a metadata revision and artifact. -- **`objectstack dev`**: Boots ObjectOS from local files or the compiled artifact without a control-plane connection. +- **`objectstack dev`**: Boots ObjectStack from local files or the compiled artifact without a control-plane connection. diff --git a/content/docs/protocol/objectos/plugin-spec.mdx b/content/docs/protocol/objectos/plugin-spec.mdx index 23f330db23..b212414051 100644 --- a/content/docs/protocol/objectos/plugin-spec.mdx +++ b/content/docs/protocol/objectos/plugin-spec.mdx @@ -33,7 +33,7 @@ my-plugin/ plugin.manifest.json ← JSON (alternative) ``` -**Recommendation:** Use TypeScript manifest for **type safety** and **validation**. ObjectOS auto-generates JSON schema from TypeScript. +**Recommendation:** Use TypeScript manifest for **type safety** and **validation**. ObjectStack auto-generates JSON schema from TypeScript. ### Manifest Schema @@ -442,7 +442,7 @@ Use for large dependencies (React, Vue) that should be shared across plugins. ### Version Constraints -ObjectOS uses **semantic versioning (semver)** with these operators: +ObjectStack uses **semantic versioning (semver)** with these operators: ```typescript dependencies: { @@ -465,7 +465,7 @@ dependencies: { ### Dependency Resolution -ObjectOS builds a **dependency graph** and loads plugins in **topological order**: +ObjectStack builds a **dependency graph** and loads plugins in **topological order**: ``` @objectstack/core (no deps) @@ -561,7 +561,7 @@ export async function onUpgrade({ context, fromVersion, toVersion, transaction } // src/lifecycle/boot.ts export async function onBoot({ context }) { - // Runs every time ObjectOS boots (after plugin is loaded) + // Runs every time ObjectStack boots (after plugin is loaded) // Example: Validate configuration const config = context.config.get('crm'); @@ -600,7 +600,7 @@ During **boot**: ## Permissions -Plugins must **declare permissions** they require. ObjectOS enforces these at runtime. +Plugins must **declare permissions** they require. ObjectStack enforces these at runtime. ### System Permissions @@ -628,7 +628,7 @@ permissions: { } ``` -If plugin attempts operation without permission, ObjectOS throws error: +If plugin attempts operation without permission, ObjectStack throws error: ```javascript // Plugin tries to make HTTP request without permission @@ -654,7 +654,7 @@ permissions: { } ``` -ObjectOS uses this for: +ObjectStack uses this for: - **Dependency tracking:** Can't uninstall plugin if other plugins reference its objects - **Security:** Plugin can only modify its own objects (not objects from other plugins) - **Cleanup:** Uninstalling plugin can optionally remove its objects @@ -945,7 +945,7 @@ export async function onUninstall({ context, transaction }) { ## Summary -Plugin packages in ObjectOS: +Plugin packages in ObjectStack: - **Manifest-driven:** `plugin.manifest.ts` is the source of truth - **Self-contained:** Bundle objects, views, logic, and config - **Dependency-managed:** Semantic versioning with conflict detection diff --git a/content/docs/protocol/objectos/runtime-capabilities.mdx b/content/docs/protocol/objectos/runtime-capabilities.mdx index ff2b6b4266..6777873b03 100644 --- a/content/docs/protocol/objectos/runtime-capabilities.mdx +++ b/content/docs/protocol/objectos/runtime-capabilities.mdx @@ -1,6 +1,6 @@ --- title: Runtime Capabilities -description: Understanding ObjectStack's subsystem capabilities (ObjectQL, ObjectUI, ObjectOS) +description: Understanding ObjectStack's subsystem capabilities (ObjectQL, ObjectUI, ObjectStack) --- # Runtime Capabilities @@ -27,7 +27,7 @@ ObjectStack capabilities are organized into three subsystems that correspond to ▲ │ ┌─────────────────────────────────────────────────────────┐ -│ ObjectOS Capabilities (System/Runtime Layer) │ +│ ObjectStack Capabilities (System/Runtime Layer) │ │ • API protocols (REST, GraphQL, OData) │ │ • Real-time (WebSockets, SSE, Event Bus) │ │ • Security (Authentication, RBAC, RLS, FLS) │ @@ -52,7 +52,7 @@ import type { ObjectStackCapabilities } from '@objectstack/spec'; const capabilities: ObjectStackCapabilities = { data: { /* ObjectQL capabilities */ }, ui: { /* ObjectUI capabilities */ }, - system: { /* ObjectOS capabilities */ }, + system: { /* ObjectStack capabilities */ }, }; ``` @@ -161,7 +161,7 @@ The **User Interface Layer** capabilities define what UI components and views ar --- -## ObjectOS Capabilities +## ObjectStack Capabilities The **System Layer** capabilities define runtime, API, security, and platform service features. @@ -169,7 +169,7 @@ The **System Layer** capabilities define runtime, API, security, and platform se | Field | Required | Description | |-------|----------|-------------| -| `version` | ✅ | ObjectOS kernel version (e.g., `"1.0.0"`) | +| `version` | ✅ | ObjectStack kernel version (e.g., `"1.0.0"`) | | `environment` | ✅ | Runtime environment (`development`, `test`, `staging`, `production`) | ### API Surface @@ -529,6 +529,6 @@ export function SemanticSearch() { /* ... */ } - [ObjectQL Reference](/docs/protocol/objectql) - [ObjectUI Reference](/docs/protocol/objectui) -- [ObjectOS Reference](/docs/protocol/objectos) +- [ObjectStack Reference](/docs/protocol/objectos) - [API Discovery](/docs/references/api/discovery) - [Driver Capabilities](/docs/references/data/driver) diff --git a/content/docs/releases/implementation-status.mdx b/content/docs/releases/implementation-status.mdx index 4a3441f393..362461ed92 100644 --- a/content/docs/releases/implementation-status.mdx +++ b/content/docs/releases/implementation-status.mdx @@ -25,7 +25,7 @@ This matrix is generated from actual codebase analysis and represents the curren --- -## Core Infrastructure (ObjectOS) +## Core Infrastructure (Kernel) ### Runtime & Kernel @@ -65,12 +65,12 @@ This matrix is generated from actual codebase analysis and represents the curren ### Metadata Framework -**Runtime Boundary** — ObjectOS metadata is file/artifact-backed and read-only at boot. Database-backed metadata persistence exists for explicitly configured control-plane services, not as an automatic ObjectOS project-DB bridge. +**Runtime Boundary** — runtime metadata is file/artifact-backed and read-only at boot. Database-backed metadata persistence exists for explicitly configured control-plane services, not as an automatic runtime project-DB bridge. - Metadata API (list types, list items, get item) is fully functional - Metadata is loaded from config files or `dist/objectstack.json` at startup and held in memory -- `MetadataPlugin` no longer registers `sys_metadata` / `sys_metadata_history` into ObjectOS or auto-bridges ObjectQL to `DatabaseLoader` +- `MetadataPlugin` no longer registers `sys_metadata` / `sys_metadata_history` into the runtime or auto-bridges ObjectQL to `DatabaseLoader` - Future: production Artifact API loader and durable local artifact cache ### System Services diff --git a/packages/spec/prompts/architecture.md b/packages/spec/prompts/architecture.md index 59c23159c9..52c35ee3c4 100644 --- a/packages/spec/prompts/architecture.md +++ b/packages/spec/prompts/architecture.md @@ -33,7 +33,7 @@ Reflects the strategy: Technology (Platform) vs. Service (Enterprise). Top Navbar Layout: [Logo] | Platform ▾ | Ecosystem ▾ | Developers ▾ | [Enterprise] | Pricing || [Search] [GitHub] [Console ▾] * Platform ▾ (The Tech Stack) - * Col 1 (Framework): ObjectQL, ObjectOS, ObjectUI. + * Col 1 (Framework): ObjectQL, Kernel, ObjectUI. * Col 2 (Tools): Object Studio (Highlight: Local-First IDE), ObjectCloud, CLI. * Footer: "Community vs. Enterprise Edition →" * Ecosystem ▾ (The Connections) diff --git a/packages/spec/prompts/implement-objectos.md b/packages/spec/prompts/implement-objectos.md index b85373ce92..271ab60e20 100644 --- a/packages/spec/prompts/implement-objectos.md +++ b/packages/spec/prompts/implement-objectos.md @@ -1,4 +1,4 @@ -# ObjectOS Implementation Agent +# ObjectStack Runtime Implementation Agent **Role:** You are the System Architect building the `objectos` runtime kernel. **Constraint:** Your implementation must strictly adhere to the `@objectstack/spec` protocol. diff --git a/packages/spec/prompts/instructions.md b/packages/spec/prompts/instructions.md index 403de3b8ea..4507854ea4 100644 --- a/packages/spec/prompts/instructions.md +++ b/packages/spec/prompts/instructions.md @@ -78,8 +78,8 @@ export const FieldSchema = z.object({ * `packages/spec/src/data/`: ObjectQL (Object, Query, Driver). * `packages/spec/src/ai/`: ObjectQL (Agent, RAG, Orchestration). * `packages/spec/src/ui/`: ObjectUI (App, View, Action). -* `packages/spec/src/system/`: ObjectOS (Manifest, Identity, Events). -* `packages/spec/src/api/`: ObjectOS (Contract, Endpoint, Realtime). +* `packages/spec/src/system/`: System (Manifest, Identity, Events). +* `packages/spec/src/api/`: API (Contract, Endpoint, Realtime). --- diff --git a/skills/objectstack-platform/SKILL.md b/skills/objectstack-platform/SKILL.md index 258a86e2ae..6634608857 100644 --- a/skills/objectstack-platform/SKILL.md +++ b/skills/objectstack-platform/SKILL.md @@ -258,7 +258,7 @@ export default defineStack({ ... }, { strict: false }); ### Compile Artifact and Runtime Metadata Boundary -ObjectOS runtime metadata must come from source files during local development or +ObjectStack runtime metadata must come from source files during local development or from a compiled artifact. Do not configure a project runtime to read or write metadata through its business database. @@ -274,7 +274,7 @@ Runtime rule of thumb: | Context | Metadata source | Database role | |:--------|:----------------|:--------------| | Local dev | TS files or `dist/objectstack.json` | Business rows only | -| Production ObjectOS | Artifact API response | Business rows only | +| Production runtime | Artifact API response | Business rows only | | Control plane | Published JSON in metadata storage | Project revisions, history, overlays | When generating `objectstack.config.ts`, keep object names short and @@ -973,10 +973,10 @@ describe('AuditPlugin', () => { ## MetadataPlugin Runtime Boundary -`MetadataPlugin` is the `IMetadataService` provider for ObjectOS, but runtime +`MetadataPlugin` is the `IMetadataService` provider for the ObjectStack runtime, but runtime metadata is read-only and artifact/file backed: -- Do **not** register `sys_metadata` or `sys_metadata_history` from an ObjectOS +- Do **not** register `sys_metadata` or `sys_metadata_history` from an ObjectStack runtime plugin. Those persistence tables belong to the control plane. (Exception, #1826: an *isolated project kernel* may opt into `sys_metadata` hydration from its own DB — the general boundary otherwise stands.) From 1cd0e7299fb8c7995225a955bcceddb527655111 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 15 Jul 2026 09:39:42 +0000 Subject: [PATCH 6/6] chore: add patch changeset for spec prompts layer-naming change packages/spec publishes prompts/ in the npm package, so the layer-naming alignment there is a published-content change. Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_0162o68e5w3bpUBEVRQboUGG --- .changeset/retire-objectos-layer-naming.md | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 .changeset/retire-objectos-layer-naming.md diff --git a/.changeset/retire-objectos-layer-naming.md b/.changeset/retire-objectos-layer-naming.md new file mode 100644 index 0000000000..a3f53f6203 --- /dev/null +++ b/.changeset/retire-objectos-layer-naming.md @@ -0,0 +1,5 @@ +--- +"@objectstack/spec": patch +--- + +Retire "ObjectOS" as the control-layer name in the published agent prompts (`prompts/`): the open control layer is now called the **Kernel**; **ObjectOS** exclusively names the commercial runtime environment. Layer vocabulary is now ObjectQL (data) / Kernel (control) / ObjectUI (view). Prompt text only — no schema changes.