create-yss-spec 1.1.3 → 2.0.0

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

@@ -14,7 +14,7 @@
 模型、字段、草稿版本、发布版本、校验错误、引用关系
 ```
 
-如果一个术语还在讨论中，可以先放在 PRD 或 discovery 文档，不要急着写进 `CONTEXT.md`。
+如果一个术语还在讨论中，可以先放在 Spec 或 discovery 文档，不要急着写进 `CONTEXT.md`。
 
 ### 1.2 契约草案先评审，API Freeze 先于前后端实现
 
@@ -35,15 +35,15 @@ Draft 阶段允许调整接口，但不能被当成稳定实现契约；Freeze
 
 | 层级 | 放什么 | 不放什么 |
 |---|---|---|
-| `AGENTS.md` | Agent 启动即必须遵守的工程红线、技能入口和阶段门禁 | 完整代码手册、临时实现细节 |
+| `AGENTS.md` | Agent 启动即必须遵守的工程约束、技能入口和阶段门禁 | 完整代码手册、临时实现细节 |
 | YSS skills | DDD 脚手架、分层职责、命名、Repository、MapStruct、统一响应等细则 | 单个功能的临时取舍 |
 | `docs/architecture/` / ADR | 本次变更的模块边界、状态流、风险取舍和回滚策略 | 全局编码规则的重复副本 |
 
 从零创建后端服务时，工程基线由 `yss-ddd-scaffold-generator` 产出；设计和审查阶段用 `yss-backend-scaffold-parent` 校验。功能开发阶段只补充本次变更需要的局部约束，不重新发明分层架构。
 
-### 1.4 一个垂直切片 Issue 只解决一个目标
+### 1.4 一个垂直切片 Ticket 只解决一个目标
 
-垂直切片 Issue 应该围绕一个清晰目标。
+垂直切片 Ticket 应该围绕一个清晰目标。
 
 好的 change：
 
@@ -57,7 +57,7 @@ Draft 阶段允许调整接口，但不能被当成稳定实现契约；Freeze
 实现数据中台模型管理、指标管理、血缘分析和权限审批
 ```
 
-如果一个 Issue 需要多天都说不清完成标准，通常应该拆分。
+如果一个 Ticket 需要多天都说不清完成标准，通常应该拆分。
 
 ### 1.5 用垂直切片交付，不按技术层横切
 
@@ -84,17 +84,17 @@ AI 可以生成方案、代码、测试和报告，但这些决策必须由人
 - 产品优先级。
 - 架构方向。
 - 发布范围。
-- 安全红线。
+- 风险 / 回滚约束。
 - 数据库迁移。
 - 认证授权。
 - 公共基础库 API。
 - 加密算法相关内容。
 
-触碰安全红线时，文档或代码中必须标记 `TODO-HUMAN-REVIEW`。
+存在需要人工确认的风险时，文档或代码中必须记录范围、责任人和结论。
 
-### 1.7 机会探索先于 PRD
+### 1.7 机会探索先于 Spec
 
-进入 PRD 前先完成机会探索环。它不是固定的“头脑风暴 → 发现”单向步骤，而是把事实、假设和 MVP 边界来回校准：
+进入 Spec 前先完成机会探索环。它不是固定的“头脑风暴 → 发现”单向步骤，而是把事实、假设和 MVP 边界来回校准：
 
 ```text
 市场 / 竞品 / 用户事实 <-> 机会构想假设 <-> MVP 边界
@@ -124,13 +124,13 @@ AI 可以生成方案、代码、测试和报告，但这些决策必须由人
 ```text
 opportunity exploration
 -> grill-with-docs
--> PRD
+-> Spec
 -> API impact / contract draft
 -> Engineering Baseline / DDD Review
 -> Architecture / 系统 / 数据架构设计
 -> Design Review
 -> OpenAPI Freeze
--> to-issues
+-> to-tickets
 -> implement / tdd
 -> code-review
 -> fresh verification
@@ -140,8 +140,8 @@ opportunity exploration
 要求：
 
 - 有机会探索结论，或明确说明无需市场 / 竞品 / 用户输入。
