create-yss-spec 3.4.3 → 3.4.4

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

@@ -41,9 +41,9 @@ Matt phase boundary 是工作阶段之间的上下文决策，不是新的生命
 
 所有命中项目必须达到 `existing-and-onboarded` 或 `initialized-and-verified`，未命中的交付面必须有带原因的 `not-applicable`。聚合结果、Manifest、验证和 onboarding 证据必须可读且当前；否则 `check.implementation-repositories-ready` 阻断 Ticket 正式化。旧实例恢复时保留已有 Ticket，但将相关 Ticket / Slice Contract 标为 `blocked` / `stale` 并返回本工作单元。
 
-`prototype_confirmation` 通过后，先判断实现仓库登记中的 backend `scaffold_status`。当状态为 `required` 时，在工程基线中先完成脚手架架构选择：Agent 按领域复杂度给出 `domain-driven` / `layered-mvc` 推荐和依据，本体选择作为子项目预填默认值，用户通过批量表确认全部项目或逐项覆盖。选择写入 `scaffold-architecture-decisions.yaml`；处于 `undecided`、`recommended`、`awaiting-user-decision` 或 `stale` 时必须阻断，不得默认 DDD，也不得在生成器内交互。
+`prototype_confirmation` 通过后，先判断实现仓库登记中的 backend `scaffold_status`。当状态为 `required` 时，在进入 DDD / MVC 分支设计前完成 `gate.backend-architecture-platform-approved`：Agent 按领域复杂度给出 `domain-driven` / `layered-mvc` 推荐和依据，并从 `docs/engineering/backend-platforms.json` 展示可选平台的精确 Spring Boot 补丁版本与 Java 版本；用户在同一次决定中确认架构与平台。本体选择作为子项目预填默认值，用户可批量确认全部项目或逐项覆盖。选择写入 `scaffold-architecture-decisions.yaml`；处于 `undecided`、`recommended`、`awaiting-user-decision` 或 `stale` 时必须阻断，不得默认 DDD、MVC 或 Spring Boot 版本，也不得在生成器内交互。既有工程使用当前 `existing-registration` 的架构及固定工程基线/POM 中的实际 Spring Boot 版本，核验摘要和支持状态后将该门禁记录为 `not-applicable`，不重复询问；架构转换或平台升级另行立项。
 
-选择达到 `lifecycle-approved` 且 digest 当前后，先完成批准且当前的 Technical Design、Data Architecture Decision v1 和 API Contract Decision v1。数据与 API 均按影响强制：命中则绑定设计及评审闭包，未命中则绑定评估、明确原因和证据。再由 `yss-implementation-contract-compiler` 编译脚手架 schema v4 `controlled-generation` 工作单元合同。顺序为：工程基线与架构推荐 → 用户确认与选择持久化 → 技术/数据/API 设计 → 工程合同原子批准 → 脚手架合同持久化 → `domain-driven` 使用 `yss-ddd-scaffold-generator` 或 `layered-mvc` 使用 `yss-layered-mvc-scaffold-generator` → 对应基线/Manifest v4 校验 → 仓库准备 v2 → 实现合同编译器业务合同重编译。`existing` / `initialized` 不重复生成；架构转换必须单独立项。schema v3 只允许历史 Manifest 的只读恢复审计，不得新生成。
+`gate.backend-architecture-platform-approved` 通过、选择达到 `lifecycle-approved` 且 digest 当前后，才可进入对应的 DDD 战术设计或 MVC 技术设计分支，再完成批准且当前的 Technical Design、Data Architecture Decision v1 和 API Contract Decision v1。数据与 API 均按影响强制：命中则绑定设计及评审闭包，未命中则绑定评估、明确原因和证据。再由 `yss-implementation-contract-compiler` 编译脚手架 schema v4 `controlled-generation` 工作单元合同。顺序为：工程基线与架构/平台推荐 → 用户确认与选择持久化 → DDD / MVC 分支设计 → 技术/数据/API 设计 → 工程合同原子批准 → 脚手架合同持久化 → `domain-driven` 使用 `yss-ddd-scaffold-generator` 或 `layered-mvc` 使用 `yss-layered-mvc-scaffold-generator` → 对应基线/Manifest v4 校验 → 仓库准备 v2 → 实现合同编译器业务合同重编译。`existing` / `initialized` 不重复生成；架构转换或平台升级必须单独立项。schema v3 只允许历史 Manifest 的只读恢复审计，不得新生成。
 
 脚手架工作单元必须使用结构化 schema v4 合同 JSON，除工程身份、架构决定、Profile、模块闭包、允许路径和验证命令外，必须以原始字节 digest 绑定 Technical Design、Data Architecture Decision v1、API Contract Decision v1 和 `gate.engineering-contract-approved` 的真实批准记录。API `required` 时 Draft、Validation、独立 Review、Freeze 与工程批准必须绑定同一 OpenAPI YAML 字节；`not-applicable` 时不得携带空占位资产。生成器在创建输出目录前读取并校验所有引用、版本、主体、gate、批准范围、资产绑定与摘要；虚构 URI、字符串自证或仅有 `status: approved` 均无效。三条 Wrapper 命令必须由受控工作单元真实执行并留存证据。非空目标、`--force`、旧项目迁移和模板升级均阻断。脚手架不得生成 Controller、Repository 实现、SQL、领域行为、业务规则、状态机、权限、事务、复杂查询、错误映射、用户可见行为或示例业务 API；`empty-scaffold-verified` 仍不是 `ready-for-agent`。
 

package/template/.pi/skills/yss-product-lifecycle/references/state-model.md

@@ -55,7 +55,7 @@ AND Slice Implementation Contract 已由生命周期编排器批准并持久化
 AND Slice Implementation Contract 的 `ticket_ref` 与 `vertical_slice_ticket_ref` 完全一致
 AND 当前工作单元消费的 contract_id/version 与最新批准版本一致
 AND Backend Slice Implementation Contract（后端适用）和 Build Architecture Checklist 已完成
-AND backend 影响且 scaffold_status=required 时，脚手架架构选择已由用户确认并达到 lifecycle-approved、兼容 schema v3 或统一 schema v4 合同与 Manifest 当前、对应 DDD / Layered MVC 基线、Wrapper 验证和 实现合同编译器重编译均已完成
+AND backend 影响且 scaffold_status=required 时，`gate.backend-architecture-platform-approved` 已由用户同时确认 DDD / MVC 与精确 Spring Boot 版本并达到 lifecycle-approved、统一 schema v4 合同与 Manifest 当前、对应 DDD / Layered MVC 基线、Wrapper 验证和 实现合同编译器重编译均已完成；既有工程只核验并复用当前登记值
 AND frontend 影响且无已有工程时，统一 schema v4 Project Scaffold Contract 已批准、持久化且当前，模板 bundled manifest 摘要或 Git commit 已锁定，`pnpm install --frozen-lockfile` 与工程基线要求的 lint/type-check/build 已实际通过
 AND 所有后续生成代码均绑定主 YSS skill、依赖闭包、允许写路径、预期证据和 YSS Skill Execution Result
 AND UI 影响切片的前端实现还原计划已通过 schema 校验、`template=false`、`status=approved`，且基线引用可读取

package/template/.pi/skills/yss-product-lifecycle/references/user-decisions.md

