Add Chinese translations for specifications meta files and key architecture docs

Co-authored-by: hotlong <50353452+hotlong@users.noreply.github.com>

Author: Copilot

content/docs/specifications/data/architecture.cn.mdx

@@ -0,0 +1,59 @@
+---
+title: 编译器架构
+description: ObjectQL 的高级架构。数据库编译器如何将声明性意图转换为物理执行。
+---
+
+import { Database, FileJson, ServerCog, ArrowRight } from 'lucide-react';
+
+**ObjectQL** 决定数据层的行为。它被设计为一个**编译器**，将通用 JSON 中间表示（IR）转换为特定数据库的指令（SQL、NoSQL 等）。
+
+## 架构管道
+
+ObjectStack 数据引擎在四个不同的阶段运行。这种关注点分离使系统能够在保持原生性能的同时与数据库无关。
+
+### 1. 定义阶段（Schema）
+**输入：** YAML/JSON Schema 文件（`*.object.yml`）
+**角色：** 定义数据的"形状"和"规则"。
+**产物：**
+*   **对象定义：** 表/集合。
+*   **字段定义：** 列/属性。
+*   **验证规则：** 完整性约束。
+
+### 2. 组合阶段（AST）
+**输入：** API 请求 / SDK 调用
+**角色：** 将传入的意图解析为规范化的**抽象语法树（AST）**。
+**关键操作：**
+*   **验证：** 确保查询与 Schema 匹配。
+*   **权限注入：** 基于 ACL 自动添加过滤器（例如，`AND owner = 'me'`）。
+*   **规范化：** 将语法糖转换为严格的逻辑表达式。
+
+### 3. 编译阶段（驱动程序）
+**输入：** 规范化查询 AST
+**角色：** 底层**驱动程序**（Postgres、SQLite、Mongo）接收 AST 并将其编译为数据库的原生语言。
+**示例：**
+*   *Postgres 驱动程序：* `SELECT * FROM accounts WHERE type = 'customer'`
+*   *Mongo 驱动程序：* `db.accounts.find({ type: 'customer' })`
+
+### 4. 执行阶段（结果）
+**输入：** 原生游标
+**角色：** 执行物理查询并将输出格式化回标准 JSON 协议。
+
+---
+
+## 协议三位一体
+
+ObjectQL 由三个核心规范组成：
+
+| 规范 | 范围 | 职责 |
+| :--- | :--- | :--- |
+| **[Schema 定义](./schema-definition)** | 静态 | 如何定义对象、字段和关系。 |
+| **[AST 结构](./ast-structure)** | 运行时 | JSON 查询对象（"IR"）的结构。 |
+| **[传输协议](./wire-protocol)** | 传输 | 客户端和服务器如何通过 HTTP 交换这些结构。 |
+
+## 设计约束
+
+为了维护"一次编写，随处运行"的承诺，ObjectQL 强制执行以下约束：
+
+1.  **无泄漏抽象：** 你不能执行原始 SQL 字符串。所有访问都必须通过 AST。
+2.  **幂等 Schema：** 应用两次 Schema 定义必须产生相同的数据库状态。
+3.  **原子事务：** 所有变更操作（插入/更新/删除）默认必须是事务性的。

content/docs/specifications/data/meta.cn.json

@@ -0,0 +1,12 @@
+{
+  "title": "ObjectQL",
+  "pages": [
+    "architecture",
+    "schema-definition",
+    "advanced-types",
+    "ast-structure",
+    "analytics-protocol",
+    "transaction-model",
+    "wire-protocol"
+  ]
+}

content/docs/specifications/meta.cn.json

@@ -0,0 +1,9 @@
+{
+  "title": "规范",
+  "root": true,
+  "pages": [
+    "data",
+    "ui",
+    "server"
+  ]
+}

content/docs/specifications/server/kernel-architecture.cn.mdx