-- PRD 前已用 `grill-with-docs` 澄清关键边界，或已有等价的确认记录。
-- 有 PRD。
+- Spec 前已用 `grill-with-docs` 澄清关键边界，或已有等价的确认记录。
+- 有 Spec。
 - 有 API 影响分析 / 契约草案 / OpenAPI Freeze 判断；涉及接口时已有影响记录和契约草案 / review-only Draft，并在开发前 Freeze。
 - 有 YSS DDD 工程基线判断；后端新服务或新模块已选择对应 YSS skills。
 - 有设计审查结论；阻断项已经回到对应阶段修正。
@@ -156,13 +156,13 @@ opportunity exploration
 | 影响类型 | 从哪里继续 | 需要补什么 |
 |---|---|---|
 | 文案、样式、局部配置 | tweak / 最小改动 | 验证记录 |
-| 页面状态、交互、字段展示 | 产品设计 / 原型评审 | 交互说明、状态矩阵、PRD 回填项 |
-| 验收标准、业务规则、非目标边界 | PRD 校准 | PRD 更新、产品总体设计影响 |
+| 页面状态、交互、字段展示 | 产品设计 / 原型评审 | 交互说明、状态矩阵、Spec 回填项 |
+| 验收标准、业务规则、非目标边界 | Spec 校准 | Spec 更新、产品总体设计影响 |
 | 请求 / 响应 / 错误 / 权限 / 分页 | API 影响分析 / 契约草案 / OpenAPI Draft Review | 契约更新、Freeze 记录、契约测试 |
 | 状态机、服务边界、集成、NFR、回滚 | 系统概要设计 / Design Review | 架构影响、ADR 候选、验证方案 |
 | 持久化、元模型、版本、血缘、查询、索引 | 数据架构 / Design Review | 数据模型、迁移约束、人工审查点 |
 
-只有当小迭代推翻了用户、痛点、MVP、非目标或产品边界，才回到 Discovery / 业务架构 / PRD 初稿阶段。
+只有当小迭代推翻了用户、痛点、MVP、非目标或产品边界，才回到 Discovery / 业务架构 / Spec 初稿阶段。
 
 ### 2.2 小调整
 
@@ -188,7 +188,7 @@ opportunity exploration
 - 先写失败测试或明确验证方式。
 - 修复后补充回归验证。
 
-如果 bug 修复引出新业务规则，升级到 PRD 校准、产品总体设计、OpenAPI 或系统概要设计等最早受影响阶段。
+如果 bug 修复引出新业务规则，升级到 Spec 校准、产品总体设计、OpenAPI 或系统概要设计等最早受影响阶段。
 
 ### 2.4 探索和 spike
 
@@ -207,7 +207,7 @@ opportunity exploration
 | 类型 | 命名 |
 |---|---|
 | 竞品矩阵 | `docs/discovery/reports/<feature>-competitive-matrix.md` |
-| PRD | `docs/requirements/<feature>-prd.md` |
+| Spec | `docs/requirements/<feature>-spec.md` |
 | OpenAPI | `docs/api/specs/<feature>.yaml` |
 | 技术方案 | `docs/architecture/<feature>-architecture.md` |
 | ADR | `docs/adr/0001-<decision>.md` |
@@ -222,7 +222,7 @@ opportunity exploration
 |---|---|---|
 | `CONTEXT.md` | 稳定术语 | 临时计划、代码路径 |
 | Competitive Matrix | 竞品功能、差异化机会、MVP 边界输入 | 未验证事实、营销文案堆砌 |
-| PRD | 用户问题、范围、验收 | 详细实现代码 |
+| Spec | 用户问题、范围、验收 | 详细实现代码 |
 | OpenAPI | 接口契约 | 页面交互细节 |
 | Architecture | 模块边界、数据流、风险 | 业务长篇背景 |
 | ADR | 难回滚、有取舍的决策 | 常规实现选择 |
@@ -236,12 +236,12 @@ opportunity exploration
 Competitive Matrix
 -> Discovery
 -> CONTEXT
--> PRD
+-> Spec
 -> API impact / contract draft
 -> Architecture / ADR / 系统 / 数据架构设计
 -> OpenAPI Freeze
--> 垂直切片 Issue
--> Issues
+-> 垂直切片 Ticket
+-> Tickets
 -> Release Note
 -> User Guide
 ```
@@ -401,19 +401,19 @@ OpenAPI Freeze
 -> E2E 关键路径
 ```
 
