create-yss-spec 1.1.2 → 1.1.4

package/template/.pi/skills/handoff/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: handoff
+description: Compact the current conversation into a handoff document for another agent to pick up.
+argument-hint: "What will the next session be used for?"
+disable-model-invocation: true
+---
+
+Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS - not the current workspace.
+
+Include a "suggested skills" section in the document, which suggests skills that the agent should invoke.
+
+Do not duplicate content already captured in other artifacts (PRDs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.
+
+Redact any sensitive information, such as API keys, passwords, or personally identifiable information.
+
+If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.

package/template/.pi/skills/to-issues/SKILL.md

@@ -54,7 +54,7 @@ Iterate until the user approves the breakdown.
 
 For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. These issues are considered ready for AFK agents, so publish them with the correct triage label unless instructed otherwise.
 
-Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.
+Publish issues in dependency order (blockers first) so you can reference real issue identifiers. Where the tracker supports it, link each slice to its parent as a native **sub-issue** and wire each blocker as a native **blocking edge** (mechanics in the issue-tracker doc); the `## Parent` and `## Blocked by` body sections are the fallback otherwise.
 
 <issue-template>
 ## Parent
@@ -65,7 +65,7 @@ A reference to the parent issue on the issue tracker (if the source was an exist
 
 A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
 
-Avoid specific file paths or code snippets — they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it here and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
+Avoid specific file paths or code snippets — they go stale fast. Exception: if the `/prototype` skill produced code that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), add a context pointer to where that prototype code lives rather than inlining it.
 
 ## Acceptance criteria
 

package/template/.trae/skills/grill-me/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: grill-me
+description: A relentless interview to sharpen a plan or design.
+disable-model-invocation: true
+---
+
+Run a `/grilling` session.

package/template/.trae/skills/grilling/SKILL.md

@@ -0,0 +1,12 @@
+---
+name: grilling
+description: Grill the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.
+---
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.
+
+If a *fact* can be found by exploring the codebase, look it up rather than asking me. The *decisions*, though, are mine — put each one to me and wait for my answer.
+
+Do not enact the plan until I confirm we have reached a shared understanding.

package/template/.trae/skills/handoff/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: handoff
+description: Compact the current conversation into a handoff document for another agent to pick up.
+argument-hint: "What will the next session be used for?"
+disable-model-invocation: true
+---
+
+Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS - not the current workspace.
+
+Include a "suggested skills" section in the document, which suggests skills that the agent should invoke.
+
+Do not duplicate content already captured in other artifacts (PRDs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.
+
+Redact any sensitive information, such as API keys, passwords, or personally identifiable information.
+
+If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.

package/template/.trae/skills/to-issues/SKILL.md

@@ -54,7 +54,7 @@ Iterate until the user approves the breakdown.
 
 For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. These issues are considered ready for AFK agents, so publish them with the correct triage label unless instructed otherwise.
 
-Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.
+Publish issues in dependency order (blockers first) so you can reference real issue identifiers. Where the tracker supports it, link each slice to its parent as a native **sub-issue** and wire each blocker as a native **blocking edge** (mechanics in the issue-tracker doc); the `## Parent` and `## Blocked by` body sections are the fallback otherwise.
 
 <issue-template>
 ## Parent
@@ -65,7 +65,7 @@ A reference to the parent issue on the issue tracker (if the source was an exist
 
 A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
 
-Avoid specific file paths or code snippets — they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it here and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
+Avoid specific file paths or code snippets — they go stale fast. Exception: if the `/prototype` skill produced code that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), add a context pointer to where that prototype code lives rather than inlining it.
 
 ## Acceptance criteria
 

package/template/AGENTS.md

@@ -65,16 +65,19 @@ PRD 定义要做什么，OpenAPI 定义前后端契约，YSS 定义工程边界
 ```text
 yss-product-lifecycle
 -> competitive-intelligence (需要竞品 / 市场事实时)
+-> research (需要技术 / 标准 / API 一手资料时)
 -> grill-with-docs
+-> prototype (需要用一次性原型回答状态 / 逻辑 / UI 设计问题时)
 -> to-prd
 -> product overview design / functional architecture
--> product-design-prototype
+-> product-design:index
 -> prototype-review
--> high-fidelity-html-prototype
+-> Product Design focused skill 产出高保真 HTML 原型并经用户确认
 -> OpenAPI Draft
 -> OpenSpec-style Spec Delta (中高风险行为变化时)
 -> OpenAPI Freeze
 -> to-issues
+-> handoff / implementation routing (跨线程、跨仓库或上下文过长时)
 -> implement / tdd
 -> code-review
 -> fresh verification
@@ -128,11 +131,13 @@ Matt skills 与 YSS skills 产物正文默认使用中文，包括澄清记录
 - 新产品、新模块或较大变更必须先判断生命周期阶段、缺失资产和下一步；可用 `yss-product-lifecycle`，已有等价记录时可复用。
 - 小需求变更或迭代不从头重跑完整链路；必须先做影响面评估，找到最近可信阶段，只补齐受影响阶段及其下游资产。
 - 任务开始前必须先参考 `docs/process/harness-process-tailoring.md` 判断小改动 / 中等变更 / 新模块或高风险变更；裁剪只能减少不相关产物，不能裁剪安全人审、Issue 追踪、Git checkpoint 和 fresh verification。
+- 需要技术事实、标准、第三方 API、框架行为或规范依据时，必须优先用 `research` 或等价一手资料调研形成可引用记录；市场 / 竞品事实仍优先用 `competitive-intelligence`。
 - 新功能或较大改动必须先用 `grill-with-docs` 澄清需求，再用 `to-prd` 形成 PRD，并在 PRD、实施计划或 Issue 中引用澄清记录。
+- 需求、状态机、复杂业务规则或 UI 方向无法仅靠文字收敛时，可用 `prototype` 做一次性逻辑 / UI 原型；原型结论必须回填到 PRD、设计、ADR 或 Issue，原型代码不得替代 YSS 必需的 Ant Design v6 高保真 HTML 原型。
 - 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` 通过后，必须新增 `high-fidelity-html-prototype` 产物，默认路径为 `docs/design/prototypes/<feature>/index.html`，且必须使用 Ant Design v6，之后才能进入 PRD 校准 / 需求冻结和 UI 驱动的 OpenAPI Draft。
+- 有用户界面的功能在 PRD 初稿和产品总体设计 / 功能架构后必须先引用 `yss-design-system`，再以 `product-design:index` 作为产品原型产出主入口，按 Product Design plugin 路由到 `$get-context`、`$ideate`、`$prototype`、`$image-to-code`、`$url-to-code` 等 focused skill，产出页面、原型、交互状态、PRD 回填项和 OpenAPI 反推清单；低保真 `prototype-review` 通过后，必须产出高保真 HTML 原型，默认路径为 `docs/design/prototypes/<feature>/index.html`，且必须使用 Ant Design v6。原型产出前必须使用 `antd` CLI 查询设计语言、组件 API、demo、token 和 semantic 信息；原型完成后必须记录 AntD v6 校验证据。该高保真 HTML 原型是流程必需产物，可由系统 / Agent 在低保真评审通过后自动产出，不要求用户手工提供；产出后必须获得用户确认并记录确认结果，未产出或未确认前不得进入 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；不得要求额外状态机或变更目录作为交付前置。
@@ -140,11 +145,14 @@ Matt skills 与 YSS skills 产物正文默认使用中文，包括澄清记录
 - 涉及持久化、Repository、元数据、版本、血缘、搜索或查询策略的变更，必须在开发前产出数据架构；数据模型、元数据管理、ER 设计、版本管理或血缘分析类产品必须在 Design Review 和 OpenAPI Freeze 前完成数据架构。
 - 进入实现前，必须先判断当前需求涉及的前端 / 后端运行时代码工程是否已存在且可复用；若不存在、不可复用或目录约定缺失，必须先在 implementation routing 中记录原因，并路由到 `yss-ddd-scaffold-generator` 或 `yss-frontend-scaffold-generator` 初始化对应脚手架后再进入业务实现。
 - 进入实现前，必须把系统架构、数据架构、ADR、工程基线、OpenAPI Freeze 结论和安全红线转译为当前切片的 `Build Architecture Checklist`。
+- 跨线程、跨仓库、上下文接近上限、原型分支回流或实现仓库交接时，必须使用 `handoff` 或等价交接记录，写清来源资产、当前阶段、未决问题、验证命令和下一步责任人。
 - 每个垂直切片完成时必须回勾 `Build Architecture Checklist`：已落实项给出代码、测试或文档证据；延期项说明原因、风险、补齐切片和是否允许继续；漂移项必须触发 Architecture Re-check；违反项必须停止实现并回到设计审查或架构修正。
 - 涉及 Repository / Gateway / 持久化边界、权限 / 认证 / 授权、审计日志、SQL / DDL / 迁移、文件上传下载 / 临时 URL、版本快照 / 元数据 / 血缘 / 查询索引、跨模块接口、部署、回滚或运维约束时，必须在当前切片的实现记录中写明架构对齐状态和 `TODO-HUMAN-REVIEW` 补齐落点。
 - 当需求、架构、流程、状态机、数据流或垂直切片关系仅靠文字难以说明时，可用 `excalidraw-diagram-generator` 生成 `.excalidraw` 图作为辅助材料；图不能替代 PRD、OpenAPI、ADR 或测试。
 - 任何 Bug、测试失败或性能回退必须先用 `diagnosing-bugs` 建立可复现反馈命令，再修复。
+- 处理 merge / rebase 冲突时必须使用 `resolving-merge-conflicts` 或等价流程：理解双方意图、保留真实目的、重新运行相关检查，并记录取舍。
 - 业务行为实现默认使用 `tdd`：先写一个会失败的行为测试并确认失败，再写最小实现；生成代码、配置或一次性原型如不适用 TDD，必须明确例外原因和验证方式。
+- 修改 YSS / Matt skill、AGENTS 规则或流程模板时，必须按 `writing-skills` 的思路给出压力场景或验证方式，避免只增加不可执行的文字规则。
 - 架构治理、难测模块、深模块设计必须使用 `improve-codebase-architecture` / `codebase-design` 的 module、interface、seam、adapter 术语。
 - `to-issues` 产出的任务必须是端到端垂直切片，不允许只按 Adapter / Application / Domain / Infrastructure 横向拆分。
 - 每个生命周期阶段完成后必须执行 Git checkpoint 判断：列出阶段产物、Issue 同步状态、排除无关脏文件，并在用户已授权时按范围提交和推送。

package/template/docs/adr/adr-product-design-prototype-entrypoint.md

@@ -0,0 +1,54 @@
+# ADR-001: 使用 product-design:index 作为产品原型主入口
+
+## 状态
+
+已接受
+
+## 日期
+
+2026-07-06
+
+## 背景
+
+YSS Harness 需要把有 UI 功能的产品原型产出收敛到一个稳定入口，同时保留需求质询、设计系统、Ant Design v6 事实校验、原型评审和用户确认门禁。原有 `product-design-prototype`、`wireframe-prototype`、`high-fidelity-html-prototype` 容易被理解为并列主入口，导致 Agent 在不同阶段选择不同原型工具，难以保证高保真 HTML 原型、AntD v6 校验证据和用户确认记录一致落地。
+
+## 决策
+
+产品原型产出统一以 `product-design:index` 为主入口。该 skill 只负责路由，实际按 Product Design plugin 规则进入 `$get-context`、`$ideate`、`$prototype`、`$image-to-code`、`$url-to-code`、`$design-qa` 或 `$share` 等 focused skill。
+
+`grill-with-docs` 保留为前置需求质询和领域边界澄清工具，不承担 HTML 原型产出。`antd` skill / `antd` CLI 作为 Ant Design v6 组件、demo、token、semantic 和 design.md 的事实来源。YSS 生命周期继续负责 `prototype-review`、用户确认、PRD 回填和 OpenAPI Draft 门禁。
+
+## 考虑的替代方案
+
+| 方案 | 优点 | 缺点 | 结论 |
+|------|------|------|------|
+| 继续使用多个原型技能并列入口 | 对旧流程改动少 | Agent 路由不稳定，难以统一 AntD v6 高保真 HTML 原型和确认记录 | 放弃 |
+| 只保留 `high-fidelity-html-prototype` | 产物目标直接 | 缺少 Product Design plugin 的上下文、视觉探索、URL / 图片 / 代码来源路由能力 | 放弃 |
+| 以 `product-design:index` 为主入口，旧技能保留兼容 | 路由统一，可复用 focused skills，迁移风险低 | 需要在文档中明确 legacy 边界 | 采纳 |
+
+## 后果
+
+### 正面影响
+
+- 有 UI 的产品原型产出入口统一。
+- 高保真 HTML 原型、AntD CLI 校验证据和用户确认记录成为固定门禁。
+- Figma / Axure / Excalidraw / 截图 / URL 可作为输入来源，而不是主交付格式。
+
+### 负面影响
+
+- 需要维护完整 `.codex/skills/product-design/` 插件目录，不能只复制 `index/SKILL.md`。
+- 旧原型技能在过渡期仍会存在，需要通过流程文档限制使用语境。
+
+### 风险
+
+- 如果 Agent 未读取 Product Design focused skill，可能误把 `product-design:index` 当作直接产出技能。
+- 如果跳过 `antd` CLI 查询，原型可能偏离 Ant Design v6 组件 API 或 token。
+- 如果缺少用户确认记录，下游 PRD 校准和 OpenAPI Draft 会失去体验冻结依据。
+
+## 相关
+
+- `AGENTS.md`
+- `docs/process/product-prototype-workflow.md`
+- `docs/process/lifecycle-artifact-map.md`
+- `docs/design/README.md`
+- `docs/design/templates/prototype-confirmation-template.md`

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

@@ -16,7 +16,9 @@
 | 原型 / 线框图 |  |  |
 | 状态矩阵 | `docs/design/<feature>-state-matrix.md` |  |
 | 原型评审结论 | `docs/design/<feature>-prototype-review.md` |  |
-| 高保真 HTML 原型 | `docs/design/prototypes/<feature>/index.html` | 有 UI 时必需；必须使用 Ant Design v6 |
+| 高保真 HTML 原型 | `docs/design/prototypes/<feature>/index.html` | 有 UI 时必需；必须使用 Ant Design v6，并通过 `product-design:index` 路由产出或记录例外原因 |
+| AntD CLI 校验证据 | `docs/design/<feature>-prototype-confirmation.md` 或评审记录 | 有 UI 时必需；记录 design.md / info / demo / token / semantic 查询 |
+| 用户确认记录 | `docs/design/<feature>-prototype-confirmation.md` | 有 UI 时必需；未确认前不得进入 OpenAPI Draft 评审 |
 | YSS 工程基线 | `.codex/skills/yss-ddd-scaffold-generator/references/yss-backend-scaffold-parent/SKILL.md` |  |
 
 ## P0 追踪矩阵
@@ -33,7 +35,7 @@
 | OpenAPI 语法 | YAML、`$ref`、path 参数、lint 通过 |  |  |
 | P0 覆盖 | 每个 P0 需求有 endpoint/schema/error/test 或明确非目标 |  |  |
 | 产品总体设计完整 | Draft 已依据 PRD 和产品总体设计 / 功能架构；缺产品总体设计时返回上游补齐 |  |  |
-| 交互输入完整 | 有 UI 时，Draft 已同时依据交互说明、原型/线框、状态矩阵、prototype-review 和 Ant Design v6 高保真 HTML 原型；无 UI 时需说明页面 / 交互资产不适用原因 |  |  |
+| 交互输入完整 | 有 UI 时，Draft 已同时依据交互说明、原型/线框、状态矩阵、prototype-review、Ant Design v6 高保真 HTML 原型、AntD CLI 校验证据和用户确认记录；无 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,6 +7,8 @@
 - `docs/design/design.md`：从本地 `Product-Design-System` 引入并整理的 Ant Design 企业级设计系统说明，后续页面设计、交互说明、原型评审和前端实现默认引用该文件。
 - `docs/design/tokens/`：随仓库保存的主题、亮色 / 暗色 / 紧凑 token 和 CSS 变量快照，后续实现不得依赖本机 Downloads 目录。
 
+产品原型产出默认以 `product-design:index` 为主入口。该 skill 只负责路由，实际按 Product Design plugin 规则进入 `$get-context`、`$ideate`、`$prototype`、`$image-to-code`、`$url-to-code`、`$share` 或 `$design-qa` 等 focused skill；YSS 生命周期仍负责校验低保真评审、高保真 HTML 原型、AntD CLI 校验证据、用户确认和 PRD / OpenAPI 回填。
+
 进入 PRD 初稿 / 需求基线流程后，必须先沉淀产品总体设计 / 功能架构，再进入页面 / 原型 / 交互设计、PRD 校准、API 影响分析 / 契约草案或实现。产品总体设计文档必须包含低保真原型 / 页面草图，用于验证页面结构、关键操作和主流程。无 UI 的功能也需要产品总体设计 / 功能架构来说明功能域、业务对象、模块边界、API / 数据影响和不适用的页面状态；只有不进入 PRD 生命周期的小改动可在影响面评估中记录不适用原因。
 
 进入 API 影响分析 / 契约草案前，有用户界面的功能还必须沉淀：
@@ -18,7 +20,7 @@
 - 表单、表格、弹窗、抽屉、步骤流等交互说明。
 - loading、empty、error、readonly、disabled、no-permission、conflict 等状态矩阵。
 - 页面字段、筛选条件、操作按钮和权限规则。
-- 低保真原型评审通过后的 Ant Design v6 高保真可交互 HTML 原型，默认路径为 `docs/design/prototypes/<feature>/index.html`。
+- 低保真原型评审通过后的 Ant Design v6 高保真可交互 HTML 原型，默认路径为 `docs/design/prototypes/<feature>/index.html`；该产物可由系统 / Agent 自动生成，不要求用户手工提供，产出前必须使用 `antd` CLI 查询设计语言、组件 API、demo、token 和 semantic 信息，产出后必须记录 AntD v6 校验证据并获得用户确认。
 
 这些资产用于反推 API 影响、契约草案、OpenAPI 请求 / 响应字段、错误结构、分页筛选、权限状态和前端验收标准。
 
@@ -28,14 +30,16 @@
 - `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 影响分析 / 契约草案前的原型评审门禁。
+- `docs/design/templates/prototype-confirmation-template.md`：高保真 HTML 原型产出后的用户确认记录。
 
 推荐技能：
 
 - `yss-design-system`：项目设计系统与 Ant Design 企业级 UI 风格基线；页面设计、原型评审、UI 实现和主题 token 落地时默认先引用。
-- `product-design-prototype`：基于 PRD 初稿和产品总体设计 / 功能架构，产出页面 / 原型 / 交互设计资产。
-- `wireframe-prototype`：低保真线框、Excalidraw、Figma、Penpot、tldraw、Axure 等原型链接沉淀。
+- `product-design:index`：产品原型产出的主路由；根据输入是否有 URL、截图、Figma、代码目标或视觉方向，进入 `$get-context`、`$ideate`、`$prototype`、`$image-to-code`、`$url-to-code`、`$share` 或 `$design-qa` 等 focused skill。
+- Product Design focused skills：基于 PRD 初稿和产品总体设计 / 功能架构，产出低保真 / 高保真页面、原型、交互设计资产和可分享原型；高保真 HTML 原型默认由该路由链路产出。
+- `antd`：Ant Design v6 组件、demo、token、semantic 和 design.md 查询工具；生成或修改高保真 HTML 原型前后必须留下 CLI 校验证据。
 - `prototype-review`：原型阶段评审门禁；未通过则不要进入 PRD 校准 / API 影响分析 / 契约草案。
-- `high-fidelity-html-prototype`：低保真原型评审通过后，基于官方 `@ant-design/cli` / Ant Design For Agents 指引生成 Ant Design v6 高保真可交互 HTML 原型；未产出前不要进入 PRD 校准 / API 影响分析 / 契约草案。
+- 兼容入口：`product-design-prototype`、`wireframe-prototype`、`high-fidelity-html-prototype` 仅作为历史兼容或产物门禁名称保留；新的产品原型产出默认使用 `product-design:index`。
 - `excalidraw-diagram-generator`：根据已形成的 Discovery、PRD、OpenAPI Draft、Architecture 或 系统 / 数据架构设计 生成 `.excalidraw` 图；用于说明和审查，不替代文本规格。
 
 推荐目录：

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

@@ -10,8 +10,10 @@
 | 产品总体设计 / 功能架构 | `docs/design/<feature>-product-overview-design.md` | 必需；缺失时先返回产品总体设计阶段 |
 | 领域术语 | `CONTEXT.md` | 核心名词、状态和业务规则 |
 | Discovery | `docs/discovery/<feature>-discovery.md` | 可选 |
+| Product Design 路由 | `product-design:index -> <focused skill>` | 必需；记录 `$get-context`、`$ideate`、`$prototype`、`$image-to-code` 或 `$url-to-code` |
 | 原型 / 线框图 | `<链接或导出图片路径>` | Excalidraw / Figma / Penpot / tldraw / Axure / Markdown |
-| 高保真 HTML 原型 | `docs/design/prototypes/<feature>/index.html` | 低保真原型评审通过后补齐；必须使用 Ant Design v6 |
+| 高保真 HTML 原型 | `docs/design/prototypes/<feature>/index.html` | 低保真原型评审通过后补齐；必须使用 Ant Design v6；可由系统 / Agent 自动产出；产出后必须获得用户确认 |
+| AntD CLI 校验证据 | `<命令输出或记录路径>` | `antd design.md/info/demo/token/semantic --version 6.0.0 --format json` |
 | 现有 API 草案 | `docs/api/specs/<feature>.yaml` | 可选；通常应先完成产品设计和 PRD 校准 |
 
 ## 2. 页面地图
@@ -104,6 +106,7 @@
 - 每个表格列、筛选条件、表单字段、抽屉、弹窗和按钮都有数据来源或契约反推说明。
 - 设计可以拆成独立可演示的垂直切片。
 - 低保真原型评审通过后，高保真 HTML 原型使用 Ant Design v6 覆盖主流程、关键状态和响应式断点。
+- 原型产出前已使用 `antd` CLI 查询设计语言、组件 API、demo、token 和 semantic 信息；原型产出后已记录 AntD v6 校验证据。
 
 ## 9. 决策与未决问题
 

package/template/docs/design/templates/prototype-confirmation-template.md

@@ -0,0 +1,57 @@
+# <功能名称> 高保真原型确认记录
+
+> 适用时机：Ant Design v6 高保真 HTML 原型产出后、PRD 校准 / 需求冻结 / UI 驱动 OpenAPI Draft 前。未确认前不得进入下游门禁。
+
+## 1. 原型信息
+
+| 项目 | 内容 |
+|---|---|
+| 功能名称 |  |
+| PRD | `docs/requirements/<feature>-prd.md` |
+| 产品总体设计 / 功能架构 | `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` |
+| 高保真 HTML 原型 | `docs/design/prototypes/<feature>/index.html` |
+| Product Design 路由 | `product-design:index -> <focused skill>` |
+| 产出方式 | 系统 / Agent 自动产出 / 人工补充 |
+| Ant Design 版本 | v6 |
+
+## 2. AntD CLI 校验证据
+
+| 校验项 | 命令 / 记录路径 | 结论 |
+|---|---|---|
+| 设计语言 | `antd design.md --version 6.0.0 --format json` |  |
+| 组件 API | `antd info <Component> --version 6.0.0 --format json` |  |
+| 组件 demo | `antd demo <Component> <demo> --version 6.0.0 --format json` |  |
+| 组件 token | `antd token <Component> --version 6.0.0 --format json` |  |
+| semantic | `antd semantic <Component> --version 6.0.0 --format json` |  |
+| lint / 替代校验 | `antd lint <prototype path> --format json` |  |
+
+## 3. 用户确认
+
+| 项目 | 内容 |
+|---|---|
+| 确认人 |  |
+| 确认时间 |  |
+| 确认方式 | 口头 / 评论 / Issue / 会议纪要 / 其他 |
+| 确认结论 | 通过 / 需调整 / 暂缓 |
+| 是否允许进入 PRD 校准 | 是 / 否 |
+| 是否允许进入 API 影响分析 / OpenAPI Draft | 是 / 否 |
+
+## 4. 调整项
+
+| 序号 | 调整内容 | 优先级 | 负责人 | 状态 |
+|---|---|---|---|---|
+| 1 |  | P0 / P1 / P2 |  |  |
+
+## 5. 结论
+
+```text
+确认结论：
+允许进入下一阶段：是 / 否
+阻断原因：
+- 
+补充说明：
+- 
+```

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

@@ -1,6 +1,6 @@
 # <功能名称> 原型评审清单
 
-> 适用时机：配合 `prototype-review` 使用。评审采用 fail-closed：有阻断项时必须回到产品设计阶段；低保真评审通过后必须进入 `high-fidelity-html-prototype`，不能直接进入 PRD 校准或 API 影响分析 / 契约草案。
+> 适用时机：配合 `prototype-review` 使用。评审采用 fail-closed：有阻断项时必须回到产品设计阶段；产品原型产出以 `product-design:index` 路由到 Product Design focused skill 为主；低保真评审通过后必须产出高保真 HTML 原型，可由系统 / Agent 自动产出；产出后必须获得用户确认，确认前不能直接进入 PRD 校准或 API 影响分析 / 契约草案。
 
 ## 评审输入
 
@@ -10,6 +10,8 @@
 | 交互说明 | `docs/design/<feature>-interaction-spec.md` |  |
 | 原型 / 线框图 | `<链接或导出图片路径>` |  |
 | 状态矩阵 | `docs/design/<feature>-state-matrix.md` |  |
+| Product Design 路由记录 | `product-design:index -> <focused skill>` |  |
+| AntD CLI 校验证据 | `<命令输出或记录路径>` |  |
 | 现有 API 草案 | `docs/api/specs/<feature>.yaml` | 可选 |
 
 ## 门禁清单
@@ -24,6 +26,8 @@
 | 权限行为能区分隐藏、禁用和调用后拒绝 |  |  |
 | 校验错误能区分模型级和字段级展示位置 |  |  |
 | 能从界面需求反推出 API 影响和契约草案 |  |  |
+| AntD v6 设计语言、组件 API、demo、token 和 semantic 已用 `antd` CLI 查询并记录 |  |  |
+| 高保真 HTML 原型未使用旧原型技能作为主入口，已通过 `product-design:index` 路由产出或记录例外原因 |  |  |
 | 前端验收、组件状态和数据依赖已明确 |  |  |
 | 安全红线已标记人工审查 |  |  |
 
@@ -59,5 +63,5 @@
 非阻断建议：
 - 
 下一步：
-- high-fidelity-html-prototype / 回到 product-design-prototype
+- product-design:index 路由高保真 HTML 原型产出 / 回到 Product Design focused skill 补齐原型 / 进入用户确认
 ```

package/template/docs/design/templates/state-matrix-template.md

@@ -1,6 +1,6 @@
 # <功能名称> 状态矩阵模板
 
-> 适用时机：配合 `product-design-prototype` 使用，在 PRD 校准和 API 影响分析 / 契约草案之前补齐页面状态。
+> 适用时机：配合 `product-design:index` 路由后的 Product Design focused skill 使用，在 PRD 校准和 API 影响分析 / 契约草案之前补齐页面状态。
 
 | 页面 / 组件 | 状态 | 触发条件 | 界面行为 | API / 数据要求 | 验收点 |
 |---|---|---|---|---|---|

package/template/docs/process/MATT-POCOCK-ENGINEERING-SKILLS.md

@@ -11,11 +11,11 @@ Matt Pocock Engineering Skills 是一组小而可组合的工程工作流。本
 
 | 本模板层级 | 默认能力 | 说明 |
 |---|---|---|
-| 需求与任务 | `competitive-intelligence`、`grill-with-docs`、`to-prd`、`to-issues` | 收集竞品 / 市场事实、澄清需求、沉淀 PRD、拆端到端垂直切片 |
+| 需求与任务 | `competitive-intelligence`、`research`、`grill-with-docs`、`prototype`、`to-prd`、`to-issues` | 收集竞品 / 市场 / 技术事实、澄清需求、用一次性原型回答设计问题、沉淀 PRD、拆端到端垂直切片 |
 | 契约层 | OpenAPI 3.1 Draft / Freeze、OpenSpec-style Spec Delta | 前后端契约、行为差异、验收场景和契约测试输入 |
 | 方法论层 | `implement`、`tdd`、`diagnosing-bugs`、`code-review` | 实现、红绿重构、Bug 诊断和独立审查 |
 | 架构与领域 | `domain-modeling`、`codebase-design`、`improve-codebase-architecture` | 领域语言、深模块设计、架构治理 |
-| 协作层 | `triage`、Issue tracker、Git checkpoint | 分诊、同步状态、记录验证证据 |
+| 协作层 | `triage`、`handoff` / 等价交接记录、Issue tracker、Git checkpoint | 分诊、跨线程 / 跨仓库交接、同步状态、记录验证证据 |
 
 ## 2. 标准执行流程
 
@@ -24,7 +24,7 @@ Matt Pocock Engineering Skills 是一组小而可组合的工程工作流。本
 | 项 | 内容 |
 |---|---|
 | 触发语 | “做一个功能”、“把这个想法落成需求”、“生成 PRD/Issue”、“可以开始实现” |
-| 使用 skills | `competitive-intelligence`（需要竞品 / 市场事实时）、`grill-with-docs`、`domain-modeling`、`to-prd`、`to-issues`、`implement`、`tdd`、`code-review` |
+| 使用 skills | `competitive-intelligence`（需要竞品 / 市场事实时）、`research`（需要技术 / 标准 / API 一手资料时）、`grill-with-docs`、`prototype`（需要一次性验证时）、`domain-modeling`、`to-prd`、`to-issues`、`implement`、`tdd`、`code-review` |
 | 输入 | 业务想法、发现报告、用户故事草案、干系人讨论记录 |
 | 输出 | PRD、OpenAPI 3.1 Spec、垂直切片 Issue、实现与测试 |
 | 落点 | `docs/requirements/`、`docs/api/specs/`、GitLab / GitHub Issues、`CONTEXT.md`、`docs/adr/` |
@@ -34,7 +34,9 @@ Matt Pocock Engineering Skills 是一组小而可组合的工程工作流。本
 
 ```text
 competitive-intelligence (when market / competitor facts are needed)
+  -> research (when technical / standards / API primary sources are needed)
   -> grill-with-docs
+  -> prototype (when a design question needs runnable feedback)
   -> domain-modeling
   -> to-prd
   -> OpenAPI 3.1 Draft
@@ -43,6 +45,7 @@ competitive-intelligence (when market / competitor facts are needed)
   -> Architecture / Data Design Review
   -> OpenAPI 3.1 Freeze
   -> to-issues
+  -> handoff / implementation routing (when crossing contexts or repos)
   -> implement with tdd
   -> code-review / fresh verification
 ```
@@ -50,12 +53,15 @@ competitive-intelligence (when market / competitor facts are needed)
 门禁：
 
 - PRD 进入开发前必须明确用户故事、验收条件、OpenAPI 影响和测试决策。
+- 技术 / 标准 / 第三方 API 事实影响 PRD、OpenAPI、架构或验收时，必须有 `research` 或等价一手资料记录，并在下游资产中引用。
+- 一次性 `prototype` 只回答设计问题；结论必须回填到 PRD、设计、ADR 或 Issue，原型代码不得作为生产实现或 YSS 高保真 HTML 原型交付。
 - 任何 API 变更必须先在 `docs/api/specs/*.yaml` 形成 Draft，经工程基线、系统 / 数据架构和设计审查后 Freeze，再进入实现。
 - API、权限、状态机、数据模型、跨端、新模块或高风险行为变化，应在 Design Review / OpenAPI Freeze 前补 OpenSpec-style Spec Delta；它只描述行为差异、验收场景和测试映射，不恢复 OpenSpec 工具链。
 - OpenAPI Freeze 后进入 `to-issues` 或等价垂直切片拆分；Issue 必须可以独立 demo 或验证。
 - 后端新服务或新模块必须先确认 YSS DDD 工程基线；从零创建服务时优先使用 `yss-ddd-scaffold-generator`。
 - `to-issues` 只能产出可独立验证的垂直切片，不允许只按 Adapter / Application / Domain / Infrastructure 横向拆分。
 - 涉及安全红线时，Issue 必须标注 `ready-for-human` 或 `TODO-HUMAN-REVIEW`。
+- 跨线程、跨仓库、上下文接近上限或原型分支回流时，必须留下 `handoff` 或等价交接记录。
 
 ### 2.2 Bug 修复流程
 
@@ -126,7 +132,9 @@ competitive-intelligence (when market / competitor facts are needed)
 |---|---|---|---|
 | `ask-matt` | 不确定该走哪个流程 | 路由到合适 skill | 作为入口说明 |
 | `competitive-intelligence` | 需要竞品、替代方案、定价、定位、用户口碑或市场事实 | 基于公开来源形成竞品情报、证据表、竞品矩阵和 PRD 输入 | `docs/discovery/reports/` |
+| `research` | 需要技术事实、标准、第三方 API、框架行为或官方文档依据 | 基于一手来源形成可引用调研记录 | `docs/discovery/reports/` 或 `docs/research/` |
 | `grill-with-docs` | 想法还不清晰，需要追问 | 结合领域建模持续追问，沉淀 glossary / ADR | `CONTEXT.md`、`docs/adr/` |
+| `prototype` | 状态机、复杂规则或 UI 方向需要可运行反馈 | 生成一次性逻辑 / UI 原型并沉淀结论 | PRD、设计、ADR 或 Issue 的结论章节 |
 | `to-prd` | 已有对话，需要整理成 PRD | 不再访谈，直接合成 PRD 并发布到 issue tracker | `docs/requirements/` 或 Issue |
 | `to-issues` | PRD / 计划需要拆任务 | 拆成可独立领取的垂直切片 Issue | Issue tracker |
 | `implement` | 按 PRD 或 Issue 实现 | 业务行为默认按 TDD 推进；生成代码、配置或一次性原型说明例外和验证方式；最后 independent review + fresh verification + commit | 当前代码分支 |
@@ -168,6 +176,9 @@ competitive-intelligence (when market / competitor facts are needed)
 | Sprint / Standup / Retro | `docs/process/` |
 | Issue tracker 配置 | `docs/agents/` |
 | 领域词汇表 | 根目录 `CONTEXT.md` |
+| 技术 / 标准 / API 调研 | `docs/discovery/reports/` 或 `docs/research/` |
+| 一次性原型结论 | PRD、设计、ADR 或垂直切片 Issue |
+| 跨线程 / 跨仓库交接 | Issue / MR / PR 评论或 `docs/implementation/` |
 
 ## 5. 门禁与验收规则
 
@@ -195,3 +206,11 @@ competitive-intelligence (when market / competitor facts are needed)
 - [ ] TDD 适用性已明确；若例外，说明验证方式。
 - [ ] 安全红线和人审点已标注。
 - [ ] 实现仓库、分支、测试命令和回滚点清楚。
+- [ ] 跨线程 / 跨仓库 / 原型回流场景已有 `handoff` 或等价交接记录。
+- [ ] 如发生 merge / rebase 冲突，已有冲突处理取舍和重新验证证据。
+
+### 5.4 Process / Skill Ready
+
+- [ ] 修改 AGENTS、流程模板或 skill 时，已按 `writing-skills` 思路列出至少一个压力场景或验证方式。
+- [ ] 新规则触发条件清楚，避免把条件技能变成所有任务的硬门禁。
+- [ ] 下游资产位置、引用方式和不适用条件明确。

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

@@ -46,7 +46,8 @@ AI 不能只作为一次性辅助工具使用。Harness 工程的目标，是把
 PRD
 → 产品总体设计 / 功能架构
 → 页面 / 原型 / 交互设计与 prototype-review（有 UI 时）
-→ Ant Design v6 高保真 HTML 原型（有 UI 时）
+→ product-design:index 路由 Product Design focused skill 产出 Ant Design v6 高保真 HTML 原型（有 UI 时）
+→ antd CLI 校验证据与用户确认记录（有 UI 时）
 → API 影响分析 / 契约草案
 → review-only OpenAPI Draft（如需要）
 → Issue Change

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

@@ -17,14 +17,18 @@
 | 当前输入 / 变更事实 | 最近可信阶段 | 需要补齐的下游 |
 |---|---|---|
 | 只有模糊想法、业务机会或竞品输入 | 2. 机会与 Discovery | Discovery、`grill-with-docs`、PRD、产品总体设计 / 功能架构 |
+| 需要技术事实、标准、第三方 API 或框架行为支撑决策 | 2. 机会与 Discovery 或 5. 系统 / 数据架构与工程契约设计审查 | `research` 或等价一手资料记录，并回填到 PRD、OpenAPI、架构或 ADR |
 | 已有清晰 PRD，但用户、痛点、MVP 或非目标不稳 | 3. 业务 / PRD / 功能架构 | PRD Review、产品总体设计 / 功能架构、必要的页面 / 原型 / 交互设计 |
-| 有 UI 变更但缺页面流、状态矩阵、原型评审或高保真 HTML 原型 | 4. 产品设计与需求冻结 | 交互说明、状态矩阵、Prototype Review、Ant Design v6 高保真 HTML 原型、PRD 回填 |
+| 状态机、复杂规则或 UI 方向无法仅靠文字判断 | 3. 业务 / PRD / 功能架构 或 4. 产品设计与需求冻结 | `prototype` 一次性验证结论，并回填到 PRD / 设计 / ADR / Issue |
+| 有 UI 变更但缺页面流、状态矩阵、原型评审、高保真 HTML 原型、AntD CLI 校验证据或用户确认记录 | 4. 产品设计与需求冻结 | 交互说明、状态矩阵、Prototype Review、Ant Design v6 高保真 HTML 原型（可在低保真评审通过后由系统 / Agent 自动产出）、AntD CLI 校验证据、用户确认记录、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 前置审查 |
 | OpenAPI 已冻结但还没有垂直切片 Issue | 6. 契约冻结与 Issue formalization | `to-issues`、实施计划、Build Architecture Checklist |
 | 已有垂直切片 Issue，但实现准备不完整 | 7. 垂直切片与 TDD 实现 | 实施计划、YSS skill routing、测试命令、回滚点 |
+| 跨线程、跨仓库、上下文过长或原型分支需要回流 | 7. 垂直切片与 TDD 实现 | `handoff` 或等价交接记录、实现仓库绑定、验证命令 |
 | 只有代码修复或测试失败 | 7. 垂直切片与 TDD 实现 | 可复现命令、失败测试、最小修复、fresh verification |
+| merge / rebase 冲突阻塞交付 | 7. 垂直切片与 TDD 实现 | `resolving-merge-conflicts` 或等价冲突处理记录、重新验证 |
 | 准备发布或宣称完成 | 8. 验证发布与复盘 | fresh verification、发布说明、回滚方案、复盘入口 |
 
 ## 升级条件
@@ -37,6 +41,8 @@
 - 服务边界、外部系统集成、部署、回滚、可观测性、性能、可靠性或运维约束变化。
 - UI 变更影响用户主流程、权限状态、异常状态、页面导航或 OpenAPI 反推清单。
 - 实现与既有架构、CONTEXT 术语、ADR、PRD 或垂直切片 Issue 出现漂移。
+- 技术事实、标准或第三方 API 判断会影响 PRD、OpenAPI、架构、验收或发布风险，且当前没有一手资料记录。
+- 当前工作需要跨线程、跨仓库、原型分支回流或上下文交接，但没有 handoff / 等价交接记录。
 - 无法给出 fresh verification 证据。
 
 ## 裁剪原则
@@ -45,5 +51,6 @@
 - 中等变更只补受影响阶段及其下游，不回到机会探索。
 - 小改动必须保留影响面评估、验证证据和 Git checkpoint 判断。
 - 小改动默认不创建 Spec Delta；只有扩散到 API、权限、状态机、数据模型、跨端或安全红线时才升级补齐。
+- 小改动默认不需要 `research`、`prototype` 或 `handoff`；只有事实依据、设计验证或交接风险会影响后续门禁时才触发。
 - 安全红线只能进入人工审查或草案状态，不能因任务小而跳过。
 - OpenAPI Freeze 后直接进入 `to-issues` 或等价垂直切片拆分；不要求额外变更状态文件。

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、产品总体设计 / 功能架构、低保真原型、页面清单、状态矩阵、原型评审、Ant Design v6 高保真 HTML 原型、需求冻结 | `yss-design-system`、`product-design-prototype`、`prototype-review`、`high-fidelity-html-prototype` | 无 UI 可省略后续交互原型；进入 PRD 初稿 / 需求基线流程时不得省略产品总体设计及其低保真原型；有 UI 时低保真评审通过后不得省略高保真 HTML 原型；中等变更只补受影响页面 | 半自动检查 PRD 字段、产品总体设计、低保真原型、状态矩阵、原型评审和高保真 HTML 原型 |
+| 2. PRD -> 产品总体设计 -> 原型校准 | 3. 业务 / PRD / 功能架构；4. 产品设计与需求冻结 | 4. 需求基线 / 功能架构；5. 页面 / 原型 / 交互设计；6. 原型评审；7. PRD 校准 / 需求冻结 | PRD、产品总体设计 / 功能架构、低保真原型、页面清单、状态矩阵、原型评审、Ant Design v6 高保真 HTML 原型、AntD CLI 校验证据、用户确认记录、需求冻结 | `yss-design-system`、`product-design:index`、Product Design focused skills（`$get-context` / `$ideate` / `$prototype` / `$image-to-code` / `$url-to-code`）、`antd`、`prototype-review` | 无 UI 可省略后续交互原型；进入 PRD 初稿 / 需求基线流程时不得省略产品总体设计及其低保真原型；有 UI 时产品原型产出以 `product-design:index` 路由为主，低保真评审通过后不得省略高保真 HTML 原型，可由系统 / Agent 自动产出，产出前后必须使用 `antd` CLI 校验并在产出后获得用户确认；中等变更只补受影响页面 | 半自动检查 PRD 字段、产品总体设计、低保真原型、状态矩阵、原型评审、高保真 HTML 原型、AntD CLI 校验证据和用户确认记录 |
 | 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 |