objectstack-ai · huangyiirene · Aug 26, 2026 · Aug 26, 2026
diff --git a/content/docs/references/api/dispatcher.mdx b/content/docs/references/api/dispatcher.mdx
@@ -5,7 +5,7 @@ description: Dispatcher protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# HttpDispatcher Protocol
+## HttpDispatcher Protocol
 
 Defines how the ObjectStack HttpDispatcher routes incoming API requests
 to the correct kernel service based on URL prefix matching.

diff --git a/content/docs/references/api/package-api.mdx b/content/docs/references/api/package-api.mdx
@@ -5,7 +5,7 @@ description: Package Api protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# Package API Protocol
+## Package API Protocol
 
 REST API endpoint schemas for package lifecycle management.
 

diff --git a/content/docs/references/api/versioning.mdx b/content/docs/references/api/versioning.mdx
@@ -5,7 +5,7 @@ description: Versioning protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# API Versioning Protocol
+## API Versioning Protocol
 
 Defines how API versions are negotiated between client and server.
 Supports multiple versioning strategies and deprecation lifecycle management.

diff --git a/content/docs/references/cloud/app-store.mdx b/content/docs/references/cloud/app-store.mdx
@@ -5,22 +5,22 @@ description: App Store protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# App Store Protocol (Customer Experience)
+## App Store Protocol (Customer Experience)
 
 Defines schemas for the end-customer experience when browsing, evaluating,
 installing, and managing marketplace apps from within ObjectOS.
 
-## Architecture Alignment
+### Architecture Alignment
 - **Salesforce AppExchange (Customer)**: Browse apps, read reviews, 1-click install
 - **Shopify App Store (Merchant)**: App evaluation, trial, install, manage subscriptions
 - **Apple App Store (User)**: Ratings, reviews, featured collections, personalized recs
 
-## Customer Journey
+### Customer Journey
 ```
 Discover → Evaluate → Install → Configure → Use → Rate/Review → Manage
 ```
 
-## Key Concepts
+### Key Concepts
 - **Reviews & Ratings**: User-submitted ratings and reviews with moderation
 - **Collections & Recommendations**: Personalized discovery and curated picks
 - **Subscription Management**: Manage licenses, billing, and renewals

diff --git a/content/docs/references/cloud/developer-portal.mdx b/content/docs/references/cloud/developer-portal.mdx
@@ -5,7 +5,7 @@ description: Developer Portal protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# Developer Portal Protocol
+## Developer Portal Protocol
 
 Defines schemas for the developer-facing side of the marketplace ecosystem.
 Covers the complete developer journey:
