openxiangda-skill-kit 2.0.0-alpha.39 → 2.0.0-alpha.47

package/docs/workflow-events.md

@@ -1,86 +0,0 @@
-# 工作流与事件
-
-## Workflow Kernel v2
-
-Workflow Kernel v2 专注审批语义：版本化定义、条件分支、审批任务、同意、拒绝、转交、回退、代理、加签、审批人解析、提交预览、主部门选择、字段策略、允许操作与审计。
-
-业务字段始终由 Data API 或 App API 保存。流程内核仅保存定义、实例、节点、任务、动作、参与者快照、字段策略和关联业务记录 ID。
-
-Native 本地运行与远端 Kernel 使用同一持久化边界：预览令牌只能消费一次；实例、当前任务、新任务、时间线和命令回执在一个 PostgreSQL 事务中提交；实例与任务版本同时参与 CAS。相同幂等键和相同请求跨重启返回原结果，相同键但不同请求明确冲突；两个运行实例并发处理同一任务时只有一个版本更新能够成功。`openxiangda dev --reset` 会清空这组本地工作流状态。本地内存适配器只用于 `--ui-only`，不提供重启或多实例保证。
-
-标准任务页使用实例的 DataRef 加载业务记录，并按节点 `fieldPolicy` 控制字段。`edit` 与 `edit_required` 的变化在流程命令前先写入 Data API，使用记录 revision 防止覆盖他人修改；采用 App API 存储的应用注入等价 loader/saver。流程命令失败不会把业务数据偷偷写进 Kernel。
-
-任务级操作包含同意、拒绝、退回、重新提交、转交、任务代理和前/后加签；实例级操作包含发起人撤回和应用管理员终止。一个正在审批的任务 Surface 可以同时返回任务级与实例级操作，例如应用管理员在任务仍活动时仍能终止实例。Admin 执行器按操作类型选择任务或实例命令，不以“当前页面有没有任务”猜测请求目标；撤回和终止也不会被当前审批节点的必填业务字段误拦截。
-
-长期代理绑定委托人的当前 Native membership RoleSubject，以及代理人的明确 membership RoleSubject。平台提供代理目标身份查询，页面同时展示角色和 scope grant；多角色用户不会因为只选择了人员而获得错误的数据范围。规则采用半开有效期 `[validFrom, validTo)`；同一委托身份下，全局规则与流程专属规则不能在时间上重叠，避免一次任务解析出两个代理人。应用最高管理员 `super_admin` 不能被代理转授，代理身份必须保持相同业务角色并覆盖委托身份的审批 scope，规则时间窗不能超出目标 membership 自身的有效期。
-
-长期代理是任务创建时的分派策略，不是读取待办时动态套用的过滤器。提交预览显示实际代理人；预览令牌同时绑定发起用户、Native 环境、RoleSession 和活动 RoleSubject 的 key/revision，换人、切换身份或授权修订变化后不能复用。正式创建任务时把原审批人标记为已代理，并把规则 ID、有效期和原/代理 RoleSubject 快照冻结为活动参与者。规则在预览后发生变化会让提交失败并要求重新预览；数据库事务再次锁定委托身份并核对整份参与者快照，防止创建任务与撤销规则并发时产生漂移。生效规则的目标身份若失去节点角色、有效期或业务 scope，预览/提交明确失败，不静默回退给原审批人。撤销只影响新任务，已创建任务继续按冻结快照处理；有效期届满后普通代理人不能继续操作遗留任务，应用管理员可根据审计链重新分派或接管。首期只允许单跳代理，不递归追踪代理人的其他代理规则。
-
-任务内的参与者是一个持久化、有顺序、可审计的队列。原审批人、长期代理人、前/后加签人、转交人和任务代理人都记录 user、RoleSubject key/kind/revision、角色快照、来源参与者、状态与完成身份；长期代理参与者额外记录规则 ID 和冻结有效期。任务表的 `assignedRoleSubjectKey` 是当前活动参与者的索引投影：长期代理、转交或任务代理会切换待办归属；前加签先让加签人活动，后加签在原审批人通过后接棒；只有最后一个必需参与者通过，节点才继续流转。拒绝、退回、撤回和管理员终止会原子关闭剩余参与者，避免出现孤立待办。
-
-任务级转交、代理和加签不能只提交 userId，必须提交从平台目标查询获得的具体 `roleSubjectKey`。Kernel 再校验其 membership 修订、角色代码、审批操作权限和当前业务 scope；scope 值缺失时 fail-closed，主部门选择会规范化为实例的学院 scope。Admin 会按当前节点过滤可选身份，并展示完整参与者链。应用管理员仍可按既定规则绕过业务数据权限处理任务，但其操作会记录为真实完成 RoleSubject，不会改写被代理人的身份。
-
-## Provider 与自定义操作
-
-审批节点只保留简单声明。需要读取应用数据的审批人解析、动作可用性或业务校验，由应用后端实现 provider 契约。自定义操作由前端 contribution 声明表单和展示，执行器调用 NestJS App API；后端按 Principal/capability 执行 Data API 或外部系统逻辑并使用幂等键。自定义操作不扩展 Kernel 状态机，异步副作用交给事件。
-
-## 前端协议
-
-任务详情返回：
-
-- 当前定义与任务修订；
-- `operations`（含输入 JSON Schema、UI Schema、执行目标、可见/可用状态与刷新范围）；
-- fieldPolicy；
-- presentation；
-- assignee/代理/加签上下文；
-- 当前活动参与者与完整参与者链；
-- 提交所需 concurrency token。
-
-前端按协议展示，不需要复制内核状态机。协议允许扩展展示元数据，但内核始终校验动作是否合法。
-
-## 事件层
-
-表单数据增删改查、流程状态变化和定时器统一产生类型化事件。订阅目标是应用后端接口。平台负责签名、持久投递、重试、死信、暂停与重放；应用负责验签、幂等和业务处理。
-
-事件首先与业务变更写入同一事务的 outbox，再由 Worker 领取带租约的投递任务。网络失败、408、409、425、429 和 5xx 才进入指数退避；确定性 4xx 直接进入死信，`Retry-After` 优先于本地退避。人工重放要求幂等键，相同键只产生同一条投递：
-
-```bash
-openxiangda event subscription list
-openxiangda event delivery list --limit 100
-openxiangda event delivery replay <delivery-id> \
-  --idempotency-key incident-20260812-replay-1
-```
-
-应用管理员也可在标准“运行与诊断”页面暂停/启用事件订阅和定时事件，并对重试或死信执行重放。重放创建新 delivery，原记录保持不变，便于审计与关联排障。
-
-定时声明使用明确的六段 Cron、IANA 时区和不超过 64 KiB 的 payload，最短间隔为 60 秒。平台持久化 `nextDueAt / lastFiredAt` 和每次 firing，并在同一事务中推进 schedule、写 firing、outbox 与匹配订阅的 delivery；多实例并发扫描或本地并发触发，同一 `timer + scheduledAt` 最多产生一个事件。停机恢复会把遗漏时段合并为一次 firing，避免恢复后形成历史洪峰；Cron 或时区改变时按新声明重算下一次执行。
-
-本地开发不需要为了等待定时点临时修改 Cron。完整 `openxiangda dev` 会话中可执行：
-
-```bash
-openxiangda event timer list
-openxiangda event timer fire <timer-id>
-```
-
-该命令触发当前计划中的下一次 firing，仍然写 PostgreSQL 并经过真实 outbox、签名、Nest handler 和 receipt；它不接受远端环境，也不能在 `--ui-only` 使用。
-
-暂停是投递控制，不是丢弃开关：暂停生效后，新业务事件不为该订阅创建 delivery；并发边界上已经存在但尚未领取的 delivery 也不会被 Worker 领取，恢复后继续处理。Worker 的完成或失败更新必须匹配本次领取的 attempt/lease 代次，旧 Worker 超时返回不能覆盖接管后的结果。重放的唯一性范围是 `app + originalDeliveryId + idempotencyKey`，客户端重试同一个操作只返回原重放记录。
-
-Nest SDK 默认使用平台托管的持久化 receipt store：它复用当前事件订阅密钥，对 `claim / complete / release` 命令做 HMAC 签名，并把消费状态保存在平台数据库，因此 Pod 重启、滚动部署或多副本运行都不会退化为进程内去重，也不要求应用自建数据库。只有显式注入 `InMemoryOpenXiangdaEventReceiptStore` 时才使用本地进程内实现。
-
-处理器完成后才提交 receipt，异常会释放 claim 以便平台重试。仍在租约内处理的重复投递返回可重试错误；只有状态已经是 `succeeded` 的事件才返回成功重复。对于“外部副作用成功、回执提交前进程崩溃”的固有窗口，处理器仍应把 `event.id` 作为 Data API 受限事务的 `idempotencyKey`，或使用下游系统自己的幂等键；receipt 提供的是可靠的消费领取与完成记录，不虚构跨系统 exactly-once。
-
-## Provider 密钥轮换
-
-Provider 轮换采用部署驱动的双阶段协议。`workflow provider rotate` 只暂存下一版本；下次 Deployment 给新 Pod 同时注入当前密钥和 `_NEXT` 密钥，新 Pod 可验证两者。readiness 成功后平台原子提升下一版本；失败部署继续使用旧版本，不影响现网。API 和 CLI 从不返回轮换后的明文。
-
-```bash
-openxiangda workflow provider list --environment production
-openxiangda workflow provider rotate special-lab-reviewers \
-  --environment production \
-  --revision 3 \
-  --idempotency-key rotate-special-lab-20260812
-openxiangda deploy preproduction \
-  --backend-image registry.example.com/apps/my-app@sha256:...
-openxiangda promote <preproduction-deployment-id> production
-```

