create-yss-spec 3.3.0 → 3.3.1

package/template/.trae/skills/yss-product-lifecycle/references/orchestration-contract.yaml

@@ -48,6 +48,34 @@ modes:
   orchestrate: bounded_write
   resume: rebuild_then_bounded_write
 
+execution_efficiency:
+  context_query:
+    strategy: combine-mode-stage-work-unit-and-required-includes
+    read_scope: current-work-unit-and-triggered-impacts
+    reuse: already-read-unchanged-sources-within-current-task
+    refresh_on: [source-changed, new-impact, evidence-conflict, resume, handoff]
+  verification:
+    scope: current-artifacts-and-triggered-contracts
+    timing: after-artifact-write-before-approval-or-transition
+    duplicate_check: reuse-only-within-same-boundary-and-unchanged-inputs
+    unchanged_inputs: [artifact-bytes, upstream-bytes, validator-and-schema, command-and-options, repository-root]
+    freshness_unknown: rerun
+    always_revalidate_on: [resume, handoff, implementation-entry, merge, release]
+    template_regression_suite: template-maintenance-or-explicit-regression-task
+    per_work_unit_context_reconciliation: required
+    skip_triggered_gates: forbidden
+  interaction:
+    questions: batch-independent-current-stage-questions
+    user_decision_policy_ref: docs/agents/digital-human-roles.yaml#user_decision_policy
+    decision_evidence_ref: references/user-decisions.md
+    dependent_future_approvals: forbidden
+    checkpoint_policy_ref: checkpoint_policy
+  timing_evidence:
+    location: existing-checkpoint-verification-evidence
+    script_fields: [command, duration_ms, exit_code]
+    distinguish: [script-execution, agent-orchestration, human-wait]
+    unmeasured_duration: unknown
+
 # 有效的 YSS 仓库必须先由生命周期编排器接管入口；Matt flow 只负责选择工作方式。
 entry_routing:
   manifest: yss-project.yaml
@@ -210,7 +238,7 @@ lifecycle_native_entries:
     implement: lifecycle-validate-and-accept
 
 work_unit_routes:
-  work-unit.discovery-opportunity:
+  work-unit.plan-opportunity:
     native: {source: yss-product-lifecycle, skill: yss-product-lifecycle, invocation_mode: model-invoked}
     primary_skill: yss-product-lifecycle
     supporting_skills: [competitive-intelligence, yss-research]
@@ -218,7 +246,7 @@ work_unit_routes:
     route_by: {market_or_competitor_fact: competitive-intelligence, technical_or_standard_fact: yss-research:technical-evidence, strategy_fact: yss-research:strategy-evidence, no_external_fact: yss-product-lifecycle}
     applies_when: opportunity_or_external_fact_requires_validation
     not_applicable_reason: no_external_fact
-  work-unit.discovery-requirements:
+  work-unit.plan-requirements:
     native: {source: yss-product-lifecycle, skill: yss-product-lifecycle, invocation_mode: model-invoked}
     primary_skill: yss-product-lifecycle
     supporting_skills: [grilling, domain-modeling]
@@ -241,7 +269,7 @@ work_unit_routes:
     skills: [yss-stage-decision, domain-modeling, yss-research]
     research_contract: {profile: strategy-evidence, mode_before_gate: evidence-audited, artifact_owner: yss-research, downstream_owner: yss-stage-decision}
     human_gate: stage-decision-package-approved
-    applies_when: discovery_to_spec_requires_stable_decision_package
+    applies_when: plan_to_spec_requires_stable_decision_package
     not_applicable_reason: existing_approved_stage_decision_current
   work-unit.spec-synthesis:
     native: {source: yss-product-lifecycle, skill: yss-product-lifecycle, invocation_mode: model-invoked}
@@ -484,6 +512,10 @@ transition_graph:
     work-unit.intensity-aware-verification: [work-unit.intensity-aware-review]
     work-unit.intensity-aware-review: [work-unit.release-and-rollback]
     work-unit.release-and-rollback: []