@@ -14,12 +14,12 @@ Covers the complete developer journey:
 Register → Create App → Develop → Validate → Build → Submit → Monitor → Iterate
 ```
 
-## Architecture Alignment
+### Architecture Alignment
 - **Salesforce Partner Portal**: ISV registration, AppExchange publishing, Trialforce
 - **Shopify Partner Dashboard**: App management, analytics, billing
 - **VS Code Marketplace Management**: Extension publishing, statistics, tokens
 
-## Identity Integration (better-auth)
+### Identity Integration (better-auth)
 Authentication, organization management, and API keys are handled by the
 Identity module (`@objectstack/spec` Identity namespace), which follows the
 better-auth specification. This module only defines marketplace-specific
@@ -35,7 +35,7 @@ extensions on top of the shared identity layer:
  There is no `Identity.ApiKeySchema` — #8715 retired it (it documented
  better-auth's apiKey plugin, which this platform does not load)
 
-## Key Concepts
+### Key Concepts
 - **Publisher Profile**: Links an Identity Organization to a marketplace publisher
 - **App Listing Management**: CRUD for marketplace listings (draft → published)
 - **Version Channels**: alpha / beta / rc / stable release channels

diff --git a/content/docs/references/cloud/environment-artifact.mdx b/content/docs/references/cloud/environment-artifact.mdx
@@ -5,7 +5,7 @@ description: Environment Artifact protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# Environment Artifact Envelope — re-export (#4740, #4535 C10)
+## Environment Artifact Envelope — re-export (#4740, #4535 C10)
 
 The envelope has exactly ONE declaration:
 `../system/environment-artifact.zod` (maintainer route A′ on #4740 —

diff --git a/content/docs/references/cloud/environment-package.mdx b/content/docs/references/cloud/environment-package.mdx
@@ -5,7 +5,7 @@ description: Environment Package protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# Environment Package Installation Protocol
+## Environment Package Installation Protocol
 
 Models `sys_package_installation` — the pairing between an Environment and
 a specific, immutable `sys_package_version` snapshot.

diff --git a/content/docs/references/cloud/environment.mdx b/content/docs/references/cloud/environment.mdx
@@ -5,7 +5,7 @@ description: Environment protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# Environment Protocol (runtime container)
+## Environment Protocol (runtime container)
 
 An **Environment** is the runtime container of an organization's data.
 It owns a physically isolated database, a canonical hostname, a plan/quota

diff --git a/content/docs/references/cloud/marketplace-admin.mdx b/content/docs/references/cloud/marketplace-admin.mdx
@@ -5,17 +5,17 @@ description: Marketplace Admin protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# Marketplace Administration Protocol
+## Marketplace Administration Protocol
 
 Defines schemas for the platform (Cloud) side of marketplace operations.
 Covers the administrative workflows for managing and governing the marketplace.
 
-## Architecture Alignment
+### Architecture Alignment
 - **Salesforce AppExchange Admin**: Security review, ISV monitoring, partner management
 - **Apple App Store Connect Review**: Human review process, guidelines, rejection reasons
 - **Google Play Console**: Policy enforcement, quality gates, content moderation
 
-## Key Concepts
+### Key Concepts
 - **Review Process**: Structured workflow for submission review (automated + manual)
 - **Curation**: Featured apps, curated collections, editorial picks
 - **Governance**: Policy enforcement, takedown, compliance

diff --git a/content/docs/references/cloud/marketplace.mdx b/content/docs/references/cloud/marketplace.mdx
@@ -5,7 +5,7 @@ description: Marketplace protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# Marketplace Protocol
+## Marketplace Protocol
 
 Defines the core schemas for the plugin marketplace ecosystem, covering:
 - **Developer Side**: Package publishing, submission, and version releases
@@ -14,13 +14,13 @@ Defines the core schemas for the plugin marketplace ecosystem, covering:
 This protocol defines the contract between plugin developers, the marketplace
 platform, and customers who install plugins.
 
-## Architecture Alignment
+### Architecture Alignment
 - **Salesforce AppExchange**: Security review, managed packages, listing profiles
 - **VS Code Marketplace**: Extension publishing, ratings, verified publishers
 - **npm Registry**: Package publishing, versioning, scoped packages
 - **Shopify App Store**: App review process, billing integration, merchant installs
 
-## Developer Publishing Flow
+### Developer Publishing Flow
 ```
 1. Develop → Build the project locally using ObjectStack CLI
 2. Validate → Run `os validate` (schema + security checks)
@@ -30,7 +30,7 @@ platform, and customers who install plugins.
 6. Publish → Approved listing goes live on marketplace
 ```
 
-## Platform Management Flow
+### Platform Management Flow
 ```
 1. Receive → Accept submissions from verified publishers
 2. Scan → Automated security scan and compatibility check

diff --git a/content/docs/references/data/context-tokens.mdx b/content/docs/references/data/context-tokens.mdx
@@ -8,7 +8,7 @@ description: Context Tokens protocol schemas
 Context Tokens — the declarative placeholders that resolve against the
 **caller's session** (who am I, which org am I in) rather than the clock.
 
-# Why this lives in `spec`
+## Why this lives in `spec`
 
 These are the sibling vocabulary to `{date-macros}`. Filter values in
 dashboards, views, reports and pages travel as JSON, so a user-scoped
@@ -38,7 +38,7 @@ neither is an ERROR, not a null comparand: resolving to `null`
 degrades to `IS NULL` on most drivers and would hand back the rows
 the filter was written to exclude.
 
-# Presentation scope, NOT a security boundary
+## Presentation scope, NOT a security boundary
 
 This is the single most important thing to understand about these
 tokens. `{current_user_id}` scopes what a surface *shows*; it does not