package/skills/openxiangda-v2-architecture/SKILL.md

@@ -1,30 +0,0 @@
----
-name: openxiangda-v2-architecture
-description: Design OpenXiangda 2.0 application boundaries and typed contracts. Use when creating an app, decomposing frontend and backend responsibilities, or changing Data, AuthZ, workflow, event, or deployment declarations.
----
-
-# OpenXiangda 2.0 Architecture
-
-Design one independently versioned application with the OpenXiangda Ant Design Pro v6 frontend baseline and NestJS backend. Do not introduce a Vite/custom-shell compatibility path for 2.0 applications.
-
-## Design Sequence
-
-1. Inspect the workspace with `openxiangda app info`.
-2. Define business aggregates and invariants in `packages/domain`.
-3. Declare Data API resources, capabilities, policies, workflow definitions, event subscriptions, and timers in `openxiangda.config.ts`.
-4. Keep synchronous user interactions in App APIs; move retryable side effects to event consumers.
-5. Use a workflow provider when assignee resolution or a workflow action depends on application data.
-6. Generate types with `openxiangda generate`, then run `openxiangda check`.
-7. For Admin changes, keep Ant Design Pro/Umi responsible for generic UI structure and OpenXiangda responsible for identity, authorization, Data, Workflow, lifecycle and delivery contracts.
-
-## Required Decisions
-
-- Name every resource, capability, event type, workflow, and provider with a stable application-scoped code.
-- Separate business data from workflow runtime state.
-- Define the authorization context needed for each operation, including active role and data attributes.
-- Define idempotency and concurrency behavior before implementing writes.
-- Define health, readiness, and rollback expectations as part of the application contract.
-
-Do not design environment-specific code paths. Environment values and secrets are injected by the platform at deployment time.
-
-Read [Concepts](../../docs/concepts.md) before introducing a new platform-facing contract. Read the [Ant Design Pro v6 cutover decision](../../docs/architecture/ant-design-pro-v6-admin-foundation.md) before changing the frontend foundation.

