openxiangda 1.0.0

package/lib/workspace-init.js

@@ -0,0 +1,139 @@
+const fs = require('fs');
+const path = require('path');
+const { spawnSync } = require('child_process');
+const { getProfile, loadConfig, saveProjectState } = require('./config');
+
+const ROOT_DIR = path.join(__dirname, '..');
+const TEMPLATE_DIR = path.join(ROOT_DIR, 'templates', 'sy-lowcode-app-workspace');
+
+function initWorkspace(options = {}) {
+  const targetDir = path.resolve(options.dir || process.cwd());
+  const packageName =
+    options.name || path.basename(targetDir) || 'sy-lowcode-app-workspace';
+  const force = Boolean(options.force);
+  const install = Boolean(options.install);
+  const profileName = options.profile || null;
+  const appType = options.appType || null;
+
+  if ((profileName && !appType) || (!profileName && appType)) {
+    throw new Error('workspace init 绑定应用时必须同时提供 --profile 和 --app-type');
+  }
+
+  ensureCanInitialize(targetDir, force);
+  copyTemplate(TEMPLATE_DIR, targetDir, {
+    __WORKSPACE_PACKAGE_NAME__: packageName,
+  });
+
+  let bound = null;
+  if (profileName && appType) {
+    const config = loadConfig();
+    const resolved = getProfile(config, profileName);
+    const state = {
+      version: 1,
+      profiles: {
+        [resolved.profileName]: {
+          baseUrl: resolved.profile.baseUrl,
+          appType,
+          resources: {
+            forms: {},
+            pages: {},
+            workflows: {},
+            automations: {},
+            menus: {},
+            roles: {},
+            pagePermissionGroups: {},
+            formPermissionGroups: {},
+          },
+          updatedAt: new Date().toISOString(),
+        },
+      },
+    };
+    saveProjectState(state, targetDir);
+    bound = {
+      profile: resolved.profileName,
+      appType,
+    };
+  }
+
+  if (install) {
+    runInstall(targetDir);
+  }
+
+  return {
+    targetDir,
+    packageName,
+    templateDir: TEMPLATE_DIR,
+    installedDependencies: install,
+    bound,
+    nextSteps: buildNextSteps(targetDir, install, bound),
+  };
+}
+
+function ensureCanInitialize(targetDir, force) {
+  if (!fs.existsSync(TEMPLATE_DIR)) {
+    throw new Error(`workspace 模板不存在: ${TEMPLATE_DIR}`);
+  }
+  if (!fs.existsSync(targetDir)) {
+    fs.mkdirSync(targetDir, { recursive: true });
+    return;
+  }
+  if (!fs.statSync(targetDir).isDirectory()) {
+    throw new Error(`目标路径不是目录: ${targetDir}`);
+  }
+  const entries = fs
+    .readdirSync(targetDir)
+    .filter(name => !['.DS_Store'].includes(name));
+  if (entries.length > 0 && !force) {
+    throw new Error(`目标目录非空: ${targetDir}。如需写入请传 --force`);
+  }
+}
+
+function copyTemplate(sourceDir, targetDir, replacements) {
+  for (const entry of fs.readdirSync(sourceDir, { withFileTypes: true })) {
+    const sourcePath = path.join(sourceDir, entry.name);
+    const targetPath = path.join(targetDir, entry.name);
+    if (entry.isDirectory()) {
+      fs.mkdirSync(targetPath, { recursive: true });
+      copyTemplate(sourcePath, targetPath, replacements);
+      continue;
+    }
+    if (!entry.isFile()) continue;
+    fs.mkdirSync(path.dirname(targetPath), { recursive: true });
+    const content = fs.readFileSync(sourcePath, 'utf8');
+    fs.writeFileSync(targetPath, applyReplacements(content, replacements));
+  }
+}
+
+function applyReplacements(content, replacements) {
+  return Object.entries(replacements).reduce(
+    (result, [key, value]) => result.split(key).join(value),
+    content
+  );
+}
+
+function runInstall(targetDir) {
+  const result = spawnSync('pnpm', ['install'], {
+    cwd: targetDir,
+    stdio: 'inherit',
+    env: process.env,
+  });
+  if (result.status !== 0) {
+    throw new Error('pnpm install 执行失败');
+  }
+}
+
+function buildNextSteps(targetDir, installedDependencies, bound) {
+  const steps = [`cd ${targetDir}`];
+  if (!installedDependencies) steps.push('pnpm install');
+  if (!bound) {
+    steps.push('openxiangda workspace bind --profile <name> --app-type APP_XXXX');
+  }
+  const profileArg = bound ? bound.profile : '<name>';
+  steps.push(`openxiangda env --profile ${profileArg}`);
+  steps.push(`openxiangda workspace publish --profile ${profileArg}`);
+  return steps;
+}
+
+module.exports = {
+  initWorkspace,
+};

