objectstack-ai · hotlong · Sep 28, 2026 · Sep 27, 2026 · Sep 27, 2026 · Sep 27, 2026
diff --git a/content/docs/api/declarative-endpoints.mdx b/content/docs/api/declarative-endpoints.mdx
@@ -1,7 +1,7 @@
 ---
 title: Custom endpoints declared as metadata
 navTitle: Declarative Endpoints
-description: "Expose your app to systems outside the platform by declaring an apis: endpoint as metadata — which channel to pick, the four publish gates, and the obligation that comes with an anonymous endpoint."
+description: "Expose your app to outside systems by declaring an apis: endpoint as metadata — pick the channel, pass the four publish gates, secure anonymous calls."
 ---
 
 A stack can publish an HTTP endpoint as **metadata** instead of writing a handler: a URL,

diff --git a/content/docs/api/plugin-endpoints.mdx b/content/docs/api/plugin-endpoints.mdx
@@ -1,7 +1,7 @@
 ---
 title: Plugin endpoints — add routes from a plugin
 navTitle: Plugin Endpoints
-description: REST endpoints that become available when the corresponding plugin is installed — auth, workflow, automation, views, realtime, notifications, AI, i18n, and file storage.
+description: REST endpoints each installed plugin adds — auth, workflow, automation, views, realtime, notifications, AI, i18n and files — and how to discover them.
 ---
 
 These REST endpoints are only available when the corresponding plugin is installed. Check the [discovery manifest](/docs/api#discovery) `services` map before calling them; all paths are relative to the base URL (defaults to `/api/v1`).

diff --git a/content/docs/automation/approvals.mdx b/content/docs/automation/approvals.mdx
@@ -1,7 +1,7 @@
 ---
 title: Approval chains — multi-step sign-off rules
 navTitle: Approval workflow
-description: Route a record for sign-off — who can configure the automation, and the run-identity decision that keeps an approval flow from quietly bypassing row-level security.
+description: Route a record for sign-off with an approval flow — who may configure it, and the run-identity choice that keeps it from bypassing row-level security.
 ---
 
 ## Scenario

diff --git a/content/docs/automation/connectors.mdx b/content/docs/automation/connectors.mdx
@@ -1,7 +1,7 @@
 ---
 title: Connectors — call external systems safely
 navTitle: Connectors
-description: Call external systems from flows — plugin-registered connectors, and declarative provider-bound instances (rest / openapi / mcp) authored as pure metadata with reference-based credentials.
+description: Call external systems from flows with plugin connectors or declarative rest, openapi and mcp instances — pure metadata with reference-based credentials.
 ---
 
 > **Status:** Shipped · **Audience:** App authors (human and AI), integration

diff --git a/content/docs/capabilities/index.mdx b/content/docs/capabilities/index.mdx
@@ -1,7 +1,7 @@
 ---
 title: What can it do? — the capability overview
 navTitle: What Can It Do?
-description: The platform's capabilities in business language — data, views, automation, approvals, permissions, analytics, AI, integrations — each with a real CRM as the running example
+description: What the platform can do, in business language — data, views, automation, approvals, permissions, analytics, AI and integrations, shown on a real CRM.
 ---
 
 

diff --git a/content/docs/concepts/metadata-lifecycle.mdx b/content/docs/concepts/metadata-lifecycle.mdx
@@ -1,7 +1,7 @@
 ---
 title: Metadata lifecycle — load, publish and HMR
 navTitle: Metadata Lifecycle & HMR
-description: How metadata flows through Repository → Change Log → Cache → Registry — the canonical event stream that powers Studio HMR, REST writes, and future cloud editing.
+description: How metadata flows through Repository, Change Log, Cache and Registry — the event stream behind Studio hot reload, REST writes and cloud editing.
 ---
 
 This page documents the metadata data path introduced by [ADR-0008](https://github.com/objectstack-ai/objectstack/blob/main/docs/adr/0008-metadata-repository-and-change-log.md) and refined by [ADR-0005](https://github.com/objectstack-ai/objectstack/blob/main/docs/adr/0005-metadata-customization-overlay.md). It is the canonical event stream that powers Studio Hot Module Replacement (HMR), REST writes, and future cloud editing.

diff --git a/content/docs/concepts/north-star.mdx b/content/docs/concepts/north-star.mdx
@@ -1,7 +1,7 @@
 ---
 title: North star — why this framework exists
 navTitle: North Star
-description: ObjectStack's current product and architecture direction.
+description: "Where ObjectStack is headed: a metadata-native backend that humans and AI agents can both operate safely — its principles, runtime shape and non-goals."
 ---
 
 ObjectStack is the metadata-native backend for business software that humans and

diff --git a/content/docs/data-modeling/drivers.mdx b/content/docs/data-modeling/drivers.mdx
@@ -1,7 +1,7 @@
 ---
 title: Database drivers — Postgres, MySQL, Mongo
 navTitle: Database Drivers
-description: Configuration reference for supported database drivers
+description: Connect ObjectStack to PostgreSQL, MySQL, SQLite, MongoDB, Turso or memory — URL-based driver inference, per-driver config keys and dialect caveats.
 ---
 
 ObjectStack supports multiple database backends through a unified driver interface.

diff --git a/content/docs/deployment/index.mdx b/content/docs/deployment/index.mdx
@@ -1,7 +1,7 @@
 ---
 title: Deployment — ship a runtime to production
 navTitle: Deployment Overview
-description: Two things deploy on this platform and they move on separate clocks — the platform runtime you operate, and the metadata app you build. Which one you are doing decides which pages in this section are yours.
+description: Deploy the platform runtime or ship your metadata app — two things on separate clocks. Find out which one you are doing and which pages cover it.
 ---
 
 Two different things get deployed here, and they run on **separate clocks**:

diff --git a/content/docs/deployment/publish-and-preview.mdx b/content/docs/deployment/publish-and-preview.mdx
@@ -1,7 +1,7 @@
 ---
 title: Publish, versioning and preview builds
 navTitle: Publish, Versioning & Preview
-description: A metadata app is versioned in your catalog while the platform moves on its own release train. Compile the app into an artifact, then pick how it reaches a running platform — installed from the catalog, or pinned as the runtime's boot artifact.
+description: Compile a metadata app into a versioned artifact, then install it from the catalog or pin it as the runtime's boot artifact to preview and publish.
 ---
 
 ## Your app and the platform move on separate clocks

diff --git a/content/docs/deployment/seed-tenancy-repair.mdx b/content/docs/deployment/seed-tenancy-repair.mdx
@@ -1,7 +1,7 @@
 ---
 title: Repair seed tenancy after a bad import
 navTitle: Seed Tenancy Repair
-description: The automatic repair that stamps organization_id on untenanted seed rows and merges the __global__ autonumber counter — when it runs, what it changes, what it deliberately leaves alone, and the manual remedy for a multi-organization install.
+description: The automatic repair that stamps organization_id on untenanted seed rows — when it runs, what it changes, and the manual fix for multi-org installs.
 ---
 
 ObjectStack ships one repair that **rewrites stored rows without an operator

diff --git a/content/docs/deployment/self-hosting.mdx b/content/docs/deployment/self-hosting.mdx
@@ -1,7 +1,7 @@
 ---
 title: Self-hosting — run your own deployment
 navTitle: Self-Hosted Deployment
-description: Run a compiled ObjectStack app on your own infrastructure with the official Docker image — plus Compose with Postgres, Kubernetes, and the bare Node.js fallback, including health checks, reverse-proxy wiring, and the secrets you must pin.
+description: Run a compiled ObjectStack app on your own servers with the official Docker image, Compose and Postgres, or Kubernetes — health checks and secrets too.
 ---
 
 This guide takes the artifact produced by `os build` / `os compile` and runs it

diff --git a/content/docs/deployment/tenancy-modes.mdx b/content/docs/deployment/tenancy-modes.mdx
@@ -1,7 +1,7 @@
 ---
 title: Tenancy postures and membership models
 navTitle: Tenancy Postures & Membership
-description: The three tenancy postures (single / group / isolated), how OS_TENANCY_POSTURE resolves, the membership policy for new users, and the degraded-tenancy boot guard.
+description: "Choose single, group or isolated tenancy: how OS_TENANCY_POSTURE resolves, the membership policy for new users, and the degraded-tenancy boot guard."
 ---
 
 An ObjectStack deployment runs in one of **three tenancy postures**. The posture

diff --git a/content/docs/getting-started/build-with-claude-code.mdx b/content/docs/getting-started/build-with-claude-code.mdx
@@ -1,7 +1,7 @@
 ---
 title: Build an app with Claude Code, step by step
 navTitle: Build with Claude Code
-description: The core ObjectStack workflow — Claude Code authors the metadata, you verify in the visual Console, guardrails catch mistakes, and the app you build is itself AI-operable over MCP.
+description: "Build an ObjectStack app with Claude Code: the AI writes the metadata, you verify it in the Console, guardrails catch mistakes, and the app speaks MCP."
 ---
 
 This is the **main way you build on ObjectStack**: you describe what you want in

diff --git a/content/docs/getting-started/how-ai-development-works.mdx b/content/docs/getting-started/how-ai-development-works.mdx
@@ -1,7 +1,7 @@
 ---
 title: How AI-written app development works
 navTitle: How AI Development Works
-description: The division of labor behind ObjectStack — AI authors the typed metadata, you verify in the visual UI, and layered guardrails keep the AI from shipping mistakes.
+description: "How building with ObjectStack splits the work: AI writes the typed metadata, you verify it in the visual UI, and layered guardrails stop its mistakes."
 ---
 
 ObjectStack is built for a specific way of working: **an AI agent writes the

diff --git a/content/docs/getting-started/quick-reference.mdx b/content/docs/getting-started/quick-reference.mdx
@@ -1,7 +1,7 @@
 ---
 title: Quick reference — every metadata type
 navTitle: Quick Reference Guide
-description: Fast lookup table for all ObjectStack protocols
+description: Look up any ObjectStack metadata type fast — the key schemas of every protocol category on one page, with common patterns and search tips.
 ---
 
 

diff --git a/content/docs/getting-started/your-first-project.mdx b/content/docs/getting-started/your-first-project.mdx
@@ -1,7 +1,7 @@
 ---
 title: Your first project — from zero to running
 navTitle: Your First Project
-description: Scaffold a standalone ObjectStack project with npm, understand what was generated, extend the data model, call the REST API, and build a deployable artifact — no monorepo checkout, no AI agent required.
+description: Scaffold a standalone ObjectStack project with npm, extend the data model, call the REST API and build a deployable artifact — no AI agent required.
 ---
 
 This is the hands-on path for developers building **on** ObjectStack from the

diff --git a/content/docs/index.mdx b/content/docs/index.mdx
@@ -1,6 +1,6 @@
 ---
 title: Documentation — build apps from metadata
-description: Technical documentation for ObjectStack.
+description: "ObjectStack documentation: build business apps from typed metadata that AI agents write and humans verify — start here for guides, concepts and APIs."
 ---
 
 ## ObjectStack Documentation

diff --git a/content/docs/kernel/architecture.mdx b/content/docs/kernel/architecture.mdx
@@ -1,7 +1,7 @@
 ---
 title: Core architecture — kernel and services
 navTitle: Architecture
-description: Deep dive into the ObjectKernel architecture
+description: "How the ObjectKernel boots and runs: its core architecture, the plugin bootstrap lifecycle, and the public kernel API you call from a plugin."
 ---
 
 ## Core Architecture

diff --git a/content/docs/kernel/events.mdx b/content/docs/kernel/events.mdx
@@ -1,7 +1,7 @@
 ---
 title: Kernel events and hooks — the full list
 navTitle: Events & Hooks
-description: System-wide event bus for loose coupling between plugins
+description: Every kernel lifecycle hook and data lifecycle hook in ObjectStack — when each fires, its payload and ordering, and which of the two systems to pick.
 ---
 
 ObjectStack has **two distinct hook systems**. They look similar but use different APIs, payloads, ordering, and error semantics — pick the right one for the job:

diff --git a/content/docs/kernel/runtime-services/email-service.mdx b/content/docs/kernel/runtime-services/email-service.mdx
@@ -1,7 +1,7 @@
 ---
 title: services.email — the outbound mail API
 navTitle: services.email
-description: Outbound email delivery and template rendering APIs.
+description: Send email from a plugin or flow with services.email — send() and sendTemplate(), the result they return, and the typed error codes to handle.
 ---
 
 - **Stability:** `stable`

diff --git a/content/docs/kernel/runtime-services/queue-service.mdx b/content/docs/kernel/runtime-services/queue-service.mdx
@@ -1,7 +1,7 @@
 ---
 title: services.queue — the job queue service API
 navTitle: services.queue
-description: Async queue publish/subscribe and DLQ operations.
+description: Publish and subscribe to async job queues with services.queue — queue size, purge, and dead-letter listing, replay and cleanup for failed messages.
 ---
 
 - **Stability:** `stable`

diff --git a/content/docs/kernel/runtime-services/sharing-service.mdx b/content/docs/kernel/runtime-services/sharing-service.mdx
@@ -1,7 +1,7 @@
 ---
 title: services.sharing — the record share API
 navTitle: services.sharing
-description: Record-level sharing and editability checks.
+description: Check and manage record-level sharing with services.sharing — read filters, canEdit and canDelete checks, and granting or revoking record shares.
 ---
 
 - **Stability:** `stable`

diff --git a/content/docs/kernel/services.mdx b/content/docs/kernel/services.mdx
@@ -1,7 +1,7 @@
 ---
 title: Service registry — resolve and override
 navTitle: Service Registry
-description: Dependency Injection mechanism for loose coupling between plugins
+description: How plugins expose and consume services in ObjectStack — register a service, resolve it by name, see the standard services, and replace a core one.
 ---
 
 ObjectStack uses a lightweight **Service Locator pattern** for Dependency Injection. Services are the primary way plugins expose and consume functionality.

diff --git a/content/docs/permissions/access-recipes.mdx b/content/docs/permissions/access-recipes.mdx
@@ -1,7 +1,7 @@
 ---
 title: Access recipes — data, automation and UI
 navTitle: Who can see data / automation / interface
-description: Map a concrete access requirement onto the platform's layers — object CRUD, field-level security, row-level security, capabilities, app/nav gating, and the run-identity of automations.
+description: Map a real access requirement onto the right layer — object CRUD, field-level and row-level security, capabilities, navigation gating and automations.
 ---
 
 ## Scenario

diff --git a/content/docs/permissions/administrator-guide.mdx b/content/docs/permissions/administrator-guide.mdx
@@ -1,7 +1,7 @@
 ---
 title: Administrator guide to permissions and access
 navTitle: Administrator Guide
-description: The task-first operations manual for customer system administrators — onboard a tenant in four steps (build the org tree, add people, assign positions, verify), with the 90% rule — daily administration is assigning positions; the capability plumbing ships built-in.
+description: "The permissions manual for tenant administrators: onboard a tenant in four steps, then run daily access by assigning positions — no plumbing needed."
 ---
 
 You are the **system administrator** of an ObjectStack tenant. You opened

diff --git a/content/docs/permissions/attachments-access.mdx b/content/docs/permissions/attachments-access.mdx
@@ -1,7 +1,7 @@
 ---
 title: Attachment access — who can read a file
 navTitle: Attachments Access
-description: How access to record attachments is decided — the parent-derived read/create/delete model, authenticated downloads, the enable.files opt-in gate, and the storage-byte lifecycle. Covers sys_attachment and sys_file.
+description: "Who can read, upload or delete a record's attachments: the parent-derived access model, authenticated downloads, the enable.files gate and file cleanup."
 ---
 
 The generic **Attachments** surface (Salesforce "Notes & Attachments" parity)

diff --git a/content/docs/permissions/authorization.mdx b/content/docs/permissions/authorization.mdx
@@ -1,7 +1,7 @@
 ---
 title: Authorization architecture — how it decides
 navTitle: Authorization Architecture
-description: The one-page map of ObjectStack authorization — the enforcement chain, combination semantics, package provenance, lifecycle coverage, and the CI governance — with its limits — behind "declared" equals "enforced". Stitches ADR-0049/0054/0056/0057/0066/0068/0069/0078/0086 into a single narrative.
+description: One-page map of ObjectStack authorization — the enforcement chain, how grants combine, package provenance, lifecycle coverage and the CI checks behind it.
 ---
 
 This page is the consolidated overview of how authorization works across the

diff --git a/content/docs/permissions/capabilities.mdx b/content/docs/permissions/capabilities.mdx
@@ -1,7 +1,7 @@
 ---
 title: "Declaring capabilities in a permission set"
 navTitle: "Declaring Capabilities"
-description: "How a package DEFINES an authorization capability with defineCapability — the declaration half of ADR-0066 D1 — and how that name travels from source to the sys_capability catalogue to a permission-set grant to a requiredPermissions check."
+description: "Define an authorization capability in a package with defineCapability, then follow it into the catalogue, a permission-set grant and a runtime check."
 ---
 
 Every other page in this module is about **consuming** a capability: granting

diff --git a/content/docs/permissions/delegated-administration.mdx b/content/docs/permissions/delegated-administration.mdx
@@ -1,7 +1,7 @@
 ---
 title: Delegated administration — scoped admin rights
 navTitle: Delegated Administration
-description: Administration itself as a scoped grant — a business-unit subtree, an action set, and an assignable-set allowlist, with self-escalation structurally impossible (ADR-0090 D12).
+description: "Hand out scoped admin rights: a business-unit subtree, an action set and an assignable-set allowlist, with self-escalation structurally impossible."
 ---
 
 A group with fifty subsidiaries cannot manage every grant from headquarters —

diff --git a/content/docs/permissions/index.mdx b/content/docs/permissions/index.mdx
@@ -1,7 +1,7 @@
 ---
 title: "Permissions and identity — the overview"
 navTitle: "Permissions & Identity"
-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."
+description: "Authentication, authorization, and record- and field-level access control in ObjectStack — declared as security metadata and enforced by the runtime."
 ---
 
 This module covers authentication, authorization, and record- and field-level

diff --git a/content/docs/permissions/permission-sets.mdx b/content/docs/permissions/permission-sets.mdx
@@ -1,7 +1,7 @@
 ---
 title: "Permission sets — grant access in bundles"
 navTitle: "Permission Sets"
-description: "The only capability container — object CRUD + FLS + scope depth + capabilities, union-merged across everything a user holds. Covers the built-in sets, assignment tables, access depth, the isDefault suggestion, and delegated-admin scopes."
+description: "Permission sets are the only capability container: object CRUD, field security, scope depth and capabilities, union-merged across what a user holds."
 ---
 
 A **permission set** is the *only* capability container in the platform

diff --git a/content/docs/permissions/permissions-matrix.mdx b/content/docs/permissions/permissions-matrix.mdx
@@ -1,7 +1,7 @@
 ---
 title: Security permissions matrix reference
 navTitle: Security Permissions Matrix
-description: Visual reference for ObjectStack's security model — permission types, the object × permission-set matrix, field-level security, sharing rules, business-unit depth, and the access-matrix snapshot gate
+description: Visual reference for ObjectStack security — permission types, the object × permission-set matrix, field security, sharing rules and business-unit depth.
 ---
 
 This page provides a comprehensive visual reference for ObjectStack's security model — from object-level permissions to field-level security, sharing rules, and business-unit depth.

diff --git a/content/docs/permissions/positions.mdx b/content/docs/permissions/positions.mdx
@@ -1,7 +1,7 @@
 ---
 title: "Positions — org hierarchy for sharing"
 navTitle: "Positions"
-description: "Positions (岗位) are flat capability-distribution groups — users hold positions, positions bind permission sets. The visibility hierarchy lives on business units, never here. Includes the built-in identity positions and the everyone/guest audience anchors."
+description: "Positions are flat groups that hand permission sets to users — the built-in identity positions, the everyone and guest anchors, and where hierarchy lives."
 ---
 
 A **position** (岗位) is a named, assignable distribution group: users hold

diff --git a/content/docs/permissions/profiles.mdx b/content/docs/permissions/profiles.mdx
@@ -1,7 +1,7 @@
 ---
 title: "Profiles (removed) — use permission sets"
 navTitle: "Profiles (removed)"
-description: "The Profile concept was removed by ADR-0090 D2. Baseline access is now authored with the everyone audience anchor, package isDefault suggestions, and ordinary permission sets distributed via positions."
+description: "Profiles were removed. Author baseline access with the everyone audience anchor, package isDefault suggestions and permission sets given via positions."
 ---
 
 ## Profiles — removed (ADR-0090 D2)

diff --git a/content/docs/permissions/record-view-auditing.mdx b/content/docs/permissions/record-view-auditing.mdx
@@ -1,7 +1,7 @@
 ---
 title: Record view auditing — who read what
 navTitle: Record-View Auditing
-description: "Who viewed this record, and when — the `read` action in sys_audit_log: its per-object opt-in, the four edges of its scope, and what a view row deliberately does not carry."
+description: "Find out who viewed a record and when: the read action in sys_audit_log, its per-object opt-in, the edges of its scope and what a view row leaves out."
 ---
 
 Every other layer in this module answers *who is allowed to see this record*.

diff --git a/content/docs/permissions/sharing-rules.mdx b/content/docs/permissions/sharing-rules.mdx
@@ -1,7 +1,7 @@
 ---
 title: "Sharing rules and organization-wide defaults"
 navTitle: "Sharing Rules"
-description: "Record-level access: the organization-wide default (OWD) baseline per object, the external sharing dial, criteria sharing rules and recipient types, and the RLS-safe analytics read scope."
+description: "Record-level access in ObjectStack: organization-wide defaults per object, the external sharing dial, criteria sharing rules and RLS-safe analytics reads."
 ---
 
 ## Sharing & Organization-Wide Defaults