package/skills/openxiangda-v2-architecture/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "OpenXiangda 2.0 Architecture"
-  short_description: "Design typed OpenXiangda 2.0 application boundaries"
-  default_prompt: "Use $openxiangda-v2-architecture to design this OpenXiangda 2.0 application."

package/skills/openxiangda-v2-backend/SKILL.md

@@ -1,48 +0,0 @@
----
-name: openxiangda-v2-backend
-description: Build the standard OpenXiangda 2.0 NestJS application backend. Use when implementing App APIs, Data API transactions, identity-aware business services, event consumers, health checks, or external integration endpoints.
----
-
-# OpenXiangda 2.0 Backend
-
-Build a normal NestJS service in `apps/server`. The platform deploys one container per application and injects identity, platform endpoints, environment configuration, and secrets.
-
-## Request Path
-
-1. Use the platform guard to verify the user token and construct typed request context.
-2. Authorize the capability and contextual data policy before accessing records.
-3. Keep invariants in domain services, not controllers.
-4. Use Data API for persistence and its restricted transaction endpoint for atomic batches.
-5. Require revision or idempotency keys for retryable writes.
-6. Return stable application contracts and structured errors.
-7. Use single-record reads for details, bounded aggregate queries for reports,
-   and the durable business-audit endpoint for history. All remain scoped to
-   the request RoleSession.
-8. For attachments, initiate a platform-managed upload, upload to the signed
-   plan, complete verification, and persist only the returned `DataFileRef`.
-9. For DingTalk school-contact relations, call the typed platform client from
-   the NestJS backend with the verified authorization and RoleSession. Expose
-   only an application App API to the browser; never call the platform relation
-   endpoint from React.
-
-## Runtime Path
-
-- Expose liveness and readiness endpoints.
-- Consume platform events with signature verification and durable idempotency.
-- Keep outbound integrations behind adapters with timeouts and correlation IDs.
-- Declare external credentials in `backend.secrets`; create values with
-  `openxiangda secret create` and rotate them with
-  `openxiangda secret rotate`, using `--from-env` or `--from-file`.
-- Read secrets only from injected environment references; never place values in
-  source, command arguments, application packages, logs, or browser responses.
-- Treat `OPENXIANGDA_OAUTH_CLIENT_*` as platform-reserved workload identity.
-  Inspect it with `openxiangda oauth runtime status --environment <key>` and
-  rotate it with `openxiangda oauth runtime rotate --environment <key>
-  --idempotency-key <stable-key>`. The platform stages by credential-version
-  CAS and rolls the same active AppVersion; no Secret is returned to the CLI.
-
-Use `openxiangda dev` for local orchestration. Run `openxiangda check`, `openxiangda test`, and `openxiangda build --backend-image <immutable-image>` before deployment.
-
-Read [Backend](../../docs/backend.md) for the standard module layout. For
-guardian, student, and class relationships, read
-[School contact relations](../../docs/school-contact-relations.md).

