create-yss-spec 3.3.6 → 3.3.8

package/template/.pi/skills/yss-technical-design/scripts/validate-technical-design.mjs

@@ -1,5 +1,8 @@
 #!/usr/bin/env node
 import { readFileSync } from 'node:fs';
+import { validateEngineeringDesign } from './engineering-design.mjs';
+import { createApprovedExecutionContext, assertApprovedExecutionContext } from '../../../../scripts/lib/approved-execution-context.mjs';
+import { verifyArchitectureEvidence } from '../../../../scripts/lib/backend-architecture.mjs';
 import path from 'node:path';
 import { fileURLToPath, pathToFileURL } from 'node:url';
 import { parseArgs } from 'node:util';
@@ -39,7 +42,8 @@ function validateMvc(design) {
   if (!design.integration_catalog.length) ensure(text(design.integration_not_applicable_reason), '无外部集成必须说明原因');
 }
 
-export function verifyArchitecture(data, root) {
+export function verifyArchitecture(data, root, {execution,sliceRef}={}) {
+  if(execution)assertApprovedExecutionContext(execution,{root,technicalDesign:data,sliceId:sliceRef});
   const binding = data.architecture;
   const file = safe(root, binding.decision_ref);
   ensure(hash(readFileSync(file)) === binding.decision_digest, '架构来源摘要漂移');
@@ -57,6 +61,10 @@ export function verifyArchitecture(data, root) {
     const entry = record.repositories?.find(item => item.project_id === binding.project_id) ?? record;
     ensure(entry.project_id === binding.project_id && entry.architecture_identity?.architecture_family === binding.family, '技术设计与既有工程登记架构不匹配');
     ensure(!['stale','blocked'].includes(record.status) && !['stale','blocked'].includes(entry.status), '工程登记已失效');
+    if (entry.architecture_identity?.schema_version === 2) {
+      ensure(entry.architecture_evidence?.engineering_baseline && entry.architecture_evidence?.manifest, '既有工程登记缺少原始工程证据引用');
+      verifyArchitectureEvidence(entry.architecture_identity, { ...entry.architecture_evidence, repository_registration: { ref: binding.decision_ref, digest: binding.decision_digest } }, { root, execution });
+    }
   }
 }
 
@@ -87,14 +95,14 @@ function validateLocalTraceability(data, root, sliceRef) {
   }
 }
 