-如果前端先做原型，也要在进入开发前回填 OpenAPI 和 PRD。
+如果前端先做原型，也要在进入开发前回填 OpenAPI 和 Spec。
 
 ## 6. 质量门禁
 
 ### 6.1 进入开发前
 
 - [ ] 已有机会探索结论，或明确说明无需市场 / 竞品 / 用户输入。
-- [ ] PRD 已说明问题、范围和验收标准。
+- [ ] Spec 已说明问题、范围和验收标准。
 - [ ] OpenAPI 影响为“无”或已有 Draft，并在开发前 Freeze。
 - [ ] 后端新服务或新模块已完成 YSS DDD 工程基线确认。
-- [ ] PRD / API / 工程基线 / Architecture / Plan 的阻断审查项已关闭。
+- [ ] Spec / API / 工程基线 / Architecture / Plan 的阻断审查项已关闭。
 - [ ] 主要测试 seam 已明确。
-- [ ] 安全红线已检查。
+- [ ] 风险 / 回滚约束已检查。
 - [ ] 垂直切片已经足够小。
 - [ ] YSS 技能集已通过 `yss-router` 或明确专项技能选择确定。
 
@@ -425,10 +425,10 @@ OpenAPI Freeze
 - [ ] 前端页面符合 `yss-ui` 的组件、Hook、分页和高度治理规范。
 - [ ] 后端代码符合 YSS DDD 分层、Gateway、Repository、Controller 边界。
 - [ ] 实现者没有审查自己的代码；独立 Review 的阻断项已关闭。
-- [ ] 如果触碰权限、认证、SQL、迁移、加密或公共 API，已完成人工确认或标记 `TODO-HUMAN-REVIEW`。
+- [ ] 如果涉及权限、认证、SQL、迁移、加密或公共 API 时，已记录风险判断和验证证据。
 - [ ] 没有调试代码。
 - [ ] 任务清单已更新。
-- [ ] 如果术语或规则变化，已更新 `CONTEXT.md` 或 PRD。
+- [ ] 如果术语或规则变化，已更新 `CONTEXT.md` 或 Spec。
 
 ### 6.3 发布前
 
@@ -442,22 +442,22 @@ OpenAPI Freeze
 ### 6.4 归档前
 
 - [ ] 垂直切片任务全部完成或明确取消。
-- [ ] 必要的 Spec Delta 已与 PRD / OpenAPI / Issue 互链。
+- [ ] 必要的 Spec Delta 已与 Spec / OpenAPI / Ticket 互链。
 - [ ] 验证结果已记录。
 - [ ] 经验已沉淀到 `AGENTS.md`、`CONTEXT.md` 或 ADR。
 
-使用 Issue 追踪时，发布前应确认所有垂直切片任务已完成或明确取消，并记录验证与回滚结论。
+使用 Ticket 追踪时，发布前应确认所有垂直切片任务已完成或明确取消，并记录验证与回滚结论。
 
 ## 7. 常见反模式
 
 | 反模式 | 后果 | 修正方式 |
 |---|---|---|
 | 跳过竞品分析直接定 MVP | 容易重复造已有弱功能，差异化不足 | 先产出竞品矩阵和机会清单 |
-| 只在聊天里讲需求 | 后续无法追溯，AI 容易遗忘 | 写入 PRD、Spec Delta 或 Issue |
+| 只在聊天里讲需求 | 后续无法追溯，AI 容易遗忘 | 写入 Spec、Spec Delta 或 Ticket |
 | 先写页面再补接口 | 字段和错误结构反复返工 | 先写 OpenAPI |
 | 按层拆任务 | 做了很多代码但无法演示 | 按垂直切片拆 |
 | 不经 yss-router 随手选技能 | 规范加载过多或漏掉关键约束 | 先选最小技能集 |
-| 把完整编码手册塞进 AGENTS.md | 入口指令变长且容易和 YSS skills 冲突 | AGENTS.md 放红线，细则放 skills / docs |
+| 把完整编码手册塞进 AGENTS.md | 入口指令变长且容易和 YSS skills 冲突 | AGENTS.md 放入口约束，细则放 skills / docs |
 | 新后端服务绕过脚手架手搓结构 | 模块依赖和命名不一致 | 先用 `yss-ddd-scaffold-generator`，再业务化定制 |
 | YSS 页面把请求写满 index.vue | 页面难维护，分页参数重复 | 请求和分页下沉 Hook |
 | 后端 Controller 直接穿透 Repository | 分层破坏，领域规则失控 | Controller 依赖 Domain Gateway / Service |
