project-tiny-context-harness 0.8.8 → 0.8.10

package/assets/README.zh-CN.md

@@ -10,25 +10,25 @@ Project Tiny Context Harness 是给 AI coding agents 用的轻量项目记忆层
 
 编码 Agent 同时需要两类能力：跨会话仍然可靠的少量项目事实，以及长任务经历多轮修改或上下文压缩后仍可信的完成检查。
 
-Tiny Context 将这些能力保持为窄边界。两条实现路径共用一次实现前、风险比例化的 Architecture Deliberation 与适用质量路由，实施过程保留 Goal 自主但遵守边界型实现质量 guardrails，项目验证后只由一个 carrier 对当前候选执行包含 Architecture Conformance 的 Engineering Quality Conformance。
-
-它不会启动或切换模型，不会创建 Agent、分支或 worktree，不会 merge、push、创建 PR 或部署，也不会取代项目测试和人工产品验收。
-
-## 三个机制如何配合
-
-| 机制 | 何时、如何使用 | 负责什么 |
-|---|---|---|
-| **Minimal Context** | 默认安装；每种交付路径都会读取并按需更新 `project_context/**`。 | 保存目标、归属、架构/接口/状态边界和可重复验证/部署等耐久事实；不声称实现或测试已经通过。 |
-| **Workflow Contract** | `init` 后自动生效的 prompt-level 默认协议。普通任务直接交给当前 coding Goal；没有 Skill 命令，也不创建 `delivery-contract.yaml`。 | 执行轻量循环：Context 发现、带适用质量路由的 Architecture Deliberation、唯一 `Context Delta`、Goal-owned 实现、项目检查、承载 Engineering Quality Conformance 的 Contract Conformance 与 Context drift；不产生 validator 结果、Receipt、持久工作流状态或机器完成权威。 |
-| **Long-Task Workflow** | 先启用一次 `long-task` profile，再显式选择 `long-task-workflow` Skill；已有有效绑定时恢复。不能因为任务看起来很长就自动启用。 | 持有一份 Source-bound Delivery Contract、Authority Lock、可恢复的局部进度、受保护修订和当前快照 Live Final Gate。 |
-
-三者的关系是：每个任务都使用 Minimal Context；普通任务走默认 Workflow Contract；只有显式选择或恢复有效绑定时，才由 `long-task-workflow` 承担执行与完成权威。Long-Task 的 Final Gate 承载 Engineering Quality/Architecture Conformance 与选定设计闭环，不再重复默认 Contract Conformance。
-
-`design-system-authoring` 与 `design-resource-authoring` 是基础 Profile 中独立、可选的上游设计 Skill，不是第四个机制，也不是 Long-Task 的阶段。其选定产物可以进入默认或 Long-Task 任一路径；当前唯一活跃的长程执行 Skill 是 `long-task-workflow`。
-
-本文使用宿主无关的逻辑 Skill 名。Codex 中用 `$skill-name`（例如 `$long-task-workflow`）显式选择，或通过 `/skills` 选择；其他宿主使用各自的 Skill 入口。
-
-## 快速开始
+Tiny Context 将这些能力保持为窄边界。两条实现路径共用一次实现前、风险比例化的 Architecture Deliberation 与适用质量路由，实施过程保留 Goal 自主但遵守边界型实现质量 guardrails，项目验证后只由一个 carrier 对当前候选执行包含 Architecture Conformance 的 Engineering Quality Conformance。
+
+它不会启动或切换模型，不会创建 Agent、分支或 worktree，不会 merge、push、创建 PR 或部署，也不会取代项目测试和人工产品验收。
+
+## 三个机制如何配合
+
+| 机制 | 何时、如何使用 | 负责什么 |
+|---|---|---|
+| **Minimal Context** | 默认安装；每种交付路径都会读取并按需更新 `project_context/**`。 | 保存目标、归属、架构/接口/状态边界和可重复验证/部署等耐久事实；不声称实现或测试已经通过。 |
+| **Workflow Contract** | `init` 后自动生效的 prompt-level 默认协议。普通任务直接交给当前 coding Goal；没有 Skill 命令，也不创建 `delivery-contract.yaml`。 | 执行轻量循环：Context 发现、带适用质量路由的 Architecture Deliberation、唯一 `Context Delta`、Goal-owned 实现、项目检查、承载 Engineering Quality Conformance 的 Contract Conformance 与 Context drift；不产生 validator 结果、Receipt、持久工作流状态或机器完成权威。 |
+| **Long-Task Workflow** | 先启用一次 `long-task` profile，再显式选择 `long-task-workflow` Skill；已有有效绑定时恢复。不能因为任务看起来很长就自动启用。 | 持有一份 Source-bound Delivery Contract、Authority Lock、可恢复的局部进度、受保护修订和当前快照 Live Final Gate。 |
+
+三者的关系是：每个任务都使用 Minimal Context；普通任务走默认 Workflow Contract；只有显式选择或恢复有效绑定时，才由 `long-task-workflow` 承担执行与完成权威。Long-Task 的 Final Gate 承载 Engineering Quality/Architecture Conformance 与选定设计闭环，不再重复默认 Contract Conformance。
+
+`design-system-authoring` 与 `design-resource-authoring` 是基础 Profile 中独立、可选的上游设计 Skill，不是第四个机制，也不是 Long-Task 的阶段。其选定产物可以进入默认或 Long-Task 任一路径；当前唯一活跃的长程执行 Skill 是 `long-task-workflow`。
+
+本文使用宿主无关的逻辑 Skill 名。Codex 中用 `$skill-name`（例如 `$long-task-workflow`）显式选择，或通过 `/skills` 选择；其他宿主使用各自的 Skill 入口。
+
+## 快速开始
 
 ```powershell
 npx --yes project-tiny-context-harness ty-context init
@@ -48,24 +48,50 @@ npx --yes project-tiny-context-harness ty-context sync
 
 `upgrade` 先执行安全迁移再同步；资产刷新不会推断或覆盖用户编写的 Context、Source、Delivery Contract 或历史文件。
 
-默认 Profile 是 `core-portable` 与 `workflow-default`，基础 managed set 已包含显式选择的 `design-system-authoring` 与 `design-resource-authoring`。显式启用长程能力：
+默认 Profile 是 `core-portable` 与 `workflow-default`，基础 managed set 已包含显式选择的 `design-system-authoring` 与 `design-resource-authoring`。显式启用长程能力：
 
 ```powershell
 ty-context enable long-task
 ```
 
-启用长程能力会额外安装 `long-task-workflow`、退役兼容指引 `source-plan-authoring` 与完成 Hook；`ty-context disable long-task` 只移除这些 Long-Task-owned surfaces，并保留两个基础设计 Skill。Tiny Context 不安装 Open Design、模型 Worker、Agent runtime、调度器、Git 编排资产或其他设计生成 runtime。
+启用长程能力会额外安装 `long-task-workflow`、退役兼容指引 `source-plan-authoring` 与完成 Hook；`ty-context disable long-task` 只移除这些 Long-Task-owned surfaces，并保留两个基础设计 Skill。Tiny Context 不安装 Open Design、模型 Worker、Agent runtime、调度器、Git 编排资产或其他设计生成 runtime。
+
+## 推荐用法
+
+初始输入可以是简要产品意图，也可以是 Web GPT 等外部服务给出的详细初始方案。该输入本身不要求设计 authoring 或 Long-Task；应按交付需要选择执行路径，不要把“是否需要设计资源”和“是否需要 Long-Task”绑定在一起：
+
+### 设计优先的 Long-Task 工作流
+
+这条路径适合确实需要新 style-bearing 设计资源的长程实现交付。它组合已有能力，但不是所有 Long-Task 的前置流程：
+
+1. **只启用一次 Long-Task。** 选择工作流 Skill 前先运行 `ty-context enable long-task`。
+2. **仅在需要时建立 Design Authority。** 如果项目尚未采用 Design Authority，且本次工作属于 style-bearing 范围，显式选择 `$design-system-authoring`，生成、选择并采用规范 `DESIGN.md`、token source 和 provider binding。项目已经配置 Design Authority 时跳过这一步。
+3. **准备一份可写的初始方案。** 将项目原生的产品/技术方案放在明确路径，例如 `docs/initial-proposal.md`。它可以由用户、外部服务或显式请求的适用方案能力编写。`design-resource-authoring` 不负责初始方案 authoring，也不要求经过 Source Plan 阶段。
+4. **生成并选择设计资源。** 选择 `$design-resource-authoring`，传入初始方案路径、精确开发范围和目标。它会输出一份完成一次性回改的修订方案、选定的不可变规范资源及其 manifest 和 dependencies，以及通过校验的残余 `design-resource-handoff-v1`。
+5. **启动 Single-Goal 交付。** 选择 `$long-task-workflow`，传入修订方案、已校验 handoff 和选定规范资源集合的精确路径。该 Skill 会建立 Source-bound Contract Draft；第一次 Compile/Authority Lock 随后会在实现前给出一次性的“继续使用当前模型”或“切换模型后恢复”选择。
+
+一组可以直接改写使用的调用顺序如下：
+
+```text
+$design-system-authoring 为这个 style-bearing 范围生成、选择并采用项目设计系统；如果 DESIGN.md 已经配置，则跳过本请求。
+
+为 <交付范围> 在 docs/initial-proposal.md 准备一份可写、项目原生的初始方案。
+
+$design-resource-authoring 使用 docs/initial-proposal.md，覆盖 <精确开发范围和目标>。返回完成回改的方案路径、通过校验的 design-resource-handoff-v1 路径，以及选定的不可变规范资源、manifest 和 dependency 路径。
+
+$long-task-workflow 将 docs/initial-proposal.md、<handoff.md> 以及选定的规范资源、manifest 和 dependencies 作为 Source，完成一次完整实现交付。
+```
+
+上面的路径只是示例，不是固定目录。候选图片或可编辑探索本身不构成保真实现权威；下游实现使用选定的不可变规范资源及其已校验 handoff。
+
+其他有效路径仍然保留：
 
-## 推荐用法
-
-初始输入可以是简要产品意图，也可以是 Web GPT 等外部服务给出的详细初始方案。该输入本身不要求设计 authoring 或 Long-Task；应按交付需要选择执行路径，不要把“是否需要设计资源”和“是否需要 Long-Task”绑定在一起：
-
-- **普通交付、不需要新设计资源：** 直接把需求交给当前 coding Goal；默认 Workflow Contract 自动生效，不需要 Workflow Skill 或 Contract 文件。
-- **长程交付、不需要新设计资源：** 启用一次 Profile 后，直接用需求或初始方案选择 `long-task-workflow`；该 Skill 会建立 Source-bound Contract Draft，设计资源不是前置条件。
-- **交付前确实需要设计资源：** 项目缺少 Design Authority 时才显式选择 `design-system-authoring`，再用 `design-resource-authoring` 生成/选择资源、按需完整冻结实现级 Source、一次性回改已接受决策并生成通过校验的残余 `design-resource-handoff-v1`。随后根据恢复与完成权威需求，把修订方案和选定资源交给默认 Workflow Contract 或 `long-task-workflow`。
-- **只需要设计资源：** 在 `design-resource-authoring` 完成后结束；除非还明确选择了实现交付，否则不创建 Long-Task Contract。
-
-设计系统通常在项目冷启动时确定，但该 Skill 只由用户选择，`init`、`sync` 与下游 Skill 都不会自动执行。`design-resource-authoring` 只对高保真、品牌化、视觉处理等 style-bearing 资源设门禁；低保真结构、IA/流程与纯语义状态研究不受此门禁。旧 Source Plan 仍可作为普通输入，但不再是推荐中间服务。
+- **普通交付、不需要新设计资源：** 直接把需求交给当前 coding Goal；默认 Workflow Contract 自动生效，不需要 Workflow Skill 或 Contract 文件。
+- **长程交付、不需要新设计资源：** 启用一次 Profile 后，直接用需求或初始方案选择 `long-task-workflow`；该 Skill 会建立 Source-bound Contract Draft，设计资源不是前置条件。
+- **交付前确实需要设计资源：** 按上面的设计优先顺序执行，再根据恢复与完成权威需求，把修订方案、已校验 handoff 和选定的不可变规范资源集合交给默认 Workflow Contract 或 `long-task-workflow`。
+- **只需要设计资源：** 在 `design-resource-authoring` 完成后结束；除非还明确选择了实现交付，否则不创建 Long-Task Contract。
+
+设计系统通常在项目冷启动时确定，但该 Skill 只由用户选择，`init`、`sync` 与下游 Skill 都不会自动执行。`design-resource-authoring` 只对高保真、品牌化、视觉处理等 style-bearing 资源设门禁；低保真结构、IA/流程与纯语义状态研究不受此门禁。旧 Source Plan 仍可作为普通输入，但不再是推荐中间服务。
 
 ## Minimal Context 与默认工作流
 
@@ -90,44 +116,44 @@ manifest/trigger 命中的少量 area/role Context
 3. 合并两路候选，只读取真正相关的 Context；
 4. 再判断 `Context Delta: none|required`。
 
-这次搜索只补充语义判断，不会把所有关键词命中都当成 Authority，也不会创建向量/持久索引、缓存、Registry、search state 或第二权威。它仍可能漏掉完全不同的同义词或间接依赖，因此每个实现需求仍要执行 Architecture Deliberation 与收尾 Conformance。
-
-`ty-context doctor` 会报告确定性的默认 Context 文件/字节规模、单文件与总量软预算超限、字节完全相同的默认文件，以及 `DESIGN.md` 权威状态。这些只是维护提示，不是新验证 Gate 或运行时状态。如果真实的近乎通用恢复事实超过字节启发式预算，应保留事实并接受 warning；绝不能为了满足预算而遗漏、过度压缩或错误分类必需 Context。
-
-Context 负责耐久的意图和边界，代码负责当前实现，测试/CI/浏览器或运行时证据/人工负责行为与产品验收。
-
-### 稀疏 Context Workspace 与 Monorepo
-
-Monorepo 可以让 Context 继续集中维护，同时只镜像确实拥有耐久非代码事实的实现 workspace：
-
-```text
-project_context/
-  areas/                              # 跨 workspace、仓库级、共享 owner
-  workspaces/
-    mobile/areas/...
-    wechat-miniapp/areas/...
-    api/areas/...
-```
-
-每个已表示的 `project_context/workspaces/<workspace-id>/**` 通过现有 `[[areas]].root` 与 `context` 精确对应一个仓库相对代码根，内部可以有多个 workspace-local Area/role owner。反向映射是稀疏的：没有耐久 Context 的 package-manager workspace 不创建空目录。真正跨 workspace、仓库级、共享或治理 Area 仍放在顶层 `project_context/areas/**`；完整代码 workspace 清单继续由 package-manager/build 配置拥有。单 workspace/非 monorepo 项目保持原有顶层 Area 布局、初始化和验证。
-
-Monorepo 应优先用一个小型顶层 Area 保存仓库公共的 default Context；workspace-local Context 默认 `on-demand`，除非它确实近乎所有任务都需要。core/default 集合、manifest 候选和 bounded search 仍只是可扩展的起始 working set，不是读取 ACL、最大集合，也不要求读完整个目标 workspace。任务需要时可以继续读取兄弟 Area、共享后端、跨客户端 contract、根 `DESIGN.md`、选定资源或代码。根 `DESIGN.md` 仍是当前共享项目 Design Authority；Context workspace 目录不会自动拆出多套设计系统。
-
-产品编辑前，用用户、产品、路径和仓库事实解析本任务 intended workspace(s)。只有仍无法区分多个实质不同的同级目标时，才问一个精确问题；不能默认选择 default Area、最近改过的客户端或通用关键词命中。跨 workspace 任务列全目标和 supporting/shared scope。实现后，如果仓库已有 changed-path / target-scope verifier，就用本任务准确变更路径调用；否则在 Conformance 中按 durable owner 检查最终 diff。Tiny Context 不新增 `[[workspaces]]` schema、自动 package-manager 拓扑扫描、强制迁移、持久 target 状态、通用 import/path/runtime scanner 或第二套 Long-Task scope classifier。
-
-普通任务：
-
-1. 读取 core/default Context，收集 manifest 候选；
-2. 在 `project_context/**` 做一次 bounded Context search，并在依赖需要时继续扩读；
-3. 多目标仓库先解析本任务 intended workspace(s)，但不把 Context workspace 或 Area 变成读取/修改权限；
-4. 对用户可见地给出一次简洁、仓库事实绑定的 Architecture Deliberation，并说明触发的质量属性或具体 preservation basis；
-5. 决定 `Context Delta: none|required`，耐久语义改变时先更新 owner Context；
-6. 使用平台内部计划；
-7. 在 Goal-owned 边界型质量 guardrails 下实现并运行项目验证，包括仓库已有的 changed-path / target-scope check；
-8. 执行 Contract Conformance，其中包含当前候选快照的 Engineering Quality Conformance、其 Architecture Conformance 子集和最终 change-scope 审查；
-9. 单独执行 Context drift check 后交付。
-
-默认工作流不要求 `plan.md`、target declaration、matrix、verdict、evidence ledger、持久检索索引或第二份执行计划。任务时长、文件数和复杂度不会自动激活长程状态。
+这次搜索只补充语义判断，不会把所有关键词命中都当成 Authority，也不会创建向量/持久索引、缓存、Registry、search state 或第二权威。它仍可能漏掉完全不同的同义词或间接依赖，因此每个实现需求仍要执行 Architecture Deliberation 与收尾 Conformance。
+
+`ty-context doctor` 会报告确定性的默认 Context 文件/字节规模、单文件与总量软预算超限、字节完全相同的默认文件，以及 `DESIGN.md` 权威状态。这些只是维护提示，不是新验证 Gate 或运行时状态。如果真实的近乎通用恢复事实超过字节启发式预算，应保留事实并接受 warning；绝不能为了满足预算而遗漏、过度压缩或错误分类必需 Context。
+
+Context 负责耐久的意图和边界，代码负责当前实现，测试/CI/浏览器或运行时证据/人工负责行为与产品验收。
+
+### 稀疏 Context Workspace 与 Monorepo
+
+Monorepo 可以让 Context 继续集中维护，同时只镜像确实拥有耐久非代码事实的实现 workspace：
+
+```text
+project_context/
+  areas/                              # 跨 workspace、仓库级、共享 owner
+  workspaces/
+    mobile/areas/...
+    wechat-miniapp/areas/...
+    api/areas/...
+```
+
+每个已表示的 `project_context/workspaces/<workspace-id>/**` 通过现有 `[[areas]].root` 与 `context` 精确对应一个仓库相对代码根，内部可以有多个 workspace-local Area/role owner。反向映射是稀疏的：没有耐久 Context 的 package-manager workspace 不创建空目录。真正跨 workspace、仓库级、共享或治理 Area 仍放在顶层 `project_context/areas/**`；完整代码 workspace 清单继续由 package-manager/build 配置拥有。单 workspace/非 monorepo 项目保持原有顶层 Area 布局、初始化和验证。
+
+Monorepo 应优先用一个小型顶层 Area 保存仓库公共的 default Context；workspace-local Context 默认 `on-demand`，除非它确实近乎所有任务都需要。core/default 集合、manifest 候选和 bounded search 仍只是可扩展的起始 working set，不是读取 ACL、最大集合，也不要求读完整个目标 workspace。任务需要时可以继续读取兄弟 Area、共享后端、跨客户端 contract、根 `DESIGN.md`、选定资源或代码。根 `DESIGN.md` 仍是当前共享项目 Design Authority；Context workspace 目录不会自动拆出多套设计系统。
+
+产品编辑前，用用户、产品、路径和仓库事实解析本任务 intended workspace(s)。只有仍无法区分多个实质不同的同级目标时，才问一个精确问题；不能默认选择 default Area、最近改过的客户端或通用关键词命中。跨 workspace 任务列全目标和 supporting/shared scope。实现后，如果仓库已有 changed-path / target-scope verifier，就用本任务准确变更路径调用；否则在 Conformance 中按 durable owner 检查最终 diff。Tiny Context 不新增 `[[workspaces]]` schema、自动 package-manager 拓扑扫描、强制迁移、持久 target 状态、通用 import/path/runtime scanner 或第二套 Long-Task scope classifier。
+
+普通任务：
+
+1. 读取 core/default Context，收集 manifest 候选；
+2. 在 `project_context/**` 做一次 bounded Context search，并在依赖需要时继续扩读；
+3. 多目标仓库先解析本任务 intended workspace(s)，但不把 Context workspace 或 Area 变成读取/修改权限；
+4. 对用户可见地给出一次简洁、仓库事实绑定的 Architecture Deliberation，并说明触发的质量属性或具体 preservation basis；
+5. 决定 `Context Delta: none|required`，耐久语义改变时先更新 owner Context；
+6. 使用平台内部计划；
+7. 在 Goal-owned 边界型质量 guardrails 下实现并运行项目验证，包括仓库已有的 changed-path / target-scope check；
+8. 执行 Contract Conformance，其中包含当前候选快照的 Engineering Quality Conformance、其 Architecture Conformance 子集和最终 change-scope 审查；
+9. 单独执行 Context drift check 后交付。
+
+默认工作流不要求 `plan.md`、target declaration、matrix、verdict、evidence ledger、持久检索索引或第二份执行计划。任务时长、文件数和复杂度不会自动激活长程状态。
 
 每次交接只报告一个 Context 结果：
 
@@ -137,61 +163,63 @@ Context: updated <文件/原因>
 Context: no durable fact change
 ```
 
-### 工程质量与模块化
-
-Shared Engineering Quality 在不增加工作流的前提下扩展原有架构义务。每个实现需求都在第一处实现编辑前，对用户可见地完成一次 `Architecture Deliberation`；风险改变深度，不取消这个环节。小修改要指出具体 owner / 当前 extension point、未改变的耐久边界、适用质量属性的 preservation，以及为何没有新增或加重技术债。material 工作还要覆盖唯一 source of truth、dependency 与 interface/state/resource lifecycle 边界、选中和拒绝的方案、至少一个合理未来变化及其扩展点、触达的技术债、forbidden shortcuts、项目原生可执行检查和触发的 failure/load/threat 场景。correctness/invariant 与 maintainability/changeability 至少给出 preservation；reliability/resource lifecycle、concurrency/consistency、performance/capacity/cost、security/privacy/safety、compatibility/migration/rollout、operability/observability/testability 只在 material 时激活。
-
-实现顺序、方法和反馈节奏仍由 Goal 决定。轻量纪律只要求复用 owning service/facade/adapter 与唯一 source of truth，做最小而完整的变化，保留明确 failure/resource 语义，并仅为稳定概念或有证据的变化轴增加抽象。精确产品/技术谓词继续由 Semantic Facts 拥有，精确选定 UI/UX 值由 selected-design closure 拥有。
-
-实现和项目验证之后，`Engineering Quality Conformance` 包含 `Architecture Conformance`，对当前候选快照检查 scope/path escape、owner/dependency 违规或 bypass、重复 truth、未声明 boundary/lifecycle 变化、silent failure、适用 resource/concurrency/security/compatibility/operability 缺陷、无证据性能声称、缺失声明检查和新增/加重技术债。性能声称必须绑定 workload、metric、baseline 或 budget、environment、comparator/tolerance 和项目原生 benchmark/probe；静态形状不证明运行时性能。候选或 controlling input 再变化就使结果失效。普通任务把它放在 Contract Conformance 内；Long-Task 用已有 Source-backed obligation/constraint/forbidden shortcut、owner/path/Binding、executable Check，以及功能 pass 时仍可能独立失败的 Assertion 表达不变量。Final Gate 是唯一 Long-Task carrier，只证明该声明、可证伪、项目检查绑定的集合，不证明整体代码质量；同一候选不会执行两套 carrier。
+### 工程质量与模块化
+
+Shared Engineering Quality 在不增加工作流的前提下扩展原有架构义务。每个实现需求都在第一处实现编辑前，对用户可见地完成一次 `Architecture Deliberation`；风险改变深度，不取消这个环节。小修改要指出具体 owner / 当前 extension point、未改变的耐久边界、适用质量属性的 preservation，以及为何没有新增或加重技术债。material 工作还要覆盖唯一 source of truth、dependency 与 interface/state/resource lifecycle 边界、选中和拒绝的方案、至少一个合理未来变化及其扩展点、触达的技术债、forbidden shortcuts、项目原生可执行检查和触发的 failure/load/threat 场景。correctness/invariant 与 maintainability/changeability 至少给出 preservation；reliability/resource lifecycle、concurrency/consistency、performance/capacity/cost、security/privacy/safety、compatibility/migration/rollout、operability/observability/testability 只在 material 时激活。
+
+实现顺序、方法和反馈节奏仍由 Goal 决定。轻量纪律只要求复用 owning service/facade/adapter 与唯一 source of truth，做最小而完整的变化，保留明确 failure/resource 语义，并仅为稳定概念或有证据的变化轴增加抽象。精确产品/技术谓词继续由 Semantic Facts 拥有，精确选定 UI/UX 值由 selected-design closure 拥有。
+
+实现和项目验证之后，`Engineering Quality Conformance` 包含 `Architecture Conformance`，对当前候选快照检查 scope/path escape、owner/dependency 违规或 bypass、重复 truth、未声明 boundary/lifecycle 变化、silent failure、适用 resource/concurrency/security/compatibility/operability 缺陷、无证据性能声称、缺失声明检查和新增/加重技术债。性能声称必须绑定 workload、metric、baseline 或 budget、environment、comparator/tolerance 和项目原生 benchmark/probe；静态形状不证明运行时性能。候选或 controlling input 再变化就使结果失效。普通任务把它放在 Contract Conformance 内；Long-Task 用已有 Source-backed obligation/constraint/forbidden shortcut、owner/path/Binding、executable Check，以及功能 pass 时仍可能独立失败的 Assertion 表达不变量。Final Gate 是唯一 Long-Task carrier，只证明该声明、可证伪、项目检查绑定的集合，不证明整体代码质量；同一候选不会执行两套 carrier。
 
 Contract Conformance 主要检查当前 Source/Context 是否到达实现和验证；单独命名的 Context drift check 反向检查实现或新决策是否让耐久 Context 过时。新增或加重技术债默认阻塞，除非项目有带 owner、rationale、tracking 和 removal condition 的显式 bounded exception。无关 legacy debt 不自动扩张任务范围，但本次触达、依赖或加重的债不能隐藏。
 
-`Architecture Context Hit`、`Decision Rationale Hit: existing|required|none` 和 `Modularity Check: none|required|exception` 仍是内部路由问题，不创建 Task Contract 或固定 `plan.md`。可见检查点只证明“存在可审查的考量”，不暴露私有思维链，也不保证最佳设计或预知所有未知未来需求。该义务不增加质量 plan/stage/matrix、第二 Authority、Contract field/aspect/Claim/risk kind、Gate、state 或 Receipt。
-
-Harness 只路由仓库原生 type/compiler/lint/AST/dependency/contract/behavior/benchmark/probe，不实现跨语言通用架构、质量或性能分析器。`ty-context check-modularity` 是 capability-aware portable risk signal：所有纳入格式检查物理行；JS/TS family 另做 lexical 单函数语句/分支、export、state-transition 与 responsibility 启发式；Python 只做专用 lexical 单函数语句/分支；其他格式（包括没有 SFC parser 的 Vue）只做 line-only。输出明确 `analysis=js-ts-heuristic|python-heuristic|line-only`；不支持指标内部为 `null`、CLI 为 `n/a`，绝不伪装成零，也不参与 risk/regression。它不是完整 static analysis、架构证明或运行时性能证据。
-
-新配置默认 `strict_except_generated`；需要 bounded legacy exception 的项目可使用 lifecycle-complete `scoped_waivers`。显式 `ty-context upgrade` 只清理那些纯粹因退役跨语言 JS 启发式的现已不支持指标而存在、且目标没有当前受支持风险的 waiver；普通 `sync` 不执行该迁移，其他 stale/invalid waiver 继续 fail closed。
+`Architecture Context Hit`、`Decision Rationale Hit: existing|required|none` 和 `Modularity Check: none|required|exception` 仍是内部路由问题，不创建 Task Contract 或固定 `plan.md`。可见检查点只证明“存在可审查的考量”，不暴露私有思维链，也不保证最佳设计或预知所有未知未来需求。该义务不增加质量 plan/stage/matrix、第二 Authority、Contract field/aspect/Claim/risk kind、Gate、state 或 Receipt。
+
+Harness 只路由仓库原生 type/compiler/lint/AST/dependency/contract/behavior/benchmark/probe，不实现跨语言通用架构、质量或性能分析器。`ty-context check-modularity` 是 capability-aware portable risk signal：所有纳入格式检查物理行；JS/TS family 另做 lexical 单函数语句/分支、export、state-transition 与 responsibility 启发式；Python 只做专用 lexical 单函数语句/分支；其他格式（包括没有 SFC parser 的 Vue）只做 line-only。输出明确 `analysis=js-ts-heuristic|python-heuristic|line-only`；不支持指标内部为 `null`、CLI 为 `n/a`，绝不伪装成零，也不参与 risk/regression。它不是完整 static analysis、架构证明或运行时性能证据。
+
+新配置默认 `strict_except_generated`；需要 bounded legacy exception 的项目可使用 lifecycle-complete `scoped_waivers`。显式 `ty-context upgrade` 只清理那些纯粹因退役跨语言 JS 启发式的现已不支持指标而存在、且目标没有当前受支持风险的 waiver；普通 `sync` 不执行该迁移，其他 stale/invalid waiver 继续 fail closed。
 
 ### Product Surface 与 Screen Contract
 
 `context_surface_contract` 继续使用现有 `contract`、area/subdomain 和 verification 角色。`product-surface-contract.md` 负责跨页面、主层/下钻与共享职责；可选且按需读取的 `screen-contract.md` 负责单屏 entry/exit/shared state、信息层级、语义区域、导航/变体、material controls 和 target/verification 引用。它们不新增 `design`、`screen` 或 product-surface Context role，局部样式修复也不要求补建 Screen Contract。
 
-material UI 在实现前执行 **UI Authority Closure**：每个稳定 surface/control/target key 必须归类为现有 Context 已覆盖、需要 Context 更新、task-local、显式 out-of-scope 或真正 decision-required。Design Source Projection 把长期 surface/flow/Screen/Control/state 含义放入既有 Surface 或 Screen/interaction Context，把视觉系统/token/motion policy/rationale 放入 `DESIGN.md`，把精确构图/数值/条件/asset 留在 versioned target，把可重复证明路径放入 verification Context，而 delivery-local coverage/provenance/blocker 留在任务或 Contract Source。出现冲突时 fail closed；当前代码、时间戳、YAML 或实现截图不能静默胜出。
-
-### 非 UI 语义完整性
-
-两条开发路径都把非 UI 需求的“完整、准确表达”定义为：在直接表达、逻辑必然、明确委托或权威仓库证据支持的范围内，下钻到最细、可独立判定的 semantic Fact。这既包括产品/业务语义，也包括技术、后端和架构语义；段落、Requirement、Product Control、宽泛状态目录和当前代码都不是粒度上限。
-
-作者端必须完整索引 material 请求片段、附件、controlling Context unit、canonical specification、外部约束、需要保留的仓库事实和 delegated instruction。标准目录是强制下限：目标/scope/glossary；actor/role/tenant/entitlement；业务规则/计算；entity/field/relation；command/query/workflow/state/time；validation/output/error/API/protocol/event/job；persistence/cache/search/transaction/consistency/concurrency/idempotency；fault/retry/degradation/recovery/backup；configuration/flag/secret；compatibility/migration/rollout；performance/capacity/cost/reliability/SLO；security/privacy/safety/compliance；observability/deployment/operations；integration/notification/file/media/localization/commercial；hardware；AI/ML；architecture owner/boundary/debt。领域特有 family、property、condition axis 和 proof method 必须扩展这个下限。
-
-每个适用 subject、typed relation 和 static/dynamic population 都有稳定身份。actor/role/tenant/version/environment/state/input/boundary/locale/time/concurrency/dependency/failure/migration/rollout/threat/custom condition 的每个适用值与精确组合都是一等原子项。每个 atomic property 要么明确 specified，要么有准确对象、basis 和 rationale 的 N/A/exclusion；unresolved、unavailable、conflict 或 unreadable 会阻断。`all-states` 等聚合字符串、默认路径、representative/pairwise sample 和无依据 N/A 都不能冒充原子 cell。
-
-一个 semantic Fact 绑定 `Outcome × subject/relation/population × exact condition × atomic property × typed expected predicate`，并保留 owner、Source locator/digest、provenance、quantifier、observation boundary 和 sensitivity。Fact identity 与 proof obligation 分离：每个 Fact 展开所有 required methods，并一直观察到最远可独立失败边界，同时冻结 comparator/parameters/tolerance/mask、Oracle capability/identity、environment 和 protected-value policy。精确值留在 Source 或 owning Context，下游只保存身份与比较权威，不复制成第二份语义数值源。
-
-普通默认流程在任务内保持精确 accounting，要求 `Expected Semantic Facts = Source Indexed Facts = implementation/acceptance accounted Facts`，并为每个 `Fact × required-method` 保存当前候选可归因的 observation/environment/comparison/Oracle/verdict；它不创建 manifest、matrix、Claim set、state 或 Gate。显式 Long-Task 则在 Source 中持久化一个 `semantic-fact-manifest-v1`，要求 `Expected = Source Indexed = Contract Indexed Facts`，把每个机器义务映射到单 Fact Assertion 和 typed `semantic_fact` result（或命名 External Confirmation），并在现有唯一 Final Gate 中验证 expectation/result 精确相等。任何 missing、extra、duplicate、unresolved、unmapped、unimplemented、unexecuted、stale、failed、proxy-only、reused 或 indistinguishable row 都阻止完成。
-
-该机制不能发现用户从未表达的意图，也不能证明任意 Inspector/Oracle 的语义绝对正确。它只能补全必要推导与用户明确委托且可辩护的选择；真正的产品、法律、安全、商业、安全性或外部 owner 决策继续阻断。耐久含义仍进入既有 Context owner，代码仍是当前实现事实；不会新增第二 plan、registry、Authority、Gate 或固定实现顺序。
-
-### 视觉交付指导
-
-两种开发路径共享一个条件式设计目的：当存在已选 implementation handoff 时，让 Agent 的开发、验收和测试在 UI/UX 方面完整遵循选定设计资源在声明范围与条件内明确表达的全部材料性信息。它不授权从静态图推断未表达的交互，也不能证明用户没有遗漏要求。Open Design 有能力输出实现级 HTML/CSS/JS、spec、token 与 asset，但“有能力”不等于每次都产出：选定 Web/App 实现 handoff 时，`design-resource-authoring` 必须显式委托并完整取得一个机器可读 canonical entry 及其精确 dependency closure，逐文件冻结 digest，并暴露稳定的 typed locator；进入 `ready` 前，还要在这些不可变字节上逐项执行声明的 verification method，无法消除的 code/spec/token/asset 冲突保持未决/不可用并阻塞。这是源资源 QA，不是生产验收。PNG 只能作为派生视觉基线，不能成为唯一实现源。
-
-provider-neutral handoff 是残余语义与索引层，不是 CSS 文本副本或第二份数值权威。正式 Web/App 生成前，`design-resource-authoring` 必须从明确 scope、已采纳 Design Authority 与冻结的 Inspector/Census 义务中先推导 Expected Fact Universe。原子单元是每个适用的 `subject × selected target × condition combination × variation combination × property` Fact Cell。subject 一等覆盖 surface、region、overlay、component family/instance、control、每个 anatomy part/slot/primitive、text、icon、media、asset 与 relation；condition 一等覆盖 33 个标准 condition axes，包括 platform/runtime/device/viewport/density/safe area/window/fold/display/color/localization/content/data/text scale/input/assistive 与无障碍偏好/system UI/IME/permission/capability/connectivity/lifecycle；variation 一等覆盖 5 个 variation axes：`variant`、`state`、`interaction_phase`、`presence_phase` 与 `instance_case`。property 使用 geometry、layout、scroll、typography、color、decoration、content、icon、media、interaction/navigation、motion/feedback、responsive、accessibility、asset、system、relation 共 217 个标准原子属性键，并允许显式声明 custom property。
-
-生成的 canonical implementation source 仍是精确值的唯一 owner。其 dependency closure 内含 `design-resource-observable-fact-manifest-v1`：稳定 subject/property/Fact ID、typed locator、定位值 digest、单位/舍入/pixel snapping、token/effective-value lineage、dynamic population/relation/asset、required proof method、comparator parameter/tolerance/mask、Oracle identity/capability 与 render environment。冻结 Inspector 必须完整枚举 resource/node/declaration/token/asset/relation/custom-property/variant/state/interaction/dynamic-population Census；complete-generation count 与 digest 证明没有抽样或截断。每个适用 Fact Cell 要么由一个原子 Fact 覆盖，要么有带 Source/basis/rationale 的显式 blocking/non-applicable disposition。“all states”等聚合字符串不能冒充原子值，也不能用 default 页面或 shared style 推断其他适用组合。
-
-`ready` 必须满足精确集合等式：`Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts`，并闭合每个资源为 material-with-facts 或真实 supporting-only。handoff 保存身份、locator、digest 与证明绑定，而不复制 CSS 数值。`exact_target` 的每个适用 condition 还必须有 full-target layout 与 pixel Facts；做不到就只能保持 partial constraint 或阻断。preflight 会在不可变本地资源上解析 manifest 与全部 typed locator，校验 dependency/Census/Fact/proof closure，并拒绝 missing、duplicate、unresolved、unsupported、stale、media 不兼容或数值冲突；探索候选仍不需要 schema。
-
-这些输入仍是普通 Source。默认 Workflow 对每个 Fact 及其 required proof obligation 做精确 task-local accounting，并从可归因的生产 owner、冷启动 final-candidate check 记录当前 actual observation/environment、comparison、tolerance、pass/fail 与 Oracle identity。任何 unread、unsupported、unresolved、unmapped、unimplemented、unexecuted、stale、复用或无法区分的适用 Fact 都阻止“完整遵循”并作为 gap 报告。Long-Task 把同一 universe 投影进已有 Claims/Assertions/Checks/Bindings：每个 method/condition cell 保存精确 `fact_refs`，每个 Fact/proof obligation 有一个 `fact_expectations` row，再由一个当前 `fact_results` row 保存同一 observation/comparison/authority 元组；Final Gate 要求 expectation/result 集合精确相等且同一当前快照上全部通过。受保护/敏感 observation 只可 redacted 或 digest-only，但不能丢失 comparison authority。两种证明载体互斥：active Long-Task 不再执行默认 closure。生成成功、截图、hash、Census 与 preflight 只证明输入完整性/完整性，不证明生产一致性。
-
-默认 Workflow 会在 material 产品、设计、实现或验收判断前执行 UI Authority Closure 和条件式 Design Authority Check。它沿稳定 key 到 exactly-one canonical adoption record，再主动打开每个受影响的 selected `exact-target`/`constraint`；只看到 registry 或 handoff index 不算已消费。项目/系统/component-family target 由 `DESIGN.md` canonical 记录，单 screen/interaction target 由 owning Screen Contract 记录；该 record 独占 interpretation、selection basis、immutable locator/digest、condition coverage 和 editable upstream/update route，其他层只保留 stable key、owner/anchor 和 local applicability。缺失、不可读、过期或冲突时 fail closed；更新必须产生新 immutable version，不能覆盖旧基线。未配置 starter、候选稿、只有风格文字或灵感图都不能授权 agent 发明生产布局。明确的设计系统采纳请求路由到 `design-system-authoring`，独立资源生成请求路由到 `design-resource-authoring`；已有充分权威的普通实现、局部样式修复和 throwaway prototype 仍保持轻量。
-
-只要是已经选定、准备进入实现的设计资源，两种开发路径都会先运行 `ty-context design-resource preflight <handoff.md>`。取得不完整、缺少或多出未声明依赖、不安全路径、过期 digest、虚构 locator、Census 未冻结/不完整、生成被抽样/截断、轴值被聚合、Expected/Canonical/Handoff Fact 集不相等、required method 缺失、comparator/Oracle/environment 绑定无效、design-system lineage 未解析、适用 cell 未覆盖、exact target 缺 full-target layout/pixel Fact、证据不受支持或含义未决都 fail closed。preflight 只证明设计输入语义完整且资源身份正确；开发流程仍必须打开真实资源，并从生产入口证明当前实现。
+material UI 在实现前执行 **UI Authority Closure**：每个稳定 surface/control/target key 必须归类为现有 Context 已覆盖、需要 Context 更新、task-local、显式 out-of-scope 或真正 decision-required。Design Source Projection 把长期 surface/flow/Screen/Control/state 含义放入既有 Surface 或 Screen/interaction Context，把视觉系统/token/motion policy/rationale 放入 `DESIGN.md`，把精确构图/数值/条件/asset 留在 versioned target，把可重复证明路径放入 verification Context，而 delivery-local coverage/provenance/blocker 留在任务或 Contract Source。出现冲突时 fail closed；当前代码、时间戳、YAML 或实现截图不能静默胜出。
+
+### 非 UI 语义完整性
+
+两条开发路径都把非 UI 需求的“完整、准确表达”定义为：在直接表达、逻辑必然、明确委托或权威仓库证据支持的范围内，下钻到最细、可独立判定的 semantic Fact。这既包括产品/业务语义，也包括技术、后端和架构语义；段落、Requirement、Product Control、宽泛状态目录和当前代码都不是粒度上限。
+
+作者端必须完整索引 material 请求片段、附件、controlling Context unit、canonical specification、外部约束、需要保留的仓库事实和 delegated instruction。标准目录是强制下限：目标/scope/glossary；actor/role/tenant/entitlement；业务规则/计算；entity/field/relation；command/query/workflow/state/time；validation/output/error/API/protocol/event/job；persistence/cache/search/transaction/consistency/concurrency/idempotency；fault/retry/degradation/recovery/backup；configuration/flag/secret；compatibility/migration/rollout；performance/capacity/cost/reliability/SLO；security/privacy/safety/compliance；observability/deployment/operations；integration/notification/file/media/localization/commercial；hardware；AI/ML；architecture owner/boundary/debt。领域特有 family、property、condition axis 和 proof method 必须扩展这个下限。
+
+每个适用 subject、typed relation 和 static/dynamic population 都有稳定身份。actor/role/tenant/version/environment/state/input/boundary/locale/time/concurrency/dependency/failure/migration/rollout/threat/custom condition 的每个适用值与精确组合都是一等原子项。每个 atomic property 要么明确 specified，要么有准确对象、basis 和 rationale 的 N/A/exclusion；unresolved、unavailable、conflict 或 unreadable 会阻断。`all-states` 等聚合字符串、默认路径、representative/pairwise sample 和无依据 N/A 都不能冒充原子 cell。
+
+一个 semantic Fact 绑定 `Outcome × subject/relation/population × exact condition × atomic property × typed expected predicate`，并保留 owner、Source locator/digest、provenance、quantifier、observation boundary 和 sensitivity。Fact identity 与 proof obligation 分离：每个 Fact 展开所有 required methods，并一直观察到最远可独立失败边界，同时冻结 comparator/parameters/tolerance/mask、Oracle capability/identity、environment 和 protected-value policy。精确值留在 Source 或 owning Context，下游只保存身份与比较权威，不复制成第二份语义数值源。
+
+普通默认流程在任务内保持精确 accounting，要求 `Expected Semantic Facts = Source Indexed Facts = implementation/acceptance accounted Facts`，并为每个 `Fact × required-method` 保存当前候选可归因的 observation/environment/comparison/Oracle/verdict；它不创建 manifest、matrix、Claim set、state 或 Gate。显式 Long-Task 则在 Source 中持久化一个 `semantic-fact-manifest-v1`，要求 `Expected = Source Indexed = Contract Indexed Facts`，把每个机器义务映射到单 Fact Assertion 和 typed `semantic_fact` result（或命名 External Confirmation），并在现有唯一 Final Gate 中验证 expectation/result 精确相等。任何 missing、extra、duplicate、unresolved、unmapped、unimplemented、unexecuted、stale、failed、proxy-only、reused 或 indistinguishable row 都阻止完成。
+
+该机制不能发现用户从未表达的意图，也不能证明任意 Inspector/Oracle 的语义绝对正确。它只能补全必要推导与用户明确委托且可辩护的选择；真正的产品、法律、安全、商业、安全性或外部 owner 决策继续阻断。耐久含义仍进入既有 Context owner，代码仍是当前实现事实；不会新增第二 plan、registry、Authority、Gate 或固定实现顺序。
+
+### 视觉交付指导
+
+两种开发路径共享一个条件式设计目的：当存在已选 implementation handoff 时，让 Agent 的开发、验收和测试在 UI/UX 方面完整遵循选定设计资源在声明范围与条件内明确表达的全部材料性信息。它不授权从静态图推断未表达的交互，也不能证明用户没有遗漏要求。Open Design 有能力输出实现级 HTML/CSS/JS、spec、token 与 asset，但“有能力”不等于每次都产出：选定 Web/App 实现 handoff 时，`design-resource-authoring` 必须显式委托并完整取得一个机器可读 canonical entry 及其精确 dependency closure，逐文件冻结 digest，并暴露稳定的 typed locator；进入 `ready` 前，还要在这些不可变字节上逐项执行声明的 verification method，无法消除的 code/spec/token/asset 冲突保持未决/不可用并阻塞。这是源资源 QA，不是生产验收。PNG 只能作为派生视觉基线，不能成为唯一实现源。
+
+provider-neutral handoff 是残余语义与绑定层，不是 CSS 文本副本、第二份数值权威或第二份完整 Fact 索引。正式 Web/App 生成前，`design-resource-authoring` 必须从明确 scope、已采纳 Design Authority 与冻结的 Inspector/Census 义务中先推导 Expected Fact Universe。原子单元是每个适用的 `subject × selected target × condition combination × variation combination × property` Fact Cell。subject 一等覆盖 surface、region、overlay、component family/instance、control、每个 anatomy part/slot/primitive、text、icon、media、asset 与 relation；condition 一等覆盖 33 个标准 condition axes，包括 platform/runtime/device/viewport/density/safe area/window/fold/display/color/localization/content/data/text scale/input/assistive 与无障碍偏好/system UI/IME/permission/capability/connectivity/lifecycle；variation 一等覆盖 5 个 variation axes：`variant`、`state`、`interaction_phase`、`presence_phase` 与 `instance_case`。property 使用 geometry、layout、scroll、typography、color、decoration、content、icon、media、interaction/navigation、motion/feedback、responsive、accessibility、asset、system、relation 共 217 个标准原子属性键，并允许显式声明 custom property。
+
+生成的 canonical implementation source 仍是精确值的唯一 owner。其 dependency closure 内含 `design-resource-observable-fact-manifest-v1`：稳定 subject/property/Fact ID、typed locator、定位值 digest、单位/舍入/pixel snapping、token/effective-value lineage、dynamic population/relation/asset、required proof method、comparator parameter/tolerance/mask、Oracle identity/capability 与 render environment。冻结 Inspector 必须完整枚举 resource/node/declaration/token/asset/relation/custom-property/variant/state/interaction/dynamic-population Census；complete-generation count 与 digest 证明没有抽样或截断。每个适用 Fact Cell 要么由一个原子 Fact 覆盖，要么有带 Source/basis/rationale 的显式 blocking/non-applicable disposition。“all states”等聚合字符串不能冒充原子值，也不能用 default 页面或 shared style 推断其他适用组合。
+
+`ready` 必须满足精确集合等式：`Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts`，并闭合每个资源为 material-with-facts 或真实 supporting-only。canonical per-target manifest 是完整 Fact/Census/proof 索引的唯一 owner；同一个已发布的 `design-resource-handoff-v1` 标识下，新文件用 `representation: manifest_backed` 只保存 Source/scope/resource/target/closure/coverage/proposal 绑定，preflight 从冻结 manifest 直接还原原有完整 V1 对象。旧的嵌入式 V1 只保留读取兼容，不新增 V2。`exact_target` 的每个适用 condition 还必须有 full-target layout 与 pixel Facts；做不到就只能保持 partial constraint 或阻断。preflight 会在不可变本地资源上解析 manifest 与全部 typed locator，校验 dependency/Census/Fact/proof closure，并拒绝 missing、duplicate、unresolved、unsupported、stale、media 不兼容或数值冲突；探索候选仍不需要 schema。
+
+容量优化发生在生成表示上，不是生成后拆分。写 Markdown 前，DSA 冻结明确的 canonical manifest 路径集合、target/scope identity、文件 SHA-256 与每个 collection 的精确 count/identity digest，并声明实际 UTF-8 上限；随后直接生成一 target 一份的小型 manifest-backed draft，其中不再复制 axes/conditions/subjects/variations/properties/lineage/Fact Cells/Facts/evidence/proofs/Oracles/environments/assets/blockers。共享含义用唯一 key 的 target-attributed Source Fact 保留原 predicate 与 provenance。`ty-context design-resource bundle` 对完整 draft/manifest 集合逐 target 做单快照 preflight，拒绝嵌入式全量数组、多 target draft、超限 descriptor、target 缺失/多出/重复及任何 manifest/digest/语义漂移，再用同卷临时目录把整组原子发布到此前不存在的最终目录。失败只删除命令自己的临时目录，不覆盖、拆分或改写 draft/已采纳 handoff。字节检查只是防止生成器违约或后续突变，不是 post-hoc split；真实 residual 数据若无法满足所选上限，就判定该上限不兼容并 fail closed，绝不拆 target、抽样、截断、粗化 Fact 或扩大 exclusion。Long-Task 只在既有读取接缝逐 target 消费规范化对象，不改变 Contract、Authority、Outcome、Final Gate、状态恢复或完成判定。
+
+这些输入仍是普通 Source。默认 Workflow 对每个 Fact 及其 required proof obligation 做精确 task-local accounting，并从可归因的生产 owner、冷启动 final-candidate check 记录当前 actual observation/environment、comparison、tolerance、pass/fail 与 Oracle identity。任何 unread、unsupported、unresolved、unmapped、unimplemented、unexecuted、stale、复用或无法区分的适用 Fact 都阻止“完整遵循”并作为 gap 报告。Long-Task 把同一 universe 投影进已有 Claims/Assertions/Checks/Bindings：每个 method/condition cell 保存精确 `fact_refs`，每个 Fact/proof obligation 有一个 `fact_expectations` row，再由一个当前 `fact_results` row 保存同一 observation/comparison/authority 元组；Final Gate 要求 expectation/result 集合精确相等且同一当前快照上全部通过。受保护/敏感 observation 只可 redacted 或 digest-only，但不能丢失 comparison authority。两种证明载体互斥：active Long-Task 不再执行默认 closure。生成成功、截图、hash、Census 与 preflight 只证明输入完整性/完整性，不证明生产一致性。
+
+默认 Workflow 会在 material 产品、设计、实现或验收判断前执行 UI Authority Closure 和条件式 Design Authority Check。它沿稳定 key 到 exactly-one canonical adoption record，再主动打开每个受影响的 selected `exact-target`/`constraint`；只看到 registry 或 handoff index 不算已消费。项目/系统/component-family target 由 `DESIGN.md` canonical 记录，单 screen/interaction target 由 owning Screen Contract 记录；该 record 独占 interpretation、selection basis、immutable locator/digest、condition coverage 和 editable upstream/update route，其他层只保留 stable key、owner/anchor 和 local applicability。缺失、不可读、过期或冲突时 fail closed；更新必须产生新 immutable version，不能覆盖旧基线。未配置 starter、候选稿、只有风格文字或灵感图都不能授权 agent 发明生产布局。明确的设计系统采纳请求路由到 `design-system-authoring`，独立资源生成请求路由到 `design-resource-authoring`；已有充分权威的普通实现、局部样式修复和 throwaway prototype 仍保持轻量。
+
+只要是已经选定、准备进入实现的设计资源，DSA 先用 `ty-context design-resource bundle` 发布精确 target 集；两种开发路径再对每个已发布 handoff 运行 `ty-context design-resource preflight <handoff.md>`。取得不完整、缺少或多出未声明依赖/target、target 重复、不安全路径、manifest/文件 digest 过期、虚构 locator、Census 未冻结/不完整、生成被抽样/截断、轴值被聚合、Expected/Canonical/Handoff Fact 集不相等、required method 缺失、comparator/Oracle/environment 绑定无效、design-system lineage 未解析、适用 cell 未覆盖、exact target 缺 full-target layout/pixel Fact、证据不受支持或含义未决都 fail closed。preflight 只证明设计输入语义完整且资源身份正确；开发流程仍必须打开真实资源，并从生产入口证明当前实现。
 
 对 material 工作，`context_uiux_design` 应用上面的投影规则并让风险比例化 coverage reasoning 保持 task-local。`context_development_engineer` 用稳定 surface/control key 把每个选定 target/condition 及 handoff 精确集合追踪到生产 route/component owner、冷启动真实用户旅程及可独立归因的渲染/交互检查。第一个有价值的可运行纵向切片只是建议性的真实入口反馈点，不是实现门禁；最终候选仍必须重跑受影响的冷启动旅程。所有已声明/适用组合必须完整覆盖，不能用 risk-only 或 pairwise 抽样替代，除非权威 Source 明确收窄范围或项目自有证明建立等价性。只报告真正检查过的组合；资源哈希、manifest 和数量只证明资源完整性，实现截图既不能成为自己的目标，也不能单独证明实现一致性。
 
-显式 Long-Task 是同一共享义务的强机器载体。它在 Compile 前解决缺失/冲突的 UI 权威，并用 `field_coverage` 闭合每个真实 Product Control 的全部 22 个 canonical 字段；这条产品语义投影与更细的 design Fact universe 相互独立，绝不构成粒度上限。选定 target 冻结 canonical manifest identity/digest，并把每个原子 Fact/required-method 对投影为一个 `fact_expectations` row，其中包含 subject/target/condition/variation/property identity、expected located-value digest、comparator/parameter/tolerance/mask、Oracle identity/capability、environment 和 sensitivity。当前 Check evidence 提供精确匹配的 `fact_results` row，包含 actual observation/environment、comparison 与 pass/fail；observation 重复/复用、result 缺失、authority 过期或任一失败都阻断 Final Gate。`design_conformance` 仍是 target-level actual/comparison artifact 的 typed 当前执行记录，`design_method` 则绑定可独立失败的 method/condition cell 及其逐 Fact rows；任何聚合记录都不能替代原子 Fact 证明。Product `surface_bindings`、Control Claims/relations 与 root-entry journey 继续承载产品语义，已有 Claim、Assertion、Check、Stage、Binding、revision 与 Final Gate 仍是唯一 Long-Task 生命周期和 closure。每个 blocker 保留精确 Source-item/method/capability lineage，不能在 Contract 内自行豁免；缩减范围必须修订 Source/Contract 权威。
+显式 Long-Task 是同一共享义务的强机器载体。它在 Compile 前解决缺失/冲突的 UI 权威，并用 `field_coverage` 闭合每个真实 Product Control 的全部 22 个 canonical 字段；这条产品语义投影与更细的 design Fact universe 相互独立，绝不构成粒度上限。选定 target 冻结 canonical manifest identity/digest，并把每个原子 Fact/required-method 对投影为一个 `fact_expectations` row，其中包含 subject/target/condition/variation/property identity、expected located-value digest、comparator/parameter/tolerance/mask、Oracle identity/capability、environment 和 sensitivity。当前 Check evidence 提供精确匹配的 `fact_results` row，包含 actual observation/environment、comparison 与 pass/fail；observation 重复/复用、result 缺失、authority 过期或任一失败都阻断 Final Gate。`design_conformance` 仍是 target-level actual/comparison artifact 的 typed 当前执行记录，`design_method` 则绑定可独立失败的 method/condition cell 及其逐 Fact rows；任何聚合记录都不能替代原子 Fact 证明。Product `surface_bindings`、Control Claims/relations 与 root-entry journey 继续承载产品语义，已有 Claim、Assertion、Check、Stage、Binding、revision 与 Final Gate 仍是唯一 Long-Task 生命周期和 closure。每个 blocker 保留精确 Source-item/method/capability lineage，不能在 Contract 内自行豁免；缩减范围必须修订 Source/Contract 权威。
 
 combined design-and-implementation 可以先用普通 Outcome/Stage 生成候选，但 candidate/planned target 不能解锁 fidelity implementation；选定结果必须先成为真实 marked Context-reachable Source，并由 owning Context/`DESIGN.md` reference 连接，Authority Lock 后再通过 Authority Revision 采用。浏览器视觉 AC 使用 `ui_browser`；浏览器代理、独立 route 或深链接不能证明可独立失败的原生/root 旅程。资源完整性和 `visual_render` 不能替代选定目标的实现一致性。冻结 baseline 是 verifier input，生成的 actual render/diff 是当前 artifact，主观批准保持外部。这不新增 `uiux_delivery`、视觉 Claim type、resource registry、risk level、lifecycle state、Gate、必需设计目录、逐控件截图矩阵或通用像素阈值。
 
@@ -201,25 +229,25 @@ combined design-and-implementation 可以先用普通 Outcome/Stage 生成候选
 
 ### 显式 Design System Authoring
 
-只有用户明确要求初始化、生成、选择、采纳、替换或修复项目设计系统/设计风格时，才使用 `design-system-authoring`。安装只让冷启动能力可用，不会自动运行。Skill 会发现 Open Design 当前真实 MCP resource/tool；若当前版本只通过 MCP 读取设计系统而没有创建 tool，则使用同一个已安装 Open Design daemon 的官方 generation/revision/accept API，不复制 provider prompt，也不把 daemon 调用冒充 MCP。
+只有用户明确要求初始化、生成、选择、采纳、替换或修复项目设计系统/设计风格时，才使用 `design-system-authoring`。安装只让冷启动能力可用，不会自动运行。Skill 会发现 Open Design 当前真实 MCP resource/tool；若当前版本只通过 MCP 读取设计系统而没有创建 tool，则使用同一个已安装 Open Design daemon 的官方 generation/revision/accept API，不复制 provider prompt，也不把 daemon 调用冒充 MCP。
 
 生成结果先是候选。必须有明确人工选择，或用户明确委托且选择标准已知，才会采纳到项目 canonical `DESIGN.md`、唯一 authored exact-value token source/generation direction，以及真正拥有 surface/interaction 耐久事实的 Context。Open Design provider ID、revision、digest 与 project binding 只是同步 provenance，不是第二权威。provider 执行成功、artifact ready、selected、authority adopted 与 `get_project.designSystemId` binding verified 会分开报告。
 
 ### 可选 Design Resource Authoring
 
-只有在用户明确要求生成、迭代、准备独立设计资源、为一段明确开发内容准备设计资源或使用 Open Design 时，才使用 `design-resource-authoring`。输入可以是零散笔记或初始方案、产品/技术方案、专门视觉 brief、截图、已有资源或历史 Source Plan。独立 Source Plan 不是前置项，也不再是推荐中间步骤。
+只有在用户明确要求生成、迭代、准备独立设计资源、为一段明确开发内容准备设计资源或使用 Open Design 时，才使用 `design-resource-authoring`。输入可以是零散笔记或初始方案、产品/技术方案、专门视觉 brief、截图、已有资源或历史 Source Plan。独立 Source Plan 不是前置项，也不再是推荐中间步骤。
+
+Skill 把明确输出或开发内容当作硬 scope ceiling。局部功能只可带上定位它所需的周边上下文；再丰富的背景也不能把生成范围扩成页面其余部分或整个产品。面向实现 handoff 时，Skill 要覆盖范围内所有材料性的 UI/UX 含义：surface/flow 与 region 结构、视觉和内容呈现、控件结构/尺寸/变体、静态与动态状态、交互/反馈/恢复/动效、响应式/平台/输入方式、可访问性及必要资产；先扣除已有 selected Source 明确覆盖的条件，再发现 Open Design 当前 agent/model、functional skill、rendering template、design system、plugin 与 export route，并把每种候选资源说明为 `selected`、`optional`、`not-needed`、`unavailable` 或 `decision-required`。
 
-Skill 把明确输出或开发内容当作硬 scope ceiling。局部功能只可带上定位它所需的周边上下文；再丰富的背景也不能把生成范围扩成页面其余部分或整个产品。面向实现 handoff 时，Skill 要覆盖范围内所有材料性的 UI/UX 含义：surface/flow 与 region 结构、视觉和内容呈现、控件结构/尺寸/变体、静态与动态状态、交互/反馈/恢复/动效、响应式/平台/输入方式、可访问性及必要资产；先扣除已有 selected Source 明确覆盖的条件，再发现 Open Design 当前 agent/model、functional skill、rendering template、design system、plugin 与 export route，并把每种候选资源说明为 `selected`、`optional`、`not-needed`、`unavailable` 或 `decision-required`。
-
-正式 Web/App implementation output 中，“完整”默认就是上文的范围内最细可观察 Fact 粒度。Skill 在委托生成前先构造 Expected Fact Universe 与冻结 Inspector/Census 义务，把它们连同已采纳 design-system identity 一起传给 Open Design，并要求返回的 canonical source/manifest 表达每个适用 cell；不能等下游实现时才发现或自行补设计 anatomy-part、状态、响应式/平台/text-scale、动效、无障碍或资产事实。
+正式 Web/App implementation output 中，“完整”默认就是上文的范围内最细可观察 Fact 粒度。Skill 在委托生成前先构造 Expected Fact Universe 与冻结 Inspector/Census 义务，把它们连同已采纳 design-system identity 一起传给 Open Design，并要求返回的 canonical source/manifest 表达每个适用 cell；不能等下游实现时才发现或自行补设计 anatomy-part、状态、响应式/平台/text-scale、动效、无障碍或资产事实。
 
-Skill 会先分类 visual-style dependency。高保真/品牌化输出、视觉方向、字体/颜色/密度、组件视觉处理和 production-style prototype 属于 style-bearing：若 `DESIGN.md` 未配置或没有唯一 authored token source/direction，Skill 必须在创建 provider project/run 前停下，并提示用户显式选择 `design-system-authoring`，绝不自动初始化。低保真结构、IA/flow topology 和纯语义 behavior/state study 属于 non-fidelity。style-bearing 工作必须把已采纳 provider ID 传给 MCP `create_project.designSystem`，并用 `get_project.designSystemId` 验证一致。
+Skill 会先分类 visual-style dependency。高保真/品牌化输出、视觉方向、字体/颜色/密度、组件视觉处理和 production-style prototype 属于 style-bearing：若 `DESIGN.md` 未配置或没有唯一 authored token source/direction，Skill 必须在创建 provider project/run 前停下，并提示用户显式选择 `design-system-authoring`，绝不自动初始化。低保真结构、IA/flow topology 和纯语义 behavior/state study 属于 non-fidelity。style-bearing 工作必须把已采纳 provider ID 传给 MCP `create_project.designSystem`，并用 `get_project.designSystemId` 验证一致。
 
-Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）委托最小充分的 artifact/file 集；最小化的是包装数量，绝不是信息粒度。一个 canonical HTML/CSS/JS 原型加 manifest、tokens/assets 与可检查的 state/component workbench 就可以承载数千个原子 Fact。重复控件可以映射到共享变体，只有仍缺少材料性含义的独特/复杂控件才需要专门状态或交互稿。静态/default 页面不能自动代表没展示的动态状态、交互、动效、响应式或可访问性。原型、低/高保真组合、组件板、provider-native 输入、逐控件一份稿、变体数量和目录都不是全局必选项。设计资源可以表达用户可感知的交互语义和产品规则的呈现方式，但业务、数据、权限和算法逻辑仍由产品/技术 Source 所有。Tiny Context 不复制 Open Design 的 prompt/template，也不内置 provider catalogue。
+Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）委托最小充分的 artifact/file 集；最小化的是包装数量，绝不是信息粒度。一个 canonical HTML/CSS/JS 原型加 manifest、tokens/assets 与可检查的 state/component workbench 就可以承载数千个原子 Fact。重复控件可以映射到共享变体，只有仍缺少材料性含义的独特/复杂控件才需要专门状态或交互稿。静态/default 页面不能自动代表没展示的动态状态、交互、动效、响应式或可访问性。原型、低/高保真组合、组件板、provider-native 输入、逐控件一份稿、变体数量和目录都不是全局必选项。设计资源可以表达用户可感知的交互语义和产品规则的呈现方式，但业务、数据、权限和算法逻辑仍由产品/技术 Source 所有。Tiny Context 不复制 Open Design 的 prompt/template，也不内置 provider catalogue。
 
 面向 Web/App 实现时，Skill 必须取得上文所述完整 canonical entry/dependency set 与可寻址事实。Figma 适合已经存在的设计团队权威，需要原生 Components/Variables/Variants、共享库、Dev Mode 或 Code Connect 的场景；Penpot 适合明确需要开放、自托管多人设计基础设施的场景；OpenPencil 可作为本地静态布局 sidecar，但当前 prototype/motion 模型仍不完整。把完整 Open Design Source 默认转换为另一种表示会增加同步和运维成本，却不会关闭新的 enforcement gap，因此三者都不是默认依赖。
 
-探索模式只做最小完整性检查并尽快展示指定候选，不需要 handoff schema。明确或受托最终选择且资源将进入实现时，Skill 只做一次合并、幂等的初始方案回改，并在任意获准的项目路径写一个 provider-neutral、带 Source marker、且只含一个严格残余 `design-resource-handoff-v1` block 的 Markdown。它记录 canonical manifest/Inspector/Census identity、精确 indexed Fact universe/disposition、implementation source profile、typed locator/digest、残余产品含义、逐 Fact proof binding 和 acceptance blocker；随后运行共享 preflight，不能把取得不完整、不可寻址、`decision_required`、`unavailable`、证据不成立、过期或集合不相等的输入称为 ready。这里没有固定目录、provider pack 或逐控件一份稿；适配器只是普通 Source，不是 Design Authority 或验收结果。Skill 不会修改 Source Plan、`project_context/**`、`DESIGN.md`、生产代码或 Delivery Contract。
+探索模式只做最小完整性检查并尽快展示指定候选，不需要 handoff schema。明确或受托最终选择且资源将进入实现时，Skill 只做一次合并、幂等的初始方案回改，并在任意获准的项目路径按 target 写 provider-neutral、带 Source marker、且只含一个严格 manifest-backed `design-resource-handoff-v1` block 的 Markdown。canonical manifest 保留完整 Inspector/Census/Fact/proof universe；小 YAML 只记录其不可变 resource/target 绑定及 residual 产品/coverage/Source/proposal 含义。共享 preflight 还原同一个完整校验对象，不能把取得不完整、不可寻址、`decision_required`、`unavailable`、证据不成立或过期的输入称为 ready。这里没有固定目录、provider pack 或逐控件一份稿；适配器只是普通 Source，不是 Design Authority 或验收结果。Skill 不会修改 Source Plan、`project_context/**`、`DESIGN.md`、生产代码或 Delivery Contract。
 
 实际生成仍由已配置的 Open Design/Product Design、Figma、图片生成、原型工具或人工设计流程负责。这些输出以普通 external Source 进入默认 Workflow 或 Long-Task。candidate 与 inspiration 不授权 fidelity；adopted exact target/constraint 作为 Context-reachable Source，由 owning Context/`DESIGN.md` 把稳定 key 连接到覆盖条件、不可变身份/digest 和 editable upstream owner/locator/update route。`context_uiux_design` 在下游执行 UI Authority Closure，只把耐久事实采纳到 Context/`DESIGN.md`；实现截图与 diff 仍是证据 artifact，不能自我授权为目标。
 
@@ -227,28 +255,28 @@ Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）
 
 ### 退役 Source Plan 兼容入口
 
-`source-plan-authoring` 仅作为 long-task profile 的兼容指引保留。`long-task-workflow` 从入口立即打开非权威 Contract Draft，并让完整 input inventory、混合输入综合/细化、稳定 Key、Product Control 级语义、偏好/调研/委托溯源、Source marker/provenance、acceptance/risk 与 Contract 映射在同一循环中收敛。这里的 Control 语义投影不限制另一条选定资源“完整可观察设计事实”清单的粒度。已有 Source Plan 仍是有效普通 Source，但不再创建独立或内部 Source-authoring 阶段、handoff、Schema、Gate、State 或第二份计划。
+`source-plan-authoring` 仅作为 long-task profile 的兼容指引保留。`long-task-workflow` 从入口立即打开非权威 Contract Draft，并让完整 input inventory、混合输入综合/细化、稳定 Key、Product Control 级语义、偏好/调研/委托溯源、Source marker/provenance、acceptance/risk 与 Contract 映射在同一循环中收敛。这里的 Control 语义投影不限制另一条选定资源“完整可观察设计事实”清单的粒度。已有 Source Plan 仍是有效普通 Source，但不再创建独立或内部 Source-authoring 阶段、handoff、Schema、Gate、State 或第二份计划。
 
 ## Single-Goal Rolling Delivery
 
-只有用户显式选择 `long-task-workflow`，或当前 worktree 已有 active long task 时才使用。它固定为：
+只有用户显式选择 `long-task-workflow`，或当前 worktree 已有 active long task 时才使用。它固定为：
 
-- 一个当前宿主选定的原生执行 Goal；压缩可在该 Goal 内继续，后续物理 Goal/session 只恢复语义状态，不重连旧 Turn；
+- 一个当前宿主选定的原生执行 Goal；压缩可在该 Goal 内继续，后续物理 Goal/session 只恢复语义状态，不重连旧 Turn；
 - 一个用户选定的仓库与最终验证/收敛 worktree；
 - 一次完整选定交付、一个 Contract、一个 Final Gate；
 - Outcome 依赖只表示验收与中间证明就绪关系，不限制实现顺序，也不表示 Worker 调度；
 - 第一次 Authority Lock 后、正式实现前有一次用户模型选择；
-- 当前 Goal 自主选择实现顺序、局部计划、工具，并可按 ROI 选择单 agent 或多开平台原生 agent/subagent；Harness 不负责分配、调度、重试或恢复，agent 报告不是 Progress 或证明，所有结果必须汇入同一验证 worktree；Frontier 只提供验收/验证建议；
+- 当前 Goal 自主选择实现顺序、局部计划、工具，并可按 ROI 选择单 agent 或多开平台原生 agent/subagent；Harness 不负责分配、调度、重试或恢复，agent 报告不是 Progress 或证明，所有结果必须汇入同一验证 worktree；Frontier 只提供验收/验证建议；
 - targeted verify 是可选反馈与修复证据，永远不能 accepted，也不构成继续实现或进入 Final Gate 的门禁；
 - scope-only revision 可先做无状态候选诊断，机械边界内的修复自动采用；只有稳定且确需用户决策的候选才至多询问一次精确 identity；
 - Final Gate 在一个当前快照上重跑全部 Check；
-- Stop Hook 在结果 stale 时阻止完成。
-
-它的证明命题有明确前提：Source 在声明观察粒度下完整且准确，Source→Contract 投影保持语义，所有实际适用单元被展开，且具名项目 Oracle 与 verifier/runtime 可信边界语义正确；在这些前提下，只有 fresh `machine_accepted` 且没有任何待定 External Confirmation 的 `AcceptedDeliveryTerminal` 才严格推出完整声明可观察漂移为空。`machine_accepted_external_pending` 只能推出机器可验证范围内的声明漂移为空，完整交付仍是带限定的未完成状态，Harness 不完成原生 Goal。Harness 会机械强制并冻结其中许多前提，但无法发现未声明要求，也无法自动证明任意项目 Oracle 对现实语义忠实。
-
-原始/修订方案、选定设计资源和混合附件会立即进入一个 Source-bound Contract Draft 循环；完整 input inventory、稳定 Key、Product Control 级含义、选定资源设计事实、acceptance/risk、direct/derived/delegated/evidence-backed 溯源、Source 归属与 Contract 映射一起收敛。声明为 Source 的 Markdown 中，每一行非空文本都必须属于一个 Material `ty-source-item` 块、唯一且通过 schema 校验的 `design-resource-handoff-v1` formal block，或满足封闭语法的 background：`markdown-structure` 只能包含不承载自然语言的锚点/分隔线，`provenance` 只能包含固定 `input`、`mode`、条件式 `source` 与可选 `sha256` 字段的 `ty-source-provenance` 注释；有文字的标题或自由说明字段可能表达权威含义，因此不能放进 background。任意背景说明文字和其他未分类文本都 fail closed。每次交付至少有一个标注 `aspect=architecture` 的 technical obligation Source Item，并映射到可独立证明的架构 obligation。若未知偏好会实质改变调研或选型，Preflight/Compile 成功前必须先询问；标准明确后，有依据的推荐才写入真实 Source，不能只藏在 YAML。方案委托不授权真实高危外部动作；输入冲突、用户保留、偏好缺失或无可靠推荐仍为 `decision_required`。旧 Source Plan 结构本身不构成阻塞。
+- Stop Hook 在结果 stale 时阻止完成。
 
-第一次正式 Compile 成功前，`delivery-contract.yaml` 是同一份非权威 Contract Draft。`long-task-workflow` 从入口开始，跨 Source 细化、仓库/Context 读取、映射和 Preflight 修复持续修改它，不要求一次响应生成完整 Contract。Source 完备性是 Preflight/Compile 的收敛条件，不是前置阶段。不存在单独 Contract Draft Skill、Draft Receipt 或 Authoring State。
+它的证明命题有明确前提：Source 在声明观察粒度下完整且准确，Source→Contract 投影保持语义，所有实际适用单元被展开，且具名项目 Oracle 与 verifier/runtime 可信边界语义正确；在这些前提下，只有 fresh `machine_accepted` 且没有任何待定 External Confirmation 的 `AcceptedDeliveryTerminal` 才严格推出完整声明可观察漂移为空。`machine_accepted_external_pending` 只能推出机器可验证范围内的声明漂移为空，完整交付仍是带限定的未完成状态，Harness 不完成原生 Goal。Harness 会机械强制并冻结其中许多前提，但无法发现未声明要求，也无法自动证明任意项目 Oracle 对现实语义忠实。
+
+原始/修订方案、选定设计资源和混合附件会立即进入一个 Source-bound Contract Draft 循环；完整 input inventory、稳定 Key、Product Control 级含义、选定资源设计事实、acceptance/risk、direct/derived/delegated/evidence-backed 溯源、Source 归属与 Contract 映射一起收敛。声明为 Source 的 Markdown 中，每一行非空文本都必须属于一个 Material `ty-source-item` 块、唯一且通过 schema 校验的 `design-resource-handoff-v1` formal block，或满足封闭语法的 background：`markdown-structure` 只能包含不承载自然语言的锚点/分隔线，`provenance` 只能包含固定 `input`、`mode`、条件式 `source` 与可选 `sha256` 字段的 `ty-source-provenance` 注释；有文字的标题或自由说明字段可能表达权威含义，因此不能放进 background。任意背景说明文字和其他未分类文本都 fail closed。每次交付至少有一个标注 `aspect=architecture` 的 technical obligation Source Item，并映射到可独立证明的架构 obligation。若未知偏好会实质改变调研或选型，Preflight/Compile 成功前必须先询问；标准明确后，有依据的推荐才写入真实 Source，不能只藏在 YAML。方案委托不授权真实高危外部动作；输入冲突、用户保留、偏好缺失或无可靠推荐仍为 `decision_required`。旧 Source Plan 结构本身不构成阻塞。
+
+第一次正式 Compile 成功前，`delivery-contract.yaml` 是同一份非权威 Contract Draft。`long-task-workflow` 从入口开始，跨 Source 细化、仓库/Context 读取、映射和 Preflight 修复持续修改它，不要求一次响应生成完整 Contract。Source 完备性是 Preflight/Compile 的收敛条件，不是前置阶段。不存在单独 Contract Draft Skill、Draft Receipt 或 Authoring State。
 
 第一次成功 Compile 创建 Authority Lock，并返回：
 
@@ -269,17 +297,17 @@ Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）
 
 锁定后的修订把“Authority 有变化”和“需要用户决策”分开：单调增强、锁定 Claims/targets/proof obligations 不变的 Source/Context snapshot 更新、Runner/input 实装修复、repo-bound scope 扩展、风险增强，以及 carrier、mutation、Check 相同且 Claim/预期失败断言覆盖不减少的等价 Counterfactual 覆盖可自动采用；产品/Source Claim/target/external-confirmation 变化，丢失 scenario/Claim/Evidence Capability/失败拦截，移除 forbidden/owner Context，runner type/effect、verifier kernel 或未知 reason 则只预览并等待精确 identity，风险降级直接拒绝。`diagnose-revision` 无副作用，撤回/替换候选只在同一 `delivery-contract.yaml` 合并，不产生询问。最终 pending brief 先解释 Authority Revision 是什么，再区分 `user_decision_reasons` 与机械边界变化。必须先展示 brief；若当前任务已有明确指令精确覆盖全部决策 reason，可机械转录而不二次询问，泛化“继续”、一揽子批准、建议或 Agent 推断不算。每次采用都保留 exact identity、旧 Authority 连续性、证据失效和完整 Final Gate，并返回滚动实现，绝不表示完成。
 
-Long-Task Skill 采用渐进读取：主 `SKILL.md` 只保留目标、硬边界和路由；Draft 输入/Contract Authoring、Evidence Design 与 Authority Lifecycle 细节按当前活动读取一层 reference，其中 Draft 输入与 Contract mapping 同时进行。这只是指令组织，不产生第二权威。共享 Architecture Deliberation 与适用质量路由在 Source-bound Draft authoring 中完成；material 且可独立证伪的架构/工程质量不变量使用已有 Source-backed obligations/constraints/forbidden shortcuts、owner/path/Binding、项目原生 executable Checks，以及功能行为可独立通过时的单独 Assertion。Final Gate 是唯一的 Long-Task Engineering Quality/Architecture Conformance 承载点，只证明该声明、项目检查绑定的集合。
+Long-Task Skill 采用渐进读取：主 `SKILL.md` 只保留目标、硬边界和路由；Draft 输入/Contract Authoring、Evidence Design 与 Authority Lifecycle 细节按当前活动读取一层 reference，其中 Draft 输入与 Contract mapping 同时进行。这只是指令组织，不产生第二权威。共享 Architecture Deliberation 与适用质量路由在 Source-bound Draft authoring 中完成；material 且可独立证伪的架构/工程质量不变量使用已有 Source-backed obligations/constraints/forbidden shortcuts、owner/path/Binding、项目原生 executable Checks，以及功能行为可独立通过时的单独 Assertion。Final Gate 是唯一的 Long-Task Engineering Quality/Architecture Conformance 承载点，只证明该声明、项目检查绑定的集合。
 
 Draft Outcome 只是 Authority Lock 前的 Outcome。Outcome 按可独立观察、判断、纵向闭环和定向验证的结果拆分，用于投影 acceptance/verification-ready 工作集、定位失败、恢复 finding 并精确失效旧局部结果。`depends_on` 只表示 acceptance 与中间证明 readiness，不授权或禁止实现编辑。每个 Outcome 属于一个有序 Stage；Stage gate 传递依赖同 Stage 其余 Outcome，后续 Stage 依赖前置 gate。Rolling Frontier 和 Stage 状态都由普通 Outcome Progress 临时派生，只是建议性验证/诊断投影。当前 Goal 可按代码现实跨 Outcome/Stage 实现、检查或返工，也可使用平台原生 opaque delegation；Harness 不创建 delegation scheduler、不把委派当证明，所有结果必须汇入选定验证 worktree。Outcome 不是 Worker、scheduler task、queue 或并行单元，Stage 也没有 Receipt 或第二个 Gate。Outcome 拆分诊断和证明归属，不拆分完成权威，因此最终仍必须在当前最终快照运行一次完整 Final Gate。
 
-Contract 声明一个有界 target profile、非空 required product target refs，以及每个 target 的 runtime family、root entrypoint 和显式 capabilities；required product target 必须声明对应 family、`cold-start` 与 `production-root` 能力。Web/process 代理不能代替单独要求的 Native/desktop 目标；browser 目标由 Playwright 证明，Native/desktop 目标由 project binary 证明。每个 `critical_user_path` Outcome 和 Stage gate 都必须从每个 required target 的 root 证明 `target_runtime`；多 Outcome Stage gate 还必须证明至少两个不同 surface 对应同一运行时状态。
+Contract 声明一个有界 target profile、非空 required product target refs，以及每个 target 的 runtime family、root entrypoint 和显式 capabilities；required product target 必须声明对应 family、`cold-start` 与 `production-root` 能力。Web/process 代理不能代替单独要求的 Native/desktop 目标；browser 目标由 Playwright 证明，Native/desktop 目标由 project binary 证明。每个 `critical_user_path` Outcome 和 Stage gate 都必须从每个 required target 的 root 证明 `target_runtime`；多 Outcome Stage gate 还必须证明至少两个不同 surface 对应同一运行时状态。
+
+如果一个声明结果可能在代理表面通过、却在目标运行时独立失败，最早拥有可运行边界的 Outcome 必须声明项目自有的真实运行 Check，并在当前 Check 执行中启动或触达目标、从同一会话产生结构化 Observation。仓库内状态报告、截图、二进制、日志或历史运行不能单独证明目标运行时。Check 显式声明带 Key 的 Given/When 场景与 journey role；global/Outcome applicability profile 绑定精确 target、journey、不可重复且每个维度只有一个值的原子 dimensions、Given condition/input/state refs 与有序 When refs。每个 Claim 列出全部适用 profile，每个 Claim-bearing Assertion 只证明一个 Claim 在一个完全匹配 profile 下的语义；每个实际 applicability × proof-surface 单元都必须可归因，不能由 risk-based、pairwise 或抽样替代。Assertion 声明 all-of Evidence Capability，并由类型化的当前执行记录证明。静态 `presence` 不能证明行为，降级路径不能替代要求的成功路径，固定输入不能证明输入变化，产生 side effect 的组件也不能自行证明其边界效果。每个行为型 Claim-bearing Assertion 还必须有同 Check、Claim-local 的 `replace_json_value` 或 `replace_text` Counterfactual：错误语义使它失败，同时列入 `preserved_assertions` 的无 Claim target-runtime liveness Assertion 必须继续通过；整文件替换不能证明语义绑定。Population 必须把真实 universe carrier 纳入 owning Check 快照，并证明 universe = eligible = observed + 合法 exclusions。Runner identity 会递归冻结受支持的 direct-literal 本地 verifier module/config/data graph：静态 import/export、literal dynamic import、`require` 形式和 literal `new URL(..., import.meta.url)` 文件；非 literal loader 与 `createRequire` 会 fail closed，package script 必须具有可恢复的静态 Node entry。候选/runtime 材料由 `input_paths`、`expected_output_paths` 或 `artifact_globs` 显式归类；其他间接 Oracle 访问必须进入 `verification_inputs`，否则属于具名可信边界。每个 Check 的 `input_paths`/Binding 应是最小可信失效范围，每个 Counterfactual carrier 都要能从声明的 target root 解释其路径。第一个有价值的可运行切片和合并后的相关变化只是默认建议反馈点；只有中间判断实际依赖某条 Progress 时才必须刷新。继续实现或进入 Final Gate 不要求先跑 targeted verify，因为 Final Gate 会忽略 Progress 并重跑全部 Check。`verify --explain` 可提前展示 Main/Counterfactual/重试次数，但不执行、不写 Progress，也不能看见 runner 内部构建。它不增加通用可达性断言、实现门禁、第二个执行型 diagnose 模式、调度器、逐平台 Progress 或逐编辑完整重建；运行时专属依赖探测、构建进度和进程清理由项目 runner 负责，Final Gate 仍是接受权所有者。
 
-如果一个声明结果可能在代理表面通过、却在目标运行时独立失败，最早拥有可运行边界的 Outcome 必须声明项目自有的真实运行 Check，并在当前 Check 执行中启动或触达目标、从同一会话产生结构化 Observation。仓库内状态报告、截图、二进制、日志或历史运行不能单独证明目标运行时。Check 显式声明带 Key 的 Given/When 场景与 journey role；global/Outcome applicability profile 绑定精确 target、journey、不可重复且每个维度只有一个值的原子 dimensions、Given condition/input/state refs 与有序 When refs。每个 Claim 列出全部适用 profile，每个 Claim-bearing Assertion 只证明一个 Claim 在一个完全匹配 profile 下的语义；每个实际 applicability × proof-surface 单元都必须可归因，不能由 risk-based、pairwise 或抽样替代。Assertion 声明 all-of Evidence Capability，并由类型化的当前执行记录证明。静态 `presence` 不能证明行为，降级路径不能替代要求的成功路径，固定输入不能证明输入变化，产生 side effect 的组件也不能自行证明其边界效果。每个行为型 Claim-bearing Assertion 还必须有同 Check、Claim-local 的 `replace_json_value` 或 `replace_text` Counterfactual：错误语义使它失败，同时列入 `preserved_assertions` 的无 Claim target-runtime liveness Assertion 必须继续通过；整文件替换不能证明语义绑定。Population 必须把真实 universe carrier 纳入 owning Check 快照，并证明 universe = eligible = observed + 合法 exclusions。Runner identity 会递归冻结受支持的 direct-literal 本地 verifier module/config/data graph：静态 import/export、literal dynamic import、`require` 形式和 literal `new URL(..., import.meta.url)` 文件；非 literal loader 与 `createRequire` 会 fail closed，package script 必须具有可恢复的静态 Node entry。候选/runtime 材料由 `input_paths`、`expected_output_paths` 或 `artifact_globs` 显式归类；其他间接 Oracle 访问必须进入 `verification_inputs`，否则属于具名可信边界。每个 Check 的 `input_paths`/Binding 应是最小可信失效范围，每个 Counterfactual carrier 都要能从声明的 target root 解释其路径。第一个有价值的可运行切片和合并后的相关变化只是默认建议反馈点；只有中间判断实际依赖某条 Progress 时才必须刷新。继续实现或进入 Final Gate 不要求先跑 targeted verify，因为 Final Gate 会忽略 Progress 并重跑全部 Check。`verify --explain` 可提前展示 Main/Counterfactual/重试次数，但不执行、不写 Progress，也不能看见 runner 内部构建。它不增加通用可达性断言、实现门禁、第二个执行型 diagnose 模式、调度器、逐平台 Progress 或逐编辑完整重建；运行时专属依赖探测、构建进度和进程清理由项目 runner 负责，Final Gate 仍是接受权所有者。
+长程任务工作流的“防劣化保障”同时保护当前因果链的真实性、跨版本的漂移拦截强度，以及相邻的 `F = 实现自由边界（Implementation Freedom Boundary）`。Context 对“当前实现”的描述必须与索引到的真实代码/运行逻辑一致；当前实现必须继续承担“需求/架构意义表达”和“fail-closed 识别、返工、最终快照复验”两项共同必要职责，并在明确的 Source 完整性、语义绑定、可观察性和可信边界下推出“不错误完成”的设计目的。`F` 是效率与反流程膨胀边界，不是第三项机制职责或无漂移定理前提：在 Source/Contract、架构、安全、禁止捷径、不可逆影响与外部动作边界内，实现顺序、方法、局部反馈节奏以及可选的单 agent/多 agent 或 subagent 实现由当前 Goal 决定；Harness 不建立开发阶段/方法 Gate、逐编辑强制验证、agent 调度/状态或委派证明。设计目的、关键逻辑、两项职责、成立边界和 `F` 都属于受保护设计不变量；弱化或替换它们必须由项目 owner 显式作出设计目的变更决策并给出替代证明，不能由 Agent 推断、文档/代码/测试同步改写或成本理由暗中授权。新增开发期限制还必须解决 Final Gate 或更轻项目检查无法覆盖的独立风险，并具有正净 ROI。该保障复用现有 Context、索引、测试、关键哨兵、路由和一致性门禁，不新增第二 Authority、Gate 或状态；它也不能补出未表达/不可观察的需求，或对拥有全部修改权限者的蓄意联合弱化提供绝对不可变保证。
 
-长程任务工作流的“防劣化保障”同时保护当前因果链的真实性、跨版本的漂移拦截强度，以及相邻的 `F = 实现自由边界（Implementation Freedom Boundary）`。Context 对“当前实现”的描述必须与索引到的真实代码/运行逻辑一致；当前实现必须继续承担“需求/架构意义表达”和“fail-closed 识别、返工、最终快照复验”两项共同必要职责，并在明确的 Source 完整性、语义绑定、可观察性和可信边界下推出“不错误完成”的设计目的。`F` 是效率与反流程膨胀边界，不是第三项机制职责或无漂移定理前提：在 Source/Contract、架构、安全、禁止捷径、不可逆影响与外部动作边界内，实现顺序、方法、局部反馈节奏以及可选的单 agent/多 agent 或 subagent 实现由当前 Goal 决定；Harness 不建立开发阶段/方法 Gate、逐编辑强制验证、agent 调度/状态或委派证明。设计目的、关键逻辑、两项职责、成立边界和 `F` 都属于受保护设计不变量；弱化或替换它们必须由项目 owner 显式作出设计目的变更决策并给出替代证明，不能由 Agent 推断、文档/代码/测试同步改写或成本理由暗中授权。新增开发期限制还必须解决 Final Gate 或更轻项目检查无法覆盖的独立风险，并具有正净 ROI。该保障复用现有 Context、索引、测试、关键哨兵、路由和一致性门禁，不新增第二 Authority、Gate 或状态；它也不能补出未表达/不可观察的需求，或对拥有全部修改权限者的蓄意联合弱化提供绝对不可变保证。
-
-工作流变更随后必须依次通过两道硬门槛。第一阶段先证明 `Coverage_new ⊇ Coverage_old`、`FalseNegative_new ⊆ FalseNegative_old`，并保持 Authority、fail-closed、完整/当前/最终候选快照证明均不可绕过；无法证明时必须保留当前正式验收路径，任何成本下降都不能补偿漂移识别能力下降。第二阶段才要求防劣化或设计目的达成的增量收益，大于 Authoring、Runtime、State、Recovery、维护、测试、流程、引入和迁移等全部增量成本。正净 ROI 只使候选进入考虑集，不代表自动采用。
+工作流变更随后必须依次通过两道硬门槛。第一阶段先证明 `Coverage_new ⊇ Coverage_old`、`FalseNegative_new ⊆ FalseNegative_old`，并保持 Authority、fail-closed、完整/当前/最终候选快照证明均不可绕过；无法证明时必须保留当前正式验收路径，任何成本下降都不能补偿漂移识别能力下降。第二阶段才要求防劣化或设计目的达成的增量收益，大于 Authoring、Runtime、State、Recovery、维护、测试、流程、引入和迁移等全部增量成本。正净 ROI 只使候选进入考虑集，不代表自动采用。
 
 只有 `weak_observability` 同时遇到多 Stage 或多个 required product runtime family 时，才额外要求一个只读 Global Product Conformance Check。它从 required root product target 启动，使用独立 Raw Execution，并在既有 Final Gate 内运行。单 Stage、单 family 继续使用原有 same-Check sensitivity，不支付额外 conformance 执行成本。
 
@@ -329,13 +357,13 @@ Contract 顶层包含：
 - `global`：非目标、owner boundary、技术约束、禁止路径/捷径和全局 Check；
 - `outcomes`：可独立判断并可定向验证的纵向结果、所属 Stage、依赖、明确 success/degradation 要求、REQ、产品/控件状态与位置、稳定技术义务和命名 AC。
 
-Runner 支持 `package_script`、`project_binary`、`node_oracle`、`playwright_test`；正式验收中的 package script 必须能恢复静态 Node entry 及其本地依赖闭包。Proof surface 支持 `ui_browser`、`runtime_behavior`、`api_contract`、`data_state`、`security_boundary`、`population_coverage`、`implementation_structure`。Execution target family 是有界的 `browser`、`native`、`desktop`、`service`、`process`、`external`，role 是 `product`、`support`、`observer`；required ref 只能指向具有 family/cold-start/production-root capabilities 的 product target。Browser target 只能由 `playwright_test` 证明，Native/desktop target 只能由 `project_binary` 证明。
+Runner 支持 `package_script`、`project_binary`、`node_oracle`、`playwright_test`；正式验收中的 package script 必须能恢复静态 Node entry 及其本地依赖闭包。Proof surface 支持 `ui_browser`、`runtime_behavior`、`api_contract`、`data_state`、`security_boundary`、`population_coverage`、`implementation_structure`。Execution target family 是有界的 `browser`、`native`、`desktop`、`service`、`process`、`external`，role 是 `product`、`support`、`observer`；required ref 只能指向具有 family/cold-start/production-root capabilities 的 product target。Browser target 只能由 `playwright_test` 证明，Native/desktop target 只能由 `project_binary` 证明。
 
 ### 一个 Contract 与 Source Claim
 
 用户选定的一次完整交付始终只有一个 Contract 和一个 Final Gate。Outcome 只按“可独立判断、可定向验证”的结果拆分；模型输出长度、YAML/文件长度、前后端层、模块数量、并行偏好或 Agent 容量都不是拆分依据。
 
-V2 强制至少一个真实 `source_path` 与一个 `source_claim`，且每个声明的 Source 文件至少包含一个 Material Item；每次交付还必须有一个 `aspect=architecture` 的 technical obligation Source Item。Authoring 阶段必须在原始 Markdown 中仅插入不渲染的 `ty-source-item:start/end` 标记，不得改写 Item 原文；其他每一行非空文本只能位于唯一且 schema-valid 的 handoff formal block，或内容符合 `markdown-structure`/`provenance` 封闭语法的 background 中。任意背景说明、未分类、嵌套、重叠、未闭合或空 section 均 fail closed。Marker key 与 Source Claim key 必须集合完全相等且全局唯一。Parser 能证明语法归属并阻断把任意材料性文字塞进 background，但不能证明用户已表达所有真实需求或 Source 对现实事实准确；后两者是显式上游前提。
+V2 强制至少一个真实 `source_path` 与一个 `source_claim`，且每个声明的 Source 文件至少包含一个 Material Item；每次交付还必须有一个 `aspect=architecture` 的 technical obligation Source Item。Authoring 阶段必须在原始 Markdown 中仅插入不渲染的 `ty-source-item:start/end` 标记，不得改写 Item 原文；其他每一行非空文本只能位于唯一且 schema-valid 的 handoff formal block，或内容符合 `markdown-structure`/`provenance` 封闭语法的 background 中。任意背景说明、未分类、嵌套、重叠、未闭合或空 section 均 fail closed。Marker key 与 Source Claim key 必须集合完全相等且全局唯一。Parser 能证明语法归属并阻断把任意材料性文字塞进 background，但不能证明用户已表达所有真实需求或 Source 对现实事实准确；后两者是显式上游前提。
 
 类型化 disposition 分开整体结果、Requirement/Control/Obligation/Non-completing Claim、单一命名 Acceptance Assertion、Global Constraint/Non-goal、Risk Fact/Affected Outcome、External Confirmation 与真实决策。Outcome Source Acceptance 必须原样对应一个 `<outcome>.<check>.<assertion>` criterion，并证明至少一个被独立 Source Item 支撑的非 Result Claim。`out_of_scope` 已退休：排除原本在范围内的要求只能进入 `decision_required`。
 
@@ -353,15 +381,15 @@ V2 强制至少一个真实 `source_path` 与一个 `source_claim`，且每个
 
 最终接受来自当前可执行证据，不来自 Agent 文本。Evidence Adapter 由 Runner 派生：只有 `playwright_test → playwright_json_v1` 可以证明 `ui_browser`，其余 Runner 使用 `structured_json_v2` Adapter 证明非浏览器 Surface，并在需要 capability record 时输出增量 `long-task-check-result-v3` payload。V2 payload 只保留解码兼容，不能满足非 `presence` 能力。
 
-每个 Check 声明非空、带 Key 的 `scenario.given`/`scenario.when`，并使用 `success`、`degradation`、`recovery`、`stage_gate`、`conformance` journey role。Global/Outcome applicability profile 绑定精确 target、journey、原子 dimensions、Given condition/input/state refs 和有序 When refs；每个 Claim-bearing Assertion 只证明一个 Claim 在一个匹配 profile 下的语义，全部实际适用 proof-surface 单元都必须覆盖。每个 Assertion 声明 `presence`、`interaction_trace`、`state_delta`、`cross_surface_consistency`、`durable_readback`、`boundary_invocation`、`external_side_effect`、`failure_injection`、`visual_render`、`design_conformance`、`design_method`、`target_runtime`、`input_variation` 中所需的 all-of 集合。除了静态 `presence`，每种能力恰好需要一条绑定该 Assertion 的当前执行记录；缺失、重复、未知或未声明记录全部 fail closed。Result 只能由 success Check 证明；success 与 degradation 不能共用一个 Check；外部边界从 observer target 观察；input variation 至少证明两个不同输入、两个输出 hash 和一个失败样例。
+每个 Check 声明非空、带 Key 的 `scenario.given`/`scenario.when`，并使用 `success`、`degradation`、`recovery`、`stage_gate`、`conformance` journey role。Global/Outcome applicability profile 绑定精确 target、journey、原子 dimensions、Given condition/input/state refs 和有序 When refs；每个 Claim-bearing Assertion 只证明一个 Claim 在一个匹配 profile 下的语义，全部实际适用 proof-surface 单元都必须覆盖。每个 Assertion 声明 `presence`、`interaction_trace`、`state_delta`、`cross_surface_consistency`、`durable_readback`、`boundary_invocation`、`external_side_effect`、`failure_injection`、`visual_render`、`design_conformance`、`design_method`、`target_runtime`、`input_variation` 中所需的 all-of 集合。除了静态 `presence`，每种能力恰好需要一条绑定该 Assertion 的当前执行记录；缺失、重复、未知或未声明记录全部 fail closed。Result 只能由 success Check 证明；success 与 degradation 不能共用一个 Check；外部边界从 observer target 观察；input variation 至少证明两个不同输入、两个输出 hash 和一个失败样例。
 
-每个 Outcome 至少有一个非 Result 原子 Claim，且 `required_proof_surfaces` 必须 all-of 全覆盖。Claim-bearing Assertion 使用显式 Expected 比较；`truthy/falsy` 禁止，`exists` 仅允许证明 `implementation_structure` Obligation。每个行为型 Claim-bearing Assertion 还必须用 same-Check、Claim-local 的 `replace_json_value` 或 `replace_text` 替换错误语义，并要求无 Claim 的 target-runtime liveness Assertion 在 `preserved_assertions` 中继续通过；`replace_file` 仅保留兼容性，不能证明语义绑定。Population 必须通过真实 universe Binding 证明全集，但不能豁免这条语义 witness。
+每个 Outcome 至少有一个非 Result 原子 Claim，且 `required_proof_surfaces` 必须 all-of 全覆盖。Claim-bearing Assertion 使用显式 Expected 比较；`truthy/falsy` 禁止，`exists` 仅允许证明 `implementation_structure` Obligation。每个行为型 Claim-bearing Assertion 还必须用 same-Check、Claim-local 的 `replace_json_value` 或 `replace_text` 替换错误语义，并要求无 Claim 的 target-runtime liveness Assertion 在 `preserved_assertions` 中继续通过；`replace_file` 仅保留兼容性，不能证明语义绑定。Population 必须通过真实 universe Binding 证明全集，但不能豁免这条语义 witness。
 
-Targeted verify、Progress、status、Receipt 与 compiled cache 都不是完成权威。Final Gate 要求 clean candidate commit，先拒绝已经 stale 的 accepted authority inputs，再从 Source 重新 Compile，在同一 Git-tree snapshot 上运行全部 Global/Outcome Check；执行前后都重新编译并核对 Contract/fragments、Source、完整 Controlling Context、verifier/runner、受支持 direct-literal 本地 verifier graph、verification inputs 与 workdir inputs 的完整受保护身份，同时复核 active identity。只有全部不变时它才可以生成 `machine_accepted` 或 `machine_accepted_external_pending`；后者仍必须明确列出外部确认项，并且不属于完整交付无漂移定理的前件。
+Targeted verify、Progress、status、Receipt 与 compiled cache 都不是完成权威。Final Gate 要求 clean candidate commit，先拒绝已经 stale 的 accepted authority inputs，再从 Source 重新 Compile，在同一 Git-tree snapshot 上运行全部 Global/Outcome Check；执行前后都重新编译并核对 Contract/fragments、Source、完整 Controlling Context、verifier/runner、受支持 direct-literal 本地 verifier graph、verification inputs 与 workdir inputs 的完整受保护身份，同时复核 active identity。只有全部不变时它才可以生成 `machine_accepted` 或 `machine_accepted_external_pending`；后者仍必须明确列出外部确认项，并且不属于完整交付无漂移定理的前件。
 
 ## 兼容与迁移
 
-当前 V2 的语义保证闭包还要求 full Context、architecture-classified Source obligation、原子 applicability dimensions、显式 target capabilities、带 applicability 的 Control-relation closure、Population universe carrier、Claim-local 语义 mutation、逐 method/condition 的 method-record/primary-observation artifacts、blocker-required capabilities 与受支持 direct-literal verifier dependency closure。缺少这些含义的旧 V2 Contract 会报告可索引的人工迁移 `long-task-v2-semantic-drift-authority`；必须依据 Source 重新表达。Upgrade 不会猜测这些含义，也不会把旧 Progress/Receipt 当作通过证据。
+当前 V2 的语义保证闭包还要求 full Context、architecture-classified Source obligation、原子 applicability dimensions、显式 target capabilities、带 applicability 的 Control-relation closure、Population universe carrier、Claim-local 语义 mutation、逐 method/condition 的 method-record/primary-observation artifacts、blocker-required capabilities 与受支持 direct-literal verifier dependency closure。缺少这些含义的旧 V2 Contract 会报告可索引的人工迁移 `long-task-v2-semantic-drift-authority`；必须依据 Source 重新表达。Upgrade 不会猜测这些含义，也不会把旧 Progress/Receipt 当作通过证据。
 
 ## 开发与验证
 
@@ -384,7 +412,7 @@ make validate-harness
 
 `test:affected` 用于日常修改和修复循环；本地推断只会报告并略过未跟踪的 `.work_products/**`，tracked 与显式路径仍按 fail-safe 路由。`test:long-task:trust` 是冻结候选版本后的高风险边界门，也是 PR CI 使用的层级；经审阅的 Trust/focused/hotspot 预算防止反馈层静默膨胀，但完整套件发现不设裁剪上限。`npm test` 是 `main` 和发布保留的完整发布回归，不应在每次小修复后重跑。受控 Ubuntu CI 使用有充分余量的分层灾难性耗时上限，本地耗时仍只做诊断。Delivery Contract 和完整 Long-Task 门仍可通过 package workspace scripts 显式执行。
 
-模块化门禁是 capability-aware 的 `ty-context check-modularity`；例外必须包含 `owner`、`introduced_at`、`reason`、`tracking_issue` 和 `expiry_condition`，不支持指标不会以零值制造通过假象。
+模块化门禁是 capability-aware 的 `ty-context check-modularity`；例外必须包含 `owner`、`introduced_at`、`reason`、`tracking_issue` 和 `expiry_condition`，不支持指标不会以零值制造通过假象。
 
 ## 诚实限制