+    work-unit.plan-opportunity: [work-unit.plan-requirements, work-unit.domain-strategy-design, work-unit.stage-decision, work-unit.spec-synthesis]
+    work-unit.plan-requirements: [work-unit.domain-strategy-design, work-unit.stage-decision, work-unit.spec-synthesis]
+    work-unit.domain-strategy-design: [work-unit.stage-decision, work-unit.spec-synthesis]
+    work-unit.stage-decision: [work-unit.spec-synthesis]
     work-unit.spec-synthesis: [work-unit.prototype-design, work-unit.technical-analysis, work-unit.implementation-repository-preparation]
     work-unit.prototype-design: [work-unit.technical-analysis, work-unit.implementation-repository-preparation]
     work-unit.technical-analysis: [work-unit.implementation-repository-preparation]
@@ -495,6 +527,25 @@ transition_graph:
     - {from: work-unit.technical-analysis, to: work-unit.slice-implementation}
     - {from: work-unit.technical-analysis, to: work-unit.ticket-decomposition}
 
+planning:
+  entry_validator: scripts/verify-plan-spec-entry
+  review_contract: docs/plan/entry-review.md
+  check_policy: docs/process/lifecycle-registry.yaml
+  default_check_status: pending
+  formal_spec_draft_requires_passed_entry: true
+  stage: stage.plan
+  record: artifact.plan-record
+  template: docs/plan/templates/plan-template.md
+  exit_policy: docs/process/lifecycle-registry.yaml
+  migration_policy: docs/process/plan-migration.md
+  critical_open_questions: block-before-spec
+  deferred_details_require: [noncritical_reason, owner, resolution_point, downstream_recipient]
+  reuse_requires: [source_ref, current_version, applicable_scope, reason]
+  downstream: work-unit.spec-synthesis
+  implementation_authorized: false
+  frontier_scope: current-plan-decisions
+  deferred_details: excluded-from-frontier-only-after-user-confirms-deferral
+
 grill_exit:
   required: [frontier_empty, facts_resolved_or_routed, decisions_confirmed, shared_understanding_confirmed, no_unresolved_runnable_blocker]
   facts_resolved_or_routed:
@@ -502,7 +553,7 @@ grill_exit:
     runnable_question: handoff-prototype-handoff
     external_decision: external-input-required
   user_confirmation_required: true
-  output: discovery-evidence
+  output: plan-evidence
 
 ticket_role_transition:
   yss_active:
@@ -761,7 +812,7 @@ tracker:
   local_markdown:
     root: docs/.scratch
     legacy_roots: [.scratch, docs/requirements/tickets]
-    feature_layout: [map.md, discovery, spec.md, spec-delta, parent-ticket.md, design, api, architecture, gates, verification, issues]
+    feature_layout: [map.md, plan, spec.md, spec-delta, parent-ticket.md, design, api, architecture, gates, verification, issues]
     primary_sync: local
     remote_ticket_required: false
     remote_mirror: optional
@@ -817,7 +868,7 @@ wayfinder_mode:
     - multi-session-or-multi-agent-work
     - unclear-decision-frontier
     - cross-domain-dependency-map-needed
-  lifecycle_position: discovery-to-spec-planning
+  lifecycle_position: plan-to-spec-planning
   completion_route: wayfinder -> handoff -> to-spec
   does_not_replace: [lifecycle-gates, spec-baseline, ticket-formalization]
   forbidden_state_mutations: [ready-for-agent, gate-approval, ticket-role]

package/template/.trae/skills/yss-product-lifecycle/references/orchestration.md

@@ -13,6 +13,16 @@
 
 连续阶段自动推进时累积 Ticket 同步和 Git 判断证据，在人工暂停、handoff、进入实现、合并或发布边界集中 checkpoint。发生阻塞、责任人变化或资产需要单独批准时立即落 checkpoint，不因合并记录而丢失阶段因果关系。
 
