openxiangda 1.0.264 → 2.0.0-alpha.2

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

@@ -1,137 +0,0 @@
----
-name: openxiangda-architecture-design
-description: Design OpenXiangda / 享搭 / 私有化低代码 applications before implementation. Use when the user asks for 架构设计 / 详细设计 / 开发方案 / 技术方案 / 应用设计 / 新应用 / 空应用 / 需求文档转享搭应用 / PRD 转开发计划 / form-page-workflow-permission-data-view planning, or when a non-trivial OpenXiangda app should be planned before coding. Produces an OpenXiangda-specific architecture document, detailed design, and task plan; repeatedly asks design-gate questions; challenges bad product assumptions such as fetching 1000 rows then local filtering, workflow forms for ordinary status changes, frontend-only permissions, or unbounded dashboard queries.
----
-
-# OpenXiangda Architecture Design
-
-Use this skill before building a non-trivial OpenXiangda app or turning product requirements into implementation tasks.
-
-This is an architecture gate, not a generic PRD writer. Convert the user's material into OpenXiangda resources: forms, fields, pages, menus, permissions, data views, workflows, automations, JS_CODE nodes, App Functions, notifications, connectors, and publish/test tasks.
-
-## Required Reference
-
-Before producing a final architecture document, read:
-
-- `references/architecture-design.md`
-
-Read these supporting references when the design touches the topic:
-
-- `references/best-practices.md`
-- `references/architecture-patterns.md`
-- `references/data-views.md`
-- `references/permissions-settings.md`
-- `references/permission-design-patterns.md`
-- `references/workflow-v3.md`
-- `references/automation-v3.md`
-- `references/notifications.md`
-- `references/pages/page-sdk.md`
-- `references/forms/form-schema.md`
-
-## Operating Mode
-
-Be the technical architect. Do not passively accept product requirements when they conflict with platform constraints, performance, permissions, or maintainability.
-
-Keep the tone direct and critical about the design, but do not insult the person. Acceptable: "这个方案不能这样做，会把查询压力和权限风险推到前端。" Not acceptable: personal attacks.
-
-## Plan-Gate Hard Rule
-
-Architecture-class requests are planning-only until the user explicitly confirms the design.
-
-This includes new apps, complex pages, login/register, public/no-login access, roles/data scopes, workflow/automation, App Function, connector, notification, and external integration work.
-
-Before confirmation you may only:
-
-- read files and docs
-- inspect `.openxiangda/state.json`
-- run read-only snapshots/doctor commands
-- run `openxiangda design gates --topic <code> --json`
-- run `openxiangda resource validate|plan` or other dry-run commands
-- ask focused design-gate questions
-- output or write the design artifact
-
-Before confirmation you must not:
-
-- edit app source files
-- create/update/delete platform resources
-- publish workspace/resources/runtime
-- send notifications
-- call live write/delete endpoints
-- start implementation subskills
-
-Once the user confirms, hand execution to the relevant implementation skill and use the resource commands documented in `references/resource-manifest-cheatsheet.md`.
-
-## Non-Negotiable Rules
-
-- Do not design list pages, option searches, linked-form choices, or report drill-downs that fetch 1000 rows and filter in local state. Use paginated queries, explicit filters, sort, and server-side search fields.
-- Do not default to `searchKeyWord` for broad fuzzy search. Prefer explicit searchable fields and structured `filterGroup` conditions.
-- Do not use workflow forms for ordinary business lifecycles. Use normal forms, status fields, state machines, responsibility fields, action logs, permissions, and automations. Use workflow only for real approval semantics.
-- Do not put sensitive authorization in page conditions only. Use page permission groups, form permission groups, backend data scope, and field access policy when data is sensitive.
-- Do not design account/role/permission requirements without choosing a permission mode first: `managed-platform-account`, `existing-platform-user-assignment`, `static-role-permission`, or `query-param-context`.
-- Do not treat query parameters as sensitive authorization. They may provide context, filters, or ticket input only; sensitive reads/writes still need public-access grants, roles, form permission groups, or App Function checks.
-- Public guest upload must use a structured `grants.forms` entry with the logical form code, explicit `upload`/`preview`/`download` actions, and optional field IDs. Never whitelist `/file/upload`; `AttachmentField` / `ImageField` supply form context that the backend compares with the signed guest claim and current live policy.
-- Do not put repeated multi-form joins or fixed dashboard metrics into page-side loops. Use Data View when the query is reusable and read-only; choose `live` or `materialized` deliberately.
-- Do not scatter reusable backend logic in pages or JS_CODE nodes. Use App Functions for logic shared by pages, automations, and workflows. Use JS_CODE V2 for node-local backend trigger logic.
-- Do not design raw native form controls for AI-authored workspace code. Use OpenXiangda platform form components first, then Ant Design / antd-mobile wrappers.
-
-## Workflow
-
-1. Ground in the current state:
-   - If a workspace exists, inspect `.openxiangda/state.json`, `app-workspace.config.ts`, and relevant `src/` resources before designing.
-   - If this is an existing app, use snapshots/read-only inspection before proposing changes.
-   - If this is a blank app, explicitly state that the design is greenfield.
-   - Run `openxiangda doctor --json` when the CLI/workspace is available.
-2. Extract the domain:
-   - Actors and roles.
-   - Business objects that should become forms.
-   - Status lifecycles versus true approval workflows.
-   - Pages, menus, PC/mobile entrances, and reporting surfaces.
-   - Backend logic, notifications, integrations, and scheduled work.
-3. Build an OpenXiangda resource map:
-   - Forms and fields.
-   - Pages and routes.
-   - Roles, permission groups, data scopes, and field permissions.
-   - Data Views with mode, query shape, freshness, indexes, and permissions.
-   - Workflows, automations, JS_CODE nodes, App Functions, notifications, connectors, and settings.
-4. Ask design-gate questions in rounds. Do not produce the final design while high-impact unknowns remain.
-   Use `openxiangda design gates --topic <code> --json` to get the current question matrix and recommended defaults.
-5. Challenge bad assumptions. Give the cost, reject the unsafe implementation path, and propose the OpenXiangda-native alternative.
-6. For frontend-heavy pages, ask whether a visual/interaction design pass is needed. If Product Design or another UI design skill is available, route design work there before page implementation.
-7. Write the final artifact by default when a workspace exists:
-   - `docs/architecture/<app-slug>-openxiangda-design.md`
-   If there is no workspace or safe target path, output the document in the conversation and ask for the destination before writing files.
-
-## Design Gates To Resolve
-
-Resolve these before finalizing:
-
-- Data volume, pagination, searchable fields, sort fields, and expected indexes.
-- Role model, data sensitivity, backend-enforced data scope, and field visibility.
-- Account source, role membership source, permission design mode, and whether platform accounts/departments are created by the app.
-- Which roles can manage roles, assign role members, grant role API permissions, maintain permission groups, or manage organization accounts; list the required `apiPermissionCodes`.
-- Permission matrix for pages/routes, form submit/view/manage, data scope, field access policy, backend App Function checks, and query parameter tamper-deny tests.
-- Which flows are status machines and which are real approvals.
-- Report freshness: real-time live view, materialized refresh cadence, or manual snapshot.
-- Whether dashboards and joins are bounded enough for Data View.
-- Which logic belongs in page services, App Function, automation, workflow, or JS_CODE V2.
-- Notification channels, recipients, trigger timing, and template payloads.
-- PC/mobile split and whether Product Design / visual mockups are required.
-- Publish profile, acceptance criteria, and demo/test path.
-
-## Final Output
-
-The final design must be decision-complete. Include:
-
-- Architecture overview and OpenXiangda resource map.
-- Form and field design with storage shape, hidden scope keys, searchable fields, and pagination strategy.
-- Permission design with page groups, form groups, data scope, and field access policy.
-- Permission mode decision with account source, role assignment source, business scope fields, hidden scalar keys, query-parameter boundary, and backend role/scope checks.
-- Delegated role-setting design: which administrator role is first granted by a platform/app admin, which `apiPermissionCodes` it receives, and whether roles it creates can further delegate management.
-- Page/menu/UX design, including PC/mobile and design mockup decisions.
-- Data access and Data View plan with `live` / `materialized`, refresh, indexes, and runtime SDK calls.
-- Status machine, workflow, automation, JS_CODE V2, and App Function plan.
-- Notification and connector plan.
-- Development task table with order, files/resources, validation, and publish steps.
-- Open questions and confirmed assumptions.
-
-After the design is accepted, hand off execution to the relevant OpenXiangda subskills. Do not skip the design gate for complex applications.

