create-yss-spec 1.1.1 → 1.1.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-yss-spec",
-  "version": "1.1.1",
+  "version": "1.1.2",
   "description": "Initialize a YSS spec project template repository",
   "files": [
     "bin",

package/template/.agents/skills/high-fidelity-html-prototype/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: high-fidelity-html-prototype
+description: Use after low-fidelity prototype review is approved and before PRD calibration, requirement freeze, OpenAPI Draft, or UI implementation when a user-facing YSS feature needs a high-fidelity interactive HTML prototype using Ant Design v6.
+---
+
+# High Fidelity HTML Prototype
+
+Use this skill only after `prototype-review` approves the low-fidelity prototype / interaction design. It turns reviewed product design into a high-fidelity, browser-runnable HTML artifact for business, UX, frontend, and API review.
+
+## Required Inputs
+
+- PRD baseline: `docs/requirements/<feature>-prd.md`.
+- Product overview design / functional architecture: `docs/design/<feature>-product-overview-design.md`.
+- Interaction spec: `docs/design/<feature>-interaction-spec.md`.
+- State matrix: `docs/design/<feature>-state-matrix.md`.
+- Approved low-fidelity prototype review: `docs/design/<feature>-prototype-review.md` or equivalent issue comment.
+- Project design system: `docs/design/design.md` and `docs/design/tokens/*`.
+
+If low-fidelity `prototype-review` is blocked or missing, stop and return to `product-design-prototype` / `prototype-review`.
+
+## Ant Design Official Agent Baseline
+
+Use the official Ant Design agent guidance as the implementation baseline:
+
+- Read or reference `https://ant.design/docs/react/for-agents` when the task starts.
+- Use `@ant-design/cli` before choosing unfamiliar components, props, tokens, or migration-sensitive APIs.
+- Prefer direct CLI subcommands because `--help` may fail in some Node environments while subcommands still work.
+
+Recommended commands:
+
+```bash
+npm view antd version
+npm view @ant-design/cli version
+npx -y @ant-design/cli@6.5.0 info Button
+npx -y @ant-design/cli@6.5.0 token Button
+npx -y @ant-design/cli@6.5.0 demo Select basic
+npx -y @ant-design/cli@6.5.0 changelog 5.0.0 6.5.0 Table
+```
+
+Use the latest verified v6.x version instead of `6.5.0` when npm reports a newer v6 release. Record the exact version and any queried components in the output.
+
+## Core Rules
+
+- Output is HTML: `docs/design/prototypes/<feature>/index.html`.
+- The prototype must use Ant Design v6. Before generating or updating code, verify the current v6 package with `npm view antd version` and `npm view @ant-design/cli version`. If the latest version is not v6.x, pin the newest available v6.x version and record the choice.
+- Use React >= 18, `antd@6.x`, and `@ant-design/icons@6.x` for interactive prototypes.
+- Prefer Ant Design components and tokens over hand-built controls: `Layout`, `Menu`, `Breadcrumb`, `Button`, `Input`, `Select`, `Table`, `Form`, `Tabs`, `Steps`, `Drawer`, `Modal`, `Alert`, `Tooltip`, `Tag`, `Badge`, `DatePicker`, `Upload`, `Pagination`, `Empty`, `Spin`, `Result`.
+- Do not create extra data-service or fixture artifacts. Use embedded sample data inside the HTML/JS for visual and interaction demonstration only.
+- Mark the file clearly as `PROTOTYPE ONLY - NOT PRODUCTION CODE`.
+- Do not treat the HTML prototype as a stable frontend implementation, generated-client contract, or OpenAPI source of truth. It informs PRD calibration and OpenAPI Draft.
+
+## Interaction Coverage
+
+The HTML prototype must cover, or explicitly mark not applicable:
+
+- Primary page navigation and page-to-page return path.
+- Main task completion flow.
+- Search / filter / sort / pagination behavior.
+- Form input, validation, submit, cancel, dirty-form leave prompt.
+- Drawer / modal / confirmation interactions.
+- loading, empty, error, readonly, disabled, no-permission, conflict, success states.
+- Permission behavior: hidden vs disabled vs rejected action.
+- Field-level and page-level error placement.
+- Responsive behavior for at least desktop, tablet, and narrow mobile viewport.
+
+## Verification
+
+Run a local browser verification before calling the artifact ready:
+
+- Open `docs/design/prototypes/<feature>/index.html` or run the dev server if the prototype needs one.
+- Check that the page renders nonblank.
+- Exercise the main flow and at least one failure / permission / conflict state.
+- Check at least one desktop and one mobile viewport.
+- Record verification evidence in the response or in the related review / issue.
+
+## Output Contract
+
+```markdown
+### 当前阶段
+High-fidelity HTML prototype
+
+### 输入资产
+- <PRD / product overview / interaction spec / state matrix / prototype review>
+
+### 高保真产物
+- `docs/design/prototypes/<feature>/index.html`
+
+### Ant Design v6 依据
+- <antd version, @ant-design/cli version, official docs checked, CLI component/token/demo queries>
+
+### 覆盖范围
+- <pages, flows, states, permissions, data dependencies>
+
+### 验证证据
+- <render command or file open path, viewport checks, interaction checks>
+
+### 是否可进入 PRD 校准 / API 影响分析
+- <yes/no; list blocking gaps>
+
+### 下一步
+- <PRD calibration / return to high-fidelity prototype / return to product-design-prototype>
+```

package/template/.codex/skills/high-fidelity-html-prototype/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: high-fidelity-html-prototype
+description: Use after low-fidelity prototype review is approved and before PRD calibration, requirement freeze, OpenAPI Draft, or UI implementation when a user-facing YSS feature needs a high-fidelity interactive HTML prototype using Ant Design v6.
+---
+
+# High Fidelity HTML Prototype
+
+Use this skill only after `prototype-review` approves the low-fidelity prototype / interaction design. It turns reviewed product design into a high-fidelity, browser-runnable HTML artifact for business, UX, frontend, and API review.
+
+## Required Inputs
+
+- PRD baseline: `docs/requirements/<feature>-prd.md`.
+- Product overview design / functional architecture: `docs/design/<feature>-product-overview-design.md`.
+- Interaction spec: `docs/design/<feature>-interaction-spec.md`.
+- State matrix: `docs/design/<feature>-state-matrix.md`.
+- Approved low-fidelity prototype review: `docs/design/<feature>-prototype-review.md` or equivalent issue comment.
+- Project design system: `docs/design/design.md` and `docs/design/tokens/*`.
+
+If low-fidelity `prototype-review` is blocked or missing, stop and return to `product-design-prototype` / `prototype-review`.
+
+## Ant Design Official Agent Baseline
+
+Use the official Ant Design agent guidance as the implementation baseline:
+
+- Read or reference `https://ant.design/docs/react/for-agents` when the task starts.
+- Use `@ant-design/cli` before choosing unfamiliar components, props, tokens, or migration-sensitive APIs.
+- Prefer direct CLI subcommands because `--help` may fail in some Node environments while subcommands still work.
+
+Recommended commands:
+
+```bash
+npm view antd version
+npm view @ant-design/cli version
+npx -y @ant-design/cli@6.5.0 info Button
+npx -y @ant-design/cli@6.5.0 token Button
+npx -y @ant-design/cli@6.5.0 demo Select basic
+npx -y @ant-design/cli@6.5.0 changelog 5.0.0 6.5.0 Table
+```
+
+Use the latest verified v6.x version instead of `6.5.0` when npm reports a newer v6 release. Record the exact version and any queried components in the output.
+
+## Core Rules
+
+- Output is HTML: `docs/design/prototypes/<feature>/index.html`.
+- The prototype must use Ant Design v6. Before generating or updating code, verify the current v6 package with `npm view antd version` and `npm view @ant-design/cli version`. If the latest version is not v6.x, pin the newest available v6.x version and record the choice.
+- Use React >= 18, `antd@6.x`, and `@ant-design/icons@6.x` for interactive prototypes.
+- Prefer Ant Design components and tokens over hand-built controls: `Layout`, `Menu`, `Breadcrumb`, `Button`, `Input`, `Select`, `Table`, `Form`, `Tabs`, `Steps`, `Drawer`, `Modal`, `Alert`, `Tooltip`, `Tag`, `Badge`, `DatePicker`, `Upload`, `Pagination`, `Empty`, `Spin`, `Result`.
+- Do not create extra data-service or fixture artifacts. Use embedded sample data inside the HTML/JS for visual and interaction demonstration only.
+- Mark the file clearly as `PROTOTYPE ONLY - NOT PRODUCTION CODE`.
+- Do not treat the HTML prototype as a stable frontend implementation, generated-client contract, or OpenAPI source of truth. It informs PRD calibration and OpenAPI Draft.
+
+## Interaction Coverage
+
+The HTML prototype must cover, or explicitly mark not applicable:
+
+- Primary page navigation and page-to-page return path.
+- Main task completion flow.
+- Search / filter / sort / pagination behavior.
+- Form input, validation, submit, cancel, dirty-form leave prompt.
+- Drawer / modal / confirmation interactions.
+- loading, empty, error, readonly, disabled, no-permission, conflict, success states.
+- Permission behavior: hidden vs disabled vs rejected action.
+- Field-level and page-level error placement.
+- Responsive behavior for at least desktop, tablet, and narrow mobile viewport.
+
+## Verification
+
+Run a local browser verification before calling the artifact ready:
+
+- Open `docs/design/prototypes/<feature>/index.html` or run the dev server if the prototype needs one.
+- Check that the page renders nonblank.
+- Exercise the main flow and at least one failure / permission / conflict state.
+- Check at least one desktop and one mobile viewport.
+- Record verification evidence in the response or in the related review / issue.
+
+## Output Contract
+
+```markdown
+### 当前阶段
+High-fidelity HTML prototype
+
+### 输入资产
+- <PRD / product overview / interaction spec / state matrix / prototype review>
+
+### 高保真产物
+- `docs/design/prototypes/<feature>/index.html`
+
+### Ant Design v6 依据
+- <antd version, @ant-design/cli version, official docs checked, CLI component/token/demo queries>
+
+### 覆盖范围
+- <pages, flows, states, permissions, data dependencies>
+
+### 验证证据
+- <render command or file open path, viewport checks, interaction checks>
+
+### 是否可进入 PRD 校准 / API 影响分析
+- <yes/no; list blocking gaps>
+
+### 下一步
+- <PRD calibration / return to high-fidelity prototype / return to product-design-prototype>
+```

package/template/.codex/skills/high-fidelity-html-prototype/agents/openai.yaml

@@ -0,0 +1,5 @@
+version: 1
+interface:
+  display_name: "High Fidelity HTML Prototype"
+  short_description: "Ant Design v6 interactive HTML prototype gate"
+  default_prompt: "Use $high-fidelity-html-prototype to create an Ant Design v6 high-fidelity interactive HTML prototype after low-fidelity prototype review."

package/template/.codex/skills/product-design-prototype/SKILL.md

@@ -25,7 +25,7 @@ If no PRD baseline exists, route back to `yss-product-lifecycle` / `grill-with-d
 5. Write the OpenAPI implication list: fields, filters, actions, errors, permissions, pagination, optimistic/concurrency states, and audit/version data.
 6. For every primary page action, add an action-to-contract row: page/component, action label, `actionKey`, endpoint or explicit non-goal, request fields, response shape, permission behavior, state transition, idempotency/concurrency rule, and error codes.
 7. For every P0 requirement containing verbs such as manage, maintain, configure, create, update, archive, retry, cancel, publish, export, or create draft, confirm the interaction spec either names the API implication or records that the capability is intentionally out of scope.
-8. Hand off to `prototype-review`. Do not freeze/calibrate the PRD or enter OpenAPI Draft for UI work until prototype review has no blocking findings.
+8. Hand off to `prototype-review`. After low-fidelity review is approved, hand off to `high-fidelity-html-prototype`. Do not freeze/calibrate the PRD or enter OpenAPI Draft for UI work until the Ant Design v6 high-fidelity HTML prototype exists and has no blocking findings.
 
 ## Tool Routing
 
@@ -33,8 +33,6 @@ If no PRD baseline exists, route back to `yss-product-lifecycle` / `grill-with-d
 |---|---|
 | Low-fidelity page or flow sketch | `wireframe-prototype` |
 | Figma work or existing Figma file | `figma` / `figma-use` |
-| Engineering state prototype | `component-story-prototype` |
-| API not frozen but interactions need data | `mock-api-prototype` |
 | YSS implementation constraints | `yss-router`, then `yss-ui`, `yss-formily`, `yss-page-module-development` as needed |
 
 ## Output Contract
@@ -67,7 +65,7 @@ Product design / prototype / interaction design
 - <yes/no; include whether PRD calibration is needed first>
 
 ### 下一步
-- <prototype-review or routing back to PRD/design>
+- <prototype-review / high-fidelity-html-prototype / routing back to PRD/design>
 ```
 
 ## Data Modeling Example

package/template/.codex/skills/prototype-review/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: prototype-review
-description: Use when reviewing UI design, wireframes, prototype links, interaction specs, or state matrices before PRD calibration, OpenAPI Draft, vertical slicing, or implementation.
+description: Use when reviewing low-fidelity UI design, wireframes, prototype links, interaction specs, or state matrices before high-fidelity HTML prototype work, PRD calibration, OpenAPI Draft, vertical slicing, or implementation.
 ---
 
 # Prototype Review
 
-Use this skill as the gate between product design/prototype work and PRD calibration / OpenAPI Draft. The review is fail-closed: if the design cannot drive calibrated requirements, API, frontend acceptance, and slices, send it back to product design.
+Use this skill as the low-fidelity gate between product design/prototype work and high-fidelity HTML prototype work. The review is fail-closed: if the design cannot drive calibrated requirements, API, frontend acceptance, and slices, send it back to product design.
 
 ## Required Inputs
 
@@ -27,13 +27,13 @@ Use this skill as the gate between product design/prototype work and PRD calibra
 | Action contract coverage | Every primary page action has an `actionKey`, endpoint or explicit non-goal, permission behavior, state transition, idempotency/concurrency rule, and error codes |
 | P0 contract coverage | Every P0 requirement with manage/maintain/configure/create/update/archive/retry/cancel/publish/export/create-draft semantics is mapped to an API implication or an explicit non-goal |
 | Rule/source coverage | Validation, approval, coverage, and publish gates state where rules come from, who can configure them, whether they are fixed, and how blocker/warning decisions are represented |
-| Frontend acceptance | A frontend engineer can tell which components, stories, mock data, and E2E paths are needed |
+| Frontend acceptance | A frontend engineer can tell which components, visible states, data dependencies, and E2E paths are needed |
 
 ## Decision Rules
 
-- If a feature has UI impact and lacks page map, user flow, prototype/wireframe, or state matrix, block PRD calibration and OpenAPI Draft.
+- If a feature has UI impact and lacks page map, user flow, prototype/wireframe, or state matrix, block high-fidelity HTML prototype work, PRD calibration, and OpenAPI Draft.
 - If the prototype hides business rules behind generic text such as "校验失败", require field-level errors and recovery behavior.
-- If a page shows a user action but the OpenAPI implication list lacks endpoint/non-goal mapping, block PRD calibration or OpenAPI Draft.
+- If a page shows a user action but the OpenAPI implication list lacks endpoint/non-goal mapping, block high-fidelity HTML prototype work, PRD calibration, or OpenAPI Draft.
 - If PRD P0 scope says a user can manage or configure an object but the design only shows read-only data, block until the write path or scope downgrade is explicit.
 - If a state is intentionally out of scope, record why and who owns the decision.
 - If implementation dependencies are unclear, route to `yss-router` only after the prototype passes this review.
@@ -57,10 +57,10 @@ Use this skill as the gate between product design/prototype work and PRD calibra
 - <requirements gaps, acceptance criteria updates, non-goals, pending decisions>
 
 ### Frontend Prototype Readiness
-- <storybook/histoire stories, mock data, component states>
+- <component states, data dependencies, frontend acceptance notes>
 
 ### Next Action
-- <PRD calibration / OpenAPI Draft / return to product-design-prototype / component-story-prototype / mock-api-prototype>
+- <high-fidelity-html-prototype / return to product-design-prototype>
 ```
 
 Use `docs/design/templates/prototype-review-checklist.md` when writing a persistent review artifact.

package/template/.codex/skills/yss-design-system/SKILL.md

@@ -70,12 +70,14 @@ description: YSS 产品设计系统与 Ant Design 企业级 UI 风格基线。
 | 场景 | 配合技能 |
 | --- | --- |
 | PRD 后做页面 / 原型 / 交互说明 | `product-design-prototype` |
-| 原型进入 PRD 校准 / OpenAPI Draft 前评审 | `prototype-review` |
+| 低保真原型进入高保真前评审 | `prototype-review` |
+| 低保真评审通过后的高保真 HTML 原型 | `high-fidelity-html-prototype` |
 | 低保真线框或流程图 | `wireframe-prototype` / `excalidraw-diagram-generator` |
 | 前端页面实现 | `yss-ui` / `yss-page-module-development` |
 | 表单 schema | `yss-formily` |
 | YTable / YTree / 高度自适应 | `yss-components` / `yss-use-table-height` / `yss-use-tree-height` |
-| API / Mock 联调 | `api-integration` / `mock-api-prototype` |
+| Ant Design v6 组件 / token / demo 查询 | 官方 `@ant-design/cli` / `https://ant.design/docs/react/for-agents` |
+| API 契约 / 接入 | `api-integration` / `yss-openapi` |
 
 ## 更新设计系统
 

package/template/.codex/skills/yss-product-lifecycle/SKILL.md

@@ -63,7 +63,7 @@ Architecture artifacts are produced progressively. Do not try to finish every ar
 | Artifact | Lifecycle timing | Primary question | Typical outputs | Diagram support |
 |---|---|---|---|---|
 | Business architecture | Opportunity exploration / Discovery / product definition | Who gets value, in which workflow, and where the product boundary sits | user journey, value stream, role/ecosystem model, capability map | journey map, swimlane, capability map |
-| Product overview design / Functional architecture | PRD baseline / product design / PRD calibration | Which product capabilities, user flows, modules, pages, APIs, and data impacts support the MVP boundary | product overview, module map, feature list, priority, dependencies, state flow, open questions, PRD gaps | feature/module map, dependency graph, user flow, page map |
+| Product overview design / Functional architecture | PRD baseline / product design / PRD calibration | Which product capabilities, user flows, modules, pages, low-fidelity prototypes, APIs, and data impacts support the MVP boundary | product overview, module map, feature list, priority, dependencies, low-fidelity wireframe, state flow, open questions, PRD gaps | feature/module map, dependency graph, user flow, page map, low-fidelity wireframe |
 | System overview design / System architecture | Engineering baseline / architecture review | How the product is built, deployed, integrated, operated, and safely evolved | C4/container view, service boundary, integration, deployment, NFR decisions, rollout/rollback decisions | system architecture, sequence, deployment, DFD |
 | Data architecture | Detailed design before persistence and repository work | How domain data, metadata, versions, lineage, and queries are modeled and stored | conceptual/logical/physical model, meta-model, versioning strategy, lineage/query/index strategy | ER, class, lineage graph, DFD |
 
@@ -90,7 +90,9 @@ Use `excalidraw-diagram-generator` when diagrams will make boundaries, flows, da
    - service boundary, state machine, integration, NFR, rollout, or rollback -> system / data architecture, engineering contract, and Design Review downstream gates;
    - persistence, metadata, versioning, lineage, query, or index -> system / data architecture, engineering contract, and Design Review downstream gates.
 4. Check whether required upstream artifacts exist.
-   - Before formal vertical slicing, verify PRD, OpenAPI Freeze or no-API-impact record, architecture review as needed, and a clear issue destination.
+   - Before PRD calibration, product design, API impact analysis, OpenAPI Draft, requirement freeze, or formal vertical slicing, verify PRD baseline and product overview design / functional architecture exist. If the task does not enter the PRD lifecycle, record the not-applicable reason in the impact assessment.
+   - For UI work, before PRD calibration, API impact analysis, OpenAPI Draft, or requirement freeze, verify low-fidelity `prototype-review` is approved and `docs/design/prototypes/<feature>/index.html` exists as an Ant Design v6 high-fidelity HTML prototype.
+   - Before formal vertical slicing, verify PRD, product overview design / functional architecture, OpenAPI Freeze or no-API-impact record, architecture review as needed, and a clear issue destination.
    - For medium/high-risk API, permission, state-machine, data-model, cross-client, new-module, or safety-sensitive changes, verify an OpenSpec-style Spec Delta exists or record why it is not needed.
    - Before frontend/backend implementation, verify vertical slice scope, implementation repo/location, whether the impacted frontend/backend runtime projects already exist and are reusable, YSS skill routing, Build Architecture Checklist, test command, and review strategy.
 5. Output the next action:
@@ -139,10 +141,11 @@ Default routing:
 
 | Intent | Next skill / workflow |
 |---|---|
-| Start a new business product/module | intake -> opportunity and Discovery -> `competitive-intelligence` when market / competitor facts are needed -> `grill-with-docs` -> `to-prd` -> business / PRD / functional architecture -> product design and requirement freeze when UI exists |
+| Start a new business product/module | intake -> opportunity and Discovery -> `competitive-intelligence` when market / competitor facts are needed -> `grill-with-docs` -> `to-prd` -> product overview design / functional architecture -> product design and requirement freeze when UI exists |
 | Analyze competitors, substitute workflows, pricing, positioning, or market facts | `competitive-intelligence`; then feed stable findings into `grill-with-docs` and `to-prd` |
-| Design UI flow after PRD baseline | `product-design-prototype`; add `wireframe-prototype`, `component-story-prototype`, or `mock-api-prototype` only when needed |
-| Review prototype before PRD calibration | `prototype-review` |
+| Design UI flow after PRD baseline | Verify product overview design / functional architecture first, then use `product-design-prototype`; add `wireframe-prototype` only when a low-fidelity page or flow sketch is needed |
+| Review low-fidelity prototype before high-fidelity design | `prototype-review` |
+| Build high-fidelity interactive HTML prototype | `high-fidelity-html-prototype` with Ant Design v6 after low-fidelity prototype review is approved |
 | Review contract draft / OpenAPI Draft inside architecture/design review | `yss-openapi-draft-review` |
 | Record behavior deltas for medium/high-risk changes | OpenSpec-style Spec Delta at `docs/specs/<feature>-spec-delta.md` using `docs/templates/spec-delta-template.md` |
 | Clarify architecture artifact timing or gaps | this skill plus `docs/process/lifecycle-artifact-map.md` and `references/artifact-checklist.md` |
@@ -202,10 +205,10 @@ When the user explicitly asks for a full delivery plan, include stage-by-stage t
 
 - Do not skip opportunity exploration for new product/module work; use `competitive-intelligence` when market/competitor facts are needed, or record why it is not needed.
 - Do not treat Discovery outputs as frozen downstream design. Discovery can provide product capability guidance and downstream impact signals, but PRD, functional architecture, OpenAPI, system architecture, and data architecture still require their own gates.
-- Do not start implementation before PRD is calibrated, required architecture artifacts are explicit, product design / prototype / interaction design exists and passes `prototype-review` when UI exists, OpenAPI Freeze decision, engineering baseline, design review, and vertical slice are clear.
+- Do not start implementation before PRD is calibrated, product overview design / functional architecture exists, required architecture artifacts are explicit, product design / prototype / interaction design exists, low-fidelity `prototype-review` passes, high-fidelity Ant Design v6 HTML prototype exists when UI exists, OpenAPI Freeze decision, engineering baseline, design review, and vertical slice are clear.
 - Do not start implementation before deciding whether the impacted frontend/backend runtime projects already exist and can be reused. Missing or conflicting runtime projects must route back to implementation routing and scaffold initialization first.
 - Do not skip business architecture for new products unless the product boundary, users, ecosystem, and value stream are already captured elsewhere.
-- Do not skip functional architecture before PRD calibration when module boundaries, MVP priority, or cross-module dependencies are still unclear.
+- Do not skip product overview design / functional architecture after PRD baseline. It is a required artifact before PRD calibration, product design / prototype / interaction design, API impact analysis, OpenAPI Draft, requirement freeze, or implementation. Only tasks that do not enter the PRD lifecycle may record a not-applicable reason in the impact assessment.
 - Do not skip system architecture when services, deployment, integrations, performance, security, reliability, or operations are affected.
 - Do not skip data architecture before persistence / repository work. For data modeling, metadata, versioning, or lineage products, treat it as mandatory before Design Review and OpenAPI Freeze.
 - Do not let Excalidraw diagrams invent requirements or architecture decisions; diagrams must point back to source artifacts and any findings must be written back to PRD, OpenAPI, ADR, or issues.

package/template/.codex/skills/yss-product-lifecycle/references/artifact-checklist.md

@@ -14,6 +14,7 @@ Use this checklist to decide whether the current request can move forward or mus
 | Functional architecture | `docs/architecture/<feature>-functional-architecture.md` or PRD/design section | Product capabilities, module boundaries, priority, dependencies, and MVP scope are clear |
 | Product overview design | `docs/design/<feature>-product-overview-design.md` | Pages, flows, states, permissions, API candidates, and PRD gaps are clear |
 | Prototype / interaction review | `docs/design/<feature>-prototype-review.md` or issue comment | UI paths, empty/error/loading states, permission states, and API backflow list are reviewed |
+| High-fidelity HTML prototype | `docs/design/prototypes/<feature>/index.html` | Ant Design v6 interactive HTML prototype exists after low-fidelity review and before PRD calibration / API Draft |
 | API impact / OpenAPI Draft | `docs/api/specs/<feature>.yaml`, issue note, or API impact record | Request/response, wrappers, errors, pagination, permissions, concurrency, and contract test seams are reviewable |
 | OpenAPI Freeze | `docs/api/<feature>-openapi-freeze.md` or issue comment | Draft has been reviewed and marked stable for frontend/backend implementation |
 | Engineering baseline | `docs/architecture/<feature>-engineering-baseline-review.md` | YSS DDD module boundary, dependency direction, DTO/VO/CMD/Query conventions, and scaffold constraints are reviewed |

package/template/.codex/skills/yss-product-lifecycle/references/stage-routing.md

@@ -9,7 +9,7 @@ Use this reference after reading current repo context. It maps request shape to
 | 1. Intake / lifecycle triage | 新需求、继续需求、Bug、小调整、流程不清、缺失资产判断 | User request, `CONTEXT.md`, docs, issues, git state | stage decision, nearest trustworthy artifact, minimal skill list | route to earliest impacted stage |
 | 2. Opportunity and Discovery | 模糊想法、竞品/市场输入、用户痛点尚不清楚 | discovery docs, market/user facts, stakeholder notes | user, pain, why now, MVP, non-goals, success criteria, downstream impact | `competitive-intelligence` when market / competitor facts are needed, then `grill-with-docs` / PRD |
 | 3. Business / PRD / functional architecture | 需要明确用户故事、验收标准、功能边界、模块依赖 | discovery, `CONTEXT.md`, ADRs, existing PRD | PRD, business architecture, functional architecture, PRD review notes | product design or contract design |
-| 4. Product design and requirement freeze | 有 UI、页面、交互、状态矩阵、权限状态、空/错/加载态 | PRD, design system, existing UI, component docs | product overview design, interaction spec, state matrix, prototype review, requirement freeze | contract and architecture review |
+| 4. Product design and requirement freeze | 有 UI、页面、交互、状态矩阵、权限状态、空/错/加载态、高保真体验 | PRD, design system, existing UI, component docs | product overview design, interaction spec, state matrix, prototype review, Ant Design v6 high-fidelity HTML prototype, requirement freeze | contract and architecture review |
 | 5. System / data architecture, engineering contract, and Design Review | 接口、DTO、错误结构、后端新服务、新模块、DDD 分层、服务边界、部署、集成、状态机、权限、NFR、持久化、元模型、版本、血缘 | calibrated requirements, design inputs, API impact decision, engineering impact decision | API impact record; contract sketch or reviewable OpenAPI Draft marked draft-for-review; OpenAPI Draft Review; engineering baseline review; system overview; data architecture when required; ADR candidates; Design Review result | contract freeze and Issue formalization |
 | 6. Contract freeze and Issue formalization | OpenAPI Freeze、无 API 影响记录、正式拆分垂直切片 | Design Review approval, contract draft / OpenAPI Draft, PRD/design/architecture artifacts | OpenAPI Freeze or no API impact record; GitHub/GitLab/local vertical slice Issues | vertical slices and TDD implementation |
 | 7. Vertical slices and TDD implementation | issue、切片、实现、review、清理简化 | frozen contract / no API impact, approved slice, implementation repo/location | implementation routing, YSS skill routing, tests, review, verification evidence | verification, release, and retrospective |

package/template/.codex/skills/yss-ui/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: "yss-ui"
-description: "YSS UI 页面开发组件技能。涉及 YTable、YTree、YssFormily、useTableHeight、useTreeHeight、页面布局、Hook 抽离、API/Mock 联调、路由菜单约定时必须使用。组件技能可以参考 yss-components 与 yss-hooks 技能规范。"
+description: "YSS UI 页面开发组件技能。涉及 YTable、YTree、YssFormily、useTableHeight、useTreeHeight、页面布局、Hook 抽离、API 契约接入、路由菜单约定时必须使用。组件技能可以参考 yss-components 与 yss-hooks 技能规范。"
 ---
 
 # YSS UI 页面与 Hook 一体化标准
@@ -197,19 +197,13 @@ const { loading, run: runPage } = useRequest(pageApi, {
 - 翻页仅更新 `page/pageSize`，保留筛选项
 - 导出、刷新等动作复用 `currentParams`
 
-## 11. API 与 Mock 联调标准
-
-API 层：
+## 11. API 契约接入标准
 
 - 接口写在 `packages/src/api/*`
 - 复用 `mutator.ts`
 - 避免重复拼接 `/api`
-
-Mock 层：
-
-- 路由放 `packages/mock/api.ts`
-- 支持筛选和分页切片
-- 返回结构统一：`{ code, message, data: { list, total, page, pageSize } }`
+- 请求 / 响应字段以冻结后的 OpenAPI 或明确的契约草案为准
+- 未冻结契约不得作为稳定生成客户端或实现依据
 
 ## 12. 路由菜单标准
 

package/template/.codex/skills/yss-ui/references/quick-recipes.md

@@ -152,7 +152,7 @@ const nodeColumns = reactive<YTableColumn[]>([
 
 ---
 
-## 模板 4：列表请求 + Mock 联调
+## 模板 4：列表请求 + API 接入
 
 ```ts
 const fetchData = async () => {

package/template/AGENTS.md

@@ -67,6 +67,10 @@ yss-product-lifecycle
 -> competitive-intelligence (需要竞品 / 市场事实时)
 -> grill-with-docs
 -> to-prd
+-> product overview design / functional architecture
+-> product-design-prototype
+-> prototype-review
+-> high-fidelity-html-prototype
 -> OpenAPI Draft
 -> OpenSpec-style Spec Delta (中高风险行为变化时)
 -> OpenAPI Freeze
@@ -126,9 +130,10 @@ Matt skills 与 YSS skills 产物正文默认使用中文，包括澄清记录
 - 任务开始前必须先参考 `docs/process/harness-process-tailoring.md` 判断小改动 / 中等变更 / 新模块或高风险变更；裁剪只能减少不相关产物，不能裁剪安全人审、Issue 追踪、Git checkpoint 和 fresh verification。
 - 新功能或较大改动必须先用 `grill-with-docs` 澄清需求，再用 `to-prd` 形成 PRD，并在 PRD、实施计划或 Issue 中引用澄清记录。
 - PRD 基线阶段必须同步明确功能架构：功能域、模块边界、优先级、MVP / 非目标范围和模块依赖；不清晰时不得进入 PRD 校准。
+- 只要进入 PRD 初稿 / 需求基线流程，产品总体设计 / 功能架构就是必要产物，默认路径为 `docs/design/<feature>-product-overview-design.md`，且必须包含低保真原型 / 页面草图。不得直接从 PRD 初稿进入页面 / 原型 / 交互设计、OpenAPI Draft、PRD 校准、需求冻结或实现；不进入 PRD 生命周期的小文案、低风险 Bug 或局部配置变更，必须在影响面评估中说明不适用原因。
 - 涉及页面设计、原型评审、UI 实现、组件选型、主题 token、颜色排版间距或 Ant Design / YSS UI 风格一致性的任务，必须先用 `yss-design-system` 作为设计系统基线；详细规范引用 `docs/design/design-system.md`。
-- 有用户界面的功能在 PRD 初稿后必须先引用 `yss-design-system`，再用 `product-design-prototype` 产出页面、原型、交互状态、PRD 回填项和 OpenAPI 反推清单，并通过 `prototype-review` 后才能进入 PRD 校准 / 需求冻结和 UI 驱动的 OpenAPI Draft。
-- 任何 API 契约变更必须先在 `docs/api/specs/*.yaml` 形成 Draft；有 UI 的功能不得只基于 PRD 反推 OpenAPI，必须结合产品总体设计、页面/原型/交互说明、状态矩阵和 `prototype-review` 结论，经工程基线（如适用）、系统 / 数据架构和设计审查后 Freeze，再实现前后端和测试。
+- 有用户界面的功能在 PRD 初稿和产品总体设计 / 功能架构后必须先引用 `yss-design-system`，再用 `product-design-prototype` 产出页面、原型、交互状态、PRD 回填项和 OpenAPI 反推清单；低保真 `prototype-review` 通过后，必须新增 `high-fidelity-html-prototype` 产物，默认路径为 `docs/design/prototypes/<feature>/index.html`，且必须使用 Ant Design v6，之后才能进入 PRD 校准 / 需求冻结和 UI 驱动的 OpenAPI Draft。
+- 任何 API 契约变更必须先在 `docs/api/specs/*.yaml` 形成 Draft；OpenAPI 不得只基于 PRD 反推，必须结合产品总体设计 / 功能架构；有 UI 的功能还必须结合页面/原型/交互说明、状态矩阵、`prototype-review` 结论和 Ant Design v6 高保真 HTML 原型，经工程基线（如适用）、系统 / 数据架构和设计审查后 Freeze，再实现前后端和测试。
 - API、权限、状态机、数据模型、跨端、新模块或高风险行为变化，应在 Design Review / OpenAPI Freeze 前补充 OpenSpec-style Spec Delta，落点为 `docs/specs/<feature>-spec-delta.md`；小文案、局部样式、配置微调和低风险 Bug 默认不需要。Spec Delta 只记录行为差异、验收场景和测试映射，不恢复 OpenSpec CLI、额外变更目录或状态机。
 - OpenAPI Freeze 后进入 `to-issues`，将冻结范围拆成端到端垂直切片 Issue；不得要求额外状态机或变更目录作为交付前置。
 - 涉及服务边界、部署、集成、性能、安全、可靠性或运维的变更，必须在设计审查前产出系统总体架构或等价设计记录。
@@ -252,7 +257,8 @@ Web Adapter
 |------|----------|------|--------|
 | PRD Review | PRD 完成后 | Product / Domain Review Agent | 用户、痛点、非目标范围、验收标准或安全红线不清 |
 | Grilling Review | 新功能 / 较大改动 PRD 前、Architecture Review 前 | Product / Domain / Architecture Agent with `grill-with-docs` | 用户价值、边界、状态、反例、架构约束、验收标准或安全红线经不起质询 |
-| Prototype Review | 有 UI 的 PRD 初稿完成后、PRD 校准前 | Product Design / UX / Frontend / API Agent | 页面清单、原型/线框、用户流、状态矩阵、PRD 回填项、权限状态或 OpenAPI 反推清单不清 |
+| Prototype Review | 有 UI 的 PRD 初稿完成后、高保真 HTML 原型前 | Product Design / UX / Frontend / API Agent | 页面清单、原型/线框、用户流、状态矩阵、PRD 回填项、权限状态或 OpenAPI 反推清单不清 |
+| High-fidelity HTML Prototype Review | 低保真原型评审通过后、PRD 校准前 | Product Design / UX / Frontend Agent | Ant Design v6 高保真 HTML 原型缺失、主流程/关键状态/响应式/权限体验不可审查 |
 | API Review | OpenAPI Draft 后 | API + Frontend + Backend Agent | schema、错误结构、分页、权限、契约测试不可落地 |
 | Architecture Review | 系统/数据架构后 | Architecture Review Agent | 业务/功能/系统/数据架构、DDD 分层、模块依赖、ADR、状态流或回滚策略不清 |
 | Plan Review | 垂直切片生成后 | Planning / Test Agent | 切片横向拆层、缺测试命令、缺回滚点或范围过大 |

package/template/CONTEXT.md

@@ -12,6 +12,7 @@
 | PRD | 产品需求文档，用于记录用户问题、解决方案、用户故事、关键决策和测试 seam。 | 除非作为既有参考，否则不要写入具体实现文件路径。 |
 | OpenAPI Draft | review-only 的 OpenAPI 3.1 契约草案。 | Freeze 前不得作为前后端稳定实现契约。 |
 | OpenAPI Freeze | 已通过评审、可作为前后端实现和契约测试输入的 OpenAPI 3.1 契约。 | Freeze 后变更必须回到 API 影响分析和设计审查。 |
+| 高保真 HTML 原型 | 低保真原型评审通过后，用于在浏览器中审查真实视觉密度、交互状态和页面流的产品设计资产。 | 不等同于生产前端实现，也不替代 OpenAPI、PRD 校准或垂直切片。 |
 | 垂直切片（Vertical Slice） | 贯穿所有受影响层、可独立验证的窄功能路径。 | 优先使用垂直切片，避免只按层拆分的横向任务。 |
 | ADR | 架构决策记录，用于沉淀难以回滚、非显而易见且存在真实取舍的技术决策。 | 常规实现选择不要写 ADR。 |
 | Fresh Verification | 完成前重新执行的验证证据，包括测试命令、契约校验、关键路径检查或人工审查结论。 | 不等同于“之前跑过”或实现者自述。 |

package/template/docs/api/templates/openapi-draft-review-checklist.md

@@ -16,6 +16,7 @@
 | 原型 / 线框图 |  |  |
 | 状态矩阵 | `docs/design/<feature>-state-matrix.md` |  |
 | 原型评审结论 | `docs/design/<feature>-prototype-review.md` |  |
+| 高保真 HTML 原型 | `docs/design/prototypes/<feature>/index.html` | 有 UI 时必需；必须使用 Ant Design v6 |
 | YSS 工程基线 | `.codex/skills/yss-ddd-scaffold-generator/references/yss-backend-scaffold-parent/SKILL.md` |  |
 
 ## P0 追踪矩阵
@@ -31,7 +32,8 @@
 | Draft 成熟度 | 明确当前仅为 review-only；实现、生成 client、契约测试固化均等待 OpenAPI Freeze |  |  |
 | OpenAPI 语法 | YAML、`$ref`、path 参数、lint 通过 |  |  |
 | P0 覆盖 | 每个 P0 需求有 endpoint/schema/error/test 或明确非目标 |  |  |
-| 交互输入完整 | Draft 已同时依据 PRD、产品总体设计、交互说明、原型/线框、状态矩阵和 prototype-review；缺任一项需说明无 UI 影响或返回上游补齐 |  |  |
+| 产品总体设计完整 | Draft 已依据 PRD 和产品总体设计 / 功能架构；缺产品总体设计时返回上游补齐 |  |  |
+| 交互输入完整 | 有 UI 时，Draft 已同时依据交互说明、原型/线框、状态矩阵、prototype-review 和 Ant Design v6 高保真 HTML 原型；无 UI 时需说明页面 / 交互资产不适用原因 |  |  |
 | DDD 契约边界 | Endpoint/schema 归属的限界上下文清楚；术语与 `CONTEXT.md` 和功能架构一致；契约不直接暴露内部聚合、Repository 或持久化表结构 |  |  |
 | 页面动作覆盖 | 每个按钮 / 抽屉 / 弹窗动作有 endpoint/non-goal、`actionKey`、权限和错误码 |  |  |
 | 对象生命周期 | manage/maintain/configure/create/update/archive/retry/cancel/publish/export/create-draft 语义闭环 |  |  |

package/template/docs/design/README.md

@@ -7,7 +7,9 @@
 - `docs/design/design.md`：从本地 `Product-Design-System` 引入并整理的 Ant Design 企业级设计系统说明，后续页面设计、交互说明、原型评审和前端实现默认引用该文件。
 - `docs/design/tokens/`：随仓库保存的主题、亮色 / 暗色 / 紧凑 token 和 CSS 变量快照，后续实现不得依赖本机 Downloads 目录。
 
-进入 API 影响分析 / 契约草案前，有用户界面的功能建议先沉淀：
+进入 PRD 初稿 / 需求基线流程后，必须先沉淀产品总体设计 / 功能架构，再进入页面 / 原型 / 交互设计、PRD 校准、API 影响分析 / 契约草案或实现。产品总体设计文档必须包含低保真原型 / 页面草图，用于验证页面结构、关键操作和主流程。无 UI 的功能也需要产品总体设计 / 功能架构来说明功能域、业务对象、模块边界、API / 数据影响和不适用的页面状态；只有不进入 PRD 生命周期的小改动可在影响面评估中记录不适用原因。
+
+进入 API 影响分析 / 契约草案前，有用户界面的功能还必须沉淀：
 
 - 页面清单和信息架构。
 - 用户主路径和异常路径。
@@ -16,12 +18,13 @@
 - 表单、表格、弹窗、抽屉、步骤流等交互说明。
 - loading、empty、error、readonly、disabled、no-permission、conflict 等状态矩阵。
 - 页面字段、筛选条件、操作按钮和权限规则。
+- 低保真原型评审通过后的 Ant Design v6 高保真可交互 HTML 原型，默认路径为 `docs/design/prototypes/<feature>/index.html`。
 
 这些资产用于反推 API 影响、契约草案、OpenAPI 请求 / 响应字段、错误结构、分页筛选、权限状态和前端验收标准。
 
 推荐模板：
 
-- `docs/design/templates/product-overview-design-template.md`：PRD 初稿之后、页面 / 原型 / 交互设计之前，用于团队评审产品总体设计、功能架构、页面/API/数据影响和 PRD 回填项；它是原型设计输入，不是交互说明本身。
+- `docs/design/templates/product-overview-design-template.md`：PRD 初稿之后、页面 / 原型 / 交互设计之前，用于团队评审产品总体设计、功能架构、低保真原型、页面/API/数据影响和 PRD 回填项；它是后续交互设计输入，不替代详细交互说明。
 - `docs/design/templates/interaction-spec-template.md`：页面、流程、交互、PRD 回填项和 OpenAPI 反推清单。
 - `docs/design/templates/state-matrix-template.md`：loading、empty、error、readonly、no-permission、conflict 等状态。
 - `docs/design/templates/prototype-review-checklist.md`：进入 PRD 校准 / API 影响分析 / 契约草案前的原型评审门禁。
@@ -31,15 +34,15 @@
 - `yss-design-system`：项目设计系统与 Ant Design 企业级 UI 风格基线；页面设计、原型评审、UI 实现和主题 token 落地时默认先引用。
 - `product-design-prototype`：基于 PRD 初稿和产品总体设计 / 功能架构，产出页面 / 原型 / 交互设计资产。
 - `wireframe-prototype`：低保真线框、Excalidraw、Figma、Penpot、tldraw、Axure 等原型链接沉淀。
-- `component-story-prototype`：Storybook / Histoire 工程态状态原型。
-- `mock-api-prototype`：MSW / mock fixtures 支撑未冻结 API 前的交互验证。
 - `prototype-review`：原型阶段评审门禁；未通过则不要进入 PRD 校准 / API 影响分析 / 契约草案。
+- `high-fidelity-html-prototype`：低保真原型评审通过后，基于官方 `@ant-design/cli` / Ant Design For Agents 指引生成 Ant Design v6 高保真可交互 HTML 原型；未产出前不要进入 PRD 校准 / API 影响分析 / 契约草案。
 - `excalidraw-diagram-generator`：根据已形成的 Discovery、PRD、OpenAPI Draft、Architecture 或 系统 / 数据架构设计 生成 `.excalidraw` 图；用于说明和审查，不替代文本规格。
 
 推荐目录：
 
 ```text
 docs/design/diagrams/
+docs/design/prototypes/
 docs/architecture/diagrams/
 docs/discovery/diagrams/
 ```

package/template/docs/design/prototypes/.gitkeep

@@ -0,0 +1 @@
+

package/template/docs/design/templates/interaction-spec-template.md

@@ -1,15 +1,17 @@
 # <功能名称> 交互说明模板
 
-> 适用时机：PRD 初稿之后、PRD 校准 / API 影响分析 / 契约草案之前；仅用于有用户界面影响的功能。
+> 适用时机：PRD 初稿和产品总体设计 / 功能架构完成之后，PRD 校准 / API 影响分析 / 契约草案之前；仅用于有用户界面影响的功能。
 
 ## 1. 输入资产
 
 | 资产 | 路径 / 链接 | 说明 |
 |---|---|---|
 | PRD 初稿 | `docs/requirements/<feature>-prd.md` | 原型评审后需要回填和校准 |
+| 产品总体设计 / 功能架构 | `docs/design/<feature>-product-overview-design.md` | 必需；缺失时先返回产品总体设计阶段 |
 | 领域术语 | `CONTEXT.md` | 核心名词、状态和业务规则 |
 | Discovery | `docs/discovery/<feature>-discovery.md` | 可选 |
 | 原型 / 线框图 | `<链接或导出图片路径>` | Excalidraw / Figma / Penpot / tldraw / Axure / Markdown |
+| 高保真 HTML 原型 | `docs/design/prototypes/<feature>/index.html` | 低保真原型评审通过后补齐；必须使用 Ant Design v6 |
 | 现有 API 草案 | `docs/api/specs/<feature>.yaml` | 可选；通常应先完成产品设计和 PRD 校准 |
 
 ## 2. 页面地图
@@ -99,9 +101,9 @@
 ## 8. 前端验收
 
 - loading、empty、error、no-permission、readonly、conflict、dirty-form 状态已展示，或明确不适用。
-- 每个表格列、筛选条件、表单字段、抽屉、弹窗和按钮都有数据来源或 mock fixture。
+- 每个表格列、筛选条件、表单字段、抽屉、弹窗和按钮都有数据来源或契约反推说明。
 - 设计可以拆成独立可演示的垂直切片。
-- 如果需要工程态原型，已规划 Storybook / Histoire 或静态 fixture。
+- 低保真原型评审通过后，高保真 HTML 原型使用 Ant Design v6 覆盖主流程、关键状态和响应式断点。
 
 ## 9. 决策与未决问题
 

package/template/docs/design/templates/product-overview-design-template.md

@@ -8,7 +8,7 @@ owner: ai
 # <功能名称> 产品总体设计与功能架构
 
 > 适用时机：PRD 初稿之后、页面 / 原型 / 交互设计之前。
-> 本文用于明确功能域、模块边界、MVP 范围、页面清单、状态 / 权限影响、OpenAPI 反推点和 PRD 回填项；它是页面 / 原型 / 交互设计的上游输入，不替代 PRD、交互说明、契约草案 / OpenAPI Draft 或系统概要设计。
+> 本文用于明确功能域、模块边界、MVP 范围、页面清单、低保真原型、状态 / 权限影响、OpenAPI 反推点和 PRD 回填项；它是页面 / 原型 / 交互设计的上游输入，不替代 PRD、交互说明、契约草案 / OpenAPI Draft 或系统概要设计。
 
 ## 1. 输入资产
 
@@ -68,30 +68,59 @@ owner: ai
 |------|----------|----------|----------|------------------|------|
 |  |  |  |  |  |  |
 
-## 8. PRD 回填项
+## 8. 低保真原型 / 页面草图
+
+> 本节用于在产品总体设计阶段先验证页面结构、核心操作和跨页面流转，不展开到高保真视觉、组件实现或完整字段级交互；后续页面 / 原型 / 交互设计需基于本节继续细化。无 UI 功能仍保留本节，用流程 / 能力草图和“不适用原因”说明用户或系统如何完成任务。
+
+### 8.1 页面地图
+
+| 页面 / 区域 | 入口 | 核心任务 | 关键操作 | 下一步 |
+|-------------|------|----------|----------|--------|
+|  |  |  |  |  |
+
+### 8.2 低保真线框
+
+```text
+页面名称：
+
+[导航 / 面包屑]
+[查询 / 筛选区域]
+[主内容区域：表格 / 表单 / 画布 / 列表]
+[操作区：主按钮 / 次按钮 / 更多操作]
+[反馈区：校验结果 / 错误提示 / 空态]
+```
+
+### 8.3 原型评审关注点
+
+| 页面 / 流程 | 需要验证的问题 | 关联 P0 需求 | 关联 API / 数据 / 权限影响 | 后续交互设计待细化 |
+|-------------|----------------|--------------|-----------------------------|--------------------|
+|  |  |  |  |  |
+
+## 9. PRD 回填项
 
 | 编号 | 回填内容 | 影响章节 | 优先级 | 状态 |
 |------|----------|----------|--------|------|
 |  |  |  |  | 待确认 / 已回填 |
 
-## 9. 开放问题与决策
+## 10. 开放问题与决策
 
 | 问题 / 决策 | 选项 | 建议 | 负责人 | 截止点 | 状态 |
 |-------------|------|------|--------|--------|------|
 |  |  |  |  | PRD 校准前 / API 影响分析前 | 待确认 |
 
-## 10. 评审清单
+## 11. 评审清单
 
 - [ ] 用户主流程和异常路径已覆盖 MVP。
 - [ ] 业务对象、状态和关系不会与 `CONTEXT.md` 术语冲突。
 - [ ] 功能域、模块边界和优先级清楚。
 - [ ] Strategic DDD Check 已完成，或明确说明本次变更不影响领域边界。
 - [ ] 页面、API、数据、权限和审计影响已显式标注。
+- [ ] 低保真原型 / 页面草图已覆盖 P0 页面、主流程和关键异常路径，并能支撑后续交互设计。
 - [ ] PRD 回填项已列出，并分清阻断项和非阻断项。
 - [ ] 安全红线已标记 `TODO-HUMAN-REVIEW`。
 - [ ] 可进入页面 / 原型 / 交互设计，或明确阻断项。
 
-## 11. 结论
+## 12. 结论
 
 - 评审结论：Approved / Blocked
 - 阻断项：

package/template/docs/design/templates/prototype-review-checklist.md

@@ -1,6 +1,6 @@
 # <功能名称> 原型评审清单
 
-> 适用时机：配合 `prototype-review` 使用。评审采用 fail-closed：有阻断项时必须回到产品设计阶段，不能进入 PRD 校准或 API 影响分析 / 契约草案。
+> 适用时机：配合 `prototype-review` 使用。评审采用 fail-closed：有阻断项时必须回到产品设计阶段；低保真评审通过后必须进入 `high-fidelity-html-prototype`，不能直接进入 PRD 校准或 API 影响分析 / 契约草案。
 
 ## 评审输入
 
@@ -24,7 +24,7 @@
 | 权限行为能区分隐藏、禁用和调用后拒绝 |  |  |
 | 校验错误能区分模型级和字段级展示位置 |  |  |
 | 能从界面需求反推出 API 影响和契约草案 |  |  |
-| 前端验收、Storybook / Histoire 或 mock 数据需要已明确 |  |  |
+| 前端验收、组件状态和数据依赖已明确 |  |  |
 | 安全红线已标记人工审查 |  |  |
 
 ## PRD 校准就绪度
@@ -59,5 +59,5 @@
 非阻断建议：
 - 
 下一步：
-- PRD 校准 / API 影响分析 / 契约草案 / 回到 product-design-prototype / component-story-prototype / mock-api-prototype
+- high-fidelity-html-prototype / 回到 product-design-prototype
 ```

package/template/docs/process/harness-executive-blueprint.md

@@ -13,7 +13,7 @@ AI 不能只作为一次性辅助工具使用。Harness 工程的目标，是把
 ```text
 机会 / 问题收集
 → 需求澄清
-→ PRD + 原型并行
+→ PRD -> 产品总体设计 -> 原型校准
 → SDD 研发规范基线
 → DDD 领域建模
 → 架构设计
@@ -31,6 +31,7 @@ AI 不能只作为一次性辅助工具使用。Harness 工程的目标，是把
 ## 哪些门禁不能跳
 
 - API 变化必须先有 API 影响记录和契约草案 / review-only OpenAPI Draft，并在实现或生成客户端前完成 Freeze 或记录无 API 影响。
+- 进入 PRD 初稿 / 需求基线流程后，必须先有产品总体设计 / 功能架构，才能进入页面 / 原型 / 交互设计、OpenAPI Draft、PRD 校准、需求冻结或实现；不进入 PRD 生命周期的小改动才可记录不适用原因。
 - 正式垂直切片前必须有 active Issue change 和完整 change 资产。
 - 架构、数据、ADR、工程基线和安全红线必须进入 Build Architecture Checklist。
 - 支付、迁移、认证授权、加密、SQL、公共基础库 API 等安全红线必须人工审查。
@@ -43,6 +44,9 @@ AI 不能只作为一次性辅助工具使用。Harness 工程的目标，是把
 
 ```text
 PRD
+→ 产品总体设计 / 功能架构
+→ 页面 / 原型 / 交互设计与 prototype-review（有 UI 时）
+→ Ant Design v6 高保真 HTML 原型（有 UI 时）
 → API 影响分析 / 契约草案
 → review-only OpenAPI Draft（如需要）
 → Issue Change

package/template/docs/process/harness-process-tailoring.md

@@ -16,9 +16,9 @@
 
 | 当前输入 / 变更事实 | 最近可信阶段 | 需要补齐的下游 |
 |---|---|---|
-| 只有模糊想法、业务机会或竞品输入 | 2. 机会与 Discovery | Discovery、`grill-with-docs`、PRD、业务 / 功能架构 |
-| 已有清晰 PRD，但用户、痛点、MVP 或非目标不稳 | 3. 业务 / PRD / 功能架构 | PRD Review、功能架构、必要的产品设计 |
-| 有 UI 变更但缺页面流、状态矩阵或原型评审 | 4. 产品设计与需求冻结 | 交互说明、状态矩阵、Prototype Review、PRD 回填 |
+| 只有模糊想法、业务机会或竞品输入 | 2. 机会与 Discovery | Discovery、`grill-with-docs`、PRD、产品总体设计 / 功能架构 |
+| 已有清晰 PRD，但用户、痛点、MVP 或非目标不稳 | 3. 业务 / PRD / 功能架构 | PRD Review、产品总体设计 / 功能架构、必要的页面 / 原型 / 交互设计 |
+| 有 UI 变更但缺页面流、状态矩阵、原型评审或高保真 HTML 原型 | 4. 产品设计与需求冻结 | 交互说明、状态矩阵、Prototype Review、Ant Design v6 高保真 HTML 原型、PRD 回填 |
 | API 路径、schema、错误结构、分页或权限发生变化 | 5. 系统 / 数据架构与工程契约设计审查 | API 影响记录、契约草案 / OpenAPI Draft Review、必要时 Spec Delta、系统 / 数据架构反审、Freeze、`to-issues` |
 | 服务边界、集成、部署、性能、可靠性或运维变化 | 5. 系统 / 数据架构与工程契约设计审查 | 系统架构、Design Review、必要时 Spec Delta、Build Architecture Checklist |
 | 持久化、元数据、版本、血缘、搜索、索引或迁移变化 | 5. 系统 / 数据架构与工程契约设计审查 | 数据架构、必要时 Spec Delta、人审点、Repository / MyBatis 前置审查 |

package/template/docs/process/harness-work-unit-map.md

@@ -14,7 +14,7 @@
 |---|---|---|---|---|---|---|
 | 0. 机会 / 问题收集 | 1. 入口分诊；2. 机会与 Discovery | 0. 入口分诊；1. 机会探索 | 分诊结论、Discovery 收敛、MVP 边界 | `yss-product-lifecycle`、`competitive-intelligence`、Discovery 模板 | 小改动可跳过；新产品 / 新模块必需 | 半自动生成分诊清单、竞品情报简报和 Discovery 模板 |
 | 1. 需求澄清 | 3. 业务 / PRD / 功能架构 | 3. 需求澄清 | 澄清记录、用户 / 痛点 / 验收标准 | `grill-with-docs`、`to-prd` | 小文案 / 单点 bug 可轻量化 | 半自动生成澄清问题和缺口清单 |
-| 2. PRD + 原型并行 | 3. 业务 / PRD / 功能架构；4. 产品设计与需求冻结 | 4. 需求基线 / 功能架构；5. 页面 / 原型 / 交互设计；6. 原型评审；7. PRD 校准 / 需求冻结 | PRD、页面清单、状态矩阵、原型评审、需求冻结 | `yss-design-system`、`product-design-prototype`、`prototype-review` | 无 UI 可省略原型；中等变更只补受影响页面 | 半自动检查 PRD 字段、状态矩阵和原型评审项 |
+| 2. PRD -> 产品总体设计 -> 原型校准 | 3. 业务 / PRD / 功能架构；4. 产品设计与需求冻结 | 4. 需求基线 / 功能架构；5. 页面 / 原型 / 交互设计；6. 原型评审；7. PRD 校准 / 需求冻结 | PRD、产品总体设计 / 功能架构、低保真原型、页面清单、状态矩阵、原型评审、Ant Design v6 高保真 HTML 原型、需求冻结 | `yss-design-system`、`product-design-prototype`、`prototype-review`、`high-fidelity-html-prototype` | 无 UI 可省略后续交互原型；进入 PRD 初稿 / 需求基线流程时不得省略产品总体设计及其低保真原型；有 UI 时低保真评审通过后不得省略高保真 HTML 原型；中等变更只补受影响页面 | 半自动检查 PRD 字段、产品总体设计、低保真原型、状态矩阵、原型评审和高保真 HTML 原型 |
 | 3. SDD 研发规范基线 | 5. 系统 / 数据架构与工程契约设计审查；6. 契约冻结与 Issue | 8. API 影响分析 / 契约草案；9. 工程基线；13. 契约冻结；14. Issue formalization | API 影响记录、契约草案 / OpenAPI Draft / Freeze、Spec Delta、工程基线、垂直切片 Issue、实施路由、验证证据 | `to-issues`、`yss-router` | 无 API / 无工程边界变化时记录无影响结论；低风险小改动跳过 Spec Delta | 自动检查 OpenAPI Freeze / no API impact / Spec Delta / vertical slice Issue / implementation routing |
 | 4. DDD 领域建模 | 3. 业务 / PRD / 功能架构；5. 系统 / 数据架构与工程契约设计审查 | 2. 业务架构；10. 系统总体架构；11. 数据架构 | CONTEXT 术语、业务能力、领域边界、聚合 / 状态规则 | `domain-modeling`、`yss-domain-modeling`、`yss-domain` | 小改动只校验是否影响既有术语或边界 | 半自动检查术语回填和领域边界审查项 |
 | 5. 架构设计 | 5. 系统 / 数据架构与工程契约设计审查 | 8. API 影响分析 / 契约草案；9. 工程基线；10. 系统总体架构；11. 数据架构；12. 设计审查 | API 影响记录、工程基线、系统概要设计、数据架构、ADR 候选、架构评审 | `codebase-design`、`improve-codebase-architecture`、YSS 架构模板 | 不触碰 API、工程边界、服务边界、数据、NFR、部署时可轻量记录无影响 | 半自动生成 Architecture Review checklist |

package/template/docs/process/lifecycle-artifact-map.md

@@ -22,8 +22,8 @@ owner: ai
 |---|---|---|---|---|
 | 1. 入口分诊 | 判断任务类型、风险等级、最近可信阶段和最小技能集 | 分诊结论或 issue 备注 | `yss-product-lifecycle` 路由结果、Git checkpoint 判断 | 是否需要 Discovery / PRD / API / 架构 / Issue |
 | 2. 机会与 Discovery | 收敛用户、痛点、为什么现在做、MVP、非目标、成功标准、产品功能指引和下游影响信号 | `docs/discovery/<feature>-discovery.md` 或等价说明 | `competitive-intelligence` 竞品情报、竞品矩阵、机会说明、产品功能指引、下游影响清单、市场分析、用户痛点文档 | 是否足以进入业务架构和 PRD |
-| 3. 业务 / PRD / 功能架构 | 明确产品边界、用户旅程、功能域、模块边界、优先级和验收标准 | `docs/requirements/<feature>-prd.md` | `grill-with-docs` 澄清记录、业务架构、功能架构、CONTEXT 术语回填 | PRD Review / 产品设计准备度 |
-| 4. 产品设计与需求冻结 | 对 UI、页面流、状态矩阵、异常路径和 PRD 回填做闭环 | 有 UI 时：交互说明和原型评审结论；无 UI 时：需求冻结记录 | 状态矩阵、页面地图、原型链接 | PRD 校准 / 工程契约与架构设计准备度 |
+| 3. 业务 / PRD / 功能架构 | 明确产品边界、用户旅程、功能域、模块边界、优先级、低保真原型和验收标准 | `docs/requirements/<feature>-prd.md`；`docs/design/<feature>-product-overview-design.md` | `grill-with-docs` 澄清记录、业务架构、CONTEXT 术语回填；不进入 PRD 生命周期的小改动可记录不适用原因 | PRD Review / 产品总体设计评审 / 产品设计准备度 |
+| 4. 产品设计与需求冻结 | 基于 PRD 初稿和产品总体设计，对 UI、页面流、状态矩阵、异常路径、高保真体验和 PRD 回填做闭环 | 有 UI 时：交互说明、低保真原型评审结论、Ant Design v6 高保真 HTML 原型；无 UI 时：需求冻结记录 | 状态矩阵、页面地图、原型链接 | PRD 校准 / 工程契约与架构设计准备度 |
 | 5. 系统 / 数据架构与工程契约设计审查 | 合并 API 影响分析、契约草案、工程基线、系统架构、数据架构和 Design Review；Draft 仅用于评审，Freeze 前不得作为实现或生成客户端契约 | 系统概要设计或等价架构记录；Design Review 结论；有 API 时：API 影响记录和契约草案 / review-only OpenAPI Draft；有后端结构影响时：工程基线审查 | OpenAPI Draft Review、OpenSpec-style Spec Delta、工程基线审查、无 API 影响记录、数据架构、ADR、架构图 | OpenAPI Freeze 准备度 |
 | 6. 契约冻结与 Issue formalization | 冻结契约并把交付范围转成可执行 Issue，并明确受影响前后端工程是否已存在 | OpenAPI Freeze 记录或无 API 影响记录；垂直切片 Issue 入口 | `to-issues` 输出、实施路由记录、实现仓库 / 脚手架判定、Issue tracker 同步 | 垂直切片准备度 |
 | 7. 垂直切片与 TDD 实现 | 将冻结范围拆成端到端切片并按 TDD 实现 | 垂直切片 Issue、实施计划、Build Architecture Checklist、测试 / 验证记录 | YSS skill routing、前后端脚手架初始化记录、`implement` / `tdd` 证据、`code-review` 报告、清理简化记录、Architecture Re-check | Fresh verification / Release Review |
@@ -37,9 +37,9 @@ owner: ai
 | 1. 机会探索 | 2. 机会与 Discovery | 机会输入、MVP 边界、非目标范围 | 新产品 / 新模块必需 |
 | 2. 业务架构 | 3. 业务 / PRD / 功能架构 | 业务架构或 PRD 中等价章节 | 新产品 / 新业务域必需 |
 | 3. 需求澄清 | 3. 业务 / PRD / 功能架构 | `grill-with-docs` 结论或等价澄清记录 | 新功能 / 较大改动必需 |
-| 4. 需求基线 / 功能架构 | 3. 业务 / PRD / 功能架构 | PRD、功能域、模块边界、验收标准 | 新功能 / 较大改动必需 |
-| 5. 页面 / 原型 / 交互设计 | 4. 产品设计与需求冻结 | 交互说明、页面清单、状态矩阵 | 有 UI 时必需 |
-| 6. 原型评审 | 4. 产品设计与需求冻结 | Prototype Review 结论 | 有 UI 时必需 |
+| 4. 需求基线 / 功能架构 | 3. 业务 / PRD / 功能架构 | PRD；产品总体设计 / 功能架构资产；功能域、模块边界、低保真原型、验收标准 | 进入 PRD 初稿 / 需求基线流程时必需 |
+| 5. 页面 / 原型 / 交互设计 | 4. 产品设计与需求冻结 | 基于 PRD 初稿和产品总体设计 / 功能架构产出的交互说明、页面清单、状态矩阵 | 有 UI 时必需；缺产品总体设计时阻断 |
+| 6. 原型评审 | 4. 产品设计与需求冻结 | Prototype Review 结论；通过后必须产出 Ant Design v6 高保真 HTML 原型 | 有 UI 时必需 |
 | 7. PRD 校准 / 需求冻结 | 4. 产品设计与需求冻结 | 需求冻结记录或校准后的 PRD | 必需；无 UI 可轻量化 |
 | 8. API 影响分析 / 契约草案 | 5. 系统 / 数据架构与工程契约设计审查 | API 影响记录、契约草案 / OpenAPI Draft 或无 API 影响记录；Draft 在 Freeze 前仅可评审；中高风险变更补 OpenSpec-style Spec Delta | 有 API 影响时必需；Spec Delta 条件必需 |
 | 9. 工程基线 | 5. 系统 / 数据架构与工程契约设计审查 | 工程基线 / YSS DDD Review | 新服务 / 新模块 / 后端结构变化时必需 |
@@ -69,6 +69,7 @@ owner: ai
 | 交互说明 | `docs/design/<feature>-interaction-spec.md` | `docs/design/templates/interaction-spec-template.md` |
 | 状态矩阵 | `docs/design/<feature>-state-matrix.md` | `docs/design/templates/state-matrix-template.md` |
 | 原型评审 | `docs/design/<feature>-prototype-review.md` | `docs/design/templates/prototype-review-checklist.md` |
+| 高保真 HTML 原型 | `docs/design/prototypes/<feature>/index.html` | `high-fidelity-html-prototype` |
 | 需求冻结 | `docs/requirements/<feature>-requirement-freeze.md` | `docs/templates/requirement-freeze-template.md` |
 | API 影响分析 / 契约草案 / OpenAPI Draft | API 影响记录、issue note 或 `docs/api/specs/<feature>.yaml` | `docs/templates/openapi-spec-template.yaml` |
 | OpenSpec-style Spec Delta | `docs/specs/<feature>-spec-delta.md` | `docs/templates/spec-delta-template.md` |

package/template/docs/templates/requirement-freeze-template.md

@@ -7,7 +7,7 @@ owner: ai
 
 # <功能名称>需求冻结记录
 
-> 适用场景：PRD 初稿经过业务架构、功能架构、产品设计 / 原型评审后，需要冻结可进入 API 影响分析 / 契约草案和工程设计的范围。
+> 适用场景：PRD 初稿经过产品总体设计 / 功能架构、产品设计 / 原型评审后，需要冻结可进入 API 影响分析 / 契约草案和工程设计的范围。
 > 本文记录最终范围、回填项、非目标和开放问题，不替代 PRD。
 
 ## 1. 输入材料
@@ -15,8 +15,9 @@ owner: ai
 | 资产 | 路径 / 链接 | 状态 | 备注 |
 |------|-------------|------|------|
 | PRD 初稿 |  |  |  |
-| 业务 / 功能架构 |  |  |  |
+| 产品总体设计 / 功能架构 |  |  | 必需 |
 | 产品设计 / 交互说明 |  |  |  |
+| 高保真 HTML 原型 | `docs/design/prototypes/<feature>/index.html` |  | 有 UI 时必需；Ant Design v6 |
 | Prototype Review |  |  |  |
 | CONTEXT 术语 |  |  |  |
 
@@ -50,7 +51,7 @@ owner: ai
 
 ## 6. 完成标准
 
-- [ ] PRD 已吸收产品设计、原型评审和功能架构暴露的阻断项。
+- [ ] PRD 已吸收产品总体设计 / 功能架构、产品设计、低保真原型评审和高保真 HTML 原型暴露的阻断项。
 - [ ] 本轮做什么、不做什么、延后什么已经明确。
 - [ ] OpenAPI、工程基线、系统架构、数据架构、安全红线影响已有明确结论。
 - [ ] 可进入 API 影响分析 / 契约草案 / 工程基线，或阻断项已列出。

package/template/docs/user-guide/product-lifecycle-workflow.md

@@ -172,7 +172,7 @@ docs/process/lifecycle-artifact-map.md
 
 ### 6.3 设计产品和契约
 
-有 UI 时先走设计系统、产品设计和原型评审。涉及 API 时，先生成 review-only OpenAPI Draft：
+有 UI 时先走设计系统、产品设计、低保真原型评审和 Ant Design v6 高保真 HTML 原型。涉及 API 时，先生成 review-only OpenAPI Draft：
 
 ```text
 基于 PRD 和产品设计，生成 OpenAPI 3.1 Draft。
@@ -206,7 +206,7 @@ OpenAPI Freeze 或无 API 影响记录完成后使用 `to-issues`：
 
 - Draft 阶段允许调整接口，但不能被当成稳定实现契约。
 - Freeze 后的契约变更必须回到 API 影响分析、架构 / 数据设计和 Design Review，不能边写代码边悄悄改接口。
-- 有 UI 的功能不得只基于 PRD 反推 OpenAPI，必须结合产品总体设计、页面/原型/交互说明和状态矩阵。
+- OpenAPI 不得只基于 PRD 反推：必须结合产品总体设计 / 功能架构；有 UI 时还必须结合页面 / 原型 / 交互说明、状态矩阵、低保真原型评审和 Ant Design v6 高保真 HTML 原型。
 - OpenAPI Freeze 后进入 `to-issues`，再进入前后端实现和契约测试。
 
 ## 8. 验证、发布和复盘

package/template/docs/user-guide/product-rd-lifecycle-best-practices.md

@@ -146,8 +146,10 @@ skills 是让 AI 按规程工作的“操作手册”，不是关键词装饰。
 | 不知道当前该做什么 | `yss-product-lifecycle` | 先阶段判断和资产检查，不写业务代码 |
 | 模糊需求追问 | `grill-with-docs` | 先问清，不让 AI 猜规则；稳定术语写 `CONTEXT.md` |
 | 生成 PRD 初稿 / 需求基线 | `to-prd` 或 PRD 模板 | 只基于已确认事实，不把待确认项写成需求 |
-| 页面和交互设计 | `product-design-prototype`、`wireframe-prototype`、`component-story-prototype`、`mock-api-prototype`、`docs/design/` | 基于 PRD 初稿细化页面流、状态和交互，再回填 PRD 并反推 API |
-| 原型评审 | `prototype-review` | 未通过时回到产品设计，不进入 PRD 校准 / API 影响分析 / 契约草案 |
+| 产品总体设计 / 功能架构 | `docs/design/templates/product-overview-design-template.md` | PRD 初稿后的必要产物；必须包含低保真原型 / 页面草图；进入页面 / 原型 / 交互设计、PRD 校准或 OpenAPI Draft 前必须完成 |
+| 页面和交互设计 | `product-design-prototype`、`wireframe-prototype`、`docs/design/` | 基于 PRD 初稿和产品总体设计细化页面流、状态和交互，再回填 PRD 并反推 API |
+| 原型评审 | `prototype-review` | 未通过时回到产品设计；通过后进入高保真 HTML 原型，不直接进入 PRD 校准 / API 影响分析 / 契约草案 |
+| 高保真 HTML 原型 | `high-fidelity-html-prototype` | 低保真评审通过后的强制产物；必须使用 Ant Design v6，并基于官方 `@ant-design/cli` / Ant Design For Agents 指引，输出 `docs/design/prototypes/<feature>/index.html` |
 | API 契约 | API 影响分析 / 契约草案 / OpenAPI Freeze 流程 | Draft 可讨论，Freeze 才可开发 |
 | 正式变更设计 | `to-issues` / Matt skills | 复用 PRD，聚焦技术方案、风险和测试 seam |
 | 拆切片 | `to-issues` | 必须是端到端垂直切片 |
@@ -208,7 +210,7 @@ Agent brief 最少包含：
 适合并行：
 
 - Discovery Agent 做竞品矩阵，Ideation Agent 基于同一主题做机会假设，最后由主 Agent 收敛。
-- API Contract Agent 和 Architecture Agent 分别审查 Draft 与 DDD 边界，前提是校准后的 PRD 已稳定，且 UI 功能的产品总体设计 / 功能架构、页面 / 原型 / 交互设计已评审或明确无 UI 影响。
+- API Contract Agent 和 Architecture Agent 分别审查 Draft 与 DDD 边界，前提是校准后的 PRD、产品总体设计 / 功能架构已稳定；有 UI 时，页面 / 原型 / 交互设计也已评审，或已明确无 UI 影响。
 - 多个独立垂直切片，且不会修改同一批文件。
 
 不适合并行：
@@ -363,7 +365,7 @@ docs/discovery/data-modeling-opportunity.md
 
 ## 6. 阶段 3：PRD 初稿 / 需求基线
 
-PRD 把追问结论变成可交付需求，不写实现代码。这里的 PRD 先形成“需求基线”，不等于最终冻结版本；有用户界面的功能，还需要先形成产品总体设计 / 功能架构，再经过页面 / 原型 / 交互设计校准后，回填 PRD 并进入 API 影响分析 / 契约草案。
+PRD 把追问结论变成可交付需求，不写实现代码。这里的 PRD 先形成“需求基线”，不等于最终冻结版本；进入 PRD 初稿 / 需求基线流程后，必须先形成产品总体设计 / 功能架构，再按是否有 UI 决定是否进入页面 / 原型 / 交互设计，最后回填 PRD 并进入 API 影响分析 / 契约草案。
 
 建议资产：
 
@@ -408,17 +410,17 @@ PRD 片段示例：
 - [ ] 非目标范围清晰。
 - [ ] 测试 seam 已明确。
 - [ ] 待人工确认问题没有伪装成已确认需求。
-- [ ] 有用户界面的功能已明确需要进入产品总体设计 / 功能架构，并在其后进入页面 / 原型 / 交互设计；简单文案或纯后端能力可记录跳过原因。
+- [ ] 产品总体设计 / 功能架构已作为 PRD 初稿后的必要产物进入下一阶段；不进入 PRD 生命周期的小文案、低风险 Bug 或局部配置变更已记录不适用原因。
 
 ## 7. 阶段 4：产品总体设计 / 功能架构
 
-产品总体设计 / 功能架构是 PRD 初稿到页面原型之间的过渡层。它回答“产品由哪些功能域和业务对象支撑”“MVP 做什么和不做什么”“哪些页面、状态、权限、API、数据会被影响”。它不是交互说明，也不替代页面原型，而是页面 / 原型 / 交互设计的上游输入。
+产品总体设计 / 功能架构是 PRD 初稿到页面 / 原型 / 交互设计之间的过渡层。它回答“产品由哪些功能域和业务对象支撑”“MVP 做什么和不做什么”“哪些页面、状态、权限、API、数据会被影响”，并用低保真原型 / 页面草图先验证页面结构、关键操作和主流程。它不是详细交互说明，也不替代后续交互设计，而是页面 / 原型 / 交互设计的上游输入。
 
 正确关系是先结构化、再原型化：
 
 ```text
 PRD 初稿定义目标、范围、用户故事和验收
--> 产品总体设计 / 功能架构明确功能域、模块边界、页面/API/数据影响和 PRD 回填项
+-> 产品总体设计 / 功能架构明确功能域、模块边界、低保真原型、页面/API/数据影响和 PRD 回填项
 -> 页面 / 原型 / 交互设计验证用户如何完成任务
 -> 交互发现遗漏后回填 PRD
 -> PRD、产品总体设计和交互设计一起作为 API 影响分析 / 契约草案输入
@@ -440,6 +442,7 @@ docs/design/templates/product-overview-design-template.md
 
 - [ ] 用户主流程、异常路径、业务对象和状态已足以支撑原型设计。
 - [ ] 功能域、模块边界、优先级、依赖和非目标范围清楚。
+- [ ] 低保真原型 / 页面草图已覆盖 P0 页面、主流程、关键操作和关键异常路径。
 - [ ] 页面、API、数据、权限、审计影响已显式标注。
 - [ ] PRD 回填项、开放问题和阻断项已记录。
 - [ ] 可进入页面 / 原型 / 交互设计，或明确阻断原因。
@@ -475,12 +478,11 @@ docs/design/data-modeling-prototype-review.md
 | 页面清单、用户流、状态矩阵、PRD 回填项、OpenAPI 反推 | `product-design-prototype` | 基于 PRD 初稿和产品总体设计后的原型入口 |
 | 低保真线框、流程草图 | `wireframe-prototype`；Excalidraw / Markdown wireframe | 适合快速讨论，不绑定工程依赖 |
 | 高保真或设计系统协作 | Figma / Penpot，必要时使用 `figma` / `figma-use` | 适合设计团队和组件规范沉淀 |
-| 工程态页面状态原型 | `component-story-prototype`；Storybook / Histoire | 适合验证 loading、empty、error、权限、冲突等状态 |
-| API 未冻结前的交互数据 | `mock-api-prototype`；MSW / JSON fixtures | 适合支撑 Storybook 或前端原型 |
+| 高保真可交互 HTML 原型 | `high-fidelity-html-prototype`；Ant Design v6 | 低保真原型评审通过后的必需产物，用于 PRD 校准和 API 反推前的体验确认 |
 | 图谱、血缘、流程编排画布 | tldraw / xyflow | 适合数据血缘、任务流、关系图等画布型体验 |
-| 进入 PRD 校准前门禁 | `prototype-review` | 未通过则回到原型阶段 |
+| 进入高保真前门禁 | `prototype-review` | 未通过则回到原型阶段 |
 
-如果团队使用 Figma、即时设计、Axure 或其它原型工具，可以在 `docs/design/data-modeling-interaction-spec.md` 中保存链接、版本、评审记录和关键截图说明。第一版不强制引入 Storybook、MSW、Excalidraw、Figma、Penpot、tldraw 或 xyflow 作为项目依赖。
+如果团队使用 Figma、即时设计、Axure 或其它原型工具，可以在 `docs/design/data-modeling-interaction-spec.md` 中保存链接、版本、评审记录和关键截图说明。第一版不强制引入 Excalidraw、Figma、Penpot、tldraw 或 xyflow 作为项目依赖。
 
 数据建模 MVP 的页面清单示例：
 
@@ -1006,11 +1008,23 @@ docs/user-guide/
 最后输出：已确认、待确认、非目标、建议写入 CONTEXT 的术语、需要 ADR 的取舍。
 ```
 
-### 20.3 页面 / 原型 / 交互设计
+### 20.3 产品总体设计 / 功能架构
+
+```text
+基于 <PRD 路径>，为 <功能名> 生成产品总体设计 / 功能架构。
+请使用 docs/design/templates/product-overview-design-template.md。
+重点输出：设计目标、用户主流程、业务对象与状态、功能域与模块边界、Strategic DDD Check、低保真原型 / 页面草图、页面/API/数据/权限/审计影响、PRD 回填项、开放问题和评审结论。
+边界：不要写交互细节、不要生成 OpenAPI Draft、不要实现代码；只判断是否足以进入页面 / 原型 / 交互设计。
+保存到 docs/design/<feature>-product-overview-design.md。
+结论必须明确：Approved 可进入页面 / 原型 / 交互设计或 PRD 校准；Blocked 需先补齐产品边界、业务对象、模块边界、低保真原型、页面/API/数据/权限影响或 PRD 回填项。
+```
+
+### 20.4 页面 / 原型 / 交互设计
 
 ```text
 使用 product-design-prototype。
-基于 <PRD 路径>，为 <功能名> 输出页面 / 原型 / 交互设计资产。
+基于 <PRD 路径> 和 docs/design/<feature>-product-overview-design.md，为 <功能名> 输出页面 / 原型 / 交互设计资产。
+如果缺少产品总体设计 / 功能架构，先阻断并要求补齐；不要直接继续生成交互设计。
 请生成页面清单、用户主路径、异常路径、低保真线框说明、交互状态矩阵、权限状态、空态/加载态/错误态。
 请明确这些设计如何反推 OpenAPI 字段、错误结构、分页筛选、权限和前端验收标准。
 请同时列出需要回填 PRD 的需求缺口、验收标准或非目标范围。
@@ -1018,24 +1032,35 @@ docs/user-guide/
 完成后输出 prototype-review 评审输入清单。
 ```
 
-### 20.4 原型评审
+### 20.5 原型评审
 
 ```text
 使用 prototype-review。
-输入资产：<PRD 路径>、docs/design/<feature>-interaction-spec.md、docs/design/<feature>-state-matrix.md、<原型链接或线框说明>。
+输入资产：<PRD 路径>、docs/design/<feature>-product-overview-design.md、docs/design/<feature>-interaction-spec.md、docs/design/<feature>-state-matrix.md、<原型链接或线框说明>。
 请审查页面覆盖、主路径、异常路径、loading/empty/error/no-permission/readonly/conflict/dirty-form 状态、权限行为、字段级错误、PRD 回填项和 OpenAPI 反推清单。
-输出：通过/阻断、阻断项、非阻断建议、PRD 校准就绪度、Contract Draft / OpenAPI Draft 就绪度、前端原型就绪度和下一步。
+输出：通过/阻断、阻断项、非阻断建议、高保真 HTML 原型输入就绪度、Contract Draft / OpenAPI Draft 输入风险和下一步。
+```
+
+### 20.6 高保真 HTML 原型
+
+```text
+使用 high-fidelity-html-prototype。
+基于 <PRD 路径>、docs/design/<feature>-product-overview-design.md、docs/design/<feature>-interaction-spec.md、docs/design/<feature>-state-matrix.md 和 docs/design/<feature>-prototype-review.md，
+为 <功能名> 生成 Ant Design v6 高保真可交互 HTML 原型。
+输出路径必须是 docs/design/prototypes/<feature>/index.html。
+请覆盖主流程、关键异常、loading/empty/error/no-permission/readonly/disabled/conflict/success 状态、表单校验、弹窗/抽屉、响应式断点。
+完成后给出 Ant Design v6 版本依据、`@ant-design/cli` 查询过的组件 / token / demo 和本地浏览器验证证据。
 ```
 
-### 20.5 PRD 校准 / 需求冻结
+### 20.7 PRD 校准 / 需求冻结
 
 ```text
-基于 <PRD 路径> 和 <交互设计路径>，执行 PRD 校准。
+基于 <PRD 路径>、<产品总体设计路径>、<交互设计路径> 和 <高保真 HTML 原型路径>，执行 PRD 校准。
 请检查页面流、状态矩阵、异常路径、权限状态和验收标准是否已经回填 PRD。
 输出：需要更新的 PRD 条目、仍待确认的问题、可以冻结的范围、不能进入 API 影响分析 / 契约草案的风险。
 ```
 
-### 20.6 技能路由
+### 20.8 技能路由
 
 ```text
 使用 yss-router。

package/template/.codex/skills/component-story-prototype/SKILL.md

@@ -1,55 +0,0 @@
----
-name: component-story-prototype
-description: Use when Storybook, Histoire, component stories, page-state demos, or engineering prototypes are needed to validate UI states before full frontend implementation.
----
-
-# Component Story Prototype
-
-Use this skill when design decisions need executable UI states. It plans engineering prototypes; it does not require adding Storybook or Histoire to a repo unless the frontend project chooses that dependency.
-
-## When To Use
-
-- Page behavior depends on many states: loading, empty, error, permission, conflict, readonly, dirty form.
-- Product/design review needs a clickable or inspectable UI before API Freeze.
-- Existing frontend already uses Storybook/Histoire, or the team wants a temporary engineering prototype.
-
-If the repo has no story tooling and the task only needs low-fidelity flow decisions, use `wireframe-prototype` instead.
-
-## Story Plan
-
-For each page or interaction, define:
-
-- Component/page name and route context.
-- Mock inputs and visible data.
-- Actions demonstrated.
-- State variants.
-- OpenAPI or mock fixture dependency.
-- Acceptance notes that later become frontend tests or E2E paths.
-
-Recommended variants:
-
-```text
-Default
-Loading
-Empty
-ValidationError
-NoPermission
-ReadonlyPublishedVersion
-ConflictOnPublish
-DirtyFormLeavePrompt
-```
-
-## Data Modeling Example
-
-For model field editing, plan stories for:
-
-- `ModelList.Default`, `ModelList.Empty`, `ModelList.NoPermission`.
-- `ModelDetail.DraftFields`, `ModelDetail.PublishedReadonly`.
-- `FieldEditor.Valid`, `FieldEditor.FieldLevelErrors`.
-- `PublishModel.ValidationFailed`, `PublishModel.Success`, `PublishModel.Conflict`.
-
-Use `mock-api-prototype` when these stories need stable mock responses before OpenAPI Freeze.
-
-## Handoff
-
-Record the story plan in the interaction spec. Do not treat stories as a replacement for PRD, OpenAPI, or design review.

package/template/.codex/skills/component-story-prototype/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Component Story Prototype"
-  short_description: "Storybook or Histoire state prototype plans"
-  default_prompt: "Use $component-story-prototype to plan component stories for UI state validation."

package/template/.codex/skills/mock-api-prototype/SKILL.md

@@ -1,48 +0,0 @@
----
-name: mock-api-prototype
-description: Use when MSW, mock service worker, mock fixtures, fake API responses, or prototype data contracts are needed before OpenAPI Freeze or generated API clients are available.
----
-
-# Mock API Prototype
-
-Use this skill to make prototypes exercise realistic data and error states before the formal API contract is frozen.
-
-## Guardrail
-
-Mock contracts are provisional. They may inform OpenAPI Draft, but they are not the source of truth after OpenAPI Freeze. Once the API is frozen, regenerate or align mocks from the frozen contract.
-
-## Fixture Contract
-
-For each mocked interaction, capture:
-
-- Operation name and screen/action that uses it.
-- Request params/body fields.
-- Success response shape.
-- Error response shape, including field-level validation errors when relevant.
-- Permission and conflict responses.
-- Pagination/filtering/sorting behavior when present.
-
-## Tool Choices
-
-| Situation | Suggested approach |
-|---|---|
-| Frontend prototype with network-like behavior | MSW handlers |
-| Storybook/Histoire state-only demo | JSON fixtures or static module mocks |
-| API design discussion | Markdown examples in interaction spec |
-| Contract has been frozen | Generate or align from OpenAPI via `api-integration` / `yss-openapi` |
-
-## Data Modeling Example
-
-Prototype these responses:
-
-- Model list success with draft/published statuses.
-- Empty model list.
-- Field editor save success.
-- Field editor validation error with `fieldCode`, `message`, and `severity`.
-- Publish validation failed with model-level and field-level errors.
-- Publish conflict when version changed since page load.
-- No-permission response for publish action.
-
-## Handoff
-
-Write mock examples into `docs/design/<feature>-interaction-spec.md` or the story plan. Then use `prototype-review` to confirm the mock data can drive PRD calibration and OpenAPI Draft.

package/template/.codex/skills/mock-api-prototype/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Mock API Prototype"
-  short_description: "Mock responses for prototype validation"
-  default_prompt: "Use $mock-api-prototype to design mock API fixtures before OpenAPI Freeze."