@@ -465,8 +465,8 @@ OpenAPI Freeze
 | 跳过测试直接实现 | 回归风险高 | 至少覆盖关键业务 seam |
 | AI 自己审查自己实现的代码 | 容易漏掉同类错误 | 使用独立 review 流程 |
 | ADR 写太多 | 决策记录变噪音 | 只记录难回滚且有真实取舍的决策 |
-| 阶段产物不 checkpoint | PRD / Spec Delta / OpenAPI / Issue 决策难追溯 | 阶段结束做 Issue 同步和 Git checkpoint |
-| 实施反馈不回流 | 同类问题反复出现 | 写入 user guide、PRD 或 AGENTS.md |
+| 阶段产物不 checkpoint | Spec / Spec Delta / OpenAPI / Ticket 决策难追溯 | 阶段结束做 Ticket 同步和 Git checkpoint |
+| 实施反馈不回流 | 同类问题反复出现 | 写入 user guide、Spec 或 AGENTS.md |
 
 ## 8. Prompt 模板
 
@@ -486,17 +486,17 @@ OpenAPI Freeze
 输出为 discovery 文档。
 ```
 
-### 8.3 PRD 生成
+### 8.3 Spec 生成
 
 ```text
-基于 discovery 文档，使用 docs/templates/prd-template.md 生成 PRD。
+基于 discovery 文档，使用 docs/templates/spec-template.md 生成 Spec。
 要求补充 Gherkin 验收标准、OpenAPI 影响、测试决策和人工审查点。
 ```
 
 ### 8.4 API 契约草案
 
 ```text
-基于 PRD 生成 OpenAPI 3.1 Draft。
+基于 Spec 生成 OpenAPI 3.1 Draft。
 要求包含分页、排序、错误响应、字段级校验错误和发布接口。
 保存到 docs/api/specs/<feature>.yaml。
 ```
@@ -504,7 +504,7 @@ OpenAPI Freeze
 ### 8.5 API 契约冻结
 
 ```text
-基于 OpenAPI Draft、工程基线、架构设计和 Issue 行为规格，
+基于 OpenAPI Draft、工程基线、架构设计和 Ticket 行为规格，
 检查路径、schema、错误结构、分页、权限、状态流、DDD 边界和契约测试是否一致。
 确认后将 docs/api/specs/<feature>.yaml 作为开发冻结契约。
 ```
@@ -519,7 +519,7 @@ OpenAPI Freeze
 ### 8.7 垂直切片
 
 ```text
-基于 PRD、冻结 OpenAPI 和架构设计，把功能拆成 3-6 个可独立验收的垂直切片。
+基于 Spec、冻结 OpenAPI 和架构设计，把功能拆成 3-6 个可独立验收的垂直切片。
 每个切片都要包含 API、后端、前端、测试和完成定义。
 ```
 
@@ -544,7 +544,7 @@ OpenAPI Freeze
 ### 8.9 通用开发
 
 ```text
