openxiangda 1.0.264 → 2.0.0-alpha.2

package/templates/sy-lowcode-app-workspace/.qoder/rules/openxiangda-form.md

@@ -1,38 +0,0 @@
----
-description: src/forms/** glob — 精准引导到 openxiangda-form skill
-glob: src/forms/**/*
-alwaysApply: false
----
-
-# OpenXiangda Form Files
-
-You are editing files under `src/forms/<formCode>/`. Use the **`openxiangda-form`** skill.
-
-## Required structure
-
-```text
-src/forms/<formCode>/
-├── schema.ts   # defineFormSchema() default export — fields / options / rules / top-level FormEffect[]
-└── page.tsx    # presentation only
-```
-
-## Common pitfalls (high signal)
-
-- 表单录入组件优先级：OpenXiangda 平台字段组件 → `antd` / `antd-mobile` 包装 → 必要时自定义业务组件。
-- `schema.ts` 定义字段与平台组件；`page.tsx` 只做展示布局，优先渲染 OpenXiangda 标准表单 / runtime，不要拼原生控件。
-- `src/forms/**` 禁止直接写原生 `<input>` / `<select>` / `<textarea>` / `<input type="file">`、手写 picker/uploader、手写人员/部门选择器。
-- 选项字段（Select / MultiSelect / Radio / Checkbox / Cascade）必须有 `options`，不要给空。
-- 跨表数据 → `SelectField` + `optionSource.type: "linkedForm"`，**禁止** `AssociationFormField`。
-- 顶层 `schema.rules` 仅用于 `FormEffect[]`（`when` / `then`），**不要**写成校验数组；校验放字段 `rules`。
-- 平台系统字段（创建人 / 修改人 / 创建时间 / 修改时间 / 部门）由平台自动维护，**不要重复创建**。
-- 隐式权限键 / 派生键 → `behavior: "HIDDEN"` + `valueSync`。
-- 平台字段缺能力时，先 `openxiangda feedback submit --yes` 反馈能力缺口，再用 `antd` / `antd-mobile` 包装做临时 workaround，并告诉用户 fingerprint。
-
-## Publish
-
-```bash
-openxiangda workspace publish --profile <name> --form <formCode> --dry-run
-openxiangda workspace publish --profile <name> --form <formCode>
-```
-
-不要用 `openxiangda form create` / `form publish` 作为日常路径（仅底层修复）。

package/templates/sy-lowcode-app-workspace/.qoder/rules/openxiangda-page.md

@@ -1,39 +0,0 @@
----
-description: src/pages/** glob — 精准引导到 openxiangda-page skill
-glob: src/pages/**/*
-alwaysApply: false
----
-
-# OpenXiangda Page Files
-
-You are editing files under `src/pages/<pageCode>/`. Use the **`openxiangda-page`** skill.
-
-## Required structure（复杂页面拆分）
-
-```text
-src/pages/<pageCode>/
-├── page.config.ts                    # entry / route / navigation
-├── page.tsx                          # 薄视图层
-├── domain/                           # 业务规则、状态机、查询构造器（可被 PC/移动复用）
-├── shared/{services,hooks}/          # 数据访问层、复用 hook
-├── components/                       # 页面内组件
-└── styles.css                        # 页面级样式
-```
-
-## Strong defaults
-
-- 正式入口（管理后台 / PC 门户 / 移动门户）必须 `entry: { mode: "app-shell", hidePlatformNav: true, defaultRoute: "<home>" }`。
-- 默认 `cssIsolation: "none"` + 原生 Tailwind utilities（`bg-white`, `border-slate-200`, `grid-cols-[240px_1fr]`），不要 `bg-card` / `text-muted-foreground` 这些未配置的 shadcn token。
-- 列表页：用 `DataManagementList` 模式 + 分页 + 结构化 `filterGroup`，**不要** `pageSize=10000` 然后前端过滤。
-- 筛选、搜索、弹窗、抽屉、行内编辑：平台数据字段优先 OpenXiangda 平台组件；普通 UI 控件用 `antd` / `antd-mobile`。
-- AI-authored `src/pages/**` 禁止直接写原生 `<input>` / `<select>` / `<textarea>` / file input、手写 picker/uploader、手写人员/部门选择器。
-- 外部接口：`src/resources/connectors/` + `sdk.connector.call()`；多表只读联表：`src/resources/data-views/` + `sdk.dataView.query()`；通知：`src/resources/notifications/` + `sdk.notification`。
-
-## Publish
-
-```bash
-openxiangda workspace publish --profile <name> --page <pageCode> --dry-run
-openxiangda workspace publish --profile <name> --page <pageCode>
-```
-
-不要用 `openxiangda page publish` 作为日常路径（仅底层修复）。

package/templates/sy-lowcode-app-workspace/.qoder/rules/openxiangda-resources.md