package/openxiangda-skills/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: openxiangda
+description: Use OpenXiangda to help AI agents build and publish apps on a private low-code platform through the openxiangda CLI, ordinary user login tokens, platform profiles, workspace initialization, workspace binding, and app snapshots; use when the user mentions OpenXiangda, 湘搭, 私有化低代码平台, sy-lowcode-app-workspace, profile/domain login, or multi-platform publishing.
+---
+
+# OpenXiangda
+
+OpenXiangda is a lightweight bridge between an AI coding tool and a private low-code platform. It does not ask users for AK/SK. The user provides a platform domain, logs in as a normal platform user, and the CLI calls `/openxiangda-api/v1` with that user's token.
+
+For page generation, OpenXiangda must use `sy-lowcode-app-workspace`: form pages, workflow form pages, and custom code pages are implemented as workspace source files, built into bundles, uploaded to OSS, and registered through `openxiangda workspace publish`. Do not generate final user-facing pages by relying on the platform's legacy default schema page.
+
+## Platform Routing
+
+Private platform routing is fixed:
+
+- Backend services are under `/service`.
+- Platform management UI is under `/platform`.
+- App runtime access is under `/view`.
+
+When the user provides a root domain such as `https://yida.wisejob.cn/`, use it directly with the CLI; OpenXiangda normalizes the API base to `https://yida.wisejob.cn/service`. If the user provides a copied `/platform` or `/view` URL, treat it as the same platform and normalize to `/service`. Do not call `/openxiangda-api/v1` at the root domain.
+
+## Required Flow
+
+1. Ask for the target platform domain if it is not known.
+2. Configure a profile:
+   ```bash
+   openxiangda platform add dev https://dev-lowcode.example.com
+   openxiangda platform use dev
+   ```
+3. If not logged in, run:
+   ```bash
+   openxiangda login --profile dev
+   ```
+   Or combine domain and login:
+   ```bash
+   openxiangda login https://dev-lowcode.example.com --profile dev
+   ```
+4. Check current context before any write:
+   ```bash
+   openxiangda env --profile dev
+   openxiangda auth status --profile dev
+   ```
+5. Ensure there is a local app workspace. If the current directory is not a `sy-lowcode-app-workspace` and no app workspace exists yet, initialize one:
+   ```bash
+   openxiangda workspace init ./my-app-workspace --profile dev --app-type APP_XXXX
+   cd ./my-app-workspace
+   pnpm install
+   ```
+6. Bind the local workspace to the app for the selected platform:
+   ```bash
+   openxiangda app list --profile dev
+   # or create one when needed:
+   openxiangda app create "示例应用" --profile dev
+   openxiangda workspace bind --profile dev --app-type APP_XXXX
+   cd /path/to/sy-lowcode-app-workspace
+   openxiangda workspace publish --profile dev
+   ```
+7. For multi-platform publishing, always pass `--profile` explicitly:
+   ```bash
+   openxiangda workspace publish --profile prod
+   ```
+
+## Rules
+
+- Never ask the user for `appKey`, `appSecret`, `AK`, or `SK`.
+- If `openxiangda` is not available in PATH, the CLI package is not installed or linked. In this repo, use `npm link`; in a packaged install, use `npm install -g .` or the published package.
+- If there is no `sy-lowcode-app-workspace`, create one with `openxiangda workspace init <dir>` before writing forms, pages, or JS_CODE nodes.
+- Never treat `openxiangda form create` as page generation. It only creates a low-level platform form shell for diagnostics or for workspace publish internals. The source of user-facing pages is `sy-lowcode-app-workspace`.
+- Publish normal form pages, workflow form pages, and custom code pages through `openxiangda workspace publish --profile <name>` from the app workspace.
+- Never store token data in the project directory. User tokens live in `~/.openxiangda/profiles.json`; project state lives in `.openxiangda/state.json` and stores only IDs and mappings.
+- Use logical resource codes in local files. Platform-specific IDs such as `formUuid`, `pageId`, `workflowId`, and `automationId` must be isolated by profile.
+- Before publishing to another platform, verify the workspace is bound for that profile. Resource IDs from one profile must not be reused for another profile.
+- Use `openxiangda app snapshot <APP_XXX> --profile <name> --json` for diagnosis before changing an existing app.
+- Run write commands that update `.openxiangda/state.json` sequentially within the same workspace. Read-only commands can run in parallel.
+- For workflow/automation JS_CODE nodes, prefer V2 `runtimeMode: "trusted_node"`. AI-authored source must be TypeScript under `sy-lowcode-app-workspace/src/js-code-nodes/<scriptCode>/index.ts`. `pnpm build-js-code --script <scriptCode>` runs TypeScript validation before bundling, and `sourceFile.localPath` should point to the TS source; the CLI builds, uploads, and replaces it with snapshot metadata during validate/create.
+
+## Subskills
+
+- `skills/openxiangda-core/SKILL.md`: command workflow and API contract details.
+- `skills/openxiangda-app/SKILL.md`: app creation, binding, snapshots, and profile-isolated workspace state.
+- `skills/openxiangda-form/SKILL.md`: workspace-based form and workflow form page development, bundle registration, and form publishing.
+- `skills/openxiangda-page/SKILL.md`: custom code page development and publishing in `sy-lowcode-app-workspace`.
+- `skills/openxiangda-workflow-automation/SKILL.md`: workflow v3 definitions, automation triggers, publishing, enabling, and profile-isolated IDs.
+- `skills/openxiangda-permission-settings/SKILL.md`: app roles, page permission groups, form permission groups, and settings-oriented guidance.
+- `skills/openxiangda-inspect/SKILL.md`: read-only app and resource diagnosis using snapshots and profile-local resource IDs.
+
+## API Namespace
+
+OpenXiangda uses `/openxiangda-api/v1`. Old `/dingtalk-api/v1.0` APIs are compatibility only and should not be used for new OpenXiangda workflows.
+
+On private deployments, the public API URL is normally `<platform-domain>/service/openxiangda-api/v1`.
+
+For endpoint details, read `references/openxiangda-api.md` only when you need request or response fields.
+
+## References Index
+
+Load these references on demand instead of memorizing them. Subskills cite the same files with relative paths.
+
+Core CLI / state:
+
+- `references/openxiangda-api.md` — `/openxiangda-api/v1` request and response fields.
+- `references/workspace-state.md` — `.openxiangda/state.json` shape and profile isolation rules.
+
+Form authoring:
+
+- `references/forms/form-schema.md` — `defineFormSchema` structure, field types, top-level effects.
+- `references/forms/component-registry.md` — supported form components and their props.
+- `references/forms/layout-and-rules.md` — layout containers, field rules, and validation patterns.
+
+Page authoring:
+
+- `references/pages/workspace-structure.md` — `src/pages/<pageCode>/` layout and config.
+- `references/pages/page-sdk.md` — `openxiangda/runtime` data and runtime APIs.
+- `references/pages/publish-flow.md` — workspace publish steps for code pages.
+
+Workflow / automation / permissions:
+
+- `references/workflow-v3.md` — workflow v3 definitions, JS_CODE nodes, trusted_node mode.
+- `references/automation-v3.md` — automation triggers, conditions, and publishing.
+- `references/permissions-settings.md` — roles, page/form permission groups, settings.
+
+Platform domain knowledge (read these first when generating forms or pages so the output matches the live platform behavior):
+
+- `references/platform-data-model.md` — how the platform persists field values (JSONB, `{label, value}` for option fields, attachment shape, etc.). Use this whenever you write, render, or diagnose form data.
+- `references/style-system.md` — three-layer style architecture, CSS namespace, and the no-hardcoded-color rule. Use this before writing any page or form CSS.
+- `references/architecture-patterns.md` — CRUD data flow, `DataManagementList` pattern, recommended directory layout for `src/pages` and `src/forms`. Use this before scaffolding a new page or list view.
+- `references/component-guide.md` — when to pick platform components vs. raw Ant Design vs. custom components, with the rules for option fields. Use this before introducing a new component.
+- `references/troubleshooting.md` — known failure modes (missing styles, `options` runtime errors, broken option rendering, etc.) and how to fix them. Use this when something does not behave as expected.