-按当前 垂直切片 Issue 的 tasks 推进下一个未完成任务。
+按当前 垂直切片 Ticket 的 tasks 推进下一个未完成任务。
 默认使用 TDD，先写公共接口层面的失败测试，再实现。
 ```
 

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

@@ -4,7 +4,7 @@
 
 本模板现在默认使用 Matt Pocock Engineering Skills + YSS + OpenAPI：
 
-- Matt skills 负责澄清、PRD、Issue 拆分、实现、TDD、诊断、审查和架构治理。
+- Matt skills 负责澄清、Spec、Ticket 拆分、实现、TDD、诊断、审查和架构治理。
 - YSS skills 负责 DDD、UI、OpenAPI、Repository、Controller、DTO、组件和编码规范。
 - OpenAPI 3.1 负责前后端契约，Draft 仅用于评审，Freeze 后才作为实现输入。
 - OpenSpec-style Spec Delta 只在中高风险行为变化时记录行为差异、验收场景和测试映射，不恢复 OpenSpec 工具链。
@@ -18,11 +18,11 @@
 | 资产 | 位置 | 用途 |
 |---|---|---|
 | 领域语言 | `CONTEXT.md` | 统一产品、开发、设计、实施和 AI 的业务词汇 |
-| 需求与验收 | `docs/requirements/` | 保存 PRD、用户故事、验收条件和边界规则 |
+| 需求与验收 | `docs/requirements/` | 保存 Spec、用户故事、验收条件和边界规则 |
 | API 契约 | `docs/api/specs/` | 用 OpenAPI 3.1 约束前后端协作 |
 | 行为差异 | `docs/specs/` | 用轻量 Spec Delta 记录中高风险变化的 ADDED / MODIFIED / REMOVED 行为和测试映射 |
 | 架构资产 | `docs/architecture/`、`docs/adr/` | 保存业务架构、功能架构、系统总体架构、数据架构和关键 ADR |
-| 交付过程 | Issue tracker、`docs/requirements/issues/`、`docs/testing/` | 跟踪垂直切片、实现路由、验证记录和审查结论 |
+| 交付过程 | Ticket tracker、`docs/requirements/tickets/`、`docs/testing/` | 跟踪垂直切片、实现路由、验证记录和审查结论 |
 
 推荐把真实工程代码放在独立实现仓库。本仓库默认作为 Harness / 研发管理仓库，保存产品、契约和过程资产。如果用户明确选择把代码放入本仓库，才按需新增：
 
@@ -39,18 +39,18 @@ docs/implementation/
 
 | 工具 | 负责什么 | 你应该什么时候用 |
 |---|---|---|
-| `yss-product-lifecycle` | 判断生命周期阶段、缺失资产、最近可信阶段和最小 skill 集合 | 不确定当前应补 PRD、设计、OpenAPI、架构、Issue 还是实现时 |
-| `competitive-intelligence` | 竞品、替代方案、定价、定位、用户口碑和市场事实研究 | 进入 Discovery / PRD 前需要外部事实支撑时 |
-| Matt Engineering Skills | 澄清、PRD、Issue、实现、TDD、诊断、审查、架构治理 | 大部分通用工程流程 |
+| `yss-product-lifecycle` | 判断生命周期阶段、缺失资产、最近可信阶段和最小 skill 集合 | 不确定当前应补 Spec、设计、OpenAPI、架构、Ticket 还是实现时 |
+| `competitive-intelligence` | 竞品、替代方案、定价、定位、用户口碑和市场事实研究 | 进入 Discovery / Spec 前需要外部事实支撑时 |
+| Matt Engineering Skills | 澄清、Spec、Ticket、实现、TDD、诊断、审查、架构治理 | 大部分通用工程流程 |
 | YSS skills | DDD、UI、OpenAPI、Repository、Controller、DTO、组件规范 | 进入具体前后端实现或专项审查时 |
 | OpenAPI 3.1 | 前后端 API 契约 | 任何接口路径、schema、错误、分页、权限或并发语义变化时 |
 | OpenSpec-style Spec Delta | 行为差异、验收场景和测试映射 | API、权限、状态机、数据模型、跨端、新模块或高风险行为变化时 |
-| Issue tracker | 状态同步和切片追踪 | 每个阶段结束、垂直切片创建、验证或阻塞更新时 |
+| Ticket tracker | 状态同步和切片追踪 | 每个阶段结束、垂直切片创建、验证或阻塞更新时 |
 
 一句话：
 
 ```text
-PRD 管用户价值，OpenAPI 管接口契约，Spec Delta 管行为差异，Issue 管交付切片，YSS 管工程规范，Matt skills 管工作方法。
+Spec 管用户价值，OpenAPI 管接口契约，Spec Delta 管行为差异，Ticket 管交付切片，YSS 管工程规范，Matt skills 管工作方法。
 ```
 
 ## 3. 新建工程的初始化流程
@@ -88,7 +88,7 @@ CONTEXT.md
 | 发布版本 | 已冻结的可引用版本 | 原则上不可变 |
 | 模型校验 | 发布前对字段、命名、关系和约束的检查 | 失败时需要字段级错误 |
 
-这一步会直接影响后续 AI 生成 PRD、API、代码和测试的质量。可用 `domain-modeling` 持续维护领域语言和 ADR。
+这一步会直接影响后续 AI 生成 Spec、API、代码和测试的质量。可用 `domain-modeling` 持续维护领域语言和 ADR。
 
 ### Step 3: 确认实现仓库和产物目录
 
@@ -114,10 +114,10 @@ docs/process/lifecycle-artifact-map.md
 ```text
 1. 入口分诊
 2. 机会与 Discovery