@@ -1,59 +0,0 @@
----
-description: src/resources/** glob — 精准引导到 connector / data-view / notification / role / permission / settings 资源 manifest
-glob: src/resources/**/*
-alwaysApply: false
----
-
-# OpenXiangda Resource Manifests
-
-You are editing engineering-managed resource manifests under `src/resources/`. **All平台资源 ID 由 CLI 解析**；本地只用逻辑 code。
-
-## 必看：复制即用速查
-
-`references/resource-manifest-cheatsheet.md`（installed at `~/.qoder/skills/openxiangda/references/resource-manifest-cheatsheet.md`）— connector / data-view / notification / workflow / automation / JS_CODE / role / page-group / form-group / settings / menu 骨架。
-
-编辑 `roles`、`permissions/page-groups`、`permissions/form-groups` 前，如果需求涉及账号、角色、数据范围、组织账号、RBAC 或查询参数授权，先运行 `openxiangda design gates --topic permissions --json`，选择权限模式并输出权限矩阵。
-
-如果 `roles/<code>.json` 代表的角色需要新增角色、分配成员、授接口权限、维护权限组或管理组织账号，必须声明 `apiPermissionCodes`；只写业务角色名不会获得这些后端接口权限。
-
-## 文件夹与对应 skill
-
-| 路径 | 用途 | 主导 skill |
-|---|---|---|
-| `src/resources/connectors/<code>.json` | 第三方 / 自建系统 HTTP 连接器 | `openxiangda-page` |
-| `src/resources/data-views/<code>.json` | 多表只读联表（materialized view） | `openxiangda-form` |
-| `src/resources/notifications/<code>.json` | 通知模板 + typeConfigs | `openxiangda-page` / `-workflow-automation` |
-| `src/resources/workflows/<code>/{workflow.json,definition.v3.json,preview.json}` | 工作流 manifest | `openxiangda-workflow-automation` |
-| `src/resources/automations/<code>/{definition.code.json,preview.json}` | 自动化 manifest | `openxiangda-workflow-automation` |
-| `src/resources/roles/<code>.json` | 角色 | `openxiangda-permission-settings` |
-| `src/resources/permissions/page-groups/<code>.json` | 页面权限组 | `openxiangda-permission-settings` |
-| `src/resources/permissions/form-groups/<formCode>/<code>.json` | 表单权限组 | `openxiangda-permission-settings` |
-| `src/resources/settings/forms/<formCode>.json` | 表单设置 / 索引 / 数据管理页 / 公开访问 | `openxiangda-permission-settings` |
-| `src/resources/menus/<code>.json` | 菜单 | `openxiangda-app` |
-
-## 命令
-
-```bash
-openxiangda resource validate <type> --only <codes> --profile <name> # 静态校验
-openxiangda resource plan     <type> --only <codes> --profile <name> # diff 本地 vs. 平台
-openxiangda resource publish  <type> --only <codes> --profile <name> # 精确 upsert
-openxiangda resource publish  <type> --code <code> --profile <name>  # 单资源等价写法
-openxiangda resource pull     --profile <name>          # 平台 → 本地
-```
-
-Function/Automation 仅因源码变化进入 scope 时，默认通过服务端字段 PATCH 只更新 source snapshot，并保留线上 bindings、contracts、metadata、trigger/view 配置和 enabled/published state。无源码且 `definitionJson.version="v3"` 完整的新建 Automation 自动走 manifest create；确需让本地整包 manifest 覆盖已有线上定义时，必须追加 `--replace-manifest --reason "..."`。正式发布先 `release begin --change <change>` 分别冻结 clean publish HEAD 与 change/远端 baseline 并整体 preflight；`SOURCE_BASE_DIVERGED` / `RELEASE_SOURCE_BEHIND_MAIN` / `RESOURCE_FIELD_CONFLICT` 不能强行重试。上线后 merge/push 冻结 SHA，验证 `release integration-status`，再正常 `release end`。
-
-`resource plan` 与 publish dry-run 严格只允许 GET/HEAD。遇到 `READ_ONLY_AUTH_REQUIRED` 时，先执行 `openxiangda auth refresh --profile <name>` 或重新登录再重试；不得在 plan 内自动 POST 刷新 token。
-
-精确 `--only/--code` 会在 manifest/source 分析与 JS_CODE 构建前收窄，只触碰目标及其传递/shared/ambient 依赖；只有明确的全工作区任务才省略 selector。
-
-## 严禁
-
-- ❌ 把 `formUuid` / `pageId` / `workflowId` 等平台 ID 直接写进 manifest（CLI 解析逻辑 code）。
-- ❌ 把 API key / token / secret / password / authorization / headers / credential 写进 manifest（平台后台配置）。
-- ✅ App Function 只在 manifest 顶层写逻辑名 `secretRefs`，使用 `function_v2` / `trusted_node_v2` 和 `ctx.secrets.get(name)`；值仅由 `openxiangda secret ... --value-stdin --change ... --profile ...` 管理。
-- ❌ data view 用作单表 CRUD、`linkedForm` 下拉、写回、强实时数据源。
-- ❌ 只靠 query 参数、前端隐藏按钮、硬编码角色、mock 权限或 `PermissionBoundary` 作为敏感授权。
-- ❌ 管理型角色缺少 `app:role:manage`、`app:page-permission-group:manage`、`app:form-permission-group:manage` 或 `app:organization:manage`。
-- ❌ 在 page 源里 hardcode `/api/notification-config/*` 或 `/connectors/actions/invoke`（用 `sdk.notification` / `sdk.connector`）。
-- ❌ 同时在 manifest 与平台后台编辑同一个资源（漂移源）。

package/templates/sy-lowcode-app-workspace/.qoder/rules/openxiangda-workflow-automation.md

@@ -1,46 +0,0 @@
----
-description: src/{workflows,automations,js-code-nodes}/** glob — 精准引导到 openxiangda-workflow-automation skill
-glob: src/{workflows,automations,js-code-nodes}/**/*
-alwaysApply: false
----
-
-# OpenXiangda Workflow / Automation / JS_CODE Files
-
-You are editing files under one of:
-
-- `src/workflows/<code>/workflow.ts`        # 代码优先工作流（推荐用于无需画布编辑的场景）
-- `src/automations/<code>/index.ts`         # 代码优先自动化（automation_code_ts，推荐）
-- `src/js-code-nodes/<code>/index.ts`       # JS_CODE V2 trusted_node 后端脚本
-
-Use the **`openxiangda-workflow-automation`** skill.
-
-## Boundary — workflow vs. status field
-
-**大多数业务流转不是工作流。** `pending → processing → resolved → closed` 用表单 + `status` 字段 + 状态机 + automation/JS_CODE。
-仅当存在**真正的审批语义**（审批人 / 审批任务 / 同意/驳回 / 意见 / 节点字段权限 / 流程记录 / 节点副作用）时创建 workflow。
-
-## JS_CODE 适用与不适用
-
-- ✅ 跨表查询、批量更新、终止流程、平台 API、外部 HTTP、复杂编排。
-- ✅ `ctx.logger.debug/info/warn/error(message, data?)` 在每个关键步骤埋点。
-- ❌ 简单 UI 交互、普通表单校验、纯展示逻辑 → 应在 React 代码页里。
-
-## 构建与发布
-
-```bash
-# JS_CODE V2 本地构建
-pnpm build-js-code --script <scriptCode>
-
-# workflow / automation 校验 + 发布
-openxiangda workflow  validate / create / publish --profile <name>
-openxiangda automation validate / create / publish / enable --profile <name>
-
-# 排查
-openxiangda automation executions <code> --profile <name>
-openxiangda automation logs <instanceId> --profile <name>
-openxiangda automation diagnose <code> --profile <name>
-```
-
-不要把 `workflowId` / `automationId` 跨 profile 复制；每个 profile 独立维护。
-
-详见 `references/automation-v3.md` / `workflow-v3.md` / `resource-manifest-cheatsheet.md`。

package/templates/sy-lowcode-app-workspace/.qoder/rules/openxiangda.md

