create-yss-spec 3.4.1 → 3.4.4

package/template/.pi/skills/yss-product-lifecycle/SKILL.md

@@ -27,7 +27,7 @@ description: 编排 YSS 产品或模块从机会调研到 Spec、原型、技术
 scripts/query-lifecycle-context --mode route --stage stage.plan --work-unit work-unit.plan-requirements --include execution_efficiency
 ```
 
-`--include` 接受编排合同的顶层键；非法模式、ID 或合同键必须失败。结果为权威投影；细节按需读 `references/orchestration.md`、`references/state-model.md`、`references/artifact-dependencies.md`、`references/user-decisions.md` 和 `references/matt-yss-adapter.md`，证据充分即停止加载。
+`--include` 接受合同顶层键，非法键或 ID 失败。细节按需读 `references/orchestration.md` 及其索引，证据充分即停止加载。
 
 按 `execution_efficiency` 合并查询、复用未变资料并验证当前资产；产品流转不重跑模板套件。词汇对账、恢复核验及门禁不变，执行细节见 `references/orchestration.md`。
 
@@ -52,11 +52,11 @@ Plan 入口读取 `docs/plan/README.md` 和 `docs/process/plan-migration.md`，
 
 不得越过命中的阶段、门禁、实现仓库准备或 Ticket 正式化。实现只接收绑定垂直切片、已批准且持久化、版本当前并通过完整 `ready-for-agent` 计算的合同；父 Ticket、`ready-for-human` 切片、`stale`、`drift`、`new_impacts`、`violation` 或缺失证据均阻断。实现仓库、脚手架、UI 还原、review input 和发布条件从对应合同子树查询，不在入口重复定义。
 
-聚合批准见 `gate_consolidation`。
+聚合批准见 `gate_consolidation`。普通功能默认一个独立审查者，按能力缺口、冲突或外部制度增员；相邻检查组合审查、逐项留证。
 
 ### 用户决定
 
-命中 `docs/agents/digital-human-roles.yaml.user_decision_policy` 的关键决定，必须先展示当前资产、版本、变化、风险、推荐方案、批准范围和后续动作，再取得提问者或其明确指定生物人负责人的原始回复。数字人同意、超时、默认项或无反对意见不能代答；恢复前按 `references/user-decisions.md` 验证当前资产与原始回复绑定。
+按角色表 `user_decision_policy` 和 `references/user-decisions.md` 先展示可审阅资产、范围、风险及后续动作，再取得提问者或其指定生物人的原始回复。数字人、超时和默认项不能代答。已有授权优先用 `continuation_ref` 核验延续；未知/实质变化或强制审批缺失才重新决定。缺陷和缺证据阻断，建议记待办；合同、验证及外部动作授权仍须满足。
 
 ### 外部副作用与 Git
 
@@ -68,7 +68,7 @@ Plan 入口读取 `docs/plan/README.md` 和 `docs/process/plan-migration.md`，
 2. 评估影响面、上游新鲜度、门禁和阻塞，选择第一个未阻塞工作单元；不把 `not-applicable` 当作豁免。
 3. 原生工作单元由主控持有正式资产；专项工作通过结构化任务包派发，只调用编排合同允许的 model-invoked skill。
 4. Matt 的 `grill-with-docs`、`to-spec`、`to-tickets`、`implement` 等仅为显式 user-invoked 兼容入口。主控不得自动调用它们或代替其创建正式资产；Matt 仅导航，不得写生命周期资产或改变门禁/Ticket 状态，任何写入前回交本编排器。
-5. 先对照用户目标逐项验收，检查遗漏诉求、错误假设与尚未解决的问题，再验收 `Workflow Execution Result`：工作单元、合同、允许写路径、`context_reconciliation`、证据、实际验证、延期 seam、漂移和下一路由必须可核验。实现派发额外绑定当前 Slice Implementation Contract；其他阶段不得伪造该合同。
+5. 先对照用户目标逐项验收，检查遗漏诉求、错误假设与尚未解决的问题，再验收 `Workflow Execution Result`：工作单元、合同、允许写路径、`context_reconciliation`、证据、实际验证、延期 seam、漂移和下一路由必须可核验。实现派发额外绑定当前 Slice Implementation Contract v3；其他阶段不得伪造该合同。
 6. 在授权边界内继续下一工作单元；遇到人工决定、新授权、证据冲突、专项失败或合并/发布结论时暂停。暂停不得阻断无依赖的独立工作。
 
 每个 `project-instance` 工作单元在申请批准或流转前，先把稳定术语回写到根目录唯一 `CONTEXT.md`，并生成通过校验的 `context_reconciliation`。候选术语、错误路径、摘要漂移或未决冲突必须阻断。质量标准只由 `engineering-baseline` 定义一次；高风险影响按裁剪合同补充反证和残余风险。

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

@@ -382,7 +382,15 @@ work_unit_routes:
     technical_design:
       applies_when: backend_delivery_impact
       new_backend_repository: required
-      architecture_source: confirmed-project-architecture-before-branch-design
+      architecture_source: new-project-user-gate-or-current-existing-registration-before-branch-design
+      pre_design_gate:
+        id: gate.backend-architecture-platform-approved
+        applies_when: new_backend_repository
+        confirms: [architecture_family, exact_spring_boot_version]
+        architecture_choices: [domain-driven, layered-mvc]
+        platform_source: docs/engineering/backend-platforms.json
+        existing_repository: not-applicable-reuse-current-registration
+        missing_or_stale: blocked
       branches:
         domain-driven: yss-tactical-design
         layered-mvc: yss-mvc-design
@@ -414,6 +422,7 @@ work_unit_routes:
       placeholder_assets: forbidden
       atomic_approval_gate: gate.engineering-contract-approved
     human_gate: gate.engineering-contract-approved
+    entry_user_gate: gate.backend-architecture-platform-approved
     applies_when: technical_or_contract_impact
     not_applicable_reason: no_technical_or_contract_impact
   work-unit.implementation-repository-preparation:
@@ -771,7 +780,8 @@ scaffold_architecture_decision:
   applies_when: [backend_impact, scaffold_status_required]
   owner: yss-product-lifecycle
   stage: work-unit.technical-analysis
-  timing: after-impact-and-engineering-baseline-inputs-before-scaffold-contract-compilation
+  gate: gate.backend-architecture-platform-approved
+  timing: after-impact-and-platform-candidate-resolution-before-ddd-or-mvc-branch-design
   source: scaffold-architecture-decisions.yaml
   schema_version: 1
   statuses: [undecided, recommended, awaiting-user-decision, user-confirmed, lifecycle-approved, consumed, stale]
@@ -782,6 +792,12 @@ scaffold_architecture_decision:
     layered-mvc:
       display_name: MVC 开发脚手架
       recommendation_signals: [crud, reporting-query, data-transformation, external-system-orchestration, thin-domain]
+  platform_choice:
+    source: docs/engineering/backend-platforms.json
+    confirms: [platform_profile, spring_boot_version, java_version]
+    version_format: exact-patch
+    latest_or_range: forbidden
+    same_user_decision_as_architecture: true
   recommendation_policy:
     evidence_required: true
     strong_domain_signal_prefers: domain-driven
@@ -794,7 +810,7 @@ scaffold_architecture_decision:
     main_project_has_no_silent_default: true
     child_projects_prefill_parent_default: true
     batch_confirmation_required: true
-    prompt_fields: [project, responsibility, agent_recommendation, recommendation_reasons, inherited_from, current_choice, platform_profile, architecture_profile, verification_database, production_database, resolved_modules, warnings]
+    prompt_fields: [project, responsibility, agent_recommendation, recommendation_reasons, inherited_from, current_choice, platform_profile, spring_boot_version, java_version, architecture_profile, verification_database, production_database, resolved_modules, warnings]
     missing_or_deferred_action: blocked
   inheritance:
     modes: [root-default, inherit, override]
@@ -803,9 +819,10 @@ scaffold_architecture_decision:
     shared_profile_change_stales_all_affected: true
     new_child_requires_confirmation: true
   persistence:
-    required: [decision_id, project_id, parent_project_id, recommended_architecture, recommendation_reasons, confirmed_architecture, override_reason, inheritance_mode, inherited_from, platform_profile, architecture_profile, verification_database, production_database, requested_capabilities, resolved_modules, resolution_version, user_confirmation, decision_inputs_digest, status]
+    required: [decision_id, project_id, parent_project_id, recommended_architecture, recommendation_reasons, confirmed_architecture, override_reason, inheritance_mode, inherited_from, platform_profile, exact_spring_boot_version_in_user_snapshot, architecture_profile, verification_database, production_database, requested_capabilities, resolved_modules, resolution_version, user_confirmation, decision_inputs_digest, status]
     downstream_reference: [decision_ref, decision_id, decision_digest]
-    no_new_gate: true
+    approval_gate: gate.backend-architecture-platform-approved
+    existing_repository: reuse-current-registration-without-user-reconfirmation
   change_policy:
     before_lifecycle_approval: update-decision
     after_lifecycle_approval_before_generation: stale-contract-and-recompile
@@ -1159,7 +1176,7 @@ user_decision_evidence:
   professional_review_replaced: false
   response_absent: paused-human-gate
   invalid_response: blocked
-  basis_changed: stale
+  basis_changed: revalidate_then_continue_only_with_independent_equivalence_evidence
 
 gate_consolidation:
   source: docs/process/lifecycle-registry.yaml
@@ -1170,7 +1187,12 @@ gate_consolidation:
   readiness: computed_after_current_approved_contract_and_all_applicable_preconditions
   api_freeze: atomic_with_engineering_contract_approval_same_version
   acceptance_does_not_authorize: [merge, push, release, production_change]
-  reuse: unchanged_subject_basis_and_scope_only
+  reuse: unchanged_approval_or_verified_approved_scope_continuation
+  default_review: one_owner_one_independent_reviewer
+  adjacent_reviews: one_bundle_with_explicit_per_check_outcomes
+  extra_reviewers: uncovered_expertise_conflict_or_external_requirement
+  suggestions: recorded_backlog_without_blocking
+  continuation_protocol: references/user-decisions.md
   invalidation: affected_dependencies_or_authorization_change_only
   historical_gate_records: read_only_no_automatic_approval_migration
   verifier: scripts/verify-lifecycle-checkpoint

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`。
 