package/skills/openxiangda-v2-backend/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "OpenXiangda 2.0 Backend"
-  short_description: "Build standard NestJS application backend services"
-  default_prompt: "Use $openxiangda-v2-backend to implement this OpenXiangda 2.0 backend."

package/skills/openxiangda-v2-data-authz/SKILL.md

@@ -1,58 +0,0 @@
----
-name: openxiangda-v2-data-authz
-description: Design OpenXiangda 2.0 Data API and contextual authorization contracts. Use for RBAC, active-role behavior, department or record attributes, application-admin bypass, field policies, and restricted transactions.
----
-
-# OpenXiangda 2.0 Data and AuthZ
-
-Model permissions as capability checks plus contextual data predicates. A role grants capabilities; policies decide which records and fields are available in the current role context.
-
-## Authorization Model
-
-1. Declare application roles and stable capability codes.
-2. Treat the selected active role as part of each request. Do not silently union all user roles.
-3. Resolve subject attributes such as departments and managed colleges from trusted platform or application providers.
-4. Resolve resource attributes such as instrument manager and college from the target record.
-5. Express allow rules as explicit subject, action, resource, and environment predicates.
-6. Grant application administrators the declared application-admin bypass and audit every bypassed write.
-7. Batch page-level authorization decisions under one RoleSession; never reuse
-   them after an identity switch and fail closed on transport or schema errors.
-
-## Data Rules
-
-- Declare resources and fields in `openxiangda.config.ts`; generate types with `openxiangda generate`.
-- Prefer server-enforced filters and field policies over client filtering.
-- Use revision checks for updates and restricted transaction batches for related writes.
-- Keep policy tests for multiple roles, role switching, cross-department denial, and administrator access.
-- Require the application directory capability before using department or user
-  selectors. Store stable IDs and resolve display labels through Directory v2;
-  do not copy tenant contact data into application records.
-- School-contact access defaults to unrestricted `all` for a verified
-  non-guest Principal/RoleSession even when no `school-contact:*` scope
-  capability is assigned. Use `school-contact:self:read` or
-  `school-contact:class:read` only when the product explicitly requires a
-  narrower scope; keep the application's own App API behind its normal
-  business-operation capability and rely on the platform query boundary, not
-  browser filtering.
-- The synchronized platform identities `SCHOOL_GUARDIAN`, `SCHOOL_STUDENT`,
-  and `SCHOOL_TEACHER` are additive `platformRoleCodes` on the trusted
-  Principal/RoleSession context, not selectable application `roleCodes`.
-  They are maintained by the platform sync and are unrestricted by default;
-  use them only for an explicit server-side identity check.
-- Apply field policies consistently to queries, search controls, forms, CSV
-  transfer and restricted transactions.
-- Use the bounded server-side aggregate endpoint for charts and summaries. Only
-  declare readable fields, explicit aliases, supported measures and a small
-  result limit; never fetch all records into the browser to aggregate them.
-- Read record history from the durable business-audit endpoint. It is still
-  row- and field-authorized for the current RoleSession; do not invent a second
-  client-side audit log.
-- Model attachments as `file` fields containing platform `DataFileRef` values.
-  Use signed initiate/upload/complete, then save the reference through normal
-  Data API writes. Download only through the authenticated Data API endpoint.
-
-Run `openxiangda check` and `openxiangda test` after every policy or schema change.
-
-Read [Data and Authorization](../../docs/data-authz.md) for policy examples and
-[School contact relations](../../docs/school-contact-relations.md) for the
-guardian/student contract.