@@ -60,7 +60,7 @@ Never reach for a context token to keep a user away from data. Removing
 a `{current_user_id}` filter widens a *view*; it must never widen
 *access*.
 
-# Where the tokens are honoured
+## Where the tokens are honoured
 
 Filter values on every surface that resolves placeholders — object list
 views, dashboard widgets, reports, SDUI page components. Navigation
@@ -69,7 +69,7 @@ such as `{active_package}`; those are nav-only and are NOT valid inside
 filter values, because filters are not evaluated with the sidebar's
 selector state.
 
-# Out of scope
+## Out of scope
 
 - `current_user.*` RLS expressions — see `@objectstack/plugin-security`.
 - `{date-macros}` — the clock-based sibling; see `./date-macros.zod.ts`.

diff --git a/content/docs/references/data/date-macros.mdx b/content/docs/references/data/date-macros.mdx
@@ -8,7 +8,7 @@ description: Date Macros protocol schemas
 Date Macro Tokens — the declarative placeholders the UI substitutes
 into filter values before sending a query to the data engine.
 
-# Why this lives in `spec`
+## Why this lives in `spec`
 
 Filter values in dashboards, views, reports and pages travel as JSON.
 Because JSON cannot evaluate code, callers cannot write `daysAgo(30)`
@@ -52,7 +52,7 @@ so the **set of recognised tokens is part of the platform contract**
 and must live here next to the rest of the JSON-DSL schemas, not
 inside any single UI implementation.
 
-# Two flavours of token
+## Two flavours of token
 
 1. **Fixed tokens** — small, finite list (`{today}`,
  `{current_quarter_start}`, `{last_year_end}`, …). Enumerated by
@@ -63,7 +63,7 @@ inside any single UI implementation.
  `DATE_MACRO_PARAM_RE`. Units: `minute(s)`, `hour(s)`, `day(s)`,
  `week(s)`, `month(s)`, `year(s)`. Directions: `ago`, `from_now`.
 
-# Out of scope
+## Out of scope
 
 - CEL expressions (`cel\`daysAgo(30)\``) run **server-side** in the
  formula engine. They are unrelated to these placeholders; see

diff --git a/content/docs/references/data/seed-loader.mdx b/content/docs/references/data/seed-loader.mdx
@@ -5,17 +5,17 @@ description: Seed Loader protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# Seed Loader Protocol
+## Seed Loader Protocol
 
 Defines the schemas for metadata-driven seed data loading with automatic
 relationship resolution, dependency ordering, and multi-pass insertion.
 
-## Architecture Alignment
+### Architecture Alignment
 - **Salesforce Data Loader**: External ID-based upsert with relationship resolution
 - **ServiceNow**: Sys ID and display value mapping during import
 - **Airtable**: Linked record resolution via display names
 