package/openxiangda-skills/skills/openxiangda-core/SKILL.md

@@ -1,222 +0,0 @@
----
-name: openxiangda-core
-description: Core OpenXiangda CLI workflow for profiles, login, workspace state, precise planning, release, runtime deployment, and version diagnostics.
----
-
-# OpenXiangda Core
-
-Use this skill for login/profile/state questions and any plan, publish, deploy, or release operation. It intentionally contains only release-critical rules; load domain skills for forms, pages, permissions, Functions, Automation, or Workflow behavior.
-
-## Delivery V2
-
-If `app-workspace.config.ts` declares `deliveryVersion: 2`, this section
-overrides the V1 release material below. The normal flow has no SDD, Git clean,
-mainline ancestry, explicit change id, `--only`, candidate, or ship gate:
-
-```bash
-openxiangda check --environment preproduction
-openxiangda deploy preproduction --json
-openxiangda deploy production --package <packageDigest> --json
-```
-
-Use `openxiangda status <runId>` and `openxiangda retry <runId>` for a failed or
-interrupted run. Use `openxiangda rollback <environment> --to <appReleaseId>`
-for rollback. Never ask the AI to choose or sequence low-level
-`workspace/resource/runtime/app-finalize` commands for a V2 release.
-
-`check --json` is the authoritative preflight: inspect its exact resource delta
-and ordered plan. Deletes and authored third-party build dependencies are
-unsupported and fail before remote writes. V2 executes authored builds with the
-CLI-sealed toolchain, never a workspace `node_modules` or custom builder.
-`status`/`retry` auto-resolve the run environment if omitted. Retry preserves
-completed checkpoints, fences the older attempt, and replays only local Form
-bindings when resuming on a different machine. Deterministic Runtime build IDs
-combine the Runtime layer and sealed package digests, preventing provenance
-collisions across packages with identical Runtime bytes. An `uploaded` release
-is reused only for an exact same-package retry when its content hash, source
-revision, and parent Runtime release match; all other identities fail closed.
-
-## Resolve the boundary
-
-Before a write or release, establish all four values:
-
-- workspace root;
-- explicit profile;
-- bound `appType` for that profile;
-- one change id and its base revision.
-
-```bash
-openxiangda env --profile <name>
-openxiangda auth status --profile <name>
-openxiangda sdd context --change <change> --changed --json
-```
-
-Run `openxiangda update check --json` once per substantial task, on a suspected mismatch, or when the cached check is older than one day. If an update is installed, refresh skills once with `openxiangda skill install --force`.
-Use `openxiangda update install` for the upgrade itself so npm reuses its cache, skips peer-resolution stalls and auxiliary audit/fund requests, reports a heartbeat, and exits on a bounded timeout. A bare `npm install -g` is only the bootstrap fallback before the CLI exists.
-
-Every write/release command must include `--profile <name>`. In a shared app repository the canonical main checkout is integration/release-only; parallel tasks develop in isolated Git worktrees/branches and never stash or restore another task's files. Merge approved commits into the authoritative remote default branch, create one `sdd bundle` for the intended changes, commit/push it, and publish once from a clean local `main`/`master` that exactly equals the remote tip.
-
-After merge, push, release, and `release end`, return to the canonical main checkout and run `openxiangda workspace cleanup`. Apply only the exact reviewed `SAFE` plan. The CLI revalidates OpenXiangda/Codex-managed worktrees under the owner lock and leaves newly-safe, malformed-owner, unmerged, dirty, journal-bearing, and stale-record entries untouched. It never runs global `git worktree prune`; review stale records separately. Never remove a worktree directory directly; local task branches close with the worktree, while remote branches follow the repository retention policy.
-
-Keep investigation proportional: one complete CodeGraph survey plus at most one focused follow-up, normally one domain subskill, and no optional prose for a request whose requirements and acceptance criteria are already explicit. Unchanged lease waits should use `task status --watch` and emit only material transitions.
-
-SDD is structured-first by default: only `change.json`, `coverage.json`, and `release.json` are created. Generate optional prose with `openxiangda sdd render <change>`; missing checklist/evidence/spec prose is a warning, while approval, exact structured scope, actual argv, mainline identity, child CAS, lease, and atomic activation remain hard gates. Set `strictDocumentation: true` only when prose completion must intentionally block a workspace.
-
-First-class direct configuration writes (form/page/menu/role/permission/workflow/connector/notification/auth/route/public-access/scope/data-view/storage/settings) also require `--change <id>` or a complete stored session created by `openxiangda release begin --change <id>`. Missing context fails locally with `PUBLISH_CONTEXT_REQUIRED` before any HTTP write. Dry-run, schema planning, validation, query/invoke/export/submit/execution/upload, and other data-plane actions do not acquire a lease. Direct Workflow publish/unpublish/delete additionally requires the frozen `--expected-revision`; never fetch the latest revision merely to replay an older payload.
-
-## Exact planning
-
-Use the same change id for every stage:
-
-```bash
-openxiangda workspace plan --profile <name> --change <change> --changed --json
-openxiangda workspace check --profile <name> --change <change> --changed
-openxiangda sdd verify <change> --changed --stage implementation
-```
-
-The approved change scope, not the checkout's global dirty set, is the release boundary. If another change owns a file/resource or the remote revision moved, stop and re-plan.
-
-Treat `scopes.changedResources`, `scopes.runtimeDependencies`, and `scopes.deployTargets` as different contracts. The first owns changed files/resources, the second records shared/transitive impact, and only the third authorizes writes. Dependency analysis may fail closed when an impact was not declared, but it must not silently expand `deployTargets`. Candidate preflight runs release-plan and SDD prepublish checks before source freeze or remote candidate/deployment writes; failure leaves reviewed SDD and private execution state untouched.
-
-For React SPA releases that contain both Form settings and form permission groups, keep them in one immutable FormRelease command: `resource publish form-setting,form-permission-group --only form-setting:<form>,form-permission-group:<group>`. The SDD generator and prepublish/actual-argv validators use this same canonical qualified-selector contract; missing, extra, split, unscoped, or directly activated Form resources remain blocked.
-
-For engineering resources, select type and exact codes:
-
-```bash
-openxiangda resource validate function --only function_a,function_b --profile <name>
-openxiangda resource plan function --only function_a,function_b --profile <name> --json
-openxiangda resource publish function --only function_a,function_b --profile <name> --dry-run
-openxiangda resource publish function --only function_a,function_b --profile <name>
-```
-
-`resource plan` and `resource publish --dry-run` are strictly GET/HEAD-only. If a read gets HTTP 401, the CLI returns `READ_ONLY_AUTH_REQUIRED` without automatically calling the refresh POST. Run `openxiangda auth refresh --profile <name>` or log in again before retrying; never weaken the plan guard to refresh credentials or mutate platform state.
-
-`--code <code>` is the single-resource equivalent of `--only <codes>`. Type-only planning is appropriate for an intentional shared dependency closure. Unscoped full-resource planning/publishing is app-wide and requires an app-wide approved change.
-
-Selectors apply before manifest parsing, source dependency analysis, and JS_CODE typecheck/build. A scoped Function/Automation plan must touch only the selected targets plus their transitive/shared/ambient dependencies; an unscoped plan intentionally retains full-workspace behavior. Resource commands use the canonical scoped builder packaged with the installed CLI for standard workspaces, so old checked-in builders still receive the optimization; refresh/bootstrap the workspace script only for equivalent manual `pnpm build-js-code` behavior. Nonstandard custom builders remain an explicit compatibility fallback.
-
-Function/Automation source analysis also extracts statically declared Form filter and order fields. `resource plan` resolves them through the target application's resource registry, compares them with each Form's frozen online schema, and reports `formFieldContracts`; publish fails before lease/write when the application mapping or field is missing. A source reference does not need to be repeated in every Function/Automation manifest. Fix the application mapping/source or stage the Form schema in the same reviewed release instead of waiting for a production SQL-column error. Dynamic field names remain runtime-validated by the platform and return `FORM_FIELD_NOT_FOUND` as a configuration error.
-
-Source-triggered Function/Automation targets use Backend Release v2 when the platform exposes that capability. One child may mix source-backed create, source-free declarative Automation manifest create, source-only update, and manifest replacement update through explicit per-resource `operation/mode`; the CLI freezes the current Backend Release parent plus Git/change baseline, then runs `prepare -> verify -> activate` or stops verified for `--stage-only`. A new Automation with a complete `definitionJson.version="v3"` and no `sourceFile` automatically uses manifest create without `--replace-manifest`; an incomplete definition still fails closed. Activation CAS-checks the entire set and applies all updates in one transaction. `--stage-only` and Secret-bound Function publishing fail closed when Backend Release v2 is unavailable; compatibility fallback is limited to non-staged, non-Secret publishing after an explicit Backend head 404. Existing online bindings, contracts, metadata, trigger/view configuration, and enabled/published state remain unchanged; noops do not advance versions/timestamps. A deliberate whole-definition replacement of an existing resource requires exact `--only/--code` and `--replace-manifest --reason "<why>"`; SDD bypass does not imply replacement authority.
-
-Resource declarations are mapping, audit, and impact-analysis metadata rather than per-Function authorization. Trusted application code may use any Form/DataView in its current tenant and app; the platform still rejects cross-app/cross-tenant access. Statically discovered source references that are absent from a Function/Automation manifest are warnings, not publish blockers. When an outer Automation `resources` declaration and runtime `definitionJson.resources` are both explicitly present they must still match, and explicit resource bindings remain sealed/read back so environment-specific code-to-ID mappings cannot silently drift.
-
-Repository identity remains strict across immutable releases. If a clone-derived primary repository ID differs from the frozen change source base, the CLI may canonicalize Backend, Workflow, and Root App Release payloads to the frozen ID only when that ID is already present in `releaseSourceRevision.repoAliases`; no alias intersection fails with `RELEASE_SOURCE_REPOSITORY_MISMATCH` before prepare.
-
-Functions with a top-level `secretRefs` field use `backend_release_v2`, including an explicit empty list that removes bindings. This path never falls back to source PATCH. It requires the per-app Secret capability probe to grant `app_function_secrets_v1`, `trusted_node_v2`, `backend_release_v2`, and `atomic_staged_children_v2`; otherwise plan/publish fails closed.
-
-For whole-app atomic activation, publish the exact mixed Function/Automation scope with `resource publish function,automation --only function:<code>,automation:<code> --stage-only --change <change>`. This stops after Backend Release verify and returns `stagedResource` plus every handled selector; the CLI automatically merges it with other changed staged children in `.openxiangda/releases/<change>/staged-resources.json` for `release app-finalize --staged-resources-json`. A Backend Release that was already activated returns `activeResource` and must not be presented as staged.
-
-Standard workspaces use the CLI-bundled scoped JS_CODE builder directly, including isolated Git-base checks; do not invoke `pnpm` merely to rebuild a selected Function/Automation. New snapshots carry `source_lineage_v1.sourceHash`, which is derived from authored source/dependencies rather than generated bundle bytes, so a builder upgrade does not falsely report source divergence.
-
-Use `openxiangda release backend-head|backend-list|backend-detail|backend-diff` to inspect immutable history. `backend-rollback <releaseId> --change <change> --reason "..."` prepares, verifies, and activates a new release from the historical snapshot; it never mutates or directly reactivates the old row. `backend-abort` stops prepared/verified work and `backend-retry` retries only recorded post-commit side effects. Do not fetch newer revisions to replay an older payload.
-
-Use `openxiangda release app-capture` for the platform's authoritative transactionally consistent whole-app manifest. Normal publishing stages changed Runtime/Page/Backend/Form children first, then runs `app-finalize --change <change> --staged-resources-json <JSON|file>`. The overlay contains only changed immutable child entries; Runtime/Page/Backend use singleton kind identity and FormRelease uses `formUuid`. The CLI preserves unmodified active children from the capture and performs `prepare -> verify -> activateStagedChildren=true`, atomically switching all child heads and the App head (`atomic_staged_children_v1`). Child drift or a lost lease causes zero root activation; never auto-refresh or conflict-retry. An aborted Form Release must never be reused as an idempotent result. Rerun the same exact form resource publish: the CLI discards the aborted staged entry, the platform creates a new immutable attempt automatically, and the Root App transaction is retried. Never sequentially activate forms as a workaround. `app-prepare` accepts the same overlay for manual review, and `app-activate <releaseId> --activate-staged-children` performs the explicit transaction switch. A platform administrator may recover a legacy, already verified immutable Root with `app-activate <releaseId> --activate-staged-children --break-glass-adopt-verified-root --reason "..."`. This audited path skips only workspace/baseline/source compatibility checks; it still requires a fresh lease/baseline and enforces Root parent CAS, exact child identity/hash/parent/head, and atomic activation. For an explicitly authorized unconditional legacy recovery, `app-activate <releaseId> --force-activate-without-validation --profile <name>` performs one direct activation write without detail/capture/change/lease/baseline/source/status/parent/hash/resource-head/environment/child-lineage gates; only authentication, the bound tenant/appType data boundary, target-row existence, database constraints, and the transaction remain inherent. No-overlay finalize remains retrospective compatibility only. `app-rollback <releaseId> --change <change> --reason "..."` prepares an audited rollback manifest.
-
-## Classic workspace
-
-Publish only named pages/forms:
-
-```bash
-openxiangda workspace publish --profile <name> --change <change> --only pages/dashboard,forms/customer --dry-run
-openxiangda workspace publish --profile <name> --change <change> --only pages/dashboard,forms/customer
-```
-
-`--page`, `--form`, and `--changed` remain supported. Full `workspace publish` is only for intentional shared/config releases.
-
-Do not call `lowcode-workspace publish-all`, `pnpm publish:all`, `pnpm publish:oss`, or legacy publish scripts directly; they bypass the selected profile contract.
-
-## React SPA
-
-Forms, Backend resources, and frontend Runtime are staged children of one Root App release:
-
-```bash
-openxiangda sdd bundle <release-change> --changes <change-a,change-b>
-# Commit and push the bundle on main/master.
-openxiangda release publish --change <release-change> --profile <name>
-```
-
-Environment-managed application:
-
-```bash
-openxiangda release ship --change <release-change> --profile <name>
-# Stop by default and validate preproduction.
-openxiangda release ship --change <release-change> --profile <name> \
-  --confirm-production
-```
-
-Once `environment init` registers a logical application, or `environment attach` connects an existing workspace, `preproduction` and `production` are separate target bindings with separate app/resource/data IDs. Never copy IDs between them. Existing legacy resource mappings may seed only the appType-matching target. `release ship` always runs candidate → preproduction → production. Normally the first invocation stops at `awaiting_production_confirmation` and a later `--confirm-production` invocation promotes the same candidate. When the user explicitly authorizes an emergency release, `--confirm-production` may be supplied on the first invocation to execute both phases in one command; it bypasses no preproduction, evidence, CAS, or confirmation gate. Candidate sealing includes source/build/public/script inputs, stable environment/resource bindings, and hashed target-specific Runtime artifacts. Deployment reuses those artifacts without rebuilding and completes both server deployment records to `succeeded`. Human acceptance remains recommended and an optional `--acceptance-note` records it. Direct `release publish` to either managed target fails closed. Environment swap and policy updates retain their existing explicit authorization, CAS, and permission rules. `openxiangda studio` is the local loopback-only developer view and exposes only registered safe actions.
-
-Treat DataView `status` as a platform lifecycle observation during candidate binding checks. The same deployment may change `resources.dataViews.<code>.status` between `draft` and `active`, including between preproduction and production confirmation, without invalidating the sealed candidate. Continue to validate the DataView ID, materialized-view name, storage mode, every other resource status, hashes, environment identity, CAS, lease, and source/mainline evidence exactly.
-
-A sealed candidate may continue from a later clean, pushed authoritative mainline commit only when its commit remains a Git ancestor and all sealed release inputs retain their exact hashes. The later HEAD is only a safety gate: Backend, Runtime, and Root children keep the sealed candidate `sourceRevision`, and `backend-abort` uses the same publish lease/baseline/session as the staged release. If any input changed, create a new candidate; never edit the private candidate file. The CLI waits for the app lease and target deployment slot before writes, and the platform permits one running or evidence-pending deployment per target. Emergency releases still use a narrow L1 scope and the same candidate → preproduction → production path; `--wait-seconds 0` only fails fast.
-
-When a reviewed catch-up contains exact non-delete targets that are already on authoritative mainline but the active application combines several historical release lineages, the first ship invocation may add `--adopt-online-baseline --adoption-reason "..."`. Ship validates and freezes the pair before candidate/deployment creation. The later `--confirm-production` invocation automatically reuses the same intent from `ship.json` and forwards it only to exact scoped resource stages. It does not relax frozen online heads, change/lease ownership, delete/prune/force rejection, server CAS, staged-child verification, or the single atomic App finalize.
-
-An environment-managed release may intentionally replace complete Function/Automation manifests with `release ship --replace-manifest --reason "..."`. The two flags are inseparable, the reason is at least 8 characters, only an exact Backend stage receives them, and production confirmation must repeat the exact preproduction intent. They never widen Form, Workflow, Runtime, configuration, wildcard, or app-wide stages.
-
-For an audited Runtime source rollback, managed `release ship`, recovery `release deploy`, and `release promote` accept `--allow-runtime-rollback --reason "..."` with a reason of at least 8 characters. This pair is scoped only to `runtime-stage` and never reaches resource stages or `app-finalize`. Ship freezes it in `ship.json`; production confirmation inherits it automatically. The default remains fail closed.
-
-`release publish` is the normal whole-app entrypoint for legacy unmanaged workspaces: it verifies SDD without mutating reviewed files, waits for the promotion lease, freezes one App capture, stages the exact Form/Backend/Runtime children, resumes from a private execution journal, finalizes once, and releases the lease. Managed applications use two-phase `release ship` and its deployment-scoped journal. Individual candidate/deploy/test/fail/promote commands are recovery/diagnostic primitives. `release fail --deployment <id> --message <text> [--code <code>] [--details-json <JSON|file>] --environment preproduction` records an audited UAT failure only after verifying the deployment belongs to the selected preproduction environment; production targets and mismatched deployment identities fail before the write.
-
-Reviewed bundle commands may retain `<profile>` as a template. The explicit real `release publish --profile <name>` value is bound to actual child argv without rewriting tracked SDD. React SPA page codes remain logical coverage targets and activate through the single Runtime child; they do not require PageRelease. If local lease state disappears, `release end --change <id>` reconciles a self-owned remote lease from the private execution journal and never reports inactive while a remote lease is active.
-
-Exact `resourceSelectors` are authoritative for supported configuration resources such as `publicAccessPolicies`. A legacy `resources=true` category marker is narrowed by those exact selectors and must not become an app-wide generic-resource release. Missing selectors, unknown resource types, wildcard `*`, deletes, and genuine app-wide resource closures remain fail closed.
-
-`runtime deploy --no-activate` uploads an immutable preview release from a clean committed mainline `HEAD`. It reads a narrow Runtime head instead of the full app snapshot. Before acquiring a lease, the CLI confirms `package.json#scripts.build` and existing dependencies; it uses `npm run build` to execute the declared script so pnpm worktree symlinks do not trigger a reinstall. Immutable Git-base artifact hashes are cached under the Git common directory. `release begin` requires local main/master and the live remote default tip to be identical, so `integration-status --change <change>` is already satisfied after activation and `release end` does not wait for a later merge. For a completed managed ship, `--change` recovers lineage from private `ship.json` or the referenced production/preproduction deployment execution journal and reports the exact missing file or field when recovery fails.
-
-`release app-head` and `runtime releases` return compact summaries by default. Use `--full` only when the complete manifest is required.
-
-`resource plan`, `resource publish`, and `runtime deploy` report coarse phases on stderr and emit a heartbeat after 15 seconds without completion. JSON stdout stays machine-readable and includes `timings`; use it to identify whether time is spent in plan, preflight, build, upload, write, or activate instead of rerunning an opaque command.
-
-Use `--upload-mode legacy-json` only for an old platform that lacks staged uploads. Keep timeout/progress on stderr so `--json` stdout remains machine-readable.
-
-## Login and profiles
-
-```bash
-openxiangda login https://lowcode.example.com --profile dev
-openxiangda platform add prod https://lowcode.example.com/platform
-openxiangda platform use dev
-```
-
-Root, `/platform`, and `/view` URLs normalize to `<origin>/service`. Normal work uses the user's profile token and `/openxiangda-api/v1`; never ask for AK/SK. Each profile has independent `appType` and resource IDs.
-
-Durable local resource/environment mappings live in `.openxiangda/state.json`; volatile candidate/deployment progress lives in the private `.openxiangda/releases/` journal. User tokens live in `~/.openxiangda/profiles.json`; shared environment values live in `~/.openxiangda/.env`. Never copy resource IDs between profiles or put tokens in the workspace.
-
-For an environment-managed workspace with more than one target, `function invoke` requires an explicit `--environment <target>` and prints the resolved profile, environment, kind, appType, and environmentId to stderr before the request. Treat this line as part of the diagnostic evidence; do not infer production behavior from an invocation whose resolved target is preproduction.
-
-## Workspace creation/binding
-
-If a local binding exists, use it. If the user explicitly names an existing `appType`, bind that exact app. Otherwise initialize a new workspace; do not search by a similar app name.
-
-```bash
-openxiangda workspace init ./my-app --profile dev --app-name "示例应用" --runtime react-spa
-openxiangda workspace bind --profile dev --app-type APP_XXXX
-```
-
-## Failure handling
-
-- Wrong/missing profile: stop before writes and resolve `env`/`auth status`.
-- Dirty shared checkout: isolate the task; do not broaden its change coverage.
-- `SOURCE_BASE_DIVERGED`: the worktree no longer descends from the frozen Git base; merge onto the reviewed head, rebuild, and start a new release. Only when approved code was historically merged before release and the online app has multiple verified release lineages may an exact non-delete catch-up use `--adopt-online-baseline --adoption-reason "..."` under the same change/lease; never use it for a stale branch, delete, prune, force, or full-app wildcard.
-- `RESOURCE_FIELD_CONFLICT`: a selected remote field changed after the frozen baseline; fetch the conflicting fields, reconcile the intended change, and re-plan the whole set before writing anything.
-- `RUNTIME_HEAD_MOVED` or resource revision conflict: fetch the new baseline, merge, rebuild, and re-plan.
-- `RUNTIME_SOURCE_BASE_DIVERGED`: the Runtime build comes from an old/different Git lineage; merge the online release source into a clean committed `HEAD`, rebuild, and retry. Use audited rollback only when the rollback itself is the approved intent.
-- `RUNTIME_SOURCE_DIRTY` or `RUNTIME_SOURCE_LINEAGE_REQUIRED`: commit all build inputs in an auditable Git repository; generated `dist/` and `.openxiangda/` state do not count, and `--no-build` is not an escape hatch.
-- `PUBLISH_LEASE_HELD`: another change owns promotion; keep developing/testing locally or wait for its release/expiry. Never bypass it with an unleased write.
-- `PUBLISH_LEASE_LOST`: heartbeat renewal failed or the lease expired during a long phase; stop immediately, inspect the active head, re-plan, and start a new release. Never replay the remaining writes with a newly fetched revision.
-- `RELEASE_SOURCE_DIRTY` or `RELEASE_PUBLISH_REVISION_CHANGED`: commit all build inputs and restart from a stable mainline SHA.
-- `RELEASE_SOURCE_MAINLINE_REQUIRED` or `RELEASE_SOURCE_MAINLINE_NOT_PUSHED`: merge approved task commits and the generated bundle into the remote default branch, switch to the synchronized local main/master, then begin the release.
-- `WORKTREE_OWNED_BY_ANOTHER_TASK`: another Codex task owns this source directory; switch to an isolated worktree. Only force-claim with an explicit reason after confirming the original task ended.
-- Plan unexpectedly includes unrelated resources: do not publish; correct `--change`/`--only` or dependency closure.
-- A write updates state: let the CLI use its lock/atomic merge; do not hand-edit state or run conflicting legacy clients.
-- Platform defect or repeated workaround: submit sanitized feedback when configured and report its fingerprint.
-
-## References
-
-- `references/workspace-state.md` — state shape and profile isolation.
-- `references/openxiangda-api.md` — exact endpoint contracts.
-- `references/resource-manifest-cheatsheet.md` — resource examples.
-- `references/connector-resources.md` — Function/connector boundaries.
-
-Load a reference only when the current task needs its contract details.

