project-tiny-context-harness 0.8.1 → 0.8.3

package/assets/README.zh-CN.md

@@ -127,17 +127,17 @@ material UI 在实现前执行 **UI Authority Closure**：每个稳定 surface/c
 
 两种开发路径共享一个条件式设计目的：当存在已选 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 的文本副本。它逐一闭合每个适用的 subject × selected target × declared condition × UI/UX dimension 单元格，覆盖 surface/flow、visual/content、component/control、state/interaction、motion、adaptation/input、accessibility、assets 八个维度，并记录明确排除/不适用/未决含义、Source Item、verification method 与 blocker。preflight 会把每个 typed HTML/Markdown/JSON/CSS locator 对着其声明的不可变资源真实解析，校验 source/dependency closure，并拒绝不可解析或 media 不兼容的证据；探索候选仍不需要 schema。
+provider-neutral handoff 是残余语义与索引层，不是 CSS 的文本副本。它默认按完整可观察设计事实（complete observable design fact）而不是 Product Control 粒度工作：只要已取得资源和声明的 inspector/oracle 能表达，图片、文字、图标、组件内部片段、更小视觉 primitive、geometry、layout、style/token、content、state、interaction 等事实都要原子索引。每个资源必须闭合为“material 且列出精确 facts”或“确实 supporting-only”，每个适用的 subject × selected target × declared condition × UI/UX dimension 单元格则必须无损守恒其精确 fact/evidence/Source/method 集合，覆盖 surface/flow、visual/content、component/control、state/interaction、motion、adaptation/input、accessibility、assets 八个维度。`exact_target` 的每个 condition 还必须有 full-target layout 与 pixel 事实；做不到就只能保持 partial constraint 或阻断。preflight 会解析 typed locator、校验 source/dependency/fact closure，并拒绝不可解析、unsupported 或 media 不兼容的证据；探索候选仍不需要 schema。
 
-这些输入仍是普通 Source。默认 Workflow 对 covered Source Items、declared verification methods、blockers、targets 和 conditions 保持精确但 task-local 的 accounting；每一项都必须到达生产 owner、冷启动旅程和已经执行的 final-candidate check，并能在失败时明确归因。任何 unresolved、unmapped、unexecuted、stale 或无法区分的项都会阻止“完整遵循”声明并作为 gap 报告。Long-Task 把同一组含义投影进已有 Claims、method Assertions、`surface_bindings`、typed evidence 和 Final Gate。两种证明载体互斥：active Long-Task 不再执行默认 closure。生成成功、截图、hash 与 preflight 只证明输入完整性或资源完整性。
+这些输入仍是普通 Source。默认 Workflow 对 fact/Source/method/blocker/target/condition 精确集合保持 task-local accounting；每一项都必须到达生产 owner、冷启动旅程和已经执行的 final-candidate check，并能在失败时明确归因。任何 unread、unsupported、unresolved、unmapped、unimplemented、unexecuted、stale 或无法区分的适用事实都会阻止“完整遵循”声明并作为 gap 报告。Long-Task 把同一组含义投影进已有 Claims、method Assertions、`surface_bindings`、fact-bound typed evidence 和 Final Gate。两种证明载体互斥：active Long-Task 不再执行默认 closure。生成成功、截图、hash 与 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、未闭合的适用单元格、不成立的证据类型或未决语义都会 fail closed。preflight 只证明设计输入语义完整且资源身份正确；开发流程仍必须打开真实资源，并从生产入口证明当前实现。
+只要是已经选定、准备进入实现的设计资源，两种开发路径都会先运行 `ty-context design-resource preflight <handoff.md>`。取得不完整、缺少或多出未声明依赖、不安全路径、过期 digest、虚构 locator、缺失/未引用 fact、伪造 resource-fact closure、未闭合的适用单元格、exact target 缺少 layout/pixel 事实、不成立的证据类型或未决语义都会 fail closed。preflight 只证明设计输入语义完整且资源身份正确；开发流程仍必须打开真实资源，并从生产入口证明当前实现。
 
-对 material 工作，`context_uiux_design` 应用上面的投影规则并让风险比例化 coverage reasoning 保持 task-local。`context_development_engineer` 用稳定 surface/control key 把每个选定 target/condition 及 handoff 精确集合追踪到生产 route/component owner、冷启动真实用户旅程及可独立归因的渲染/交互检查，并在首个可运行纵向切片完成时先从真实入口检查，再扩展其余 UI。只报告真正检查过的组合；资源哈希、manifest 和数量只证明资源完整性，实现截图既不能成为自己的目标，也不能单独证明实现一致性。
+对 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 权威，并把每个 applicable Control 的 surface、region/location、type/label、user task、visibility/availability、trigger/input/validation/default、interaction/navigation、loading/empty/success/failure/recovery/permission/feedback/accessibility 完整投影为独立 Source-backed Control Claim 和受保护产品语义；空字段不生成 Claim。聚合的 Product `surface_bindings` 把每个 Control 连接到 owner surface、required product target、既有 Technical route/component Bindings 和 root-entry 成功旅程。选定 exact/constraint target 用 typed `design_conformance` 把冻结输入和声明条件绑定到当前 actual/comparison artifacts；`verification_method_bindings` 让每个 handoff method 都能独立失败，每个已声明 blocker 则保留精确 Source-item/method lineage，并落到目标本地机器证明或会阻断目标的 External Confirmation。它们不能在 Contract 内自行豁免，缩减范围必须修订 Source/Contract 权威。现有 Claim、Assertion、Check、Stage、Binding、revision 与 Final Gate 是唯一 Long-Task 生命周期和 closure。
+显式 Long-Task 是同一共享义务的强机器载体。它在 Compile 前解决缺失/冲突的 UI 权威，并用 `field_coverage` 闭合每个真实 Control 的全部 22 个 canonical 字段：每个字段只能是具有具体语义的 `specified`、带明确理由的 `not_applicable` 或会阻断的 `unresolved`；省略绝不等于不适用。specified/not-applicable 项会在每个声明的 applicability profile 下生成独立受保护 Control Claim；即使关系不适用，`control_relation_closure` 也会成为带精确 applicability 的负向 Claim。`control_relation_closure` 与 `control_relations` 同时闭合跨 Control/系统的共享状态、依赖/顺序、导航、权限、校验、反馈和恢复链。聚合的 Product `surface_bindings` 把每个 Control 连接到 owner surface、required product target、既有 Technical route/component Bindings 和 root-entry 成功旅程。选定 exact/constraint target 用 typed `design_conformance` 把冻结输入和声明条件绑定到当前 actual/comparison artifacts；每个 `verification_method_binding` 都有独立 `design_method` 记录，并在每个精确 condition 下声明精确 handoff `fact_refs`、method record 与 method-native primary observation，其当前路径和 digest 均不得被另一单元复用。所有 cell 的 fact 并集必须等于 target 完整事实集，runtime evidence 也必须逐格重复同一组 refs。Playwright 的每个 project instance 必须显式附带两类 artifact。每个 blocker 保留精确 Source-item/method/required-capability lineage，只能由 capability 完整的精确目标上的机器 Claim 闭合，否则保留为阻断目标的 External Confirmation。它们不能在 Contract 内自行豁免，缩减范围必须修订 Source/Contract 权威。现有 Claim、Assertion、Check、Stage、Binding、revision 与 Final Gate 是唯一 Long-Task 生命周期和 closure。
 
 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、必需设计目录、逐控件截图矩阵或通用像素阈值。
 
@@ -171,24 +171,26 @@ Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）
 
 ### 退役 Source Plan 兼容入口
 
-`/source-plan-authoring` 仅作为 long-task profile 的兼容指引保留。`/long-task-workflow` 从入口立即打开非权威 Contract Draft，并让完整 input inventory、混合输入综合/细化、稳定 Key、控件级语义、偏好/调研/委托溯源、Source marker/provenance、acceptance/risk 与 Contract 映射在同一循环中收敛。已有 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 时才使用。它固定为：
 
 - 一个平台原生、持续的 Goal；
-- 一个用户选定的仓库/worktree；
+- 一个用户选定的仓库与最终验证/收敛 worktree；
 - 一次完整选定交付、一个 Contract、一个 Final Gate；
-- Outcome 依赖只表示验收就绪关系，不表示 Worker 调度；
+- Outcome 依赖只表示验收与中间证明就绪关系，不限制实现顺序，也不表示 Worker 调度；
 - 第一次 Authority Lock 后、正式实现前有一次用户模型选择；
-- 当前 Goal 内部滚动展开实现 Frontier；
-- targeted verify 只用于修复，永远不能 accepted；
+- 当前 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-bound Contract Draft 循环；完整 input inventory、稳定 Key、控件级含义、acceptance/risk、direct/derived/delegated/evidence-backed 溯源、Source marker 与 Contract 映射一起收敛。若未知偏好会实质改变调研或选型，Preflight/Compile 成功前必须先询问；标准明确后，有依据的推荐才写入真实 Source，不能只藏在 YAML。方案委托不授权真实高危外部动作；输入冲突、用户保留、偏好缺失或无可靠推荐仍为 `decision_required`。旧 Source Plan 结构不构成阻塞，但激活前必须完成 Material Source Item 标记。
+它的证明命题有明确前提：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。
 
