feat: Add security and system protocol schemas

- Introduced sharing.mdx for Organization-Wide Defaults and sharing rules.
- Added territory.mdx for Territory Management Protocol and its schemas.
- Created auth-config.mdx for Better-Auth Configuration Protocol.
- Implemented metadata-persistence.mdx for Metadata Persistence protocol schemas.
- Developed migration.mdx for Migration protocol schemas.
- Established service-registry.mdx for Service Registry protocol schemas.
- Launched worker.mdx for Worker System Protocol with task processing features.

Author: hotlong

.gitignore

@@ -71,4 +71,3 @@ next-env.d.ts
 .source/
 apps/*/. source/
 apps/*/.next/docs/
-docs/

PLANNING.md

@@ -0,0 +1,100 @@
+# ObjectStack Project Master Plan & Status Report
+
+**Date:** 2026-02-05
+**Version:** 1.0.0
+
+## 1. Project Master Scheme (项目总体方案)
+
+ObjectStack is designed as a **metadata-driven, post-SaaS operating system**. It virtualizes the application stack into strict Zod protocols, allowing business logic, UI, and data structures to be defined as code and executed by a universal runtime.
+
+### 1.1 Architectural Layers
+
+1.  **Protocol Layer (`@objectstack/spec`)**
+    *   **Role:** The "DNA" of the system.
+    *   **Technology:** Pure TypeScript + Zod.
+    *   **Status:** **Complete**. Covers UI, Data, Security, Automation, AI, System.
+
+2.  **Kernel Layer (`@objectstack/core`)**
+    *   **Role:** The Microkernel. Handles plugin lifecycle, dependency injection, event bus, and logging.
+    *   **Status:** **Stable**.
+
+3.  **Engine Layer**
+    *   **ObjectQL (`@objectstack/objectql`)**: Universal data access abstraction.
+    *   **Runtime (`@objectstack/runtime`)**: The execution brain. Contains the `HttpDispatcher` which unifies request handling.
+    *   **Status:** **Stable (Memory-only)**.
+
+4.  **Interface Layer (Adapters & Plugins)**
+    *   **Server**: `@objectstack/plugin-hono-server` (Production HTTP), `@objectstack/adapter-nextjs` (Frontend Backend).
+    *   **Client**: `@objectstack/plugin-msw` (Browser Mocking), `@objectstack/client` (SDK).
+    *   **Status:** **Unified Architecture Implemented**.
+
+5.  **Infrastructure Layer (Drivers)**
+    *   **Data**: `driver-memory` (Dev/Test), `driver-sqlite` (Local), `driver-postgres` (Scale).
+    *   **Status:** **Partial** (Memory only).
+
+---
+
+## 2. Current Development Progress (当前开发进度)
+
+### ✅ Completed Milestones
+
+*   **Protocol Definition:** All major protocols (UI, Data, API, security) are defined in Zod.
+*   **Unified Dispatcher Architecture:**
+    *   Refactored `plugin-hono-server` to use `@objectstack/hono` factory.
+    *   Refactored `plugin-msw` to use shared `HttpDispatcher`.
+    *   **Result:** The mock server now behaves identically to the production server.
+*   **CI/CD Stabilization:**
+    *   Fixed build and test pipelines for the monorepo.
+    *   Resolved integration test environment issues (skipping live-server tests in CI).
+*   **Documentation:**
+    *   Updated `packages.mdx` with correct plugin architecture descriptions.
+
+### 🚧 Works in Progress
+
+*   **Client SDK**: Basic structure exists, but needs stronger typing inference from Zod schemas.
+*   **React Components**: `@objectstack/client-react` exists but is minimal.
+
+---
+
+## 3. Next Development Roadmap (下一步开发计划)
+
+The immediate focus shifts from **Architecture/Kernel** stability to **Feature/Persistence** implementation.
+
+### Phase 1: Persistence Strategy (Week 1-2)
+**Objective:** Move beyond in-memory data to persistent storage.
+1.  **Create `@objectstack/driver-sqlite`**:
+    *   Implement `ObjectStackDriver` interface.
+    *   Target: `better-sqlite3` for fast local development.
+    *   Compliance: Pass the standard `driver-test-suite` (which runs on memory driver currently).
+2.  **Create `@objectstack/driver-postgres`**:
+    *   Target: `pg` or `postgres.js`.
+    *   Support JSONB for flexible metadata storage.
+
+### Phase 2: Metadata UI Engine (Week 3-4)
+**Objective:** Render UI directly from Zod Protocol definitions.
+1.  **Enhance `@objectstack/client-react`**:
+    *   Implement `useObject(objectName)` hook.
+    *   Implement `useView(viewName)` hook.
+2.  **Dynamic Form Builder**:
+    *   Create a component that takes a `ZodSchema` or Field Protocol and renders a form.
+    *   Support `auto-layout` based on field types.
+
+### Phase 3: Automation Runtime (Week 5-6)
+**Objective:** Make the system "Active".
+1.  **Implement `@objectstack/plugin-automation`**:
+    *   **Triggers:** Listen to `data:create`, `data:update` events.
+    *   **Flow Engine:** Interpreter for `src/automation/flow.zod.ts`.
+    *   **Actions:** Execute server-side logic defined in metadata.
+
+### Phase 4: AI Agent Integration (Week 7+)
+**Objective:** Activate the "Post-SaaS" AI capabilities.
+1.  **Agent Runtime**:
+    *   Implement `AgentExecutor` using `src/ai/agent.zod.ts`.
+    *   Connect Agents to `HttpDispatcher` as Tools.
+
+---
+
+## 4. Immediate Action Items (Today/Tomorrow)
+
+1.  **Scaffold `packages/plugins/driver-sqlite`**.
+2.  **Extract Standard Driver Test Suite**: Ensure `packages/core/src/qa` has a reusable test suite that can be applied to new drivers immediately.