-## Loading Flow
+### Loading Flow
 ```
 1. Build object dependency graph from field metadata (lookup/master_detail)
 2. Topological sort → determine insert order (parents before children)

diff --git a/content/docs/references/data/validation.mdx b/content/docs/references/data/validation.mdx
@@ -5,12 +5,12 @@ description: Validation protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# ObjectStack Validation Protocol
+## ObjectStack Validation Protocol
 
 This module defines the validation schema protocol for ObjectStack, providing a comprehensive
 type-safe validation system similar to Salesforce's validation rules but with enhanced capabilities.
 
-## Overview
+### Overview
 
 Validation rules are applied at the data layer to ensure data integrity and enforce business logic.
 A validation rule is a **deterministic, synchronous, side-effect-free predicate over a single
@@ -30,7 +30,7 @@ The system supports these validation types:
 5. **JSON Schema Validation**: Validate a JSON field against a JSON Schema
 6. **Conditional Validation**: Apply a nested rule based on a CEL condition
 
-## Deliberately NOT validation rules
+### Deliberately NOT validation rules
 
 These were once declared here but never enforced. Because the contract above rules them out
 (they need I/O or are client-side concerns), they were removed rather than left as silent
@@ -51,7 +51,7 @@ no-ops. Use the layer that already does each one correctly:
  a `delete` event was a proven silent no-op — the enum value was removed rather than left
  advertised-but-unenforced (#3184; see docs/audits/2026-06-validationschema-property-liveness.md).
 
-## Salesforce Comparison
+### Salesforce Comparison
 
 ObjectStack validation rules are inspired by Salesforce validation rules but enhanced:
 - Salesforce: Formula-based validation with `Error Condition Formula`

diff --git a/content/docs/references/identity/scim.mdx b/content/docs/references/identity/scim.mdx
@@ -5,18 +5,18 @@ description: Scim protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# SCIM 2.0 Protocol Implementation
+## SCIM 2.0 Protocol Implementation
 
 System for Cross-domain Identity Management (SCIM) 2.0 specification
 implementation for ObjectStack.
 
-## Overview
+### Overview
 
 SCIM 2.0 is an HTTP-based protocol for managing user and group identities
 across domains. It provides a standardized REST API for user provisioning,
 de-provisioning, and synchronization.
 
-## Use Cases
+### Use Cases
 
 1. **Enterprise SSO Integration**
  - Integrate with Okta, Azure AD, OneLogin
@@ -38,13 +38,13 @@ de-provisioning, and synchronization.
  - Track all identity changes
  - Meet SOX/HIPAA requirements for user management
 
-## Specification References
+### Specification References
 
 - **RFC 7643**: SCIM Core Schema
 - **RFC 7644**: SCIM Protocol
 - **RFC 7642**: SCIM Requirements
 
-## Industry Implementations
+### Industry Implementations
 
 - **Okta**: Leading SCIM provider
 - **Azure AD**: Microsoft's identity platform

diff --git a/content/docs/references/kernel/cli-extension.mdx b/content/docs/references/kernel/cli-extension.mdx
@@ -5,14 +5,14 @@ description: Cli Extension protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# CLI Extension Protocol
+## CLI Extension Protocol
 
 Defines the contract for plugins that extend the ObjectStack CLI with
 custom commands. This enables third-party packages (e.g., marketplace,
 cloud deployment tools) to register new CLI commands via oclif's
 built-in plugin system.
 
-## How It Works (oclif Plugin Model)
+### How It Works (oclif Plugin Model)
 
 1. **Declare** — Plugin's `package.json` includes an `oclif` config section
  declaring its commands directory and any topics.
@@ -21,7 +21,7 @@ built-in plugin system.
 3. **Load** — oclif automatically discovers and registers all Command classes
  exported from the plugin's commands directory.
 
-## Plugin Package Contract
+### Plugin Package Contract
 
 The plugin must be a valid oclif plugin:
 
@@ -57,7 +57,7 @@ export default class MarketplaceSearch extends Command {
 }
 ```
 
-## Migration from Commander.js
+### Migration from Commander.js
 
 The previous plugin model required `contributes.commands` in the manifest
 and exported Commander.js `Command` instances. The new model uses oclif's

diff --git a/content/docs/references/kernel/cluster.mdx b/content/docs/references/kernel/cluster.mdx
@@ -5,7 +5,7 @@ description: Cluster protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# Cluster Protocol
+## Cluster Protocol
 
 Defines the runtime semantics required for ObjectStack to behave correctly
 when more than one Node.js process is involved. The protocol layer codifies

diff --git a/content/docs/references/kernel/dependency-resolution.mdx b/content/docs/references/kernel/dependency-resolution.mdx
@@ -5,18 +5,18 @@ description: Dependency Resolution protocol schemas
 
 {/* ⚠️ AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
 
-# Dependency Resolution Protocol
+## Dependency Resolution Protocol
 
 Defines schemas for runtime dependency resolution when installing,
 upgrading, or managing packages. Provides a standardized way to
 express dependency conflicts, resolution results, and installation order.
 
-## Architecture Alignment
+### Architecture Alignment
 - **npm**: Dependency tree resolution with conflict detection
 - **Helm**: Dependency management with version constraints
 - **Salesforce**: Package dependency validation at install time
 
-## Resolution Flow
+### Resolution Flow
 ```
 1. Parse manifest.dependencies (SemVer ranges)
 2. Check installed packages registry