@@ -213,11 +215,15 @@ Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）
 
 Long-Task Skill 采用渐进读取：主 `SKILL.md` 只保留目标、硬边界和路由；Draft 输入/Contract Authoring、Evidence Design 与 Authority Lifecycle 细节按当前活动读取一层 reference，其中 Draft 输入与 Contract mapping 同时进行。这只是指令组织，不产生第二权威。共享 Architecture Deliberation 在 Source-bound Draft authoring 中完成；material 架构不变量使用已有 obligations/constraints/forbidden shortcuts、owner/path/Binding 和项目原生 executable Checks，Final Gate 是唯一的 Long-Task Architecture Conformance 承载点。
 
-Draft Outcome 只是 Authority Lock 前的 Outcome。Outcome 按可独立观察、判断、纵向闭环和定向验证的结果拆分，使当前 Goal 能缩小 dependency-ready 工作集、定向验证、定位失败、恢复 finding 并精确失效旧局部结果。`depends_on` 只表示 acceptance readiness。每个 Outcome 属于一个有序 Stage；Stage gate 传递依赖同 Stage 其余 Outcome，后续 Stage 依赖前置 gate。Rolling Frontier 和 Stage 状态都由普通 Outcome Progress 临时派生；Outcome 不是 Worker、scheduler task、queue 或并行单元，Stage 也没有 Receipt 或第二个 Gate。Outcome 拆分执行和诊断，不拆分完成权威，因此最终仍必须在当前最终快照运行一次完整 Final Gate。
+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 对应同一运行时状态。
+
+如果一个声明结果可能在代理表面通过、却在目标运行时独立失败，最早拥有可运行边界的 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 仍是接受权所有者。
 
-Contract 声明一个有界 target profile、非空 required product target refs，以及每个 target 的 runtime family/root entrypoint。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 对应同一运行时状态。
+长程任务工作流的“防劣化保障”同时保护当前因果链的真实性、跨版本的漂移拦截强度，以及相邻的 `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 或状态；它也不能补出未表达/不可观察的需求，或对拥有全部修改权限者的蓄意联合弱化提供绝对不可变保证。
 
-如果一个声明结果可能在代理表面通过、却在目标运行时独立失败，最早拥有可运行边界的 Outcome 必须声明项目自有的真实运行 Check，并在当前 Check 执行中启动或触达目标、从同一会话产生结构化 Observation。仓库内状态报告、截图、二进制、日志或历史运行不能单独证明目标运行时。Check 显式声明带 Key 的 Given/When 场景与 journey role；Assertion 声明 all-of Evidence Capability，并由类型化的当前执行记录证明。静态 `presence` 不能证明行为，降级路径不能替代要求的成功路径，固定输入不能证明输入变化，产生 side effect 的组件也不能自行证明其边界效果。每个 Check 的 `input_paths`/Binding 应是最小可信失效范围，每个 Counterfactual carrier 都要能从声明的 target root 解释其路径。当前 Goal 在第一个可运行切片后执行一次；后续相关修改先合并，`progress_stale` 只表示证据已旧，并在依赖该结果或进入 Final Gate 前刷新。`verify --explain` 可提前展示 Main/Counterfactual/重试次数，但不执行、不写 Progress，也不能看见 runner 内部构建。它不增加通用可达性断言、第二个执行型 diagnose 模式、调度器、逐平台 Progress 或逐编辑完整重建；运行时专属依赖探测、构建进度和进程清理由项目 runner 负责，Final Gate 仍是接受权所有者。
+工作流变更随后必须依次通过两道硬门槛。第一阶段先证明 `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 执行成本。
 