package/skills/openxiangda-v2-data-authz/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "OpenXiangda 2.0 Data and AuthZ"
-  short_description: "Model Data API contracts and contextual authorization"
-  default_prompt: "Use $openxiangda-v2-data-authz to design this application's data authorization."

package/skills/openxiangda-v2-delivery/SKILL.md

@@ -1,88 +0,0 @@
----
-name: openxiangda-v2-delivery
-description: Validate, build, deploy, observe, promote, retry, and roll back an OpenXiangda 2.0 application. Use when preparing an immutable AppPackage or changing a platform-managed environment.
----
-
-# OpenXiangda 2.0 Delivery
-
-Deliver the whole application as one immutable version. The client submits intent; the platform owns durable execution and environment state.
-
-## Preflight
-
-1. Run `openxiangda doctor` and confirm client/platform contract compatibility.
-2. For a first deployment only, confirm an authorized platform administrator has run `openxiangda app provision`.
-   Provisioning creates only `preproduction`; do not assume `production` exists.
-3. Run `openxiangda generate --check`, `openxiangda check`, and `openxiangda test`.
-4. Build and push the backend image; use an immutable digest reference.
-5. Run `openxiangda build --backend-image <immutable-image>` and retain the returned package digest.
-6. Confirm every required `backend.secrets` declaration exists and is active in
-   the target environment. Missing optional values are intentionally skipped.
-7. Do not copy or mutate `.openxiangda/build` artifacts after sealing. Deploy
-   re-hashes the package, component manifests, artifact bytes, frontend files,
-   backend image declaration, and config/contracts inventory before upload.
-
-## Deployment
-
-- Inspect the plan before changing an environment.
-- Use `openxiangda deploy` only with explicit user authorization.
-- Follow the durable run with `openxiangda status` and `openxiangda logs`.
-- Use `openxiangda retry` only for retryable failed runs.
-- Use `openxiangda cancel <deploymentId>` to stop an obsolete or blocked run before submitting a replacement package.
-- Use `openxiangda promote` to move the exact same application version between environments.
-- Use `openxiangda environment status` as the authoritative environment inventory.
-- Use `openxiangda environment stop <environment>` to scale an idle environment to zero without deleting data, configuration, the active Head, or history. Use `start` to restore that same Head.
-- Production is created only by the first explicitly authorized promotion. Never create or infer it from workspace configuration.
-- Use `openxiangda rollback` to create a new run that activates a known historical version.
-
-Do not rebuild during promotion or rollback. Do not expose injected secrets in logs, manifests returned to clients, or package metadata.
-Provider key rotation is finalized by a successful deployment, not by the rotate
-command itself. A failed deployment must leave the currently active key intact.
-
-## Toolchain release
-
-When changing or publishing OpenXiangda 2.0 itself, first run
-`pnpm release:version` from a clean, up-to-date `master`. Review, commit, and
-push the generated package/template version diff; the command itself never
-commits or publishes. Only then run `pnpm release:plan`. Planning, validation,
-and publishing fail before builds while reviewed Changesets remain
-unmaterialized. The gate is native to the independent 2.0 repository and must
-not invoke 1.x compatibility suites. The
-plan compares current npm tarballs before expensive tests, rejects changed
-published versions, compares candidates with their nearest earlier release and
-maps actual artifact differences to deterministic gates. Candidate dependency
-closures always check/test/build; every candidate tarball is installed outside
-the monorepo into a newly generated application. Admin/browser changes require
-Chromium, core application SDK changes require the independent reference app,
-and Skill Kit changes require Skills/docs. Unknown or first-release packages
-fail closed to the full matrix. Run `pnpm verify:release:full` for the periodic
-complete audit. `pnpm verify:release` freezes one candidate artifact manifest,
-runs the formal gate once, and leaves a validated receipt bound to the exact
-HEAD, registry, mode and tarball digests. `pnpm release:publish` requires that
-receipt, repeats only immutable/concurrency preconditions, and publishes those
-exact bytes without rerunning the formal gate. Use `verify:release:full` only
-with `release:publish:full`. The final publish command repeats version
-availability before writing npm, so concurrent publication cannot invalidate
-the reviewed plan. It never modifies the independent reference worktree;
-`pnpm release:sync-reference` is an explicit post-publication repository task.
-`pnpm distribution:smoke` runs only this packed-distribution verification.
-Keep `strictDepBuilds: true` in the official workspace and template. Permit only
-reviewed dependency lifecycle scripts (`esbuild` today); never suppress the
-warning with a broad allow-all setting. The packed gate must fail if a fresh
-install reports an ignored build script.
-
-If the same release train changes the OpenXiangda 2.0 platform server, run its
-`npm run verify:openxiangda-v2:release` gate before the independent toolchain
-gate. It must validate SQL migrations, discover every platform v2 suite, run
-the shared HTTP/storage security suites, compile without pulling in the 1.x
-baseline, and complete the real OAuth2/Data API/App API/Events/Workflow HTTP
-chain once. That live chain already contains backend/service restart recovery,
-receipt takeover and concurrent Workflow command scenarios, so repeating the
-same suite is not a substitute for deterministic tests. A successful clean
-commit may reuse its exact local verification receipt for 24 hours; any source,
-step plan or runtime fingerprint change reruns the complete gate. The platform
-root release script invokes this gate automatically only when Platform Server
-is in its resolved image build plan, before any Docker candidate is created.
-Passing either local gate is evidence for review, never authorization to commit,
-publish, or deploy.
-
-Read [Delivery](../../docs/delivery.md) for gates and failure handling.