@@ -1,82 +0,0 @@
----
-description: OpenXiangda 工作区强约束 — 路由、命令、不变量、禁令
-alwaysApply: true
----
-
-# OpenXiangda Workspace Rule
-
-This is a `sy-lowcode-app-workspace` managed by the `openxiangda` CLI. Read [AGENTS.md](AGENTS.md) for the full guidance. The summary below is auto-injected into every Qoder turn.
-
-## Hard route — 用户意图 → skill / 命令
-
-| 用户说 | 必用 skill | 必用命令 |
-|---|---|---|
-| 发布 / 上线 / 部署 / publish / deploy | `openxiangda-core` | `openxiangda check --environment preproduction` → `openxiangda deploy preproduction` |
-| 晋级生产 | `openxiangda-core` | `openxiangda deploy production --package <packageDigest>` |
-| 发布失败 / 重试 | `openxiangda-core` | `openxiangda status <runId>` → `openxiangda retry <runId>` |
-| 创建 / 初始化应用 | `openxiangda-app` | `openxiangda workspace init <dir> --profile <name> --app-name "..."` |
-| 绑定已有应用 | `openxiangda-app` | `openxiangda workspace bind --profile <name> --app-type APP_XXX` |
-| 改表单字段 / schema / 表单页 | `openxiangda-form` | 编辑 `src/forms/<code>/` → `workspace publish --form <code>` |
-| 改代码页 / portal / dashboard | `openxiangda-page` | 编辑 `src/pages/<code>/` → `workspace publish --page <code>` |
-| 审批流程 / workflow / JS_CODE | `openxiangda-workflow-automation` | `openxiangda workflow ...` |
-| 自动化 / 定时 / 提交触发 | `openxiangda-workflow-automation` | `openxiangda automation ...` |
-| 账号 / 角色 / 权限 / 数据范围 / 查询参数授权 | `openxiangda-permission-settings` | 先 `openxiangda design gates --topic permissions --json`，再 `openxiangda permission ...` / `openxiangda settings ...` |
-| 排查 / 快照 / 对比 / 报错 | `openxiangda-inspect` | `openxiangda app snapshot APP_XXX --profile <name> --json` |
-| 登录 / token / 切平台 | `openxiangda-core` | `openxiangda env --profile <name>` / `openxiangda auth status` |
-| 外部后端 / 三方系统调用享搭 / AK/SK | `openxiangda-open-api` | `openxiangda open-api spec list --search <keyword> --json` |
-
-## Always
-
-- `deliveryVersion: 2` 的正常发布只允许 Delivery V2 命令；Runtime buildId 同时包含 Runtime layer 与密封包摘要，仅同包 `uploaded` Release 在内容、源码、父版本完全一致时复用，不覆盖不可变存储对象；后续 V1 SDD/mainline/`--only`/candidate/ship 内容仅作兼容说明，不得混入 V2。
-- V2 `check --json` 是权威预检：确认精确资源差异和执行计划。删除与未密封第三方构建依赖在写入前失败；包执行只用 CLI 工具链且不链接工作区 `node_modules`。`status`/`retry` 自动定位环境，retry 以 attempt 隔离旧执行器并仅重放跨机器所需的本地 Form 绑定。
-- 每个任务使用独立 worktree/branch 和一个开发 change，但 feature worktree 不发布。批准提交先合并并 push 到远端默认主分支，再创建一个 `sdd bundle`，从同步且干净的 main/master 一次发布。
-- 合并、push、发布和 `release end` 后，回到 canonical 主工作区先审阅 `openxiangda workspace cleanup`，再执行 `openxiangda workspace cleanup --apply` 应用精确哈希计划。CLI 在 owner lock 内复核，只删除已审阅的 managed `SAFE` 项，不顺带处理后来才安全的项，也不执行全局 `git worktree prune`；stale 记录单独人工审阅。
-- L0 只读/文档/测试无需 SDD；L1 窄小可逆改动记录精确范围且不重复确认；表单结构、业务函数、自动化/流程、权限、登录/公开访问、数据写入、runtime/config 等 L2/L3 走完整 SDD，live evidence/archive 放到发布后。
-- 极小的文案、样式、绑定修正可使用 `openxiangda sdd quick <change> ...`，但必须限制在精确的低风险范围内；用户已明确要求该小改时不再重复 propose/approve。
-- SDD 默认 streamlined：approval 与结构化精确范围是硬门禁，未完成的 task/evidence/spec 文案只告警；只有 `strictDocumentation: true` 才阻断。
-- Function/Automation 源码触发默认走服务端 source-field PATCH，保留线上 bindings/contracts/metadata/trigger/view/enabled/published state；无源码且 `definitionJson.version="v3"` 完整的新建 Automation 自动走 manifest create，只有替换已有整包 manifest 才必须精确 `--only/--code` 并加 `--replace-manifest --reason "..."`。
-- 相同 change 的 staged FormRelease 只有经服务端重新核验 immutable/inactive/non-aborted、identity/hash、冻结 schema/formType、finalized 资源、parent/base revision 与当前 Form Head 后，才可重挂接新 baseline/session。`schemaSyncedAt` 不是发布证据；禁止伪造、直发 schema 或提前激活 Form 绕过 Workflow 校验。
-- Form 设置与表单权限组同时发布时，必须合并为一条 `resource publish form-setting,form-permission-group`，并使用 `form-setting:<code>`、`form-permission-group:<code>` 精确 selector；SDD 生成与校验共享同一契约，禁止缺失、夹带或拆分 FormRelease。
-- 环境托管 `release ship --replace-manifest --reason "..."` 必须成对、reason 至少 8 字符且仅限精确 Backend selector；正式确认复用与预发完全相同的参数，不透传 Form/Workflow/Runtime/配置或全量步骤。
-- `release ship` 始终顺序执行 candidate → 预发 → 生产。日常分两次确认；明确授权紧急发布时首条命令可带 `--confirm-production` 一次完成，但不跳过预发/证据/CAS。candidate 封存环境/资源绑定、sourceRevision 及两目标 Runtime 哈希产物；后续主线 HEAD 只作安全门禁，Backend/Runtime/Root 不改写候选来源，且每条服务端 deployment 必须闭环为 `succeeded`。
-- 预发 UAT 失败使用 `release fail --deployment <id> --message "..." [--code <code>] [--details-json <JSON|file>] --environment preproduction` 写审计；CLI 先校验 deployment 属于所选预发环境，禁止 production 或环境不匹配写入。
-- 托管发布完成后运行 `release integration-status --change <change> --profile <name> --check`；CLI 从私有 `ship.json` 或其引用的 production/preproduction deployment execution 日志恢复血缘，无法恢复时指出实际缺失的文件或字段。
-- 写入平台前只从与权威远端 tip 完全一致的 clean main/master 执行 `release begin`。feature branch 或未 push 主线在任何写入前失败；clone primary 只有在冻结仓库 ID 已存在于 `repoAliases` 时才会 canonicalize，无交集在 Release prepare 前失败关闭；激活后直接运行 `integration-status` 和 `release end`，无需发布后再合并。
-- 环境托管工作区禁止直发：已有工作区先用 `environment attach` 接入，旧映射只能迁移到 appType 相同的预发 target，正式 target 必须为空。然后执行 `release candidate`、`release deploy --environment preproduction`、`release test`，最后将同一 candidate 用 `release promote --environment production --confirm-production` 晋级。两套环境的 appType、资源 ID 和数据不可互拷；用 `openxiangda studio` 查看状态。只有用户明确授权的投产前重分类可执行 `environment swap --reason "..." --confirm-production`；它不移动应用数据或 Release Head，且默认不放开副作用。
-- 单独修改某个环境的副作用策略只能使用 `environment policy update <preproduction|production> --side-effect-policy-json <JSON|file> --reason "..."`：先执行 `--dry-run`，正式环境额外要求 `--confirm-production`，不得借用 `environment swap`。patch 只校验本次提交字段并原样保留未知历史字段，`--full-replace` 才按完整目标删除遗漏字段。`organizationWrites=explicit_capability_only` 只解除环境级 deny，仍强制 `app:organization:manage`。发布硬门禁只保留明确 scope/profile/target、权限、干净且已推送主线、不可变版本、CAS/租约与生产确认；文案和人工验收说明默认是建议，只有显式 strict 模式才阻断。
-- 单文件改动默认按 change 和逻辑目标发布：先 `workspace plan --profile <name> --change <change> --changed`，再 `workspace publish --profile <name> --change <change> --only pages/a,forms/b --dry-run`。
-- 账号/角色/权限/RBAC/组织账号/查询参数授权需求先选权限模式：`managed-platform-account` / `existing-platform-user-assignment` / `static-role-permission` / `query-param-context`，并输出权限矩阵。
-- 角色能新增角色、分配成员、授接口权限、维护权限组或管理组织账号时，`src/resources/roles/<code>.json` 必须声明 `apiPermissionCodes`，例如 `app:role:manage`、`app:page-permission-group:manage`、`app:form-permission-group:manage`、`app:organization:manage`。
-- 任何写操作前确认当前 profile：`openxiangda env --profile <name>`。
-- `.openxiangda/state.json` 是 profile 到 appType / 资源 ID 的持久权威映射；临时 release/deployment 进度只写私有 `.openxiangda/releases/` journal。两者均由 CLI 维护，不要手改。
-- 多 target 的托管工作区执行 `function invoke` 必须显式传 `--environment <target>`，并核对 stderr 回显的最终 target。
-- 用户 token 在 `~/.openxiangda/profiles.json`；共享 env 在 `~/.openxiangda/.env`。
-- 表单字段必须有 user-facing `placeholder`；选项使用 `SelectField` / `RadioField`，跨表用 `linkedForm` SelectField。
-- 表单录入组件顺序：OpenXiangda 平台组件 → `antd` / `antd-mobile` 包装 → 必要时自定义业务组件。
-- 发现平台缺陷、能力缺口、规则不清、反复 workaround、AI 不确定点、用户可见体验问题时，主动 `openxiangda feedback submit --yes`；提交后告诉用户反馈内容和 fingerprint。
-- 页面默认 `cssIsolation: "none"` + 原生 Tailwind utilities；正式入口必须是 app-shell。
-
-## Never
-
-- ❌ `pnpm publish:all` / `pnpm publish:oss` / `pnpm register` / `lowcode-workspace publish-*` 直接调用。它们由 `_guard:publish` 拦截，缺少 `OPENXIANGDA_PROFILE` 时会 fail-fast。
-- ❌ 要求用户在对话中粘贴 AK / SK / appKey / appSecret；获授权的外部后端集成使用 `open-api credential` 安全交付。
-- ❌ 在没有本地 `.openxiangda/state.json` 绑定时，去平台搜索同名应用"复用"。
-- ❌ 把 `formUuid` / `pageId` / `workflowId` / `automationId` 从 dev 复制到 prod。
-- ❌ 对已经登记环境的 preproduction / production 执行 `release publish`，或绕过有效预发证据直接晋级正式。
-- ❌ 改一处就全量发布。
-- ❌ 在临时发布副本中做仓库没有的 hot patch，或让一个任务发布其他会话的 dirty 文件。
-- ❌ 只隐藏按钮、只判断 query 参数、硬编码角色、前端模拟权限、假账号/假 ID、或用 `PermissionBoundary` 代替真实授权。
-- ❌ 给用户挂“管理员”业务角色但不给该角色绑定 `app:role:manage` 等角色设置接口权限。
-- ❌ 绕过 `sdk.organization` / `ctx.organization` 直接写平台账号/部门。
-- ❌ `openxiangda form create` / `form publish` / `page publish` 当作页面生成方式（仅底层修复）。
-- ❌ 把 token / AK / SK / 第三方密钥写进项目文件。
-- ❌ `npm publish` — 本工作区 `"private": true`，不发 npm 包。
-- ❌ 在 AI 生成的 `src/forms/**` / `src/pages/**` 直接写原生 `<input>` / `<select>` / `<textarea>` / file input、手写 picker/uploader、手写人员/部门选择器。
-
-## When unsure
-
-读 [AGENTS.md](AGENTS.md) 与全局 skill：`~/.qoder/skills/openxiangda/SKILL.md`。
-
-## 并行 candidate
-
-candidate 只可跨越不相干的后续主线提交：其 commit 必须仍是干净、已推送主线的祖先，且 sealed 输入哈希全部不变。同一目标一次只允许一个 running / evidence-pending deployment；等待 lease/槽位，紧急修复也走精确 candidate → preproduction → production。