@@ -148,3 +148,7 @@ Checkpoint 中已批准门禁必须带 `basis: [{ref, digest}]` 和按 `evidence
 ## 专项合同加载索引
 
 专项加载提示：实现仓库与脚手架查询 `implementation_repository_preparation`、`backend_scaffold`；切片实现查询 `ticket_formalization`、`ready_for_agent`；UI 查询 `frontend_implementation_plan`、`frontend_implementation_verification`；审查查询 `review_input`；发布查询 `release_readiness`、`git_authorization`、`user_decision_evidence`；战略交接读取 `docs/process/strategic-handoff-package.md` 并按其中验证器执行。
+
+## 后端脚手架平台
+
+在工程基线中合并展示、确认架构和 Boot 精确版本、Java、YSS 父 POM/BOM；缺少选择时询问，当前批准可复用。独立子项目可继承或覆盖，并可一次确认明确列出的多个项目。同一 Maven 工程统一平台。执行 `scripts/backend-platforms` 展示兼容状态；只允许已验证组合。决定、合同、Manifest 和下游身份绑定同一平台摘要；变更重新确认。合同见仓库 `docs/engineering/backend-platforms.md`。

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

@@ -14,6 +14,8 @@
 
 Matt 五态不得扩义。资产的 `ready-for-human` 与 Ticket label 必须带命名空间表达。`paused-human-gate` 表示等待 `docs/agents/digital-human-roles.yaml` 指定的会签人（数字人或生物人），不是「必须是生物人」。但 `user_decision_policy` 命中的关键决定还必须有真实用户回复，数字人会签不能解除该等待。
 
+Slice v3 冻结需求文件的 status 是冻结时快照，不能用来推断当前执行状态。状态流转和验收结果写入已配置主 tracker / 任务包；需求改版后重新编译、审查与绑定批准，见 [Slice 冻结需求协议](../../yss-implementation-contract-compiler/references/slice-implementation-contract.md#第二轮增量规则)。
+
 ## 上下文与外部输入证据
 
 状态模型不新增 context 状态域。阶段边界只在状态块或 checkpoint 中保存可选证据：
@@ -53,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

@@ -8,7 +8,7 @@
 2. **绑定原始回复**：保存回复人、原始消息引用、回复时间、原文、决定、对应事项、范围及请求摘要。Agent 只能整理，不得生成、推测或补造用户同意。来源记录是可追溯证据，不是密码学身份认证。
 3. **无回复就等待**：超时、默认选项、数字人同意、无反对意见和 Agent 自述均无效。依赖该决定的工作保持 `paused-human-gate` / `ready-for-human`；来源错误等使用 `blocked`。独立工作可以继续，不得借其完成清除未决决定。
 4. **回复必须指向明确**：单项明确请求的“同意”有效。多项需要逐项指定、清楚的子集或“同意以上全部事项”；“继续”不算全部批准。拒绝、修改意见和撤回均保留为有效回复，但不放行。编排器结合原文判定语义；机器核验结构、明确性底线、来源和绑定，不能用自填 `approved` 覆盖相反原文。
-5. **复用已有有效确认**：同一版本、范围和依据不重复询问，不按时间自动过期。相关资产或依据摘要变化、范围扩大或撤回时，旧批准失效；展示差异后重新确认。无关文件变化不触发重新确认。回复按来源时间追加，禁止删除拒绝、修改或撤回记录来恢复旧批准。
+5. **复用已有有效确认**：同一版本、范围和依据不重复询问，不按时间自动过期。当前资产字节变化先使旧验证过期；按下述授权延续协议核验差异，决定依据未变时更新专业审查和验证证据，不要求新回复。实质变化、范围扩大或撤回时展示差异后重新确认。无关文件变化不触发重新确认。回复按来源时间追加，禁止删除拒绝、修改或撤回记录来恢复旧批准。
 6. **提问者和负责人分开**：默认回复人为提问者。其他业务、技术或发布负责人必须由提问者在原始消息中明确指定，包含对应事项和负责人；数字人不得自行代任。用户表达使用自然语言，内部 ID 和引用由 Agent 整理。
 
 ## 记录与来源
@@ -45,12 +45,32 @@ Workflow Execution Result 使用 `user_decisions` 保存当前要求与证据引
 
 checkpoint 的 `human_review` 保存 `user_decisions`、`required_decisions`、`not_applicable` 和需要时的 `external_input`。`stage_trace.completed_work_unit` 标识已完成单元；进入实施时 `human_review.implementation` 保存当前切片及持久化合同引用。等待态可以保存；恢复、流转和完成时重新核验。外部回复、新授权、风险接受均以同一决定记录作为恢复依据，不能以工具恢复或默认答案替代。
 
-## 首次实施与脚手架
+## 已批准范围内连续推进
 
-首次实施批准的主体为功能级 `implementation-scope` 清单，`slices` 每行包含：`ticket_ref`、`contract`（ref/version/digest）、`repositories`、`allowed_write_paths`、`baselines`（ref/version/digest）。仓库与写路径必须对应当前合同 `common.project_roots/allowed_write_paths`；基线包含合同引用的工程基线。`scope` 使用批准的切片引用集合。合同、范围或基线变化时回到确认；已覆盖的后续切片复用原记录。
+优先使用已有回复；没有明确授权时先形成可审阅方案，再集中确认范围、验收标准和实施边界。Plan、Spec、产品设计和工程契约仍完成适用检查，但不重复询问同一决定。脚手架架构选择、运行时外部动作仍按各自授权边界执行；交付验收不授权 commit、push、发布或生产操作。
+
+`delivery-scope` 用户决定的主体可使用 `delivery-authorization` 清单：`schema_version: 1`、`kind`、不可变且有 `ref/version/digest` 的 `basis` 原始快照、`external_policy` 和 `targets`。每个 target 明确 `boundary/subject_ref/scope/decision_basis`；scope 不能超过原回复覆盖范围。`decision_basis` 必须逐项列明非空的 `business_scope/acceptance/contract_commitments/authorization/risk_acceptance/quality/external_commitments` 字符串数组；不存在的承诺明确写“无新增承诺”，不能留空。边界和资产路径明确，禁止通配授权未来未知范围。外部制度文件有 `status: confirmed|unconfirmed` 和 `requirements`；每项制度列 `id/boundaries/principals`，无额外审批只能在已确认后显式使用空数组。
+
+当前 requirement 保持 `boundary/subject_ref/scope`，用 `continuation_ref` 引用 `approved-scope-continuation-v1` 证据，替代直接 `user_decision_ref`。证据包含 `schema_version: 1`、`kind`、`boundary/scope`、当前 `subject`、实际验证 `basis`、原始 `source` requirement、独立 `review` 资产和适用的 `external_decisions`。资产描述均用 `ref/version/digest`，digest 为带 `sha256:` 前缀的原字节摘要。不允许链式延续或生成新的用户回复。
+
+`implementation-scope` target 还必须包含 `implementation_limits`，按切片 Ticket 引用登记 `repositories/allowed_write_paths`。校验器将当前实施清单逐项与原授权边界精确比较；即使重算当前摘要并声明“无语义变化”，也不能扩大仓库或写路径。
+
+独立 review 包含：`decision: approved`、`role_id/runtime_id/principal_ref/drafter_principal_ref`、`classification`（`within-approved-scope/presentation-only/implementation-detail`）、`material_changes: []`、`findings`、当前 `boundary/scope/subject/basis`、与原授权一致的 `decision_basis`、`reason`、`comparison.before/after`。before 必须是原授权 basis 内不可变快照，after 必须绑定当前 subject。审查者按原快照与当前完整资产比较语义，不能只比较自填摘要或声称“无变化”；机器验证来源、摘要、身份分离、范围和声明的一致性，不替代专业语义判断。
+
+finding 分为 `requirement-violation/missing-evidence/important-risk/suggestion`，带 `id/reason`。前三类未 `resolved` 则阻断；suggestion 必须有 `follow_up` 待办，不因个人偏好加门禁。重要风险须重新取得用户风险接受决定，不能改分类绕过。
+
+外部制度有要求时，`external_decisions` 每项含 `obligation_id/principal_ref/requirement`，逐一验证当前资产、范围和指定真人原始回复；制度未确认不能自动延续。制度文件或原授权决定依据变化需要重新评估和确认，不能清空要求。
+
+使用 `scripts/verify-user-decision --continuation <requirement.yaml>` 核验。会签记录可携带同一 `continuation_ref`；工作单元和任务包沿用 `user_decisions`，Plan 入口使用 `plan_continuation_ref`。实施仍校验当前 scope 清单、切片合同、仓库、允许写路径和工程基线，不因延续省略合同校验。旧记录维持严格读取；未登记该 capability 的接收端必须拒绝延续并升级，不能静默当普通批准。
+
+相邻专业检查可共用一个 `schema_version: 1, kind: review-bundle, reviews: [...]` 文件。每行都是已有会签记录形状，有唯一 gate/check ID、当前 subject/digest/scope、独立身份和明确结论；失败项不能被总体通过掩盖。`verify-approval-record` 检查所有行，聚合门禁按检查 ID 读取各自行。组合审查不增加用户确认次数，也不省略检查覆盖。
+
+## 实施范围与架构选择
+
+首次实施批准的主体为功能级 `implementation-scope` 清单，`slices` 每行包含：`ticket_ref`、`contract`（ref/version/digest）、`repositories`、`allowed_write_paths`、`baselines`（ref/version/digest）。仓库与写路径必须对应当前合同的实施范围（v2 `common.project_roots/allowed_write_paths`，v3 `scope.project_roots/allowed_write_paths`，通过统一读取器核验）；基线包含合同引用的工程基线。`scope` 使用批准的切片引用集合。合同、范围或基线变化时回到确认；已覆盖的后续切片复用原记录。
 
 实施就绪和派发必须同时提供 `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-prototype-stage/SKILL.md