+## 执行成本
+
+执行策略以 `orchestration-contract.yaml.execution_efficiency` 为准，通过同一次 `query-lifecycle-context` 查询取得。Plan → Spec → Ticket 的耗时应分清脚本执行、Agent 读取与编排、人工等待；没有计时记录时不把总时长归因于摘要计算。
+
+同一工作单元把 mode、stage、work-unit 和必要 include 放进一次查询。查询已给出的内容不再整份读取；已读资料在当前任务内未变化时复用，变化、新影响或恢复时重新加载。只问当前阶段尚缺且会影响判断的问题，独立问题可合并；依赖尚未形成资产的后续批准仍按用户决定协议逐边界取得。
+
+资产写入稳定后、批准或流转前执行当前合同要求的验证。同一边界内，只有输入字节、上游、验证器/schema、参数和仓库根均已确认未变化且实际结果可读时，才引用已执行结果；不确定就重跑。每个工作单元仍生成并校验自己的 context reconciliation；恢复、交接、实现、合并和发布边界重新执行适用验证。`verify-*-scenarios` 与模板全量核验用于模板维护或明确的回归任务，不因产品阶段切换而重复执行；实例合同显式要求的检查仍须执行。
+
+脚本命令、实际退出码和 duration_ms 记入已有 checkpoint 的验证证据；Agent 编排和人工等待仅在有计时来源时记录，否则标为 unknown。无需为耗时再建一套阶段产物。
+
 ## 阶段边界
 
 Matt phase boundary 是工作阶段之间的上下文决策，不是新的生命周期状态。按以下顺序判断，第一项适用即停止判断：
@@ -59,7 +69,7 @@ tracker 选择和冲突按 `docs/agents/issue-tracker.md` 裁决：已持久化
 
 - `work-unit.technical-analysis` 由 `yss-technical-design` 组织后端技术设计，先按项目确认架构，再调用 DDD `yss-tactical-design` 或传统 MVC `yss-mvc-design`。状态、规则、一致性、持久化影响本身不意味着选择 DDD。无后端技术设计影响记录带原因的 `not-applicable`，其他 API / 前端技术分析继续各自路由。新合同使用 `artifact.technical-design`，通过 `evidence.technical-design-review` 回交现有架构审查；旧 DDD 稳定 ID 只读兼容。批准仍由生命周期维护，编译器消费批准且当前的设计起草实现合同；`stale`、`drift` 或 `new_impacts` 时不得继续 Ticket 正式化。
 
-- `work-unit.discovery-requirements` 实际调用 `grilling` 和 `domain-modeling`；`work-unit.discovery-opportunity` 按事实类型路由 `competitive-intelligence` 或 `yss-research`。`yss-research:quick` 只用于探索；外部证据进入领域战略、阶段决策或其他生命周期批准输入前必须升级为 `evidence-audited`。生命周期原生工作单元默认负责 Spec、Ticket 和实现资产；`to-spec`、`to-tickets`、`implement` 仅保留为显式兼容入口，结果必须回交生命周期验收。
+- `work-unit.plan-requirements` 实际调用 `grilling` 和 `domain-modeling`；`work-unit.plan-opportunity` 按事实类型路由 `competitive-intelligence` 或 `yss-research`。`yss-research:quick` 只用于探索；外部证据进入领域战略、阶段决策或其他生命周期批准输入前必须升级为 `evidence-audited`。生命周期原生工作单元默认负责 Spec、Ticket 和实现资产；`to-spec`、`to-tickets`、`implement` 仅保留为显式兼容入口，结果必须回交生命周期验收。
 - 原生 `work-unit.ticket-decomposition` 只能在 OpenAPI Freeze 或无 API 影响记录后创建垂直切片，初始 Ticket 状态统一为 `ready-for-human`；生命周期复算完整公式后才能提升 `ready-for-agent`。该工作单元必须返回 `ticket_decomposition_result_ref` 和垂直切片引用，并作为实现的必经前置证据。
 - 原生 `work-unit.slice-implementation` 必须在生命周期批准并持久化 Slice Implementation Contract 和 Build Architecture Checklist 后执行；用户显式 `implement` 仍走兼容入口，不得绕过生命周期。
 - `Workflow Execution Result.next_route` 必须通过生命周期转换校验；Spec、原型和技术分析不得直接跳转到 Ticket 正式化或实现，必须先完成 `work-unit.implementation-repository-preparation`，再进入 `work-unit.ticket-decomposition`。

package/template/.trae/skills/yss-research/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yss-research
-description: Research technical or product-strategy questions with traceable evidence before YSS Discovery, Spec, domain-strategy, API, architecture, or implementation decisions. Use for current facts, standards, third-party APIs, business constraints, user problems, domain-boundary evidence, or when the deprecated `research` alias is invoked.
+description: Research technical or product-strategy questions with traceable evidence before YSS Plan, Spec, domain-strategy, API, architecture, or implementation decisions. Use for current facts, standards, third-party APIs, business constraints, user problems, domain-boundary evidence, or when the deprecated `research` alias is invoked.
 ---
 
 # YSS Research