package/openxiangda-skills/skills/openxiangda-form/SKILL.md

@@ -1,184 +0,0 @@
----
-name: openxiangda-form
-description: "Create, edit, and publish OpenXiangda normal forms and workflow forms in sy-lowcode-app-workspace: schema, fields, options, validation, layout, linkedForm select sources, hidden permission scope keys, FormEffect, workflow form bundles, and single-form publish. Use platform form components first. Trigger on 创建表单, 表单字段, 表单录入, schema, SelectField, linkedForm, workflow form, formCode, or src/forms changes."
----
-
-# OpenXiangda Form
-
-## When to use this skill
-
-- User wants to **create / edit a form (`src/forms/<code>/`)**, change fields, options, layout, validation, or top-level FormEffect.
-- User wants a **workflow form page** (used together with `openxiangda-workflow-automation`).
-- User wants to **publish only a form** (`workspace publish --form <code>`) or pull / inspect an existing form schema.
-- User asks how form values are persisted (option `{label, value}`, attachment shape, member fields, etc.).
-
-## Quick recipe
-
-```bash
-# 1. preflight
-openxiangda env --profile <name>
-openxiangda form list --profile <name>
-
-# 2. edit source
-#   src/forms/<formCode>/schema.ts   — fields, options, rules, top-level FormEffect[]
-#   src/forms/<formCode>/page.tsx    — presentation only
-
-# 3. normal release: stage the exact Form bundle, then Root App finalize
-openxiangda resource plan form-setting --only <formCode> --profile <name>
-openxiangda resource publish form-setting --only <formCode> --change <change> --profile <name>
-openxiangda release app-finalize --staged-resources-json .openxiangda/releases/<change>/staged-resources.json --change <change> --profile <name>
-```
-
-## DO / DO NOT
-
-- ✅ `defineFormSchema` from `openxiangda` and default-export it.
-- ✅ Every visible field has a concise user-facing `placeholder`. Use `tips` only for special constraints.
-- ✅ Use `SelectField` / `RadioField` for enums; for cross-form sources use `SelectField` with `optionSource.type: "linkedForm"` (and `remoteSearch: true` + `searchFieldId` when source is large).
-- ✅ Permission scope keys / sync keys / derived fields stay in schema with `behavior: "HIDDEN"`, derived from visible select/person/department fields via `valueSync`.
-- ✅ Always provide `options` for option components (Select / MultiSelect / Radio / Checkbox / CascadeSelect).
-- ✅ `schema.ts` is the source of data fields and platform field components; `page.tsx` is presentation only and should render through the OpenXiangda standard form/runtime.
-- ✅ Use built-in `JSONField` for editable structured JSON. Customize one field with `renderer` / `editor`, or pass a `components` registry through `StandardFormPage` / `DataManagementList` when the whole surface needs a domain-specific JSON component.
-- ✅ If a custom layout or widget is truly needed, wrap OpenXiangda platform components first. If no platform component exists, wrap `antd` / `antd-mobile` and preserve their props, refs, keyboard behavior, and overlay handling.
-- ❌ `AssociationFormField` for new form work (use `linkedForm` SelectField).
-- ❌ Top-level `schema.rules` as validation array. Top-level `rules` is `FormEffect[]` only (`when` / `then`).
-- ❌ Extra fields for system metadata (creator / updater / created/updated time / depts) — platform creates them automatically.
-- ❌ Developer notes / implementation comments inside labels / placeholders / tips / section titles / empty states.
-- ❌ `openxiangda form create` as page generation; it is a low-level repair command.
-- ❌ Copy `formUuid` from dev to prod — each profile has its own `formUuid` under `.openxiangda/state.json`.
-- ❌ Raw native form controls in app/workspace source: `<input>`, `<select>`, `<textarea>`, `<input type="file">`, hand-written pickers, hand-written uploaders, and custom employee/department selectors. These belong only inside OpenXiangda SDK/platform component internals.
-
-## Required Workspace Flow
-
-```bash
-openxiangda env --profile <name>
-openxiangda form list --profile <name>
-cd /path/to/sy-lowcode-app-workspace
-```
-
-If the workspace does not exist yet, create it before writing form source:
-
-```bash
-openxiangda workspace init ./my-app-workspace --profile <name> --app-name "应用名称"
-cd ./my-app-workspace
-pnpm install
-```
-
-Use `--app-type APP_XXX` only when the user explicitly provides an existing app to reuse.
-
-Create or edit workspace source:
-
-```text
-src/forms/<formCode>/
-├── schema.ts
-└── page.tsx
-```
-
-Then stage the exact Form bundle:
-
-```bash
-openxiangda resource publish form-setting --only <formCodes> --change <change> --profile <name>
-```
-
-For a single form edit, still keep the child staged until Root App finalize:
-
-```bash
-openxiangda resource publish form-setting --only <formCode> --change <change> --profile <name>
-```
-
-The Form resource bundle carries schema, settings, indexes, data-management, runtime-write, public-access configuration, and changed form permission groups under one CAS parent. It returns a canonical staged FormRelease and the CLI records it in the change-scoped staged-resources file. `workspace publish --form` is limited to an intentional first-time bootstrap or isolated repair outside a governed multi-resource release; it is not the normal release path.
-
-An exact staged FormRelease remains usable across a fresh release baseline/lease for the same app/profile/change/deployment only after the CLI re-verifies its immutable, inactive, non-aborted server state, identity/hash, frozen schema/formType, finalized resources, parent/base revision, and current Form head. Workflow planning reads that frozen contract even when the live Form head is intentionally not activated and local `schemaSyncedAt` is absent. Never synthesize `schemaSyncedAt`, direct-publish the schema, or activate the Form early as a workaround; all conflicts fail closed.
-
-For Phase 6 React SPA workspaces, `app-workspace.config.ts` should declare
-`runtimeMode: "react-spa"`. In that mode, `workspace publish --form <code>` is
-schema-only by default: it creates/binds the form and syncs schema, but skips
-the legacy form page bundle, OSS upload, and bundle register. The app-level
-React runtime renders submit/detail/list pages. Pass `--legacy-form-bundle`
-only when intentionally maintaining compatibility with an old embedded form
-page bundle.
-
-## Low-level Commands
-
-Use these only for diagnosis, binding existing resources, or repairing a broken publish state:
-
-```bash
-openxiangda form bind customer --form-uuid FORM_XXX --profile <name>
-openxiangda form pull customer --profile <name> --json
-openxiangda form create customer --name "客户信息" --profile <name>
-openxiangda form publish customer --bundle-url <url> --profile <name>
-```
-
-Do not use `openxiangda form create` as the normal way to generate a user-facing page. It creates the old platform form shell and will show the legacy default schema until a workspace bundle is published.
-
-## Form Release / CAS Safety
-
-- Treat all Form configuration as one immutable release stream. Freeze `revision`, `etag`, and `activeFormReleaseHead` from one snapshot before writing.
-- Publish declared schema, packages, settings, indexes, data-management, runtime-write, public-access configuration, and `formPermissionGroups` through one Form `bundle` mutation. `resource publish form-setting,form-permission-group --only <codes> --change <change>` groups changes by `formUuid`, stages one immutable FormRelease per form, and never falls back to direct live permission-group writes. Resource Form bundles return immutable `contentHash` plus a canonical `stagedResource` (stable identity is `formUuid`); the CLI merges each entry into `.openxiangda/releases/<change>/staged-resources.json`. Root `app-finalize` atomically switches all child heads plus the App head. Use direct `--activate` only for an intentional form-only repair outside a governed multi-resource release; never use `workspace publish --form` inside an atomic React SPA release.
-- Every mutation must carry `If-Match`, `expectedRevision`, `expectedParent`, and a stable artifact ID. Creation starts at revision `0`.
-- A revision/head conflict is not retryable. Stop with zero later writes, re-plan, and explicitly merge the competing change; never silently adopt the newer live head.
-- Use `openxiangda form release-head|release-list|release-detail|release-diff` for inspection and `release-activate|release-rollback|release-abort` for controlled recovery. See `docs/openxiangda-form-releases.md` in the OpenXiangda tool repository.
-
-## Data Export
-
-Use `openxiangda form export` for read-only data delivery. It reuses the active profile token and the workspace app binding, so do not hand-write export URLs or ask for AK/SK.
-
-```bash
-openxiangda form export customer --mode xlsx --profile dev
-openxiangda form export customer --mode xlsx-images --profile dev --all
-openxiangda form export customer --mode package --profile dev --output ./exports/
-```
-
-Modes:
-
-- `xlsx`: normal Excel export. Images and attachments stay as links/text.
-- `xlsx-images`: Excel export with `ImageField` images embedded when the server can read a supported `png` / `jpg` / `gif`; failures degrade to links.
-- `package`: zip export containing `data.xlsx`, `attachments/`, and `manifest.json`; attachment/image cells use package-relative paths and the `Attachments` sheet lists one file per row.
-
-Useful filters:
-
-```bash
-openxiangda form export customer --mode package --profile dev --all --fields formInstId,instance_title,field_xxx
-openxiangda form export customer --mode xlsx --profile dev --filters-json ./filters.json --order-json ./order.json
-openxiangda form export customer --mode xlsx --profile dev --page 1 --page-size 100 --condition-type and --search-keyword 张三 --instance-status completed
-```
-
-## Workspace Form Rules
-
-Read these references only when writing or reviewing schema:
-
-- `references/forms/form-schema.md`
-- `references/forms/component-registry.md`
-- `references/forms/layout-and-rules.md`
-- `references/platform-data-model.md` — how each field type is persisted (JSONB, `{label, value}` for option fields, attachment shape). Consult before designing schema or wiring values.
-- `references/component-guide.md` — platform component first, `antd` / `antd-mobile` fallback, and native-control ban for AI-authored app code.
-- `references/best-practices.md` — status lifecycle fields, ownership redundancy, role-governance fields, and the boundary between normal forms and workflow forms.
-
-## Rules
-
-- Prefer deterministic `formCode` as local key; bind live `formUuid` under the active profile.
-- Every visible field should have a concise, user-facing `placeholder` that tells the user what to enter or select.
-- Use `tips` sparingly. Add tips only for special constraints, unusual formats, or non-obvious business rules; ordinary fields should not have tips.
-- Use `SelectField` or `RadioField` for enumerable business values. Do not model enums as `TextField` values that users must type manually.
-- When a value is maintained by another form or data source, such as class, college, customer, project, category, or asset, use `SelectField` with `optionSource.type: "linkedForm"`. The runtime queries the source form through the SDK, converts records to `{ label, value }` options, and can use `remoteSearch: true` plus `searchFieldId` for large datasets. Do not use `AssociationFormField` for new form work, and do not make users maintain raw ID text fields for those values.
-- Display only fields the user needs to interact with. Permission scope keys, computed fields, sync fields, and developer/internal fields should normally be derived from visible select/person/department fields and stay in the schema with `behavior: "HIDDEN"` instead of appearing on the form page. For select-derived scalar keys, use `valueSync`.
-- Do not create separate fields for platform system metadata such as creator, updater, creator department, updater department, created time, or updated time unless the user explicitly asks for a separate business concept. The platform creates those system fields for every form.
-- All labels, placeholders, tips, section titles, empty states, and helper text must be end-user-facing business copy. Do not write developer explanations or implementation notes into visible page copy.
-- For business lifecycles, model status with normal form fields (`status`, owner/responsibility fields, action-log relation fields) unless the scenario has real approval tasks. Do not create workflow forms for ordinary status transitions.
-- For permission isolation, collect user-facing ownership with select, personnel, or department fields. If form permission groups require scalar matching, add hidden derived keys such as `collegeScopeKey`, `classScopeKey`, `ownerDeptScopeKey`, and `ownerUserScopeKey`; never expose those keys as editable text inputs.
-- For multi-platform publishing, create or bind the form separately for each profile.
-- Do not copy `formUuid` from dev to prod unless the target platform explicitly already uses that ID.
-- Keep `schema.ts` and `page.tsx` as the source for fields/layout/rules and presentation; generated build output is not the source of truth.
-- In `schema.ts`, import `defineFormSchema` from `openxiangda` and default-export the schema.
-- Treat `schema.ts` as the field/component contract. Prefer platform field components listed in `references/forms/component-registry.md`; do not replace them with raw JSX controls in `page.tsx`.
-- Keep `page.tsx` presentation-only. It may customize layout, wrappers, sections, or routing, but should render a complete OpenXiangda standard form/runtime rather than assembling isolated raw controls.
-- If a platform field is missing for a real business need, submit feedback with `openxiangda feedback submit --yes` and then use an `antd` / `antd-mobile` wrapper as a local workaround. Report the workaround and fingerprint to the user.
-- Put validation on field-level `rules`; never generate old top-level validation arrays under `schema.rules`. Top-level `rules` is only for `FormEffect[]` with `when` and `then`.
-- Always provide `options` for option components. `SelectField`, `MultiSelectField`, `RadioField`, `CheckboxField`, and `CascadeSelectField` must not be emitted with `options` undefined. See `references/component-guide.md` for the full list and `references/platform-data-model.md` for the `{label, value}` storage contract.
-- Do not emit raw native form controls in app/workspace source. For basic entry use `TextField`, `TextAreaField`, `NumberField`, `DateField`, `SelectField`, `RadioField`, etc.; for platform-specific entry use `UserSelectField`, `DepartmentSelectField`, `AttachmentField`, `ImageField`, `EditorField`, `DigitalSignatureField`, and `LocationField`.
-- For image thumbnails or lightweight detail previews, configure `imageCompression` on `ImageField` or `AttachmentField`. The submitted value still keeps the original `url`; compressed variants are written to `thumbUrl`, `previewUrl`, and `variants`.
-- React SPA custom edit surfaces that render `FormProvider` must set `config.api` from `usePageFormRuntimeApi()` or `createPageFormRuntimeApi(sdk)`. Do not map all field requests to `sdk.request`, because attachment and image preview require the PageSdk Blob download channel.
-- For OSS-backed image or attachment fields, declare a storage resource first, then set `uploadProvider: "oss"` and `storageCode`. Do not hardcode OSS URLs or credentials in schema/page source; if compressed output uses `webp`, storage `allowedExtensions` must include `webp`.
-- Workflow form pages use the same workspace form structure plus workflow v3 configuration. In legacy workspaces, publish the form page bundle through workspace publish before treating it as complete. In React SPA workspaces, `workspace publish --form` syncs schema only, and the SPA default process pages render through `runtime deploy`.
-- After editing one form, use `workspace publish --form <formCode>` or preview `--changed --dry-run`; do not run full workspace publish by default.
-- Use `openxiangda form pull` or app snapshot before overwriting an existing form.
-- Before assuming a value shape (e.g. dates, attachments, member fields, option fields), verify against `references/platform-data-model.md` instead of guessing.