@@ -244,14 +250,14 @@ ty-context long-task abandon <workdir> [--force-corrupt-state]
 ```
 
 - `init` 创建单文件 inline Outcome 的 Compact Contract 模板。
-- `preflight` 应用 Compact 默认值并一次输出 Source/REQ/CTRL/OBL/AC、Stage closure、required-target/root/runner、scenario/journey、capability、external impact、Product Conformance、Context、风险、路径/Binding、Runner/Input、Proof 与 workspace-scope 诊断。首次 Authority Lock 前，它把每个 HEAD-relative 当前变化路径分类为 protected、expected change、allowed support、forbidden 或 unclassified；后两类中的 forbidden/unclassified 都阻塞。它完全只读，不创建 Authority Lock、marker、cache、progress、Receipt、pending revision、状态锁，也不运行项目 Check。
-- `compile` 重复同一 fail-closed workspace 分类，因此直接 Compile 不能绕过 Preflight，再生成 Global 与 Outcome Result/Requirement/Control-field/Non-completing/Technical Claim，拒绝未覆盖 Claim，并让第一次正式成功 Compile 成为 Authority Lock。首次 enable 仅保护配置的 managed destination 中当前 package asset tree 实际存在的精确文件，以及精确的 config/hook 文件；managed 目录根和宽泛 `.codex/**` 均不豁免。每次结果都包含 lifecycle event、`delivery_completed_by_this_event: false`、`native_goal_effect: none` 和 next action。第一次结果附带 `execution_model_checkpoint.required: true` 及 terminal-turn/explicit-choice 契约，后续 Compile 返回 `false`；这些字段不进入 Authority state。
+- `preflight` 应用 Compact 默认值并一次输出 Source 非空文本归属、REQ、CTRL 字段/关系闭包、OBL/AC、applicability、Stage closure、required-target/root/runner、scenario/journey、capability、external impact、Product Conformance、Context、风险、路径/Binding、Runner/Input、语义 witness/liveness、Proof 与 workspace-scope 诊断。首次 Authority Lock 前，它把每个 HEAD-relative 当前变化路径分类为 protected、expected change、allowed support、forbidden 或 unclassified；后两类中的 forbidden/unclassified 都阻塞。它完全只读，不创建 Authority Lock、marker、cache、progress、Receipt、pending revision、状态锁，也不运行项目 Check。
+- `compile` 重复同一 fail-closed workspace 分类和 activation validator，因此直接 Compile 不能绕过 Preflight，再按精确 applicability 生成 Global 与 Outcome Result/Requirement/Control-field/Control-relation/Non-completing/Technical Claim，拒绝未覆盖单元，并让第一次正式成功 Compile 成为 Authority Lock。首次 enable 仅保护配置的 managed destination 中当前 package asset tree 实际存在的精确文件，以及精确的 config/hook 文件；managed 目录根和宽泛 `.codex/**` 均不豁免。每次结果都包含 lifecycle event、`delivery_completed_by_this_event: false`、`native_goal_effect: none` 和 next action。第一次结果附带 `execution_model_checkpoint.required: true` 及 terminal-turn/explicit-choice 契约，后续 Compile 返回 `false`；这些字段不进入 Authority state。
 - `diagnose-revision` 只做无副作用候选 Compile；仅 scope-only 候选能运行 Active Authority 已有且未更换的 Check，输出固定为非验收、非 Progress、非 pending。
 - `compile --revise` 自动采用单调或机械边界内的修订；需要用户决策时返回 `authority_revision_pending`、精确 id、确定性 material 摘要、`user_decision_reasons` 和自包含 `decision_brief`。先展示 brief；只有已明确且精确覆盖全部 reason 的当前任务指令可直接承载该 id。候选再变会生成新 id 并使旧批准失效。采用后证据失效、输出 `authority_revision_adopted` 并回到滚动执行，不表示交付完成。
-- `verify` 在重查 active task/revision/compiled/worktree identity 并依据 immutable baseline 应用同一 workspace 分类后写 scoped Progress；targeted verify 始终只是修复证据。`verify --explain` 只读地合并 Main Raw Execution、列出适用 Counterfactual 调用与声明的重试次数上界，不执行命令、不写 Progress，也不预测耗时或 runner 内部子进程。
-- `status` 输出 `unverified`、`progress_passing`、`progress_failing`、`progress_stale` 或 `blocked_external`，由当前 Progress 派生 `stages`、`ready_stages` 和受 Stage 约束的 Outcome frontier，不持久化 Stage 完成。它同时报告 fresh `final_workflow_status`、target profile/state、完整 `external_confirmations` 与唯一的 `pending_authority_revision`。`progress_passing` 只能表述为定向修复证据，不能简称“Outcome 完成”；`progress_stale` 是证据新鲜度事实，不是当前通过或每次编辑后立即重跑的指令；`final_workflow_status: null` 表示 Goal 尚未完成。
-- `resume` 完全只读，恢复 task/contract identity、风险、相关 Context、Git 状态、相同的 Final/target/Stage/external/pending surface、ready Outcome、findings 和 next safe action。
-- `final-gate` 在完整 Check 后再次验证 active identity；并发 revision 不能产生 accepted。Receipt 把每个 Stage 派生为 `passed`、`failed`、`blocked_external` 或 `blocked_dependency`，把 `target_state` 派生为 `not_accepted`、`blocked_external` 或 Contract 精确声明的 `implementation_complete`、`target_profile_usable`、`production_release_ready`。
+- `verify` 在重查 active task/revision/compiled/worktree identity 并依据 immutable baseline 应用同一 workspace 分类后写 scoped Progress；targeted verify 始终只是可选反馈/修复证据。`verify --explain` 只读地合并 Main Raw Execution、列出适用 Counterfactual 调用与声明的重试次数上界，不执行命令、不写 Progress，也不预测耗时或 runner 内部子进程。
+- `status` 输出 `unverified`、`progress_passing`、`progress_failing`、`progress_stale` 或 `blocked_external`，由当前 Progress 派生 `stages`、`ready_stages` 和建议性的验收/验证 Outcome frontier，不持久化 Stage 完成。兼容字段 `ready_for_implementation` 只是该投影的别名，不是实现门禁。它同时报告 fresh `final_workflow_status`、target profile/state、完整 `external_confirmations` 与唯一的 `pending_authority_revision`。`progress_passing` 只能表述为定向修复证据，不能简称“Outcome 完成”；`progress_stale` 是证据新鲜度事实，不是当前通过或每次编辑后立即重跑的指令；`final_workflow_status: null` 表示 Goal 尚未完成。
+- `resume` 完全只读，恢复 task/contract identity、风险、相关 Context、Git 状态、相同的 Final/target/Stage/external/pending surface、ready Outcome、findings 和建议性的验证/修复 next action；该建议不限制实现顺序。
+- `final-gate` 在执行前重新编译 Source Authority，并捕获 Contract/fragments、Source、Controlling Context、verifier/runner、verification inputs 和 workdir inputs 的语义与原始受保护身份；完成全部 Check 后，再次编译并哈希同一完整集合。任一输入竞争变化都会 fail closed，并发 revision 也不能产生 accepted。Receipt 把每个 Stage 派生为 `passed`、`failed`、`blocked_external` 或 `blocked_dependency`，把 `target_state` 派生为 `not_accepted`、`blocked_external` 或 Contract 精确声明的 `implementation_complete`、`target_profile_usable`、`production_release_ready`。
 - `stop-check` 与 `close` 自己运行 Live Final Gate，并只用 accepted identity 做 CAS clear。每次机器接受的 Stop 都给一个非阻塞 terminal-scope `systemMessage`；外部待确认时同时列出全部确认项。Final/Stop/close 输出 `acceptance_scope: declared_machine_authority` 与 `native_goal_effect: none`，close 另输出 `closed_scope: machine_authority`。`status: closed` 只表示机器 Authority 已清理，不表示原生 Goal 或完整外部交付完成。
 - `abandon --force-corrupt-state` 仅用于损坏/mismatch/legacy-unrecoverable 状态或遗留锁，只删除确定性 active state 与 `<workdir>/.ty-context/**`。
 
@@ -267,13 +273,13 @@ Contract 顶层包含：
 - `global`：非目标、owner boundary、技术约束、禁止路径/捷径和全局 Check；
 - `outcomes`：可独立判断并可定向验证的纵向结果、所属 Stage、依赖、明确 success/degradation 要求、REQ、产品/控件状态与位置、稳定技术义务和命名 AC。
 
-Runner 支持 `package_script`、`project_binary`、`node_oracle`、`playwright_test`。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 只能指向 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。Authoring 阶段必须在原始 Markdown 中仅插入不渲染的 `ty-source-item:start/end` 标记，不得改写 Item 原文。Marker key 与 Source Claim key 必须集合完全相等且全局唯一。
+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`。
 
@@ -291,15 +297,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。每个 Assertion 声明 `presence`、`interaction_trace`、`state_delta`、`cross_surface_consistency`、`durable_readback`、`boundary_invocation`、`external_side_effect`、`failure_injection`、`visual_render`、`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。
+每个 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，从 Source 重新 Compile，在同一 Git-tree snapshot 上运行全部 Global/Outcome Check，并在结束时再次校验 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`；后者仍必须明确列出外部确认项，并且不属于完整交付无漂移定理的前件。
 
 ## 兼容与迁移
 
-0.7.2 在同一个 `long-task-delivery-v2` 权威中增加 ordered Stage、required target/root entrypoint、显式 success/degradation journey 与 scenario、类型化 Evidence Capability、类型化 external impact、按风险触发的 Product Conformance，以及 terminal target/Stage projection。缺少这些字段的旧 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 当作通过证据。
 
 ## 开发与验证
 
@@ -330,7 +336,7 @@ make validate-harness
 - 它不能证明用户从未遗漏未声明需求。
 - bounded Context keyword search 仍可能漏掉同义词或间接依赖，只能补充语义判断。
 - Harness 不能切换 host 选择的模型，只能在第一次 Authority Lock 后要求一次用户选择。
-- 核心长程执行不提供并行 mutation runtime。
+- Tiny Context 不提供并行 mutation/delegation runtime；平台 Goal 可使用自身 opaque implementation delegation，但 Harness 不持久化它，也不把它当证据。
 - 它不观测平台 token 或模型调用数。
 - Network policy 会约束传给 runner 的代理环境，但不是操作系统 sandbox。
 - 同用户/管理员文件篡改、系统级 Hook 绕过不在安全边界内。

package/assets/agents/AGENTS_CORE.md

@@ -23,11 +23,11 @@ The default workflow never requires a plan artifact, matrix, verdict, evidence l
 
 ## Selected-Design Conformance Obligation
 
-This shared obligation activates only for a selected implementation handoff. Run `ty-context design-resource preflight <handoff.md>` before UI Authority Closure. A Web/App target needs one completely acquired machine-readable canonical entry and its exact dependency closure; unresolved locators/cells/meaning, unsupported evidence or stale digests fail closed. Preflight and hashes prove input completeness/integrity, never production conformance.
+This shared obligation activates only for a selected implementation handoff. Run `ty-context design-resource preflight <handoff.md>` before UI Authority Closure. A Web/App target needs one completely acquired machine-readable canonical entry and its exact dependency closure. The handoff must inventory every in-scope observable fact exposed by the acquired resources and declared inspector/oracle capability, close every resource as material-with-facts or honestly supporting-only, and bind every coverage row to the exact fact/evidence/Source/method sets. Product Control granularity is not the design-fact ceiling. An exact target additionally needs full-target layout and pixel facts for every condition; partial input remains a constraint or blocking unresolved. Unresolved locators/cells/facts/meaning, unsupported evidence or stale digests fail closed. Preflight and hashes prove input completeness/integrity, never production conformance.
 
 Every adopted target has exactly one canonical record: `DESIGN.md` for project/system/component-family scope or the owning Screen Contract for one-screen/interaction scope. That record owns interpretation, selection basis, immutable locator/digest, condition coverage and editable-upstream update route; other layers keep only the stable key, owner/anchor and local applicability. Use the on-demand UIUX Skill for deterministic Design Source Projection. Never overwrite an adopted baseline; update upstream, approve a new immutable version and update the canonical record.
 
-Default work keeps one ephemeral exact accounting of covered Source Items, declared verification methods, blockers, targets and conditions. Route every applicable item to the production owner, cold-start journey and an executed final-candidate project check whose failure remains attributable; one check may cover several methods only when each method/fact can fail distinctly. A selected-target, implementation or declared check-input change stales closure. Any unresolved, unmapped, unexecuted, stale or indistinguishable item blocks a complete-conformance claim and must be reported as a gap. This creates no file, matrix, Claim set, state or Gate.
+Default work keeps one ephemeral exact accounting of covered facts, Source Items, declared verification methods, blockers, targets and conditions. Route every applicable item to the production owner, cold-start journey and an executed final-candidate project check whose failure remains attributable; one check may cover several methods only when each method/fact can fail distinctly. A selected-target, fact inventory, implementation or declared check-input change stales closure. Any unresolved, unmapped, unexecuted, stale or indistinguishable item blocks a complete-conformance claim and must be reported as a gap; this explicitly includes every unread, unsupported or unimplemented applicable design fact. This creates no file, matrix, Claim set, state or Gate.
 
 Externally authored resources remain ordinary Source and exploration remains schema-free. `design-system-authoring` is explicit-only; `design-resource-authoring` keeps the requested scope ceiling and may reconcile final accepted decisions into the initial proposal once, but neither authoring path changes Context/code/Contract or claims acceptance. An active Long-Task projects this same obligation into its existing Claims, Assertions, bindings and Final Gate and never also runs the default closure. For every external product, architecture, technical or acceptance constraint, internally classify it as covered by Context, requiring a Context update, task-local, out of scope or decision-required; Conformance confirms it reached the correct owner and verification without shortcuts or duplicate authority.
 
@@ -39,17 +39,17 @@ Do not infer long-task mode from duration, complexity, file count or agent prefe
 2. Explicit `/long-task-workflow` authors or resumes exactly one complete `long-task-delivery-v2` Contract for the selected delivery.
 3. `/normal-long-task` is a retirement pointer. Otherwise remain on the default Workflow Contract, even when work is long.
 
-Raw/revised proposals, selected design resources and mixed attachments enter one Source-bound Contract Draft loop immediately. Source inventory, refinement, provenance, markers and Contract mapping converge in the same non-authoritative `delivery-contract.yaml` until Preflight is ready and formal Compile creates Authority Lock; there is no prior or internal Source-authoring stage. A legacy Source Plan remains ordinary input. Candidate resources authorize no fidelity Claim. A selected implementation handoff must pass the shared design-resource preflight; its marked residual handoff enters `task.source_paths`, its handoff and source-profile entry/dependencies enter target Check `verification_inputs`, and Long-Task Preflight/Compile requires exact target/condition/file equality, covered Source Claims, one independent positive Assertion per declared verification method and blocker Source-item/method lineage before Authority Lock. After lock, resource changes use Authority Revision.
+Raw/revised proposals, selected design resources and mixed attachments enter one Source-bound Contract Draft loop immediately. Source inventory, refinement, provenance, markers and Contract mapping converge in the same non-authoritative `delivery-contract.yaml` until Preflight is ready and formal Compile creates Authority Lock; there is no prior or internal Source-authoring stage. Every non-empty line in declared Markdown Source belongs to one Material Item, the one validated formal handoff block or a closed-grammar background block containing only text-free anchors/horizontal rules or fixed-field `ty-source-provenance` comments; text-bearing headings, free-form provenance, arbitrary background prose and unclassified text fail closed unless classified as Material. At least one technical-obligation Source Item has `aspect=architecture` and maps to an independently provable architecture obligation. A legacy Source Plan remains ordinary input. Candidate resources authorize no fidelity Claim. A selected implementation handoff must pass the shared design-resource preflight; its marked residual handoff enters `task.source_paths`, its handoff and source-profile entry/dependencies enter target Check `verification_inputs`, and Long-Task Preflight/Compile requires exact target/condition/file equality, complete fact/resource closure, covered Source Claims, one independent positive Assertion plus typed `design_method` evidence, exact `fact_refs`, a distinct record path and primary-observation path/current digest for every method × condition cell, and blocker Source-item/method/capability lineage before Authority Lock. Playwright emits method evidence only when every project instance explicitly attaches both cell artifacts, and runtime fact refs must equal the compiled cell. After lock, resource changes use Authority Revision.
 
-When an Outcome declares Controls, its Product `surface_bindings` bind every Control to an owner surface, required product target, existing route/component Bindings and a root-entry success journey. Each bound Control's navigation result—or interaction, trigger or location fallback—must be proved on that target with interaction plus target-runtime evidence. Selected exact/constraint targets additionally bind declared conditions and frozen inputs to current actual/comparison artifacts through `design_conformance`; `verification_method_bindings` map every handoff method to a separate positive Assertion with relevant Source Claims and required evidence capabilities. Every declared design-acceptance blocker preserves exact Source-item/method provenance and resolves to target-local machine proof or a target-blocking external confirmation; it cannot be dismissed in-band, and scope removal requires revised Source/Contract authority. These are protected Contract semantics, not a UI registry, second Gate or per-surface state.
+When an Outcome declares Controls, all 22 canonical fields close through `field_coverage` as concrete `specified`, justified `not_applicable` or blocking `unresolved`; cross-Control/shared-state/navigation/permission/recovery meaning closes through applicability-bound `control_relation_closure` and `control_relations`, including a negative Claim when relations are not applicable. Its Product `surface_bindings` bind every Control to an owner surface, required product target, existing route/component Bindings and a root-entry success journey. Each bound Control's navigation result—or interaction, trigger or location fallback—must be proved on that target with interaction plus target-runtime evidence. Global and Outcome applicability profiles bind every Claim to its exact target, journey, atomic duplicate-free dimension assignments, Given condition/input/state refs and ordered When refs; every Claim-bearing Assertion proves one Claim in one matching profile, and every actual applicable proof-surface cell is covered without representative/pairwise sampling. Required product targets declare their family, cold-start and production-root capabilities. Selected exact/constraint targets additionally bind declared conditions and frozen inputs to current actual/comparison artifacts through `design_conformance`; `verification_method_bindings` map every handoff method to a separate positive Assertion, the exact facts for each method × condition cell, typed method record and distinct record/primary-observation artifacts whose current primary identities cannot be reused across cells. The union of compiled cells equals the target's complete handoff fact set; runtime `design_method` records repeat the exact `fact_refs`. Every behavioral Claim-bearing Assertion has a same-Check claim-local `replace_json_value` or `replace_text` Counterfactual and a claimless target-runtime liveness Assertion that must remain passing; whole-file replacement cannot prove semantic binding. Population binds its universe carrier into the owning Check input snapshot and proves universe = eligible = observed plus valid exclusions. Every declared design-acceptance blocker preserves exact Source-item/method/required-capability provenance and resolves to a machine Claim proved on the exact capability-qualified target or a target-blocking External Confirmation; it cannot be dismissed in-band, and scope removal requires revised Source/Contract authority. These are protected Contract semantics, not a UI registry, second Gate or per-surface state.
 
-The workflow uses one native Goal, one selected workspace, one Contract and one Final Gate. New authoring uses inline vertical Outcomes grouped by ordered Stages; existing `outcome_files` are physical compatibility only. Target profiles name required product targets and root runtimes; Checks declare Given/When journeys and all-of Evidence Capabilities. Stage/frontier state is derived from ordinary Progress and creates no second Gate, Receipt, scheduler or completion authority.
+The workflow uses one native Goal, one selected verification workspace, one Contract and one Final Gate. New authoring uses inline vertical Outcomes grouped by ordered Stages; existing `outcome_files` are physical compatibility only. New authority uses explicit `context_snapshot_mode: full`. Target profiles name required product targets, root runtimes and capabilities; Checks declare Given/When journeys and all-of Evidence Capabilities. Compile freezes declared verification inputs plus the supported direct-literal local verifier module/config/data graph; Check inputs/outputs/artifacts remain explicitly classified runtime material, non-literal loaders fail closed, and other indirect runtime access belongs in `verification_inputs` or the named project Oracle TCB. Stage/frontier state is derived from ordinary Progress and creates no implementation gate, second Gate, Receipt, scheduler or completion authority. `F = Implementation Freedom Boundary` keeps implementation order, local planning, methods, repair/feedback cadence and optional use of one or multiple platform-native agents/subagents Goal-owned within Source/Contract, architecture, safety, forbidden-shortcut and irreversible/external-action boundaries. Harness creates no development phase/method Gate, per-edit mandate, agent allocator/scheduler, delegation state or proof; agent reports are non-authoritative and all outputs converge into the selected workspace. Anti-Degradation Assurance requires current-implementation Context to match indexed code/runtime and keeps the controlling purpose, enabling key logic, two necessary implementation responsibilities, theorem boundary and adjacent `F` protected from implicit weakening. Replacing one requires an explicit project-owner design-purpose decision and replacement proof; a new development-stage constraint must additionally close a distinct path that final proof or a lighter project check cannot cover and have positive net ROI. Mechanism changes first prove `Coverage_new ⊇ Coverage_old`, `FalseNegative_new ⊆ FalseNegative_old` and non-bypassable Authority/fail-closed/final-snapshot proof; otherwise preserve the current formal acceptance path. Only after that hard gate may positive net ROI compare anti-degradation or purpose benefit with all incremental authoring/runtime/state/recovery/maintenance/test/process/introduction/migration cost, and cost never compensates for weaker drift interception. This is project governance and verification, not another Authority, Gate or state.
 
 After the first Authority Lock, treat `execution_model_checkpoint.required: true` as a terminal-turn boundary. Unless the user already stated an explicit task-specific choice naming current-model continuation or a model switch, end the current turn before product implementation, file edits, builds or tests and ask the user to choose `continue_current_model` or switch models and then resume. Generic continue/resume/finish/continue-goal language does not satisfy the checkpoint; later revisions do not repeat it. Harness records no model route or checkpoint acknowledgement state.
 
 During Draft authoring, proof design or authority lifecycle work, read the applicable references in the package-managed `long-task-workflow` Skill. Use `ty-context long-task help` for CLI syntax instead of treating this startup router as a command reference. Before first Authority Lock, Preflight and Compile classify current HEAD-relative workspace changes against protected paths and declared expected/support ownership; after lock, Verify and Final Gate apply the same fail-closed categories against the immutable baseline. During first enable, protection covers only exact files present in the current package asset tree for configured managed destinations plus the exact harness config/hook files; managed directory roots and broad `.codex/**` are never exempt.
 
-Final Gate, Stop and close recompile the source Contract and rerun every declared Check on one clean current snapshot. Final Gate is the Long-Task path's sole `Architecture Conformance` and selected-design closure owner; do not run either default-workflow closure. Required targets cannot substitute for one another; presence cannot prove behavior; resource integrity or `visual_render` cannot substitute for selected-target `design_conformance`; success and degradation remain distinct; typed boundary effects require an observer; unresolved design blockers remain blocking. `verify --explain` is a read-only declared-execution preview and creates no proof or Progress. Targeted verify is repair evidence only; `progress_stale` is a freshness fact, not a per-edit rerun instruction, so coalesce related edits and refresh the cheapest reliable owning Check before dependent reliance or Final Gate. Status, progress, Stage/frontier projections, receipts and compiled cache are audit/recovery surfaces only; prose, historical tests or Agent judgment never create acceptance. Authority Revision separates authority change from user decision: mechanically bounded revisions may auto-adopt but still invalidate affected evidence; semantic/proof/forbidden-boundary/verifier-kernel changes and unknown reasons require one exact decision. Present the self-contained brief first. If an explicit current task instruction exactly covers every listed reason, mechanically relay it without a second question; generic continuation, blanket authorization, recommendation or Agent inference never qualifies. Coalesce withdrawn candidates and ask only for the final blocking identity. An adopted revision returns to rolling execution and is never delivery completion. External confirmations remain typed and explicit; machine acceptance reports target/stage qualification but cannot by itself authorize completing the platform-native Goal, CI, deployment or human acceptance.
+Final Gate, Stop and close first reject stale accepted authority inputs, recompile the source Contract and rerun every declared Check on one clean current snapshot. Final Gate records the semantic and raw identity of the Contract/fragments, Source, full Controlling Context, verifier/runner, recursively frozen local verifier dependencies, verification inputs and workdir inputs before execution, then recompiles and re-hashes that full protected set afterward; any race fails closed. Final Gate is the Long-Task path's sole `Architecture Conformance` and selected-design closure owner; do not run either default-workflow closure. Required targets cannot substitute for one another; presence cannot prove behavior; resource integrity or `visual_render` cannot substitute for selected-target `design_conformance`; omitted/substituted design `fact_refs` cannot be hidden by passing artifacts; success and degradation remain distinct; typed boundary effects require an observer; unresolved design blockers remain blocking. `verify --explain` is a read-only declared-execution preview and creates no proof or Progress. Targeted verify is optional repair feedback only; `progress_stale` is a freshness fact, not a per-edit rerun instruction. Coalesce related edits and refresh the cheapest reliable owning Check only before intermediate reliance; implementation and Final Gate may proceed because Final Gate ignores Progress and reruns all Checks. Status, progress, Stage/frontier projections, receipts and compiled cache are audit/recovery surfaces only; prose, historical tests or Agent judgment never create acceptance. Authority Revision separates authority change from user decision: mechanically bounded revisions may auto-adopt but still invalidate affected evidence; semantic/proof/forbidden-boundary/verifier-kernel changes and unknown reasons require one exact decision. Present the self-contained brief first. If an explicit current task instruction exactly covers every listed reason, mechanically relay it without a second question; generic continuation, blanket authorization, recommendation or Agent inference never qualifies. Coalesce withdrawn candidates and ask only for the final blocking identity. An adopted revision returns to rolling execution and is never delivery completion. External confirmations remain typed and explicit: exactly fresh `machine_accepted` with no pending confirmation is the complete-delivery accepted terminal covered by the full no-drift implication; `machine_accepted_external_pending` proves only the declared machine scope and cannot authorize completing the platform-native Goal, CI, deployment or human acceptance. The theorem remains conditional on complete/accurate declared Source and a semantically sound named project oracle; unsupported resource extraction remains blocking, and Harness/runtime packages and Git metadata are explicit trusted-computing-boundary components.
 
 Tiny Context does not create or restore platform Goals, invoke models, spawn agents, call an App Server, create branches/worktrees, merge, push, open PRs, deploy or manage process trees. `ty-context enable long-task` installs the Long-Task Workflow Skill, the retired Source Plan compatibility pointer and package-owned completion Hook.
 

package/assets/skills/context_development_engineer/SKILL.md

@@ -9,7 +9,7 @@ description: Use when the user explicitly asks for 开发工程师, 软件工程
 
 This generated Skill provides portable engineering judgment. Project-specific rules belong in `<harnessRoot>/skills/development_engineer/SKILL.md`; the repo-local Skill is more specific while durable conclusions still belong in `project_context/**`.
 
-When an active `/long-task-workflow` binding exists, that Skill owns lifecycle, one-workspace, no-proactive-subagent and Final Gate boundaries. This Skill contributes architecture and implementation judgment only; it must not create a second plan, agent scheduler or acceptance path.
+When an active `/long-task-workflow` binding exists, that Skill owns lifecycle, the selected verification workspace, Goal-owned implementation/delegation boundary and Final Gate. This Skill contributes architecture and implementation judgment only; it must not create a second plan, delegation scheduler/state or acceptance path.
 
 ## 目标
 
@@ -94,7 +94,7 @@ sample provider / interface / page 证据不能替代 all-provider / all-interfa
 
 For material production UI, first confirm Design Authority readiness; then carry declared Context, `DESIGN.md` and Source intent into the real implementation without creating another workflow:
 
-- when a selected implementation handoff exists, run `ty-context design-resource preflight <handoff.md>` before fidelity implementation. Open the strict residual block and every indexed exact/constraint resource. Keep one exact task-local accounting of covered Source Items, declared verification methods, acceptance blockers, selected targets and conditions; route every applicable item to the production owner, cold-start journey and a project-owned check whose failure remains attributable. Missing applicability cells, unsupported evidence, unresolvable typed locators, incomplete/truncated implementation source, unresolved rows or stale digests fail closed. Provider retrieval and preflight prove input completeness/integrity only, not the implementation;
+- when a selected implementation handoff exists, run `ty-context design-resource preflight <handoff.md>` before fidelity implementation. Open the strict residual block and every indexed exact/constraint resource. Its default unit is every complete observable design fact exposed by the acquired resources and supported inspector/oracle capability, not merely one Product Control: preserve addressable images, text, icons, component parts, smaller primitives, exact layout/style/content/state/behavior facts and their declared conditions. Keep one exact task-local accounting of fact/Source/method/blocker/target/condition sets; route every applicable item to the production owner, cold-start journey and a project-owned check whose failure remains attributable. Exact targets require full-target layout and pixel proof per condition; partial input remains a constraint. Missing facts/resource closure/applicability cells, unsupported evidence, unresolvable typed locators, incomplete/truncated implementation source, unresolved rows or stale digests fail closed. Provider retrieval and preflight prove input completeness/integrity only, not the implementation;
 - treat an unconfigured starter, style-only guidance, inspiration-only references or conflicting targets as insufficient authority for invented production layout; route explicit design authoring through `context_uiux_design` or return for a genuine material decision;
 - classify referenced targets as `exact-target`, `constraint` or `inspiration`; for every affected selected exact target/constraint, traverse its stable key from owning Context through `DESIGN.md` and open the immutable adopted locator/digest before deciding or coding—a registry mention alone is not consumption. Bind fidelity claims only to the named conditions;
 - resolve the editable upstream owner/locator/update route before changing a design resource. Missing, unreadable, stale or conflicting adopted resources fail closed for the affected claim. If the immutable target is readable but upstream editing is unavailable, implementation may consume it but a resource change remains a named manual/external boundary. Never overwrite an adopted baseline; use a new immutable version and update the owning reference;
@@ -102,15 +102,15 @@ For material production UI, first confirm Design Authority readiness; then carry
 - reuse production components and real product routes for states/specimens instead of building a detached static imitation as the acceptance target;
 - trace each selected target and declared viewport/mode/state condition through a stable surface/control key to its production route/component owner, cold-start real-user entry journey and project-owned rendered/interactive Check;
 - preserve approved semantic tokens and component APIs; do not bypass them with undeclared raw color, spacing, typography or motion values merely to match one screenshot;
-- implement the declared Visual Coverage Set across the applicable viewport, theme/mode, state, content-stress and accessibility/motion combinations, while avoiding an unrequested full Cartesian expansion;
-- after the first runnable vertical slice, inspect it through the real production entry so wrong shell/navigation ownership is discovered before broad rollout; rerun the affected cold-start journey on the final candidate;
+- implement the declared Visual Coverage Set across every applicable viewport, theme/mode, state, content-stress and accessibility/motion combination. Do not synthesize unrequested dimensions, but never prune a declared/applicable combination or replace its coverage with risk-only or pairwise sampling unless authoritative Source explicitly narrows the requirement or a project-owned proof establishes equivalence;
+- use the first useful runnable vertical slice as a recommended real-production-entry feedback point when its expected early-localization value exceeds the run cost; it is not an implementation gate. Always rerun the affected cold-start journey on the final candidate;
 - run project-owned rendered/component/browser verification and report only the combinations actually checked. Design file hashes, registry membership and counts prove resource integrity; static analysis, generated kits and screenshot artifacts are supporting review material rather than implementation-conformance proof.
 - For each applicable material control, preserve region/location, type/label, user task, visibility/availability, trigger/input/validation/default, interaction/navigation, loading/empty/success/failure/recovery/permission/feedback and accessibility semantics. An omitted field is not permission to invent durable product behavior; resolve it through UI Authority Closure.
 - never promote the implementation's own generated screenshot/diff into its target; exact targets and acceptance-affecting baselines are selected Source/verifier inputs before comparison.
 
-Without an active Long-Task, final-current-candidate Contract Conformance confirms every accounted item is mapped, resolved, executed and passing. One project check may cover several methods only when each method and covered fact remains independently attributable on failure. A selected-target, implementation or declared check-input change stales closure. Any unresolved, unmapped, unexecuted, stale or indistinguishable item blocks a complete selected-design-conformance claim; report the checked scope and exact gaps. Do not persist the accounting as a matrix, Claim set, readiness state or Gate.
+Without an active Long-Task, final-current-candidate Contract Conformance confirms every accounted fact/item is read, mapped, implemented, resolved, executed and passing. One project check may cover several methods only when each method and covered fact remains independently attributable on failure. A selected-target, fact inventory, implementation or declared check-input change stales closure. Any unread, unsupported, unresolved, unmapped, unimplemented, unexecuted, stale or indistinguishable applicable fact blocks a complete selected-design-conformance claim; report the checked scope and exact gaps. Do not persist the accounting as a matrix, Claim set, readiness state or Gate.
 
-If an active Long-Task applies, do not run the preceding default closure. Express material visual expectations through its existing Requirement, full Control projection, Product `surface_bindings`, Assertion, Check, Stage, Technical Binding and external-confirmation mechanisms. Include the validated residual handoff in real `task.source_paths` and every declared immutable resource in target verification inputs; make target keys/conditions/files equal the handoff. Map covered Source Items into the root conformance Assertion and one independent Assertion per declared verification method; bind each handoff blocker with the same Source Items and methods. Bind every Control to a required production target and root-entry journey; bind selected exact/constraint targets to typed `design_conformance` actual/comparison evidence. Final Gate is the sole Long-Task carrier. A blocker cannot be dismissed in-band, and scope removal requires revised Source/Contract authority. A design candidate or planned target cannot unlock fidelity implementation: selection must become real Context-reachable Source with one canonical adoption record and an adopted Authority Revision first. Do not introduce a second visual plan, acceptance document or lifecycle.
+If an active Long-Task applies, do not run the preceding default closure. Express material visual expectations through its existing Requirement, full Control projection, Product `surface_bindings`, Assertion, Check, Stage, Technical Binding and external-confirmation mechanisms. Include the validated residual handoff in real `task.source_paths` and every declared immutable resource in target verification inputs; make target keys/conditions/files equal the handoff. Map covered Source Items into the root conformance Assertion and one independent Assertion per declared verification method; every method × condition evidence cell and current typed record must carry the exact handoff `fact_refs`, whose union equals the complete target fact set. Bind each handoff blocker with the same Source Items and methods. Bind every Control to a required production target and root-entry journey; bind selected exact/constraint targets to typed `design_conformance` actual/comparison evidence. Final Gate is the sole Long-Task carrier. A blocker cannot be dismissed in-band, and scope removal requires revised Source/Contract authority. A design candidate or planned target cannot unlock fidelity implementation: selection must become real Context-reachable Source with one canonical adoption record and an adopted Authority Revision first. Do not introduce a second visual plan, value copy, acceptance document or lifecycle.
 
 ## Modularity Check
 

package/assets/skills/context_uiux_design/SKILL.md

@@ -40,9 +40,9 @@ Project-specific UI/UX and visual design rules belong in a separate project-loca
 - `design-resource-authoring` 可以按明确请求在上游动态委托 Open Design 产生 flow、低保真、候选方向、组件族/独特复杂控件状态、交互原型或实现级资源；它以明确输出/开发内容为上限，在范围内补齐材料性 UI/UX 含义但不要求逐控件一份稿，不复制 provider 的提示词/模板，也不把任何资源设为全局必选。
 - `design-system-authoring` 是另一个仅显式调用的冷启动/修复 Skill：它用 Open Design 生成或选择候选，经过明确或受托选择后，把结果采纳到 canonical `DESIGN.md`、唯一 token source/direction 与 owning Context。缺少设计系统不会让本 Skill 或 `design-resource-authoring` 自动调用它。
 - 本 Skill 不承担独立资源生产。只有进入默认开发流程或 Long-Task、需要采纳稳定结论时，本 Skill 才消费这些或其他外部设计 Source。
-- 如果上游交付是用于实现的已选资源，先要求一个通过 `ty-context design-resource preflight <handoff.md>` 的 `design-resource-handoff-v1`。Web/App target 必须声明完整取得的 canonical entry 与依赖闭包；handoff 作为残余语义/coverage 适配器，以 typed locator 索引资源，并逐 subject × target × condition 闭合 surface/flow、visual/content、component/control、state/interaction、motion、adaptation/input、accessibility、assets。探索候选不需要此文件；provider/preflight 也不等于采纳或验收。
+- 如果上游交付是用于实现的已选资源，先要求一个通过 `ty-context design-resource preflight <handoff.md>` 的 `design-resource-handoff-v1`。Web/App target 必须声明完整取得的 canonical entry 与依赖闭包；handoff 作为残余语义/coverage 适配器，以 typed locator 原子索引资源内每个受支持、范围内、可观察的设计事实，逐资源记录完整检查闭包，并逐 subject × target × condition 闭合 surface/flow、visual/content、component/control、state/interaction、motion、adaptation/input、accessibility、assets。Control 是产品交互语义单位，不是 UI 原子粒度上限；图片、文字、图标、组件内部片段、更小视觉 primitive、布局/样式/状态/行为事实只要资源表达就要索引。探索候选不需要此文件；provider/preflight 也不等于采纳或验收。
 - 候选、灵感和未选定输出不是 Context readiness 或实现权威，不能写入 selected registry；选定目标仍必须完成 UI Authority Closure 和 `Context Delta`。
-- 消费时沿 owning Context 的 surface/control/target key 到 canonical adoption record，主动打开每个受影响的 selected `exact-target`/`constraint`，而不是把登记存在视为已消费。核对产品 Source、Screen/Control Context、token owner、不可变 adopted locator/digest、覆盖条件以及 editable upstream owner/locator/update route；按 Design Source Projection 只把长期稳定且无冲突的事实写入其唯一 owner，不要求统一 pack、目录或工具格式。
+- 消费时沿 owning Context 的 surface/control/target key 到 canonical adoption record，主动打开每个受影响的 selected `exact-target`/`constraint`，而不是把登记存在视为已消费。核对产品 Source、Screen/Control Context、token owner、不可变 adopted locator/digest、覆盖条件、完整 fact/resource closure 以及 editable upstream owner/locator/update route；`exact-target` 每个条件必须具备整目标 layout 与 pixel 事实，否则应保持 partial `constraint` 或阻断。按 Design Source Projection 只把长期稳定且无冲突的事实写入其唯一 owner，精确值仍留在 canonical resource，不要求统一 pack、目录或工具格式。
 - 缺失、不可读、过期或冲突的 adopted resource 对受影响 claim 一律 fail closed。若 immutable adopted target 可读而 editable upstream 不可用，可以继续理解/实现既有目标，但修改资源必须保留为明确人工/外部边界。更新经 upstream 完成后生成/批准新 immutable version 并更新 owning reference，不能静默覆盖旧基线。
 - 设计资源生成本身不改 `project_context/**`、`DESIGN.md` 或 production code；定稿后只可一次性回改初始方案。设计系统采纳则由显式 `design-system-authoring` 完成。下游实现与验证仍由当前 Workflow Contract 或 `long-task-workflow` 负责。
 
@@ -126,18 +126,18 @@ Configured is system-level visual authority only, not surface implementation-rea
 - If the user explicitly asks to initialize/generate/select/adopt the project design system, use the explicit-only `design-system-authoring`; never infer it from a missing starter. If the user explicitly delegates standalone resource generation, use `design-resource-authoring`. Style-bearing resources must stop on unconfigured authority and bind the adopted Open Design system; low-fidelity/IA/semantics-only resources remain lightweight. After final selection, resource authoring may reconcile accepted decisions into the initial proposal once, but this downstream Skill adopts durable target meaning only after UI Authority Closure.
 - Never use the implementation's own generated screenshot or diff as the target it claims to match. A target is selected Source; an implementation render is evidence. Baseline replacement requires deliberate review and cannot merely erase a failure.
 - Keep resource integrity and implementation conformance separate: a valid file hash, provider extraction/export, registry entry or resource count proves only acquisition/integrity, not that the production route/component renders or behaves like the selected target under the declared conditions.
-- Do not require Figma, a fixed `docs/design/**` tree, an image for every local change or universal pixel-perfect thresholds. Use project-native design assets and the smallest authority sufficient for the claimed fidelity.
+- Do not require Figma, a fixed `docs/design/**` tree, an image for every local change or a universal numeric pixel tolerance. For a selected `exact-target`, however, require project-owned condition-specific full-target layout and pixel comparison; if the resource or oracle cannot support that claim, classify it as a constraint or blocking gap. Use project-native design assets and the smallest authority sufficient for the claimed fidelity.
 
 ## Visual Delivery Coverage / 视觉交付覆盖
 
 For material design-system, redesign, high-fidelity implementation or visual-polish work, keep a task-local **Visual Coverage Set** before implementation and verification. When external design Source declares coverage, reconcile it with current delivery scope rather than creating competing authority. The downstream working set remains internal planning, not a required file, matrix, Context role, workflow artifact or completion authority.
 
-- Select risk-proportional representative combinations across production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions. Do not expand the full Cartesian product unless Source explicitly requires full combination coverage, and never claim an unchecked combination.
+- Start from the complete set of combinations that authoritative Source, selected targets/constraints and applicable Control semantics declare across production surface/route/component, viewport, theme or product mode, interaction/state, content stress and accessibility/motion conditions. Risk-proportional reasoning may prioritize execution order or add exploratory combinations beyond that authority, but must never prune a declared/applicable combination or replace it with representative/pairwise sampling unless authoritative Source explicitly narrows the scope or a project-owned proof establishes equivalence. Do not invent a Cartesian product across dimensions outside declared scope, and never claim an unchecked combination.
 - Cover relevant states such as default, hover, focus, active, disabled, loading, empty/no-results, error, success and long/extreme content. Use the project's declared viewport, contrast, target-size, reduced-motion and localization rules rather than inventing universal thresholds.
 - Keep the authority split explicit: `project_context/**` owns durable surface/interaction responsibility and `DESIGN.md` owns durable visual-system semantics and rationale. Record one authored exact-value token source and one generation direction; generated CSS/theme/export files are implementation outputs, not competing authored truth. If `DESIGN.md` is not the machine-token source, name the project-native source it governs instead of hand-maintaining the same exact values twice.
 - Map every claimed fidelity combination to its selected `exact-target` or named `constraint`; do not let the Visual Coverage Set turn inspiration or missing authority into an implicit target.
 - Inspect production components or real product routes. A detached static kit, mock, poster, marketing specimen or generated showcase may guide design review, but it cannot be the only evidence for product UI behavior or fidelity.
-- For each selected combination, identify the cold-start real-user entry journey and inspect the first runnable production slice before expanding the rest of the UI; deep links remain supplemental when users normally enter through a shell or navigation owner.
+- For each selected combination, identify the cold-start real-user entry journey. A first useful runnable production slice is a recommended real-entry feedback point when early localization is worth its cost, not a prerequisite for expanding implementation; deep links remain supplemental when users normally enter through a shell or navigation owner. Always rerun the affected cold-start journey on the final candidate.
 - Render and inspect the declared coverage with project-owned browser/component tests plus screenshots or manual review as appropriate. Report the combinations actually checked and any omitted or external review explicitly. A screenshot baseline may be updated only through deliberate review; replacing it merely to erase a diff is not verification.
 
 ## 输出边界

package/assets/skills/design-resource-authoring/SKILL.md

@@ -5,7 +5,7 @@ description: Use when the user explicitly asks to generate, author, plan, commis
 
 # Design Resource Authoring
 
-Commission the smallest sufficient set of design resources for the explicitly requested output or development scope from live Open Design capabilities. This Skill is a thin task-local planner, provider adapter, iteration guide, final proposal reconciler and handoff layer; Open Design owns generation logic and Tiny Context owns neither its prompts nor runtime.
+Commission the smallest sufficient set of design resources for the explicitly requested output or development scope from live Open Design capabilities. For a selected implementation handoff, the default indexing unit is every complete observable design fact exposed by the acquired resource and supported inspector/oracle capability; exact targets additionally require condition-specific full-target layout and pixel facts. This Skill is a thin task-local planner, provider adapter, iteration guide, final proposal reconciler and handoff layer; Open Design owns generation logic and Tiny Context owns neither its prompts nor runtime.
 
 ## Hard boundaries
 
@@ -15,6 +15,7 @@ Commission the smallest sufficient set of design resources for the explicitly re
 - Never make a prototype, wireframe, high-fidelity candidate, design-system slice, provider-native file, variant count or directory layout universally mandatory.
 - Treat the user's explicit output/development scope as the hard ceiling. Include only the surrounding context needed to design that slice.
 - Never require one artifact per control. Reuse selected component sources and group repeated controls by family; commission a dedicated study only for unique or complex uncovered meaning.
+- Do not confuse Product Control granularity with design-fact granularity. An image, text run, icon, component part, smaller visual primitive, layout relation, geometry/style/token/content/state/behavior fact remains independently material when the selected resource expresses it.
 - Never infer that a page frame or prototype covers states, responsiveness, accessibility or interaction it does not explicitly specify or demonstrate.
 - Exploration and unselected previews stay schema-free. Only a final selected implementation handoff requires the shared strict Markdown adapter; this is input preparation, not a resource pack or acceptance result.
 - Design resources may express user-visible interaction and presentation, but must not invent or become sole owner of business, data, permission or algorithmic rules.
@@ -34,14 +35,14 @@ Commission the smallest sufficient set of design resources for the explicitly re
 2. **Inventory inputs.** Accept initial proposals, notes, product/technical plans, visual briefs, screenshots, references and existing resources. Preserve each role as exact target, constraint, inspiration, current-implementation evidence or background; report unreadable/unused material.
 3. **Classify visual-style dependency.** Mark the commission `style-bearing` when it materially expresses visual fidelity, brand, typography/color/density, component visual treatment or a production-style prototype. Mark it `non-fidelity` for IA/flow topology, low-fidelity structure, semantics-only behavior/state studies or an explicitly non-fidelity prototype. Mixed work is style-bearing unless split into an independent non-fidelity commission.
 4. **Apply the conditional Design Authority gate.** For style-bearing work, read `DESIGN.md` and its token source. If authority is unconfigured, stop before project/run creation and tell the user to explicitly invoke `$design-system-authoring`; do not invoke it automatically. A combined explicit request authorizes running that Skill first and then resuming this one. Non-fidelity work remains allowed.
-5. **Find design gaps.** For handoff, account for material in-scope structure, control anatomy/variants, content/visual treatment, states, interaction/feedback/motion, adaptation/input, accessibility and assets. Subtract only coverage explicitly supplied by selected Source.
+5. **Find design gaps.** For handoff, account for every in-scope observable design fact across structure, control/component anatomy and smaller primitives, content/visual treatment and exact style/layout values, states, interaction/feedback/motion, adaptation/input, accessibility and assets. Subtract only coverage explicitly supplied by selected Source; unsupported or unreadable facts remain blocking rather than silently absent.
 6. **Discover live capabilities.** Inspect the current Open Design agent/model, skills, templates, design systems, plugins and export paths. Treat absent/non-enumerable capabilities honestly.
 7. **Choose the minimum sufficient commission.** Give each considered resource `selected`, `optional`, `not-needed`, `unavailable` or `decision-required` with one reason. Ask only when a missing preference materially changes the commission.
 8. **Bind and commission through Open Design.** For style-bearing work, create or verify the Open Design project with the adopted design-system ID and require `get_project.designSystemId` to match. Send a bounded product commission through structured MCP; use documented fallbacks only when required.
 9. **Acquire a complete implementation source when applicable.** For Web/App implementation handoff, require Open Design to emit a canonical machine-readable entry plus the full declared dependency set—not only a screenshot or preview. Enumerate and retrieve every selected file without truncation, preserve exact bytes/digests, record one `implementation_web` or `implementation_app` source profile with `acquisition: complete`, and make all local HTML/CSS/JS dependencies resolve inside that frozen set. Non-Web resources use the bounded `reference` profile and are not forced into HTML.
 10. **Observe, inspect and iterate.** Keep provider execution, artifact readiness and design suitability separate. Iterate within scope. Keep proposal effects only in the delta buffer while candidates remain unsettled.
 11. **Finalize selection and reconcile once.** After explicit human selection or explicit delegated selection, preserve immutable identity and consolidate accepted, rejected and unresolved effects. Apply only accepted decisions once to a writable initial-proposal file; if it exists only in conversation, return one complete revised proposal. Preserve original intent/provenance and make reruns idempotent. Do not write unresolved or rejected choices as requirements.
-12. **Compile the residual implementation handoff when requested.** For final selected resources intended for development, write one project-native Markdown Source at an authorized path. Preserve readable `ty-source-item` facts and exactly one fenced `design-resource-handoff-v1` YAML block. Keep exact code-expressible UI facts in the canonical resources; the handoff indexes them through typed, locally resolvable locators and adds only scope, applicability, residual product meaning, explicit exclusions/unresolved items, blockers and downstream bindings. Close every applicable subject × target × condition × dimension cell, bind covered cells to same-target/same-condition evidence, Source Items and verification methods, and run `ty-context design-resource preflight <handoff.md>`. Missing/unresolvable locators, partial dependency closure, `decision_required`/`unavailable`, stale digests and unsupported evidence are blocking. Do not create this file for exploration.
+12. **Compile the residual implementation handoff when requested.** For final selected resources intended for development, write one project-native Markdown Source at an authorized path. Preserve readable `ty-source-item` facts and exactly one fenced `design-resource-handoff-v1` YAML block. Keep exact code-expressible UI values in the canonical resources; atomically index every observable fact through typed, locally resolvable locators, close every resource as `material_with_facts` or honestly `supporting_only`, and add only scope, applicability, residual product meaning, explicit exclusions/unresolved items, blockers and downstream bindings. Close every applicable subject × target × condition × dimension cell and make its `fact_refs`, evidence, Source Items and verification methods exactly equal the indexed fact unions. Every exact target needs full-target `layout_geometry` and `visual_pixel` facts per condition; otherwise classify it as a partial constraint or unresolved. Run `ty-context design-resource preflight <handoff.md>`. Missing/unresolvable locators, partial dependency or resource-fact closure, `decision_required`/`unavailable`, stale digests and unsupported evidence are blocking. Do not create this file for exploration.
 13. **Return an intent-sized result.** Exploration shows the artifact promptly. An implementation handoff returns the validated handoff path, selected immutable resources, stable-key coverage, provenance, binding, limitations and preflight result. Include the reconciled initial proposal or its updated path when final selection occurred.
 
 ## Conditional Design Authority gate

package/assets/skills/design-resource-authoring/references/downstream-handoff.md

@@ -16,7 +16,7 @@ For every material in-scope surface/flow/region/component/control condition, rec
 
 Design resources may show user-visible triggers, transitions, states, feedback and product-rule presentation. Business, data, permission and algorithmic rules remain owned by product/technical Source and must not be invented by visuals.
 
-Canonical implementation resources own exact code-expressible layout, visual, content, state, interaction, adaptation, motion, semantic and asset facts. The structured handoff is the residual semantic and index layer for scope, applicability and downstream binding: it indexes those facts through typed locators instead of manually duplicating their values, and it is not a second numeric/style source.
+Canonical implementation resources own exact code-expressible layout, visual, content, state, interaction, adaptation, motion, semantic and asset facts. The structured handoff is the residual semantic and index layer for scope, applicability and downstream binding: it atomically indexes every observable fact through typed locators, records a complete inspection closure for every resource instead of manually duplicating values, and is not a second numeric/style source. Product Controls remain semantic interaction units and do not cap fact granularity; addressable images, text, icons, component parts, smaller primitives, geometry/style/token/state/behavior facts are indexed when expressed.
 
 ## Final proposal reconciliation
 
@@ -83,17 +83,20 @@ The strict block includes:
 - editable upstream owner, locator and update/export method, or an explicit manual/external-update boundary when unavailable;
 - declared platform, viewport, mode, state, content, input and full/reduced/not-applicable motion conditions;
 - typed, locally resolvable evidence locators (`html_selector`, `markdown_anchor`, `json_pointer`, `css_selector`, `css_custom_property` or bounded `whole_resource`) whose kinds distinguish frame/component variant/prototype state or transition/motion/responsive/input/accessibility/semantic/token/asset/annotation meaning;
+- atomic `facts`, each naming exactly one subject, target, condition, dimension, `subject|full_target` observation scope, same-target/same-condition evidence set, Source-item set and verification method;
+- exactly one `resource_fact_closure` entry per resource with a named complete inspector, rationale and either `material_with_facts` plus the exact fact set or `supporting_only` plus no facts;
 - stable subjects grouped only when they truly share meaning;
 - every declared scope surface represented by one unambiguous surface subject, with no stable key owned by two subjects;
 - explicit target applicability for each subject and complete subject × target × condition × dimension coverage for `surface_flow`, `visual_content`, `component_control`, `state_interaction`, `motion`, `adaptation_input`, `accessibility` and `assets`;
 - exactly one disposition per applicable cell: `covered`, `not_applicable`, `excluded_by_scope`, `decision_required` or `unavailable`;
-- covered-cell same-target/same-condition evidence, Source-item refs and dimension-appropriate project verification methods; referenced design Source Items use `requirement`, `control` or `acceptance` markers;
+- covered-cell `fact_refs`, same-target/same-condition evidence, Source-item refs and dimension-appropriate project verification methods, each set exactly equal to the union of its facts; every fact appears in exactly one coverage row, and referenced design Source Items use `requirement`, `control` or `acceptance` markers;
+- for every `exact_target` condition, one `full_target` `layout_geometry` fact and one `full_target` `visual_pixel` fact backed by exact-target evidence; if complete visible fidelity cannot be extracted/compared, keep the resource a `constraint` or unresolved;
 - source-backed rationales for non-applicable/excluded rows; unresolved rows remain visible and make preflight fail;
-- target-local acceptance blockers that downstream checks must bind rather than dismiss;
+- target-local acceptance blockers with exact target/subject/dimension/Source-item/verification-method lineage and a non-empty `required_capabilities` set; use the narrowest truthful capability such as physical device, sensor, camera, orientation, haptic, screen reader, pixel-density, safe-area, input or production runtime rather than weakening it to an available proxy;
 - selection basis, proposal reconciliation path/status and known limitations;
 - outer review and separate provider/artifact/design qualifiers.
 
-Unknown fields fail closed. A static frame may support only visible layout/visual/component facts for its shown condition; it cannot cover unseen interaction, motion, adaptation/input or accessibility. Run:
+Unknown fields fail closed. Every resource must be inspected; a material resource cannot be hidden as `supporting_only`, and unsupported/unreadable extraction remains blocking inside the named inspector/oracle TCB. A static frame may support only visible layout/visual/component facts for its shown condition; pixel evidence cannot cover unseen interaction, motion, adaptation/input or accessibility. Run:
 
 ```text
 ty-context design-resource preflight <handoff.md>
@@ -118,11 +121,11 @@ initial proposal
 
 ### Default Workflow consumption
 
-The consuming Goal brings the revised proposal, selected resources and residual handoff as ordinary Source. It reruns shared preflight before UI Authority Closure, opens affected exact/constraint resources before deciding, classifies coverage, decides `Context Delta`, and makes every adopted decision-relevant target Context-reachable through existing owners. It routes every covered Source Item and verification method through the production owner and real-entry checks. A later update creates a new immutable version rather than overwriting the adopted baseline.
+The consuming Goal brings the revised proposal, selected resources and residual handoff as ordinary Source. It reruns shared preflight before UI Authority Closure, opens affected exact/constraint resources before deciding, classifies coverage, decides `Context Delta`, and makes every adopted decision-relevant target Context-reachable through existing owners. It routes every fact, covered Source Item and verification method through the production owner and real-entry checks. Any unread, unsupported, unmapped, unimplemented, unverified or indistinguishable applicable fact blocks the complete claim. A later update creates a new immutable version rather than overwriting the adopted baseline.
 
 ### Long-Task consumption
 
-The same revised proposal, selected resources and validated residual handoff enter `long-task-workflow`'s Source-bound Contract Draft loop immediately. The marked handoff is `task.source_paths`; each Contract design target's frozen `source_paths` and Check `verification_inputs` equal that handoff plus every declared resource path and condition. Covered Source Items map through `source_claims` to the root conformance Assertion. Every verification method maps to an independently failing Assertion carrying its relevant Source Claims; every blocker preserves its Source-item/method lineage into a target-local machine Claim or target-blocking External Confirmation. Authority Lock, Authority Revision and Final Gate remain the sole lifecycle. This Skill creates no Contract Draft, Outcome, Receipt, Check result or Gate.
+The same revised proposal, selected resources and validated residual handoff enter `long-task-workflow`'s Source-bound Contract Draft loop immediately. The marked handoff is `task.source_paths`; each Contract design target's frozen `source_paths` and Check `verification_inputs` equal that handoff plus every declared resource path and condition. Covered Source Items map through `source_claims` to the root conformance Assertion. Every verification method maps to an independently failing Assertion carrying its relevant Source Claims; each method × condition evidence cell carries the exact handoff `fact_refs`, the union equals the target fact set, and current typed `design_method` evidence repeats the exact set. Every blocker preserves its Source-item/method/required-capability lineage into a machine Claim proved on the exact capability-qualified target or a target-blocking External Confirmation. Authority Lock, Authority Revision and Final Gate remain the sole lifecycle. This Skill creates no Contract Draft, Outcome, Receipt, Check result or Gate.
 
 ## Forbidden inferences
 

package/assets/skills/design-resource-authoring/references/resource-selection.md

@@ -105,7 +105,7 @@ Do not manufacture a gap already resolved by selected Source.
 
 A prototype is often valuable for new Web/App flows, but it is never automatically required. Low- and high-fidelity resources may both be selected only when they answer independent questions. One comprehensive, inspectable artifact may cover page composition and several component families; a static frame cannot claim unseen interaction or state coverage merely because all controls appear in it.
 
-Do not translate control-level completeness into one artifact per control. Map ordinary controls to selected shared component variants, group related states in one component-family board or workbench, and reserve dedicated resources for unique or complex controls whose material meaning is otherwise uncovered.
+Do not translate Product Control closure into one artifact per control. Artifact grouping is an authoring optimization, while the later implementation handoff still inventories every observable design fact inside those artifacts, including component parts and smaller primitives. Map ordinary controls to selected shared component variants, group related states in one component-family board or workbench, and reserve dedicated resources for unique or complex controls whose material meaning is otherwise uncovered.
 
 ## 7. Assign a disposition to every considered resource
 
@@ -132,6 +132,7 @@ scope:
   viewports: []
 coverage:
   material_needs: []
+  observable_fact_families: []
   existing_mappings: []
   required_content_visual: []
   required_components_states: []
@@ -157,7 +158,7 @@ This is an explanatory shape, not a required file or schema. Never paste or para
 - Reuse the current Open Design project when that preserves context and provenance; preserve the prior artifact hash before overwriting a selected candidate.
 - Do not create low-fi, high-fi, component boards or native-platform copies merely because a process diagram lists them.
 - For exploration, stop as soon as the requested decision is supported.
-- For an implementation handoff, stop only when every material in-scope coverage item has an explicit disposition and the resource mapping leaves no material user-visible design decision for the implementer to invent. Honest `decision-required` or `unavailable` items may stop further generation, but the result is a blocked authoring outcome: it cannot pass shared preflight, be called a ready implementation handoff or authorize fidelity work. This does not claim Design Authority or implementation acceptance.
+- For an implementation handoff, stop only when every material in-scope coverage item and every supported observable fact in the selected resources has an explicit inventory/disposition, every resource has a complete inspection closure, and the mapping leaves no material user-visible design decision for the implementer to invent. An exact target also needs full-target layout and pixel facts for every declared condition. Honest `decision-required` or `unavailable` items may stop further generation, but the result is a blocked authoring outcome: it cannot pass shared preflight, be called a ready implementation handoff or authorize fidelity work. This does not claim Design Authority or implementation acceptance.
 
 During iteration, keep accepted, rejected and unresolved implications in a task-local delta buffer. Do not require or emit an interim delta after every iteration and never continuously synchronize the initial proposal. After explicit human selection or explicitly delegated selection, consolidate the buffer once and reconcile only accepted decisions into the initial proposal. If it is a writable file, update it in place while preserving original intent/provenance; otherwise return one complete revised proposal. The operation must be idempotent, name selected artifact locators/hashes and affected stable keys, and exclude rejected/unresolved choices. Never write a Source Plan, Context, `DESIGN.md`, code, tests or Contract.