package/template/.trae/skills/yss-stage-decision/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yss-stage-decision
-description: 编排 Discovery 到 Spec 入口的方案决策与业务边界、协作和规则设计；当需求、业务责任区、统一业务词汇或下游影响尚未稳定时使用。
+description: 编排 Plan 到 Spec 入口的方案决策与业务边界、协作和规则设计；当需求、业务责任区、统一业务词汇或下游影响尚未稳定时使用。
 ---
 
 # YSS Stage Decision
@@ -9,14 +9,16 @@ description: 编排 Discovery 到 Spec 入口的方案决策与业务边界、
 
 ## 适用边界
 
-- 适用于 `project-instance` 的 Discovery → Spec 入口。
+- 适用于 `project-instance` 的 Plan → Spec 入口。
 - `template-source` 只维护本技能、Schema、验证器和合成 Fixture，不生成具体产品领域资产。
 - 业务边界与协作工作单元只回答：有哪些业务板块、每个业务责任区负责什么、不同责任区如何交接、使用哪些统一业务词汇、发生哪些业务事实、有哪些待确认的关键业务对象和不可违反的业务规则。
 - Entity、Aggregate、Repository、Java 类、数据库表和 OpenAPI Freeze 留给下游工作单元。
 
 ## 执行顺序
 
-1. 读取 `yss-project.yaml`、`CONTEXT.md`、既有 Discovery/Spec、ADR 和父 Ticket/checkpoint。
+Plan 的目标与退出条件由 `docs/process/lifecycle-registry.yaml` 持有；从 `docs/plan/templates/plan-template.md` 汇总输入。旧资产按 `docs/process/plan-migration.md` 重新整理并核查，关键未决项不得延期到 Spec，非关键项记录责任人、解决时点与接收方。
+
+1. 读取 `yss-project.yaml`、`CONTEXT.md`、既有 Plan/Spec、ADR 和父 Ticket/checkpoint。
 2. 分离事实、决策、假设、约束和未决项；技术事实走 `yss-research` 的 `technical-evidence`，领域边界、业务规则、MVP、非目标、成功标准或阶段推进依据等决策证据走 `strategy-evidence`，市场/竞品事实走 `competitive-intelligence`。
 3. 从业务故事、已发生的事实、规则、责任人和失败路径识别业务板块与业务责任区，不从数据库表或调用链直接反推边界。
 4. 为每个业务责任区建立统一业务词汇；对跨责任区协作记录规则提供方、规则使用方、业务决策权、信息传递方向和口径转换负责人。

package/template/.trae/skills/yss-stage-decision/references/stage-decision-package-contract.md

@@ -1,6 +1,6 @@
 # 方案决策包合同
 
-内部对象 `stage_decision_package` 是 Discovery、需求/产品/商务决策与业务边界和规则设计之间的冻结入口。它记录“做什么、为什么做、范围是什么、哪些仍未决”，不复制业务边界与规则事实。
+内部对象 `stage_decision_package` 是 Plan、需求/产品/商务决策与业务边界和规则设计之间的冻结入口。它记录“做什么、为什么做、范围是什么、哪些仍未决”，不复制业务边界与规则事实。
 
 ## 必须包含
 

package/template/AGENTS.md

@@ -38,11 +38,11 @@
 
 ## 5. `project-instance` 产品研发路由
 
-主流程：分诊 → Discovery → Spec / 功能架构 → 产品设计 → 工程契约 → Ticket → 切片 → 验证 / 发布 / 复盘。
+主流程：分诊 → Plan → Spec / 功能架构 → 产品设计 → 工程契约 → Ticket → 切片 → 验证 / 发布 / 复盘。
 
 - 先按 `docs/process/harness-process-tailoring.md` 判定影响面和最近可信阶段，再由 `yss-product-lifecycle` 执行 `docs/process/lifecycle-registry.yaml`；阅读导航见 `docs/process/lifecycle-artifact-map.md`。
 - 命中门禁必须完成；仅未命中时记录带原因的 `not-applicable`，不得生成空文档或混淆门禁、产物、工作单元、证据。安全 / 权限写入普通 Spec、契约、架构、验收和 seam，按实际影响触发门禁。