package/openxiangda-skills/references/architecture-patterns.md

@@ -0,0 +1,242 @@
+# Architecture Patterns
+
+> 面向 AI Agent 的平台架构范式指南：理解「表单为数据存储中枢、代码页承载业务逻辑」的低代码开发模型，并据此构建可发布的应用。
+
+---
+
+## 1. 平台设计理念
+
+### 1.1 表单 = 数据存储
+
+- **每个表单（Form）= 一张数据表**：表单 schema 定义即数据结构（字段、类型、校验、关联）。
+- 平台底层按字段建表：简单字段使用原生 SQL 类型列，复杂字段使用 json/jsonb 列存储结构化对象。AI 无需关心建表 DDL、迁移脚本或 CRUD 接口。
+- 表单除了承担「数据录入 UI」，还会自动暴露：列表查询、详情、增删改查 API、字段级权限、流程触发钩子。
+
+### 1.2 低代码 = Schema + 代码页
+
+```
+低代码应用 = 表单（定义数据结构）+ 代码页（实现业务逻辑/编排/可视化）
+```
+
+- **表单层**：声明式 schema (`src/forms/xxx/schema.ts`)，负责字段与数据契约。
+- **代码页层**：React/TSX (`src/pages/xxx/`)，负责非录入场景下的业务交互、数据可视化、聚合操作。
+
+### 1.3 「零后端开发」数据管理模式
+
+| 传统后端 | OpenXiangda 模式 |
+| --- | --- |
+| 设计表结构 + 迁移 | 编写表单 schema |
+| 编写 REST API | 平台自动生成数据 API |
+| 维护权限中间件 | 表单字段级权限 + 部门/角色 |
+| 自建文件存储 | `AttachmentField` 直接接入平台存储 |
+| 自研流程引擎 | 表单 + workflow + js-code-nodes |
+
+AI Agent 在该平台上写代码时，**不应该考虑数据库、表结构、后端接口**——这些由表单 schema 自动派生。
+
+---
+
+## 2. 标准 CRUD 数据流
+
+### 2.1 数据流向
+
+```
+┌──────────────┐    ┌─────────────────┐    ┌────────────────┐    ┌────────────┐
+│ 表单页       │───▶│ 数据存储        │───▶│ 数据管理页     │───▶│ 详情页     │
+│ (录入/编辑)  │    │ (平台数据表)    │    │ (列表/查询)    │    │ (查看)     │
+└──────────────┘    └─────────────────┘    └────────────────┘    └────────────┘
+       ▲                                            │
+       └────────────────────────────────────────────┘
+                     (从列表点编辑回填)
+```
+
+### 2.2 实现步骤
+
+1. **定义表单 schema**：`src/forms/xxx/schema.ts` → 生成数据表 + 录入页。
+2. **编写数据管理页**：`src/pages/xxx/index.tsx` 内使用 `DataManagementList` 组件做列表/查询/批量操作。
+3. **绑定菜单入口**：`openxiangda menu create --type=page --target=/pages/xxx`（指向自定义代码页，**而不是** view 类型）。
+
+### 2.3 反模式：不要使用平台内置 View
+
+> ❌ `openxiangda menu create --type=view --formUuid=FORM_XXX`
+
+平台内置 View 视图灵活性差：列宽/操作列/筛选项受限、无法嵌入业务交互、无法做联动。
+
+> ✅ **统一使用「自定义代码页 + `DataManagementList`」组合**。
+
+#### `DataManagementList` 的优势
+
+- 完全自定义列渲染（`render` 函数、React 节点）。
+- 自定义行操作 / 批量操作按钮。
+- 自定义筛选区（部门选择、人员选择、级联）。
+- 与页面内其他组件（Drawer、Modal、Tabs）自由组合。
+- 仍复用平台分页、查询、导出能力。
+
+---
+
+## 3. 数据管理页的标准构建方式
+
+### 3.1 最小可用示例
+
+```tsx
+// src/pages/instrument-list/index.tsx
+import { DataManagementList } from 'openxiangda';
+import { Tag, message } from 'antd';
+import { useNavigate } from 'react-router-dom';
+
+export default function InstrumentListPage() {
+  const navigate = useNavigate();
+
+  return (
+    <DataManagementList
+      formUuid="FORM_INSTRUMENT"
+      columns={[
+        { fieldId: 'name', title: '仪器名称' },
+        { fieldId: 'code', title: '编号', width: 140 },
+        {
+          fieldId: 'status',
+          title: '状态',
+          render: (val) => (
+            <Tag color={val.value === 'idle' ? 'green' : 'orange'}>
+              {val.label}
+            </Tag>
+          ),
+        },
+        { fieldId: 'department', title: '所属部门' },
+      ]}
+      actions={[
+        {
+          label: '预约',
+          onClick: (record) => navigate(`/forms/reservation/new?instrumentId=${record.id}`),
+        },
+        {
+          label: '编辑',
+          onClick: (record) => navigate(`/forms/instrument/${record.id}/edit`),
+        },
+      ]}
+      batchActions={['export', 'delete']}
+      filters={[
+        { fieldId: 'status', type: 'select' },
+        { fieldId: 'department', type: 'department-select' },
+        { fieldId: 'owner', type: 'user-select' },
+      ]}
+      onRowClick={(record) => navigate(`/pages/instrument-detail/${record.id}`)}
+    />
+  );
+}
+```
+
+### 3.2 关键 Props 速查
+
+| Prop | 类型 | 说明 |
+| --- | --- | --- |
+| `formUuid` | `string` | 绑定的表单（数据源） |
+| `columns` | `Column[]` | 列定义；`render` 可返回任意 React 节点 |
+| `actions` | `Action[]` | 行级操作按钮 |
+| `batchActions` | `('export' \| 'delete' \| BatchAction)[]` | 批量操作 |
+| `filters` | `Filter[]` | 筛选区字段；支持 `select` / `date-range` / `user-select` / `department-select` 等 |
+| `queryParams` | `Record<string, any>` | 固定查询条件（如「只看我创建的」） |
+| `onRowClick` | `(record) => void` | 行点击事件，常用于跳转详情 |
+
+---
+
+## 4. 页面类型与适用场景
+
+| 页面类型 | 实现方式 | 适用场景 |
+| --- | --- | --- |
+| 表单录入 / 编辑页 | `src/forms/xxx/` (`schema.ts` + `page.tsx`) | 新增数据、修改数据 |
+| 数据管理页 | `src/pages/xxx/` 使用 `DataManagementList` | 列表、查询、批量操作、导出 |
+| 流程表单页 | `src/forms/xxx/` 关联 workflow | 审批流程发起、节点处理 |
+| 自定义业务页 | `src/pages/xxx/` 自由编码 | 仪表盘、看板、复杂交互、对外门户 |
+| 详情页 | `src/pages/xxx/[id].tsx` 使用 `FormSummaryCard` 等 | 查看单条数据、关联记录 |
+
+> AI Agent 在创建新页面前，先按上表判断「应该走表单还是代码页」，避免把列表场景误塞进表单页。
+
+---
+
+## 5. 多端架构（PC / Mobile）
+
+### 5.1 分离策略
+
+- **页面层按端独立**：`src/pages/pc/xxx/` 与 `src/pages/mobile/xxx/`，避免单文件内 `if (isMobile)` 满天飞。
+- **入口统一调度**：
+
+  ```tsx
+  // src/pages/instrument/index.tsx
+  import { useDeviceDetect } from 'openxiangda';
+  import PcPage from './pc';
+  import MobilePage from './mobile';
+
+  export default function InstrumentEntry() {
+    const { isMobile } = useDeviceDetect();
+    return isMobile ? <MobilePage /> : <PcPage />;
+  }
+  ```
+
+- **UI 库分端**：
+  - PC → `antd`
+  - Mobile → `antd-mobile`
+- **逻辑层共享**：`src/domain/` 与 `src/shared/services/` 在两端复用，确保业务规则一处实现。
+
+### 5.2 共享 / 分离原则
+
+| 层 | PC/Mobile 是否共享 |
+| --- | --- |
+| 业务规则（domain） | ✅ 共享 |
+| 数据服务（services） | ✅ 共享 |
+| Hooks（hooks） | ✅ 多数共享，端相关的拆 `usePcXxx` / `useMobileXxx` |
+| 表单 schema | ✅ 共享（平台组件已多端适配） |
+| 页面布局 / 组件 | ❌ 分离 |
+
+---
+
+## 6. 目录组织规范
+
+```
+src/
+├── forms/                  # 表单（每个目录 = 一张数据表）
+│   └── instrument/
+│       ├── schema.ts       # 字段定义
+│       └── page.tsx        # 录入页（可选自定义布局）
+├── pages/                  # 自定义代码页（含数据管理页）
+│   ├── instrument-list/    # 列表/管理
+│   ├── instrument-detail/  # 详情
+│   └── dashboard/          # 仪表盘等业务页
+├── domain/                 # 纯业务逻辑（无 UI、可单测）
+│   └── instrument/
+│       ├── rules.ts
+│       └── types.ts
+├── shared/
+│   ├── services/           # 数据服务层（封装 SDK 调用）
+│   ├── hooks/              # 跨页面 hooks
+│   ├── components/         # 跨页面共享组件
+│   └── utils/              # 通用工具函数
+└── js-code-nodes/          # 工作流 JS 脚本（由 build-js-code.mjs 打包）
+```
+
+### 6.1 命名约定
+
+- 目录与文件统一 `kebab-case`：`instrument-list/`，`use-instrument-form.ts`。
+- React 组件文件首字母大写：`DataPanel.tsx`，与默认导出一致。
+- 表单目录名 = 表单业务名（不含 `Form` 后缀）。
+- 数据管理页目录名建议 `xxx-list`，详情页 `xxx-detail`。
+
+### 6.2 依赖方向（单向）
+
+```
+pages ──▶ shared ──▶ domain
+forms ──▶ shared ──▶ domain
+```
+
+- `domain/` 不依赖 `shared/` 或 UI。
+- `shared/` 不依赖 `pages/` 或 `forms/`。
+- 反向依赖（如 domain 导入 pages）= 立刻拒绝。
+
+---
+
+## 速查 Checklist（AI Agent 自检）
+
+- [ ] 新增数据场景：是否已经定义表单 schema？
+- [ ] 列表/查询场景：是否使用 `DataManagementList` 而非平台 view？
+- [ ] 菜单绑定：是否指向代码页 `--type=page`？
+- [ ] PC/Mobile：是否分离页面、共享 domain？
+- [ ] 目录：业务逻辑是否落在 `domain/`，未污染 UI 层？