package/skills/openxiangda-v2-delivery/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "OpenXiangda 2.0 Delivery"
-  short_description: "Build deploy observe promote and rollback whole apps"
-  default_prompt: "Use $openxiangda-v2-delivery to validate and deploy this OpenXiangda 2.0 application."

package/skills/openxiangda-v2-frontend/SKILL.md

@@ -1,50 +0,0 @@
----
-name: openxiangda-v2-frontend
-description: Build OpenXiangda 2.0 Ant Design Pro desktop Admin and separate mobile user experiences. Use for routes, menus, data pages, platform fields, role switching, workflow pages, or application actions.
----
-
-# OpenXiangda 2.0 Frontend
-
-Build in `apps/web` with React 19, Ant Design 6, Umi Max 4 and ProComponents 3. `openxiangda-admin` is the platform integration layer. Do not preserve or recreate the former Vite/custom-shell implementation or any 1.x compatibility path.
-
-## Desktop Admin
-
-1. Keep one route fact source. In the official template, edit `apps/web/config/routes.ts`; Umi routes, menu items and tab descriptors must derive from it. Do not hand-maintain a second path/menu tree.
-2. Use `OpenXiangdaAdminProvider` and `AdminLayout` from `openxiangda-admin/core`. Use the platform Principal and one active RoleSession; switching role replaces the current permission/data context instead of merging roles.
-3. Use capability codes only for UI visibility. The Data API, App API and Workflow API remain authoritative and must reject unauthorized requests independently.
-4. Prefer `ResourceTablePage`, `ResourceFormPage` and `ResourceDetailPage` from `openxiangda-admin/data` for normal management pages. They provide ProTable server pagination/filter/order, ProForm, revision/CAS, field policies, platform rendering and audit history.
-5. Set `allowCreate`, `allowUpdate` or `allowDelete` to false when a business operation is owned by a workflow or NestJS endpoint. Route the page action to the real owner; never offer a generic Data API write that bypasses derived fields or state transitions.
-6. Use `WorkbenchPage` from `openxiangda-admin/dashboard`. Production metrics and ECharts series must come from bounded server-side aggregation under the current RoleSession.
-7. Use `WorkflowSubmissionPage` for approval submission. The normal page shows a business form and one primary submit action. Save through Data API/App API first; only then call prepare and open a Modal with the real path and unresolved department/approver choices. Never keep approval preview visible before submit.
-8. Use `WorkflowWorkCenterPage`, `WorkflowTaskPage` and `WorkflowInstancePage` for Kernel surfaces. Render Kernel operations exactly as returned. Application business actions use `loadAppActions` and `executeAppAction`; they must be `app_action`, cannot override Kernel keys, and must execute through an authorized NestJS App API.
-9. Import narrow browser-safe entrypoints: `openxiangda-admin/core`, `/navigation`, `/data`, `/dashboard`, `/workflow`, `openxiangda-devkit-core/client`, and `openxiangda-contracts/browser`.
-10. Admin is desktop-only. Do not spend scope on squeezing ProLayout/ProTable into a phone layout.
-
-## Platform fields and mobile user UI
-
-1. Use `openxiangda-field-kit/desktop` in the desktop Admin. Build the independent mobile tree with `OpenXiangdaUserProvider` from `openxiangda-user` and the standard pages from `openxiangda-user/mobile`; those pages consume `openxiangda-field-kit/mobile`. Mobile is not a CSS-responsive copy of the Admin.
-2. Before choosing a field, read [Platform field components](../../docs/field-components.md) or the exported `fieldCatalog`. It records every kind's value contract, when to use it and when not to use it.
-3. Platform fields include text/textarea/richtext, number/money/percent, boolean, single/multiple select, radio/checkbox/cascade, date/datetime/date range, user/users, department/departments, address/location, image/attachments, signature, subtable/JSON, serial and workflow status. The association-form/relation platform component is discontinued; use option/radio for ordinary choices or an application page plus App API for complex relation queries.
-4. Persist established stable values. Directory and option values use `{ label, value }`; address, location and attachment values use the `openxiangda-field-kit` types. Never replace them with display-only strings or Ant Design component instances.
-5. Personnel, departments, administrative divisions, uploads, downloads and previews must use platform APIs. Do not copy platform directory data or write a second upload protocol. Do not use Ant Upload or a raw file input in an application page for a persistent file field.
-6. Use `attachments` for general files and `images` when thumbnail/preview/photo selection is required. The DataResource field must be `file`. Rich-text local images require `richTextImageFieldCode` pointing to a companion `file` field so uploaded files bind with the saved record.
-7. Keep database declarations minimal: field code, storage type, nullability, index and storage constraints. Required/default/hidden/layout/help/conditional display are page behavior. A custom page may implement different UI validation, so critical business rules must also be enforced by NestJS/Data API policy.
-8. Render list/detail values by field kind. Show readable labels, tags, formatted dates/numbers/amounts, address text, user/department identity, image preview and attachment download instead of raw JSON or internal IDs.
-9. Prefer `MobileAppShell`, `MobileWorkbenchPage`, `MobileResourceListPage`, `MobileResourceFormPage`, `MobileResourceDetailPage`, `MobileWorkflowSubmissionPage`, `MobileWorkflowWorkCenterPage`, `MobileWorkflowTaskPage` and `MobileWorkflowInstancePage`. The Workflow submission page must show only the business form and one Submit action until save and prepare succeed; only then open the approval preview.
-10. Keep the mobile package out of NestJS dependencies. The browser may call only platform-relative Native clients under the current RoleSession; it must not persist platform tokens, service addresses, permission decisions or business responses.
-
-## Verification
-
-After contracts or pages change, run:
-
-```bash
-openxiangda generate
-openxiangda check
-openxiangda test
-pnpm --filter @app/web test:e2e
-pnpm --filter @app/web build
-```
-
-Use accessible role/label locators rather than private Ant Design DOM classes. The current desktop Chromium gate covers shell, menu, tabs, stable role switch, data list/detail, full-page form, workflow work center/submission and personal center. When adding a mobile user template, add a separate mobile-device Chromium gate; do not claim mobile completion from the desktop suite.
-
-Production source/dependency audits must reject Vite, the former AdminShell, template fake users, Umi Mock APIs and development Secrets. Read [Frontend](../../docs/frontend.md) and [Ant Design Pro v6 cutover](../../docs/architecture/ant-design-pro-v6-admin-foundation.md) before changing the foundation.

