create-yss-spec 3.2.0 → 3.3.1

package/template/docs/agents/digital-human-roles.yaml

@@ -67,7 +67,7 @@ orchestrator:
   kind: orchestrator
   title: YSS 生命周期主控
   default_dual_hat: [role.project-manager]
-  stages: [stage.entry-triage, stage.discovery, stage.spec-architecture, stage.product-design, stage.system-data-engineering, stage.ticket-formalization, stage.vertical-slice-implementation, stage.verification-release-retrospective]
+  stages: [stage.entry-triage, stage.plan, stage.spec-architecture, stage.product-design, stage.system-data-engineering, stage.ticket-formalization, stage.vertical-slice-implementation, stage.verification-release-retrospective]
   core_skills: [yss-product-lifecycle, yss-implementation-contract-compiler]
   forbidden_skills: [yss-domain, yss-ui, yss-ui-business-page-generation, yss-web-controller, yss-repository, implement]
   description: >-
@@ -84,12 +84,12 @@ roles:
     kind: digital-human
     contract_version: 1
     title: YSS 需求经理
-    stages: [stage.discovery, stage.spec-architecture]
-    draft_artifact_ids: [artifact.discovery-record, artifact.spec]
+    stages: [stage.plan, stage.spec-architecture]
+    draft_artifact_ids: [artifact.plan-record, artifact.spec]
     core_skills: [grilling, domain-modeling, yss-research, competitive-intelligence, grill-with-docs]
     forbidden_skills: [yss-ui, yss-domain, yss-web-controller, yss-repository, yss-ddd-scaffold-generator, yss-layered-mvc-scaffold-generator, yss-frontend-scaffold-generator, implement, tdd]
     description: >-
-      Own Discovery language, users, MVP, non-goals, success criteria, test
+      Own Plan language, users, MVP, non-goals, success criteria, test
       seams, and Spec prose. Propose CONTEXT.md glossary entries. Do not freeze
       visual prototypes, OpenAPI, or code. Do not guess unconfirmed business
       rules. Hand off to the orchestrator when the frontier is empty.
@@ -99,14 +99,14 @@ roles:
     kind: digital-human
     contract_version: 1
     title: YSS 产品经理
-    stages: [stage.discovery, stage.spec-architecture, stage.product-design, stage.verification-release-retrospective]
+    stages: [stage.plan, stage.spec-architecture, stage.product-design, stage.verification-release-retrospective]
     draft_artifact_ids: [artifact.product-overview, artifact.functional-architecture, artifact.interaction-spec, artifact.state-matrix, artifact.prototype-confirmation]
     core_skills: [yss-design-system, yss-prototype-stage, prototype-review, yss-antdv-next-design, yss-research, competitive-intelligence]
     forbidden_skills: [yss-ui, yss-domain, yss-repository, yss-web-controller, yss-ddd-scaffold-generator, yss-layered-mvc-scaffold-generator, implement, tdd]
     description: >-
       Own priority, product-design impact, interaction, state matrix, prototype
       confirmation recommendation, and the commercial constraints, delivery
-      commitments, release window, and commercial non-goals for Discovery and
+      commitments, release window, and commercial non-goals for Plan and
       release. May reject Spec scope. Do not write production code or freeze
       OpenAPI alone. Do not independently approve external commercial contracts
       or formal commitments; those require biological-human approval. Frontend
@@ -119,7 +119,7 @@ roles:
     kind: digital-human
     contract_version: 1
     title: YSS 项目经理
-    stages: [stage.entry-triage, stage.discovery, stage.spec-architecture, stage.product-design, stage.system-data-engineering, stage.ticket-formalization, stage.vertical-slice-implementation, stage.verification-release-retrospective]
+    stages: [stage.entry-triage, stage.plan, stage.spec-architecture, stage.product-design, stage.system-data-engineering, stage.ticket-formalization, stage.vertical-slice-implementation, stage.verification-release-retrospective]
     draft_artifact_ids: [artifact.parent-ticket, artifact.vertical-slice-ticket]
     core_skills: [yss-product-lifecycle, handoff, implementation-repo-onboarding, cross-repo-implementation-routing]
     forbidden_skills: [yss-domain, yss-ui, implement, tdd, yss-web-controller]
@@ -180,9 +180,9 @@ roles:
       feature implementation. Must be a different instance from the implementer.
 
 stage_groups:
-  - id: group.discovery
-    name: Discovery
-    stage: stage.discovery
+  - id: group.plan
+    name: Plan
+    stage: stage.plan
     members: [role.lifecycle-orchestrator, role.requirements-manager, role.product-manager]
   - id: group.spec
     name: Spec
@@ -219,6 +219,7 @@ gate_policy:
     - gate.repository-identity-valid
     - gate.prototype-verified
   orchestrator:
+    - gate.implementation-repositories-ready
     - gate.slice-contract-approved
     - gate.slice-ready-for-agent
   digital_human_review:
@@ -273,8 +274,9 @@ user_decision_policy:
     - gate.architecture-reviewed
     - gate.release-ready
   work_units:
-    work-unit.discovery-requirements: discovery-conclusion
+    work-unit.plan-requirements: plan-conclusion
     work-unit.service-project-initialization: scaffold-choice
+    work-unit.implementation-repository-preparation: scaffold-choice
     work-unit.slice-implementation: implementation-scope
     work-unit.release-and-retrospective: gate.release-ready
   work_unit_gates:

package/template/docs/agents/issue-tracker.md

