create-yss-spec 3.3.0 → 3.3.3

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 草稿。此检查复用 `gate.plan-approved` 用户决定，不新增批准阶段，也不授权实现。
+
+检查 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`、`gate_id: gate.plan-approved`、与入口一致的 `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。
+- `internal_checks`：注册表 `check_impacts` 内部专业审查全部逐项记录。命中项须 `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`：边界为 `gate.plan-approved`，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/MATT-POCOCK-ENGINEERING-SKILLS.md

@@ -4,6 +4,7 @@ Matt Pocock Engineering Skills 提供轻量的澄清、实现、TDD、诊断和
 
 ## 进入与退出
 
+- `triage` 是显式 Issue / PR 兼容入口；普通请求由 `yss-product-lifecycle` 的 `request_triage` 合同处理。其 YSS 适配只回交取证、简报和状态建议；简报不替代批准的切片合同，状态调整由生命周期核验。详细规则见 [请求分诊协议](../../.agents/skills/yss-product-lifecycle/references/request-triage.md)。
 - Matt user-invoked 的 `grill-with-docs`、`to-spec`、`to-tickets` 和 `implement` 必须由用户显式启动，任何 skill 不得自动调用它们；YSS 生命周期只准备、校验和验收其结果。所有 Matt model-invoked skill 仍须遵守 `AGENTS.md` 的阶段、门禁和证据要求，并只能在生命周期允许的工作单元中调用。
 - `code-review` 保持唯一默认审查入口。YSS 适配把 Slice `required_skills`、`alibaba-java-code-style` 与命中的 `yss-ui` / `yss-domain` 等专项 skill 编译为 Standards 检查输入，并要求实现仓已有的 `pnpm` / `./mvnw` 机器检查；禁止再增加第二个通用审查 skill 或专用审查 Cloud 环境来代替这条接线。审查 finding 按编排合同分流：实现者修复后全轴复审，或合同 `stale` 后回 实现合同编译器；审查者不得写实现。
 - `template-source` 只执行模板维护流程，不生成具体产品 Spec、原型、OpenAPI 或垂直切片 Ticket。

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`，非法、缺失或不支持的身份直接进入迁移检查。
@@ -18,7 +20,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`。
@@ -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.discovery` | Discovery | 澄清问题、用户、约束和机会。 | 问题边界、关键假设和待确认项已记录。 |
+| `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,35 +24,44 @@
 
 ### 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.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.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 生命周期产物
 
 | 稳定 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` | 新模块或跨边界变化。 |

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

@@ -1,7 +1,7 @@
 {
   "schema_version": 1,
   "registry_id": "yss.lifecycle",
-  "semantic_sha256": "68c053060bb837fe4bc2b40d7a6ffcea1a53fc6b5e6b929eb0858824c657a15d",
+  "semantic_sha256": "38ec430630bbaee2c94f5d0d3dcd31f1d5481482b8cec52e44e983e4af6b638e",
   "published_ids": [
     "artifact.architecture-review",
     "artifact.data-architecture",
@@ -19,6 +19,7 @@
     "artifact.openapi-draft",
     "artifact.openapi-freeze-record",
     "artifact.parent-ticket",
+    "artifact.plan-record",
     "artifact.product-overview",
     "artifact.project-scaffold-contract",
     "artifact.prototype-confirmation",
@@ -33,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",
@@ -57,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",
@@ -76,6 +95,7 @@
     "gate.user-confirmation",
     "stage.discovery",
     "stage.entry-triage",
+    "stage.plan",
     "stage.product-design",
     "stage.spec-architecture",
     "stage.system-data-engineering",
@@ -94,6 +114,8 @@
     "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",