-3. 业务 / PRD / 功能架构
+3. 业务 / Spec / 功能架构
 4. 产品设计与需求冻结
 5. 系统 / 数据架构与工程契约设计审查
-6. 契约冻结与 Issue formalization
+6. 契约冻结与 Ticket 正式化
 7. 垂直切片与 TDD 实现
 8. 验证发布与复盘
 ```
@@ -125,23 +125,23 @@ docs/process/lifecycle-artifact-map.md
 常见入口：
 
 - 只有一个模糊想法：先机会探索，再用 `grill-with-docs` 收敛用户、痛点、MVP、非目标和成功标准。
-- 已有行业、竞品或用户材料：先用 `competitive-intelligence` 做 Discovery 事实整理，再生成 PRD。
+- 已有行业、竞品或用户材料：先用 `competitive-intelligence` 做 Discovery 事实整理，再生成 Spec。
 - 明确 Bug 或小调整：不走完整机会探索环，直接用 `diagnosing-bugs` 或最小改动加验证。
 - 已有功能的小需求变更：先做影响面评估，选择最近可信阶段，只更新受影响资产和下游门禁。
-- 新模块、API 或跨端改动：必须按 8 个主阶段推进；有 UI 时必须经过产品设计、原型评审和需求冻结；有 API 时必须完成 API 影响分析 / 契约草案、必要的 Spec Delta、工程基线、系统 / 数据架构、Design Review、OpenAPI Freeze，再进入 `to-issues`、垂直切片和 TDD。
+- 新模块、API 或跨端改动：必须按 8 个主阶段推进；有 UI 时必须经过产品设计、原型评审和需求冻结；有 API 时必须完成 API 影响分析 / 契约草案、必要的 Spec Delta、工程基线、系统 / 数据架构、Design Review、OpenAPI Freeze，再进入 `to-tickets`、垂直切片和 TDD。
 
 ## 5. `yss-product-lifecycle` 使用入口
 
-当你不知道当前应该补 Discovery、PRD、OpenAPI、工程基线、垂直切片还是 YSS 实现技能时，先使用 `yss-product-lifecycle`。
+当你不知道当前应该补 Discovery、Spec、OpenAPI、工程基线、垂直切片还是 YSS 实现技能时，先使用 `yss-product-lifecycle`。
 
 它的职责是阶段判断和路由，不替代 Matt skills、`yss-router` 或具体 YSS 专项技能。
 
 推荐使用场景：
 
 - 新产品、新模块或跨端/API 改动：先判断生命周期阶段和缺失资产。
-- 小需求变更或迭代：判断现有 PRD、产品总体设计、交互设计、OpenAPI、架构、垂直切片中哪一层最早受影响。
-- 已有 PRD 或设计材料：检查是否可以进入产品总体设计、API 影响分析 / 契约草案、工程基线、Issue 或垂直切片。
-- 实现前：确认 PRD、OpenAPI Freeze、工程基线、设计审查和垂直切片是否齐备。
+- 小需求变更或迭代：判断现有 Spec、产品总体设计、交互设计、OpenAPI、架构、垂直切片中哪一层最早受影响。
+- 已有 Spec 或设计材料：检查是否可以进入产品总体设计、API 影响分析 / 契约草案、工程基线、Ticket 或垂直切片。
+- 实现前：确认 Spec、OpenAPI Freeze、工程基线、设计审查和垂直切片是否齐备。
 
 推荐提示词：
 
@@ -154,20 +154,20 @@ docs/process/lifecycle-artifact-map.md
 
 ### 6.1 澄清需求
 
-使用 `grill-with-docs`，把想法问到可以进入 PRD：
+使用 `grill-with-docs`，把想法问到可以进入 Spec：
 
 ```text
-使用 grill-with-docs，围绕“<功能名>”澄清用户、痛点、MVP、非目标、成功标准、边界条件和安全人审点。
+使用 grill-with-docs，围绕“<功能名>”澄清用户、痛点、MVP、非目标、成功标准、边界条件和人工审查点。
 请同步检查 CONTEXT.md 中是否需要补充领域术语，必要时提出 ADR 候选。
 ```
 
-### 6.2 生成 PRD
+### 6.2 生成 Spec
 
-已有足够上下文后使用 `to-prd`：
+已有足够上下文后使用 `to-spec`：
 
 ```text