@@ -41,7 +41,7 @@ Local 主 tracker 的完整功能包结构如下：
 ```text
 docs/.scratch/<feature>/
 ├── map.md
-├── discovery/
+├── plan/
 ├── spec.md
 ├── spec-delta/
 ├── parent-ticket.md

package/template/docs/agents/strategic-design-skills-integration.md

@@ -11,6 +11,8 @@
 
 父模板通过 `.agents/skills/.strategic-design-skills-manifest.json` 固定上游 Git revision、路径和 tree hash。公共 ID 不因 profile 改名；共享规则先在战略设计源仓演进，再由父模板同步。
 
+本轮 Plan 调整的 `yss-stage-decision` hash 对应战略设计子仓 commit `3a358684c5684ada433dca4fd97ee187050ca6d8`；父模板的 `source_revision` 与 gitlink 已同步。实施记录见 `.template-source/evidence/maintenance/2026-09-09-plan/`。
+
 ## 父模板薄适配
 
 父模板承载完整产品研发生命周期，只允许在以下位置保留最小语境差异：

package/template/docs/agents/yss-skill-registry.yaml

@@ -85,6 +85,7 @@ capabilities:
   - { id: component.gateway-resilience, primary_skill: yss-resilience4j, task_modes: [guidance, integration, slice-implementation, troubleshooting, component-maintenance, review-input] }
   - { id: scaffold.ddd, primary_skill: yss-ddd-scaffold-generator, task_modes: [integration, component-maintenance] }
   - { id: scaffold.layered-mvc, primary_skill: yss-layered-mvc-scaffold-generator, task_modes: [integration, component-maintenance] }
+  - { id: scaffold.frontend-vue3, primary_skill: yss-frontend-scaffold-generator, task_modes: [integration, component-maintenance] }
   - { id: project-init.mvc-data-analysis, primary_skill: yss-mvc-data-analysis-project-initializer, task_modes: [component-maintenance] }
   - { id: migration.springboot3, primary_skill: yss-up-springboot3, task_modes: [guidance, integration, troubleshooting, component-maintenance, review-input] }
 recipes:
@@ -106,8 +107,12 @@ recipes:
   - { id: backend.distributed-id, capabilities: [component.distributed-id] }
   - { id: backend.ddd-scaffold, capabilities: [scaffold.ddd, quality.java-code-style] }
   - { id: backend.mvc-scaffold, capabilities: [scaffold.layered-mvc, quality.java-code-style] }
+  - { id: frontend.vue3-scaffold, capabilities: [scaffold.frontend-vue3] }
   - { id: backend.springboot3-migration, capabilities: [migration.springboot3, quality.java-code-style] }
 skill_dependencies:
+  code-review:
+    - { skill: yss-repository, type: context-conditional, when: backend-persistence-impact }
+    - { skill: yss-mybatis, type: context-conditional, when: backend-persistence-impact }
   yss-prototype-stage:
     - { skill: prototype-review, type: review-only }
     - { skill: yss-design-system, type: coordination-only }

package/template/docs/architecture/README.md

@@ -10,7 +10,7 @@
 
 | 产物 | 产出阶段 | 重点问题 | 建议文件 |
 |------|----------|----------|----------|
-| 业务架构 | 机会探索 / Discovery / 产品定义 | 用户是谁、价值流是什么、产品在业务生态中的边界在哪里 | `<feature>-business-architecture.md` |
+| 业务架构 | 机会探索 / Plan / 产品定义 | 用户是谁、价值流是什么、产品在业务生态中的边界在哪里 | `<feature>-business-architecture.md` |
 | 产品总体设计 / 功能架构 | Spec 初稿之后、页面 / 原型 / 交互设计之前 | 用户主流程、业务对象、功能域、模块边界、页面/API/数据影响、优先级、依赖和 MVP 非目标范围是什么 | `<feature>-product-overview-design.md` 或 `<feature>-functional-architecture.md` |
 | 系统概要设计 / 系统总体架构 | 工程基线 / 系统 / 数据架构设计 | 服务/模块如何构建、部署、集成、运维、回滚和演进 | `<feature>-system-overview-design.md`、`<feature>-system-architecture.md` 或 `<feature>-architecture.md` |
 | 数据架构 | 详细设计 / 持久化开发前 | 概念/逻辑/物理模型、元模型、版本、血缘、查询、索引和存储策略是什么 | `<feature>-data-architecture.md` |

package/template/docs/architecture/templates/business-architecture-template.md

@@ -14,7 +14,7 @@ owner: ai
 
 | 资产 | 路径 / 链接 | 状态 | 备注 |
 |------|-------------|------|------|
-| Discovery |  |  |  |
+| Plan |  |  |  |
 | 竞品 / 市场分析 |  |  |  |
 | CONTEXT 术语 |  |  |  |
 | 现有业务流程 |  |  |  |

package/template/docs/architecture/templates/functional-architecture-template.md

@@ -16,7 +16,7 @@ owner: ai
 |------|-------------|------|------|
 | Spec 初稿 |  |  |  |
 | 业务架构 |  |  |  |
-| Discovery |  |  |  |
+| Plan |  |  |  |
 | CONTEXT 术语 |  |  |  |
 
 ## 2. 功能目标与边界

package/template/docs/design/README.md

@@ -63,5 +63,5 @@ Token 或组件视觉变体变更必须先修改 `DESIGN.md`，再更新派生
 docs/.scratch/<feature>/design/diagrams/
 docs/.scratch/<feature>/design/prototypes/
 docs/.scratch/<feature>/architecture/diagrams/
-docs/.scratch/<feature>/discovery/diagrams/
+docs/.scratch/<feature>/plan/diagrams/
 ```

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

@@ -9,7 +9,7 @@
 | Spec 初稿 | `docs/.scratch/<feature>/spec.md` | 原型评审后需要回填和校准 |
 | 产品总体设计 / 功能架构 | `docs/.scratch/<feature>/design/<feature>-product-overview-design.md` | 必需；缺失时先返回产品总体设计阶段 |
 | 领域术语 | `CONTEXT.md` | 核心名词、状态和业务规则 |
