openxiangda-skill-kit 2.0.0-alpha.132 → 2.0.0-alpha.134

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda-skill-kit",
-  "version": "2.0.0-alpha.132",
+  "version": "2.0.0-alpha.134",
   "description": "Validation and deterministic packaging for OpenXiangda 2.0 AI skills.",
   "type": "module",
   "main": "./dist/index.js",
@@ -17,7 +17,7 @@
     "README.md"
   ],
   "dependencies": {
-    "openxiangda-devkit-core": "2.0.0-alpha.107"
+    "openxiangda-devkit-core": "2.0.0-alpha.109"
   },
   "devDependencies": {
     "tsx": "4.23.12",

package/skills/openxiangda-v2/references/commands.md

@@ -5,7 +5,7 @@
 | Command | Risk | Purpose |
 | --- | --- | --- |
 | `pnpm openxiangda create` | deploy | 创建、绑定并初始化应用 |
-| `pnpm openxiangda dev` | write-local | 连接平台测试数据启动本地 Web 与 Nest |
+| `pnpm openxiangda dev` | write-local | 连接平台测试数据启动本地 Web，按需启动 Nest |
 | `pnpm openxiangda check` | write-local | 生成契约并在目标平台预检后执行检查、测试和构建 |
 | `pnpm openxiangda accept` | deploy | 按计划准备可选的真实预发验收身份 |
 | `pnpm openxiangda deploy` | deploy | 部署测试环境或显式复用测试版本部署生产 |

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

@@ -60,14 +60,18 @@ const visitorReservations = {
 };
 ```
 
-Put it in `data: { resources: [visitorReservations] }`. Resource CRUD
-capabilities are derived by `resourceCapabilityCodes`. For a Native resource,
-grant `read` to each role that may enter its generated page; the compiler also
-grants that role every enabled generated create/update/delete operation. Remove
-an operation only when the role must be restricted, using the corresponding
-code in `deniedCapabilities`. The compiler validates the denial and seals only
-the resulting allow list, so runtime authorization has no second deny model.
-Non-Native mutation owners never receive this expansion. Directory-backed roles also require
+New applications compose `defineDataModel`, `defineResourceList`, `defineResourceForm`
+and `defineApplicationModule` through the root `modules` property. A model alone
+creates storage, never a page or menu. Select `crud: [{ model: model.code }]` only
+when a standard CRUD page serves a business task. The existing `data.resources`
+shape shown above remains a low-level input to the same compiler.
+
+Use `resourceRoleCapabilities(appCode, resourceCode, 'read' | 'manage' | [operations])`
+for explicit grants. Reading a page never implicitly grants create/update/delete.
+Use `manage` only for a confirmed management role. Existing alpha roles that relied
+on implicit expansion must declare their intended operations before regenerating.
+`deniedCapabilities` subtracts explicit grants and is removed from the sealed role.
+Directory-backed roles also require
 `app:<app-code>:directory:read`. Explicit field `access` capability codes are
 also granted only to the intended roles. They are owned and exported by the
 generated field policy, so do not repeat them in `authz.capabilities`.

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

@@ -11,18 +11,23 @@ imports at 100 rows per transaction, use exact declared labels or field codes,
 and leave attachment values to the platform managed-file component.
 
 Declare searchable and filterable fields on the resource and let the standard
-CRUD renderer compose the search area. Keyword search spans the declared
-searchable fields; the first two filters remain inline and additional filters
-open in the platform's large modal. The renderer also preserves declaration
-order for form fields and removes authorization/debug explanations from the
-business UI. Do not create application-owned search toolbars, field ordering
-maps, permission tips or per-resource CRUD pages for these standard behaviors.
+CRUD renderer compose one toolbar. Keyword search spans the declared searchable
+fields; all declared filters open on demand in the platform modal. Business
+columns are the default; audit columns and density are optional list settings.
+Desktop create/edit opens a drawer over the retained list; existing full-page
+routes use the same form lifecycle. The renderer retains values after failed
+saves, prevents repeated submission and asks before discarding an edited form.
+Declare shared form/detail groups in `crud[].sections` with `title` and `fields`.
+Form/detail field selections remain exhaustive and ordered. Use lightweight
+section headings, two ordinary columns on PC and one on mobile; small forms
+need no artificial group. Do not copy a list/form renderer or add application
+search toolbars, field ordering maps or authorization/debug explanations.
 
 Read the current user, complete application-role union and capabilities from the platform runtime authorization endpoint. There is no application-selected active role or identity switch. The standard Shell owns the optional Perspective selector. Use `hasReadCapability` for navigation, list/detail visibility and readable fields; continue to use `hasCapability` for create/update/delete, workflows and custom actions. The standard client sends the selected Perspective automatically, and the server repeats the projection for rows, fields and RLS. Never implement resource-specific frontend filters for it. Strip unauthorized fields from create and update payloads and never treat a disabled input as server authorization. Verify with `pnpm openxiangda check`.
 
 Use the standard `Shell` unchanged. It owns the authenticated user's display
 name, account identifier, safe avatar upload, localized application-role names,
-theme controls, Perspective selection and navigation scroll restoration. It
+Perspective selection, collapsible menu groups and navigation scroll restoration. It
 also owns directory field requests under the current logged-in user's role
 union. Never fetch identity for the header, display role codes, add a second
 identity selector, or copy Shell and
@@ -98,16 +103,11 @@ alias, or build the destination in the browser. Omitting the declaration means
 there is no application business-record target; a broken published mapping
 fails closed.
 
-The platform also owns admin appearance. Wrap bespoke admin content in
-`OpenXiangdaAdminPage`. Ant Design components inherit the existing
-`ConfigProvider`; do not create another theme provider. Use
-`useOpenXiangdaTheme()` for TypeScript-rendered values such as chart colors and
-the public `--oxa-color-*`, `--oxa-shadow-surface`, and
-`--oxa-radius-surface` variables for custom CSS. Never hard-code white, black,
-or neutral greys as admin canvas, card, border, or text colors. Application
-brand and categorical colors may remain explicit only when they are not used as
-structural theme colors. Verify every custom admin page in light, dark, and
-follow-system modes.
+Wrap bespoke admin content in `OpenXiangdaAdminPage` and use Ant Design default
+components. The platform UI provider supplies Chinese locale and contextual
+feedback only. Do not generate appearance preferences, color settings or palette
+registries. Keep component CSS scoped and verify real PC/mobile interactions,
+including selectors, dialogs, form submission and failure recovery.
 
 Declare application-owned login visuals with optional
 `frontend.authentication`. The only supported account contract is
@@ -271,3 +271,25 @@ UUIDs or revision/event diagnostics. Treat `stale` as metadata and show the
 friendly refresh prompt only after a real command token/CAS conflict. Do not
 copy the standard page into an application merely to show full business fields
 or rearrange platform-owned operations.
+
+## Foundation module and field selection
+
+New applications plan task pages first and compose data models and selected CRUD
+views through `defineApplicationModule`. Internal tables need no page. List, form
+and detail selections are exhaustive; `hidden` controls presentation independently
+of Data API permissions. Keep root configuration short by importing business modules.
+
+Use platform Field Kit before custom input controls. PC input may use `antd`;
+mobile input uses the scoped `openxiangda/mobile` Ant Design Mobile adapter, inside
+`MobileSurface` with `openxiangda/mobile/styles.css` (already included in React styles).
+Do not import the `antd-mobile` root, which resets global page styles.
+Do not write raw business input/select/textarea or
+contentEditable elements. Keep mobile entrypoints in src/mobile/, Mobile*.tsx or
+*.mobile.tsx so the application check can inspect their static local imports.
+Basic text/number/boolean/option/date controls have a mobile adapter; complex field
+migration remains staged, and each field must pass actual interaction acceptance.
+
+
+标准列表使用高级条件分组、显示列浮层、冻结和拖动列序、多排序。仅从页面声明的可读业务字段提供选择；导出与列表共用条件和排序。依赖所选记录的 toolbar contribution 声明 `requiresSelection: true`。显示列修改即时预览，显式保存个人偏好。
+
+标准表单使用“暂存 / 提交”及平台草稿箱，不自行使用 localStorage、业务表或 Nest 保存草稿。PC 抽屉头部提供全屏、新开页面、关闭；新开页面由平台保存并交接草稿。移动端为分组字段行、简单标题和固定底部操作，草稿/恢复确认用移动底部弹层；不显示“返回列表”。草稿字段必须保持权限裁剪，编辑草稿不得用最新 revision 覆盖原编辑版本。

package/skills/openxiangda-v2/references/workspace.md

@@ -1,35 +1,20 @@
 # OpenXiangda 2.0 Application Agent Contract
 
 - Use only the workspace-pinned CLI: `pnpm openxiangda <command>`. Never invoke a bare global `openxiangda` inside a 2.0 task.
-- `appspec/` is the optional OpenXiangda 2.0 business-intent layer. Before changing observable behavior, read the bounded index with `pnpm openxiangda spec context --json`, then select only the relevant stable ID; use no ChangeSpec for L0 work, one short ChangeSpec for L1, and add permission/rollback/concurrency detail only for L2/L3. Before close, the user—not AI—confirms `currentSpec=merged` or `not-applicable`. AppSpec is advisory and never a release gate. Never read, import or migrate 1.x `openspec/` or SDD.
-- Use Vite, React Router, Refine Core and Ant Design. Do not add Umi, ProComponents or another admin shell.
-- The platform `openxiangda/react` owns the only admin `ConfigProvider` and the
-  `light`/`dark`/`system` appearance preference. Admin pages use Ant Design's
-  `defaultAlgorithm`/`darkAlgorithm`, `theme.useToken()`, or generated
-  `--oxa-antd-*` CSS variables. Do not add a nested theme provider, theme
-  store, palette editor, `--oxa-color-*`/`--oxa-shell-*` aliases, or fixed
-  white/black/neutral structural colors. Future palettes are centralized
-  platform seed configurations; alpha contracts are replaced directly without
-  compatibility aliases. User-end pages are outside this admin visual contract
-  and may use Tailwind CSS and their own product design tokens/components, but
-  must not mutate the admin provider or Seed.
-- Use the complete Ant Design Seed/Map/Alias/Component model on admin pages:
-  platform-owned Seed values feed the selected algorithm; admin code consumes
-  generated Alias values for colors, spacing, typography, control dimensions,
-  motion, shadows, z-index and breakpoints. Never hand-write Map values or
-  introduce an admin token registry. Component tokens are only for
-  platform-approved non-color dimensions and typography.
-- The template includes Tailwind CSS v4 for user-end pages. Keep its `@theme`
-  and utility classes in the user-end layer, omit Tailwind preflight from the
-  admin shell, and do not make user-end utilities depend on `--oxa-antd-*`.
+- Maintain business goals, task pages, permission decisions and acceptance examples in the existing `appspec/app.md`; complex modules may have focused capability records. `appspec/` is the OpenXiangda 2.0 business-intent layer. Before changing observable behavior, read the bounded index with `pnpm openxiangda spec context --json`, then select only the relevant stable ID; use no ChangeSpec for L0 work, one short ChangeSpec for L1, and add permission/rollback/concurrency detail only for L2/L3. Before close, the user—not AI—confirms `currentSpec=merged` or `not-applicable`. AppSpec is advisory and never a release gate. Never read, import or migrate 1.x `openspec/` or SDD.
+- Use Vite, React Router, Refine Core and platform Field Kit. Use Ant Design for PC and the scoped openxiangda/mobile adapter for touch controls; wrap custom mobile pages in MobileSurface and import openxiangda/mobile/styles.css. Do not import the antd-mobile root with its global reset. Do not author raw business input/select/textarea/contentEditable elements. Keep mobile entrypoints under src/mobile/ or name them Mobile*.tsx / *.mobile.tsx so openxiangda check can inspect their local dependency graph. Do not add Umi, ProComponents or another admin shell.
+- Use Ant Design's default component appearance on PC and the platform's scoped mobile adapter for touch controls. The UI provider supplies Chinese locale and contextual feedback only. Do not generate appearance preferences, color configuration, palette registries, visual state stores or document-wide color effects. Prefer platform components and keep CSS scoped to the component.
+- The template includes Tailwind CSS v4 utilities for user pages. The application owns its minimal document reset; omit preflight from the shared runtime and do not scaffold custom palettes.
 - Bind every generated `appRoutes` entry to its local page with `defineApplicationContributions`; desktop `admin` routes stay inside the platform Shell, while `user` routes render without an admin Shell for independent mobile/user experiences. Generated resource CRUD routes are compiler-owned under `/admin/resources/<resourceCode>...` and `/m/admin/resources/<resourceCode>...`; never recreate root resource paths, aliases or redirects. Explicit routes that have the same canonical shape as another explicit or generated route fail compilation, even when dynamic parameter names differ. Use only the typed `toolbar`, `row` and `detail` resource slots for generated resource actions. Declare the complete editable admin menu with `defineAdminNavigation` and its page/group helpers; the Shell renders only generated `adminNavigation` references and permissions only filter them. Do not create another router, menu store, layout, identity provider, permission store or copied CRUD page; route/action access uses capability or `allOf`/`anyOf`, while Data/App API and Workflow authorization remain server-owned.
 - Application login is optional `frontend.authentication`: existing platform users only, registration rejected, exact desktop `/login` and mobile `/m/login`. Bind generated `authenticationSurfaces` to separate PC/mobile renderers through `defineApplicationContributions`; renderers own only brand visuals and call `ApplicationLoginSurfaceProps`. The platform alone owns passwords, providers, OAuth state/callbacks, secure cookies, current identity and authorization. Never put login in protected `appRoutes`, call a v1 auth route, store tokens, create users/roles, or add another Router/identity provider. Keep QA in generated `platformAuthManifest`, outside the protected route denominator.
 - Branded standard user pages use the optional exact `standardUserSurfaces` contribution from `openxiangda/react`: provide separate desktop/mobile `frame` and `applicationTodoCenter` renderers or omit the property entirely. The platform still owns `/todos`, `/m/todos`, Workflow routes, `RuntimeBoundary`, current-user Notification Hub data, query/load/interaction callbacks and navigation. Never add a second Router, Todo API client, identity store or token prop.
 - External users without platform accounts use only an exact static `surface: 'user'` route declared through `frontend.publicAccess`. Declare the one resource, bounded field sets, required operations, draft limits and named duplicate validations; consume only generated `anonymousPublicAccess` and `createAnonymousPublicClient`. `own.list`/`own.read` mean records submitted by the same platform-issued HttpOnly browser credential, not a verified natural person, and another browser or cleared cookie intentionally loses access. Never create a guest role/user, call the general Native Data API, expose an anonymous upload path, store identity locally or derive ownership from IP, user-agent or fingerprint.
-- Declare each resource once in `openxiangda.config.ts` with only `code`, `name`, `fields` and optional `mutationOwner`, generated/list/layout/data-policy settings. A Workflow subject resource may additionally declare `detailRouteCode: { desktop, mobile }`; both values reference explicit authenticated user routes that require the resource read capability, use the correct `/m` family and contain exactly one dynamic record parameter. This is the only business-record navigation source: never infer `/<resourceCode>/<recordId>` or add an alias. Each field owns type, label, required state, Surface flags, reference/file metadata and access. Resource codes are lower kebab-case. Use `native` for direct Data API mutations, `action`, `readonly` or `workflow` for non-Native ownership; never grant or generate Native mutation for a non-Native owner.
+- Define storage with `defineDataModel` in `modules/<business>/models.ts`; compose modules with `defineApplicationModule`. Select standard pages explicitly through `crud`, `defineResourceList` and `defineResourceForm`. Models without `crud` receive no pages or navigation. A business task page may consume several models. The root `openxiangda.config.ts` composes modules, routes and roles; it must not grow into one giant business definition. Existing `data.resources` remains a lower-level input to the same compiler. Keep internal fields `hidden: true`; this is presentation, never authorization. `system: true` marks server-owned values and hides them by default; `hidden: false` may show a business status or serial number. Form/detail/list field selections are exhaustive and ordered. A Workflow subject resource may declare explicit desktop/mobile `detailRouteCode` as documented in the workflow contract.
 - Never write resource-level `schemaVersion`, `appCode`, `schema`, `surface`, `capabilities`, `fieldPolicies` or `platform/data` modules. The compiler derives the strict DataResource, CRUD capabilities, Surface and AI Schema. The application manifest still starts with its one top-level `schemaVersion: 3`.
 - Ordinary list/get/create/update/delete, filters, export and batch operations use the platform Native Data API. Do not create Function CRUD or NestJS wrappers.
-- Add NestJS only for a named business action that needs a cross-resource transaction, an invariant or an external side effect.
+- Standard PC lists use one toolbar, on-demand filters/column settings and drawer create/edit over the retained list. Full-page entry uses the same platform form. Declare shared form/detail groups with `crud[].sections: [{ title, fields }]`; each view's field selection remains exhaustive and ordered. Small forms may omit groups. Keep only business columns by default, use lightweight sections and let platform components handle pending, errors and dirty cancellation. Do not recreate list/form layouts in application code.
+- Add NestJS only for a named business action that needs a cross-resource transaction, an invariant or an external side effect. The blank app contains no apps/server source or Nest dependency importer. Declare backend.enabled or a server operation, then run pnpm openxiangda check or pnpm dev to initialize and install the optional backend once; existing source is never regenerated. Standard platform workflow definitions and activations do not require Nest.
+- One model can declare up to 20 named standard views with `crud[].code` and `name`. Each selects its own list/form/detail fields, sections, generated operations and mobile availability. Bind navigation with `adminResourcePage(modelCode, { viewCode })`; only an unnamed CRUD declaration generates the original default routes. Views share model values, access and Data API ownership. Include writable required fields in create forms or set `generated.create: false`. Keep platform display preferences and authenticated drafts scoped to the selected view; do not copy models or invent a second draft store.
 - Every interactive business action binds `@OpenXiangdaOperation(operation)` and injects `OpenXiangdaBusinessDataApiService`, `OpenXiangdaBusinessNotificationService`, or `OpenXiangdaStandardOperations`. The platform checks the action capability once at App API ingress; the trusted backend then has full Data/managed business-notification access only to its exact application/environment while audit retains the initiating user and action. Do not author `authorizationJSON`, forward user tokens, grant ordinary users `app:notification2:send`, or reapply the user's resource, row and field permissions inside the action.
 - A NestJS backend declares only `enabled`, `isolation: 'shared' | 'dedicated'` and `resourceProfile: 'light' | 'standard'`. Never put raw Kubernetes resources, replicas, ports or environment maps in application metadata; the platform owns capacity and scaling.
 - Use the current logged-in user and the union of that user's application roles. An app for every logged-in platform user may declare one existing package role through `authz.authenticatedUserRoleCode`; the platform materializes it on first access and unions it with manual and business-projected roles. Do not fabricate a browser fallback role or use a business membership resource for this universal audience. An optional declared Perspective projects only read visibility (pages, rows and fields); create/update/delete, workflows and custom actions continue to authorize against the complete union. Standard Data API calls inherit `X-OpenXiangda-Perspective` automatically. Use `@CurrentPerspective()` only when custom Nest code reads outside the standard Data API, and apply an equivalent read projection explicitly. Business code must not persist a platform Token or authorization result and must not implement a second identity path.
@@ -41,8 +26,37 @@
 - Visitor duplicate protection uses `createVisitorReservation({ duplicateMatch: { fieldCode: submittedValue }, ... })`. `duplicateMatch` is a non-empty value map, never a field-name array, and no mutable pre-read is allowed.
 - Desktop and mobile pages share values, validation and authorization, but use separate renderers. Options, members and departments store display snapshots; resource references store direct JSON display values; attachments, images and signatures use platform-managed file references.
 - `option.*`, `user.*`, `department.*` and `resource-ref.*` values never collapse to scalar IDs. Single values store one labeled object and multiple values store object arrays. `resource-ref.*` JSON is not a foreign key, trusted target snapshot or automatically refreshed copy; current target state is read by `resourceCode` plus `value`. A resource source `labelField` must be `text.short` or `text.long`; `serial-number` is allowed in source search, description and snapshot fields, but not as the label. `location` accepts only exact WGS84 coordinates captured by DingTalk or browser geolocation; it has no manual input or `manual` source. Roles that consume directory-backed fields explicitly include `app:<app-code>:directory:read`.
-- Derive role grants with `resourceCapabilityCodes(appCode, resourceCode)`. Grant a Native resource's `read` capability to every role allowed to enter its generated page; the compiler adds enabled generated create/update/delete capabilities by default. Tighten only exceptional roles with `deniedCapabilities`, which is compile-time authoring input and is removed from the sealed role. Non-Native mutation owners never receive this expansion. Declare current-user rows only with `currentUserDataPolicy(...)`; do not invent operators, values or alternate current-user spellings.
+- Use `resourceRoleCapabilities(appCode, resourceCode, "read" | "manage" | [operations])` for explicit role grants. A read grant never expands into create/update/delete when a page is added. Confirm the business permission matrix before implementing multi-role behavior; `manage` is only for roles explicitly allowed all CRUD operations. Use `currentUserDataPolicy(...)` for current-user row scope.
 - Do not add compatibility aliases, migration branches or silent fallbacks for an earlier 2.0 alpha contract. Replace an incorrect contract and regenerate the application.
 - Standard Workflow and Notification Hub are optional 2.0 modules. Enable them only through canonical `openxiangda.config.ts` declarations and generated clients. `standalone`/`hidden-handoff` default to the compiler-owned process operation; action-owned submission must instead declare `launch.submission.kind: 'named-operation'` with sealed create/existing input and output bindings so the standard PC/mobile page calls the original Named Action and accepts an explicit no-Workflow result. Never add a browser save callback or call Workflow prepare/start directly. Custom pages launch only through a verified Named Action using `OpenXiangdaBusinessProcessService`. PC and mobile render the same `ProcessCommandSurface` independently and recover only by `commandId`. To replace Workflow detail, declare both desktop and mobile `detailRouteCode` values whose routes contain exactly `:instanceId`. Add the current-user todo page only with `frontend.user.applicationTodoCenter: true`; never query Notification Hub management APIs from a user page.
 - Run `pnpm openxiangda check --json` after contract changes and read `data.sealedArtifact`; check never seals, and an older `.openxiangda/build/app-package.json` is not the current check result. Use `pnpm openxiangda accept --plan <file>` only for optional real preproduction identity acceptance; it never blocks delivery. Deploy with `pnpm openxiangda deploy`, inspect with `pnpm openxiangda status` and `pnpm openxiangda logs`, and use the platform rollback command rather than mutating K3s directly.
 - AI-native clients start the workspace protocol through the same pinned binary: `pnpm exec openxiangda --mcp-stdio --cwd <workspace>`. Read `openxiangda://workspace/contracts` or call `contract_describe`; for first-time menu authoring, copy `data.adminNavigationAuthoring.suggestion.expression` once into `frontend.admin.navigation` with its listed `openxiangda/config` imports, then edit that application-owned declaration. Never treat the proposal as runtime discovery. When AppSpec is enabled, also read `openxiangda://workspace/appspec` or call `appspec_context`. Require `aiCatalog` and `aiCatalogDigest` to match the normal compiler output. This is a stdio transport mode, not another application-owned server. Never write an application MCP server, Catalog file, preview store or second authorization path.
+
+- For an ordinary CRUD module, omit unused backend/platform blocks; the platform owns CRUD. `pnpm dev` uses connected development and starts Nest only when enabled or required by declared server capabilities. Run interface tests for changed business rules and browser tests for the actual PC/mobile create/edit/save/read journeys; passing HTTP tests alone is not acceptance.
+
+
+## Standard data entry and list controls
+
+Use the platform standard list for nested AND/OR conditions, display-column
+selection/order/freezing and multiple sorting. Set `requiresSelection: true` on
+selection-dependent toolbar contributions. Preserve hidden fields and query /
+export parity. Column changes preview immediately and save to current-user
+platform preferences explicitly.
+
+Standard forms use Save draft / Submit. Consume platform authenticated drafts;
+do not create application draft tables, localStorage or Nest draft endpoints.
+PC drawer controls are Full screen / New page / Close, with a platform draft
+handoff to the new page. Mobile entry uses grouped touch-field rows, a simple
+title and a fixed action footer, with bottom sheets for drafts and recovery.
+Do not add a mobile Back to list action or desktop form controls. Preserve edit
+revisions and draft CAS; successful submission consumes the draft atomically.
+
+## Optional application backend
+
+The default scaffold contains Web and shared contracts only. Declare
+`backend: { enabled: true }` or application server capabilities, then use the
+existing `pnpm openxiangda check` / `pnpm dev` loop. The tool initializes Nest
+source and its exact dependencies once, preserves authored source, and retries
+an interrupted dependency install. Standard platform workflow activation does
+not imply application Nest. See `docs/backend.md` and the runnable
+`examples/business-action-extension` for SDK ownership and transaction retries.