@@ -0,0 +1,36 @@
+---
+title: 内核架构
+description: ObjectOS 内核的设计。用于身份、安全和同步的集中式引擎。
+---
+
+import { Cpu, ShieldCheck, RefreshCw, Zap } from 'lucide-react';
+
+**ObjectOS** 是堆栈的"操作系统"。ObjectQL 处理*数据*，而 ObjectOS 处理*控制*。
+
+它充当位于 API 和数据库驱动程序之间的中间件内核，确保每次数据访问都经过身份验证、授权并符合业务规则。
+
+## 内核层
+
+### 1. 身份层（谁？）
+在任何逻辑运行之前，内核解析行为者。
+*   **身份验证：** OIDC、SAML 或 LDAP。
+*   **会话管理：** 无状态 JWT 或会话存储。
+*   **上下文注入：** 将 `userId`、`role` 和 `organization` 加载到请求上下文中。
+
+### 2. 策略层（他们可以吗？）
+内核强制执行**"纵深防御"**安全模型。
+*   **配置文件检查：** 此用户是否有使用此应用的许可证？
+*   **对象权限：** 他们可以 `READ` `Contract` 对象吗？
+*   **字段级安全（FLS）：** 他们可以看到 `contract_value` 吗？
+*   **共享规则：** 他们可以访问*此特定记录*吗？
+
+### 3. 逻辑层（会发生什么？）
+这是"业务逻辑"容器。
+*   **触发器：** 同步逻辑（`beforeInsert`）。
+*   **流程：** 可视化编排（`审批流程`）。
+*   **作业：** 异步任务（`发送电子邮件`）。
+
+### 4. 同步层（它在哪里？）
+ObjectOS 设计为**本地优先**操作。
+*   **变更数据捕获（CDC）：** 跟踪每个事务的"增量"。
+*   **复制：** 将这些增量同步到边缘设备（SQLite）或数据仓库（Snowflake）。

content/docs/specifications/server/meta.cn.json

@@ -0,0 +1,12 @@
+{
+  "title": "ObjectOS",
+  "pages": [
+    "kernel-architecture",
+    "permission-governance",
+    "workflow-engine",
+    "automation-rules",
+    "audit-compliance",
+    "integration-etl",
+    "plugin-manifest"
+  ]
+}

content/docs/specifications/ui/meta.cn.json

@@ -0,0 +1,11 @@
+{
+  "title": "ObjectUI",
+  "pages": [
+    "sdui-protocol",
+    "component-schema",
+    "view-protocol",
+    "layout-system",
+    "action-triggers",
+    "report-template"
+  ]
+}

content/docs/specifications/ui/sdui-protocol.cn.mdx

@@ -0,0 +1,54 @@
+---
+title: SDUI 协议
+description: 服务器驱动 UI 架构。ObjectStack 如何将"界面作为数据"来实现无限定制。
+---
+
+import { LayoutTemplate, Layers, Blocks, Smartphone } from 'lucide-react';
+
+**ObjectUI** 是视图层规范。它建立在**服务器驱动 UI（SDUI）**的原则之上。
+
+在传统的前端中，布局在 React/Vue 组件中硬编码（`<CustomerForm />`）。
+在 ObjectStack 中，前端是一个通用**渲染器**。它从服务器下载 JSON 布局定义并即时绘制。
+
+## UI 管道
+
+### 1. 布局请求
+客户端询问：*"给我编辑发票 #1024 的表单"*。
+```http
+GET /api/v4/ui/layouts/invoice/edit
+```
+
+### 2. 解析引擎
+服务器提供布局，合并三层定制：
+1.  **基础协议：** 在 `invoice.object.yml` 中定义的默认字段。
+2.  **管理员配置：** 通过页面构建器添加的自定义部分和字段。
+3.  **用户偏好：** 用户个性化的列宽和隐藏字段。
+
+### 3. 布局 JSON（响应）
+服务器响应组件树描述，而不是 HTML。
+```json
+{
+  "type": "page",
+  "layout": "two_column",
+  "regions": {
+    "main": [
+      { "type": "field_group", "label": "Basics", "children": ["name", "date"] },
+      { "type": "related_list", "object": "invoice_line", "label": "Line Items" }
+    ],
+    "sidebar": [
+      { "type": "widget", "component": "approval_history" }
+    ]
+  }
+}
+```
+
+### 4. 渲染器（客户端）
+通用 `PageRenderer` 组件遍历此 JSON 并实例化映射的组件（`FieldGroup`、`RelatedList`、`Widget`）。
+
+---
+
+## 为什么选择 SDUI？
+
+1.  **即时更新：** 在 Schema 中更改字段标签或移动部分，每个用户（Web、移动、外部门户）都会立即看到它，无需应用更新。
+2.  **平台原生：** 相同的 JSON 可以在 React 中渲染为 DOM 节点，在 SwiftUI/Kotlin 中渲染为原生视图，或在 TUI 中渲染为命令行。
+3.  **个性化：** 因为布局是按请求生成的，我们可以根据用户的角色或记录的状态隐藏整个部分（例如，如果状态为"草稿"，则隐藏"批准"按钮）。