create-yss-spec 3.3.1 → 3.3.4

package/template/docs/process/frontend-backend-delivery.md

@@ -12,7 +12,7 @@
 
 后端每个交付包绑定一个窄业务切片。交付描述采用 `schemas/backend-delivery.schema.json`，包含战略包路径与摘要、切片规则/场景、OpenAPI operationId、冻结接口和后端 Slice Contract 的批准绑定、构建与部署身份、测试数据准备说明及验证证据。
 
-接口和 Slice Contract 的 `digest` 均为原文件字节 SHA-256，分别由既有 `gate.openapi-frozen` 和 `gate.slice-contract-approved` 的批准记录绑定。同包携带源角色政策及所需用户决定/批准证据；接收端按源政策验证，不能只填 `status: approved`。
+接口和 Slice Contract 的 `digest` 均为原文件字节 SHA-256，分别由当前 `gate.engineering-contract-approved` 和 `gate.slice-contract-approved` 的批准记录绑定。同包携带源角色政策及所需用户决定/批准证据；接收端按源政策验证，不能只填 `status: approved`。
 
 验证记录采用 `schemas/backend-delivery-verification.schema.json`，`subject_digest` 使用 `backendDeliveryBasis()`。实际命令、执行时间、零退出码与日志摘要必须齐备；契约验证逐条覆盖交付接口及场景的成功/失败结果。`supporting_files` 显式列出批准或用户决定的其余本地依赖；导出时通过临时源视图验证闭包，漏文件会失败。
 
@@ -67,6 +67,6 @@ scripts/verify-frontend-delivery --root <frontend> --slice <slice-id> <relative-
 
 前端 `frontend_cases` 的 `evidence_ref` 必须同时绑定 `evidence_digest`（原始文件字节 SHA-256）。用例内容变化后须更新接收记录并重编译依赖合同。
 
-OpenAPI Freeze 的来源门禁兼容综合模板 `gate.openapi-frozen` 与研发模板 `gate.openapi-freeze-confirmed`；仍严格校验来源角色策略及批准字节绑定，不允许其他门禁代替。每个交付范围至少包含一个带成功/失败验证的战略场景。
+OpenAPI Freeze 的来源门禁兼容当前综合模板 `gate.engineering-contract-approved`、历史冻结包 `gate.openapi-frozen` 与研发模板 `gate.openapi-freeze-confirmed`；仍严格校验来源角色策略及批准字节绑定，不允许其他门禁代替。每个交付范围至少包含一个带成功/失败验证的战略场景。
 
-生命周期中的稳定入口为 `gate.frontend-delivery-inputs-verified`，定义见各自 `lifecycle-registry.yaml`；角色表将它登记为 evidence_only，实际核验仍由脚本执行，不增设人工批准，也不替代 Slice Contract 的批准门禁。
+生命周期中的稳定入口为 `check.frontend-delivery-inputs-verified`，定义见各自 `lifecycle-registry.yaml`；角色表将它登记为 automatic_checks，实际核验仍由脚本执行，不增设人工批准，也不替代 Slice Contract 的批准门禁。

package/template/docs/process/github-workflows.md