package/openxiangda-skills/references/automation-v3.md

@@ -0,0 +1,129 @@
+# Automation V3 Reference
+
+Automations have two files:
+
+- `trigger.json`: when the automation runs.
+- `automation.json`: what the automation does.
+
+## Trigger Config
+
+Form submit trigger:
+
+```json
+{
+  "type": "form_data_submitted",
+  "appType": "APP_XXX",
+  "formUuid": "FORM_XXX",
+  "enabled": true
+}
+```
+
+Form update trigger:
+
+```json
+{
+  "type": "form_data_updated",
+  "appType": "APP_XXX",
+  "formUuid": "FORM_XXX",
+  "enabled": true
+}
+```
+
+Scheduled trigger:
+
+```json
+{
+  "type": "scheduled",
+  "appType": "APP_XXX",
+  "enabled": true,
+  "scheduleType": "fixed_time",
+  "fixedTime": {
+    "startTime": "2026-05-21T09:00:00+08:00",
+    "cronExpression": "0 0 9 * * *"
+  }
+}
+```
+
+Workflow trigger:
+
+```json
+{
+  "type": "workflow_process_completed",
+  "appType": "APP_XXX",
+  "formUuid": "FORM_XXX",
+  "processDefinitionId": "workflow-id",
+  "enabled": true
+}
+```
+
+Use CLI flags such as `--form-code customer` so the CLI can fill `formUuid` from the current profile. Do not hardcode IDs from another profile.
+
+## Definition JSON
+
+Minimum shape:
+
+```json
+{
+  "version": "v3",
+  "nodes": [
+    { "id": "start", "type": "start", "data": { "label": "开始" } },
+    { "id": "notify", "type": "work_notification", "data": { "label": "通知" } },
+    { "id": "end", "type": "end", "data": { "label": "结束" } }
+  ],
+  "edges": [
+    { "id": "e1", "source": "start", "target": "notify" },
+    { "id": "e2", "source": "notify", "target": "end" }
+  ]
+}
+```
+
+Supported node types:
+
+- `start`
+- `end`
+- `condition`
+- `condition_branch`
+- `branch`
+- `js_code`
+- `data_retrieve_single`
+- `data_retrieve_batch`
+- `data_create`
+- `data_update`
+- `connector_call`
+- `callback_wait`
+- `work_notification`
+- `dingtalk_card`
+
+## JS_CODE V2
+
+Use trusted Node JS_CODE nodes for AI/admin automation logic:
+
+```json
+{
+  "id": "sync_customer",
+  "type": "js_code",
+  "data": {
+    "label": "同步客户",
+    "runtimeMode": "trusted_node",
+    "sourceType": "file_snapshot",
+    "scriptCode": "sync_customer",
+    "sourceFile": {
+      "localPath": "src/js-code-nodes/sync_customer/index.ts"
+    },
+    "timeout": 30000
+  }
+}
+```
+
+Author source in `sy-lowcode-app-workspace/src/js-code-nodes/<scriptCode>/index.ts`. AI-authored source must be TypeScript. Build with `pnpm build-js-code --script <scriptCode>`; the command runs TypeScript validation before bundling. During validate/create, the CLI uploads the generated bundle, replaces `sourceFile.localPath` with `{ bucketName, objectName, sha256, ... }`, and the backend verifies sha256 before execution.
+
+Scripts may use `module.exports = async (ctx) => {}`, `require`, `process`, `Buffer`, legacy `methods.*`, arbitrary HTTP, and `platform.api` for `/openxiangda-api/v1`.
+
+Validation rules:
+
+- `version` must be `v3`.
+- `nodes` and `edges` must be arrays.
+- Exactly one `start` node is required.
+- Each node needs `id`, `type`, and object `data`.
+- Each edge needs `id`, `source`, and `target`.
+- Use `openxiangda automation validate --strict` before publishing.