@@ -46,7 +46,7 @@ Design QA 合并 visual、layout、interaction、content、accessibility、cross
 
 用户确认必须绑定提问者或其明确指定负责人的原始回复，使用生命周期 `user_decision_policy` 和统一用户决定记录；产品数字人只提供确认建议，不能代答。正式证据追加 `user_decision_ref/decision_subject_ref`，校验原型、视觉基线和操作范围与用户所见快照一致。用户确认只描述原型确认了什么、哪些范围可操作、哪些为模拟或 gap，以及接受/拒绝结论；不要求用户确认技术栈、CLI 或构建细节。
 
-`check.prototype-reviewed` 和 `check.prototype-verified` 是 `gate.product-design-approved` 的内部检查；独立评审和验证通过后，用户统一确认当前原型。档位选择属于验证输入，不单独请求批准，也不授权实现。
+`check.prototype-reviewed` 和 `check.prototype-verified` 是 `gate.product-design-approved` 的内部检查；独立评审和验证通过后，按生命周期用户决定协议核验当前范围。已有明确授权且决定依据不变时用 `continuation_ref` 延续；新的业务体验取舍、范围或重要风险仍由用户确认。档位选择属于验证输入，不单独请求批准，也不授权实现。
 
 ## 按需读取
 

package/template/.pi/skills/yss-repository/SKILL.md