-| Discovery | `docs/.scratch/<feature>/discovery/<feature>-discovery.md` | 可选 |
+| Plan | `docs/.scratch/<feature>/plan/<feature>-discovery.md` | 可选 |
 | 原型阶段合同 / Product Design 路由 | `yss-prototype-stage -> product-design:index -> <focused skill>` | 必需；记录 `$get-context`、`$ideate`、`$prototype`、`$image-to-code` 或 `$url-to-code` |
 | 原型 / 线框图 | `<链接或导出图片路径>` | Excalidraw / Figma / Penpot / tldraw / Axure / Markdown |
 | 原型交付物 | `docs/.scratch/<feature>/design/prototypes/index.html` 或稳定 URL | 低保真评审后按 H1/H2 档位补齐；H2 AntD 条件取事实；真实组件待验事项交接到前端实现计划，产出后必须获得用户确认 |

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

@@ -14,7 +14,7 @@ owner: ai
 
 | 资产 | 路径 / 链接 | 状态 | 备注 |
 |------|-------------|------|------|
-| Discovery / 竞品分析 |  |  |  |
+| Plan / 竞品分析 |  |  |  |
 | 业务架构 |  |  |  |
 | Spec 初稿 |  |  |  |
 | CONTEXT 术语 |  |  |  |

package/template/docs/{discovery → plan}/IDEATION.md

@@ -1,6 +1,6 @@
 # 机会构想 (Ideation) — 发现与需求之间的假设生成
 
-> **Phase：生成可验证假设，再用 Discovery 事实校准。AI 是发散、挑战和组合机会的加速器。**
+> **Plan 内部方法：生成可验证假设，再用 事实核查 事实校准。AI 是发散、挑战和组合机会的加速器。**
 
 ---
 
@@ -11,7 +11,7 @@ Ideation 不等同于  Matt skills `需求澄清`：
 | 项 | 定位 | 输出 |
 |---|---|---|
 | Ideation Agent | 产品机会探索角色，回答“可能做什么、是否值得探索” | 候选机会、假设、挑战点、组合方案 |
-| Discovery Agent | 事实验证角色，回答“证据支持什么、用户真实痛点是什么” | 市场、竞品、用户洞察、MVP 边界输入 |
+| 事实核查角色 | 事实验证角色，回答“证据支持什么、用户真实痛点是什么” | 市场、竞品、用户洞察、MVP 边界输入 |
 |  Matt skills `需求澄清` | 方法论 skill，回答“某个已选方向如何形成技术方案” | 设计说明、方案取舍、风险识别、进入计划前的批准点 |
 
 推荐关系：
@@ -20,7 +20,7 @@ Ideation 不等同于  Matt skills `需求澄清`：
 市场 / 竞品 / 用户事实 <-> 机会构想假设 <-> MVP 边界
 ```
 
-如果只有一个模糊主题，可以先 Ideation 再 Discovery；如果已经有竞品、用户或行业材料，应先 Discovery 再 Ideation。二者循环到 Spec 前，必须收敛用户、痛点、做什么、不做什么和成功标准。
+如果只有一个模糊主题，可以先 Ideation 再 事实核查；如果已经有竞品、用户或行业材料，应先 事实核查 再 Ideation。二者循环到 Spec 前，必须收敛用户、痛点、做什么、不做什么和成功标准。
 
 ---
 
@@ -90,7 +90,7 @@ Substitute / Combine / Adapt / Modify / Put to another use / Eliminate / Reverse
 ## AI-Human Loop
 
 ```