-export async function validateTechnicalDesign(data, { root = process.cwd(), sliceRef, legacyDdd = false } = {}) {
+export async function validateTechnicalDesign(data, { root = process.cwd(), sliceRef, legacyDdd = false, readOnly = false, execution } = {}) {
   if (data?.schema_version === 1) {
     ensure(legacyDdd, '旧 v1 合同需要显式 --legacy-ddd，仅按 DDD 兼容读取');
     const errors = validateDdd(data);
     ensure(!errors.length, errors.join('; '));
     if (sliceRef) ensure(data.status === 'approved', '切片只能消费 approved 设计');
     if (data.strategic_handoff || data.strategic_context_import_ref || data.upstream_impact?.source_kind === 'strategic-handoff') {
-      const result = await verifyConsumption(data, { root, sliceRef });
+      const result = await verifyConsumption(data, { root, sliceRef, readOnly });
       ensure(result.result === 'verified', JSON.stringify(result));
     }
     return { result: 'legacy-ddd-read-only', architecture_family: 'domain-driven', status: data.status };
@@ -103,12 +111,13 @@ export async function validateTechnicalDesign(data, { root = process.cwd(), slic
   ensure(data.digest === technicalDigest(data), '技术设计合同摘要不匹配');
   ensure(!['stale','blocked','drift','new_impacts'].includes(data.status), '设计状态不可消费');
   if (sliceRef) ensure(data.status === 'approved', '切片只能消费 approved 设计');
-  verifyArchitecture(data, root);
+  verifyArchitecture(data, root, {execution,sliceRef});
   ensure(data.inputs.some(item => item.kind === 'context' && item.ref === 'CONTEXT.md') && data.inputs.some(item => item.kind === 'spec'), '共同输入缺少根 CONTEXT.md 或 Spec');
   for (const input of data.inputs) ensure(hash(readFileSync(safe(root, input.ref))) === input.digest, `输入摘要漂移: ${input.ref}`);
   for (const ref of data.evidence_refs) safe(root, ref);
   if (data.status === 'approved') ensure(data.evidence_refs.length > 0, '已批准设计缺少评审证据');
-  if (data.architecture.family === 'domain-driven') {
+  if(data.design_scope==='engineering-only')validateEngineeringDesign(data,{root});
+  else if (data.architecture.family === 'domain-driven') {
     const errors = validateDdd(data.design);
     ensure(!errors.length, errors.join('; '));
     ensure(data.design.status === data.status, 'DDD 分支状态与共同合同不一致');
@@ -119,16 +128,19 @@ export async function validateTechnicalDesign(data, { root = process.cwd(), slic
   for (const seam of seams.values()) ensure(ids.has(seam.subject_ref), `测试 seam 设计对象悬空: ${seam.seam_id}`);
   validateLocalTraceability(data, root, sliceRef);
   if (data.strategic_handoff) {
-    const result = await verifyConsumption(data, { root, sliceRef });
+    const result = await verifyConsumption(data, { root, sliceRef, readOnly });
     ensure(result.result === 'verified', JSON.stringify(result));
   }
   return { result: 'ready-for-lifecycle-review', technical_design_id: data.technical_design_id, architecture_family: data.architecture.family, status: data.status, digest: data.digest };
 }
 
 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 } } });
+  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'} } });
   ensure(positionals.length === 1, '用法: validate-technical-design.mjs <合同> --root <项目根> [--slice <ID>] [--legacy-ddd]');
-  const result = await validateTechnicalDesign(read(path.resolve(positionals[0])), { root: values.root, sliceRef: values.slice, legacyDdd: values['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 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`);
 }
 if (process.argv[1] && import.meta.url === pathToFileURL(process.argv[1]).href) main().catch(error => { process.stderr.write(`${JSON.stringify({ result: 'blocked', errors: [error.message] })}\n`); process.exitCode = 1; });

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

@@ -0,0 +1,12 @@
+import test from 'node:test';import assert from 'node:assert/strict';import fs from 'node:fs';import path from 'node:path';
+import {fixture} from '../../../../scripts/fixtures/existing-backend/fixture.mjs';
+import {validateTechnicalDesign,technicalDigest} from '../scripts/validate-technical-design.mjs';
+import {enforceTechnicalDesign} from '../../../../scripts/lib/technical-design-boundary.mjs';
+function design(f){
+ f.write('spec.md','只增加默认关闭的工程诊断；不改业务领域或数据。');f.write('api.json',{openapi:'3.1.0',paths:{'/internal/identity':{get:{operationId:'identity'}}}});
+ const binding=ref=>({ref,version:'v1',digest:f.write(ref,fs.readFileSync(path.join(f.root,ref),'utf8')).digest});
+ const data={schema_version:2,technical_design_id:'technical-design.engineering',version:'v1',status:'ready-for-human',context_ref:'CONTEXT.md',design_scope:'engineering-only',architecture:{family:f.identity.architecture_family,source_kind:'existing-registration',project_id:f.identity.project_id,decision_ref:f.bindings.repository_registration.ref,decision_digest:f.bindings.repository_registration.digest},inputs:[{kind:'context',...f.write('CONTEXT.md','# 业务上下文\n'),version:'v1'},{kind:'spec',...binding('spec.md')},{kind:'api',...binding('api.json')},{kind:'engineering',...f.bindings.engineering_baseline,version:'v1'}],source_items:[{source_id:'scenario.identity',kind:'scenario',critical:true,source_ref:'spec.md'}],traceability:[{source_id:'scenario.identity',disposition:'implemented',tactical_refs:['component.build'],test_seam_refs:['test-seam.ok','test-seam.fail'],evidence_refs:['spec.md'],dependency_status:'known',dependent_slice_refs:['slice.identity'],scenario_tests:[{outcome:'success',seam_ref:'test-seam.ok'},{outcome:'failure',seam_ref:'test-seam.fail'}]}],design:{scope_reason:'仅工程配置',impact_assessment:Object.fromEntries(['domain_model','business_state','business_rules','business_persistence','schema_migration','ui_change','architecture_boundary_change'].map(k=>[k,'none'])),component_catalog:[{component_id:'component.build',responsibility:'工程诊断资源',build_unit_ref:'app',write_paths:['pom.xml'],depends_on:[]}],allowed_write_paths:['pom.xml'],read_dependencies:[{...f.bindings.engineering_baseline,purpose:'固定构建图'}],flow:['核验固定资源','缺失时失败'],failure_handling:'503',consistency_policy:{read_only:'read-only',transaction_boundary:'no write',concurrency:'bounded',idempotency:'read',cross_database_limit:'no atomic claim',timeouts:'5seconds',recovery:'restore original'},test_seams:[{seam_id:'test-seam.ok',kind:'engineering',subject_ref:'component.build',assertion:'当前资源返回身份'},{seam_id:'test-seam.fail',kind:'engineering',subject_ref:'component.build',assertion:'坏资源拒绝'}]},evidence_refs:['spec.md']};data.digest=technicalDigest(data);return data;
+}
+for(const family of ['domain-driven','layered-mvc'])test(`${family} engineering-only preserves real architecture without invented domain models`,async t=>{const f=fixture(family);t.after(f.cleanup);const data=design(f);await validateTechnicalDesign(data,{root:f.root});assert.equal(data.design.aggregate_catalog,undefined);});
+test('engineering branch rejects domain/catalog/path/unit/write-mode/evidence/seam bypasses',async t=>{const f=fixture();t.after(f.cleanup);for(const fault of ['domain','catalog','path','unit','write','api','seam']){const data=design(f);if(fault==='domain')data.design.impact_assessment.domain_model='changed';if(fault==='catalog')data.design.aggregate_catalog=[];if(fault==='path'){data.design.component_catalog[0].write_paths=['src/main/java/application'];data.design.allowed_write_paths=['src/main/java/application'];}if(fault==='unit')data.design.component_catalog[0].build_unit_ref='missing';if(fault==='write')data.design.consistency_policy.read_only='read-write';if(fault==='api')data.inputs=data.inputs.filter(x=>x.kind!=='api');if(fault==='seam')data.traceability[0].scenario_tests=data.traceability[0].scenario_tests.slice(0,1);data.digest=technicalDigest(data);await assert.rejects(()=>validateTechnicalDesign(data,{root:f.root}),undefined,fault);}});
+test('compiler cannot downgrade domain impact to engineering-only',t=>{const f=fixture();t.after(f.cleanup);const data=design(f);data.status='approved';data.digest=technicalDigest(data);const binding={...f.write('technical.json',data),version:'v1'};assert.throws(()=>enforceTechnicalDesign({technical_design:binding,architecture_identity:f.identity,slice_id:'slice.identity',conditions:['aggregate-impact']},{root:f.root}),/engineering|工程/);});

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

@@ -7,7 +7,7 @@ description: Use when generating or refactoring YSS Web Adapter Controllers, req
 
 ## 架构分流（先执行）
 
-读取当前合同的 architecture_identity 并与工程基线、仓库登记及 Manifest 核对；再且只读取 `references/profiles/<architecture_profile>.md`。支持的分支为 target-domain-model、layered-mvc-service、mvc-data-analysis-v1；成熟度以注册表为准，不能把 draft 称为受支持。MVC 不执行下文 DDD 专属规则，也不加载其旧分层 guide；组件、安全、批准合同、允许路径及执行证据规则仍共用。
+读取当前合同的 architecture_identity 并与工程基线、仓库登记及 Manifest 核对；再且只读取 `references/profiles/<architecture_profile>.md`。生成式分支为 target-domain-model、layered-mvc-service、mvc-data-analysis-v1；既有工程分支为 existing-domain-driven-maven、existing-layered-mvc-maven。成熟度以注册表为准，不能把 draft 称为受支持。MVC 不执行下文 DDD 专属规则，也不加载其旧分层 guide；组件、安全、批准合同、允许路径及执行证据规则仍共用。
 
 以下 Application / Domain Gateway / Infrastructure / Web module 叙述仅适用于 target-domain-model；MVC 的 service/core/repository/server/client 所有权由所选 Profile 引用定义。
 

package/template/.pi/skills/yss-web-controller/references/profiles/existing-domain-driven-maven.md

@@ -0,0 +1,5 @@
+# existing-domain-driven-maven
+
+只用于 `source_kind=existing-registration` 且 `architecture_family=domain-driven` 的受支持身份。先核验登记、工程基线、独立观测 manifest 和边界审查的当前摘要，再以工程基线中的实际 build unit、source root、package 与 architecture responsibility 映射确定 Web 落点；不得要求模板模块名、数量或生成器 manifest。
+
+Controller 只暴露冻结接口并调用合同指定的 Application 或 engineering-only orchestration seam。若批准合同将只读工程探针放在实际 Web build unit 内且没有 Application 源码写路径，保持该边界，不为满足生成式目录结构新建模块、聚合、Gateway 或业务服务。请求参数、Result 包装、错误脱敏、允许路径和真实 Maven/JAR 验证仍按共用规则执行。实际映射不清、越出登记源码根或改变业务架构时返回 `blocked`。

package/template/.pi/skills/yss-web-controller/references/profiles/existing-layered-mvc-maven.md

@@ -0,0 +1,5 @@
+# existing-layered-mvc-maven
+
+只用于 `source_kind=existing-registration` 且 `architecture_family=layered-mvc` 的受支持身份。以登记、工程基线、独立观测 manifest 与边界审查中的实际 build unit、source root、package 和 responsibility 映射确定 Controller/server 落点；模块名和数量可以与模板不同，不补造生成器或脚手架合同。
+
+Controller 只调用已登记的 service/use-case seam，保持公开 DTO、私有 DTO、错误脱敏和事务责任的实际映射。批准合同若只允许现有 build unit 内的 engineering-only seam，不得为套用生成式结构新建 client/server/service 模块。映射不清、Controller 直连 Repository、越界路径或业务架构变化均返回 `blocked`。

package/template/README.md

@@ -42,15 +42,15 @@
 4. `project-instance` 默认从 `yss-product-lifecycle` 的 `route` 模式开始，再由原生 `work-unit.*` 推进 Plan、Spec、产品设计、工程契约和 Ticket 正式化；`grill-with-docs`、`to-spec`、`to-tickets`、`implement` 仅作为用户显式调用的兼容入口。
 5. 实现仓库接入、YSS 路由、独立审查、fresh verification 和 Git checkpoint 以 `AGENTS.md` 的硬门禁为准。
 
-YSS skills 的公开发布投影维护在 [iloveZzz/yss-spec-dev-skills](https://github.com/iloveZzz/yss-spec-dev-skills)，发布清单和导出命令见 [skills 维护说明](./docs/agents/skills-maintenance.md)。
 
 YSS UI 组件知识同时通过项目级 MCP 配置提供；支持的客户端、Codex 全局安装和自检方法见 [YSS UI MCP 接入](./docs/user-guide/yss-ui-mcp.md)。
 
 ## 模板初始化 CLI
 
-`create-yss-spec` 的目标维护位置是独立 GitHub 仓库 [iloveZzz/create-yss-spec](https://github.com/iloveZzz/create-yss-spec)。本仓库不再包含 CLI 源码、测试、发布配置或开发过程记录。CLI 的使用方法已经合并到统一用户手册：
+`create-yss-spec` 的发布仓库是 [iloveZzz/create-yss-spec](https://github.com/iloveZzz/create-yss-spec)。用户从统一手册选择家族；CLI 源码、测试、打包和发布仍在各自仓库维护：
 
-- [YSS 用户手册：创建、接管和更新项目](./docs/user-guide/用户手册.md#创建接管和更新项目)
+- [YSS 用户手册：CLI 能力与写入方式](./docs/user-guide/用户手册.md#cli-能力与写入方式)
+- [YSS 用户手册：接管、同步与恢复](./docs/user-guide/用户手册.md#接管同步与恢复)
 
 推荐入口：
 
@@ -106,11 +106,9 @@ scripts/verify-template-fast
 | [docs/process/MATT-POCOCK-ENGINEERING-SKILLS.md](./docs/process/MATT-POCOCK-ENGINEERING-SKILLS.md) | Matt Pocock Engineering Skills 集成与使用 |
 | [docs/process/lifecycle-registry.yaml](./docs/process/lifecycle-registry.yaml) | 生命周期结构事实源：主阶段、门禁、产物、工作单元、证据与稳定 ID |
 | [docs/process/harness-process-tailoring.md](./docs/process/harness-process-tailoring.md) | 小改动 / 中等变更 / 新模块的流程裁剪指南 |
-| [docs/process/template-engineering-overview.md](./docs/process/template-engineering-overview.md) | 模板工程定位、产品线、控制平面、分发边界与维护工作流 |
 | [docs/process/harness-executive-blueprint.md](./docs/process/harness-executive-blueprint.md) | 面向业务方和管理者的 Harness 一页式蓝图 |
 | [docs/process/implementation-repo-integration.md](./docs/process/implementation-repo-integration.md) | 外部前端 / 后端实现仓库接入与跨仓库切片绑定 |
 | [docs/agents/README.md](./docs/agents/README.md) | Agent 协作文档目录说明 |
-| [docs/agents/skills-maintenance.md](./docs/agents/skills-maintenance.md) | Agent skills 安装与维护 |
 | [docs/user-guide/yss-ui-mcp.md](./docs/user-guide/yss-ui-mcp.md) | YSS UI MCP 项目配置、全局安装边界与自检 |
 | [docs/plan/IDEATION.md](./docs/plan/IDEATION.md) | 机会构想方法 |
 | [docs/architecture/README.md](./docs/architecture/README.md) | 架构设计 + 审查清单 |
@@ -130,4 +128,4 @@ scripts/verify-template-fast
 
 ## 按职责使用与升级
 
-[五类项目用户手册](docs/user-guide/用户手册.md)提供选型、初始化及升级；[设备借用贯穿案例](docs/user-guide/设备借用贯穿案例.md)演示战略、后端、前端与统一验收。[全部手册](docs/user-guide/用户手册索引.md)区分日常使用与维护入口。GitHub 当前能力与 npm 发布快照分别核对。
+[四个现行家族用户手册](docs/user-guide/用户手册.md)提供选型、初始化及升级；[设备借用贯穿案例](docs/user-guide/设备借用贯穿案例.md)演示战略、后端、前端与统一验收。[全部手册](docs/user-guide/用户手册索引.md)给出本体和子项目入口。GitHub 当前能力、npm 发布版本与实例模板快照分别核对。

package/template/docs/agents/backend-architecture-profiles.md

@@ -4,6 +4,10 @@ Profile、模块闭包、生成器、成熟度和 Recipe 的权威映射见 `yss
 
 执行前比较工程基线、仓库登记、Manifest 与当前合同的 `architecture_identity`。缺失、digest 漂移、Profile 不匹配或越界写路径均停止；既有工程不能自动重选架构。新 Profile 的真实编译及首切片验证未通过前保持 `draft`，不能设置 `ready-for-agent`。
 
+## 既有工程适配
+
+`existing_project_profiles` 与下述生成器 Profile 独立维护。首版两个 Maven 适配器通过真实 Git/POM 三方核验、对应架构的成功/失败行为测试与 Maven test/package 后标记 supported；依据见 `.template-source/evidence/maintenance/2026-09-12-existing-project-delivery/maven-adapters-04.json`。这是适配协议支持证据，不是实际产品批准、数据库兼容或真实跨仓 S0 结论。每个工程仍须自己的固定来源、架构边界审查和执行证据，详见 `docs/process/existing-backend-architecture.md`。生成器原有 draft 和首切片要求保持。
+
 ## MVC 分层
 
 - `layered-mvc-service` 的用例层为 `service`；`mvc-data-analysis-v1` 的用例层为 `core`。后者是薄应用层，不是合并 Domain 的容器。MVC 不加载 `yss-domain`，不生成 DDD Gateway。

package/template/docs/agents/yss-skill-registry.yaml

@@ -6,6 +6,19 @@ description: >-
   单一可执行注册表。实现合同编译器与生命周期编排器只消费通过本表校验的
   canonical 技能；skills-lock.json 继续独立持有来源、hash 与投影完整性。
 canonical_content_root: .agents/skills
+existing_project_profiles:
+  existing-domain-driven-maven:
+    source_kind: existing-registration
+    architecture_family: domain-driven
+    build_system: maven
+    maturity: supported
+    required_roles: [domain, application, infrastructure, web]
+  existing-layered-mvc-maven:
+    source_kind: existing-registration
+    architecture_family: layered-mvc
+    build_system: maven
+    maturity: supported
+    required_roles: [application, persistence, web]
 architecture_profiles:
   target-domain-model:
     architecture_family: domain-driven

package/template/docs/design/templates/prototype-confirmation-template.md

@@ -52,7 +52,7 @@
 确认结论：
 允许进入下一阶段：是 / 否
 阻断原因：
-- 
+-
 补充说明：
-- 
+-
 ```

package/template/docs/design/templates/prototype-review-checklist.md

@@ -60,9 +60,9 @@
 结论：通过 / 阻断
 内部独立审查：`check.prototype-reviewed` 通过 / 不通过
 阻断项：
-- 
+-
 非阻断建议：
-- 
+-
 下一步：
 - yss-prototype-stage 计算档位并进入对应适配器 / 回到产品设计补齐状态与风险 / 进入原型交付物构建
 ```

package/template/docs/plan/templates/market-analysis-template.md

@@ -44,9 +44,9 @@
 
 ## 关键结论
 
-1. 
-2. 
-3. 
+1.
+2.
+3.
 
 ## 数据来源
 

package/template/docs/plan/templates/user-pain-points-template.md

@@ -23,13 +23,13 @@
 ## 痛点分类
 
 ### 功能痛点
-- 
+-
 
 ### 体验痛点
-- 
+-
 
 ### 信任痛点
-- 
+-
 
 ## 未被满足的需求
 

package/template/docs/process/delivery-preflight.md

@@ -0,0 +1,72 @@
+# 只读交付预检
+
+`scripts/preflight-delivery --input <输入清单> --stage prepare|build|export|accept --json` 在任何初始化、构建或写入接收状态之前读取当前原始资产。它不初始化项目、不运行清单中的命令、不启动服务、不发 HTTP、不解压 ZIP、不生成批准或收据。结构化结果证明本次读取到的前提；执行边界仍须重新验证。
+
+输入采用 [delivery-preflight-input.schema.json](schemas/delivery-preflight-input.schema.json)，输出采用 [delivery-preflight-result.schema.json](schemas/delivery-preflight-result.schema.json)。`schema_version` 均为 1。退出码：当前阶段就绪为 `0`，存在阻断为 `1`，协议、参数或输入语法无效为 `2`。CLI 总是输出 JSON；`--json` 是显式调用标志。库入口为 `await preflightDelivery(input, {stage, root})`，与 CLI 使用同一结果结构。
+
+## 输入与事实来源
+
+- `governance_root` 相对调用工作目录解析；也可显式给绝对治理根。省略时使用库的 `root` 或 CLI 当前工作目录。产品资产只能来自明确的 `project-instance`。`planned_initialization: true` 表示拟初始化目标：列出缺项和正常恢复入口，不猜测身份，也不生成文件。
+- `delivery_kind` 可选 `complete`（默认全链诊断）、`strategic-handoff` 或 `backend-delivery`。按事实所有者分流，避免源包的导出反过来依赖消费它的下游合同与交付。两个导出 CLI 会核对并固定自己的类型、治理根和被导出的源文件，不能用另一来源的预检结果放行。
+- `scope` 必须给出 `repository_id`、`project_id`、`slice_id` 与非空 `operation_ids`。空清单不能取得就绪结果。`ui_mode` 默认为 `existing-baseline`；显式可选 `prototype` 或带 `ui_not_applicable_reason` 的 `not-applicable`。战略包若实际含 UI 基线，不接受“不适用”覆盖它。
+- `architecture_identity` 消费现有身份协议。`architecture_bindings` 使用 `repository_registration`、`engineering_baseline`、`manifest` 三个 `{ref,digest}` 原始引用。先逐份核验身份、来源类型和基本事实，再调用 `verifyArchitectureEvidence` 核对三方及实际 Git/Maven 工程；不存在的生成来源不能伪填。
+- `assets` 中各引用采用 `{ref,digest,id?,version?,approval_ref?}`。摘要是当前文件字节的 `sha256:`。需要批准的 API、技术设计、Slice 和 UI 基线须提供资产 ID、版本及原始批准引用，并核验真实决定和当前字节覆盖。
+- 所有 `ref` 相对治理根解析，拒绝路径越界、symlink 和远程地址。UI 证据包内部引用相对其 manifest 所在目录；包内批准可通过战略来源完整复验。
+
+## 阶段与诊断
+
+| 最早阻断阶段 | 当前阶段必须具备的前提 |
+|---|---|
+| `prepare` | 明确治理身份与根词汇、非空目标范围、受支持架构身份、三份原始来源和实际工程核验 |
+| `build` | 上述前提、冻结 OpenAPI、已批准技术设计、已批准且事实源新鲜的 Slice Contract |
+| `export` | 上述前提、适用 UI 基线、实际构建制品、部署验证、批准的战略交接来源 |
+| `accept` | 上述前提、完整后端交付语义；仅当交付 v2 目标绑定协议启用时要求本地授权 |
+
+后续阶段缺项照样列出，但不阻断当前较早阶段。所有可独立读取的前提都会检查，失败不会遮蔽其他资产问题。依赖缺失使用 `pending`（尚不可判定），不会伪装为成功或衍生大量“错误内容”。缺少部署所绑定的交付依据时，部署的交叉核验为 `pending`；导出前需准备相应交付记录。
+
+上表是 `complete` 的全链诊断。实际导出按以下所有权收敛：
+
+- `strategic-handoff` 核验自身治理根、词汇、源资产批准、handoff 范围和 UI 基线。后端三方身份、技术设计、Slice、构建、部署及后端交付属于下游待履行项，诊断的 `blocking_stages` 为空，不阻断战略导出。仅当清单明确给出冻结 API 资产时额外核验 API；不要求全部战略交接先 Freeze API。
+- `backend-delivery` 在 `export` 阶段要求后端交付**源记录**，以它核验部署依据和已经先导出的战略包。源记录不是尚未生成的后端包。UI 与战略来源由绑定的战略包只读验证，不要求后端治理根复制源资产；清单可额外提供，但给出的冲突仍须修正。
+- 输入不要求已导出的后端包、当前 `accepted` 记录或尚未生成的接收收据。`accept` 的落地应从包和目标仓原始授权读取候选事实，先完成只读校验，成功后才写新状态；当前两个导入 CLI 保持原协议，不能为复用本清单而强制先存在接收成功记录。
+
+每项诊断包含稳定 `code`、`status`、责任方 `owner`、事实来源 `source`、原始引用 `evidence`、`blocking_stages`、正常恢复路径 `recovery` 和说明 `message`。状态为 `ready`、`missing`、`conflict`、`stale`、`unsupported`、`pending` 或有原因的 `not-applicable`。单项 `ready` 只表示该项，不能替代整体结果。
+
+## 构建、交接与兼容边界
+
+`assets.build` 指向与后端交付协议一致的独立构建记录 `{source_commit,artifact_digest}`；`assets.build_artifact` 绑定实际制品文件，预检读取其字节并与构建摘要核对。这样保持原交付 build 格式，同时验证真实制品。`assets.deployment` 复用 `backend-delivery-verification` 的 `backend-deployment` 记录；逐项核验成功执行时间和原始日志，并与后端交付依据摘要比较，绝不执行记录中的 `command`。
+
+战略来源通过 `inspectSource` 复验。技术设计消费与后端交付复验使用严格 `readOnly: true`；可完整只读验证的目录包正常承接。必须解包或缺少可直接读取的来源布局时，明确返回未就绪及恢复信息；不得悄悄写临时目录或将 ZIP 的摘要相同当作内容验证通过。旧生成式身份和原型仍按原有规则读取，未知版本明确拒绝。预检不把 `verified` profile 自动升级为 `supported`。
+
+`assets.local_authorization` 只随经真实 S3a 验证后启用的目标绑定协议 v2 生效；在协议尚未提供可复用只读验证入口时，预检明确拒绝该未知能力。旧 v1 交付不额外要求尚未启用的本地授权。
+
+## 批准后的实现增量
+
+`export` / `accept` 从 `assets.slice_contract` 的当前持久化字节与本地批准生成进程内受信上下文，再共同传给架构、技术设计和编译新鲜度检查。输入清单不能提交 `execution` JSON；`status: approved`、`approved: true` 或扩大后的路径数组都不能建立权限。上下文在每个消费边界重新读取原始文件，不缓存批准成功结果。
+
+主模板当前将 `gate.slice-contract-approved` 配置为生命周期主控，`approval_ref` 指向现有生命周期 checkpoint：对应 gate 为 `approved`，`subject_ref` 指向本次 Slice；`human_review.implementation` 与 `human_review.user_decisions` 通过已有 `assertImplementationDecision` 核验原始回复、当前合同字节、Ticket、实现仓库、允许写范围和工程基线。不得为该主控 gate 伪造 `approval-record`。来源明确将此 gate 配置为会签时，遵守来源会签协议；当前专用后端同时列入主控及双数字人会签，显式会签规则优先，需要绑定当前合同身份、版本、摘要的批准记录，不能复用主模板 checkpoint。这里复用来源现有批准规则，不另建并行门禁。
+
+既有工程身份 v2 的原始 Slice 必须使用对象形式的 `lifecycle_refs` 和 `readiness`，其中 `ticket`、`engineering_baseline` 为非空引用，`blockers`、`stale_inputs`、`not_applicable` 为数组。数组附加属性在 JSON 序列化后会丢失，因此在批准及预检边界先拒绝该结构；这里不要求运行中生命周期状态的就绪布尔字段，也不改变旧交付最小合同的批准语义。
+
+合法输出增量只在 Slice 批准范围与工程登记允许范围的交集内放行；固定输入身份、登记引用、基线、构建映射或技术设计被替换仍会失效。`evaluateContractFreshness` / `validateExecutionResult` 的当前上下文使用 `approved_slice: {ref,digest,id?,version?,approval_ref}`；验证器自行重读和核验，不接受任意调用方执行许可。
+
+技术设计子进程仅传递原始 `--approved-slice`、`--approved-slice-digest`、`--approved-slice-approval` 绑定，在子进程内重新验证；三项须同时提供。单独传 `--execution '{"approved":true}'` 会被参数解析拒绝。后端交付源码中的 Slice 批准复验也消费相同 helper；可移植导出时，须在正常 `supporting_files` 中包含 checkpoint 引用的实施范围清单、原始决定和相关来源，不能只打包一个批准状态。
+
+工程接入技能在既有 Java/Maven 跨仓接入前运行 `prepare`，补证后重跑。两个导出 CLI 已在外层、任何导出写入之前复验 `export`。v5 的既有 UI 战略导出与包含既有架构身份 v2 的后端导出必须提供 `--preflight-input`；旧路径可选，原批准规则仍独立有效。以下命令中的清单必须绑定对应源文件及其当前摘要：
+
+```sh
+scripts/strategic-handoff export --source-root /governance/source --handoff docs/handoff.yaml --output /delivery/strategy-v1 --preflight-input /inputs/strategic-preflight.json
+scripts/backend-delivery export --source-root /governance/backend --delivery docs/backend-delivery.yaml --output /delivery/backend-v1 --preflight-input /inputs/backend-preflight.json
+```
+
+战略清单设 `delivery_kind: strategic-handoff`，包含 `assets.strategic_handoff` 和 `assets.ui_baseline`；后端清单设 `delivery_kind: backend-delivery`，包含工程、合同、构建、部署和 `assets.backend_delivery` 原始绑定。缺清单时错误给出恢复文档；预检失败保留全部结构化诊断，不创建输出目录。
+
+编译和接收外层可复用此库；不要从本库内部调用的纯验证函数无条件递归调用完整预检。当前纯验证入口包括架构证据、技术设计、战略来源及后端交付检查。
+
+预检使用当前工具安装根的 `harness-profile.yaml` 判定技术验证能力，调用清单的 `governance_root` 不能改变职责。主模板及 `harness.backend-delivery` 验证原始后端技术设计、Slice 与批准后的实现增量；战略及前端 profile 接收已导出的受控包。向后两类 profile 显式传入原始 `technical_design` 或 `slice_contract` 会得到 `PREFLIGHT_TECHNICAL_DESIGN_UNSUPPORTED` / `PREFLIGHT_SLICE_CONTRACT_UNSUPPORTED`，诊断包含源引用、责任人和转交后端的恢复入口，不尝试加载未安装的创作技能。已声明后端能力但分发文件缺失同样阻断，不能被视为验收成功。
+
+`verify-delivery-preflight-scenarios` 在所有 profile 执行共有 CLI、只读、阶段和战略 v5 场景。两类真实 Git 原始工程的 synthetic 机制测试及批准增量测试只在主模板和后端 profile 执行；其他 profile 输出带职责原因的 `not-applicable` 并实测显式技术资产的 unsupported 诊断。此分流不豁免主模板或后端的正例，也不等同于真实产品 S0–S6/O1 验收。
+
+既有 UI 原始基线可保留 `ready-for-human` 字节，由外部产品批准绑定这些当前字节；预检仍必须验证该批准。不能要求先把原始资产改为 `approved` 再沿用旧摘要确认，以免制造批准后的内容漂移。
+
+JSON Schema 批处理按序列化后的 UTF-8 字节长度传输输入，验证器只读取该长度；完整 JSON 到达后不再等待 stdin EOF。截断或非法输入帧返回明确协议错误；同步校验默认 30 秒超时，返回 `JSON_SCHEMA_TIMEOUT`，超时不能记为验证通过。此内部传输保持原 schema 验证语义，不写临时资产或接收状态。共有回归使用真实 Python 验证器和保持写端开启的测试桥，覆盖 Unicode、大输入/错误输出、非法 schema、截断帧与超时。

package/template/docs/process/document-writing.md

@@ -61,7 +61,11 @@
 
 ## 4. 进度与会签提示
 
-进度更新说明本轮有意义的变化、当前阻塞和接下来由谁处理。状态没有变化时，无须重述全部计划。已授权且 Agent 可以完成的动作继续执行，避免把操作转交用户。
+仅在用户询问状态、阶段切换或出现阻塞时，简短展示四项信息：**当前阶段、当前阻塞、谁处理、下一动作**。可以用一句话或四行表达，不要求表格。普通问题直接回答；其他进度更新只说明本轮有意义的变化，状态未变时不重复整套说明。
+
+状态读取已有 checkpoint 和适用验证结果，不建立或要求用户填写另一套状态文件。未核验的阶段或阻塞情况写“待核验”；只有当前适用证据支持时才能写“无阻塞”。证据过期应明确指出过期输入及恢复动作，不能沿用历史通过结论。责任人按已有登记填写，缺失写“未登记”，不自行指派；下一动作说明如何补齐登记或核验。
+
+默认只展示当前需要处理的事项，证据路径按需展开。查看状态本身不改文件，也不触发全套验证；推进阶段时仍执行原有适用校验。已授权且 Agent 可以完成的动作继续执行，避免把操作转交用户。
 
 请求决定时展示当前版本、推荐方案及理由、实质选项和取舍、风险、批准范围与后续动作，遵守既有用户决定协议。可以突出当前最重要的问题，但所有影响决定的阻塞和选项都应可见。一次回复需要多个相互独立的决定时，分别说明各自影响。
 

package/template/docs/process/existing-backend-architecture.md

@@ -0,0 +1,31 @@
+# 既有后端工程的架构身份
+
+既有工程以 `source_kind: existing-registration` / 身份 schema v2 接入，不反推生成器历史。原生成式身份与脚手架合同继续使用原字段和 H2/not-bound 语义。外层 Slice Contract v2、Technical Design v2、根身份/生命周期状态 v1 不改变。
+
+支持 Java/Maven 的 `existing-domain-driven-maven`、`existing-layered-mvc-maven`。适配 Profile 由技能注册表的 `existing_project_profiles` 持有，不与生成器 Profile 共用成熟度。编译器复用对应架构 Recipe/capability，并将实际责任路径传给实现者；单 JAR 内多个包可以分别承担职责，不生成伪 Maven 层模块。
+
+## 三份原始证据
+
+编译输入的 `architecture_evidence` 包含 `repository_registration`、`engineering_baseline`、`manifest`，每项均为 `{ref,digest}`。引用相对治理根，摘要为原字节 SHA-256。实现者不得传三个内联身份对象替代原文件。
+
+- 登记含 `repository_id/project_id`、`status: current`、`local_worktree`、`project_root`、`repository_url`、`owner`、`allowed_write_paths`、`verification_commands`、`architecture_identity`。`architecture_evidence` 引用工程基线与 manifest，自身不自引用。实际 Git 根、origin、HEAD 必须与登记和固定基线一致；origin 只用于核对已登记来源，不产生授权。
+- 工程基线使用 `schema_version: 1/kind: existing-engineering-baseline`，含 `id/version/status: current/author`、项目身份、`architecture_identity`、`source`、`build_units`、`boundary_scope`、验证命令、数据库声明及 `boundary_review`。仅将有证据的功能范围登记为 DDD/MVC，不宣称混合仓整体同构。
+- 观测 manifest 使用 `schema_version: 1/kind: existing-project-observation`，含同一项目身份、`architecture_identity`、`source`、`build_units`。它记录当前可重复读取的事实，不记录虚构的生成器完成状态。
+
+`source` 含真实 `base_commit`、`roots`、`files`；每个文件含 `path/base_blob/sha256`。Git 树必须覆盖声明范围，源码实际字节必须匹配；初始有限补丁另外登记 `patches` 的 `path/base_blob/sha256`，并由基线审查覆盖。排除 `.git`、`target`、`node_modules`。固定构建输入必须覆盖父 POM、Wrapper、所选单元及实际构建消费的受管源码；不能只取两个修改文件声称固定完整工程。
+
+`build_units` 每项含 `id/artifact_id/pom_ref/roles/role_paths/depends_on`。直接解析 POM 核对 artifact、声明的仓内依赖和 reactor 模块闭包；角色路径必须存在于冻结源码及 `boundary_scope`。Profile/父 POM的动态解析、私有 SNAPSHOT 实际字节、完整构建结果另由构建验证证据证明，静态 POM 观测不能代替 Maven 构建。
+
+身份仅保存 `schema_version/source_kind/architecture_family/architecture_profile/repository_id/project_id/source_digest/build_units_digest`。后两个摘要使用规范 JSON（对象键排序、数组保持顺序）的 SHA-256。三份文件保存同一身份，编译器必须重新读取原引用核验，不能仅比较身份副本。
+
+## 审查与数据库
+
+`boundary_review` 引用所属治理仓角色策略中的真实架构审查会签记录：主模板为 `check.architecture-reviewed`，专用后端模板为 `gate.technical-design-approved`。两者均必须绑定工程基线本身，且通过本地角色与门禁策略核验；不能凭记录自述跨职责替代，审查必须来自不同于基线作者的执行者，附可读审查证据。`artifact_bindings` 绑定基线 id/version 及去除 `boundary_review` 后的规范 JSON 摘要，避免自引用。基线的完整文件摘要再由仓库登记、合同绑定。此审查不替代当前 Slice 合同批准。
+
+`databases.verification` 与 `databases.production` 分别记录 `declared/verified/unknown/not-applicable`。`verified` 必须包含 engine/version/environment_id 及原字节 verification 引用；被引用记录绑定 source_digest、相同环境/引擎/版本、实际命令/退出码/时间和原始日志摘要。声明 PostgreSQL、装有驱动或 H2 通过均不能当作 PostgreSQL 实库验证；生产未知据实保留未知。
+
+## 新鲜度与恢复
+
+编译时只接受固定输入；基线、登记、观测、审查或原始源码改变，必须补证并重新编译/批准。合同 `resolution.architecture_evidence` 冻结三方引用，在复验时重新加载。技术设计的 `existing-registration` 引用必须指向同一正式登记。
+
+批准后验证输出时，只允许合同与登记允许路径的交集作为源码增量；构建角色与依赖仍须一致。原始输入仍保持不变，输出作为本轮执行结果核验，不把每次正常业务编辑判为基线替换。新增架构、未声明依赖、身份改变或越界输出继续失效并重路由。错误以 `ARCH_*` 原因区分证据缺失、来源不支持、三方冲突、源码漂移、构建冲突、审查过期和数据库未验证，正常恢复是修正事实源、复验、重新编译及取得必要批准。

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

@@ -0,0 +1,40 @@
+# 既有 UI 的受控交接
+
+适用于已有 Vue/前端工程的用户界面、导航、交互、状态与权限体验均无改动的交接。`existing-ui-baseline` 是对实际源码和执行结果的观测包；批准和截图不能将它转换为原型。实际 UI 或后端引起的 UI 体验变化必须回到产品设计与原型流程。
+
+## 事实与原始文件
+
+`existing-ui-baseline.schema.json` 定义 v1 外层合同。独立 `existing-ui-baseline.json` 与所有证据文件放在同一目录；引用均相对此目录，禁止绝对路径、越界和符号链接。未知类型与版本拒绝。
+
+- `source` 绑定登记的 repository/project ID、固定 Git commit、源码快照树摘要、锁文件和独立源码观测 manifest。观测 manifest 为 `schema_version: 1`、`kind: existing-ui-source-observation`，包含相同身份、`source_digest` 和精确 `files: [{path,digest}]`。源码文件集必须与实际快照一致；不得把不属于固定提交的源码标记为该提交。
+- `build` 指向原始构建记录：`schema_version: 1`、`source_commit`、`source_digest`、`lock_digest`、实际 `command/executed_at/exit_code`、`evidence: [{ref,digest}]` 及构建输出树 `output: {ref,digest}`。前端优先 `pnpm`；执行记录不能由后续验证器补造。
+- `capture` 指向原始浏览器捕获记录：相同源码和执行字段、`build_digest`、`openapi_digest`、`ui_change: none`、原始日志及 `cases`。每个 case 的 route、state、viewport、source_refs、actions、image、api 必须与基线逐项相同。
+- 每个 case 将精确源码文件、动作说明、PNG 截图、视口与 API 记录绑定到唯一 `case_id`。API 记录包含 `schema_version: 1`、`case_id`、源码/构建/OpenAPI 摘要以及 `exchanges`；每次交换记录实际 operation ID、method、URL、status、executed_at 及原始 request/response 文件摘要。操作必须存在于冻结 OpenAPI 且 method/path 一致。
+- `replay` 是可离线阅读的重放说明，不宣称离线运行真实服务。文件内不得保存访问令牌或个人业务数据；试验用合成数据。
+
+所有文件摘要使用 `sha256:` 加十六进制 SHA-256。源码与构建树使用共享 `treeDigest` 的规范文件清单算法。源码变更、日志替换、锁文件变化、动作/截图/API 不一致均使验证失败。验证只说明输入文件间的绑定和完整性；必须另有实际采集、可审阅原始执行与真实批准，不能凭自洽 JSON 宣称真实运行。
+
+## 当前批准与交接版本
+
+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 或自签批准。该门禁的原始回复随交接闭包携带。
+
+既有 manifest 的 `status` 表达准备状态，展示后保持其原字节不变。`ready-for-human` 清单可在当前批准记录验证通过后交接；有效批准由现有批准记录及真实用户决定持有，不要求确认后把清单改为 `approved`。结构验证不授予批准，导出、包验证和接收均须核验完整批准链。确认后任何字节改写（包括只改 status）仍使原决定失效。旧原型分支仍要求原型自身为 `approved`，不转换历史批准。
+
+Frontend Strategic Preflight v2 使用 `ui_baseline_kind/ui_baseline_ref`；Frontend Delivery Acceptance v3 使用 `ui_baseline_kind` 与每用例 `baseline_case_ids`。协议必须对应 Handoff v5，禁止降级到 v1 预检或 v1/v2 接收。旧 Handoff v3/v4 及其原型验证不变。
+
+## 运行时入口
+
+- `validateExistingUiBaseline(data,{bundleRoot})` 返回 `{errors}`，校验观测原始文件，不生成或授予批准。
+- `ui-baseline.mjs` 导出 `uiBaselineKind`、`uiBaselineRef`、`uiBaselineCaseIds`、`uiBaselineSourceKeys`、`hasConsumerRoutes` 和 `validateHandoffUiBaseline(root,handoff)`。消费者应通过这些入口分派，不散落版本或字段假设。
+- `inspectSource` 负责完整交接、门禁和真实决定；export/verify/import 与前端接收复用该验证。
+- `openBundle(input,action,{readOnly:true})` 只验已展开的受支持源布局，不写临时文件。ZIP 报 `readonly-extraction-required`，旧布局无法映射时报 `readonly-source-layout-required`，两者都不是已通过。默认模式保留旧包验包兼容性。
+
+机制验证运行 `scripts/verify-existing-ui-baseline-scenarios`，其中数据和决定均明确标记为 synthetic fixture，不能进入真实试验批准链。真实 Java/Vue 闭环、S0–S6 与 O1 由维护主控独立记账。
+
+### 固定 Vite 代理前缀
+
+真实浏览器 URL 可包含冻结 API 路径之外的代理前缀。可选 `api_route_mapping` 仅支持 `kind=vite-env-prefix-rewrite`：同时绑定固定源码中的 Vite 配置和所用模式环境文件，声明 `prefix` 与空 `replacement`。首版识别 `apiBase = env.VITE_API_BASE_URL || '/api'` 及 `proxy[apiBase]` 中 `path.replace(new RegExp(`^${apiBase}`), '')` 的既有约定；环境文件必须唯一声明相同 `VITE_API_BASE_URL`。其他表达式明确拒绝，不能执行包内 JavaScript 或随意删 URL 前缀。
+
+请求保留实际观测 URL。验证仅在完整路径段匹配已绑定前缀后比较冻结路径；未声明映射时沿用完整路径精确匹配。配置、环境、模式和实际启动记录属于基线审阅范围；静态绑定不声称验证任意 JavaScript 的运行语义。历史采集缺少构建输出摘要时保留缺口，不能用后补摘要替代同时期运行证据。

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

@@ -6,7 +6,7 @@
 
 战略方维护业务规则、Spec、页面流程和视觉基线；后端维护 API 及后端交付；前端维护工程设计、页面和验收证据；统一管理方维护基线引用、跨仓切片与业务验收汇总。
 
-前端消费需求可在上游设计时提前反馈。前端项目在战略和后端交付尚未齐备时，只能验包、诊断和回交缺口。两类输入通过接收核验后，可以准备前端工程设计、实现计划和 Slice Contract；合同获准前不得写代码。
+前端消费需求可在上游设计时提前反馈。Handoff v4/v5 导入后的 Frontend Strategic Preflight 可在后端交付前完成战略输入、Context、相应 UI 基线和源规则追踪核验，并允许起草前端工程设计与实现计划；它固定返回 `ready_for_agent: false`。仅当 Backend/API/Data 影响命中时，最终接收才等待后端交付；UI-only 路径使用有依据的 `backend-not-applicable`。Slice Contract 获准前均不得写代码。
 
 ## 后端导出与前端导入
 
@@ -28,11 +28,24 @@ scripts/backend-delivery import --bundle <directory-or-zip> --target-root <front
 
 ## 接收与启动
 
-导入只产生 `frontend-acceptance-draft.json`，不会批准资产。接收方完成正式词汇对账并按 `schemas/frontend-delivery-acceptance.schema.json` 准备接收记录：
+Handoff v4/v5 先生成 `frontend-strategic-preflight-draft.json`；补齐正式 Context Reconciliation 后执行 `scripts/verify-frontend-strategic-preflight`。通过仅允许进入前端工程设计草案。
 
-- `backend_delivery` 绑定后端导入收据和包摘要。
+后端交付导入只新增匹配的 backend binding 并产生 `frontend-acceptance-draft.json`，不会覆盖已填写的前端预检/设计草案，也不会批准资产。最终接收方按交接版本准备记录，禁止静默降级：
+
+| 战略交接 | 前端战略预检 | 最终接收 | 用例基线字段 |
+|---|---|---|---|
+| Handoff v3（历史） | 原历史路径 | Acceptance v1，要求后端交付 | `visual_case_ids` |
+| Handoff v4 | Preflight v1 | Acceptance v2 | `visual_case_ids` |
+| Handoff v5 | Preflight v2 | Acceptance v3 | `baseline_case_ids` |
+
+v5 的预检和接收都声明 `ui_baseline_kind`，必须与战略包一致。原型分支继续原视觉/原型要求；既有 UI 分支使用 [existing-ui-baseline v1](existing-ui-baseline.md)，只允许无 UI/交互/状态/权限体验改动并已取得当前基线确认的工程。真实截图不得自行升级为原型批准。
+
+接收记录遵守以下绑定：
+
+- `strategic_preflight` 绑定当前预检文件及字节摘要。
+- `backend_dependency.mode: required` 时，`backend_delivery` 绑定真实后端导入收据和包摘要；`not-applicable` 时必须与 Handoff v4/v5 backend 路由的影响引用、原因和证据一致，且不得绑定后端收据。
 - `strategic_handoff` 绑定战略导入收据、包摘要、正式 `context_reconciliation_ref` 和全部源规则/关键场景的承接 rows。
-- `frontend_cases` 绑定业务规则/场景、成功或失败结果、已交付接口、Visual Baseline `case_id` 和可读取的用例说明。
+- `frontend_cases` 绑定业务规则/场景、成功或失败结果、对应 UI 基线的 `case_id` 和可读取的用例说明；有后端依赖时绑定已交付接口，`backend-not-applicable` 时 `operation_ids` 必须为空。
 - 已规划的承接使用 `mapped`，表示已映射用例，不声称代码已实现。当前交付范围必须 mapped 到当前切片；其他范围的 pending、conflict、deferred 或 not-applicable 沿用战略逐条承接的理由、证据和依赖阻断规则。
 
 完成接收核对后记录 `status: accepted` 并执行：
@@ -63,10 +76,13 @@ scripts/verify-frontend-delivery --root <frontend> --slice <slice-id> <relative-
 
 ## 维护与验证
 
-共享实现由当前主模板维护，通过 `scripts/sync-strategic-handoff-tools` 分发；canonical Skill 变更后生成运行时投影与 lock。新/旧模板的实例初始化与 sync 不静默转换 profile。场景入口为 `scripts/verify-frontend-delivery-scenarios`，通过临时实例和明确标注的合成测试服务验证行为，不作为具体产品的交付证据。
+共享实现由当前主模板维护，通过 `scripts/sync-strategic-handoff-tools` 分发；canonical Skill 变更后生成运行时投影与 lock。新/旧模板的实例初始化与 sync 不静默转换 profile。场景入口为 `scripts/verify-frontend-delivery-scenarios` 与 `scripts/verify-existing-ui-baseline-scenarios`，通过临时实例和明确标注的合成测试服务验证行为，不作为具体产品的交付证据。
 
 前端 `frontend_cases` 的 `evidence_ref` 必须同时绑定 `evidence_digest`（原始文件字节 SHA-256）。用例内容变化后须更新接收记录并重编译依赖合同。
 
 OpenAPI Freeze 的来源门禁兼容当前综合模板 `gate.engineering-contract-approved`、历史冻结包 `gate.openapi-frozen` 与研发模板 `gate.openapi-freeze-confirmed`；仍严格校验来源角色策略及批准字节绑定，不允许其他门禁代替。每个交付范围至少包含一个带成功/失败验证的战略场景。
 
 生命周期中的稳定入口为 `check.frontend-delivery-inputs-verified`，定义见各自 `lifecycle-registry.yaml`；角色表将它登记为 automatic_checks，实际核验仍由脚本执行，不增设人工批准，也不替代 Slice Contract 的批准门禁。
+
+
+初始化、构建、导出与接收的前提通过 [只读交付预检](delivery-preflight.md) 汇总。预检不启动服务或制造接收状态；最终有后端依赖的接收仍执行本节真实服务探测，不能复用旧预检结论跳过实际边界核验。

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

@@ -6,6 +6,12 @@
 
 每个受影响实现仓库必须登记：仓库地址、分支、代码所有者、CI 入口、测试 / 构建命令、允许写路径、回滚点和 MR / PR。没有登记记录时，先完成 onboarding，不能用本仓库目录代替实现仓库。
 
+## 1.0 既有工程与交付预检
+
+接入和初始化规划前运行 `scripts/preflight-delivery --input <清单> --stage prepare --json`，按责任来源补齐可独立判断的缺项；后续执行边界重新核验，不把旧报告当放行凭据。阶段与退出码见 [完整交付预检](delivery-preflight.md)。
+
+未由模板生成的 Java/Maven 工程按 [既有后端身份](existing-backend-architecture.md) 登记稳定仓库/项目身份、固定源码、实际构建单元和独立边界审查。DDD 与 layered-mvc 复用对应 Recipe，但原始来源独立，不能重跑脚手架补造历史。无 UI 改动的 Vue 证据按 [既有 UI 基线](existing-ui-baseline.md) 承接；涉及新页面、状态或行为则回原型流程。
+
 ## 1.1 Harness 内实现项目路径策略
 
 当前 Harness 明确承载运行时代码时，统一使用以下多项目布局：