@@ -71,6 +71,6 @@ finding 分为 `requirement-violation/missing-evidence/important-risk/suggestion
 
 实施就绪和派发必须同时提供 `user_decisions`、`slice_contract_ref` 与 `vertical_slice_ticket_ref`。Worker 任务包通过 `user_decisions` 传递记录，不能只声明 `ready_for_agent=true`。
 
-脚手架 `user_confirmation` 新增 `user_decision_ref/decision_subject_ref`，主体为生成前的决策输入快照；当前范围至少包含项目 ID、确认的架构和 `decision_inputs_digest`。先获得真实回复，再由生命周期批准生成合同；不能回到生成器内提问。
+脚手架 `user_confirmation` 使用 `gate.backend-architecture-platform-approved`，`user_decision_ref/decision_subject_ref` 的主体为分支设计前的决策输入快照；当前范围至少包含项目 ID、确认的架构、平台 Profile、精确 Spring Boot 补丁版本、Java 版本和 `decision_inputs_digest`。先获得真实回复，门禁通过后才能进入 DDD 战术设计或 MVC 技术设计，再由生命周期批准生成合同；不能回到设计 skill 或生成器内提问。既有工程核验并复用当前登记值，该门禁记录为 `not-applicable`；升级或架构转换不得冒充复用。
 
 Git commit/push、外部动作仍分别检查已有授权和其范围。用户对一个具体动作的明确自然语言授权可整理成结构化记录，不必再次要求填写内部字段；生命周期批准不隐含其他动作授权。

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

@@ -50,7 +50,7 @@ Plan 的目标与退出条件由 `docs/process/lifecycle-registry.yaml` 持有
 - 业务边界与规则设计是本类事实的权威资产，方案决策包只通过内部字段 `domain_strategy_ref` 引用它。两个合同的 `context_snapshot.context_ref` 必须精确为仓库根 `CONTEXT.md`，禁止子目录、`CONTEXT-MAP.md`、绝对路径和 Markdown 伪锚点。
 - 进入 `check.domain-strategy-approved` 或 `check.stage-decision-package-approved` 的外部决策证据必须引用通过校验的 `yss-research` `evidence-audited` 研究包；研究包只提供证据，不得直接修改本技能资产或批准门禁。
 - `stage_decision_package` 必须经过 `draft → ready-for-human → approved`；起草者不得自签。
-- 内部专业审查为 `check.domain-strategy-approved` 和 `check.stage-decision-package-approved`，汇入 `gate.plan-approved` 一次确认，实际状态由 `yss-product-lifecycle` 维护；阶段包批准引用必须通过 `scripts/verify-approval-record`，不得用不可读路径或聊天确认替代。
+- 内部专业审查为 `check.domain-strategy-approved` 和 `check.stage-decision-package-approved`，汇入 `gate.plan-approved` 一次确认，实际状态由 `yss-product-lifecycle` 维护。新 Plan 流程由产品经理在一个 `review-bundle.plan` 任务中逐项给出结论，并以相同 `review_session_id` 汇总到 Plan 门禁；未命中项只记录有依据的 `not-applicable`。资产的 `approval_ref` 可指向该 bundle 中自己的唯一结论；验证器按 check ID 选择，旧单条批准继续兼容。
 - 下游只能消费批准且版本当前的包；发现语义冲突返回 `drift` / `new_impacts`，不得静默修改上游。
 
 ## 结果合同

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

@@ -10,6 +10,8 @@
 - `concept_candidates`、`invariants`、`context_snapshot`；
 - `downstream_mapping`、`evidence_refs`、`approval`。
 
+`approval.approval_ref` 可以指向 `check.domain-strategy-approved` 单条记录，或指向包含该唯一结论的 `review-bundle.plan`；验证器按 check ID 选择结论并核对 `approval.approver`。bundle 中另一项检查的结论不能替代本检查。
+
 ## 业务责任区
 
 每个业务责任区声明内部 `context_id`、职责边界、非职责、业务板块分类、责任人、关键场景和本地词汇引用。`context_id` 是稳定身份，由 Agent 维护；不得使用代码模块、数据库 schema 或菜单路径替代。

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

@@ -9,7 +9,7 @@
 - `context_snapshot`：只引用根 `CONTEXT.md`，并绑定结构化术语身份、全文摘要和引用集摘要；
 - `domain_strategy_ref`：领域战略合同的稳定 ID、版本、digest 和批准状态；
 - UI/API/Data/Backend/Frontend/跨仓/高风险影响面布尔值；
-- 每个消费者能力的稳定 `mapping_id`、领域来源 ID、传播方式、重新批准条件、证据引用和批准记录。`approval.approval_ref` 必须指向可读取且通过 `scripts/verify-approval-record` 的 `gate.stage-decision-package-approved` 会签记录；`approval.approver` 必须与记录中的 `role_id` 一致。
+- 每个消费者能力的稳定 `mapping_id`、领域来源 ID、传播方式、重新批准条件、证据引用和审查记录。`approval.approval_ref` 必须指向可读取的 `check.stage-decision-package-approved` 单条审查记录，或指向包含该唯一结论的 `review-bundle.plan`；验证器按 check ID 选择并校验，`approval.approver` 必须与选中结论中的 `role_id` 一致。该检查结论汇入 `gate.plan-approved`，不单独暂停用户。
 
 ## 未决项规则
 

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

@@ -3,7 +3,7 @@ import { readFile } from "node:fs/promises";
 import process from "node:process";
 import { parseArgs } from "node:util";
 import { parseDocument } from "../../../../scripts/vendor/yaml.mjs";
-import { loadApprovalRecord, resolveApprovalRef, validateApprovalRecordFile } from "../../../../scripts/lib/approval-record.mjs";
+import { loadApprovalRecord, resolveApprovalRef, validateApprovalRecord } from "../../../../scripts/lib/approval-record.mjs";
 import { verifyContextSnapshot } from "../../../../scripts/lib/context-contract.mjs";
 
 import { extractTraceability } from "../../../../scripts/lib/strategic-handoff-rules.mjs";
@@ -196,8 +196,8 @@ function validate(data, contextRoot) {
     if (approval.current_version !== data.domain_version) errors.push("approval.current_version 必须等于 domain_version");
     try {
       const approvalPath = resolveApprovalRef(approval.approval_ref);
-      validateApprovalRecordFile(approvalPath, { requireApproved: true });
-      const record = loadApprovalRecord(approvalPath);
+      const record = loadApprovalRecord(approvalPath, "check.domain-strategy-approved");
+      validateApprovalRecord(record, { requireApproved: true });
       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

@@ -5,7 +5,7 @@ import { resolve } from "node:path";
 import process from "node:process";
 import { parseArgs } from "node:util";
 import { parseDocument } from "../../../../scripts/vendor/yaml.mjs";
-import { loadApprovalRecord, resolveApprovalRef, validateApprovalRecordFile } from "../../../../scripts/lib/approval-record.mjs";
+import { loadApprovalRecord, resolveApprovalRef, validateApprovalRecord } from "../../../../scripts/lib/approval-record.mjs";
 import { verifyContextSnapshot } from "../../../../scripts/lib/context-contract.mjs";
 
 const required = ["schema_version", "stage_decision_id", "package_version", "status", "problem_statement", "target_users", "mvp", "non_goals", "success_criteria", "test_seams", "confirmed_decisions", "assumptions", "constraints", "unresolved_items", "context_snapshot", "domain_strategy_ref", "impact_assessment", "downstream_mapping", "evidence_refs", "approval"];
@@ -129,8 +129,8 @@ async function validate(data, contextRoot) {
   if (data.status === "approved" && nonEmpty(approval.approval_ref)) {
     try {
       const approvalPath = resolveApprovalRef(approval.approval_ref);
-      validateApprovalRecordFile(approvalPath, { requireApproved: true });
-      const record = loadApprovalRecord(approvalPath);
+      const record = loadApprovalRecord(approvalPath, "check.stage-decision-package-approved");
+      validateApprovalRecord(record, { requireApproved: true });
       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/run-scenarios.mjs

@@ -201,6 +201,39 @@ try {
   const packagePass = run(packageValidator, packageFile, temporaryRoot);
   if (packagePass.status !== 0) throw new Error(`valid v3 stage decision package should pass: ${packagePass.stderr}`);
 
+  const bundleFile = join(temporaryRoot, "plan-review-bundle.json");
+  const bundledDomainValue = parseYaml(domainSource);
+  bundledDomainValue.approval.approval_ref = bundleFile;
+  const bundledDomainSource = JSON.stringify(bundledDomainValue, null, 2);
+  const bundledDomainFile = join(temporaryRoot, "domain-strategy-bundled.yaml");
+  await writeFile(bundledDomainFile, bundledDomainSource);
+  const bundledPackageValue = parseYaml(packageSource);
+  bundledPackageValue.domain_strategy_ref.persisted_ref = "domain-strategy-bundled.yaml";
+  bundledPackageValue.domain_strategy_ref.digest = digestYaml(bundledDomainSource);
+  bundledPackageValue.approval.approval_ref = bundleFile;
+  const bundledPackageSource = JSON.stringify(bundledPackageValue, null, 2);
+  const bundledPackageFile = join(temporaryRoot, "stage-decision-bundled.yaml");
+  await writeFile(bundledPackageFile, bundledPackageSource);
+  await writeFile(bundleFile, JSON.stringify({
+    schema_version: 1,
+    kind: "review-bundle",
+    bundle_id: "review-bundle.plan",
+    task_id: "task.plan-review.supplier-admission",
+    work_unit_id: "work-unit.plan-requirements",
+    review_session_id: "review-session.plan.supplier-admission",
+    role_id: "role.product-manager",
+    runtime_id: "runtime.generic",
+    principal_ref: "instance:role.product-manager",
+    reviews: [
+      { schema_version: 1, gate_id: "check.domain-strategy-approved", decision: "approved", actor_kind: "digital-human", role_id: "role.product-manager", runtime_id: "runtime.generic", principal_ref: "instance:role.product-manager", drafter_role_id: "role.requirements-manager", drafter_principal_ref: "instance:role.requirements-manager", subject_ref: bundledDomainFile, subject_digest: digestYaml(bundledDomainSource).slice(7), approval_scope: ["feature.supplier-admission"], evidence_refs: [bundledDomainFile] },
+      { schema_version: 1, gate_id: "check.stage-decision-package-approved", decision: "approved", actor_kind: "digital-human", role_id: "role.product-manager", runtime_id: "runtime.generic", principal_ref: "instance:role.product-manager", drafter_role_id: "role.requirements-manager", drafter_principal_ref: "instance:role.requirements-manager", subject_ref: bundledPackageFile, subject_digest: digestYaml(bundledPackageSource).slice(7), approval_scope: ["feature.supplier-admission"], evidence_refs: [bundledPackageFile] }
+    ]
+  }, null, 2));
+  const bundledDomainPass = run(validator, bundledDomainFile, temporaryRoot);
+  if (bundledDomainPass.status !== 0) throw new Error(`domain strategy should select its conclusion from Plan review-bundle: ${bundledDomainPass.stderr}`);
+  const bundledPackagePass = run(packageValidator, bundledPackageFile, temporaryRoot);
+  if (bundledPackagePass.status !== 0) throw new Error(`stage decision should select its conclusion from Plan review-bundle: ${bundledPackagePass.stderr}`);
+
   const v2Stage = toV2Stage(packageSource, digestYaml(v2DomainSource));
   const v2StageFile = join(temporaryRoot, "stage-decision-v2.yaml");
   await writeFile(v2StageFile, JSON.stringify(v2Stage, null, 2));

package/template/.pi/skills/yss-tactical-design/SKILL.md

@@ -9,7 +9,7 @@ description: 在 YSS 技术分析阶段将批准的战略领域输入细化为
 
 ## 适用边界
 
-- 由 `yss-technical-design` 在已确认 `domain-driven` 的技术设计分支中调用；传统 MVC 使用 `yss-mvc-design`，不得按状态或一致性影响单独推断为 DDD。
+- 由 `yss-technical-design` 在已确认 `domain-driven` 的技术设计分支中调用；新建后端必须先通过 `gate.backend-architecture-platform-approved`，由用户在同一次决定中确认 DDD / MVC 与精确 Spring Boot 版本。传统 MVC 使用 `yss-mvc-design`；既有工程直接核验并复用当前登记架构及固定工程基线/POM 中的实际 Spring Boot 版本，不重复询问。不得按状态、一致性影响、目录或默认值单独推断为 DDD。
 - 输入必须是版本当前的 Spec、功能架构、战略 DDD、状态矩阵、OpenAPI Draft / Freeze、ADR 和工程约束。若输入来自 Strategic Design Handoff，必须先用 `scripts/verify-strategic-context-import` 验证历史 v3/v4 或当前 v5 的 `source_context_snapshot` / `context_delta` 已对账到目标仓根 `CONTEXT.md`，对应的 prototype 或 existing UI baseline 可读取且摘要当前，并且目标侧 `context_reconciliation` 有效；未完成时不得开始战术建模。
 - 默认将结果写入系统概要设计 / 数据架构中的 Tactical DDD Check；聚合、状态机、一致性或持久化映射复杂到无法清楚表达时，才升级为独立战术设计文档。
 - 没有聚合、状态、不变量、一致性或领域边界影响时返回 `not-applicable` 及原因，不生成空设计。

package/template/.pi/skills/yss-technical-design/SKILL.md

@@ -17,7 +17,7 @@ description: 在 YSS 技术分析中统一承接需求与战略输入，按已
 
 先读根 `CONTEXT.md`、已批准且当前的 Spec、业务规则、关键场景、适用的 API 契约、ADR 和工程约束。没有 API 或其他专项影响时记录有依据的不适用，不生成占位设计。
 
-按项目绑定架构选择的来源及摘要。新工程复用 `scaffold-architecture-decisions.yaml` 的用户确认决定，先确认再进入分支，后续脚手架消费同一决定；既有工程沿用已登记架构，架构转换另行立项。只有 `domain-driven` 和 `layered-mvc` 两种架构族，不能从目录推断或默认 DDD。具体 Profile 及模块边界消费技能注册表与 `docs/agents/backend-architecture-profiles.md`。
+按项目绑定架构选择的来源及摘要。新工程必须先通过 `gate.backend-architecture-platform-approved`：Agent 展示 DDD / MVC 推荐依据及平台清单中的精确 Spring Boot、Java 版本，用户在同一次决定中确认两项内容；决定持久化到 `scaffold-architecture-decisions.yaml`，再进入对应分支，后续脚手架消费同一决定。既有工程核验并沿用当前登记架构及固定工程基线/POM 中的实际 Spring Boot 版本，该门禁记录为 `not-applicable`，不重复询问；架构转换或平台升级另行立项。只有 `domain-driven` 和 `layered-mvc` 两种架构族，不能从目录推断或默认 DDD、MVC 或 Spring Boot 版本。具体 Profile 及模块边界消费技能注册表与 `docs/agents/backend-architecture-profiles.md`。
 
 - `domain-driven`：调用 `yss-tactical-design`，补齐适用的战略领域输入。
 - `layered-mvc`：调用 `yss-mvc-design`，不要求战略 DDD、聚合、值对象、Domain Event 或 DDD Gateway。

package/template/.pi/skills/yss-technical-design/references/technical-design-contract.md

@@ -5,7 +5,7 @@
 ## 共同头
 
 - `schema_version: 2`、`technical_design_id: technical-design.<name>`、`version: vN`、`status`、`context_ref: CONTEXT.md`。
-- `architecture`：`family`、`project_id`、`source_kind: scaffold-decision | existing-registration`、`decision_ref`、`decision_digest`。新项目引用正式且 current 的脚手架决定，所选项目必须已由用户确认；既有登记引用当前 `project_id` 和 `architecture_identity.architecture_family`，也可从登记的 `repositories` 数组按项目解析。架构来源变化须重新绑定和审查，不能改合同字段冒充用户改选。
+- `architecture`：`family`、`project_id`、`source_kind: scaffold-decision | existing-registration`、`decision_ref`、`decision_digest`。新项目引用正式且 current 的脚手架决定，所选项目必须已通过 `gate.backend-architecture-platform-approved`，用户决定同时绑定 DDD / MVC、平台 Profile、精确 Spring Boot 与 Java 版本；既有登记引用当前 `project_id` 和 `architecture_identity.architecture_family`，并从固定工程基线/POM 复用实际 Spring Boot 版本，不重新询问。架构或平台来源变化须重新绑定和审查，不能改合同字段冒充用户改选或升级。
 - `inputs`：每行 `{kind, ref, version, digest}`，kind 为 context/spec/rules/scenarios/api/adr/engineering/strategic；至少包含根 CONTEXT.md 与 Spec。适用的工程/API 约束同样绑定。无 API 影响理由记录在需求或工程输入中。DDD 另须 strategic 输入，MVC 不要求。
 - `source_items`：无战略包时从批准需求提取稳定规则和场景 `{source_id, kind: rule | scenario, critical, source_ref}`。source_ref 必须对应 inputs，不复制源正文成为第二事实源。
 - `traceability`：逐项对应 source_items。沿用 `tactical_refs` 字段名以兼容承接协议，其值在新合同中可指向 MVC 用例、规则或 DDD 对象；其他字段与战略承接 rows 相同。implemented 仅表示设计承接已落实，不表示代码已实现。

package/template/.pi/skills/yss-technical-design/tests/run-scenarios.mjs

@@ -56,7 +56,7 @@ try {
   ddd.design.aggregate_catalog[0].api_exposure = 'public'; ddd.digest = technicalDigest(ddd);
   await assert.rejects(() => validate(ddd), /internal-only/); checks++;
   const scaffold = mvcFixture(root);
-  const decision = attachScaffoldDecisionFixture(path.join(root, 'decision-evidence'), { project_id: 'example', status: 'user-confirmed', confirmed_architecture: 'layered-mvc', decision_inputs_digest: `sha256:${'1'.repeat(64)}`, user_confirmation: { confirmation_ref: 'user-message', confirmed_by: 'user' } });
+  const decision = attachScaffoldDecisionFixture(path.join(root, 'decision-evidence'), { project_id: 'example', status: 'user-confirmed', confirmed_architecture: 'layered-mvc', platform_profile: 'spring-boot-2.7-jdk8', decision_inputs_digest: `sha256:${'1'.repeat(64)}`, user_confirmation: { confirmation_ref: 'user-message', confirmed_by: 'user' } });
   const record = { status: 'current', template: false, decisions: [decision] };
   const recordFile = path.join(root, 'decision.json');
   writeFileSync(recordFile, JSON.stringify(record));

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

@@ -185,6 +185,7 @@ gate_policy:
     gate.plan-approved: [role.product-manager]
     gate.spec-baseline-approved: [role.product-manager]
     gate.product-design-approved: [role.frontend-engineer, role.test-engineer]
+    gate.backend-architecture-platform-approved: [role.backend-engineer]
     gate.engineering-contract-approved: [role.backend-engineer, role.test-engineer]
     implementation-scope: [role.test-engineer]
   default_if_unlisted: biological-human
@@ -218,6 +219,7 @@ gate_policy:
   product_digital_human_with_biological_veto: []
   biological_human:
     - gate.product-design-approved
+    - gate.backend-architecture-platform-approved
   automatic_checks:
     - check.repository-identity-valid
     - check.frontend-delivery-inputs-verified
@@ -269,7 +271,7 @@ user_decision_policy:
   continuation:
     capability: approved-scope-continuation-v1
     source_boundary: delivery-scope
-    boundaries: [gate.plan-approved, gate.spec-baseline-approved, gate.product-design-approved, gate.engineering-contract-approved, implementation-scope]
+    boundaries: [gate.plan-approved, gate.spec-baseline-approved, gate.product-design-approved, gate.backend-architecture-platform-approved, gate.engineering-contract-approved, implementation-scope]
     material_changes: [business-scope, acceptance, contract-commitments, authorization, risk-acceptance, quality, external-commitments]
     unknown_change: blocked
     external_requirements: preserve-project-policy
@@ -279,6 +281,7 @@ user_decision_policy:
     - gate.plan-approved
     - gate.spec-baseline-approved
     - gate.product-design-approved
+    - gate.backend-architecture-platform-approved
     - gate.engineering-contract-approved
   work_units:
     work-unit.service-project-initialization: scaffold-choice
@@ -290,6 +293,7 @@ user_decision_policy:
     work-unit.prototype-design:
       - gate.product-design-approved
     work-unit.technical-analysis:
+      - gate.backend-architecture-platform-approved
       - gate.engineering-contract-approved
   conditional_decisions: [ scaffold-choice, external-input, new-authorization, risk-acceptance ]
   waiting_allows: independent-work-only

package/template/docs/architecture/templates/engineering-baseline-review-template.md

@@ -21,7 +21,7 @@ owner: ai
 | YSS skill 路由 |  |  |  |
 | `prototype_confirmation` |  |  | UI 影响时必须是已确认；无 UI 影响记录 `not-applicable` 及原因 |
 | 后端脚手架登记 / 生成结果 |  |  | 记录 `scaffold_status`、目标目录、生成器输入、预期文件和 Execution Result |
-| 后端脚手架架构选择 |  |  | `scaffold-architecture-decisions.yaml` 的 decision_id、用户确认引用和 digest |
+| 后端架构与平台选择 |  |  | 新建工程记录 `gate.backend-architecture-platform-approved`、DDD / MVC、精确 Spring Boot / Java、decision_id、用户确认引用和 digest；既有工程记录登记值复用证据 |
 
 ## 2. 工程影响判断
 
@@ -34,11 +34,11 @@ owner: ai
 | 是否影响统一响应 / DTO / VO / Query / CMD | 是 / 否 |  |
 | 是否存在高风险变更、人工确认项或回滚约束 | 是 / 否 |  |
 
-## 2.2 脚手架架构选择
+## 2.2 后端架构与平台选择
 
-| 项目 | Agent 推荐及依据 | 继承来源 | 用户确认 | architecture_family | Profile / 模块闭包 | decision_id / digest |
-|---|---|---|---|---|---|---|
-|  |  |  |  | `domain-driven` / `layered-mvc` |  |  |
+| 项目 | 工程类型 | Agent 推荐及依据 | 继承来源 | 用户确认 / 复用 | architecture_family | Spring Boot / Java | Profile / 模块闭包 | gate / decision_id / digest |
+|---|---|---|---|---|---|---|---|---|
+|  | 新建 / 既有 |  |  |  | `domain-driven` / `layered-mvc` | 精确补丁 / Java |  |  |
 
 > 聚合不变量、复杂状态机、跨聚合一致性、Domain Event 或复杂并发任一强信号命中时推荐 DDD；强信号均不存在且以 CRUD、报表、数据转换或外部编排为主时推荐 MVC。用户可覆盖软性推荐，但必须记录原因；不支持的 Profile 直接阻断。
 
@@ -88,7 +88,7 @@ owner: ai
 | 检查项 | 结论 | 证据 / 备注 |
 |---|---|---|
 | 原型确认已完成，或已记录 `not-applicable` 原因 | 是 / 否 / 不适用 | `prototype_confirmation` |
-| `scaffold_status=required` 时已由 Agent 推荐、用户确认并持久化 architecture decision，随后由实现合同编译器编译 schema v3 合同并经生命周期批准，再使用对应 DDD / MVC 生成器 | 是 / 否 / 不适用 | decision_id / digest、contract_id / contract_version、实现合同编译器 draft、批准引用、持久化引用和 Manifest v3 |
+| `scaffold_status=required` 时已由 Agent 推荐并通过 `gate.backend-architecture-platform-approved` 同时确认 DDD / MVC 与精确 Spring Boot 版本，随后编译 schema v4 合同并经生命周期批准，再使用对应生成器；既有工程核验复用登记值 | 是 / 否 / 不适用 | gate、decision_id / digest、platform_configuration、contract_id / contract_version、批准引用、持久化引用和 Manifest v4 |
 | 脚手架生成结果只包含工程结构、配置和机械模板 | 是 / 否 | 禁止生成业务行为 |
 | 生成器输入、预期文件和实际 `./mvnw validate` / `./mvnw test` / `./mvnw package` 已留证 | 是 / 否 | 每条命令记录 `exit_code`、`duration_ms`、stdout/stderr 引用和执行时间；打印命令不算证据 |
 | `yss-backend-scaffold-parent` 基线校验已完成并重新进入 `yss-implementation-contract-compiler` | 是 / 否 / 不适用 |  |

package/template/docs/engineering/backend-platforms.md

@@ -4,7 +4,7 @@ DDD 和 Layered MVC 共同消费 `backend-platforms.json`。平台定义是候
 
 ## 用户选择
 
-运行 `scripts/backend-platforms` 展示 Boot 精确补丁、Java、YSS 父 POM/BOM、可选状态和阻塞原因。生命周期编排器将平台与架构放在同一次用户决定中。缺少选择时询问；已有批准且当前的选择只展示摘要并复用。独立子项目可继承或覆盖，也可一次确认明确列出的多个项目。同一 Maven Reactor 不混用平台。
+运行 `scripts/backend-platforms` 展示 Boot 精确补丁、Java、YSS 父 POM/BOM、可选状态和阻塞原因。新建后端在进入 DDD / MVC 分支设计前必须通过 `gate.backend-architecture-platform-approved`；生命周期编排器将平台与架构放在同一次用户决定中。缺少选择时询问；已有批准且当前的选择只展示摘要并复用。既有工程核验并复用登记的 `architecture_identity` 与固定工程基线/POM 中的实际 Spring Boot 版本，该门禁记录为 `not-applicable`，不重复询问；平台升级另行立项。独立子项目可继承或覆盖，也可一次确认明确列出的多个项目。同一 Maven Reactor 不混用平台。
 
 候选为 2.7.18 / Java 8、3.5.16 / Java 17 或 21、4.1.1 / Java 17 或 21。3.5 和 4.1 推荐 Java 17。新增补丁必须先通过组合验证，生成合同不接受 `x`、版本范围或 `latest`。
 

package/template/docs/process/existing-ui-baseline.md

@@ -18,7 +18,7 @@
 
 Handoff v5 必须声明 `ui_baseline_kind`。原型分支继续保留 prototype、visual baseline 与离线原型要求；既有 UI 分支只使用 `source.existing_ui_baseline_ref`，不允许混入或伪填原型字段。`package_export` v2 显式绑定相同类型。
 
-既有 UI 引用的 digest 是 `existing-ui-baseline.json` **原字节摘要**。`package_export.approvals.existing_ui_baseline_ref` 沿用源 profile 已有的产品确认门禁（主模板为 `gate.product-design-approved`，战略专职 profile 为 `gate.user-confirmation`）与 `digest_kind: sha256-bytes`；该门禁必须存在于源 `user_decision_policy.gates`。批准主体必须是同一 manifest，使用现有真实用户决定校验。人工确认需在最终可审阅字节准备完成后获得；不得复用旧原型批准、仅改 status 或自签批准。该门禁的原始回复随交接闭包携带。
+既有 UI 引用的 digest 是 `existing-ui-baseline.json` **原字节摘要**。`package_export.approvals.existing_ui_baseline_ref` 使用 `gate.product-design-approved` 与 `digest_kind: sha256-bytes`；该门禁必须存在于源 `user_decision_policy.gates`。批准主体必须是同一 manifest，使用现有真实用户决定校验。人工确认需在最终可审阅字节准备完成后获得；不得复用旧原型批准、仅改 status 或自签批准。旧包中的 `gate.user-confirmation` 仅按历史模式读取，不得作为当前输入继续流转。该门禁的原始回复随交接闭包携带。
 
 既有 manifest 的 `status` 表达准备状态，展示后保持其原字节不变。`ready-for-human` 清单可在当前批准记录验证通过后交接；有效批准由现有批准记录及真实用户决定持有，不要求确认后把清单改为 `approved`。结构验证不授予批准，导出、包验证和接收均须核验完整批准链。确认后任何字节改写（包括只改 status）仍使原决定失效。旧原型分支仍要求原型自身为 `approved`，不转换历史批准。
 

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

@@ -13,7 +13,7 @@
 | `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 脚手架证据齐全。 |