package/templates/sy-lowcode-app-workspace/AGENTS.md

@@ -1,158 +0,0 @@
-<!-- OpenXiangda-Policy-Version: 7 -->
-# AGENTS.md — OpenXiangda 工作区 AI 强约束
-
-> 任何 AI（Qoder / Claude / Codex / Cursor / Copilot 等）在本工作区操作前 **必须先读完本文件**。
-> 这是 `sy-lowcode-app-workspace`，由 `openxiangda` CLI 统一管理；普通 npm 习惯不适用于此工作区的发布与生命周期操作。
-
-## 一句话原则
-
-**本工作区声明 `deliveryVersion: 2`。所有“发布 / 上线 / 部署 / publish / deploy / ship / release”请求只使用 `openxiangda check`、`openxiangda deploy`、`openxiangda status`、`openxiangda retry`、`openxiangda rollback`，完整约定见 [DELIVERY.md](DELIVERY.md)。**
-
-Delivery V2 自动从期望状态按资源指纹计算精确范围，使用 CLI 密封工具链封存内容寻址 App Package，并在服务端持久化 ReleaseRun、attempt 和检查点；包执行不链接工作区 `node_modules`。`status`/`retry` 可自动定位预发或生产环境，跨机器重试只重放本地 Form 绑定并跳过已完成的平台写入。Runtime buildId 同时包含 Runtime layer 与密封包摘要，避免相同 Runtime 字节在不同包之间发生来源碰撞；同包重试仅在历史 Release 为 `uploaded` 且内容、源码、父版本完全一致时复用，绝不覆盖不可变存储对象。删除和未密封的第三方构建依赖会在远程写入前失败关闭。它不要求 SDD、Git clean、主线 ancestry、`--change`、`--only` 或生产确认参数。本文后续出现的 `workspace publish`、`resource publish`、`runtime deploy`、`release publish/ship`、candidate、SDD/mainline 发布门禁均属于 V1 底层兼容说明，不得用于 V2 正常发布。
-
-**架构类需求先过设计门。** 新应用、复杂页面、登录注册、公开访问、权限数据范围、流程自动化、连接器/通知等需求，先 `openxiangda doctor --json` + `openxiangda design gates --topic <code> --json`。只有仍存在会改变实现方向的业务、安全或数据选择时才输出设计并等待确认；用户已经给出具体需求与验收标准时，直接记录结构化 SDD 范围并实现，不再写长篇设计或重复确认。
-
-共享应用仓库把规范 `main`/`master` 检出专用于集成和发布；每个开发任务从最新远端主线使用独立 Git worktree/branch，禁止为了发布 stash/restore 或覆盖其他任务文件。调查默认只做一次完整 CodeGraph 查询，明确缺失时最多补一次精确查询；普通任务只加载一个领域技能。等待状态未变化时使用 `openxiangda task status --watch`，不要重复输出相同进度。
-
-任务关闭必须回到 canonical 主工作区：合并、push、发布及 `release end` 后先审阅 `openxiangda workspace cleanup`，再对这一份精确 `SAFE` 计划执行 `openxiangda workspace cleanup --apply`。CLI 只清理 OpenXiangda/Codex 管理、已进入实时主线、干净、无 owner/journal/lease 的 worktree，并在 owner lock 内复核；不会顺带清理后来才安全的项，也不会全局 `git worktree prune`。stale 记录需单独人工审阅，禁止直接 `rm -rf`。
-
-**按风险分级治理。** 只读/文档/测试为 L0；纯文案样式或单一既有资源绑定等窄小可逆改动为 L1，可用受限的 `openxiangda sdd quick` 记录精确范围；表单结构、业务 Function、Automation/Workflow、权限、登录/公开访问、数据写入和 runtime/config 为 L2；不可逆、生产迁移或应用级扩权为 L3。L2/L3 必须挂完整 SDD，并由 `coverage.json` 把需求与场景映射到精确的文件、表单、页面及工程资源范围。
-
-**开发 change 与发布 bundle 分离。** 每个任务在独立 worktree/branch 维护一个显式 change，从 `openxiangda sdd context --change <change> --changed --json` 开始；结构化范围是硬约束，任务/证据/规格文案默认只告警。所有批准提交先合并并 push 到主分支，再执行 `openxiangda sdd bundle <release-change> --changes ...`，从与远端完全一致的 clean `main`/`master` 一次发布；feature worktree 不直接发布。
-
-工作区内的 npm scripts（`publish:all` / `publish:oss` / `register`）已加 `_guard:publish` 守卫；缺少 `OPENXIANGDA_PROFILE` 环境变量时会立即 fail，提示重新走 CLI 入口。
-
-## 路由表 — 用户意图 → 命令 / skill
-
-| 用户说（中 / 英） | 用 skill | 第一条命令 |
-|---|---|---|
-| 发布 / 上线 / 部署 / publish / deploy | `openxiangda-core` | `openxiangda check --environment preproduction` → `openxiangda deploy preproduction` |
-| 晋级生产 | `openxiangda-core` | `openxiangda deploy production --package <packageDigest>` |
-| 发布失败 / 断点续跑 | `openxiangda-core` | `openxiangda status <runId>` → `openxiangda retry <runId>` |
-| 创建应用 / 新建 app / 初始化工作区 | `openxiangda-app` | `openxiangda workspace init <dir> --profile <name> --app-name "..."` |
-| 绑定已有应用 | `openxiangda-app` | `openxiangda workspace bind --profile <name> --app-type APP_XXX` |
-| 创建 / 改表单字段、schema、表单页 | `openxiangda-form` | 编辑表单并声明 form-setting bundle → `resource publish form-setting --only <code>` 暂存；整应用由 `app-finalize` 激活 |
-| 导出表单数据 / 图片 / 附件 / Excel / zip | `openxiangda-form` | `openxiangda form export <formCode> --mode xlsx|xlsx-images|package --profile <name>` |
-| 创建 / 改自定义代码页、portal、看板 | `openxiangda-page` | 编辑 `src/pages/<code>/` → `workspace publish --page <code>` |
-| 审批流程 / 流程节点 / JS_CODE | `openxiangda-workflow-automation` | `openxiangda workflow validate / create / publish` |
-| 自动化 / 定时任务 / 提交触发 / cron | `openxiangda-workflow-automation` | `openxiangda automation validate / create / publish / enable` |
-| 账号 / 角色 / 权限组 / 字段权限 / 数据范围 / 查询参数授权 | `openxiangda-permission-settings` | 先 `openxiangda design gates --topic permissions --json`，再 `openxiangda permission ...` / `openxiangda settings ...` |
-| 查应用结构 / 快照 / 对比 / 排查 / 报错 | `openxiangda-inspect` | `openxiangda app snapshot <APP_XXX> --profile <name> --json` |
-| 登录 / 切平台 / token / whoami | `openxiangda-core` | `openxiangda env --profile <name>` / `openxiangda auth status` |
-| 多表只读联表查询 / 报表数据源 | `openxiangda-form`（data view） | 在 `src/resources/data-views/<code>.json` 声明 → `resource publish` |
-| 调外部 / 第三方 API / 钉钉 / 自建系统 | `openxiangda-page`（connector） | 在 `src/resources/connectors/<code>.json` 声明 → `sdk.connector.invoke()` |
-| 外部后端 / 三方系统调用享搭 / AK/SK / 开放接口 | `openxiangda-open-api` | `openxiangda open-api spec list --search <keyword> --json` |
-| 资源诊断 / 小步修复 / 同步 manifest | 对应资源 skill | `openxiangda route|public-access|auth-config|function|connector|notification|data-view|menu|permission ... --dry-run` |
-
-## 必须遵守
-
-- ✅ 先 preflight：`openxiangda env --profile <name>` + `openxiangda auth status --profile <name>` + `openxiangda update check --json`。
-- ✅ 架构类需求先 plan gate：`openxiangda doctor --profile <name> --json` + `openxiangda design gates --topic <code> --json`，用户确认后再实现。
-- ✅ L2/L3 保留 context → propose → 用户确认 → approve；默认只创建 change/coverage/release，完整文档由 `sdd render` 按需生成。approval、coverage 与实际发布范围为硬门禁，未完成的任务/证据/规格文案只告警。需要严格文档门禁时显式配置 `strictDocumentation: true`。
-- ✅ 涉及账号、角色、权限、数据范围、组织账号、RBAC、查询参数授权时，先跑 `openxiangda design gates --topic permissions --json`，选择 `managed-platform-account` / `existing-platform-user-assignment` / `static-role-permission` / `query-param-context`，并输出权限矩阵后再改资源。
-- ✅ 某个应用角色如果要查询组织账号，声明 `app:organization:read`；如需创建、修改账号/部门或重置密码，再声明 `app:organization:manage`。角色设置、页面/表单权限组等能力同样通过 `src/resources/roles/<code>.json` 的 `apiPermissionCodes` 显式授权，例如 `app:role:manage`、`app:page-permission-group:manage`、`app:form-permission-group:manage`。
-- ✅ 查询家校通讯录的家长、学生、教师、班主任身份和班级/监护关系时使用 `sdk.organization.schoolContact.*` / `ctx.organization.schoolContact.*`。`SCHOOL_HEAD_TEACHER` 只判断全局身份，具体班级必须读取 `teachers.list` 的 `isHeadTeacher`。已登录非游客用户无需绑定应用角色权限，默认查询当前租户全部关系；只有明确要求时才声明 `:self:read` 或 `:class:read` 收紧。
-- ✅ 单文件改动默认按 change 和逻辑资源增量发布：`workspace plan --profile <name> --change <change> --changed`，再 `workspace publish --profile <name> --change <change> --only pages/a,forms/b --dry-run` → 正式发布。
-- ✅ 用户 token 在 `~/.openxiangda/profiles.json`；项目 state 在 `.openxiangda/state.json`（只存 ID）。
-- ✅ 共享环境（`APP_OSS_*`、反馈机器人等）在 `~/.openxiangda/.env`，项目 `.env` 仅做 per-workspace override。
-- ✅ 多 profile（dev / prod / ...）资源 ID 互不复用；每个 profile 的 `appType` / `formUuid` / `pageId` / `workflowId` / `automationId` 独立维护。
-- ✅ 改已有应用前先 `openxiangda app snapshot APP_XXX --profile <name> --json`。
-- ✅ 表单录入组件选择顺序：OpenXiangda 平台表单组件 → `antd` / `antd-mobile` 包装 → 只有两者都不满足时才写自定义业务组件。
-- ✅ 发现平台缺陷、能力缺口、规则不清、反复 workaround、AI 不确定点、用户可见体验问题时，主动 `openxiangda feedback submit --yes`；发送后告诉用户反馈内容和 fingerprint。
-- ✅ 正式多资源开发优先写 `src/resources/**` 后执行 `openxiangda resource validate|plan|publish <type> --only <codes>`；单资源可用 `--code <code>`。直接 CLI 写平台资源时先 `--dry-run`，需要避免漂移就加 `--write-manifest`。
-- ✅ `resource plan` 与 publish dry-run 严格只允许 GET/HEAD；遇到 `READ_ONLY_AUTH_REQUIRED` 时先执行 `openxiangda auth refresh --profile <name>` 或重新登录，不得在 plan 内自动 POST 刷新 token。
-- ✅ Function/Automation 使用 Backend Release v2；正式多资源发布用精确 `--only/--code` 加 `--stage-only` 暂存，同一 child 可混合源码 create、无 `sourceFile` 的完整 v3 声明式 Automation manifest create、source-only update 和显式 manifest replacement，再由 Root App finalize 原子激活。声明式 create 自动选路；替换已有资源的整包 manifest 才需要另加 `--replace-manifest --reason "..."`。clone primary 与冻结仓库 ID 不同时，只有冻结 ID 已存在于 `repoAliases` 才会统一用于 Backend/Workflow/Root App Release；无交集继续失败关闭。
-- ✅ 相同 change 已有 staged FormRelease 时，不要直发 schema、伪造 `schemaSyncedAt` 或提前激活 Form。CLI 只在重新核验服务端不可变状态、identity/hash、冻结 schema/formType、finalized 资源、parent/base revision 与当前 Form Head 后，才将 child 重挂接到新的 baseline/session；冲突继续失败关闭。
-- ✅ 同一发布同时包含 Form 设置和表单权限组时，必须使用一条 `resource publish form-setting,form-permission-group`，并以 `form-setting:<code>`、`form-permission-group:<code>` 精确限定 `--only`；SDD bundle 与 prepublish 校验共享该契约，禁止缺失、夹带、拆分发布或提前激活。
-- ✅ 未登记环境的旧工作区，正式 promotion 先聚合 mainline bundle 并 commit/push，再运行 `release publish --change <id> --profile <name>`。
-- ✅ 旧工作区已有 Root、且操作者明确授权无条件恢复时，可执行 `release app-activate <releaseId> --force-activate-without-validation --profile <name>`。该命令不读取 detail/capture，不要求 change、租约、baseline、源码 lineage、状态、parent、hash、resource head 或环境发布门禁；服务端直接在目标 tenant/appType 内以单事务切换 Root 与可识别的 staged children。
-- ✅ 已通过 `environment init` 或 `environment attach` 接入的工作区使用 `release ship`，始终按 candidate → preproduction → production 执行。日常首条命令在预发停止，后续 `--confirm-production` 晋级；用户明确授权紧急发布时，首条命令可携带 `--confirm-production` 在一个命令内顺序完成两阶段，但不跳过预发、证据、CAS 或确认。candidate 封存源码、public、构建配置/脚本、稳定环境/资源绑定和两目标 Runtime 哈希产物；部署不现场重建，Backend/Runtime/Root 子发布始终使用 candidate sourceRevision，并将两条服务端 deployment 闭环为 `succeeded`。两套环境身份仍完全隔离，人工验收建议和 swap/policy/权限门禁保持不变。
-- ✅ DataView `status` 仅是平台生命周期观察值；同一托管部署导致的 `active → draft → active` 不应让候选失效。`dataViewId`、`materializedViewName`、`storageMode`、其他资源状态、哈希、环境身份、CAS、租约和来源主线仍严格校验。
-- ✅ 预发 UAT 未通过时，使用 `release fail --deployment <id> --message "..." [--code <code>] [--details-json <JSON|file>] --environment preproduction --profile <name>` 写入平台审计。CLI 会先核对 deployment 属于所选预发环境；production target 或不匹配的 deployment 必须在写入前拒绝。
-- ✅ 托管发布完成后运行 `release integration-status --change <change> --profile <name> --check`。CLI 会从私有 `ship.json` 恢复血缘，必要时自动沿 production/preproduction deployment ID 查找对应 `execution.json`；失败信息必须指出实际缺失的日志或字段。
-- ✅ 只有已审计目标早已进入权威主线、线上却由多次历史 lineage 组成且无法对应单一 Git 基线时，第一次 `release ship` 才可增加 `--adopt-online-baseline --adoption-reason "..."`；该意图冻结进私有 `ship.json` 并由后续 `--confirm-production` 自动复用。仅允许精确非删除 selectors，冻结 Head、change/lease、服务端 CAS、staged children 与单次 App finalize 仍是硬门禁。
-- ✅ 环境托管发布需要完整替换 Function/Automation manifest 时，`release ship` 可成对增加 `--replace-manifest --reason "..."`；reason 至少 8 字符，只透传精确 Backend selector，正式确认必须复用同一对参数，不扩散到 Form/Workflow/Runtime/配置或全量范围。
-- ✅ 环境托管发布确需审计式 Runtime 源码血缘回退时，`release ship`、恢复命令 `release deploy` 和 `release promote` 可成对增加 `--allow-runtime-rollback --reason "..."`；reason 至少 8 字符，只透传 `runtime-stage`，不进入资源阶段或 `app-finalize`。ship 冻结该意图并由正式确认自动复用；默认仍失败关闭。
-- ✅ 受支持的配置资源（如 `publicAccessPolicies`）以精确 `resourceSelectors` 为边界；历史 `resources=true` 类别标记会被精确 selector 收窄。缺失 selector、未知类型、通配符 `*`、删除和真正全量资源仍 fail closed。
-- ✅ 本地开发者可运行 `openxiangda studio` 查看两套环境、差异、候选、部署和测试证据；该页面只监听回环地址且只暴露注册动作，生产操作仍需显式确认。
-
-## 严禁
-
-- ❌ 直接 `pnpm publish:all` / `pnpm publish:oss` / `pnpm register` / `lowcode-workspace publish-*`。它们是工作区内部脚本，不会注入 `OPENXIANGDA_PROFILE / BASE_URL / ACCESS_TOKEN / APP_TYPE`，发到错的环境也无人提醒。
-- ❌ 要求用户在对话中粘贴 AK / SK / appKey / appSecret。普通工作区流程使用用户 token；获授权的外部后端集成使用 `open-api credential` 安全交付。
-- ❌ 在没有本地 `.openxiangda/state.json` 绑定时，去平台搜索同名应用尝试"复用"。空目录 / 无绑定 → 直接 `workspace init --app-name` 创建新应用。
-- ❌ 把 `openxiangda form create` / `form publish` / `page publish` 当作日常页面生成方式。它们仅作底层修复 / 诊断。
-- ❌ 改一个文件就 `workspace publish` 全量。
-- ❌ 用“先 GET 最新 revision，再 PUT 旧整包 definition”的方式重试 Function/Automation 冲突；源码小改不得顺带覆盖线上 bindings/contracts/metadata/state。
-- ❌ 用户确认架构设计前就实现、写平台资源、发布、部署或发送通知。
-- ❌ 只隐藏按钮、只判断 query 参数、硬编码角色、前端模拟权限、假账号/假 ID、或用 `PermissionBoundary` 代替真实授权。敏感数据必须由角色、页面/表单权限组、public-access grants 或 App Function 后端校验保护。
-- ❌ 只给用户分配“管理员”业务角色，却不给该角色绑定 `app:role:manage` 等角色设置接口权限，然后期望他能新增账号、角色或权限组。
-- ❌ 直接绕过 SDK 调平台账号/组织写接口；应用管理平台账号/部门必须使用 `sdk.organization` / `ctx.organization`，且当前操作者具备 `app:organization:manage`。
-- ❌ 直连钉钉或根据班级成员推断、复制家长学生关系；应用只消费平台组织中心维护的家校关系读模型。
-- ❌ 把 token、AK、SK、第三方密钥写进项目文件。
-- ❌ `npm publish` —— 这个工作区是 `"private": true` 的应用工作区，不是要发到 npm 的 package。
-- ❌ 在 AI 生成的 `src/forms/**` / `src/pages/**` 里直接写原生 `<input>` / `<select>` / `<textarea>` / `<input type="file">`、手写 picker、手写 uploader、手写人员/部门选择器。原生控件只允许出现在 OpenXiangda SDK / 平台组件内部。
-
-## 表单 / 页面写作约束（高频踩坑）
-
-- 表单字段：可见字段必须有用户能看懂的 `placeholder`；`tips` 只用于特殊约束。
-- 表单录入：优先在 `schema.ts` 使用 `TextField` / `SelectField` / `DateField` / `UserSelectField` / `AttachmentField` 等平台字段；`page.tsx` 只做展示布局，不要拼原生控件。
-- 表单选项：用 `SelectField` / `RadioField` 表枚举；跨表数据用 `SelectField` + `optionSource.type: "linkedForm"`（数据量大时加 `remoteSearch: true` + `searchFieldId`）。**禁止**新建 `AssociationFormField`。
-- 权限隐式键、计算字段、同步字段：在 schema 中保留 `behavior: "HIDDEN"`，由可见字段通过 `valueSync` 派生，不要让用户填裸 ID。
-- 页面筛选 / 弹窗 / 抽屉 / 行内编辑：平台数据字段优先平台组件；普通 UI 控件用 `antd` / `antd-mobile`，不要用原生表单控件。
-- 页面默认 `cssIsolation: "none"` + 原生 Tailwind utilities（`bg-white`、`border-slate-200`、`grid-cols-[240px_1fr]` 等），不要用 `bg-card` / `text-muted-foreground` 这类未配置的 shadcn token。
-- 列表页用 `DataManagementList` 模式 + 分页 + 结构化 `filterGroup`，不要 `pageSize=10000` 然后前端过滤。
-- 结构化 JSON 录入用 `JSONField`；单字段扩展用 `renderer` / `editor`，列表详情或新增抽屉的统一替换通过 `DataManagementList components={{ JSONField: CustomJsonField }}` 透传。
-- 正式入口（管理后台 / PC 门户 / 移动门户）必须是 app-shell：`page.config.ts` 里 `entry: { mode: "app-shell", hidePlatformNav: true, defaultRoute: "<home>" }`。
-- 对外接口走 `src/resources/connectors/`；多表只读联表走 `src/resources/data-views/`；通知模板走 `src/resources/notifications/`。
-- 新 React SPA 公开访问使用 `/view/:appType/public/*` + `src/resources/routes/` + `src/resources/public-access/` + `PublicAccessGate`。旧 `?publicAccess=guest` 只用于旧 `sy-lowcode-view` 兼容，新应用禁止采用。
-
-## JS_CODE 批量构建
-
-`pnpm build-js-code --scripts functions:a,functions:b,automations:c` 可在一次进程中构建多个 App Function / Automation / JS_CODE 目标；也兼容重复的 `--script a --script b --source functions`。正式 `resource plan/publish` 使用 CLI 内置 scoped builder 和 `.openxiangda/build-cache.cli-v4.json`，按 authored source/dependencies 的稳定血缘增量构建；手工运行模板内 `pnpm build-js-code` 使用 `.openxiangda/build-cache.json`。两者都不能只因 `dist/**/index.cjs` 存在就视为有效；强制重建使用 `--force`。
-
-App Function 第三方凭据只能在 Function manifest 顶层声明 `secretRefs: [{name, required}]`，并使用 `function_v2` + `runtimeContractVersion: "trusted_node_v2"`；源码通过 `await ctx.secrets.get(name)` 获取。值只能用 `openxiangda secret create|rotate --value-stdin --change <id> --profile <name>` 或隐藏 TTY 配置，禁止写入 Git、`.env`、manifest、源码、构建产物、plan、日志和异常。本地联调只允许 `openxiangda function test --secret-from-env logical=ENV`，它不会把值写入 workspace/cache/state。
-
-App Function 查询应用角色及维护角色成员必须使用正式的 `ctx.platform.roles`：`findByCode(roleCode)`、`list()`、`get(roleId)`、`listUsers(roleId)`、`addUsers(roleId, userIds)`、`removeUser(roleId, userId)`。该 API 固定到 `ctx.app.appType`，按真实 operator 校验 `app:role:manage` 并保留调用审计；不要依赖自定义的 `ctx.platform.roles` 声明，也不要用泛型 `ctx.platform.api` 绕过角色契约。
-
-## 工作区结构速查
-
-```text
-sy-lowcode-app-workspace/
-├── AGENTS.md                        # 本文件
-├── .qoder/rules/openxiangda.md      # Qoder always-on 项目规则
-├── .cursor/rules/openxiangda.mdc    # Cursor always-on 项目规则
-├── openspec/                        # SDD v2 specs / changes / coverage / release / archive
-├── .openxiangda/state.json          # profile → appType → 资源 ID 的权威映射（CLI 维护）
-├── app-workspace.config.ts
-├── package.json                     # publish:all/publish:oss/register 都被 _guard:publish 守卫
-├── src/
-│   ├── forms/<formCode>/{schema.ts,page.tsx}    # 表单页源（openxiangda-form）
-│   ├── pages/<pageCode>/                         # 自定义代码页源（openxiangda-page）
-│   ├── workflows/<code>/workflow.ts              # 代码优先工作流（openxiangda-workflow-automation）
-│   ├── automations/<code>/index.ts               # 代码优先自动化
-│   ├── js-code-nodes/<code>/index.ts             # JS_CODE V2 trusted_node TS 源
-│   └── resources/                                 # data-views / connectors / notifications / roles / ...
-└── examples/best-practices/                       # 仅参考；不发布
-```
-
-## 还想看更细的
-
-- 全局 skill：`~/.qoder/skills/openxiangda/SKILL.md`（root 决策卡）+ 9 个子 skill。
-- 资源 / 连接器 manifest：`docs/openxiangda-resources-and-connectors.md`（来自 openxiangda 仓库）。
-- 平台数据模型：`references/platform-data-model.md`（option `{label, value}`、附件、成员字段等持久化形态）。
-- 排错清单：`references/troubleshooting.md`。
-
-## 升级现有工作区
-
-如果这份文件是后加上来的，请确认下面三件事：
-
-1. `package.json` 的 `publish:all` / `publish:oss` / `register` 已加上 `pnpm _guard:publish && ...` 前缀。
-2. `.qoder/rules/openxiangda.md` 与 `.cursor/rules/openxiangda.mdc` 都存在。
-3. `openxiangda update check --json` 显示已是最新，并跑过 `openxiangda skill install --force`。
-
-## 并行候选与紧急发布
-
-- candidate 创建后允许主线继续合入不相干任务；晋级时要求 candidate commit 仍是已推送主线祖先，且 sealed 输入文件哈希全部不变。任一输入变化都必须重建 candidate。
-- 同一目标环境一次只允许一个 running / evidence-pending deployment；CLI 会先等待应用 lease 和部署槽位。`--wait-seconds 0` 只用于快速发现占用，不能绕过 CAS。
-- 紧急修复使用精确 L1 scope，仍按 candidate → preproduction → production 发布；不得跳过应用/环境资源映射校验、预发证据或生产确认。应用内逐函数 `resources` 仅作映射和审计，不是权限白名单。

