create-yss-spec 3.3.0 → 3.3.3

package/template/.pi/skills/yss-prototype-stage/references/prototype-profile-routing.md

@@ -66,4 +66,4 @@
 
 - 新证据只生成 schema v4、Visual Baseline schema v1 与 `artifact.prototype-deliverable`。
 - prototype evidence schema v1/v2/v3 和 `artifact.high-fidelity-html-prototype` 只读兼容；已经关闭的历史证据保持有效，不补造图片。
-- 在途 UI 证据必须迁移到 v4 并产生 Visual Baseline 后才能关闭 `gate.prototype-verified`；非 UI 功能不生成空包。
+- 在途 UI 证据必须迁移到 v4 并产生 Visual Baseline 后才能关闭 `check.prototype-verified`；非 UI 功能不生成空包。

package/template/.pi/skills/yss-prototype-stage/scripts/prototype-contract.mjs

@@ -196,7 +196,7 @@ export function validatePrototypeEvidence(data, { allowTemplate = false, allowLe
   const warnings = [];
   if (!object(data)) return { errors: ["原型证据必须是对象"], warnings };
   if ([1, 2, 3].includes(data.schema_version)) {
-    if (!allowLegacy) errors.push(`schema_version ${data.schema_version} 是只读旧证据；在途工作关闭 gate.prototype-verified 前必须迁移到 4`);
+    if (!allowLegacy) errors.push(`schema_version ${data.schema_version} 是只读旧证据；在途工作关闭 check.prototype-verified 前必须迁移到 4`);
     else warnings.push(`legacy prototype evidence schema v${data.schema_version}; read-only`);
     return { errors, warnings };
   }
@@ -206,7 +206,7 @@ export function validatePrototypeEvidence(data, { allowTemplate = false, allowLe
   if (!allowTemplate && errors.length === 0) {
     try {
       const confirmation = data.user_confirmation;
-      assertUserDecisionRequirement({ boundary: "gate.user-confirmation", subject_ref: confirmation.decision_subject_ref, scope: confirmation.operable_scope, user_decision_ref: confirmation.user_decision_ref }, decisionOptions);
+      assertUserDecisionRequirement({ boundary: "gate.product-design-approved", subject_ref: confirmation.decision_subject_ref, scope: confirmation.operable_scope, user_decision_ref: confirmation.user_decision_ref }, decisionOptions);
       if (decisionDigest(decisionIO(decisionOptions).document(confirmation.decision_subject_ref)) !== decisionDigest(prototypeDecisionSnapshot(data))) throw new TypeError("user-decision-stale: 原型与用户所见快照不一致");
     } catch (error) { errors.push(error.message); }
   }

package/template/.pi/skills/yss-prototype-stage/tests/run-scenarios.mjs

@@ -83,7 +83,7 @@ function common(profile, kind, block) {
     user_confirmation: { result: "approved", confirmation_ref: "confirmation.md", confirmed_decision: "接受当前设计", operable_scope: ["主操作"], simulations_or_gaps: [] },
     gaps: [], blockers: []
   };
-  const f = buildDecisionFixture(path.join(tempRoot, `decision-${profile}-${kind}`), { boundary: "gate.user-confirmation", scope: data.user_confirmation.operable_scope, subjectContent: JSON.stringify(prototypeDecisionSnapshot(data)) });
+  const f = buildDecisionFixture(path.join(tempRoot, `decision-${profile}-${kind}`), { boundary: "gate.product-design-approved", scope: data.user_confirmation.operable_scope, subjectContent: JSON.stringify(prototypeDecisionSnapshot(data)) });
   data.user_confirmation.user_decision_ref = f.ref;
   data.user_confirmation.decision_subject_ref = f.requirement.subject_ref;
   return data;

package/template/.pi/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/.pi/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. 为每个业务责任区建立统一业务词汇；对跨责任区协作记录规则提供方、规则使用方、业务决策权、信息传递方向和口径转换负责人。
@@ -31,9 +33,9 @@ description: 编排 Discovery 到 Spec 入口的方案决策与业务边界、
 ## 产物与批准
 
 - 业务边界与规则设计是本类事实的权威资产，方案决策包只通过内部字段 `domain_strategy_ref` 引用它。两个合同的 `context_snapshot.context_ref` 必须精确为仓库根 `CONTEXT.md`，禁止子目录、`CONTEXT-MAP.md`、绝对路径和 Markdown 伪锚点。
-- 进入 `gate.domain-strategy-approved` 或 `gate.stage-decision-package-approved` 的外部决策证据必须引用通过校验的 `yss-research` `evidence-audited` 研究包；研究包只提供证据，不得直接修改本技能资产或批准门禁。
+- 进入 `check.domain-strategy-approved` 或 `check.stage-decision-package-approved` 的外部决策证据必须引用通过校验的 `yss-research` `evidence-audited` 研究包；研究包只提供证据，不得直接修改本技能资产或批准门禁。
 - `stage_decision_package` 必须经过 `draft → ready-for-human → approved`；起草者不得自签。
-- 建议门禁为 `gate.domain-strategy-approved` 和 `gate.stage-decision-package-approved`，实际状态由 `yss-product-lifecycle` 维护；阶段包批准引用必须通过 `scripts/verify-approval-record`，不得用不可读路径或聊天确认替代。
+- 内部专业审查为 `check.domain-strategy-approved` 和 `check.stage-decision-package-approved`，汇入 `gate.plan-approved` 一次确认，实际状态由 `yss-product-lifecycle` 维护；阶段包批准引用必须通过 `scripts/verify-approval-record`，不得用不可读路径或聊天确认替代。
 - 下游只能消费批准且版本当前的包；发现语义冲突返回 `drift` / `new_impacts`，不得静默修改上游。
 
 ## 结果合同

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

@@ -1,6 +1,6 @@
 # 方案决策包合同
 
-内部对象 `stage_decision_package` 是 Discovery、需求/产品/商务决策与业务边界和规则设计之间的冻结入口。它记录“做什么、为什么做、范围是什么、哪些仍未决”，不复制业务边界与规则事实。
+内部对象 `stage_decision_package` 是 Plan、需求/产品/商务决策与业务边界和规则设计之间的冻结入口。它记录“做什么、为什么做、范围是什么、哪些仍未决”，不复制业务边界与规则事实。
 
 ## 必须包含
 
@@ -9,7 +9,7 @@
 - `context_snapshot`：只引用根 `CONTEXT.md`，并绑定结构化术语身份、全文摘要和引用集摘要；
 - `domain_strategy_ref`：领域战略合同的稳定 ID、版本、digest 和批准状态；
 - UI/API/Data/Backend/Frontend/跨仓/高风险影响面布尔值；
-- 每个下游消费者的传播方式、重新批准条件、证据引用和批准记录。`approval.approval_ref` 必须指向可读取且通过 `scripts/verify-approval-record` 的 `gate.stage-decision-package-approved` 会签记录；`approval.approver` 必须与记录中的 `role_id` 一致。
+- 每个下游消费者的传播方式、重新批准条件、证据引用和批准记录。`approval.approval_ref` 必须指向可读取且通过 `scripts/verify-approval-record` 的 `check.stage-decision-package-approved` 会签记录；`approval.approver` 必须与记录中的 `role_id` 一致。
 
 ## 未决项规则
 

package/template/.pi/skills/yss-stage-decision/scripts/validate-domain-strategy.mjs

@@ -156,7 +156,7 @@ function validate(data, contextRoot) {
       const approvalPath = resolveApprovalRef(approval.approval_ref);
       validateApprovalRecordFile(approvalPath, { requireApproved: true });
       const record = loadApprovalRecord(approvalPath);
-      if (record.gate_id !== "gate.domain-strategy-approved") errors.push("approval.approval_ref 的 gate_id 必须为 gate.domain-strategy-approved");
+      if (record.gate_id !== "check.domain-strategy-approved") errors.push("approval.approval_ref 的 gate_id 必须为 check.domain-strategy-approved");
       if (record.role_id !== approval.approver) errors.push("approval.approver 必须与会签记录 role_id 一致");
     } catch (error) { errors.push(`approval.approval_ref 会签记录无效: ${error.message}`); }
   }

package/template/.pi/skills/yss-stage-decision/scripts/validate-stage-decision-package.mjs

@@ -87,7 +87,7 @@ async function validate(data, contextRoot) {
       const approvalPath = resolveApprovalRef(approval.approval_ref);
       validateApprovalRecordFile(approvalPath, { requireApproved: true });
       const record = loadApprovalRecord(approvalPath);
-      if (record.gate_id !== "gate.stage-decision-package-approved") errors.push("approval_ref 的 gate_id 必须为 gate.stage-decision-package-approved");
+      if (record.gate_id !== "check.stage-decision-package-approved") errors.push("approval_ref 的 gate_id 必须为 check.stage-decision-package-approved");
       if (record.role_id !== approval.approver) errors.push("approval.approver 必须与会签记录 role_id 一致");
     } catch (error) { errors.push(`approval_ref 会签记录无效: ${error.message}`); }
   }

package/template/.pi/skills/yss-stage-decision/tests/fixtures/domain-strategy-approval.yaml

@@ -1,5 +1,5 @@
 schema_version: 1
-gate_id: gate.domain-strategy-approved
+gate_id: check.domain-strategy-approved
 decision: approved
 actor_kind: digital-human
 role_id: role.product-manager

package/template/.pi/skills/yss-stage-decision/tests/fixtures/stage-decision-approval.yaml

@@ -1,5 +1,5 @@
 schema_version: 1
-gate_id: gate.stage-decision-package-approved
+gate_id: check.stage-decision-package-approved
 decision: approved
 actor_kind: digital-human
 role_id: role.product-manager

package/template/.pi/skills/yss-stage-decision/tests/run-scenarios.mjs

@@ -70,7 +70,7 @@ try {
     .replace("<referenced-terms-digest>", context.referenced_terms_digest);
   const domainFile = join(temporaryRoot, "domain-strategy.yaml");
   await writeFile(domainFile, domainSource);
-  const domainDecision = buildDecisionFixture(join(temporaryRoot, "domain-decision"), { boundary: "gate.domain-strategy-approved", subjectRef: domainFile });
+  const domainDecision = buildDecisionFixture(join(temporaryRoot, "domain-decision"), { boundary: "check.domain-strategy-approved", subjectRef: domainFile });
   const domainApproval = parseDocument(await readFile(join(testsRoot, "fixtures/domain-strategy-approval.yaml"), "utf8")).toJS();
   await writeFile(domainApprovalRef, JSON.stringify({ ...domainApproval, subject_ref: domainFile, approval_scope: domainDecision.requirement.scope, user_decision_ref: domainDecision.ref }));
   const pass = run(validator, domainFile, temporaryRoot);
@@ -123,7 +123,7 @@ try {
     .replace("<domain-strategy-digest>", digestYaml(domainSource));
   const packageFile = join(temporaryRoot, "stage-decision.yaml");
   await writeFile(packageFile, packageSource);
-  const packageDecision = buildDecisionFixture(join(temporaryRoot, "package-decision"), { boundary: "gate.stage-decision-package-approved", subjectRef: packageFile });
+  const packageDecision = buildDecisionFixture(join(temporaryRoot, "package-decision"), { boundary: "check.stage-decision-package-approved", subjectRef: packageFile });
   const packageApproval = parseDocument(await readFile(join(testsRoot, "fixtures/stage-decision-approval.yaml"), "utf8")).toJS();
   await writeFile(packageApprovalRef, JSON.stringify({ ...packageApproval, subject_ref: packageFile, approval_scope: packageDecision.requirement.scope, user_decision_ref: packageDecision.ref }));
   const packagePass = run(packageValidator, packageFile, temporaryRoot);

package/template/.pi/skills/yss-ui/assets/docs/guide/llms.md

@@ -28,7 +28,7 @@ LLMs.txt 是一个专门为大语言模型设计的文档格式规范。通过
 包含所有组件的完整 API 文档、使用示例和最佳实践。**强烈推荐**作为默认配置，因为：
 - ✅ **更准确的代码生成** - AI 能看到完整的 Props、Events、Slots 定义
 - ✅ **真实示例参考** - 包含实际使用代码，避免 AI 猜测用法
-- ✅ **完整上下文** - 现代 AI 工具（Claude 200K、GPT-4 128K）完全支持这个大小
+- ✅ **完整上下文** - 现代 AI 工具的大上下文窗口可完整加载文档
 
 ### 轻量级索引：llms.txt
 
@@ -96,60 +96,6 @@ Always reference the YSS UI documentation when working with components:
 
 ---
 
-### Claude Code
-
-在 Claude Code 中，将 LLMs.txt 添加到工作区的知识库（Docs / Context Files）配置中，即可在代码补全与解释时引用其中的内容。
-
-**使用方法：**
-
-1. 打开 Claude Code 设置
-2. 找到 "Docs / Context Files" 配置
-3. 添加 `http://192.168.164.27:3200/llms-full.txt`
-
-<a href="https://code.claude.com/docs" target="_blank">详细了解 Claude Code 文档上下文配置</a>
-
----
-
-### Trae
-
-在 Trae 中，将 LLMs.txt 文件放入项目的 knowledge sources 并在设置里开启引用。
-
-**使用方法：**
-
-1. 打开 Trae 项目设置
-2. 找到 "Knowledge Sources" 配置
-3. 添加 `http://192.168.164.27:3200/llms-full.txt`
-4. 启用该知识源
-
-<a href="https://trae.ai/docs" target="_blank">详细了解 Trae 的知识源功能</a>
-
----
-
-### Qoder
-
-在 Qoder 中，可以在 `.qoder/config.yml` 中添加 LLMs.txt 作为外部知识文件，或在对话中通过 `@docs` 进行临时引用。
-
-**使用方法 1：配置文件**
-
-在项目根目录创建 `.qoder/config.yml`：
-
-```yaml
-knowledge:
-  external_docs:
-    - url: http://192.168.164.27:3200/llms-full.txt
-      name: YSS UI Documentation
-```
-
-**使用方法 2：临时引用**
-
-```
-@docs http://192.168.164.27:3200/llms-full.txt
-```
-
-<a href="https://docs.qoder.com/" target="_blank">详细了解 Qoder 配置方法</a>
-
----
-
 ### 其他 AI 工具
 
 任何支持 LLMs.txt 的 AI 工具均可使用以上路径来更好地理解 YSS UI。

package/template/AGENTS.md

@@ -30,19 +30,13 @@
 - 每仓只允许根目录一个大小写精确的 `CONTEXT.md`；禁止嵌套、`CONTEXT-MAP.md`、跨仓路径和伪锚点。
 - `project-instance` 每个工作单元批准或流转前完成 `context_reconciliation`；缺失、冲突或摘要漂移即 `blocked`。`template-source` 校验模板合同并记录带原因的 `not-applicable`。
 
-## 4. `template-source` 模板维护路由
-
-- 按“影响面 → 事实源 → 投影 / 派生 → 分级证据”维护；改 Skill 必须用 `maintaining-skills`，并按 `docs/process/harness-process-tailoring.md` 判定 L1 / L2 / L3。
-- `.agents/skills` 是共享 Skill 权威目录；其他 Agent root 下的同名 Skill 是生成投影，不得手改或与 canonical 并列维护。
-- 内循环运行 `scripts/verify-template-fast`；晋级审查运行 `scripts/verify-template-candidate`；首次冻结和最终发布前运行不可裁剪的 `scripts/verify-template`。外部 `create-yss-spec` 集成未闭合不得称可发布。
-
 ## 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,7 +15,8 @@ context_schema_version: 1
 
 | 术语 | 含义 | 英文标识 | 避免 / 备注 |
 |---|---|---|---|
-| Agent | 执行特定工作流步骤的 AI 协作者。 | — | 不要与生物人审查者、数字人角色或 Ticket 状态混用。运行时实例（Cursor Agent、Claude Code、Grok Bot 等）是 Agent 的承载，不是角色本身。 |
+| Plan（战略规划） | 确认目标、业务边界、关键规则、MVP / 非目标、优先级和交接责任，为 Spec 提供已确认的战略输入。 | — | 问题探索是其中按需开展的活动；不等同于 AI-DLC 官方阶段名、交付排期或实现合同的 Context Plan。旧阶段 ID 已弃用，不提供兼容解析。 |
+| Agent | 执行特定工作流步骤的 AI 协作者。 | — | 不要与生物人审查者、数字人角色或 Ticket 状态混用。运行时实例（Cursor Agent、Codex、Grok Bot 等）是 Agent 的承载，不是角色本身。 |
 | 运行时绑定 | 把数字人角色落到某个 Agent 平台的适配声明，权威清单在数字人角色注册表的 `runtimes`。 | — | 不要为每个平台复制一套职称职责。 |
 | Grok Bot | Grok 平台上的持久数字队友实例；对应 `runtime.grok`。 | — | 不是数字人角色、技能或门禁。 |
 | 数字人角色 | 叠加在生命周期编排器上的职称配置；一个运行时实例绑定一种。v1 清单以 `docs/agents/digital-human-roles.yaml` 为准。 | — | 不要称为 Ticket「标准角色」、职能 Agent 或某个平台的产品名。 |
@@ -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 专项规范。 |
@@ -58,8 +59,8 @@ context_schema_version: 1
 | ADR | 架构决策记录，用于沉淀难以回滚、非显而易见且存在真实取舍的技术决策。 | — | 常规实现选择不要写 ADR。 |
 | Fresh Verification | 完成前重新执行的验证证据，包括测试命令、契约校验、关键路径检查或人工审查结论。 | — | 不等同于“之前跑过”或实现者自述。 |
 | `implementation-ready` | 模板维护实现和命中影响面的快速核验已经完成，但尚未冻结正式审查候选。 | — | 是模板维护默认出口；不等同于 `ready-for-agent`、已审查或可发布。 |
-| `review-ready` | 模板维护候选已完成 candidate 核验、首次完整发布门禁和摘要冻结，可以派发独立审查。 | — | Reviewer 必须消费同一候选摘要；候选字节变化后旧审查失效。 |
-| `release-ready` | 模板维护冻结候选已经通过独立审查和最终完整 Fresh Verification。 | — | 仍不替代 `gate.release-ready` 所需的生物人发布裁决。 |
+| `review-ready` | 模板维护显式选择独立审查时的就绪状态；旧候选协议要求 candidate 核验、首次完整验证和摘要冻结。 | — | Reviewer 必须消费同一候选摘要；候选字节变化后旧审查失效。 |
+| `release-ready` | 模板维护已完成维护者自检和发布前完整 Fresh Verification；显式选择独立审查时还须闭合该审查。 | — | 仍不替代 `gate.release-ready` 所需的生物人发布裁决。 |
 | 实现验证命令 | 前端测试 / 构建优先 `pnpm`，后端校验 / 测试 / 编译优先 `./mvnw`。 | — | 不要默认 `npm`、`yarn` 或裸 `mvn`；仓库确实缺少 pnpm 或 Maven Wrapper 时记受控例外。 |
 | 脚手架架构选择 | 新建后端工程在工程基线中对 `domain-driven` 与 `layered-mvc` 的结构化选择；Agent 提供证据化推荐，用户确认后由生命周期批准并供脚手架合同消费。 | — | 不是新门禁，也不是生成器内的交互参数；缺失、未确认或摘要漂移时阻断生成。 |
 | 测试质量基线 | 项目实例明确采纳的覆盖率阈值、关键流程清单和受控例外。 | — | 模板推荐值本身不构成可执行门禁；未定义关键流程时，不得声称其 E2E 覆盖率达到 100%。 |
@@ -101,6 +102,9 @@ context_schema_version: 1
 | 模板实例分发面 | 模板源中应随 CLI 快照进入 `project-instance` 的共享生命周期、模板、用户指南和验证资产集合。 | — | 不包含模板源审查、研究、发布路线、源仓库专属 ADR 或源仓库 LLM Wiki 编译树。 |
 | 模板源治理区 | 仅供 `template-source` 使用、保存审查证据、研究记录、跨仓契约、发布路线、源仓库治理决策和源仓库 LLM Wiki 编译树的归档区域。 | — | 不随 CLI 分发；不等于产品实例的研发管理资产。`wiki-root` 为 `.template-source/wiki`。 |
 | 仓库身份清单 | 显式声明仓库身份和清单结构版本的机器可读资产。 | — | 不承载项目名称、团队规模、Tracker 或其他易变业务配置。 |
+| 聚合门禁 | 汇总适用自动检查和独立专业审查后，对当前资产与范围作一次批准或验收；权威定义见生命周期注册表。 | — | 内部检查失败仍阻断；有效批准只在相关依据、范围或授权变化时失效。 |
+| 内部检查 | 以 `check.*` 登记的自动前置核验、计算状态或独立专业审查；作为聚合门禁输入，不单独请求用户批准。 | — | 不等于省略检查或允许起草者自审。 |
+| 交付验收 | 对当前交付候选的独立审查、实际验证和回滚证据作出验收结论。 | — | 不授予实际合并、推送或发布权限；这些动作另按授权范围执行。 |
 
 ## 业务术语
 

package/template/README.md

@@ -10,12 +10,9 @@
 
 ```text
 ├── .agents/                 ← 跨 Agent 共享 skills 的权威内容
-├── .claude/                 ← Claude skills 投影与平台专属 skills
 ├── .codex/                  ← Codex skills 投影与平台专属 skills
 ├── .cursor/                 ← Cursor skills 投影
 ├── .pi/                     ← Pi skills 投影与平台专属 skills
-├── .qoder/                  ← Qoder skills 投影与平台专属 skills
-├── .trae/                   ← Trae skills 投影与平台专属 skills
 ├── AGENTS.md                ← AI 指令
 ├── CONTEXT.md               ← 领域词汇表
 ├── yss-project.yaml         ← 仓库身份清单
@@ -23,7 +20,7 @@
 │   ├── api/                 ← OpenAPI 3.1 契约
 │   ├── adr/                 ← 架构决策记录
 │   ├── requirements/        ← Spec / 用户故事 / 需求草案 / 垂直切片
-│   ├── discovery/           ← 机会探索、市场、竞品和用户材料
+│   ├── plan/                ← 战略规划与 Spec 上游输入
 │   ├── design/              ← 产品设计、原型、交互说明和状态矩阵
 │   ├── architecture/        ← 架构设计与审查模板
 │   ├── releases/            ← 发布说明
@@ -42,7 +39,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 +112,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/__yss_dotfile__.gitignore

@@ -1,3 +1,4 @@
+# >>> create-yss-spec managed rules
 # Python
 __pycache__/
 *.py[cod]
@@ -13,12 +14,12 @@ dist/
 
 # IDE
 .idea/
-.vscode/
 .DS_Store
 
 # Secrets
 .env
 .env.*
+!.env.example
 *.pem
 
 # Database
@@ -28,17 +29,9 @@ dist/
 # Logs
 *.log
 logs/
-.template-source/cache/
 
 # Coverage
 htmlcov/
 .coverage
 .pytest_cache/
-Excalidraw
-.obsidian
-.ua
-output
-docs/process/presentations/
-docs/process/yss-product-lifecycle-team-guide.md
-docs/graphify-out
-docs/.scratch/
+# <<< create-yss-spec managed rules

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

@@ -1,6 +1,6 @@
 # 数字人角色
 
-结构化事实源是 `docs/agents/digital-human-roles.yaml`。角色、技能、协作组和会签级别与运行时无关。Claude Code、Cursor、Codex、Grok Bot 等只通过 YAML `runtimes` 绑定。冲突时以 YAML 为准。
+结构化事实源是 `docs/agents/digital-human-roles.yaml`。角色、技能、协作组和会签级别与运行时无关。Cursor、Codex、Grok Bot 等只通过 YAML `runtimes` 绑定。冲突时以 YAML 为准。
 
 ## 何时读本文
 
@@ -12,29 +12,17 @@
 |---|---|---|
 | 数字人角色 | 职称配置（需求经理、产品经理、前端工程师…） | Ticket 五态、某个平台的 Bot |
 | 主控数字人 | 生命周期编排器的运行时实例 | 第八个业务职称 |
-| 职能工作单元 | Discovery / Spec / Code / Review | 职称 |
+| 职能工作单元 | Plan / Spec / Code / Review | 职称 |
 | 执行态 | Explorer / Drafter / Worker / Reviewer / Verifier | 数字人角色 |
-| 运行时绑定 | 如何在 Cursor / Claude / Grok 等落地 | 角色职责本身 |
+| 运行时绑定 | 如何在 Cursor / Codex / Grok 等落地 | 角色职责本身 |
 
 一次数字人任务包同时写明 `task_id`、`work_unit_id`、`actor_id`、数字人角色、执行态、当前 `runtime_id`，以及从角色表复制的 `core_skills` / `forbidden_skills`。可用 `taskPackageDefaults(roleId)`（`scripts/lib/digital-human-roles.mjs`）读取，禁止手写第二套技能包。`role.test-engineer` 的 core_skills 含 YSS / Alibaba 专项 skill，仅作为 `code-review` Standards 只读输入，不得写实现；finding 交实现者修复或回 实现合同编译器，审查者不得当场改代码。任务包 canonical Schema 为 `docs/process/schemas/digital-human-task-package.schema.json`，按 `contract.kind` 选择生命周期、切片实现或模板维护合同。
 
 ## 会签人
 
-`gate_policy.digital_human_review` 与 `dual_digital_human` 是「门禁 × 起草者 × 会签人」规则，不是门禁名单。主控按 `countersigners` 派会签任务。
+正式门禁的会签由 `gate_policy.digital_human_review` / `dual_digital_human` / `biological_human` 定义；内部专业审查由 `check_reviews` 定义，自动检查由 `automatic_checks` 定义。每项的起草者与会签人只读取 YAML，不在本文复制名单。
 
-| 门禁 / 工作单元 | 起草 | 会签 |
-|---|---|---|
-| `gate.prototype-reviewed` | `role.product-manager` | `role.frontend-engineer` |
-| `gate.openapi-draft-reviewed` | `role.backend-engineer` | `role.frontend-engineer` |
-| `gate.engineering-baseline-accepted` | （实现者） | `role.test-engineer` |
-| `gate.frontend-implementation-verified` | `role.frontend-engineer` | `role.test-engineer` |
-| `work-unit.code-review` | 实现者 | `role.test-engineer`（必须不同实例） |
-| `gate.spec-baseline-approved` | `role.requirements-manager` | `role.product-manager` |
-| `gate.openapi-frozen` | `role.backend-engineer` | `role.product-manager`、`role.test-engineer` |
-| `gate.user-confirmation` | 产品数字人提供建议 | 提问者或其明确指定的生物人负责人 |
-| `gate.release-ready` | — | 生物人（`role.biological-human`） |
-
-未列入表的门禁（含 `gate.design-reviewed`、`gate.architecture-reviewed`）走 `default_if_unlisted: biological-human`。
+Plan、产品设计、工程契约统一呈现适用检查后批准。`gate.delivery-accepted` 由测试角色进行交付验收，实际合并或发布仍须另有生物人授权。内部检查不独立请求用户决定；检查失败仍阻断聚合门禁。专业审查可在同一工作单元完成多个检查项，但必须保留逐项结论、资产摘要与独立执行者身份。
 
 会签写入 `docs/.scratch/<feature>/gates/<gate-id>-approval.yaml`，形状见 `docs/templates/approval-record-template.yaml`。恢复前运行 `scripts/verify-approval-record --require-approved`。错误会签只能得到 `blocked`，不能把门禁标成 `approved`。Checkpoint 里会签桶门禁为 `approved` 时必须有可读 `approval_ref`。
 
@@ -57,7 +45,7 @@
 | ID | 覆盖 | 落地方式 |
 |---|---|---|
 | `runtime.generic` | 任何能加载 `core_skills` 并接受任务包的 Agent | 通用会话 / 人设 / system prompt |
-| `runtime.skill-projection` | `yss-skill-registry.yaml` 的 `agent_runtime_roots`（claude、codex、cursor、pi、qoder、trae） | 投影技能 + subagent 任务包 |
+| `runtime.skill-projection` | `yss-skill-registry.yaml` 的 `agent_runtime_roots`（codex、cursor、pi） | 投影技能 + subagent 任务包 |
 | `runtime.grok` | Grok Bot | 持久 Bot、群聊或 1:1 交接；群超过 6 人改 1:1，不改逻辑协作组 |
 
 新增平台：先加 `runtimes` 条目，再写适配说明。不要把平台限制写进 `roles`。
@@ -71,7 +59,7 @@ Grok 专用操作见 `docs/templates/grok-bot-profile-template.md`。通用实
 | 运行时副作用审批 | 发消息、改生产、付款、删数据等工具动作 | 生物人（各平台自己的 Allow / 确认框） |
 | 生命周期会签 | `gate.*` 与独立 code review | 见 YAML `gate_policy` |
 
-会签写入 `docs/templates/approval-record-template.yaml`，带 `runtime_id`、`principal_ref` 与实例引用。起草者不得出现在会签人里。`gate.release-ready`、对外商务合同、运行时外部副作用，以及未列入会签表的 `gate.design-reviewed` / `gate.architecture-reviewed` 仍须生物人。
+会签写入 `docs/templates/approval-record-template.yaml`，带 `runtime_id`、`principal_ref` 与实例引用。起草者不得出现在会签人里。对外商务合同和运行时外部副作用仍须生物人；交付验收不授予这些权限。
 
 ## 实例化