@@ -42,3 +42,7 @@ description: 用于按批准的 YSS 架构与持久化合同实现或重构 PO
 ## Review 输入
 
 `code-review` 仅对本体项目及合同/实现仓登记的后端研发项目执行本 Skill。候选命中持久化结构或数据访问时，Standards 轴必须读取所选 Profile 并引用规则与代码证据；未命中时记录带原因的 `not-applicable`。Reviewer 只报告 finding，不写实现。
+
+## 新脚手架平台约束
+
+消费批准切片架构身份中的 `platform_configuration`，与工程 Manifest 核对后使用对应 YSS 组件。Boot 2.7 使用 `javax` Web/Validation API；Boot 3.5/4.1 使用 `jakarta`。Boot 4 按 Jackson 3、对应自动配置和 starter 适配；不替换 `javax.sql` 等 Java SE 包。平台不一致、兼容条目缺失或候选未验证时回合同编译器阻断，不在业务实现中升级或替换组件。详见 仓库共享合同 `docs/engineering/backend-platforms.md`。

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

@@ -1,6 +1,6 @@
 ---
 name: yss-research
-description: Research technical or product-strategy questions with traceable evidence before YSS Plan, Spec, domain-strategy, API, architecture, or implementation decisions. Use for current facts, standards, third-party APIs, business constraints, user problems, domain-boundary evidence, or when the deprecated `research` alias is invoked.
+description: "研究 YSS 技术或产品策略事实并提供可追溯证据；用于标准、第三方行为、业务约束和 research 兼容入口。"
 ---
 
 # YSS Research

