docs: retire 'ObjectOS' as the control-layer name — the layer is now 'Kernel'

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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0162o68e5w3bpUBEVRQboUGG

Author: claude

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 |
 
 ---

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:
 
 <p align="center">
-  <img src="docs/screenshots/layers.png" width="900" alt="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">
+  <img src="docs/screenshots/layers.png" width="900" alt="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">
 </p>
 
 See [ARCHITECTURE.md](./ARCHITECTURE.md) for the complete design documentation including the plugin lifecycle state machine, dependency graph, and design decisions.

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):
 

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.
 </Callout>
@@ -32,7 +32,7 @@ machinery underneath.
   <Card
     icon={<Cpu />}
     title="System Protocol"
-    description="ObjectOS: Control, runtime, and governance."
+    description="Kernel: Control, runtime, and governance."
   />
   <Card
     icon={<Workflow />}
@@ -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)

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:

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.

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
 

content/docs/index.mdx

@@ -45,13 +45,13 @@ Each module documents one capability in depth — overview first, then guides, w
   <Card href="/docs/api" title="API & SDK" description="Generated REST, realtime, and client SDK surfaces" />
   <Card href="/docs/ai" title="AI" description="Agents, actions as tools, RAG, and natural-language queries" />
   <Card href="/docs/plugins" title="Plugins & Packages" description="Extend the runtime and package your extensions" />
-  <Card href="/docs/kernel" title="Kernel & Services" description="The ObjectOS runtime, service registry, and services.* APIs" />
+  <Card href="/docs/kernel" title="Kernel & Services" description="The ObjectStack runtime, service registry, and services.* APIs" />
   <Card href="/docs/deployment" title="Deployment & Operations" description="Deployment modes, environments, publishing, and troubleshooting" />
 </Cards>
 
 ## 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

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

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