create-yss-spec 3.3.7 → 3.4.1

package/template/docs/design/tokens/variables.css

@@ -1,52 +1,54 @@
 :root {
+  --yss-card-padding: 20px;
+  --yss-control-height: 32px;
   --yss-color-primary-control: #245bdb;
   --yss-color-primary-control-hover: #2f68eb;
   --yss-color-on-primary: #ffffff;
   --yss-control-height-compact: 28px;
   --yss-card-compact-padding: 16px;
   --brand-color-primary: #3371ff;
-  --brand-color-primary-bg: #d6e4ff;
-  --brand-color-primary-bg-hover: #adc6ff;
-  --brand-color-primary-border: #85a5ff;
-  --brand-color-primary-border-hover: #597ef7;
-  --brand-color-primary-hover: #4096ff;
-  --brand-color-primary-active: #0958d9;
-  --brand-color-primary-text: #002c8c;
+  --brand-color-primary-bg: #f0f7ff;
+  --brand-color-primary-bg-hover: #d6e8ff;
+  --brand-color-primary-border: #adceff;
+  --brand-color-primary-border-hover: #85b1ff;
+  --brand-color-primary-hover: #5c92ff;
+  --brand-color-primary-active: #2152d9;
+  --brand-color-primary-text: #3371ff;
   --brand-color-success: #52c41a;
   --brand-color-success-bg: #f6ffed;
   --brand-color-success-border: #b7eb8f;
-  --brand-color-success-hover: #73d13d;
+  --brand-color-success-hover: #95de64;
   --brand-color-success-active: #389e0d;
   --brand-color-warning: #faad14;
   --brand-color-warning-bg: #fffbe6;
   --brand-color-warning-border: #ffe58f;
-  --brand-color-warning-hover: #ffc53d;
+  --brand-color-warning-hover: #ffd666;
   --brand-color-warning-active: #d48806;
   --brand-color-error: #f5222d;
-  --brand-color-error-bg: #fff2f0;
-  --brand-color-error-border: #ffccc7;
+  --brand-color-error-bg: #fff1f0;
+  --brand-color-error-border: #ffa39e;
   --brand-color-error-hover: #ff4d4f;
   --brand-color-error-active: #cf1322;
   --brand-color-info: #3371ff;
-  --brand-color-info-bg: #e6f4ff;
-  --brand-color-info-border: #91caff;
+  --brand-color-info-bg: #f0f7ff;
+  --brand-color-info-border: #adceff;
   --brand-color-link: #3371ff;
-  --brand-color-link-hover: #4096ff;
-  --brand-color-link-active: #0958d9;
+  --brand-color-link-hover: #85b1ff;
+  --brand-color-link-active: #2152d9;
   --brand-color-text: rgba(0, 0, 0, 0.88);
   --brand-color-text-secondary: rgba(0, 0, 0, 0.65);
-  --brand-color-text-tertiary: #8c8c8c;
-  --brand-color-text-quaternary: #bfbfbf;
-  --brand-color-fill: #d9d9d9;
-  --brand-color-fill-secondary: #f0f0f0;
-  --brand-color-fill-tertiary: #f5f5f5;
-  --brand-color-fill-quaternary: #fafafa;
+  --brand-color-text-tertiary: rgba(0,0,0,0.45);
+  --brand-color-text-quaternary: rgba(0,0,0,0.25);
+  --brand-color-fill: rgba(0,0,0,0.15);
+  --brand-color-fill-secondary: rgba(0,0,0,0.06);
+  --brand-color-fill-tertiary: rgba(0,0,0,0.04);
+  --brand-color-fill-quaternary: rgba(0,0,0,0.02);
   --brand-color-bg-layout: #f0f2f5;
   --brand-color-bg-container: #ffffff;
   --brand-color-bg-elevated: #ffffff;
   --brand-color-border: #d9d9d9;
   --brand-color-border-secondary: #f0f0f0;
-  --brand-font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
+  --brand-font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif;
   --brand-font-family-code: 'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, Courier, monospace;
   --brand-font-size: 14px;
   --brand-font-size-sm: 12px;
@@ -250,49 +252,49 @@
 }
 
 .dark {
-  --brand-color-primary: #3983dc;
-  --brand-color-primary-bg: #121e32;
-  --brand-color-primary-bg-hover: #152d4f;
-  --brand-color-primary-border: #213b5b;
-  --brand-color-primary-border-hover: #284f7e;
-  --brand-color-primary-hover: #61a1e8;
-  --brand-color-primary-active: #3169ad;
-  --brand-color-primary-text: #b5daf8;
-  --brand-color-success: #64b537;
-  --brand-color-success-bg: #192913;
-  --brand-color-success-border: #304d20;
-  --brand-color-success-hover: #87ca5c;
-  --brand-color-success-active: #518f2f;
-  --brand-color-warning: #dcaa37;
-  --brand-color-warning-bg: #312512;
-  --brand-color-warning-border: #5b4920;
-  --brand-color-warning-hover: #e8c35e;
-  --brand-color-warning-active: #ad872f;
-  --brand-color-error: #dc6966;
-  --brand-color-error-bg: #32191a;
-  --brand-color-error-border: #5b3231;
-  --brand-color-error-hover: #e89590;
-  --brand-color-error-active: #ad5553;
-  --brand-color-info: #3983dc;
-  --brand-color-info-bg: #121e32;
-  --brand-color-info-border: #213b5b;
-  --brand-color-link: #3983dc;
-  --brand-color-link-hover: #61a1e8;
-  --brand-color-link-active: #3169ad;
-  --brand-color-text: #dcdcdc;
-  --brand-color-text-secondary: #adadad;
-  --brand-color-text-tertiary: #7e7e7e;
-  --brand-color-text-quaternary: #4f4f4f;
-  --brand-color-fill: #3e3e3e;
-  --brand-color-fill-secondary: #303030;
-  --brand-color-fill-tertiary: #272727;
-  --brand-color-fill-quaternary: #1d1d1d;
-  --brand-color-bg-layout: #1d1d1d;
-  --brand-color-bg-container: #141414;
-  --brand-color-bg-elevated: #272727;
-  --brand-color-border: #3e3e3e;
-  --brand-color-border-secondary: #303030;
-  --brand-font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
+  --brand-color-primary: #3371ff;
+  --brand-color-primary-bg: #f0f7ff;
+  --brand-color-primary-bg-hover: #d6e8ff;
+  --brand-color-primary-border: #adceff;
+  --brand-color-primary-border-hover: #85b1ff;
+  --brand-color-primary-hover: #5c92ff;
+  --brand-color-primary-active: #2152d9;
+  --brand-color-primary-text: #3371ff;
+  --brand-color-success: #52c41a;
+  --brand-color-success-bg: #f6ffed;
+  --brand-color-success-border: #b7eb8f;
+  --brand-color-success-hover: #95de64;
+  --brand-color-success-active: #389e0d;
+  --brand-color-warning: #faad14;
+  --brand-color-warning-bg: #fffbe6;
+  --brand-color-warning-border: #ffe58f;
+  --brand-color-warning-hover: #ffd666;
+  --brand-color-warning-active: #d48806;
+  --brand-color-error: #f5222d;
+  --brand-color-error-bg: #fff1f0;
+  --brand-color-error-border: #ffa39e;
+  --brand-color-error-hover: #ff4d4f;
+  --brand-color-error-active: #cf1322;
+  --brand-color-info: #3371ff;
+  --brand-color-info-bg: #f0f7ff;
+  --brand-color-info-border: #adceff;
+  --brand-color-link: #3371ff;
+  --brand-color-link-hover: #85b1ff;
+  --brand-color-link-active: #2152d9;
+  --brand-color-text: rgba(0, 0, 0, 0.88);
+  --brand-color-text-secondary: rgba(0, 0, 0, 0.65);
+  --brand-color-text-tertiary: rgba(0,0,0,0.45);
+  --brand-color-text-quaternary: rgba(0,0,0,0.25);
+  --brand-color-fill: rgba(0,0,0,0.15);
+  --brand-color-fill-secondary: rgba(0,0,0,0.06);
+  --brand-color-fill-tertiary: rgba(0,0,0,0.04);
+  --brand-color-fill-quaternary: rgba(0,0,0,0.02);
+  --brand-color-bg-layout: #f0f2f5;
+  --brand-color-bg-container: #ffffff;
+  --brand-color-bg-elevated: #ffffff;
+  --brand-color-border: #d9d9d9;
+  --brand-color-border-secondary: #f0f0f0;
+  --brand-font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif;
   --brand-font-family-code: 'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, Courier, monospace;
   --brand-font-size: 14px;
   --brand-font-size-sm: 12px;

package/template/docs/design/tokens/variables.dark.css

@@ -1,47 +1,47 @@
 :root {
-  --brand-color-primary: #3983dc;
-  --brand-color-primary-bg: #121e32;
-  --brand-color-primary-bg-hover: #152d4f;
-  --brand-color-primary-border: #213b5b;
-  --brand-color-primary-border-hover: #284f7e;
-  --brand-color-primary-hover: #61a1e8;
-  --brand-color-primary-active: #3169ad;
-  --brand-color-primary-text: #b5daf8;
-  --brand-color-success: #64b537;
-  --brand-color-success-bg: #192913;
-  --brand-color-success-border: #304d20;
-  --brand-color-success-hover: #87ca5c;
-  --brand-color-success-active: #518f2f;
-  --brand-color-warning: #dcaa37;
-  --brand-color-warning-bg: #312512;
-  --brand-color-warning-border: #5b4920;
-  --brand-color-warning-hover: #e8c35e;
-  --brand-color-warning-active: #ad872f;
-  --brand-color-error: #dc6966;
-  --brand-color-error-bg: #32191a;
-  --brand-color-error-border: #5b3231;
-  --brand-color-error-hover: #e89590;
-  --brand-color-error-active: #ad5553;
-  --brand-color-info: #3983dc;
-  --brand-color-info-bg: #121e32;
-  --brand-color-info-border: #213b5b;
-  --brand-color-link: #3983dc;
-  --brand-color-link-hover: #61a1e8;
-  --brand-color-link-active: #3169ad;
-  --brand-color-text: #dcdcdc;
-  --brand-color-text-secondary: #adadad;
-  --brand-color-text-tertiary: #7e7e7e;
-  --brand-color-text-quaternary: #4f4f4f;
-  --brand-color-fill: #3e3e3e;
-  --brand-color-fill-secondary: #303030;
-  --brand-color-fill-tertiary: #272727;
-  --brand-color-fill-quaternary: #1d1d1d;
-  --brand-color-bg-layout: #1d1d1d;
+  --brand-color-primary: #2e63dc;
+  --brand-color-primary-bg: #1d305b;
+  --brand-color-primary-bg-hover: #223e7e;
+  --brand-color-primary-border: #1d305b;
+  --brand-color-primary-border-hover: #223e7e;
+  --brand-color-primary-hover: #5585e8;
+  --brand-color-primary-active: #2850ad;
+  --brand-color-primary-text: #2e63dc;
+  --brand-color-success: #49aa19;
+  --brand-color-success-bg: #162312;
+  --brand-color-success-border: #274916;
+  --brand-color-success-hover: #306317;
+  --brand-color-success-active: #3c8618;
+  --brand-color-warning: #d89614;
+  --brand-color-warning-bg: #2b2111;
+  --brand-color-warning-border: #594214;
+  --brand-color-warning-hover: #7c5914;
+  --brand-color-warning-active: #aa7714;
+  --brand-color-error: #d32029;
+  --brand-color-error-bg: #2a1215;
+  --brand-color-error-border: #58181c;
+  --brand-color-error-hover: #e84749;
+  --brand-color-error-active: #a61d24;
+  --brand-color-info: #2e63dc;
+  --brand-color-info-bg: #14192c;
+  --brand-color-info-border: #1d305b;
+  --brand-color-link: #2e63dc;
+  --brand-color-link-hover: #223e7e;
+  --brand-color-link-active: #2850ad;
+  --brand-color-text: rgba(255,255,255,0.85);
+  --brand-color-text-secondary: rgba(255,255,255,0.65);
+  --brand-color-text-tertiary: rgba(255,255,255,0.45);
+  --brand-color-text-quaternary: rgba(255,255,255,0.25);
+  --brand-color-fill: rgba(255,255,255,0.18);
+  --brand-color-fill-secondary: rgba(255,255,255,0.12);
+  --brand-color-fill-tertiary: rgba(255,255,255,0.08);
+  --brand-color-fill-quaternary: rgba(255,255,255,0.04);
+  --brand-color-bg-layout: #000000;
   --brand-color-bg-container: #141414;
-  --brand-color-bg-elevated: #272727;
-  --brand-color-border: #3e3e3e;
+  --brand-color-bg-elevated: #1f1f1f;
+  --brand-color-border: #424242;
   --brand-color-border-secondary: #303030;
-  --brand-font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
+  --brand-font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif;
   --brand-font-family-code: 'SFMono-Regular', Consolas, 'Liberation Mono', Menlo, Courier, monospace;
   --brand-font-size: 14px;
   --brand-font-size-sm: 12px;

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 finalize --source-root /governance/source --handoff docs/handoff.yaml --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 及后端交付；前端维护工程设计、页面和验收证据；统一管理方维护基线引用、跨仓切片与业务验收汇总。
 
-前端消费需求可在上游设计时提前反馈。Handoff v4 导入后的 Frontend Strategic Preflight 可在后端交付前完成战略输入、Context、视觉基线和源规则追踪核验，并允许起草前端工程设计与实现计划；它固定返回 `ready_for_agent: false`。仅当 Backend/API/Data 影响命中时，最终接收才等待后端交付；UI-only 路径使用有依据的 `backend-not-applicable`。Slice Contract 获准前均不得写代码。
+前端消费需求可在上游设计时提前反馈。新 Handoff v5 交付目录导入后生成 Import Receipt v3；历史裸 v4/v5 包继续生成 v2。Frontend Strategic Preflight 可在后端交付前完成战略输入、Context、相应 UI 基线和源规则追踪核验，并允许起草前端工程设计与实现计划；它固定返回 `ready_for_agent: false`。仅当 Backend/API/Data 影响命中时，最终接收才等待后端交付；UI-only 路径使用有依据的 `backend-not-applicable`。Slice Contract 获准前均不得写代码。
 
 ## 后端导出与前端导入
 
@@ -28,14 +28,25 @@ scripts/backend-delivery import --bundle <directory-or-zip> --target-root <front
 
 ## 接收与启动
 
-Handoff v4 先生成 `frontend-strategic-preflight-draft.json`；补齐正式 Context Reconciliation 后执行 `scripts/verify-frontend-strategic-preflight`。通过仅允许进入前端工程设计草案。
+Handoff v4/v5 先生成 `frontend-strategic-preflight-draft.json`；补齐正式 Context Reconciliation 后执行 `scripts/verify-frontend-strategic-preflight`。通过仅允许进入前端工程设计草案。
 
-后端交付导入只新增匹配的 backend binding 并产生 `frontend-acceptance-draft.json`，不会覆盖已填写的前端预检/设计草案，也不会批准资产。最终接收方按当前 `schemas/frontend-delivery-acceptance.schema.json`（v2）准备记录；v1 仅服务历史 Handoff v3，继续要求真实后端交付：
+后端交付导入只新增匹配的 backend binding 并产生 `frontend-acceptance-draft.json`，不会覆盖已填写的前端预检/设计草案，也不会批准资产。最终接收方按交接版本准备记录，禁止静默降级：
+
+| 战略交接 | 前端战略预检 | 最终接收 | 用例基线字段 |
+|---|---|---|---|
+| Handoff v3（历史） | 原历史路径 | Acceptance v1，要求后端交付 | `visual_case_ids` |
+| Handoff v4 | Preflight v1 | Acceptance v2 | `visual_case_ids` |
+| Handoff v5 delivery | Preflight v2 | Acceptance v3 | `ui_baseline_kind`、`ui_baseline_ref`、source delivery record |
+| 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 backend 路由的影响引用、原因和证据一致，且不得绑定后端收据。
+- `backend_dependency.mode: required` 时，`backend_delivery` 绑定真实后端导入收据和包摘要；`not-applicable` 时必须与 Handoff v4/v5 backend 路由的影响引用、原因和证据一致，且不得绑定后端收据。
 - `strategic_handoff` 绑定战略导入收据、包摘要、正式 `context_reconciliation_ref` 和全部源规则/关键场景的承接 rows。
-- `frontend_cases` 绑定业务规则/场景、成功或失败结果、Visual Baseline `case_id` 和可读取的用例说明；有后端依赖时绑定已交付接口，`backend-not-applicable` 时 `operation_ids` 必须为空。
+- `frontend_cases` 绑定业务规则/场景、成功或失败结果、对应 UI 基线的 `case_id` 和可读取的用例说明；有后端依赖时绑定已交付接口，`backend-not-applicable` 时 `operation_ids` 必须为空。
 - 已规划的承接使用 `mapped`，表示已映射用例，不声称代码已实现。当前交付范围必须 mapped 到当前切片；其他范围的 pending、conflict、deferred 或 not-applicable 沿用战略逐条承接的理由、证据和依赖阻断规则。
 
 完成接收核对后记录 `status: accepted` 并执行：
@@ -66,10 +77,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 明确承载运行时代码时，统一使用以下多项目布局：

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

@@ -1,7 +1,7 @@
 {
   "schema_version": 1,
   "registry_id": "yss.lifecycle",
-  "semantic_sha256": "38ec430630bbaee2c94f5d0d3dcd31f1d5481482b8cec52e44e983e4af6b638e",
+  "semantic_sha256": "5ec72f7acca16869cb25c1089f925c5a60c1dd376b4fc4799b09f5678ae065c3",
   "published_ids": [
     "artifact.architecture-review",
     "artifact.data-architecture",

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

@@ -419,17 +419,17 @@ work_units:
     scope: project-instance
     input: Spec、原型、API/数据/工程影响面。
     output: OpenAPI、数据架构、按确认架构形成的 DDD / MVC 技术设计合同、工程基线、架构审查和 Slice 合同草案。
-    completion: 命中契约已冻结；无 API 影响有可读记录；命中技术设计影响时架构已确认、规则与场景承接无未解释冲突；工程基线通过。
+    completion: 命中契约已冻结；无 API 影响有可读记录；所有后端交付均有批准且当前的 Technical Design；数据影响为真时数据架构已批准，否则有可核验的不适用记录；架构、规则与场景承接无未解释冲突；gate.engineering-contract-approved 通过。
   - id: work-unit.implementation-repository-preparation
     name: 实现仓库准备
     scope: project-instance
-    input: 工程影响面、工程基线、逐项目用户决定、实现仓库位置；新建工程还需批准且当前的 Project Scaffold Contract。
-    output: 已有工程的 Repository Onboarding Result，或新工程的 Scaffold Manifest 与 Scaffold Verification；并汇总 Implementation Repository Preparation Result。
-    completion: 每个命中的交付面均为 existing-and-onboarded 或 initialized-and-verified，未命中的交付面有带原因的 not-applicable；聚合结果当前且证据可读。
+    input: 已完成的技术分析执行结果、Context reconciliation、战略交接消费结果、工程合同批准、工程影响面和实现仓库位置；新建后端还需批准且当前并绑定设计前置的 Project Scaffold Contract v4。
+    output: 已有工程的 Repository Onboarding Result，或新工程的 Scaffold Manifest v4 与 Scaffold Verification；并汇总 Implementation Repository Preparation Result v2。
+    completion: 每个后端项目均携带技术/数据设计门禁结果；新生成只接受 v4；历史 v3 仅在机械骨架未修改、设计补齐和恢复批准均通过时对账复用；检测到提前业务实现时保持 blocked。每个命中的交付面均为 existing-and-onboarded 或 initialized-and-verified，未命中的交付面有带原因的 not-applicable；聚合结果当前且证据可读。
   - id: work-unit.service-project-initialization
     name: 独立服务项目初始化
     scope: project-instance
-    input: 逐项目批准的架构决策、schema v3 初始化合同、战略上下文交接及目标/skillUtils 写范围。
+    input: 逐项目批准的架构决策、Technical Design、Data Architecture Decision、工程合同批准、schema v4 初始化合同、战略上下文交接及目标/skillUtils 写范围。
     output: 独立 Git project-instance、锁定 skillUtils、唯一根 CONTEXT、架构身份、Manifest 和验证证据；父项目仅保留引用。
     completion: 当前合同与交接摘要一致，真实 Wrapper 三命令通过后仅 empty-scaffold-verified；首切片仍须独立批准和验证。
   - id: work-unit.ticket-decomposition