openxiangda 1.0.78 → 1.0.80

package/README.md

@@ -66,11 +66,12 @@ openxiangda update install
 
 Domestic npm mirrors may lag and return an older OpenXiangda version. `openxiangda update check --json` is designed for AI agents: it returns the installed version, latest official npm version, whether an update is available, and the compatibility commands to run after updating. `openxiangda update install` installs from the official registry and refreshes OpenXiangda skills by default.
 
-Codex skills are installed separately from login/profile state. Run `openxiangda skill install` after installing or linking the CLI. It installs the `openxiangda` root skill plus the 7 top-level subskills into `${CODEX_HOME:-~/.codex}/skills` by default:
+Codex skills are installed separately from login/profile state. Run `openxiangda skill install` after installing or linking the CLI. It installs the `openxiangda` root skill plus the 8 top-level subskills into `${CODEX_HOME:-~/.codex}/skills` by default:
 
 - `openxiangda`
 - `openxiangda-core`
 - `openxiangda-app`
+- `openxiangda-architecture-design`
 - `openxiangda-form`
 - `openxiangda-page`
 - `openxiangda-workflow-automation`

package/lib/cli.js

@@ -4506,7 +4506,16 @@ async function requestOptionalWithAuth(config, profileName, apiPath, options = {
   try {
     return await requestWithAuth(config, profileName, apiPath, options);
   } catch (error) {
-    if (Number(error?.apiCode) === 404 || String(error?.message || '').includes('HTTP 404')) {
+    const status = Number(error?.status || error?.statusCode || error?.response?.status);
+    const apiCode = Number(error?.apiCode);
+    const message = String(error?.message || '');
+    if (
+      status === 404 ||
+      apiCode === 404 ||
+      message.includes('HTTP 404') ||
+      message.includes('不存在') ||
+      /not\s*found/i.test(message)
+    ) {
       return null;
     }
     throw error;

package/lib/skills.js

@@ -31,6 +31,13 @@ const SKILL_SPECS = [
     sourceRelativePath: 'openxiangda-skills/skills/openxiangda-app',
     type: 'subskill',
   },
+  {
+    name: 'openxiangda-architecture-design',
+    displayName: 'OpenXiangda Architecture Design',
+    shortDescription: '新应用和复杂需求的架构设计、详细设计和开发任务门禁。',
+    sourceRelativePath: 'openxiangda-skills/skills/openxiangda-architecture-design',
+    type: 'subskill',
+  },
   {
     name: 'openxiangda-form',
     displayName: 'OpenXiangda Form',

package/openxiangda-skills/SKILL.md

@@ -20,6 +20,7 @@ OpenXiangda supports two workspace modes. Classic `sy-lowcode-app-workspace` pub
 | 发布 classic workspace / 上线旧模式 | `openxiangda-core` | `openxiangda workspace publish --profile <name> --changed --dry-run` |
 | 发布 React SPA / Phase 6 runtime | `openxiangda-core` | `openxiangda resource publish --profile <name>` then `openxiangda runtime deploy --profile <name>` |
 | 只发布改动 / 增量 / 单页 / 单表 | `openxiangda-core` | `... --changed` / `--page <code>` / `--form <code>` / `--only pages/a,forms/b` |
+| 架构设计 / 详细设计 / 新应用需求 / 需求文档转享搭应用 | `openxiangda-architecture-design` | read `references/architecture-design.md`; inspect workspace/app state before coding |
 | 创建应用 / 新建 app / scaffold / 初始化工作区 | `openxiangda-app` | `openxiangda workspace init <dir> --profile <name> --app-name "..."` |
 | 绑定已有应用 / bind existing app | `openxiangda-app` | `openxiangda workspace bind --profile <name> --app-type APP_XXX` |
 | 创建 / 修改表单字段 / 表单页 / schema | `openxiangda-form` | edit `src/forms/<code>/{schema.ts,page.tsx}` → `workspace publish --form <code>` |
@@ -39,7 +40,10 @@ OpenXiangda supports two workspace modes. Classic `sy-lowcode-app-workspace` pub
 - ✅ User token lives in `~/.openxiangda/profiles.json`; project state in `.openxiangda/state.json` (IDs only).
 - ✅ Each profile (dev / prod / ...) has its own `appType` and resource IDs; never copy a `formUuid` / `pageId` / `workflowId` / `automationId` across profiles.
 - ✅ Run `openxiangda update check --json` at the start of substantial work; if `updateAvailable`, run `openxiangda update install` and `openxiangda skill install --force`.
+- ✅ For non-trivial app requirements, run the architecture design gate first: forms, fields, pages, permissions, data views, status/workflow, automation, notifications, and development tasks must be decided before coding.
 - ✅ For form-entry UX, pick components in this order: OpenXiangda platform form components → `antd` / `antd-mobile` wrappers → custom component only when neither exists.
+- ✅ List pages, linked options, remote selectors, and report drill-downs must use paginated server-side queries with explicit searchable fields. Do not fetch a large page and filter in local state.
+- ✅ Treat workflow forms as an exception. Ordinary ticket/order/task/asset lifecycles use status fields, state machines, action logs, permissions, and automations; workflows are for real approval tasks.
 - ✅ Proactively submit platform feedback when you discover a defect, missing capability, unclear rule, repeated workaround, user-visible UX gap, or implementation uncertainty worth improving.
 
 ### Hard rules — never
@@ -149,6 +153,7 @@ When the user provides a root domain such as `https://yida.wisejob.cn/`, use it
 
 - `skills/openxiangda-core/SKILL.md`: command workflow and API contract details.
 - `skills/openxiangda-app/SKILL.md`: app creation, binding, snapshots, and profile-isolated workspace state.
+- `skills/openxiangda-architecture-design/SKILL.md`: OpenXiangda-specific architecture design, detailed design, critical review, and development task planning before implementation.
 - `skills/openxiangda-form/SKILL.md`: workspace-based form and workflow form page development, bundle registration, and form publishing.
 - `skills/openxiangda-page/SKILL.md`: custom code page development and publishing in `sy-lowcode-app-workspace`.
 - `skills/openxiangda-workflow-automation/SKILL.md`: workflow v3 definitions, automation triggers, publishing, enabling, and profile-isolated IDs.
@@ -170,6 +175,7 @@ Load these references on demand instead of memorizing them. Subskills cite the s
 Core CLI / state:
 
 - `references/openxiangda-api.md` — `/openxiangda-api/v1` request and response fields.
+- `references/architecture-design.md` — OpenXiangda architecture design gate, anti-pattern rejection, question gates, final design template, and black-box demo scenario.
 - `references/workspace-state.md` — `.openxiangda/state.json` shape and profile isolation rules.
 - `references/connector-resources.md` — `src/resources` manifests, connector schema, App Function boundary, and platform runtime calls.
 - `references/resource-manifest-cheatsheet.md` — 复制即用的 connector / data-view / notification / App Function / workflow / automation / JS_CODE / role / permission group / settings / menu manifest 骨架与运行时调用示例。在创建任何 `src/resources/` 资源前先看这份。

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

@@ -0,0 +1,312 @@
+# OpenXiangda Architecture Design Reference
+
+Use this reference to turn product material into an OpenXiangda-specific architecture document and task plan.
+
+## Table Of Contents
+
+- [Purpose](#purpose)
+- [Critical Review Stance](#critical-review-stance)
+- [Architecture Gate Workflow](#architecture-gate-workflow)
+- [Anti-Patterns To Reject](#anti-patterns-to-reject)
+- [Question Gates](#question-gates)
+- [Resource Design Checklist](#resource-design-checklist)
+- [Final Document Template](#final-document-template)
+- [Black-Box Demo Scenario](#black-box-demo-scenario)
+
+## Purpose
+
+This design flow is for applications built on OpenXiangda. The output is not a generic PRD. It must tell the implementer exactly which platform resources to create and why:
+
+- forms and fields
+- custom pages and menus
+- data views
+- roles, page permission groups, form permission groups, data scopes, and field access
+- status machines or workflows
+- automations, JS_CODE V2 nodes, and App Functions
+- notifications and connectors
+- publish and acceptance steps
+
+The design is complete only when another agent can implement it without deciding major architecture tradeoffs.
+
+## Critical Review Stance
+
+Act as the technical architect. Product requirements are inputs, not orders.
+
+Be direct when a requirement is technically wrong:
+
+- "这个设计不能按你说的实现。把 1000 条数据拉到前端再筛选，会在真实数据量下变慢，也会绕开后端权限边界。这里必须做分页查询和服务端过滤。"
+- "这不是审批流，是业务状态流转。硬做成流程表单会让页面、权限、数据修复和后续扩展都变复杂。应该用普通表单 + 状态机。"
+- "前端隐藏按钮不是权限控制。敏感数据必须落到表单权限组、数据范围和字段权限。"
+
+Do not insult the person. Criticize the proposal and explain the technical consequence.
+
+## Architecture Gate Workflow
+
+1. **Read the input**: user prompt, uploaded requirements, current workspace files, app snapshots, and existing resources.
+2. **Classify the app**: admin CRUD, portal, workbench, dashboard, workflow approval, status lifecycle, automation-heavy app, integration-heavy app, or mixed.
+3. **Draft the resource map**:
+   - forms as data tables
+   - pages/routes/menus
+   - permissions
+   - data views
+   - workflow/status/automation/function boundaries
+   - notifications/connectors
+4. **Ask missing high-impact questions**. Ask in small rounds; do not dump every possible question at once.
+5. **Reject bad assumptions** and replace them with OpenXiangda-native patterns.
+6. **Confirm UI design needs**. For portals, dashboards, mobile pages, and workbenches, ask whether to run Product Design / visual ideation before implementation.
+7. **Write the design artifact**. Default path when a workspace exists:
+   `docs/architecture/<app-slug>-openxiangda-design.md`.
+8. **Create a development task table** that can be executed by OpenXiangda subskills.
+
+## Anti-Patterns To Reject
+
+| Anti-pattern | Why it is wrong | Required replacement |
+|---|---|---|
+| Fetch 1000 rows then filter in React state | Breaks at real data volume, wastes network, and may bypass data permission thinking | Paginated query with `currentPage`, `pageSize`, sort, and structured server filters |
+| Dropdown options load all records | Large forms become slow and stale | `linkedForm` `SelectField` with `remoteSearch`, explicit `searchFieldId`, and page size |
+| Broad `searchKeyWord` for every search | Expensive and imprecise | Explicit searchable fields and `filterGroup` OR conditions |
+| Workflow form for normal ticket lifecycle | Adds approval constraints and operational overhead without approval semantics | Normal form + status field + state machine + action log + automations |
+| Frontend-only data isolation | Hides UI but does not enforce data access | Page permission groups, form permission groups, data scopes, and field access |
+| One large page owns all business logic | Hard to test and change | `domain/`, `shared/services/`, hooks, reusable components |
+| Repeated multi-form joins in page code | Duplicated, slow, inconsistent | Data View for read-only reusable row/aggregate queries |
+| Materialized view for hard realtime data | Users see stale data | `storageMode: "live"` only for bounded realtime joins, or direct source queries/App Function |
+| Live view for unbounded heavy joins | Slow runtime queries | Materialized view with scheduled refresh and indexes |
+| JS_CODE for reusable business service | Logic gets duplicated in graph nodes | App Function for shared backend logic; JS_CODE only for node-local trigger logic |
+| Raw native form controls | Inconsistent with platform runtime and validation | OpenXiangda platform components first, Ant Design wrappers second |
+
+## Question Gates
+
+Ask only what materially changes the design.
+
+### Scope And Actors
+
+- Who are the user roles?
+- Which roles create, process, approve, view, export, or administer data?
+- Is this PC-only, mobile-only, or both?
+- Is the app greenfield or modifying an existing app?
+
+### Forms And Data
+
+- What are the core business objects?
+- Which objects need independent lifecycle, permissions, or reporting?
+- Which fields are visible to users, hidden scope keys, computed fields, or system-derived fields?
+- Which fields will be searched, sorted, grouped, or used for permissions?
+- What data volume is expected now and after growth?
+
+### Pagination And Search
+
+- Which list pages need filters?
+- Which fields support exact filtering versus fuzzy search?
+- Which selectors need remote search?
+- What default page size is acceptable?
+- Which sorts are business-critical?
+
+Default if the user does not know: design conservative pagination with explicit filters, do not fetch all rows.
+
+### Permissions
+
+- Is data sensitive?
+- Is frontend-only filtering acceptable, or must backend data isolation be enforced?
+- Does each role see all records, own records, department records, assigned records, or a custom scope?
+- Are any fields sensitive enough for backend field access policy?
+- Are page permission groups enough for visibility, or do forms also need permission groups?
+
+Default: if the app contains personal data, costs, approval records, or cross-department data, backend-enforced permissions are required.
+
+### Status Machine Or Workflow
+
+- Is there an actual approver task with agree/reject opinion and approval history?
+- Does each node require field permissions?
+- Is audit history tied to approval tasks, or is a business action log enough?
+- Can the process be represented as a normal status transition?
+
+Default: ordinary service, ticket, order, asset, and task lifecycles are status machines, not workflow forms.
+
+### Data Views And Reports
+
+- Is the query single-form CRUD or repeated multi-form read-only logic?
+- Is the output row-level or aggregate?
+- Must users see source changes immediately?
+- What staleness is acceptable: realtime, 10-30 minutes, hourly, daily, manual?
+- Which fields are filters, dimensions, measures, drill-down keys, and permission scope aliases?
+- What rows can be excluded early by definition `where`?
+
+Default: management dashboards usually use materialized views with scheduled refresh. Operational bounded drill-downs can use live views.
+
+### Automation, JS_CODE, App Function
+
+- What should happen after form submit/update/delete or field change?
+- Are there scheduled scans or deadline reminders?
+- Does logic need to be reused by pages and multiple backend flows?
+- Does it need external HTTP or platform API calls?
+- Which logs are needed for diagnosis?
+
+Default: reusable calculations and validations become App Functions; one-off backend trigger orchestration becomes JS_CODE V2 in automation/workflow.
+
+### Notifications And Connectors
+
+- Which channels are required: in-app, email, DingTalk, WeChat, third-party todo?
+- Who receives each notification and why?
+- Which payload fields are needed?
+- Are templates reusable resources?
+- Are external credentials needed? If yes, use connectors/resources, never page source secrets.
+
+### UI Design
+
+Ask whether to use Product Design or another design skill for:
+
+- dashboard
+- portal
+- mobile entry
+- workbench
+- dense operation console
+- executive report page
+- visually important landing/first screen
+
+For simple CRUD/admin lists, design can proceed with the appropriate OpenXiangda template unless the user asks for visual exploration.
+
+## Resource Design Checklist
+
+### Forms
+
+- Use deterministic `formCode`.
+- Define visible fields, hidden scope keys, and derived values.
+- Use platform field components.
+- Use `SelectField` / `RadioField` for enums.
+- Use `linkedForm` select with remote search for large source forms.
+- Avoid extra system metadata fields unless they represent a separate business concept.
+
+### Pages
+
+- Choose React SPA or classic workspace based on the app mode.
+- Use `DataManagementList` for standard management lists.
+- Split PC/mobile when workflows differ, but reuse `domain/` and `shared/services/`.
+- Keep page components thin.
+
+### Permissions
+
+- App roles use stable local codes.
+- Page permission groups control entry/menu visibility.
+- Form permission groups enforce data access.
+- Field permissions hide sensitive fields where backend support exists.
+- Frontend-only button hiding is UX, not security.
+
+### Data Views
+
+- Use row view for joined lists and drill-downs.
+- Use aggregate view for fixed metrics.
+- Choose `materialized` for read-heavy reports with staleness tolerance.
+- Choose `live` only for bounded realtime joins.
+- Index materialized output aliases used for filters, sort, and dimensions.
+- Show `lastRefreshedAt` when users care about freshness.
+
+### Status, Workflow, Automation
+
+- Model normal lifecycles as status fields and state machines.
+- Use workflow for real approval tasks only.
+- Use automation for backend triggers and schedules.
+- Use JS_CODE V2 trusted_node for node-local backend logic.
+- Use App Function for reusable backend services.
+
+## Final Document Template
+
+```markdown
+# <App Name> OpenXiangda Architecture Design
+
+## 1. Design Decision Summary
+
+- App type:
+- Runtime/publish mode:
+- Key platform resources:
+- Main tradeoffs:
+- Rejected unsafe assumptions:
+
+## 2. Actors And Permissions
+
+| Role | Users | Page visibility | Data scope | Field restrictions | Notes |
+|---|---|---|---|---|---|
+
+## 3. Forms And Fields
+
+| Form code | Purpose | Key fields | Hidden/scope fields | Search/sort fields | Permission notes |
+|---|---|---|---|---|---|
+
+## 4. Pages, Menus, And UX
+
+| Page/route | Audience | Pattern/template | Main actions | Data source | Design mockup needed |
+|---|---|---|---|---|---|
+
+## 5. Query, Pagination, And Search
+
+- List pages:
+- Remote selectors:
+- Server-side filters:
+- Default page sizes:
+- Index/search-field plan:
+
+## 6. Data Views And Reports
+
+| Data view | Type | Mode | Freshness | Filters/indexes | Permission scope | Runtime call |
+|---|---|---|---|---|---|---|
+
+## 7. Status, Workflow, Automation, And Functions
+
+- Status machines:
+- Workflow forms:
+- Automations:
+- JS_CODE V2 nodes:
+- App Functions:
+
+## 8. Notifications And Connectors
+
+| Scenario | Trigger | Channel | Recipients | Template/resource | Notes |
+|---|---|---|---|---|---|
+
+## 9. Development Task Table
+
+| Phase | Task | Resources/files | Validation | Publish step |
+|---|---|---|---|---|
+
+## 10. Acceptance Criteria
+
+- Functional checks:
+- Permission checks:
+- Performance/query checks:
+- Report freshness checks:
+- Notification/automation checks:
+
+## 11. Open Questions And Confirmed Assumptions
+
+- Confirmed:
+- Still open:
+```
+
+## Black-Box Demo Scenario
+
+Use this scenario to validate this skill after release. Run it in a fresh Codex session that only has the installed OpenXiangda skills.
+
+Product-manager style prompt:
+
+```text
+我要做一个校园综合服务工单与物资审批平台。所有工单列表先拉 1000 条前端筛选就行，普通工单从提交到完成也都走审批流。需要 PC 管理后台、移动端报修、SLA 看板、库存预警、通知和一些自动化。
+```
+
+Expected behavior:
+
+- The agent rejects fetching 1000 rows and proposes paginated server queries.
+- The agent rejects workflow for ordinary ticket status changes and keeps workflow only for high-value spare-part approval.
+- The agent asks about permission strictness, sensitive cost fields, data scope, report freshness, design mockups, searchable fields, and pagination.
+- The final design covers normal forms, one workflow form, pages, Data Views, permissions, automations, JS_CODE V2, App Functions, notifications, and task plan.
+
+Coverage target:
+
+- Forms: service ticket, service category, asset equipment, spare-part inventory, satisfaction evaluation, role settings.
+- Status machine: submitted, accepted, assigned, processing, pending acceptance, completed, closed.
+- Workflow: high-value spare-part approval only.
+- Pages: PC admin, mobile report entry, ticket workbench, SLA/inventory/satisfaction dashboard.
+- Data Views: live ticket joined detail, materialized SLA aggregate, inventory alert statistics.
+- Permissions: reporter self, repairer assigned, supervisor department, admin all, sensitive cost field restrictions.
+- Automations: new ticket notification, timeout escalation, completion evaluation reminder, low-stock warning.
+- JS_CODE V2: SLA classification, dynamic recipients, message payload assembly.
+- App Functions: dispatch rule, inventory deduction validation, SLA calculation.
+- Notifications: in-app, DingTalk/third-party todo as required.

package/openxiangda-skills/references/resource-manifest-cheatsheet.md

@@ -186,13 +186,17 @@ JS_CODE 调用：`ctx.notification.sendByType({ ... })`。允许的 channels：`
 {
   "code": "reservation_reminder_summary",
   "name": "Reservation Reminder Summary",
-  "sourceFile": { "localPath": "src/functions/reservation_reminder_summary/index.ts" },
-  "runtimeMode": "trusted_node",
-  "timeout": 30000,
   "resources": {
     "forms": ["reservation_order"],
     "dataViews": ["reservation_order_overview"],
     "connectors": ["crm"]
+  },
+  "definitionJson": {
+    "runtimeMode": "trusted_node",
+    "timeout": 30000,
+    "sourceFile": {
+      "localPath": "src/functions/reservation_reminder_summary/index.ts"
+    }
   }
 }
 ```

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

@@ -0,0 +1,99 @@
+---
+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/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.
+
+## 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 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.
+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.
+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.
+- 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.
+- 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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda",
-  "version": "1.0.78",
+  "version": "1.0.80",
   "description": "OpenXiangda CLI, workspace build tools, runtime SDK, and form components.",
   "private": false,
   "bin": {