package/templates/sy-lowcode-app-workspace/DELIVERY.md

@@ -1,43 +0,0 @@
-# OpenXiangda Delivery V2
-
-This workspace uses `deliveryVersion: 2`. Delivery V2 is desired-state based,
-content-addressed, resumable, and independent from Git/SDD cleanliness.
-
-Normal release commands are deliberately limited to:
-
-```bash
-openxiangda check --environment preproduction
-openxiangda deploy preproduction --json
-openxiangda deploy production --package <packageDigest> --json
-openxiangda status <runId> --json
-openxiangda retry <runId> --json
-openxiangda rollback production --to <appReleaseId> --json
-```
-
-Rules:
-
-- Do not assemble a release by choosing low-level `workspace publish`,
-  `resource publish`, `runtime deploy`, `release publish`, `release ship`, or
-  `app-finalize` commands. Delivery V2 owns that orchestration.
-- Do not add `--only`, `--change`, SDD bypass flags, Git-clean workarounds, or
-  production-confirmation flags. The package compiler derives the exact delta.
-- Preproduction compiles and uploads one immutable App Package. Production
-  deploys that exact `packageDigest` without rebuilding.
-- `check --json` shows the exact resource delta, dependency-only Form bindings,
-  and ordered plan. Resource deletion fails before any remote write.
-- Authored Form/Backend/Workflow code uses the CLI-sealed toolchain. Package
-  execution never links workspace `node_modules`; undeclared third-party build
-  dependencies fail preflight.
-- On failure, keep the `runId`. `status` and `retry` auto-locate its environment
-  when omitted. Retry preserves successful checkpoints, fences the previous
-  attempt, and safely replays local Form bindings on another machine. Runtime
-  build IDs include the Runtime layer and sealed package digests, preventing
-  cross-package provenance collisions. A same-package retry reuses an existing
-  Runtime release only in `uploaded` state after exact content, source, and
-  parent verification; storage is never overwritten.
-- Project `.env`, credentials, private keys, `.git`, `node_modules`, `dist`,
-  and generated `.openxiangda` state are never included in the authored source
-  layer. Runtime output is a separate immutable layer.
-
-Low-level V1 commands remain installed only for diagnostics and compatibility
-with old workspaces that do not declare `deliveryVersion: 2`.