+| `stage.system-data-engineering` | 系统 / 数据架构与工程契约 | 固化系统、数据、工程基线和 API 契约。 | 新建后端已由用户确认 DDD / MVC 与精确 Spring Boot 版本，既有工程已核验并复用登记值；受影响工程契约冻结或记录无 API 影响；required 脚手架证据齐全。 |
 | `stage.ticket-formalization` | Ticket 正式化 | 将冻结范围拆为可追踪的父 Ticket 和垂直切片。 | 工作单元窄、依赖清晰、验收和测试 seam 可执行。 |
 | `stage.vertical-slice-implementation` | 垂直切片实现 | 以批准合同驱动 TDD 实现和跨仓库协作。 | 允许写路径、禁止模式、证据和验证命令全部满足。 |
 | `stage.verification-release-retrospective` | 验证 / 发布 / 复盘 | 完成 fresh verification、发布和回顾。 | 所有命中门禁通过，人工审查点已完成，checkpoint 可追溯。 |
@@ -29,7 +29,8 @@
 | `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.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.backend-architecture-platform-approved` | 后端架构与平台批准 | `stage.system-data-engineering` | 新建后端工程进入技术设计分支前，由用户在同一次决定中确认 domain-driven / layered-mvc 和精确 Spring Boot 版本；既有工程核验并复用当前登记架构及固定工程基线中的实际 Spring Boot 版本，记录 not-applicable，不重复询问。 | 无 | `evidence.approval-record` |