-- 新功能和较大变更先进入 Discovery；`grill-with-docs`、`to-spec`、`to-tickets`、`implement` 仅为用户显式兼容入口。API 变更先形成 OpenAPI 3.1 Draft，审查后 Freeze，再实现。
+- 新功能和较大变更先进入 Plan；`grill-with-docs`、`to-spec`、`to-tickets`、`implement` 仅为用户显式兼容入口。API 变更先形成 OpenAPI 3.1 Draft，审查后 Freeze，再实现。
 - Spec Delta 只记冻结基线的高风险行为差异。OpenAPI Freeze 或无 API 影响记录后拆窄垂直切片，禁止仅按技术层横拆。
 - `seam-deferred` 必须记录风险、责任人、后续 Ticket、验证计划和目标版本或发布日期。
 

package/template/CONTEXT.md

@@ -15,6 +15,7 @@ context_schema_version: 1
 
 | 术语 | 含义 | 英文标识 | 避免 / 备注 |
 |---|---|---|---|
+| Plan（战略规划） | 确认目标、业务边界、关键规则、MVP / 非目标、优先级和交接责任，为 Spec 提供已确认的战略输入。 | — | 问题探索是其中按需开展的活动；不等同于 AI-DLC 官方阶段名、交付排期或实现合同的 Context Plan。旧阶段 ID 已弃用，不提供兼容解析。 |
 | Agent | 执行特定工作流步骤的 AI 协作者。 | — | 不要与生物人审查者、数字人角色或 Ticket 状态混用。运行时实例（Cursor Agent、Claude Code、Grok Bot 等）是 Agent 的承载，不是角色本身。 |
 | 运行时绑定 | 把数字人角色落到某个 Agent 平台的适配声明，权威清单在数字人角色注册表的 `runtimes`。 | — | 不要为每个平台复制一套职称职责。 |
 | Grok Bot | Grok 平台上的持久数字队友实例；对应 `runtime.grok`。 | — | 不是数字人角色、技能或门禁。 |
@@ -26,9 +27,9 @@ context_schema_version: 1
 | 运行时副作用审批 | 对发消息、改生产、付款、删数据等工具动作的账号级确认。 | — | 点 Allow 不等于门禁已批准或可发布。避免只称「Grok 平台审批」。 |
 | Ticket 状态 | Tracker 五态：`needs-triage`、`needs-info`、`ready-for-agent`、`ready-for-human`、`wontfix`。 | — | 不要称为数字人角色或「标准角色」。 |
 | 阶段协作组 | 某阶段需要共同可见会签的逻辑成员集合。 | — | 不是某个产品的群聊；平台人数上限只写在对应 `runtimes`。 |
-| 需求经理 | 主责 Discovery 语言、用户/MVP/非目标、Spec 正文与测试 seam 的数字人角色。 | — | 不拥有原型视觉定稿，不 Freeze API，不写实现。 |
+| 需求经理 | 主责 Plan 语言、用户/MVP/非目标、Spec 正文与测试 seam 的数字人角色。 | — | 不拥有原型视觉定稿，不 Freeze API，不写实现。 |
 | 产品经理 | 主责优先级、产品设计影响、原型确认建议、范围裁剪以及商业约束、交付承诺、发布窗口和商业非目标的数字人角色。 | — | 不写生产代码，不单独 Freeze API；对外商务合同和正式承诺须由生物人批准。 |
-| 商业约束 | Discovery 与发布阶段需要确认的商业边界、交付承诺、发布窗口和商业非目标。 | — | 由产品经理负责数字人侧的整理与协调；不等同于独立的“商务”数字人角色。 |
+| 商业约束 | Plan 与发布阶段需要确认的商业边界、交付承诺、发布窗口和商业非目标。 | — | 由产品经理负责数字人侧的整理与协调；不等同于独立的“商务”数字人角色。 |
 | Agent 入口规则 | Agent 启动任务时必须先遵守的全局路由、硬门禁和禁止事项。 | — | 不作为 YSS 后端、前端或其他专项编码规范的完整手册。 |
 | 标准文档语言 | 面向业务、产品、架构、实施、审查、发布和复盘的持久化文档所使用的默认语言。 | — | 统一使用简体中文；英文专有名词、代码标识、API 路径、schema、文件名和协议 metadata 保持原样。 |
 | Matt Engineering Skills | 来自 `mattpocock/skills` 的轻量工程流程技能集合。 | — | 用于澄清、Spec、Ticket、实现、TDD、诊断、审查和架构治理，不替代 YSS 专项规范。 |