package/templates/sy-lowcode-app-workspace/app-workspace.config.ts

@@ -1,51 +0,0 @@
-import { defineAppWorkspaceConfig } from "openxiangda/build";
-
-export default defineAppWorkspaceConfig({
-  deliveryVersion: 2,
-  appType: process.env.APP_TYPE || process.env.OPENXIANGDA_APP_TYPE || "APP_XXXXXXXXXXXXXXXX",
-  appName: process.env.APP_NAME || "低代码应用",
-  platformUrl: process.env.APP_PLATFORM_URL || process.env.OPENXIANGDA_BASE_URL || "http://yida.wisejob.cn/service",
-  servicePrefix: process.env.APP_SERVICE_PREFIX || "/service",
-  appKey: process.env.APP_KEY || "",
-  appSecret: process.env.APP_SECRET || "",
-  userId: process.env.APP_USER_ID || "",
-  version: process.env.APP_VERSION || "0.1.0",
-  buildId: process.env.APP_BUILD_ID || "",
-  oss: {
-    region: process.env.APP_OSS_REGION || "oss-cn-hangzhou",
-    bucket: process.env.APP_OSS_BUCKET || "sy-app-workspace-dev",
-    accessKeyId: process.env.APP_OSS_ACCESS_KEY_ID || "",
-    accessKeySecret: process.env.APP_OSS_ACCESS_KEY_SECRET || "",
-    pathPrefix: process.env.APP_OSS_PATH_PREFIX || "app-workspace",
-  },
-  defaults: {
-    protocolVersion: process.env.APP_PAGE_PROTOCOL_VERSION || "1.0",
-    frameworkVersion: process.env.APP_FRAMEWORK_VERSION || "18.3.1",
-    cssIsolation:
-      process.env.APP_PAGE_CSS_ISOLATION === "namespace"
-        ? "namespace"
-        : process.env.APP_PAGE_CSS_ISOLATION === "shadow"
-          ? "shadow"
-          : "none",
-    formMenuParentId: process.env.APP_FORM_MENU_PARENT_ID || "",
-    formMenuIcon: process.env.APP_FORM_MENU_ICON || "",
-    pageMenuParentId: process.env.APP_PAGE_MENU_PARENT_ID || "",
-    pageMenuIcon: process.env.APP_PAGE_MENU_ICON || "",
-  },
-  compatibility: {
-    apiContracts:
-      process.env.OPENXIANGDA_API_CONTRACTS === "legacy" ? "legacy" : "strict",
-    legacyFallbacks: process.env.OPENXIANGDA_LEGACY_FALLBACKS === "true",
-    requestTrace: process.env.OPENXIANGDA_REQUEST_TRACE === "true",
-  },
-  governance: {
-    sdd: {
-      enabled: false,
-      strictHighRisk: false,
-      strictDocumentation: false,
-      documentationMode: 'structured',
-      path: process.env.OPENXIANGDA_SDD_PATH || "openspec",
-      schemaVersion: "openxiangda-sdd-v2",
-    },
-  },
-});