+| `gate.engineering-contract-approved` | 工程契约批准 | `stage.system-data-engineering` | 存在 API、架构或工程基线影响；组合适用专业审查后统一批准并核验授权，有 API 影响时同时冻结当前 OpenAPI；范围内细化不重复请求用户确认。 | `gate.backend-architecture-platform-approved`、`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` |
 

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

@@ -1,7 +1,7 @@
 {
   "schema_version": 1,
   "registry_id": "yss.lifecycle",
-  "semantic_sha256": "6d994e65718fd614c03519fe72377206bba11f5bc77da7aed0e0f1cd792cee88",
+  "semantic_sha256": "38afc53efe827596c036133c826acd818c8dab85fab0f430d62a60cf62005196",
   "published_ids": [
     "artifact.architecture-review",
     "artifact.data-architecture",
@@ -72,6 +72,7 @@
     "evidence.technical-design-review",
     "evidence.yss-skill-execution-result",
     "gate.architecture-reviewed",
+    "gate.backend-architecture-platform-approved",
     "gate.delivery-accepted",
     "gate.design-reviewed",
     "gate.domain-strategy-approved",

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

@@ -59,7 +59,7 @@ stages:
   - id: stage.system-data-engineering
     name: 系统 / 数据架构与工程契约
     goal: 固化系统、数据、工程基线和 API 契约。
-    exit_criteria: 受影响工程契约冻结或记录无 API 影响；required 脚手架证据齐全。
+    exit_criteria: 新建后端已由用户确认 DDD / MVC 与精确 Spring Boot 版本，既有工程已核验并复用登记值；受影响工程契约冻结或记录无 API 影响；required 脚手架证据齐全。
   - id: stage.ticket-formalization
     name: Ticket 正式化
     goal: 将冻结范围拆为可追踪的父 Ticket 和垂直切片。
@@ -172,6 +172,13 @@ gates:
     requires_checks:
       - check.prototype-reviewed
       - check.prototype-verified
+  - id: gate.backend-architecture-platform-approved
+    name: 后端架构与平台批准
+    stage: stage.system-data-engineering
+    trigger: 新建后端工程进入技术设计分支前，由用户在同一次决定中确认 domain-driven / layered-mvc 和精确 Spring Boot 版本；既有工程核验并复用当前登记架构及固定工程基线中的实际 Spring Boot 版本，记录 not-applicable，不重复询问。
+    evidence:
+      - evidence.approval-record
+    requires_checks: []
   - id: gate.engineering-contract-approved
     name: 工程契约批准
     stage: stage.system-data-engineering
@@ -179,6 +186,8 @@ gates:
     evidence:
       - evidence.approval-record
       - evidence.fresh-verification
+    requires_gates:
+      - gate.backend-architecture-platform-approved
     requires_checks:
       - check.openapi-draft-reviewed
       - check.design-reviewed
@@ -417,9 +426,9 @@ work_units:
   - id: work-unit.technical-analysis
     name: 技术分析与契约冻结
     scope: project-instance
-    input: Spec、原型、API/数据/工程影响面。
-    output: OpenAPI、数据架构、按确认架构形成的 DDD / MVC 技术设计合同、工程基线、架构审查和 Slice 合同草案。
-    completion: 命中契约已冻结；无 API 影响有可读记录；所有后端交付均有批准且当前的 Technical Design；数据影响为真时数据架构已批准，否则有可核验的不适用记录；架构、规则与场景承接无未解释冲突；gate.engineering-contract-approved 通过。
+    input: Spec、原型、API/数据/工程影响面；新建后端的架构与平台候选，或既有工程当前登记的架构与平台配置。
+    output: 新建后端的 DDD / MVC 与精确 Spring Boot 版本用户决定，或既有工程复用核验；OpenAPI、数据架构、按确认架构形成的 DDD / MVC 技术设计合同、工程基线、架构审查和 Slice 合同草案。
+    completion: 新建后端的 gate.backend-architecture-platform-approved 已通过，既有工程已核验复用并记录该门禁不适用；命中契约已冻结；无 API 影响有可读记录；所有后端交付均有批准且当前的 Technical Design；数据影响为真时数据架构已批准，否则有可核验的不适用记录；架构、规则与场景承接无未解释冲突；gate.engineering-contract-approved 通过。
   - id: work-unit.implementation-repository-preparation
     name: 实现仓库准备
     scope: project-instance

package/template/docs/process/schemas/digital-human-task-package.schema.json

@@ -7,6 +7,7 @@
   "required": ["schema_version", "task_id", "work_unit_id", "actor_id", "role_id", "runtime_id", "execution_state", "workflow_status", "skill_source", "contract", "inputs", "objective", "allowed_write_paths", "forbidden_actions", "expected_outputs", "expected_evidence_files", "verification_commands", "verification_results", "downstream_consumers", "convergence"],
   "properties": {
     "plan_review_ref": { "type": "string", "minLength": 1 },
+    "plan_approval_ref": { "type": "string", "minLength": 1 },
     "plan_user_decision_ref": { "type": "string", "minLength": 1 },
     "plan_continuation_ref": { "type": "string", "minLength": 1 },
     "schema_version": { "const": 1 },

package/template/docs/process/schemas/lifecycle-checkpoint.schema.json

@@ -30,6 +30,10 @@
       "type": "string",
       "minLength": 1
     },
+    "plan_approval_ref": {
+      "type": "string",
+      "minLength": 1
+    },
     "plan_user_decision_ref": {
       "type": "string",
       "minLength": 1

package/template/docs/process/schemas/review-bundle.schema.json

@@ -0,0 +1,42 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://yss.dev/schemas/review-bundle.schema.json",
+  "title": "YSS Review Bundle v1",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["schema_version", "kind", "bundle_id", "task_id", "work_unit_id", "review_session_id", "role_id", "runtime_id", "principal_ref", "reviews"],
+  "properties": {
+    "schema_version": { "const": 1 },
+    "kind": { "const": "review-bundle" },
+    "bundle_id": { "type": "string", "pattern": "^review-bundle\\.[a-z0-9][a-z0-9-]*$" },
+    "task_id": { "type": "string", "minLength": 1 },
+    "work_unit_id": { "type": "string", "pattern": "^work-unit\\.[a-z0-9][a-z0-9-]*$" },
+    "review_session_id": { "type": "string", "minLength": 1 },
+    "role_id": { "type": "string", "pattern": "^role\\.[a-z0-9][a-z0-9-]*$" },
+    "runtime_id": { "type": "string", "pattern": "^runtime\\.[a-z0-9][a-z0-9-]*$" },
+    "principal_ref": { "type": "string", "minLength": 1 },
+    "reviews": {
+      "type": "array",
+      "minItems": 1,
+      "items": {
+        "type": "object",
+        "additionalProperties": true,
+        "required": ["schema_version", "gate_id", "decision", "actor_kind", "role_id", "runtime_id", "principal_ref", "drafter_principal_ref", "subject_ref", "subject_digest", "approval_scope", "evidence_refs"],
+        "properties": {
+          "schema_version": { "const": 1 },
+          "gate_id": { "type": "string", "pattern": "^check\\.[a-z0-9][a-z0-9-]*$" },
+          "decision": { "enum": ["approved", "rejected", "vetoed"] },
+          "actor_kind": { "const": "digital-human" },
+          "role_id": { "type": "string", "minLength": 1 },
+          "runtime_id": { "type": "string", "minLength": 1 },
+          "principal_ref": { "type": "string", "minLength": 1 },
+          "drafter_principal_ref": { "type": "string", "minLength": 1 },
+          "subject_ref": { "type": "string", "minLength": 1 },
+          "subject_digest": { "type": "string", "pattern": "^[a-f0-9]{64}$" },
+          "approval_scope": { "type": "array", "minItems": 1, "uniqueItems": true, "items": { "type": "string", "minLength": 1 } },
+          "evidence_refs": { "type": "array", "minItems": 1, "uniqueItems": true, "items": { "type": "string", "minLength": 1 } }
+        }
+      }
+    }
+  }
+}

package/template/docs/process/strategic-handoff-package.md

@@ -6,7 +6,7 @@
 
 1. 源仓必须为 `project-instance`。新交付使用 Domain Strategy v3 与 Stage Decision Package v3；规则、场景、决定、假设、约束、成功标准、测试 seam 与 downstream mapping 使用稳定 ID 和证据。v2 仅用于历史 Handoff v3 的只读验证；修改或重发须显式迁移、重新批准。不得用行号、文字 hash 或导出顺序生成业务身份。
 2. 每个场景明确 `critical`、`rule_refs`、`success_results` 和既有 `failure_results`；兼容字段 `rules` 必须与引用规则正文一致。不变量使用 `rule_ref`，并通过 `scenario_refs` 指向确实覆盖该规则的场景。缺身份或关联先回战略方确认、更新并重新批准，导出器不猜测。
-3. 新原型与既有 UI 交接都使用 Handoff v5，分别选择 `prototype` 或 `existing-ui-baseline`。历史 Handoff v3/v4 与既有裸 v5 包继续按冻结 schema 执行 `verify/import`，但 v3/v4 不再创建新 export；修改或重新交付必须迁移到 v5 并重新批准。校验器先读取 `schema_version` 再选择固定 schema，未知版本输出支持列表并 fail closed。`package_export` 的 `approvals` 按 `source` 字段及 `handoff` 绑定批准记录，声明 `record_ref`、`gate_id`、`digest_kind`。沿用源角色表的现有门禁；当前综合模板的战略、阶段决策及交接资产统一绑定 `gate.plan-approved`，Spec 对应 Spec 基线批准，原型和视觉基线对应 `gate.product-design-approved`；历史包及其他源 profile 仍按包内明确登记的源批准规则验证，不自动迁移当前门禁状态。
+3. 新原型与既有 UI 交接都使用 Handoff v5，分别选择 `prototype` 或 `existing-ui-baseline`。历史 Handoff v3/v4 与既有裸 v5 包继续按冻结 schema 执行 `verify/import`，但 v3/v4 不再创建新 export；修改或重新交付必须迁移到 v5 并重新批准。校验器先读取 `schema_version` 再选择固定 schema，未知版本输出支持列表并 fail closed。`package_export` 的 `approvals` 按 `source` 字段及 `handoff` 绑定批准记录，声明 `record_ref`、`gate_id`、`digest_kind`。当前战略 profile 的领域战略、阶段决策和业务 Ticket 绑定 `gate.plan-approved`，Spec 绑定 `gate.spec-baseline-approved`，原型、视觉或既有 UI 基线绑定 `gate.product-design-approved`，交接自身绑定 `gate.strategic-design-handoff-approved`。历史包仍按包内明确登记的源批准规则验证，但旧门禁只能作为历史证据，不能作为当前输入继续流转。
 4. 批准记录除既有会签字段，还要在 `artifact_bindings` 中逐项绑定 `{id, version, digest}`。战略/阶段建议 `canonical-json`；普通文件使用 `sha256-bytes`；视觉基线使用 `visual-baseline`。正文中的 `approved` 和可读取批准路径不能替代当前字节的批准绑定。源角色表要求用户决定记录时，接收端必须支持并核验该策略；旧工具缺少该能力时阻断并要求升级，不能按旧规则放行。
 5. `additional_files` 明确补充依赖；`reference_map` 将 `evidence.*` 稳定证据引用解析为仓内路径。源资产、批准记录、证据引用、Markdown 本地链接和显式目录共同形成依赖闭包。HTTP 引用保留为引用，不在导出时下载网页。
 6. 原型分支的 `prototype` 指定 `profile`、`preview_root`、`entry_ref`、`verification_ref`、`verification_digest`（验证记录的字节摘要）；H2 另须 `source_root`、`lock_ref` 和 `source_digest`（源码目录树摘要，算法同下述预览树）。源码交付目录不含 node_modules / .git；锁文件与源码一同保存。预览目录须资源闭合，可通过本地静态服务离线浏览。源码、锁文件或验证记录变化须更新交接摘要并重新批准。
@@ -99,16 +99,10 @@ scripts/strategic-feedback verify-adjudication --root <消费者项目根> <adju
 
 共享脚本和包 schema 以主模板为维护源，通过 `scripts/sync-strategic-handoff-tools` 同步到设计/研发模板；源战略 schema 的离线验证副本由该脚本从 canonical `yss-stage-decision/references` 派生。各仓技能仍只编辑 `.agents/skills`，再生成各 runtime 投影与锁。CLI 快照使用各自同步工具，工作树快照用于集成验证，不代表已发布 commit。共享同步仅从主技能注册表投影 `existing_project_profiles` 验证元数据，保留接收模板自己的 Recipe、capability 与创作技能；源注册表及目标有效字节写入工具锁。后端接收模板使用独立视觉 wire runtime，不安装原型创作技能。超出本 profile 职责的技术设计/编译资产在预检中明确标记不支持，战略交接路线不依赖这些后端资产。
 
-## 当前用户决定与交接复用
+## 当前用户决定与交接复核
 
-源角色策略以 `required_capabilities: [strategic-decision-reuse-v1]` 声明本节语义；不支持该能力的接收器必须拒绝。历史包仍按包内源策略校验，不升级旧批准。
+当前用户决定只覆盖 Plan、Spec 和适用的产品设计。各批准记录使用 `subject_ref`、`approval_scope`、`user_decision_ref` 绑定最终可审阅资产与原始回复；Plan 审阅包聚合领域战略和阶段决策的内部检查结论，产品设计门禁聚合原型审查与浏览器验证结论。输入摘要、范围、风险或授权条件变化时，对应决定失效并重新确认。
 
-当前会签绑定 `subject_ref`、`approval_scope`、`user_decision_ref`。只有最终战略交接允许用 `decision_reuse_ref` 引用复用证明；原回复的 boundary、资产和范围保持不变。checkpoint 的 `human_review.decision_reuse` 保存 `{target_gate, ref}`，会签必须引用同一证明。数字人审查仍独立完成。
+`gate.strategic-design-handoff-approved` 不要求新的用户回复，也不把旧决定改写为交接决定。产品经理形成完整交接包后，由需求经理独立复核来源批准新鲜度、完整包摘要、风险与范围，并以 Fresh Verification 关闭交接门禁。缺少独立复核、来源批准过期、摘要漂移或验证失败均阻断 finalize。
 
-复用证明采用 schema v1，`kind: strategic-decision-reuse-v1`，包含 `target_gate`、`scope_ref`、`scope`、`requirements`。每个 requirement 保留原 `boundary`、`subject_ref`、`scope`、`user_decision_ref`。校验当前原始回复、负责人、撤销、资产摘要和范围，不接受自填布尔值作为覆盖证据。
-
-独立交付范围清单采用 schema v1，`kind: strategic-delivery-scope`，包含 `delivery_ref`、`assets`、`risks`、`conditions`。每项资产包含 `ref`、`version`、原始字节 `digest`、`boundary` 和 `scope`；原决定的 subject 或 basis 必须覆盖该资产，专业边界须一致。风险必须已出现在原决定的 risks 中，授权条件必须已出现在 next_actions 中；无法证明的部分补充确认。
-
-`delivery_ref` 是交接正文去除 `package_export`、`status` 后的独立 JSON/YAML 快照；也必须列入 assets 并由既有真实决定明确覆盖；不强制新增交接回复。所有实际 source 资产及视觉或既有 UI 基线 manifest 均须逐项覆盖。业务 Ticket 已被 Spec 的当前行为与验收范围明确覆盖时，可引用该 Spec 决定；数字人交接会签仍使用交接门禁，不改写原回复的专业边界。先固定该快照与业务资产，再确认和会签，最后组装包，避免摘要循环。仅重新组装传输包且业务依据和范围不变时复用有效确认。
-
-导出将范围清单、复用证明、原决定及其来源依赖一起收集。离线 verify 重新检查实际交付与批准覆盖；缺文件、摘要变化、范围遗漏、未知能力均阻断，不回写旧包。
+历史包中的 `strategic-decision-reuse-v1`、`decision_reuse_ref` 和旧门禁批准保持可读，供离线 `verify/import` 复核当时证据。它们不能关闭当前聚合门禁；任何修改、重发或继续流转都必须先完成战略门禁迁移并重新批准。

package/template/docs/templates/build-architecture-checklist-template.md

@@ -19,7 +19,7 @@ owner: ai
 | 系统 / 数据架构设计 |  |  |
 | 风险 / 回滚约束 | `AGENTS.md` |  |
 | Slice Implementation Contract |  | 填写 contract_id / contract_version / 生命周期批准状态 |
-| 后端脚手架策略 | `orchestration-contract.yaml` / DDD 或 Layered MVC 生成器 |  | backend `scaffold_status=required` 时填写 architecture decision、schema v3 合同身份、批准/持久化引用、生成器输入、Manifest v3、实际 `./mvnw` 结果和后置实现合同编译器重编译 |
+| 后端脚手架策略 | `orchestration-contract.yaml` / DDD 或 Layered MVC 生成器 |  | backend `scaffold_status=required` 时填写架构与平台用户门禁、architecture decision、精确 Spring Boot 版本、schema v4 合同身份、批准/持久化引用、生成器输入、Manifest v4、实际 `./mvnw` 结果和后置实现合同编译器重编译；既有工程填写登记值复用证据 |
 | 工程项目路径策略 | `docs/process/implementation-repo-integration.md` / 实现合同编译器 Contract |  | Harness 内必须是 `apps/backend/<project>/` 或 `apps/frontend/<project>/`；`apps/backend/`、`apps/frontend/` 仅为容器，`app/backend/`、`app/frontend/` 及其子路径阻断 |
 | 垂直切片工作单元 |  |  |
 | YSS Skill Execution Result |  | 每个 skill / work_unit 的结果文件引用 |
@@ -32,7 +32,7 @@ owner: ai
 | 后端切片必须回勾 `Backend Slice Implementation Contract`：required skills、允许写范围、禁止模式、证据文件、延期 seam 和验证命令完整 | implementation routing / 垂直切片 Ticket / `AGENTS.md` |  | `implemented` / `seam-deferred` / `drift` / `violation` / `not-applicable` |  | 缺合同或合同不完整时暂停并记录替代方案 |
 | 统一合同版本：实现消费的 contract_id / contract_version 与生命周期批准并持久化的版本一致，实现合同编译器 未自行批准合同或推进 `ready-for-agent` | Slice Implementation Contract / 生命周期证据 |  | `implemented` / `seam-deferred` / `drift` / `violation` / `not-applicable` |  | 版本不一致时将工作单元标记 `stale` 并暂停 build |
 | 合同子项闭环：Common、Frontend、Backend、Contract、Cross-repo 子合同按影响面填写，不适用项有原因 | Slice Implementation Contract |  | `implemented` / `seam-deferred` / `drift` / `violation` / `not-applicable` |  | 缺失适用子合同时回到 实现合同编译器 |
-| 后端脚手架顺序：工程基线与 Agent 推荐 → 用户确认并持久化 architecture decision → schema v3 合同 draft / 生命周期批准 → DDD 或 Layered MVC 生成器 → 对应基线与 Manifest v3 校验 → 实现合同编译器重编译；生成器无交互且不得生成业务行为 | `yss-product-lifecycle` / `yss-ddd-scaffold-generator` / `yss-layered-mvc-scaffold-generator` |  | `implemented` / `seam-deferred` / `drift` / `violation` / `not-applicable` |  | 选择缺失、digest 漂移、顺序缺失、生成器混入业务行为或缺 Execution Result 时阻断 |
+| 新建后端顺序：工程基线与 Agent 推荐 → `gate.backend-architecture-platform-approved` 同时确认 DDD / MVC 与精确 Spring Boot 版本 → 持久化 architecture decision → DDD / MVC 分支设计 → schema v4 合同 draft / 生命周期批准 → 对应生成器 → 基线与 Manifest v4 校验 → 实现合同编译器重编译；既有工程核验复用登记值；生成器无交互且不得生成业务行为 | `yss-product-lifecycle` / `yss-ddd-scaffold-generator` / `yss-layered-mvc-scaffold-generator` |  | `implemented` / `seam-deferred` / `drift` / `violation` / `not-applicable` |  | 门禁或选择缺失、digest 漂移、顺序缺失、生成器混入业务行为或缺 Execution Result 时阻断 |
 | 写路径与证据：Execution Result 的 changed_files 均位于 allowed_write_paths，expected_evidence_files 已实际生成 | Slice Implementation Contract / YSS Skill Execution Result |  | `implemented` / `seam-deferred` / `drift` / `violation` / `not-applicable` |  | 路径越界或证据缺失标记 `violation` 并阻断 build |
 | TDD 模式：每个工作单元唯一选择 `behavior-tdd` 或 `controlled-generation`；生成器未承载状态、权限、业务过滤、事务、错误映射或用户可见交互 | Slice Implementation Contract / 垂直切片 Ticket / Execution Result |  | `implemented` / `seam-deferred` / `drift` / `violation` / `not-applicable` |  | 模式不匹配时拆分工作单元并完整重路由 |
 | 所有后续生成代码：必须消费当前批准合同、主 YSS skill、依赖闭包、允许写路径、预期证据和 YSS Skill Execution Result；业务行为使用 `behavior-tdd` | `post_scaffold_generated_code_policy` |  | `implemented` / `seam-deferred` / `drift` / `violation` / `not-applicable` |  | 缺任一条件或以时间压力豁免时阻断 build |

package/template/docs/templates/implementation-routing-template.md

@@ -226,7 +226,7 @@ owner: ai
 
 | 受影响端 | 是否已有可用工程 | scaffold_status | 目标是否确认 | 处理结论 | 使用 skill | 输出位置 / 仓库 | 备注 |
 |---|---|---|---|---|---|---|---|
-| backend | 是 / 否 / 不适用 | existing / required / initialized / not-applicable | 是 / 否 / 不适用 | 复用现有 / 初始化 / 阻塞 | `yss-ddd-scaffold-generator` / `yss-layered-mvc-scaffold-generator` / none |  | 填写 architecture_family、decision_id 与 digest |
+| backend | 是 / 否 / 不适用 | existing / required / initialized / not-applicable | 是 / 否 / 不适用 | 复用现有 / 初始化 / 阻塞 | `yss-ddd-scaffold-generator` / `yss-layered-mvc-scaffold-generator` / none |  | 新建填写 gate、architecture_family、精确 Spring Boot 版本、decision_id 与 digest；既有工程填写登记值复用证据 |
 | frontend | 是 / 否 / 不适用 | existing / required / initialized / not-applicable | 是 / 否 / 不适用 | 复用现有 / 初始化 / 阻塞 | `yss-frontend-scaffold-generator` / none |  |  |
 
 脚手架输出位置必须回指具体项目根：后端为 `apps/backend/<project>/`，前端为 `apps/frontend/<project>/`；不得把 `apps/backend/`、`apps/frontend/` 容器根或任何 `app/backend/`、`app/frontend/` 路径作为生成目标。
@@ -240,18 +240,18 @@ owner: ai
 
 ### 4.3 后端脚手架工作单元
 
-当 backend `scaffold_status=required` 时，生命周期先按领域复杂度推荐 DDD/MVC，并以批量决策表反问用户确认本体默认与子项目覆盖。选择写入 `scaffold-architecture-decisions.yaml`；缺失、未确认或 stale 时阻断。随后登记一个 `controlled-generation` 工作单元：`domain-driven` 使用 `primary_skill=yss-ddd-scaffold-generator`，`layered-mvc` 使用 `primary_skill=yss-layered-mvc-scaffold-generator`。生成后执行对应基线校验和 `yss-implementation-contract-compiler` 合同重编译。`existing` / `initialized` 不重复生成，架构转换另立迁移工作单元。
+当 backend `scaffold_status=required` 时，生命周期先按领域复杂度推荐 DDD/MVC，并展示平台清单中的精确 Spring Boot / Java 版本，以批量决策表取得同一次用户确认并通过 `gate.backend-architecture-platform-approved`。选择写入 `scaffold-architecture-decisions.yaml`；缺失、未确认或 stale 时阻断。门禁通过后才进入对应的 DDD 战术设计或 MVC 技术设计，再登记 `controlled-generation` 工作单元。`domain-driven` 使用 `primary_skill=yss-ddd-scaffold-generator`，`layered-mvc` 使用 `primary_skill=yss-layered-mvc-scaffold-generator`。生成后执行对应基线校验和 `yss-implementation-contract-compiler` 合同重编译。`existing` / `initialized` 核验并复用当前登记架构与平台，不重复询问或生成；架构转换、平台升级另立迁移工作单元。
 
 | 项 | 内容 |
 |---|---|
-| 前置 | `prototype_confirmation`、工程基线、实现仓库和脚手架目标已确认；`scaffold-architecture-decisions.yaml` 已由用户确认且 digest 当前；实现合同编译器 schema v3 脚手架合同 draft 已经生命周期批准并持久化为结构化 JSON，生成器通过 `--contract-file` 消费 |
+| 前置 | `prototype_confirmation`、工程基线、实现仓库和脚手架目标已确认；`gate.backend-architecture-platform-approved` 已同时确认 DDD / MVC 与精确 Spring Boot 版本，`scaffold-architecture-decisions.yaml` digest 当前；实现合同编译器 schema v4 脚手架合同 draft 已经生命周期批准并持久化为结构化 JSON，生成器通过 `--contract-file` 消费 |
 | 生成器 | `domain-driven` → `yss-ddd-scaffold-generator`；`layered-mvc` → `yss-layered-mvc-scaffold-generator` |
 | 模式 | `controlled-generation` |
 | Java / Maven 身份 | `base_package` 与 Maven `group_id` 分开登记；项目版本、父 POM GAV、`yss-components.version` 进入批准合同并原样传给 CLI |
 | 允许生成 | DDD 的 Domain / Application / Infrastructure / Adapter / Bootstrap，或 MVC 的 server / service / repository 与能力解析出的 adapter / client / feign-client；以及 POM、配置、Wrapper 和非业务机械模板 |
 | 禁止生成 | 业务规则、状态机、权限、事务、复杂查询、错误映射、业务字段和用户可见行为 |
 | 生成选项 | 关闭 `--with-example`；生成器严格 initialize-only，非空目录、`--force`、旧项目迁移和当前模板升级均为 `unsupported` |
-| Profile | DDD：`target-domain-model` + MySQL；MVC：`layered-mvc` + MySQL/Oracle/OceanBase Oracle；共同固定 Spring Boot 2.7 / Java 8 / `javax` / MyBatis-Plus，其他组合须先通过独立 fixture |
+| Profile | DDD：`target-domain-model`；MVC：`layered-mvc-service`；Spring Boot / Java 使用用户确认且兼容清单验证通过的精确组合，不使用版本范围或 `latest` |
 | 验证 | 使用一键生成验证入口，实际执行项目根目录 `./mvnw validate`、`./mvnw test`、`./mvnw package`；通过后仅为 `empty-scaffold-verified`，golden first slice 通过后才是 `first-slice-verified` |
 | 后置 | `yss-backend-scaffold-parent`、`yss-implementation-contract-compiler` 业务合同重编译、YSS Skill Execution Result |