-使用 to-prd，把当前讨论整理为 PRD。
-正文使用中文，包含用户故事、验收标准、非目标范围、OpenAPI 影响、测试决策、AI/人工审查点和安全红线。
+使用 to-spec，把当前讨论整理为 Spec。
+正文使用中文，包含用户故事、验收标准、非目标范围、OpenAPI 影响、测试决策、AI/人工审查点和风险 / 回滚约束。
 ```
 
 ### 6.3 设计产品和契约
@@ -175,7 +175,7 @@ docs/process/lifecycle-artifact-map.md
 有 UI 时先走设计系统、`product-design:index` 路由的产品设计、低保真原型评审、Ant Design v6 高保真 HTML 原型、AntD CLI 校验证据和用户确认记录。涉及 API 时，先生成 review-only OpenAPI Draft：
 
 ```text
-基于 PRD 和产品设计，生成 OpenAPI 3.1 Draft。
+基于 Spec 和产品设计，生成 OpenAPI 3.1 Draft。
 Draft 仅用于评审，不得作为实现或生成客户端的稳定契约。
 请检查 YSS response wrappers、错误结构、分页、权限、并发和契约测试 seam。
 如涉及 API、权限、状态机、数据模型、跨端、新模块或高风险行为变化，请同步生成 OpenSpec-style Spec Delta，记录 ADDED / MODIFIED / REMOVED、验收场景和测试映射。
@@ -185,11 +185,11 @@ Draft 经工程基线、系统 / 数据架构和 Design Review 通过后，记
 
 ### 6.4 拆分垂直切片
 
-OpenAPI Freeze 或无 API 影响记录完成后使用 `to-issues`：
+OpenAPI Freeze 或无 API 影响记录完成后使用 `to-tickets`：
 
 ```text
-使用 to-issues，基于 PRD、OpenAPI Freeze 和架构设计，把功能拆成可独立验证的垂直切片 Issue。
-每个 Issue 必须包含用户价值、验收标准、测试命令、依赖、回滚点、YSS skill routing 和 TODO-HUMAN-REVIEW。
+使用 to-tickets，基于 Spec、OpenAPI Freeze 和架构设计，把功能拆成可独立验证的垂直切片 Ticket。
+每个 Ticket 必须包含用户价值、验收标准、测试命令、依赖、回滚点、YSS skill routing，以及需要人工确认的事项（如适用）。
 ```
 
 ### 6.5 实现与审查
@@ -206,8 +206,8 @@ OpenAPI Freeze 或无 API 影响记录完成后使用 `to-issues`：
 
 - Draft 阶段允许调整接口，但不能被当成稳定实现契约。
 - Freeze 后的契约变更必须回到 API 影响分析、架构 / 数据设计和 Design Review，不能边写代码边悄悄改接口。
-- OpenAPI 不得只基于 PRD 反推：必须结合产品总体设计 / 功能架构；有 UI 时还必须结合页面 / 原型 / 交互说明、状态矩阵、低保真原型评审、Ant Design v6 高保真 HTML 原型、AntD CLI 校验证据和用户确认记录。
-- OpenAPI Freeze 后进入 `to-issues`，再进入前后端实现和契约测试。
+- OpenAPI 不得只基于 Spec 反推：必须结合产品总体设计 / 功能架构；有 UI 时还必须结合页面 / 原型 / 交互说明、状态矩阵、低保真原型评审、Ant Design v6 高保真 HTML 原型、AntD CLI 校验证据和用户确认记录。
+- OpenAPI Freeze 后进入 `to-tickets`，再进入前后端实现和契约测试。
 
 ## 8. 验证、发布和复盘
 
@@ -217,6 +217,6 @@ OpenAPI Freeze 或无 API 影响记录完成后使用 `to-issues`：
 - 运行时间或当前提交。
 - 结果摘要。
 - 失败项或未覆盖风险。
-- 是否触碰安全红线。
+- 是否存在高风险变更、人工确认项或回滚约束。
 
-发布前补齐发布说明、实施步骤和回滚方案。发生架构返工、重要 review finding、verify 返工或 `TODO-HUMAN-REVIEW` 延期时，必须写复盘，并把流程修订回写到 `AGENTS.md`、生命周期文档、ADR 或模板中。
+发布前补齐发布说明、实施步骤和回滚方案。发生架构返工、重要 review finding、verify 返工或人工确认延期时，必须写复盘，并把流程修订回写到 `AGENTS.md`、生命周期文档、ADR 或模板中。