package/templates/sy-lowcode-app-workspace/examples/best-practices/README.md

@@ -1,43 +0,0 @@
-# OpenXiangda Best Practices
-
-These examples are intentionally placed under `examples/best-practices/`.
-They are copied by `workspace init`, but they are not scanned by
-`lowcode-workspace build` or `openxiangda workspace publish`.
-
-Copy the pieces you need into `src/`:
-
-```bash
-cp -R examples/best-practices/src/shared/components/admin-ui-templates src/shared/components/
-cp -R examples/best-practices/src/pages/work-order-list-drawer src/pages/
-cp -R examples/best-practices/src/domain/service-ticket src/domain/
-cp -R examples/best-practices/src/shared/services/service-ticket.ts src/shared/services/
-cp -R examples/best-practices/src/pages/service-ticket-ops src/pages/
-cp -R examples/best-practices/src/forms/service-ticket src/forms/
-```
-
-Run `pnpm examples:check` after editing examples, and run the normal
-`pnpm check` after copying code into `src/`.
-
-## Core Rules
-
-- Keep view code thin. Pages compose components, hooks, and services.
-- Put business rules in `domain/`; keep it free of React, SDK, and UI imports.
-- Put platform calls in `shared/services/`.
-- Put reusable loading, empty, error, status, and confirmation UI in
-  `shared/components/`.
-- Use state fields and operation logs for business lifecycle flows.
-- Use workflow only for real approval tasks.
-- For account, role, data scope, organization-account, RBAC, or query-param
-  authorization work, run `openxiangda design gates --topic permissions --json`
-  and choose an access governance mode before copying examples.
-- Query with pagination and structured conditions. Avoid large page sizes,
-  client-side filtering, and broad `searchKeyWord` queries.
-- For admin UI, choose one optional default from `glass-home-dashboard`,
-  `mint-analytics-dashboard`, `ops-monitor-dashboard`, or
-  `work-order-list-drawer`; use `work-order-list-drawer` as the default CRUD
-  list pattern.
-- Keep record detail and all create/edit/process forms in drawers or modals;
-  do not keep a permanent right-side detail column on data-management pages.
-
-Read `decision-guide.md`, `module-structure.md`, and `design-style.md` before
-using any template.