package/skills/openxiangda-v2-frontend/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "OpenXiangda 2.0 Frontend"
-  short_description: "Build standard React and Ant Design application pages"
-  default_prompt: "Use $openxiangda-v2-frontend to implement this OpenXiangda 2.0 frontend."

package/skills/openxiangda-v2-workflow-events/SKILL.md

@@ -1,56 +0,0 @@
----
-name: openxiangda-v2-workflow-events
-description: Implement OpenXiangda Workflow Kernel v2 and durable application events. Use for approval definitions, assignee providers, task actions, delegation, add-sign, previews, data-change events, workflow events, or timers.
----
-
-# OpenXiangda 2.0 Workflow and Events
-
-The workflow kernel owns definitions, instances, tasks, transitions, delegation, add-sign, audit, and field policies. The application owns business records and application-specific logic.
-
-## Workflow
-
-1. Declare approval and conditional nodes in `openxiangda.config.ts`.
-2. Use provider contracts for application-data-dependent assignee resolution and custom action decisions.
-3. Use `WorkflowSubmissionPage` when the flow starts from a business form.
-   Persist the draft first through Data API/App API and return a revision-bound
-   snapshot; bind preview readiness to that snapshot plus all submission
-   answers. Reuse one idempotency key across a failed save retry and a separate
-   stable key across a failed start retry.
-4. Return protocol `operations`, field policies, presentation hints, execution targets, and concurrency tokens from the backend. Task and instance operations may coexist on one Surface; dispatch them to their declared task/instance command scope.
-5. Persist business changes through Data API or App API, then correlate them to
-   the workflow action. The Kernel never stores business fields or silently
-   projects business status; use an App API or workflow event consumer for the
-   latter.
-6. In full local development, persist preparation tokens, instances, tasks,
-   timelines, delegations, and command receipts in PostgreSQL. Commit instance
-   and task CAS updates atomically; scope idempotency to the command, request,
-   and immutable Native RoleSubject so restart replay cannot cross identities.
-7. Test approve, reject, transfer, return, resubmit, delegation, add-sign, initiator withdrawal, admin termination, duplicate requests, stale revisions, restart replay, and concurrent commands.
-8. Rotate application Provider signing keys with `workflow provider rotate`,
-   then deploy. During that deployment the Nest adapter must accept both current
-   and `_NEXT` secrets; the platform activates the next version after readiness.
-
-## Events
-
-- Subscribe to typed data and workflow events; implement idempotent consumers.
-- Declare timers with an explicit six-field Cron expression, an IANA timezone,
-  and a bounded object payload. Use them as durable event producers rather than
-  adding an application-owned scheduler.
-- In a full local `openxiangda dev` session, use
-  `openxiangda event timer fire <timer-id>` (or MCP `fire_local_timer`) to test
-  the next persisted occurrence without editing the schedule. Confirm the
-  resulting delivery with `event delivery list`; UI-only mode is not evidence.
-- Verify signatures, propagate correlation IDs, and fail retryably for transient dependencies.
-- Never assume event ordering unless the contract explicitly provides a partition key.
-- Inspect dead letters with `event delivery list` and replay with a stable
-  idempotency key. Do not retry deterministic 4xx failures in a consumer loop.
-- Keep the default platform-backed durable receipt store in production. It uses
-  the subscription HMAC secret and survives Pod restarts and multiple replicas;
-  inject `InMemoryOpenXiangdaEventReceiptStore` only in local tests.
-- Treat an in-flight duplicate as retryable, not successful. Use `event.id` as
-  the Data API transaction or downstream idempotency key for side effects that
-  can succeed before the receipt completion request reaches the platform.
-
-Use `openxiangda generate`, `openxiangda check`, and `openxiangda test` to keep providers and event payloads aligned.
-
-Read [Workflow and Events](../../docs/workflow-events.md) for protocol details.

package/skills/openxiangda-v2-workflow-events/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "OpenXiangda 2.0 Workflow and Events"
-  short_description: "Implement workflow providers and durable event consumers"
-  default_prompt: "Use $openxiangda-v2-workflow-events to implement this workflow and event behavior."