-人类提主题或 Discovery 事实 → AI 发散候选机会 → 人类选择 Top 10
-→ AI 挑战者分析 → Discovery 验证证据 → AI 连接者找模式
+人类提主题或 事实核查 事实 → AI 发散候选机会 → 人类选择 Top 10
+→ AI 挑战者分析 → 事实核查 验证证据 → AI 连接者找模式
 → 收敛 MVP 边界 → 确认是否进入 Spec / Ticket 或  Matt skills 需求澄清 技术方案设计
 ```

package/template/docs/plan/README.md

@@ -0,0 +1,9 @@
+# Plan（战略规划）
+
+Plan 为 Spec 提供已确认的战略输入。目标和退出条件引用 [生命周期注册表](../process/lifecycle-registry.yaml)，裁剪引用 [影响面规则](../process/harness-process-tailoring.md)。
+
+从 [规划模板](templates/plan-template.md) 开始。先识别哪些结论仍有效、哪些问题需要探索，再确认目标、业务边界、关键规则、MVP / 非目标、优先级和交接责任。业务边界与规则设计、方案决策包保留各自权威正文，Plan 通过引用组织输入，不重复定义。
+
+问题探索是阶段内部按需开展的活动；市场和竞品事实使用 `competitive-intelligence`，技术或战略证据使用 `yss-research`。机会构想与事实核查可以反复迭代，关键问题解决后才申请进入 Spec。
+
+历史资产处理见 [迁移说明](../process/plan-migration.md)。

package/template/docs/plan/entry-review.md

@@ -0,0 +1,23 @@
+# Plan → Spec 入口审阅
+
+正式 Spec 起草之前必须通过 `node scripts/verify-plan-spec-entry <state.yaml>`；显式 `to-spec`、恢复、任务包派发和下一路由均不得绕过。Plan 不通过时可继续无依赖调研，不创建正式 Spec 草稿。此检查复用 `plan-conclusion` 用户决定，不新增批准阶段，也不授权实现。
+
+检查 ID 与条件门禁取自 `docs/process/lifecycle-registry.yaml` 的 `stage.plan.spec_entry`。查询 Plan 或相关工作单元自动加载 `planning`、`grill_exit` 和全量检查，初始均为 `pending`。自动加载不代表勾选通过。
+
+## 持久化合同
+
+入口状态包含 `feature_id`、`plan_review_ref`、`plan_user_decision_ref`。这三个字段同样用于任务包、checkpoint 和完成态 Workflow Execution Result；不从历史阶段、路径或默认值推断。
+
+`plan_review_ref` 指向 YAML / JSON：
+
+- `schema_version: 1`、`kind: plan-entry-review`、与入口一致的 `feature_id`。
+- `plan_ref`：本次 Plan 正文；`context_reconciliation_ref`：本次已通过的 Context 调和记录。
+- `basis`：非空 `{ref, digest}` 列表，digest 为实际文件字节的 `sha256:` 摘要。必须包含 Plan 正文、根 `CONTEXT.md`、生命周期注册表、Context 调和记录及各检查和门禁引用的文件。远程事实先保存可追溯证据快照。
+- `checks`：注册表要求的全部检查 ID，每项包含 `status: pending | passed` 和非空 `evidence_refs`，引用 `basis`。必需检查不接受 `not-applicable`。缺项、未知项、pending 均阻断。
+- `open_items`：显式数组，空数组代表无未决项。每项有 `id`、`critical`、`runnable_blocker`、`status` 和 `evidence_refs`。影响业务边界、关键规则或 MVP 的问题属于 critical。`resolved` 须有解决证据；仅非关键、非可执行阻塞项可 `deferred`，并填写 `noncritical_reason`、`owner`、`resolution_point`、`downstream_recipient`。延期内容随整个审阅包展示并取得用户确认。
+- `impacts`：显式评估 `domain_strategy`（领域边界、词汇、协作或核心规则影响）和 `stage_decision`（需要稳定阶段决策合同）。证据和判断必须呈现给用户；缺值不解释为 false。
+- `gates`：注册表 Plan 门禁全部逐项记录。命中项须 `status: approved`、`approval_ref`、`subject_ref`、`approval_scope`、`evidence_refs`，会签记录及对应资产均加入 `basis`；未命中项须 `status: not-applicable`、`reason`、`evidence_refs`，并由用户确认影响面判断。阶段决策门禁的上游依赖必须批准，不能用 N/A 跳过。
+
+先固定审阅包及依据，展示当前内容、范围、风险、延期、N/A 理由和下一动作，再取得真实用户回复。`plan_user_decision_ref` 采用 `docs/process/schemas/user-decision.schema.json`：边界为 `plan-conclusion`，subject 为当前 `plan_review_ref`，scope 包含当前 `feature_id`。不得将旧“继续”、数字人会签或合成测试回复当作本次批准。
+
+审阅包、注册表、Plan、词汇、依据或批准来源变化均要求重新校验；摘要漂移时重新展示并取得当前确认。检查器保证结构、引用、摘要和回复绑定，不证明业务事实或身份来源绝对真实；主控仍须按证据核查影响面，不能为了放行而填 false 或空问题列表。

package/template/docs/plan/templates/plan-template.md

@@ -0,0 +1,58 @@
+---
+pipeline: <feature-id>
+stage: plan
+status: draft
+owner: <负责人>
+---
+
+# <功能名称> Plan（战略规划）
+
+> 生命周期身份：`stage.plan` / `artifact.plan-record`。按影响面填写，不制造未命中项的空产物。进入 Spec 的退出条件以 `docs/process/lifecycle-registry.yaml` 为准。
+
+## 1. 输入与复用依据
+
+| 资产 / 证据引用 | 版本 | 本次仍有效的依据 | 需要重新探索的部分 |
+|---|---|---|---|
+
+## 2. 用户、问题与目标
+
+- 目标用户和关键业务故事：
+- 问题、为什么现在做：
+- 期望结果、成功标准及验证方式：
+- 约束、假设及事实证据：
+
+## 3. 战略资产引用
+
+| 权威资产 | 当前版本 / 引用 | 确认状态 / 未命中原因 |
+|---|---|---|
+| 根 CONTEXT.md | | |
+| 业务边界与规则设计 | | |
+| 方案决策包 | | |
+
+业务责任区、关键规则和协作关系消费上述资产，不复制为第二套正文。
+
+## 4. MVP、非目标和优先级
+
+| 能力 / 范围 | MVP / 非目标 | 优先级及依据 | 成功信号 |
+|---|---|---|---|
+
+## 5. 下游影响与交接
+
+| 下游阶段 / 接收方 | 输入引用 | 责任人 | 待细化内容 | 命中门禁 |
+|---|---|---|---|---|
+
+详细页面、API、技术模型和实现切片在后续阶段细化；此处只登记影响与交接责任。
+
+## 6. 未决项
+
+| 问题 | 是否影响业务边界 / 关键规则 / MVP | 判断依据 | 责任人 | 解决时点 | 接收方 / 解决证据 |
+|---|---|---|---|---|---|
+
+## 7. 退出核查与用户决定
+
+- [ ] 已按注册表核查 Plan 退出条件；关键未决项已解决。
+- [ ] 非关键未决项有依据、责任人、解决时点及接收方；无 runnable blocker。
+- [ ] 用户已确认规划结论，命中的门禁及根词汇对账证据可读且版本当前。
+- 当前资产版本、确认范围和原始用户决定引用：
+- 结论：ready-for-human / blocked / 已满足进入 Spec 的条件（附证据）。
+- 下一工作单元：

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

@@ -18,7 +18,7 @@
 | 模板源维护 | 影响面分析 | 修改单一事实来源、按验证与审查强度分级执行证据、必要的技能投影同步、fresh verification / review | 产品 Spec、产品设计、OpenAPI、运行时代码 |
 | 小改动 | 入口分诊 | 影响面、主 tracker 同步、fresh verification | Spec、架构、原型、切片（没有触发条件时） |
 | 中等变更 | 最近可信的 Spec / 架构阶段 | Spec、功能架构、必要工程审查、父 Ticket 和切片 | 未命中的 UI、数据或 API 门禁 |
-| 全新产品 / 模块 | Discovery | Discovery、Spec、产品总体设计、功能架构、必要设计 / 契约审查、父 Ticket 和切片 | 未命中的 UI、数据或 API 门禁 |
+| 全新产品 / 模块 | Plan | Plan、Spec、产品总体设计、功能架构、必要设计 / 契约审查、父 Ticket 和切片 | 未命中的 UI、数据或 API 门禁 |
 | 高风险变更 | 既有冻结基线 | Spec Delta、架构 / 数据 / 工程审查、契约复核、切片和回滚设计 | 与风险证据无关的门禁 |
 
 任何裁剪都必须写明原因和证据，不生成空文档。对跨仓库变更，Harness 记录必须绑定实现仓库、分支、CI、验证命令、发布顺序和回滚点；没有前端、后端或 OpenAPI 影响时显式记录 `not-applicable`。

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

@@ -10,7 +10,7 @@
 | 稳定 ID | 阶段 | 目标 | 退出标准 |
 |---|---|---|---|
 | `stage.entry-triage` | 入口分诊 | 确认仓库身份、问题范围和影响面。 | yss-project.yaml 合法，影响面和最近可信阶段可解释。 |
-| `stage.discovery` | Discovery | 澄清问题、用户、约束和机会。 | 问题边界、关键假设和待确认项已记录。 |
+| `stage.plan` | Plan（战略规划） | 确认目标、业务边界、关键规则、MVP / 非目标、优先级和交接责任，为 Spec 提供战略输入；按影响面探索并复用仍有效的结论。 | 用户确认规划结论，命中的战略与阶段决策门禁通过；影响业务边界、关键规则或 MVP 的问题已解决，其他未决项有责任人和解决时点；下游可进入 Spec，不代表可实现。 |
 | `stage.spec-architecture` | Spec / 功能架构 | 固化解决方案和功能边界。 | Spec 基线和功能边界可审查。 |
 | `stage.product-design` | 产品设计 | 在存在产品设计影响时校准页面流和状态。 | 命中的设计门禁通过；未命中项记录 not-applicable 及原因。 |
 | `stage.system-data-engineering` | 系统 / 数据架构与工程契约 | 固化系统、数据、工程基线和 API 契约。 | 受影响工程契约冻结或记录无 API 影响；required 脚手架证据齐全。 |
@@ -28,8 +28,8 @@
 |---|---|---|---|---|---|
 | `gate.frontend-delivery-inputs-verified` | 前端联合输入核验 | `stage.system-data-engineering` | 专职前端 profile 或显式 frontend_delivery 绑定的任务启动、恢复、合同编译、实现和验证；实际执行 scripts/verify-frontend-delivery，输入就绪不等于实现获批。 | 无 | `evidence.fresh-verification` |
 | `gate.repository-identity-valid` | 仓库身份校验 | `stage.entry-triage` | 每次进入流程。 | 无 | `evidence.repository-identity-check` |
-| `gate.domain-strategy-approved` | 业务边界与规则确认 | `stage.discovery` | 需要确定业务板块、业务责任区、统一业务词汇、协作关系或关键规则。 | 无 | `evidence.domain-strategy-review`、`evidence.approval-record` |
-| `gate.stage-decision-package-approved` | 阶段决策包批准 | `stage.discovery` | Discovery 到 Spec 入口需要稳定的阶段决策合同。 | `gate.domain-strategy-approved` | `evidence.stage-decision-package`、`evidence.approval-record` |
+| `gate.domain-strategy-approved` | 业务边界与规则确认 | `stage.plan` | 需要确定业务板块、业务责任区、统一业务词汇、协作关系或关键规则。 | 无 | `evidence.domain-strategy-review`、`evidence.approval-record` |
+| `gate.stage-decision-package-approved` | 阶段决策包批准 | `stage.plan` | Plan 到 Spec 入口需要稳定的阶段决策合同。 | `gate.domain-strategy-approved` | `evidence.stage-decision-package`、`evidence.approval-record` |
 | `gate.spec-baseline-approved` | Spec 基线批准 | `stage.spec-architecture` | 新功能、行为变化或范围扩大进入 Spec 基线。 | 无 | `evidence.approval-record` |
 | `gate.prototype-reviewed` | 原型评审 | `stage.product-design` | 命中产品设计影响，且低保真页面、流程、状态或 API 反推需要独立评审。 | 无 | `evidence.prototype-review-result` |
 | `gate.prototype-verified` | 原型交付物验证 | `stage.product-design` | 产品设计影响需要通过 H1/H2 原型交付物进行视觉或流程校准；真实组件验证留到前端实现阶段。 | 无 | `evidence.prototype-profile-decision`、`evidence.prototype-deliverable-verification` |
@@ -39,6 +39,7 @@
 | `gate.openapi-frozen` | OpenAPI Freeze | `stage.system-data-engineering` | API 进入实现。 | 无 | `evidence.approval-record` |
 | `gate.engineering-baseline-accepted` | 工程基线 | `stage.system-data-engineering` | 后端、前端或高风险工程变化。 | 无 | `evidence.fresh-verification` |
 | `gate.architecture-reviewed` | 架构审查 | `stage.system-data-engineering` | 高风险或跨边界变化。 | 无 | `evidence.design-review-result` |
+| `gate.implementation-repositories-ready` | 实现仓库准备就绪 | `stage.system-data-engineering` | 后端或前端交付面进入 Ticket 正式化；未命中的交付面须记录带原因的 not-applicable。 | `gate.engineering-baseline-accepted` | `evidence.implementation-repository-preparation`、`evidence.fresh-verification` |
 | `gate.slice-contract-approved` | Slice Implementation Contract 批准 | `stage.ticket-formalization` | Agent 进入实现；脚手架完成后每个后续生成代码工作单元。 | 无 | `evidence.contract-approval` |
 | `gate.slice-ready-for-agent` | 垂直切片实现就绪 | `stage.ticket-formalization` | 垂直切片具备直接实现条件。 | 无 | `evidence.contract-approval`、`evidence.approval-record` |
 | `gate.frontend-implementation-verified` | 前端实现还原验证 | `stage.verification-release-retrospective` | UI 影响切片完成实现并准备合并、发布或阶段完成。 | 无 | `evidence.frontend-implementation-verification` |
@@ -49,9 +50,9 @@
 | 稳定 ID | 产物 | 所属阶段 | 触发条件 |
 |---|---|---|---|
 | `artifact.impact-assessment` | 影响面分析 | `stage.entry-triage` | 每次变更。 |
-| `artifact.domain-strategy` | 业务边界与规则设计 | `stage.discovery` | 新产品/模块、跨责任区协作、业务词汇冲突、责任边界或关键规则变化。 |
-| `artifact.stage-decision-package` | 方案决策包 | `stage.discovery` | Discovery 到 Spec 入口需要结构化上游决策。 |
-| `artifact.discovery-record` | Discovery 记录 | `stage.discovery` | 新问题或边界不清。 |
+| `artifact.domain-strategy` | 业务边界与规则设计 | `stage.plan` | 新产品/模块、跨责任区协作、业务词汇冲突、责任边界或关键规则变化。 |
+| `artifact.stage-decision-package` | 方案决策包 | `stage.plan` | Plan 到 Spec 入口需要结构化上游决策。 |
+| `artifact.plan-record` | Plan 记录 | `stage.plan` | 新问题或边界不清。 |
 | `artifact.spec` | Spec | `stage.spec-architecture` | 新功能、行为变化或范围扩大。 |
 | `artifact.product-overview` | 产品总体设计 | `stage.spec-architecture` | 进入 Spec 基线。 |
 | `artifact.functional-architecture` | 功能架构 | `stage.spec-architecture` | 新模块或跨边界变化。 |
@@ -67,6 +68,8 @@
 | `artifact.engineering-baseline` | 工程基线记录 | `stage.system-data-engineering` | 后端、前端或高风险工程变化。 |
 | `artifact.architecture-review` | 架构审查记录 | `stage.system-data-engineering` | 高风险或跨边界变化。 |
 | `artifact.technical-design` | 技术设计合同 | `stage.system-data-engineering` | 后端技术设计需要按已确认 DDD 或 MVC 架构明确行为、分层、一致性或数据映射。 |
+| `artifact.project-scaffold-contract` | Project Scaffold Contract | `stage.system-data-engineering` | 命中的前端或后端交付面选择初始化新工程。 |
+| `artifact.implementation-repository-preparation-result` | 实现仓库准备结果 | `stage.system-data-engineering` | 后端或前端交付面进入 Ticket 正式化。 |
 | `artifact.tactical-design` | DDD 战术设计 | `stage.system-data-engineering` | 聚合边界、状态机、一致性或持久化映射复杂到无法在系统概要设计的 Tactical DDD Check 中清楚表达。 |
 | `artifact.spec-delta` | Spec Delta | `stage.spec-architecture` | 已有冻结 Spec 的高风险行为变化。 |
 | `artifact.parent-ticket` | 功能父 Ticket | `stage.ticket-formalization` | 每个进入追踪的功能。 |
@@ -101,6 +104,7 @@
 | `evidence.yss-skill-execution-result` | YSS Skill Execution Result | 专项 skill 的合同版本、写入、验证、延期 seam 与偏离证据。 |
 | `evidence.frontend-implementation-verification` | 前端实现还原验证证据 | UI 实现相对冻结原型和 Spec 的桌面/窄屏视觉、状态、交互、控制台与 pnpm 验证记录。 |
 | `evidence.fresh-verification` | Fresh Verification 记录 | 本轮实际执行的验证命令、结果和时间。 |
+| `evidence.implementation-repository-preparation` | 实现仓库准备证据 | 按项目记录交付面、已有仓库接入或新脚手架合同、生成清单、实际验证结果、仓库位置、Git 边界和当前版本。 |
 | `evidence.checkpoint-and-rollback` | Checkpoint 与回滚点 | 可追溯的变更边界、发布记录和恢复动作。 |
 <!-- lifecycle-registry:structure:end -->
 

package/template/docs/process/lifecycle-registry-baseline.json

@@ -1,7 +1,7 @@
 {
   "schema_version": 1,
   "registry_id": "yss.lifecycle",
-  "semantic_sha256": "4eadc734957c5112dad60ec9fe4d844ac8790cbe798fbd8177ee60eae6dbe1fa",
+  "semantic_sha256": "96fcbcb858eed45ba228d87c75804f28ccb464b1963c0d23be348ade094bac01",
   "published_ids": [
     "artifact.architecture-review",
     "artifact.data-architecture",
@@ -13,12 +13,15 @@
     "artifact.functional-architecture",
     "artifact.high-fidelity-html-prototype",
     "artifact.impact-assessment",
+    "artifact.implementation-repository-preparation-result",
     "artifact.interaction-spec",
     "artifact.low-fidelity-prototype",
     "artifact.openapi-draft",
     "artifact.openapi-freeze-record",
     "artifact.parent-ticket",
+    "artifact.plan-record",
     "artifact.product-overview",
+    "artifact.project-scaffold-contract",
     "artifact.prototype-confirmation",
     "artifact.prototype-deliverable",
     "artifact.prototype-review",
@@ -42,6 +45,7 @@
     "evidence.fresh-verification",
     "evidence.frontend-implementation-verification",
     "evidence.impact-assessment",
+    "evidence.implementation-repository-preparation",
     "evidence.maintenance-intensity-checkpoint",
     "evidence.openapi-draft-review",
     "evidence.prototype-confirmation",
@@ -59,6 +63,7 @@
     "gate.engineering-baseline-accepted",
     "gate.frontend-delivery-inputs-verified",
     "gate.frontend-implementation-verified",
+    "gate.implementation-repositories-ready",
     "gate.openapi-draft-reviewed",
     "gate.openapi-frozen",
     "gate.prototype-reviewed",
@@ -72,6 +77,7 @@
     "gate.user-confirmation",
     "stage.discovery",
     "stage.entry-triage",
+    "stage.plan",
     "stage.product-design",
     "stage.spec-architecture",
     "stage.system-data-engineering",
@@ -86,9 +92,12 @@
     "work-unit.entry-triage",
     "work-unit.fresh-verification",
     "work-unit.frontend-implementation-verification",
+    "work-unit.implementation-repository-preparation",
     "work-unit.independent-review",
     "work-unit.intensity-aware-review",
     "work-unit.intensity-aware-verification",
+    "work-unit.plan-opportunity",
+    "work-unit.plan-requirements",
     "work-unit.prototype-design",
     "work-unit.release-and-retrospective",
     "work-unit.release-and-rollback",

package/template/docs/process/lifecycle-registry.yaml

@@ -8,17 +8,22 @@ id_policy:
   pattern: '^(stage|gate|artifact|work-unit|evidence)\.[a-z0-9][a-z0-9-]*$'
   published_ids_immutable: true
   baseline: docs/process/lifecycle-registry-baseline.json
-  deprecated_ids: [artifact.high-fidelity-html-prototype, work-unit.fresh-verification, work-unit.independent-review]
+  deprecated_ids: [artifact.high-fidelity-html-prototype, work-unit.fresh-verification, work-unit.independent-review, stage.discovery, artifact.discovery-record, work-unit.discovery-opportunity, work-unit.discovery-requirements]
 
 stages:
   - id: stage.entry-triage
     name: 入口分诊
     goal: 确认仓库身份、问题范围和影响面。
     exit_criteria: yss-project.yaml 合法，影响面和最近可信阶段可解释。
-  - id: stage.discovery
-    name: Discovery
-    goal: 澄清问题、用户、约束和机会。
-    exit_criteria: 问题边界、关键假设和待确认项已记录。
+  - id: stage.plan
+    name: Plan（战略规划）
+    goal: 确认目标、业务边界、关键规则、MVP / 非目标、优先级和交接责任，为 Spec 提供战略输入；按影响面探索并复用仍有效的结论。
+    exit_criteria: 用户确认规划结论，命中的战略与阶段决策门禁通过；影响业务边界、关键规则或 MVP 的问题已解决，其他未决项有责任人和解决时点；下游可进入 Spec，不代表可实现。
+    spec_entry:
+      required_checks: [goals, scope_and_priority, boundaries_and_rules, open_questions, handoff, context_reconciliation, grill_exit]
+      gate_impacts:
+        gate.domain-strategy-approved: domain_strategy
+        gate.stage-decision-package-approved: stage_decision
   - id: stage.spec-architecture
     name: Spec / 功能架构
     goal: 固化解决方案和功能边界。
@@ -110,6 +115,9 @@ evidence:
   - id: evidence.fresh-verification
     name: Fresh Verification 记录
     description: 本轮实际执行的验证命令、结果和时间。
+  - id: evidence.implementation-repository-preparation
+    name: 实现仓库准备证据
+    description: 按项目记录交付面、已有仓库接入或新脚手架合同、生成清单、实际验证结果、仓库位置、Git 边界和当前版本。
   - id: evidence.checkpoint-and-rollback
     name: Checkpoint 与回滚点
     description: 可追溯的变更边界、发布记录和恢复动作。
@@ -127,15 +135,15 @@ gates:
     evidence: [evidence.repository-identity-check]
   - id: gate.domain-strategy-approved
     name: DDD 战略设计批准
-    stage: stage.discovery
+    stage: stage.plan
     trigger: 存在 DDD 战略设计影响或需要确定领域边界、统一语言和核心规则。
     public_name: 业务边界与规则确认
     public_trigger: 需要确定业务板块、业务责任区、统一业务词汇、协作关系或关键规则。
     evidence: [evidence.domain-strategy-review, evidence.approval-record]
   - id: gate.stage-decision-package-approved
     name: 阶段决策包批准
-    stage: stage.discovery
-    trigger: Discovery 到 Spec 入口需要稳定的阶段决策合同。
+    stage: stage.plan
+    trigger: Plan 到 Spec 入口需要稳定的阶段决策合同。
     evidence: [evidence.stage-decision-package, evidence.approval-record]
     requires_gates: [gate.domain-strategy-approved]
   - id: gate.spec-baseline-approved
@@ -183,6 +191,12 @@ gates:
     stage: stage.system-data-engineering
     trigger: 高风险或跨边界变化。
     evidence: [evidence.design-review-result]
+  - id: gate.implementation-repositories-ready
+    name: 实现仓库准备就绪
+    stage: stage.system-data-engineering
+    trigger: 后端或前端交付面进入 Ticket 正式化；未命中的交付面须记录带原因的 not-applicable。
+    evidence: [evidence.implementation-repository-preparation, evidence.fresh-verification]
+    requires_gates: [gate.engineering-baseline-accepted]
   - id: gate.slice-contract-approved
     name: Slice Implementation Contract 批准
     stage: stage.ticket-formalization
@@ -212,18 +226,18 @@ artifacts:
     trigger: 每次变更。
   - id: artifact.domain-strategy
     name: DDD 战略设计
-    stage: stage.discovery
+    stage: stage.plan
     trigger: 新产品/模块、跨上下文功能、统一语言冲突、服务边界或核心规则变化。
     public_name: 业务边界与规则设计
     public_trigger: 新产品/模块、跨责任区协作、业务词汇冲突、责任边界或关键规则变化。
   - id: artifact.stage-decision-package
     name: 阶段决策包
-    stage: stage.discovery
-    trigger: Discovery 到 Spec 入口需要结构化上游决策。
+    stage: stage.plan
+    trigger: Plan 到 Spec 入口需要结构化上游决策。
     public_name: 方案决策包
-  - id: artifact.discovery-record
-    name: Discovery 记录
-    stage: stage.discovery
+  - id: artifact.plan-record
+    name: Plan 记录
+    stage: stage.plan
     trigger: 新问题或边界不清。
   - id: artifact.spec
     name: Spec
@@ -285,6 +299,14 @@ artifacts:
     name: 技术设计合同
     stage: stage.system-data-engineering
     trigger: 后端技术设计需要按已确认 DDD 或 MVC 架构明确行为、分层、一致性或数据映射。
+  - id: artifact.project-scaffold-contract
+    name: Project Scaffold Contract
+    stage: stage.system-data-engineering
+    trigger: 命中的前端或后端交付面选择初始化新工程。
+  - id: artifact.implementation-repository-preparation-result
+    name: 实现仓库准备结果
+    stage: stage.system-data-engineering
+    trigger: 后端或前端交付面进入 Ticket 正式化。
   - id: artifact.tactical-design
     name: DDD 战术设计
     stage: stage.system-data-engineering
@@ -367,13 +389,13 @@ work_units:
     input: 已审查 commit。
     output: release note、观察信号、回滚点。
     completion: 两仓库顺序和恢复动作明确。
-  - id: work-unit.discovery-opportunity
+  - id: work-unit.plan-opportunity
     name: 机会调研
     scope: project-instance
     input: 用户问题、市场/竞品事实需求和现有上下文。
-    output: Discovery 机会结论、证据、替代方案和关键假设。
+    output: Plan 机会结论、证据、替代方案和关键假设。
     completion: 机会继续/停止建议可审查；事实已 research 或记录为假设。
-  - id: work-unit.discovery-requirements
+  - id: work-unit.plan-requirements
     name: 需求分析
     scope: project-instance
     input: 机会结论、用户反馈和领域词汇。
@@ -391,16 +413,16 @@ work_units:
   - id: work-unit.stage-decision
     name: 阶段决策包综合
     scope: project-instance
-    input: Discovery、DDD 战略设计以及产品经理负责的商业约束输入。
+    input: Plan、DDD 战略设计以及产品经理负责的商业约束输入。
     output: 带版本、digest、证据和下游映射的阶段决策包。
     completion: 必填字段、引用、影响面和下游消费验证通过；批准门禁完成。
     public_name: 方案决策包综合
-    public_input: Discovery、业务边界与规则设计以及产品经理负责的商业约束输入。
+    public_input: Plan、业务边界与规则设计以及产品经理负责的商业约束输入。
     public_output: 带版本、digest、证据和下游映射的方案决策包。
   - id: work-unit.spec-synthesis
     name: Spec 综合
     scope: project-instance
-    input: 已确认的 Discovery 记录和测试 seam。
+    input: 已确认的 Plan 记录和测试 seam。
     output: Spec、产品总体设计和功能架构。
     completion: Spec 内容完整并进入 ready-for-human；下游推进仍需 gate.spec-baseline-approved。
   - id: work-unit.prototype-design
@@ -415,6 +437,12 @@ work_units:
     input: Spec、原型、API/数据/工程影响面。
     output: OpenAPI、数据架构、按确认架构形成的 DDD / MVC 技术设计合同、工程基线、架构审查和 Slice 合同草案。
     completion: 命中契约已冻结；无 API 影响有可读记录；命中技术设计影响时架构已确认、规则与场景承接无未解释冲突；工程基线通过。
+  - id: work-unit.implementation-repository-preparation
+    name: 实现仓库准备
+    scope: project-instance
+    input: 工程影响面、工程基线、逐项目用户决定、实现仓库位置；新建工程还需批准且当前的 Project Scaffold Contract。
+    output: 已有工程的 Repository Onboarding Result，或新工程的 Scaffold Manifest 与 Scaffold Verification；并汇总 Implementation Repository Preparation Result。
+    completion: 每个命中的交付面均为 existing-and-onboarded 或 initialized-and-verified，未命中的交付面有带原因的 not-applicable；聚合结果当前且证据可读。
   - id: work-unit.service-project-initialization
     name: 独立服务项目初始化
     scope: project-instance

package/template/docs/process/plan-migration.md

@@ -0,0 +1,13 @@
+# Plan 阶段切换说明
+
+新流程仅使用 `stage.plan`、`artifact.plan-record`、`work-unit.plan-opportunity` 和 `work-unit.plan-requirements`。不提供 Discovery 阶段别名、旧标识解析或兼容入口；旧 ID 在注册表中仅作为弃用清单保留，以防重新分配，不可执行。
+
+新工作从 `docs/plan/templates/plan-template.md` 起草，工作目录为 `docs/.scratch/<feature>/plan/`。问题、机会和事实探索是 Plan 内按影响面执行的活动。
+
+历史冻结文档、批准记录和摘要保持原字节。旧状态不能直接恢复执行；如需继续，按当前 Plan 模板重新整理输入并核查当前退出条件，不把旧批准自动视为新流程批准。已有事实和结论可引用，但须记录当前版本、适用范围和复用理由。
+
+综合模板和战略设计模板共同采用 Plan。它为 Spec 提供战略输入；后续 Spec、页面原型、契约、Ticket 及交接边界仍由各自 profile 和生命周期注册表定义。Plan 不等同于实现合同中的 Context Plan。
+
+影响业务边界、关键规则或 MVP 的未决项必须在进入 Spec 前解决；其他细节须经用户确认延期，并具备不影响当前决定的依据、责任人、解决时点和接收方。既有 runnable blocker 不得降为普通延期项。
+
+Plan 是借鉴 AI-DLC 前置规划职责的本地名称，不宣称是 AWS 官方阶段名称或完整 Inception。