apps/docs/mdx-components.tsx

@@ -0,0 +1,9 @@
+import type { MDXComponents } from 'mdx/types';
+import defaultComponents from 'fumadocs-ui/mdx';
+
+export function useMDXComponents(components: MDXComponents): MDXComponents {
+  return {
+    ...defaultComponents,
+    ...components,
+  };
+}

apps/docs/scripts/debug-docs.ts

@@ -0,0 +1,21 @@
+
+import { docs } from '../.source/server';
+import path from 'path';
+
+console.log('CWD:', process.cwd());
+console.log('Resolved Content Path (Reference):', path.resolve(process.cwd(), '../../content/docs'));
+
+console.log('--- Loaded Docs ---');
+// docs is a collection.
+// It might be an array or map depending on implementation.
+// Fumadocs collections usually export the list of items.
+
+// Check if docs is array or object
+if (Array.isArray(docs)) {
+    console.log(`Found ${docs.length} docs.`);
+    docs.forEach((doc: any) => {
+        console.log(`- ${doc.data.title} (${doc.file.path})`);
+    });
+} else {
+    console.log('Docs object:', docs);
+}

content/docs/references/cli/meta.json content/docs/framework/cli/meta.jsoncontent/docs/references/cli/meta.json renamed to content/docs/framework/cli/meta.json

@@ -0,0 +1,56 @@
+---
+title: Architecture
+description: Deep dive into the ObjectKernel architecture
+---
+
+# Core Architecture
+
+The ObjectKernel architecture follows a strict **Life-Cycle** process to ensure system stability.
+
+## The Bootstrap Lifecycle
+
+When you request `kernel.bootstrap()`, the following sequence occurs:
+
+```mermaid
+graph TD
+    A[Bootstrap Start] --> B[Discovery]
+    B --> C[Validation]
+    C --> D[Resolution]
+    D --> E[Init Phase]
+    E --> F[Start Phase]
+    F --> G[Ready State]
+```
+
+### 1. Discovery Phase
+The kernel scans for registered plugins. In a typical app, plugins are explicitly registered via code, but the kernel also supports scanning `package.json` for auto-discovery in certain environments.
+
+### 2. Validation Phase
+Each plugin's manifest is validated against the **Plugin Protocol** specific in `@objectstack/spec`.
+- **Name**: Must be unique.
+- **Version**: SemVer compatible.
+- **Dependencies**: Declared dependencies must be present.
+
+### 3. Resolution Phase (Topological Sort)
+The kernel builds a dependency graph of all plugins. If Plugin A depends on Plugin B, Plugin B is guaranteed to be initialized first. Circular dependencies will throw a fatal error.
+
+### 4. Init Phase (Synchronous Setup)
+The `init(ctx)` hook is called for every plugin in order.
+- **Purpose**: Register Services, Validate Configuration.
+- **Restriction**: NO side effects (e.g., do not connect to DB, do not start HTTP server).
+- **Outcome**: The Service Registry is fully populated.
+
+### 5. Start Phase (Async Execution)
+The `start(ctx)` hook is called.
+- **Purpose**: Connect to databases, bind network ports, start background jobs.
+- **Outcome**: The system is live.
+
+## Error Handling
+
+The Kernel implements a **Rollback Mechanism**. If any plugin fails during the `start` phase, the kernel attempts to stop all previously started plugins in reverse order to ensure a clean exit.
+
+```typescript
+const kernel = new ObjectKernel({
+    rollbackOnFailure: true, // Default: true
+    defaultStartupTimeout: 30000 // 30s timeout per plugin
+});
+```

