openxiangda-skill-kit 2.0.0-alpha.12

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

@@ -0,0 +1,44 @@
+---
+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.
+- 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.

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

@@ -0,0 +1,4 @@
+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

@@ -0,0 +1,63 @@
+---
+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`.
+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 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, run
+`pnpm verify:release`. The gate is native to the independent 2.0 repository and
+must not invoke 1.x compatibility suites. It packs every public package,
+validates published `exports`, bin targets and dependency protocols, installs
+the tarballs outside the monorepo, creates a new application from the packed
+creator, and runs that application's generate/check/test/build lifecycle.
+The packed application's lifecycle also installs the pinned Playwright Chromium
+and runs its Admin browser acceptance exactly once before the production build.
+The release pipeline builds/checks/tests the workspace once, then uses the
+`:from-build` distribution, skill and docs stages so those gates reuse verified
+artifacts instead of rebuilding the entire workspace.
+`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` gate before the independent toolchain gate. It
+must validate SQL migrations, discover every platform v2 suite, run the shared
+HTTP/storage security suites, and compile without pulling in the 1.x baseline.
+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

@@ -0,0 +1,4 @@
+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

@@ -0,0 +1,40 @@
+---
+name: openxiangda-v2-frontend
+description: Build OpenXiangda 2.0 React and Ant Design admin experiences. Use when implementing menus, routes, CRUD pages, role switching, workflow task pages, or application-defined action components.
+---
+
+# OpenXiangda 2.0 Frontend
+
+Build inside `apps/web` with `openxiangda-admin`. Preserve the standard shell, role session, route guards, error handling, and typed clients.
+
+## Implementation Rules
+
+1. Register menus and routes through the application contribution API.
+2. Gate navigation and actions with generated capability names; the server remains authoritative.
+3. Use the active-role session supplied by the platform. Switching roles must refresh permissions and scoped data.
+4. Use the standard CRUD and workflow modules first; add application components only for real domain interactions.
+5. Render workflow actions and field policies from the backend protocol. Do not duplicate workflow transition rules in the browser.
+6. Keep data calls in typed client modules rather than components.
+7. Preserve the standard responsive layout, permission-filtered navigation,
+   cached tabs, personal center and stable role switcher. Build management lists
+   with the standard search, pagination, sorting, density, column settings,
+   revision-aware editing and batch action surfaces before adding custom UI.
+8. Use `department`, `user`, and `relation` search/form controls for persisted
+   identifiers. Render directory identifiers with `DepartmentText` or
+   `UserText`; do not expose internal IDs as the primary business label.
+9. Keep DataResource field policies effective across list columns, search,
+   forms, import and export. Authorization loading or errors must fail closed.
+10. Use the standard dashboard and CSV transfer modules before creating
+    application-specific copies. Imports must use restricted transactions and
+    stable idempotency keys.
+11. Keep the standard record detail drawer and business-audit timeline unless
+    the domain needs a genuinely different presentation. Use `DataFileField`
+    for managed attachments and the aggregate chart components for summaries;
+    never expose storage URLs or aggregate complete result sets in-browser.
+12. Import from the narrow `openxiangda-admin/core`, `/data`, `/dashboard`,
+    and `/workflow` entrypoints. Keep business route modules lazy and preserve
+    the template's chunk-cycle and size budgets.
+
+Run `openxiangda generate`, `openxiangda check`, and `openxiangda test` after changing contracts or pages. Run `pnpm test:e2e` for shell, navigation, role, data-page or recovery changes; preserve the desktop and mobile Chromium paths and use accessible role/label locators instead of Ant Design private DOM. Use accessible Ant Design patterns and run the repository's Ant Design lint when available.
+
+Read [Frontend](../../docs/frontend.md) for route, menu, role, and workflow page examples.

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

@@ -0,0 +1,4 @@
+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

@@ -0,0 +1,39 @@
+---
+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. Keep submit preview and actual start on the same definition version and subject context.
+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.
+6. Test approve, reject, transfer, return, resubmit, delegation, add-sign, initiator withdrawal, admin termination, duplicate requests, and stale revisions.
+7. 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.
+- Use timers as durable event producers.
+- 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

@@ -0,0 +1,4 @@
+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."