@@ -0,0 +1,52 @@
+# GitHub CI 与发布前验证
+
+本合同区分模板源、项目实例和实现仓库的验证责任。生命周期门禁仍由 `lifecycle-registry.yaml` 定义；维护分级由 `maintenance-intensity.yaml` 和 `harness-process-tailoring.md` 定义；检查组、影响面和兼容触发路径只在 `template-verification-profiles.yaml` 维护。
+
+## 模板源
+
+| 入口 | 行为 | 结果边界 |
+|---|---|---|
+| PR：Template CI | 对合成 merge commit 执行 candidate；以事件 base SHA 计算影响面；核心或未映射路径升级全量 | 合并前机器检查，不宣布发布就绪 |
+| main push：Template CI | Node 24 全量 `scripts/verify-template` | 检查合并后的完整主干 |
+| Template compatibility | 工具影响 PR、main 全量及发布前执行 Node 22 工具测试、macOS vendor 一致性、Node 26 非阻断观察 | 独立于 Node 24 主验证，不再重复主验证中的工具测试 |
+| 手动：Template release verification | 输入完整 40 位模板 commit，精确检出；全量验证、生成器集成与兼容矩阵 | 产出证据，不打 tag、不创建 Release、不发布包 |
+
+模板工作流首先要求 `template-source`。全量检查初始化验证实际依赖的公开 gitlink 固定子模块，不追踪上游分支；兼容期私有 `yss-harness-dev-agent` 不参与主模板验证，也不要求 GitHub 默认 token 具备跨仓私有读取权限。工具依赖使用固定 pnpm 与 frozen lockfile；Node 24 为主验证环境，Python 3.12 / jsonschema 4.23.0 提供既有 schema 检查依赖。vendor 校验在临时目录重建并比较，不先覆盖受版本管理的 vendor。
+
+本地复验应把独立 Node 24 的 bin 加入 PATH 后直接运行验证入口；不要用带 `--package` 的 `npm exec` 包住整条验证链，其包配置可能被内部 npx 继承，改变实际执行的工具。
+
+PR 无工作流级 paths 过滤，始终产生 `Template checks` 汇总结果；兼容检查只有在计划要求时才能跳过。PR 同号的新运行取消旧运行；main 和发布前运行用 run ID 隔离。远程 required checks / 分支保护由仓库维护者配置，本轮不修改远程设置。
+
+## 发布版本与证据
+
+`Template release verification` 必须先存在于默认分支。输入 SHA 与实际 HEAD 必须一致；该提交也必须具备本合同对应的脚本和 action。调用工作流的版本与待验证 SHA 可能不同，Actions run 保留编排版本，报告记录被验证版本。
+
+`node .template-source/scripts/verify-template-release.mjs --commit <40位SHA> --output <仓库外绝对目录>` 要求干净的模板工作树、所有必需子模块已初始化且与 gitlink 一致；仅允许兼容期私有 `yss-harness-dev-agent` 未初始化。全量验证后，从 gitlink 对应的 `create-yss-spec` commit 创建隔离副本，用待发布模板重建快照；打包、干净安装、初始化、Skill 投影/锁校验，以及同步前后用户 `.github` 保留检查必须通过。不会改原始生成器工作树。既有其他专职生成器场景继续由全量 profile 执行。
+
+生成器消费者验收使用 `npm pack --ignore-scripts` 和本地 tarball 安装，属于包格式验证的受控工具例外；模板工具测试仍用 pnpm。不会执行 npm publish，也不使用浮动生成器版本或 latest 包。
+
+证据保存在 runner 临时目录，通过 artifact 上传：PR 保留计划、base/head/tested commit 与日志；发布保留 `release-verification.json`、每条命令实际退出码、日志、模板 SHA、生成器 SHA、子模块版本与新快照摘要；兼容 job 分别上传日志。失败时也尝试上传，准备阶段失败或 runner 丢失造成证据缺失时不得宣称通过。最终通过要求全量、集成和阻断兼容 job 均成功；Node 26 观察失败可见但不阻断。
+
+本地实现验证不等同于已执行 GitHub Actions。正式发布前仍须对实际待发布提交运行以上入口，由维护者明确发起实际发布。
+
+## 项目实例 CI 合同
+
+本轮仅定义合同，不安装实例 CI。现有生成器继续排除 `.github`；升级同步不得接管已有工作流。自动安装将作为独立能力处理。
+
+实例 CI 的后续实现须遵循：
+
+- 先验证根 `yss-project.yaml` 的 `project-instance` 身份，以及根 `CONTEXT.md` 合同。
+- 只检查已有流程资产的 schema、引用、摘要与状态真实性。Plan、Spec、设计和契约草案允许合入；不存在的未来阶段产物不是失败。
+- 对声称批准或正在流转的工作单元，按生命周期注册表检查其实际门禁、用户决定、当前资产和证据；不能以“草案允许合入”绕过流转条件。
+- 不运行上游技能分发、上游同步、模板生成器回归或模板发布检查，也不要求 `.template-source`、模板子模块或模板维护 checkpoint。
+- 业务构建、单元测试和交付验收归属已登记的实现仓库；按其接入合同引用证据，不在治理实例中猜测业务构建命令。
+
+## 平台事实依据
+
+- [GitHub 事件与 PR merge / workflow_dispatch 语义](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows)
+- [checkout 的 ref 和子模块选项](https://github.com/actions/checkout#usage)
+- [job outputs](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/pass-job-outputs)
+- [并发控制](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#concurrency)
+- [失败后 artifact 上传及隐藏路径规则](https://github.com/actions/upload-artifact/blob/v4/README.md)
+
+以上平台语义于 2026-09-10 使用 yss-research technical-evidence / quick 查阅官方文档；验证责任与裁剪策略来自本轮用户确认。

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

@@ -4,6 +4,8 @@
 
 安全 / 权限不单独分诊。需求或冻结资产没有明确改变相关行为时不登记、不解释 `not-applicable`、不增加门禁；明确改变时只按实际 UI、API、Backend、Data、High-risk 影响复用普通流程。SQL / DDL / 迁移、上传 / 下载等技术载体继续由其数据或 API 影响决定路线，不自动升级为安全专项。
 
+门禁与内部检查以 `lifecycle-registry.yaml` 的 `gates` / `checks` 为准。自动前置校验和就绪计算不产生独立批准；专业审查作为聚合门禁内部证据保留独立性。未命中项须有影响面依据和原因，命中项失败仍阻断。Plan、设计和工程资产在聚合边界统一呈现批准范围；相同资产版本、依据和范围复用原批准，相关变化仅使受影响批准失效。交付验收不代替实际合并、发布等外部动作授权。
+
 ## 1. 判定顺序
 
 1. 先读取 `yss-project.yaml`，非法、缺失或不支持的身份直接进入迁移检查。
@@ -27,25 +29,6 @@
 
 同一独立执行者可以在一个连续工作单元内完成相邻的实现动作，但不能替代独立审查者。阶段证据在集中 checkpoint 回写，至少包含：范围、变更文件、受影响仓库、验证命令及结果、阻塞项、人工审查点、Ticket 状态和下一步。
 
-## 4. 模板维护验证与审查强度分级
-
-本节只适用于 `template-source` 的模板、流程规则和共享 skill 维护，不降低 `project-instance` 的 Spec、OpenAPI Freeze、垂直切片或高风险工程门禁。强度由错误逃逸损失和是否改变 Agent 行为决定，不由文件所在目录单独决定。
-
-| 强度 | 权威触发项 | 最低验证证据 | Review |
-|---|---|---|---|
-| L1 | `maintenance-intensity.yaml` 的 `levels.L1.triggers` | 至少一项与变更直接相关的实际检查 | `self-check` 或显式 `human-checkpoint` |
-| L2 | `maintenance-intensity.yaml` 的 `levels.L2.triggers`，或该策略的 `default_level` | 修改前可失败的最小反例，以及本轮 fresh verification | 一名非实施者执行 `focused-independent` 聚焦审查；结论可内联 checkpoint |
-| L3 | `maintenance-intensity.yaml` 的 `levels.L3.triggers` | 维护者自检与本轮 fresh verification；正式发布另执行一次完整 `scripts/verify-template` | 日常不要求独立审查；发布证据由维护者提供 |
-
-判定规则：
-
-1. 等级只由 `maintenance-intensity.yaml` 计算；未给出 trigger 时使用该策略的 `default_level`，未知 trigger 必须更新策略后才可验证。
-2. 实施者可先分级，不要求 L1/L2 预批准；发现新影响时立即更新 `escalation`、重新分级并补齐证据。
-3. 发布、合并或阶段完成时按整体候选重新判定；不得把共同改变整体语义的修改拆成多个 L1/L2 规避 L3。
-4. RED 用于证明行为差异。L1 不人为构造失败；L2 可使用已有失败、最小 fixture 或现有测试修改前失败；L3 不再强制构造完整 RED/GREEN/REFACTOR/压力场景，记录维护者自检和 fresh verification 即可。
-5. 模板正式发布仍执行一次完整 `scripts/verify-template`，但不因 L3 额外冻结候选或派发正式独立审查。
-6. 模板维护与产品切片使用同一 finding 闭环：`violation` / 机器检查失败 / 适用行空白由实施者修复后重新验证并按本表强度复审；`drift` / `new_impacts` 升级影响面并重新分级，禁止在旧合同或旧 checkpoint 上继续编码。审查者不得写实现。未命中的条件项才 `not-applicable`；命中后不得豁免。
-
 ## 5. 上下文、反证与质量基线裁剪
 
 - Slice Contract 的 `common.context_plan` 是实现上下文的唯一轻量计划：先读 `CONTEXT.md`、已批准 Spec、当前合同和适用 ADR / 工程基线，再按影响面按需加载 references；达到最小充分证据后停止扩展。缺失权威上下文只能 `blocked` 或 `reroute`。
@@ -54,39 +37,3 @@
 - 只有命中高风险影响时才要求 Doubt-Driven 在途反证：API / 数据迁移、跨仓契约、发布回滚、实际改变的安全行为、生命周期或生成语义。反证写入现有决策 / 架构 / 契约 / 发布审查记录，不新增生命周期阶段；缺少反证、证据不足或残余风险未处理即阻断。
 - Wayfinder 是超长工作的可选规划模式，不改变阶段、门禁或 Ticket 状态；地图收敛后按 `wayfinder → handoff → to-spec` 返回主链。
 
-模板维护默认停在 `implementation-ready`，不自动冻结候选或派发审查。需要独立审查时显式提升到 `review-ready`；完成独立审查和最终完整门禁后才能成为 `release-ready`。三个核验入口由 `docs/process/template-verification-profiles.yaml` 统一定义：
-
-- `scripts/verify-template-fast`：按 Git 影响面运行快速检查；未映射路径或核心核验资产变化时 fail-safe 升级为完整门禁。
-- `scripts/verify-template-candidate`：运行命中影响面、候选完整性和审查合同检查；PR 默认使用该入口。
-- `scripts/verify-template`：执行不可裁剪的完整发布门禁；首次正式冻结前和最终发布前各运行一次，修复内循环不重复运行。
-
-新模板维护 checkpoint 使用 schema v2；历史 schema v1 继续只读兼容，不批量迁移。L1/L2 可直接写入主 Ticket 或集中 checkpoint，不要求新增独立文档：
-
-```yaml
-schema_version: 2
-intensity: L1 | L2 | L3
-classification_reason: <分级理由>
-triggers: [<可观察触发项>]
-changed_assets: [<路径或资产引用>]
-verification_evidence:
-  - kind: relevant-check | counterexample | red | green | refactor | pressure-scenario | fresh-verification | focused-independent-review | formal-independent-review
-    command: <本轮实际命令或可读取证据引用>
-    result: pass
-review_mode: self-check | human-checkpoint | focused-independent | formal-independent # L2 需聚焦审查证据；L3 使用 self-check，历史 formal 记录只读兼容
-escalation: none | <升级原因和原等级>
-target_state: implementation-ready | review-ready | release-ready
-current_state: implementation-ready | review-ready | release-ready | needs-human
-verification_profile: fast | candidate | release
-review_round: 0 | 1 | 2
-candidate_digest: null | <sha256>
-```
-
-使用 `scripts/verify-maintenance-checkpoint <file>` 或通过 stdin 传入 YAML / JSON 做只读校验。`implementation-ready` 必须使用 fast、`review_round: 0` 且不带候选摘要；`review-ready` 必须绑定候选、candidate / 首次完整门禁和三轴任务包证据；`release-ready` 还必须绑定正式独立审查与最终完整门禁。第二轮仍有未关闭的 `violation`、`drift` 或 `new_impacts` 时，使用 `scripts/evaluate-maintenance-review-round` 形成新的 `needs-human` checkpoint，禁止自动开启第三轮。触发项 ID 与最低等级只由 `docs/process/maintenance-intensity.yaml` 维护；校验器消费该策略。未知触发项必须先更新该权威策略和场景，不能静默接受。
-
-进入 `review-ready` 后使用 `scripts/prepare-maintenance-review` 一次生成 Standards、Spec、Lead 三个任务包。任务包必须明确 `candidate_kind`、`candidate_requirement`、`candidate_digest`、审查轴、允许读取路径、报告写入路径和适用规则。候选变化会使旧报告失效；`judgement-call` 进入后续 backlog，不得在审查中升级为未由既有单一事实来源支持的新硬要求。
-
-Worktree 候选使用 `scripts/capture-maintenance-candidate --output <目录>` 捕获。新候选目录必须位于 `.template-source/evidence/maintenance/`、在捕获前不存在，并通过 staging 原子落盘；检查时该目录必须恰好包含 `candidate-manifest.yaml`、`candidate.bin` 和 `tracked.diff`。所有 untracked 路径、mode、类型和内容均已按 `yss-worktree-candidate-v1` 帧写入单一 `candidate.bin`，不得再生成逐文件 `untracked-content/000xxx` 副本。审查任务包、报告和旧候选目录可用重复的 `--exclude <仓库相对路径>` 与实现字节分离，但排除路径只允许位于 `.template-source/evidence/maintenance/`，并全部写入 manifest；`scripts/**`、`docs/**` 或其他实现 / 权威资产不能通过该接口排除。`scripts/inspect-maintenance-candidate` 只读复核摘要、清单、规范三文件和外部 `tracked.diff`；历史候选的逐文件引用继续兼容。
-
-固定远程模板输入可使用 `scripts/cache-template-commit --repository <remote-url> --commit <40位commit>`。缓存键仅由 URL 与 commit 构成，每次命中仍复核 metadata 和 Git object hash；缓存目录不进入 Git 或正式证据。
-
-`focused-independent-review` 与 `formal-independent-review` 的 `command` 必须引用可读取的审查结论。L3 日常新记录使用 checkpoint 的 `self-check` 证据，不创建独立审查记录；历史 L3 正式记录继续使用 `docs/process/schemas/maintenance-review-record.schema.json` 并只读兼容，仍须带 `legacy_formal_review: true`、审查身份和明确通过结论。审查请求、实施者自述、否定裁决、伪造或非规范候选流、无效任务包、未关闭 findings 或 symlink 越界证据都会被拒绝。可用 `scripts/verify-maintenance-review-record` 单独校验历史记录。

package/template/docs/process/implementation-repo-integration.md

@@ -76,21 +76,3 @@ apps/
 | frontend-only | frontend repo、分支、lint / type-check / build | `not-applicable`：无前端运行时代码 |
 | contract-only | OpenAPI Draft / Freeze、消费者确认 | `not-applicable`：无 OpenAPI 变化 |
 
-## 3. 本变更的跨仓库合同
-
-- 模板仓库负责 `yss-project.yaml`、流程事实源、迁移指南、技能投影、模板校验脚本和快照可发布状态。
-- CLI 仓库负责 `attach`、`sync`、受管 manifest、快照 commit、metadata、迁移计划、备份 / 回滚、端到端测试和用户说明。
-- CLI 只写研发管理资产；不得创建或覆盖前后端运行时代码，不删除目标 `.git`，也不创建、覆盖或删除 `.gitmodules` 与 gitlink。
-- 模板 commit 必须是 40 位不可变提交；开发测试可通过 `YSS_SPEC_TEMPLATE_REF` 覆盖，正式发布不得跟随浮动 `main`。
-
-## 4. Fresh verification 与 checkpoint
-
-模板仓库至少执行：
-
-```bash
-scripts/sync-skills --check
-scripts/update-skill-lock --check
-scripts/verify-template
-```
-
-CLI 仓库至少执行固定 commit 的 `YSS_SPEC_TEMPLATE_REF=<pinned-commit> npm test`、`npm pack --dry-run`，并在解包后的 CLI 上验证 init、attach、sync、迁移冲突和回滚。共同发布前记录两个仓库的 commit、模板快照 hash、测试结果、独立审查结论和 rollback 路径。

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

@@ -3,14 +3,14 @@
 本文是模板仓库与模板实例共享的生命周期派生阅读视图。结构化事实源是 `docs/process/lifecycle-registry.yaml`；本文解释主阶段、条件门禁、必须持久化的产物和退出标准。具体项目只有在触发条件命中时才执行对应门禁。
 
 <!-- lifecycle-registry:structure:start -->
-> 此结构区由 `docs/process/lifecycle-registry.yaml` 生成。当前为 `shadow` 模式：它校验结构和派生文档，不改变运行时状态 schema 或人工批准语义。
+> 此结构区由 `docs/process/lifecycle-registry.yaml` 生成。当前为 `active` 模式：正式门禁、内部检查和派生文档共同消费此事实源。
 
 ## 1. 主阶段
 
 | 稳定 ID | 阶段 | 目标 | 退出标准 |
 |---|---|---|---|
 | `stage.entry-triage` | 入口分诊 | 确认仓库身份、问题范围和影响面。 | yss-project.yaml 合法，影响面和最近可信阶段可解释。 |
-| `stage.plan` | Plan（战略规划） | 确认目标、业务边界、关键规则、MVP / 非目标、优先级和交接责任，为 Spec 提供战略输入；按影响面探索并复用仍有效的结论。 | 用户确认规划结论，命中的战略与阶段决策门禁通过；影响业务边界、关键规则或 MVP 的问题已解决，其他未决项有责任人和解决时点；下游可进入 Spec，不代表可实现。 |
+| `stage.plan` | Plan（战略规划） | 确认目标、业务边界、关键规则、MVP / 非目标、优先级和交接责任，为 Spec 提供战略输入；按影响面探索并复用仍有效的结论。 | 命中的战略与阶段决策检查通过，用户统一批准当前 Plan；影响业务边界、关键规则或 MVP 的问题已解决，其他未决项有责任人和解决时点；下游可进入 Spec，不代表可实现。 |
 | `stage.spec-architecture` | Spec / 功能架构 | 固化解决方案和功能边界。 | Spec 基线和功能边界可审查。 |
 | `stage.product-design` | 产品设计 | 在存在产品设计影响时校准页面流和状态。 | 命中的设计门禁通过；未命中项记录 not-applicable 及原因。 |
 | `stage.system-data-engineering` | 系统 / 数据架构与工程契约 | 固化系统、数据、工程基线和 API 契约。 | 受影响工程契约冻结或记录无 API 影响；required 脚手架证据齐全。 |
@@ -24,26 +24,35 @@
 
 ### 2.1 条件门禁
 
-| 稳定 ID | 门禁 | 所属阶段 | 触发条件 | 前置门禁 | 必须留下的证据 |
+| 稳定 ID | 门禁 | 所属阶段 | 触发条件 | 前置门禁 / 检查 | 必须留下的证据 |
 |---|---|---|---|---|---|
-| `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.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.plan-approved` | Plan 批准 | `stage.plan` | Plan 结论进入 Spec；汇总战略检查后仅确认一次当前规划范围。 | `check.domain-strategy-approved`、`check.stage-decision-package-approved` | `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` |
-| `gate.user-confirmation` | 用户确认 | `stage.product-design` | 产品设计影响尚未被人工确认。 | 无 | `evidence.prototype-confirmation` |
-| `gate.openapi-draft-reviewed` | OpenAPI Draft Review | `stage.system-data-engineering` | 有 API 影响且 Draft 已生成。 | 无 | `evidence.openapi-draft-review` |
-| `gate.design-reviewed` | 设计审查 | `stage.system-data-engineering` | API 或架构影响。 | 无 | `evidence.design-review-result` |
-| `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` |
-| `gate.release-ready` | 发布就绪 | `stage.verification-release-retrospective` | 合并、发布或阶段完成。 | `gate.frontend-implementation-verified` | `evidence.fresh-verification`、`evidence.checkpoint-and-rollback` |
+| `gate.product-design-approved` | 产品设计批准 | `stage.product-design` | 存在产品设计影响；独立原型评审与交付物验证通过后确认最终原型。 | `check.prototype-reviewed`、`check.prototype-verified` | `evidence.prototype-confirmation` |
+| `gate.engineering-contract-approved` | 工程契约批准 | `stage.system-data-engineering` | 存在 API、架构或工程基线影响；完成适用专业审查后统一批准，有 API 影响时同时冻结当前 OpenAPI。 | `check.openapi-draft-reviewed`、`check.design-reviewed`、`check.architecture-reviewed`、`check.engineering-baseline-accepted`、`check.openapi-frozen` | `evidence.approval-record`、`evidence.fresh-verification` |
+| `gate.slice-contract-approved` | 切片合同批准 | `stage.ticket-formalization` | 主控在已授权范围内批准已持久化且当前的垂直切片合同；不代替就绪计算。 | 无 | `evidence.contract-approval` |
+| `gate.delivery-accepted` | 交付验收 | `stage.verification-release-retrospective` | 实现交付验收；汇总独立审查、Fresh Verification 和回滚证据，不授予合并或发布权限。 | `check.frontend-implementation-verified` | `evidence.fresh-verification`、`evidence.checkpoint-and-rollback` |
+
+### 内部检查与自动前置条件
+
+检查失败仍阻断。专业审查记录作为聚合门禁证据，不单独请求用户批准；自动检查通过不授权实现或发布。
+
+| 稳定 ID | 检查 | 阶段 | 触发条件 |
+|---|---|---|---|
+| `check.frontend-delivery-inputs-verified` | 前端联合输入核验 | `stage.system-data-engineering` | 专职前端 profile 或显式 frontend_delivery 绑定的任务启动、恢复、合同编译、实现和验证；实际执行 scripts/verify-frontend-delivery，输入就绪不等于实现获批。 |
+| `check.repository-identity-valid` | 仓库身份校验 | `stage.entry-triage` | 每次进入流程。 |
+| `check.domain-strategy-approved` | 业务边界与规则评审 | `stage.plan` | 需要确定业务板块、业务责任区、统一业务词汇、协作关系或关键规则。 |
+| `check.stage-decision-package-approved` | 阶段决策包评审 | `stage.plan` | Plan 到 Spec 入口需要稳定的阶段决策合同。 |
+| `check.prototype-reviewed` | 原型评审 | `stage.product-design` | 命中产品设计影响，且低保真页面、流程、状态或 API 反推需要独立评审。 |
+| `check.prototype-verified` | 原型交付物验证 | `stage.product-design` | 产品设计影响需要通过 H1/H2 原型交付物进行视觉或流程校准；真实组件验证留到前端实现阶段。 |
+| `check.openapi-draft-reviewed` | OpenAPI Draft Review | `stage.system-data-engineering` | 有 API 影响且 Draft 已生成。 |
+| `check.design-reviewed` | 设计审查 | `stage.system-data-engineering` | API 或架构影响。 |
+| `check.openapi-frozen` | OpenAPI 冻结准备 | `stage.system-data-engineering` | 有 API 影响；确认待冻结版本、Draft 审查和契约绑定，工程契约批准后原子冻结同一版本。 |
+| `check.engineering-baseline-accepted` | 工程基线 | `stage.system-data-engineering` | 后端、前端或高风险工程变化。 |
+| `check.architecture-reviewed` | 架构审查 | `stage.system-data-engineering` | 高风险或跨边界变化。 |
+| `check.implementation-repositories-ready` | 实现仓库准备就绪 | `stage.system-data-engineering` | 后端或前端交付面进入 Ticket 正式化；未命中的交付面须记录带原因的 not-applicable。 |
+| `check.slice-ready-for-agent` | 垂直切片实现就绪 | `stage.ticket-formalization` | 垂直切片具备直接实现条件。 |
+| `check.frontend-implementation-verified` | 前端实现还原验证 | `stage.verification-release-retrospective` | UI 影响切片完成实现并准备合并、发布或阶段完成。 |
 
 ### 2.2 生命周期产物
 

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

@@ -1,7 +1,7 @@
 {
   "schema_version": 1,
   "registry_id": "yss.lifecycle",
-  "semantic_sha256": "96fcbcb858eed45ba228d87c75804f28ccb464b1963c0d23be348ade094bac01",
+  "semantic_sha256": "38ec430630bbaee2c94f5d0d3dcd31f1d5481482b8cec52e44e983e4af6b638e",
   "published_ids": [
     "artifact.architecture-review",
     "artifact.data-architecture",
@@ -34,6 +34,20 @@
     "artifact.tactical-design",
     "artifact.technical-design",
     "artifact.vertical-slice-ticket",
+    "check.architecture-reviewed",
+    "check.design-reviewed",
+    "check.domain-strategy-approved",
+    "check.engineering-baseline-accepted",
+    "check.frontend-delivery-inputs-verified",
+    "check.frontend-implementation-verified",
+    "check.implementation-repositories-ready",
+    "check.openapi-draft-reviewed",
+    "check.openapi-frozen",
+    "check.prototype-reviewed",
+    "check.prototype-verified",
+    "check.repository-identity-valid",
+    "check.slice-ready-for-agent",
+    "check.stage-decision-package-approved",
     "evidence.antd-cli-validation",
     "evidence.approval-record",
     "evidence.browser-prototype-verification",
@@ -58,14 +72,18 @@
     "evidence.technical-design-review",
     "evidence.yss-skill-execution-result",
     "gate.architecture-reviewed",
+    "gate.delivery-accepted",
     "gate.design-reviewed",
     "gate.domain-strategy-approved",
     "gate.engineering-baseline-accepted",
+    "gate.engineering-contract-approved",
     "gate.frontend-delivery-inputs-verified",
     "gate.frontend-implementation-verified",
     "gate.implementation-repositories-ready",
     "gate.openapi-draft-reviewed",
     "gate.openapi-frozen",
+    "gate.plan-approved",
+    "gate.product-design-approved",
     "gate.prototype-reviewed",
     "gate.prototype-verified",
     "gate.release-ready",

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

@@ -1,14 +1,36 @@
 schema_version: 1
 registry_id: yss.lifecycle
-status: shadow
+status: active
 description: >-
-  YSS 生命周期结构化事实源。Phase 1 以 shadow/check 方式派生结构表并校验漂移，
-  不切换任何运行时状态 schema 或人工批准语义。
+  YSS 生命周期结构化事实源。聚合门禁与内部检查分别登记，运行时查询、批准核验和派生阅读视图共同消费本注册表。
 id_policy:
-  pattern: '^(stage|gate|artifact|work-unit|evidence)\.[a-z0-9][a-z0-9-]*$'
+  pattern: '^(stage|gate|check|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, stage.discovery, artifact.discovery-record, work-unit.discovery-opportunity, work-unit.discovery-requirements]
+  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
+    - gate.frontend-delivery-inputs-verified
+    - gate.repository-identity-valid
+    - gate.domain-strategy-approved
+    - gate.stage-decision-package-approved
+    - gate.prototype-reviewed
+    - gate.prototype-verified
+    - gate.user-confirmation
+    - gate.openapi-draft-reviewed
+    - gate.design-reviewed
+    - gate.openapi-frozen
+    - gate.engineering-baseline-accepted
+    - gate.architecture-reviewed
+    - gate.implementation-repositories-ready
+    - gate.slice-ready-for-agent
+    - gate.frontend-implementation-verified
+    - gate.release-ready
 
 stages:
   - id: stage.entry-triage
@@ -18,12 +40,14 @@ stages:
   - id: stage.plan
     name: Plan（战略规划）
     goal: 确认目标、业务边界、关键规则、MVP / 非目标、优先级和交接责任，为 Spec 提供战略输入；按影响面探索并复用仍有效的结论。
-    exit_criteria: 用户确认规划结论，命中的战略与阶段决策门禁通过；影响业务边界、关键规则或 MVP 的问题已解决，其他未决项有责任人和解决时点；下游可进入 Spec，不代表可实现。
+    exit_criteria: 命中的战略与阶段决策检查通过，用户统一批准当前 Plan；影响业务边界、关键规则或 MVP 的问题已解决，其他未决项有责任人和解决时点；下游可进入 Spec，不代表可实现。
     spec_entry:
-      required_checks: [goals, scope_and_priority, boundaries_and_rules, open_questions, handoff, context_reconciliation, grill_exit]
+      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
+        gate.plan-approved: plan
+      check_impacts:
+        check.domain-strategy-approved: domain_strategy
+        check.stage-decision-package-approved: stage_decision
   - id: stage.spec-architecture
     name: Spec / 功能架构
     goal: 固化解决方案和功能边界。
@@ -123,101 +147,60 @@ evidence:
     description: 可追溯的变更边界、发布记录和恢复动作。
 
 gates:
-  - id: gate.frontend-delivery-inputs-verified
-    name: 前端联合输入核验
-    stage: stage.system-data-engineering
-    trigger: 专职前端 profile 或显式 frontend_delivery 绑定的任务启动、恢复、合同编译、实现和验证；实际执行 scripts/verify-frontend-delivery，输入就绪不等于实现获批。
-    evidence: [evidence.fresh-verification]
-  - id: gate.repository-identity-valid
-    name: 仓库身份校验
-    stage: stage.entry-triage
-    trigger: 每次进入流程。
-    evidence: [evidence.repository-identity-check]
-  - id: gate.domain-strategy-approved
-    name: DDD 战略设计批准
+  - id: gate.plan-approved
+    name: Plan 批准
     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.plan
-    trigger: Plan 到 Spec 入口需要稳定的阶段决策合同。
-    evidence: [evidence.stage-decision-package, evidence.approval-record]
-    requires_gates: [gate.domain-strategy-approved]
+    trigger: Plan 结论进入 Spec；汇总战略检查后仅确认一次当前规划范围。
+    evidence:
+      - evidence.approval-record
+    requires_checks:
+      - check.domain-strategy-approved
+      - check.stage-decision-package-approved
   - id: gate.spec-baseline-approved
     name: Spec 基线批准
     stage: stage.spec-architecture
     trigger: 新功能、行为变化或范围扩大进入 Spec 基线。
-    evidence: [evidence.approval-record]
-  - id: gate.prototype-reviewed
-    name: 原型评审
-    stage: stage.product-design
-    trigger: 命中产品设计影响，且低保真页面、流程、状态或 API 反推需要独立评审。
-    evidence: [evidence.prototype-review-result]
-  - id: gate.prototype-verified
-    name: 原型交付物验证
-    stage: stage.product-design
-    trigger: 产品设计影响需要通过 H1/H2 原型交付物进行视觉或流程校准；真实组件验证留到前端实现阶段。
-    evidence: [evidence.prototype-profile-decision, evidence.prototype-deliverable-verification]
-  - id: gate.user-confirmation
-    name: 用户确认
+    evidence:
+      - evidence.approval-record
+    requires_checks: []
+  - id: gate.product-design-approved
+    name: 产品设计批准
     stage: stage.product-design
-    trigger: 产品设计影响尚未被人工确认。
-    evidence: [evidence.prototype-confirmation]
-  - id: gate.openapi-draft-reviewed
-    name: OpenAPI Draft Review
-    stage: stage.system-data-engineering
-    trigger: 有 API 影响且 Draft 已生成。
-    evidence: [evidence.openapi-draft-review]
-  - id: gate.design-reviewed
-    name: 设计审查
+    trigger: 存在产品设计影响；独立原型评审与交付物验证通过后确认最终原型。
+    evidence:
+      - evidence.prototype-confirmation
+    requires_checks:
+      - check.prototype-reviewed
+      - check.prototype-verified
+  - id: gate.engineering-contract-approved
+    name: 工程契约批准
     stage: stage.system-data-engineering
-    trigger: API 或架构影响。
-    evidence: [evidence.design-review-result]
-  - id: gate.openapi-frozen
-    name: OpenAPI Freeze
-    stage: stage.system-data-engineering
-    trigger: API 进入实现。
-    evidence: [evidence.approval-record]
-  - id: gate.engineering-baseline-accepted
-    name: 工程基线
-    stage: stage.system-data-engineering
-    trigger: 后端、前端或高风险工程变化。
-    evidence: [evidence.fresh-verification]
-  - id: gate.architecture-reviewed
-    name: 架构审查
-    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]
+    trigger: 存在 API、架构或工程基线影响；完成适用专业审查后统一批准，有 API 影响时同时冻结当前 OpenAPI。
+    evidence:
+      - evidence.approval-record
+      - evidence.fresh-verification
+    requires_checks:
+      - check.openapi-draft-reviewed
+      - check.design-reviewed
+      - check.architecture-reviewed
+      - check.engineering-baseline-accepted
+      - check.openapi-frozen
   - id: gate.slice-contract-approved
-    name: Slice Implementation Contract 批准
+    name: 切片合同批准
     stage: stage.ticket-formalization
-    trigger: Agent 进入实现；脚手架完成后每个后续生成代码工作单元。
-    evidence: [evidence.contract-approval]
-  - id: gate.slice-ready-for-agent
-    name: 垂直切片实现就绪
-    stage: stage.ticket-formalization
-    trigger: 垂直切片具备直接实现条件。
-    evidence: [evidence.contract-approval, evidence.approval-record]
-  - id: gate.frontend-implementation-verified
-    name: 前端实现还原验证
-    stage: stage.verification-release-retrospective
-    trigger: UI 影响切片完成实现并准备合并、发布或阶段完成。
-    evidence: [evidence.frontend-implementation-verification]
-  - id: gate.release-ready
-    name: 发布就绪
+    trigger: 主控在已授权范围内批准已持久化且当前的垂直切片合同；不代替就绪计算。
+    evidence:
+      - evidence.contract-approval
+    requires_checks: []
+  - id: gate.delivery-accepted
+    name: 交付验收
     stage: stage.verification-release-retrospective
-    trigger: 合并、发布或阶段完成。
-    evidence: [evidence.fresh-verification, evidence.checkpoint-and-rollback]
-    requires_gates: [gate.frontend-implementation-verified]
+    trigger: 实现交付验收；汇总独立审查、Fresh Verification 和回滚证据，不授予合并或发布权限。
+    evidence:
+      - evidence.fresh-verification
+      - evidence.checkpoint-and-rollback
+    requires_checks:
+      - check.frontend-implementation-verified
 
 artifacts:
   - id: artifact.impact-assessment
@@ -479,3 +462,99 @@ work_units:
     input: 已审查候选、发布窗口和回滚点。
     output: 发布/回滚证据和复盘记录。
     completion: 人工发布裁决、fresh verification 和治理回流均完成。
+checks:
+  - id: check.frontend-delivery-inputs-verified
+    name: 前端联合输入核验
+    stage: stage.system-data-engineering
+    trigger: 专职前端 profile 或显式 frontend_delivery 绑定的任务启动、恢复、合同编译、实现和验证；实际执行 scripts/verify-frontend-delivery，输入就绪不等于实现获批。
+    evidence:
+      - evidence.fresh-verification
+  - id: check.repository-identity-valid
+    name: 仓库身份校验
+    stage: stage.entry-triage
+    trigger: 每次进入流程。
+    evidence:
+      - evidence.repository-identity-check
+  - id: check.domain-strategy-approved
+    name: 业务边界与规则评审
+    stage: stage.plan
+    trigger: 存在 DDD 战略设计影响或需要确定领域边界、统一语言和核心规则。
+    public_name: 业务边界与规则评审
+    public_trigger: 需要确定业务板块、业务责任区、统一业务词汇、协作关系或关键规则。
+    evidence:
+      - evidence.domain-strategy-review
+      - evidence.approval-record
+  - id: check.stage-decision-package-approved
+    name: 阶段决策包评审
+    stage: stage.plan
+    trigger: Plan 到 Spec 入口需要稳定的阶段决策合同。
+    evidence:
+      - evidence.stage-decision-package
+      - evidence.approval-record
+    requires_checks:
+      - check.domain-strategy-approved
+  - id: check.prototype-reviewed
+    name: 原型评审
+    stage: stage.product-design
+    trigger: 命中产品设计影响，且低保真页面、流程、状态或 API 反推需要独立评审。
+    evidence:
+      - evidence.prototype-review-result
+  - id: check.prototype-verified
+    name: 原型交付物验证
+    stage: stage.product-design
+    trigger: 产品设计影响需要通过 H1/H2 原型交付物进行视觉或流程校准；真实组件验证留到前端实现阶段。
+    evidence:
+      - evidence.prototype-profile-decision
+      - evidence.prototype-deliverable-verification
+  - id: check.openapi-draft-reviewed
+    name: OpenAPI Draft Review
+    stage: stage.system-data-engineering
+    trigger: 有 API 影响且 Draft 已生成。
+    evidence:
+      - evidence.openapi-draft-review
+  - id: check.design-reviewed
+    name: 设计审查
+    stage: stage.system-data-engineering
+    trigger: API 或架构影响。
+    evidence:
+      - evidence.design-review-result
+  - id: check.openapi-frozen
+    name: OpenAPI 冻结准备
+    stage: stage.system-data-engineering
+    trigger: 有 API 影响；确认待冻结版本、Draft 审查和契约绑定，工程契约批准后原子冻结同一版本。
+    evidence:
+      - evidence.openapi-draft-review
+  - id: check.engineering-baseline-accepted
+    name: 工程基线
+    stage: stage.system-data-engineering
+    trigger: 后端、前端或高风险工程变化。
+    evidence:
+      - evidence.fresh-verification
+  - id: check.architecture-reviewed
+    name: 架构审查
+    stage: stage.system-data-engineering
+    trigger: 高风险或跨边界变化。
+    evidence:
+      - evidence.design-review-result
+  - id: check.implementation-repositories-ready
+    name: 实现仓库准备就绪
+    stage: stage.system-data-engineering
+    trigger: 后端或前端交付面进入 Ticket 正式化；未命中的交付面须记录带原因的 not-applicable。
+    evidence:
+      - evidence.implementation-repository-preparation
+      - evidence.fresh-verification
+    requires_checks:
+      - check.engineering-baseline-accepted
+  - id: check.slice-ready-for-agent
+    name: 垂直切片实现就绪
+    stage: stage.ticket-formalization
+    trigger: 垂直切片具备直接实现条件。
+    evidence:
+      - evidence.contract-approval
+      - evidence.fresh-verification
+  - id: check.frontend-implementation-verified
+    name: 前端实现还原验证
+    stage: stage.verification-release-retrospective
+    trigger: UI 影响切片完成实现并准备合并、发布或阶段完成。
+    evidence:
+      - evidence.frontend-implementation-verification