…ent/docs/references/client-sdk/index.mdx …tent/docs/framework/client-sdk/index.mdxcontent/docs/references/client-sdk/index.mdx renamed to content/docs/framework/client-sdk/index.mdx content/docs/references/client-sdk/index.mdx renamed to content/docs/framework/client-sdk/index.mdx

@@ -0,0 +1,52 @@
+---
+title: Events & Hooks
+description: System-wide event bus
+---
+
+# Events & Hooks
+
+The Kernel provides a high-performance, typed Event Bus for loose coupling.
+
+## Lifecycle Events
+
+These events are emitted by the Kernel itself during the bootstrap process.
+
+| Event | Description |
+| :--- | :--- |
+| `kernel:init` | The kernel has started initialization. |
+| `kernel:ready` | All plugins have successfully started. System is live. |
+| `kernel:shutdown` | Shutdown signal received. |
+
+## Data Events
+
+The Data Engine emits events for record mutations.
+
+| Event | Payload |
+| :--- | :--- |
+| `data:beforeCreate` | `{ object, record }` - Can modify record or throw error to cancel. |
+| `data:afterCreate` | `{ object, record, id }` - Post-processing. |
+| `data:beforeUpdate` | `{ object, id, record }` |
+| `data:afterUpdate` | ... |
+
+## Usage
+
+### Listening to Events
+
+```typescript
+ctx.hook('kernel:ready', async () => {
+    ctx.logger.info("System is ready! Sending startup notification...");
+});
+
+ctx.hook('data:beforeCreate', async ({ object, record }) => {
+    if (object === 'order' && record.amount > 10000) {
+        ctx.logger.warn('Large order detected!');
+    }
+});
+```
+
+### Emitting Events
+
+```typescript
+// Custom business event
+ctx.emit('order:shipped', { orderId: '123' });
+```

content/docs/framework/core/architecture.mdx

@@ -0,0 +1,56 @@
+---
+title: Introduction
+description: The Core Microkernel of ObjectStack
+---
+
+# ObjectStack Core
+
+The `@objectstack/core` package is the **Microkernel** of the ObjectStack operating system. It provides the minimal runtime environment required to load plugins, manage dependencies, and orchestrate the system lifecycle.
+
+Similar to how the Linux Kernel manages hardware drivers and processes, the ObjectStack Core manages **Protocol Plugins** and **Services**.
+
+## Why a Microkernel?
+
+ObjectStack is designed to be:
+1.  **Modular**: Every feature, including the API Server, Database Driver, and UI Engine, is a plugin.
+2.  **Extensible**: You can replace any default component with your own implementation.
+3.  **Environment Agnostic**: Runs on Node.js, Bun, Edge Runtimes (Cloudflare Workers), or even in the Browser (via Mock Service Worker).
+
+## Key Responsibilities
+
+1.  **Plugin Lifecycle Management**: Loading, validating, initializing, and starting plugins in the correct dependency order.
+2.  **Dependency Injection (DI)**: A central registry for services to communicate without tight coupling.
+3.  **Event Bus**: System-wide hook system for intercepting logic (e.g., `data:beforeCreate`, `kernel:ready`).
+4.  **Configuration Management**: Standardized configuration loading using Zod validation.
+
+## Installation
+
+```bash
+pnpm add @objectstack/core
+```
+
+## Basic Usage
+
+```typescript
+import { ObjectKernel } from '@objectstack/core';
+
+// 1. Create the Kernel
+const kernel = new ObjectKernel({
+    logger: { level: 'info' }
+});
+
+// 2. Register Plugins
+kernel.use({
+    name: 'my-custom-plugin',
+    version: '1.0.0',
+    async init(ctx) {
+        ctx.logger.info('Initializing my plugin...');
+    },
+    async start(ctx) {
+        ctx.logger.info('Plugin started!');
+    }
+});
+
+// 3. Boot system
+await kernel.bootstrap();
+```

content/docs/framework/core/events.mdx

@@ -0,0 +1,11 @@
+{
+  "title": "Core (Microkernel)",
+  "pages": [
+    "index",
+    "architecture",
+    "plugins",
+    "services",
+    "events",
+    "types"
+  ]
+}