package/template/.pi/skills/yss-resilience4j/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yss-resilience4j
-description: Use when 用于 YSS Resilience4j starter、网关熔断、限流降级、GlobalCircuitExceptionAdvice、GatewayConfiguration 和断路器配置排障。
+description: "接入或排查 YSS Resilience4j starter、网关熔断、限流降级与断路器配置。"
 ---
 
 # yss-resilience4j

package/template/.pi/skills/yss-security-algorithm/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yss-security-algorithm
-description: Use when YSS RSA/AES/DES/SM2/SM4 encryption, JWT/JWK configuration, password encoding, key loading, rotation, or decryption failures are involved.
+description: "接入或排查 YSS 加解密、JWT/JWK、密码编码、密钥加载与轮换。"
 ---
 
 # yss-security-algorithm

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` 及原因，不生成空设计。
@@ -39,3 +39,7 @@ description: 在 YSS 技术分析阶段将批准的战略领域输入细化为
 跨仓交接使用 `scripts/strategic-handoff export / verify / import`。正式导出前补齐源战略的稳定规则 ID、关键场景和当前批准绑定；源资产原字节冻结、包内路径通过清单解析。目标导入只产生快照和对账/承接草案，正式 reconciliation 通过后才能进入战术设计。流程与字段见 `docs/process/strategic-handoff-package.md`。
 
 战术合同必须绑定 `strategic_handoff` 导入收据、包摘要、正式目标对账及逐条承接 rows。来自导入包时禁止仅填 `upstream_current: true`。批准前执行 `scripts/verify-strategic-handoff-consumption --root <target> <tactical>`；存在受控延期时按切片执行 `--slice <slice-id>`，实际核验通过且合同批准后才可继续相关切片。最新源规则、关键场景或资产变化使依赖项 stale；未知依赖扩大阻断，业务冲突回交战略方。结果绑定当前包与战术摘要，不能复用旧输出宣布 ready-for-agent。
+
+## 后端脚手架平台承接
+
+消费生命周期已确认的架构与 `platform_configuration` v2；不得自行选择、批准或静默升级 Boot/Java。平台清单执行 `scripts/backend-platforms` 查询；只允许已验证 YSS 组合，新生成缺少配置或证据即阻断。决定、合同、Manifest 与下游架构身份须绑定同一平台及兼容摘要。详见 仓库共享合同 `docs/engineering/backend-platforms.md`。

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。
@@ -37,3 +37,7 @@ schema v1 战术合同只按 DDD 显式兼容读取；使用 `--legacy-ddd`，
 ## 交接
 
 按现有架构审查门禁进行独立评审。批准且版本当前后交回生命周期，再交编译器；DDD 实现使用 `yss-domain`，MVC 实现按已登记 Profile 的能力与 Recipe 路由。发现 `stale`、`drift`、`new_impacts` 或路径越界时回交重路由。需要图示时按用户或合同要求调用 `archify`，图只作派生证据。
+
+## 后端脚手架平台承接
+
+消费生命周期已确认的架构与 `platform_configuration` v2；不得自行选择、批准或静默升级 Boot/Java。平台清单执行 `scripts/backend-platforms` 查询；只允许已验证 YSS 组合，新生成缺少配置或证据即阻断。决定、合同、Manifest 与下游架构身份须绑定同一平台及兼容摘要。详见 仓库共享合同 `docs/engineering/backend-platforms.md`。

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/scripts/validate-technical-design.mjs

@@ -135,11 +135,11 @@ export async function validateTechnicalDesign(data, { root = process.cwd(), slic
 }
 
 async function main() {
-  const { values, positionals } = parseArgs({ allowPositionals: true, options: { root: { type: 'string', default: process.cwd() }, slice: { type: 'string' }, 'legacy-ddd': { type: 'boolean', default: false }, 'read-only': {type:'boolean',default:false}, 'approved-slice': {type:'string'}, 'approved-slice-digest': {type:'string'}, 'approved-slice-approval': {type:'string'} } });
+  const { values, positionals } = parseArgs({ allowPositionals: true, options: { root: { type: 'string', default: process.cwd() }, slice: { type: 'string' }, 'legacy-ddd': { type: 'boolean', default: false }, 'read-only': {type:'boolean',default:false}, 'work-unit': {type:'string'}, 'approved-slice': {type:'string'}, 'approved-slice-digest': {type:'string'}, 'approved-slice-approval': {type:'string'} } });
   ensure(positionals.length === 1, '用法: validate-technical-design.mjs <合同> --root <项目根> [--slice <ID>] [--legacy-ddd]');
   const approvedOptions=['approved-slice','approved-slice-digest','approved-slice-approval'];
   ensure(!approvedOptions.some(key=>values[key])||approvedOptions.every(key=>values[key]),'执行增量必须完整给出持久化 Slice、字节摘要及本地批准引用');
-  const execution=values['approved-slice']?createApprovedExecutionContext({ref:values['approved-slice'],digest:values['approved-slice-digest'],approval_ref:values['approved-slice-approval']},{root:values.root}):undefined;
+  const execution=values['approved-slice']?createApprovedExecutionContext({ref:values['approved-slice'],digest:values['approved-slice-digest'],approval_ref:values['approved-slice-approval']},{root:values.root,work_unit_id:values['work-unit']}):undefined;
   const result = await validateTechnicalDesign(read(path.resolve(positionals[0])), { root: values.root, sliceRef: values.slice, legacyDdd: values['legacy-ddd'], readOnly:values['read-only'], execution });
   process.stdout.write(`${JSON.stringify(result, null, 2)}\n`);
 }

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/.pi/skills/yss-ui/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: "yss-ui"
-description: Use when implementing or reviewing YSS Vue pages that combine YSS wrappers with Ant Design Vue, including component selection, version compatibility, layout, Formily, tables, trees, hooks, overlays, themes, accessibility, API integration, and delivery verification.
+description: "选择和核验 YSS Vue 生产页面组件及 Ant Design Vue 兼容性；原型任务用 yss-prototype-stage。"
 ---
 
 # YSS UI 统一路由与交付门禁

package/template/.pi/skills/yss-ui-business-page-generation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yss-ui-business-page-generation
-description: 指导生成或改造 Vue3 YSS UI CRUD、列表、表单、详情、左树右表和弹窗抽屉页面，覆盖组件选型、模块拆分、Orval API、响应式高度、主题和原型验收；当用户要求生成 YSS UI 业务页或 CRUD 模块时使用。
+description: "生成或改造完整 YSS UI CRUD、列表、表单、详情或左树右表模块；组织页面、API 与验收。"
 ---
 
 # YSS UI 业务页面生成 Skill

package/template/.pi/skills/yss-up-springboot3/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yss-up-springboot3
-description: Use when YSS Spring Boot 3 / Spring Cloud 升级辅助技能。Use when auditing or migrating YSS backend services/components from Spring Boot 2.x or Spring Cloud 2021-era dependencies toward Spring Boot 3, Jakarta namespace, newer Spring Security, MyBatis, OpenFeign, gateway, validation, and related compatibility changes.
+description: "审查或迁移 YSS Spring Boot 2 到 3 的依赖、Jakarta 与 Spring Cloud 兼容性。"
 ---
 
 # yss-up-springboot3

package/template/.pi/skills/yss-use-table-height/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yss-use-table-height
-description: 指导 YTable、YEditTable、左树右表、分页列表、工具栏表格和弹窗/抽屉内表格使用 @yss-ui/hooks 的 useTableHeight 实现稳定自适应高度；当需要避免双滚动条、底部空白、容器撑开闪烁，或需要计入分页、工具栏、添加按钮偏移时使用。
+description: "用 useTableHeight 修复 YTable、YEditTable 自适应高度、双滚动条及分页或工具栏偏移。"
 ---
 
 # useTableHeight 使用

package/template/.pi/skills/yss-use-tree-height/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yss-use-tree-height
-description: 指导 YTree、左树右表、组织树、分类树、树搜索和 Tab/抽屉内树区域使用 @yss-ui/hooks 的 useTreeHeight 实现自适应高度；当树区域需要独立滚动、容器切换后高度不正确或需要扣除 YTree 内置搜索高度时使用。
+description: "用 useTreeHeight 实现 YTree 独立滚动，修复搜索区、Tab 或抽屉切换后的高度。"
 ---
 
 # useTreeHeight 使用

package/template/.pi/skills/yss-userinfo/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yss-userinfo
-description: Use when YSS current-user context, `AuthUserInfoUtil`, propagated user headers, JWT user payloads, Redis user cache, or background-user fallback is involved.
+description: "接入或排查 YSS AuthUserInfoUtil、用户头透传、JWT、Redis 用户缓存与后台用户上下文。"
 ---
 
 # yss-userinfo

package/template/.pi/skills/yss-validation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yss-validation
-description: Use when YSS Bean Validation/JSR-303 dependencies, validation messages, LiteFlow EL parsing, `ExpressParserFactory`, parser registration, or validation-error mapping is involved.
+description: "接入或排查 YSS Bean Validation、校验消息、LiteFlow EL 解析器与校验错误映射。"
 ---
 
 # yss-validation
@@ -55,3 +55,7 @@ Read `references/source-index.md` as a path-hint index whenever the task depends
 - Do not invent class names or configuration keys without checking the source index.
 - Do not replace component extension points with business-local framework code.
 - Do not broaden the task into unrelated YSS components unless the user asks.
+
+## 新脚手架平台约束
+
+消费批准切片架构身份中的 `platform_configuration`，与工程 Manifest 核对后使用对应 YSS 组件。Boot 2.7 使用 `javax` Web/Validation API；Boot 3.5/4.1 使用 `jakarta`。Boot 4 按 Jackson 3、对应自动配置和 starter 适配；不替换 `javax.sql` 等 Java SE 包。平台不一致、兼容条目缺失或候选未验证时回合同编译器阻断，不在业务实现中升级或替换组件。详见 仓库共享合同 `docs/engineering/backend-platforms.md`。

package/template/.pi/skills/yss-web-controller/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: yss-web-controller
-description: Use when generating or refactoring YSS Web Adapter Controllers, request DTOs, response VOs, validation, result wrappers, or Web Convertors from frozen contracts and stable Application interfaces.
+description: "按冻结合同与稳定 Application 接口生成或重构 YSS Controller、请求 DTO、响应 VO 和 Web Convertor。"
 ---
 
 # yss-web-controller
@@ -89,3 +89,7 @@ node scripts/generate_controller.mjs \
 - DTO/VO/WebConvertor 机械骨架可用 `controlled-generation`；权限、错误映射、校验语义和接口行为必须使用 `behavior-tdd`。
 - 写入必须位于合同 `allowed_write_paths`，并提供 Controller、DTO/VO、WebConvertor、契约/API 测试和实际验证结果。
 - 按统一 `YSS Skill Execution Result` 返回偏离与新增影响；出现新 API/schema、权限或响应包装变化时暂停并回到 实现合同编译器/生命周期。
+
+## 新脚手架平台约束
+
+消费批准切片架构身份中的 `platform_configuration`，与工程 Manifest 核对后使用对应 YSS 组件。Boot 2.7 使用 `javax` Web/Validation API；Boot 3.5/4.1 使用 `jakarta`。Boot 4 按 Jackson 3、对应自动配置和 starter 适配；不替换 `javax.sql` 等 Java SE 包。平台不一致、兼容条目缺失或候选未验证时回合同编译器阻断，不在业务实现中升级或替换组件。详见 仓库共享合同 `docs/engineering/backend-platforms.md`。