package/template/README.md

@@ -23,7 +23,7 @@
 │   ├── api/                 ← OpenAPI 3.1 契约
 │   ├── adr/                 ← 架构决策记录
 │   ├── requirements/        ← Spec / 用户故事 / 需求草案 / 垂直切片
-│   ├── discovery/           ← 机会探索、市场、竞品和用户材料
+│   ├── plan/                ← 战略规划与 Spec 上游输入
 │   ├── design/              ← 产品设计、原型、交互说明和状态矩阵
 │   ├── architecture/        ← 架构设计与审查模板
 │   ├── releases/            ← 发布说明
@@ -42,7 +42,7 @@
 1. 先读取 `yss-project.yaml`，按 `repository_mode` 选择模板维护或产品研发生命周期。
 2. 必读入口为 `AGENTS.md` 与 `CONTEXT.md`；流程事实分别以生命周期映射和裁剪指南为准。
 3. `template-source` 修改后先按 `maintenance-intensity.yaml` 判定 L1 / L2 / L3，默认用 `scripts/verify-template-fast` 达到 `implementation-ready`；L3 日常采用维护者自检，正式发布前执行完整门禁；只有共享 skill 变更才运行 `scripts/sync-skills` 和 `scripts/update-skill-lock`。
-4. `project-instance` 默认从 `yss-product-lifecycle` 的 `route` 模式开始，再由原生 `work-unit.*` 推进 Discovery、Spec、产品设计、工程契约和 Ticket 正式化；`grill-with-docs`、`to-spec`、`to-tickets`、`implement` 仅作为用户显式调用的兼容入口。
+4. `project-instance` 默认从 `yss-product-lifecycle` 的 `route` 模式开始，再由原生 `work-unit.*` 推进 Plan、Spec、产品设计、工程契约和 Ticket 正式化；`grill-with-docs`、`to-spec`、`to-tickets`、`implement` 仅作为用户显式调用的兼容入口。
 5. 实现仓库接入、YSS 路由、独立审查、fresh verification 和 Git checkpoint 以 `AGENTS.md` 的硬门禁为准。
 
 YSS skills 的公开发布投影维护在 [iloveZzz/yss-spec-dev-skills](https://github.com/iloveZzz/yss-spec-dev-skills)，发布清单和导出命令见 [skills 维护说明](./docs/agents/skills-maintenance.md)。
@@ -115,7 +115,7 @@ scripts/verify-template-fast
 | [docs/agents/README.md](./docs/agents/README.md) | Agent 协作文档目录说明 |
 | [docs/agents/skills-maintenance.md](./docs/agents/skills-maintenance.md) | Agent skills 安装与维护 |
 | [docs/user-guide/yss-ui-mcp.md](./docs/user-guide/yss-ui-mcp.md) | YSS UI MCP 项目配置、全局安装边界与自检 |
-| [docs/discovery/IDEATION.md](./docs/discovery/IDEATION.md) | 机会构想方法 |
+| [docs/plan/IDEATION.md](./docs/plan/IDEATION.md) | 机会构想方法 |
 | [docs/architecture/README.md](./docs/architecture/README.md) | 架构设计 + 审查清单 |
 | [docs/testing/README.md](./docs/testing/README.md) | 测试策略 |
 

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

@@ -12,7 +12,7 @@
 |---|---|---|
 | 数字人角色 | 职称配置（需求经理、产品经理、前端工程师…） | Ticket 五态、某个平台的 Bot |
 | 主控数字人 | 生命周期编排器的运行时实例 | 第八个业务职称 |
-| 职能工作单元 | Discovery / Spec / Code / Review | 职称 |
+| 职能工作单元 | Plan / Spec / Code / Review | 职称 |
 | 执行态 | Explorer / Drafter / Worker / Reviewer / Verifier | 数字人角色 |
 | 运行时绑定 | 如何在 Cursor / Claude / Grok 等落地 | 角色职责本身 |
 

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
@@ -274,7 +274,7 @@ 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

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/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` |
@@ -50,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` | 新模块或跨边界变化。 |