project-tiny-context-harness 0.8.13 → 0.8.17

package/assets/README.zh-CN.md

@@ -8,7 +8,7 @@ Project Tiny Context Harness 是给 AI coding agents 用的轻量项目记忆层
 
 ## 为什么存在
 
-编码 Agent 同时需要两类能力：跨会话仍然可靠的少量项目事实，以及在交付确实需要时可恢复、可审计、可机器复验的完成检查。
+编码 Agent 同时需要两类能力：跨会话仍然可靠的少量项目事实，以及在交付确实需要时可恢复、可审计、可机器复验的完成检查。Tiny Context 的设计目的，是通过可恢复的真实归属和与交付需要相称的保障，减少大方案、耐久项目事实、设计意图、实现与证明之间的漂移；这不是未经基准验证的效果声明。
 
 Tiny Context 将这些能力保持为窄边界。两条实现路径共用一次实现前、风险比例化的 Architecture Deliberation 与适用质量路由，实施过程保留 Goal 自主但遵守边界型实现质量 guardrails，项目验证后只由一个 carrier 对当前候选执行包含 Architecture Conformance 的 Engineering Quality Conformance。
 
@@ -74,8 +74,8 @@ ty-context enable 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，也不要求经过独立的中间 authoring 阶段。
-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 必须在实现前无条件结束当前回合，并输出 `处理好模型更换之后，请发送【继续】。`。此前任何模型策略文字都不能跳过该边界，Harness 也不能观察模型是否真的改变。用户恢复后，父 Goal 执行内部 Delegation Suitability 判断；只有宿主显式选择精确 `long_task_implementation` 时才把独立有界工作交给它，否则不启动 generic 替代项而由父 Goal 执行。Authority、架构、Context、集成、当前候选检查与正式验证始终由父 Goal 持有。
+4. **生成并选择设计资源。** 选择 `$design-resource-authoring`，传入初始方案路径、精确开发范围和目标。正式 Web/App 工作会先读取真实技术 Source，再输出一份完成一次性回改的修订方案、选定的不可变规范资源及其 manifest/dependencies、独立 implementation-feasibility input，以及通过校验的残余 `design-resource-handoff-v1`。
+5. **启动 Single-Goal 交付。** 选择 `$long-task-workflow`，传入修订方案、已校验 handoff、implementation-feasibility input 和选定规范资源集合的精确路径。该 Skill 会建立 Source-bound Contract Draft；第一次 Compile/Authority Lock 必须在实现前无条件结束当前回合，并输出 `处理好模型更换后，请仅回复：模型切换卡点解除，继续`。普通“继续”不满足 managed prompt protocol；此前任何模型策略文字都不能跳过该边界，Harness 也不能观察下一条宿主消息或模型是否真的改变。用户恢复后，父 Goal 先识别合格的有界工作包，再判断 profile/capacity；没有用户或宿主显式禁止时，合格集合必须实际调用多个精确 `long_task_implementation`，由宿主结果进入六理由 zero-start 或 partial delegation。数量保持动态，禁止 generic 替代项；Source、Contract、Authority、架构、Context、工作包选择、集成、当前候选检查、正式验证、Final Gate、close 与 completion 始终只由父 Goal 持有。
 
 一组可以直接改写使用的调用顺序如下：
 
@@ -84,9 +84,9 @@ $design-system-authoring 为这个 style-bearing 范围生成、选择并采用
 
 为 <交付范围> 在 docs/initial-proposal.md 准备一份可写、项目原生的初始方案。
 
-$design-resource-authoring 使用 docs/initial-proposal.md，覆盖 <精确开发范围和目标>。返回完成回改的方案路径、通过校验的 design-resource-handoff-v1 路径，以及选定的不可变规范资源、manifest 和 dependency 路径。
+$design-resource-authoring 使用 docs/initial-proposal.md，覆盖 <精确开发范围和目标>。返回完成回改的方案路径、通过校验的 design-resource-handoff-v1 路径、implementation-feasibility Source 路径，以及选定的不可变规范资源、manifest 和 dependency 路径。
 
-$long-task-workflow 将 docs/initial-proposal.md、<handoff.md> 以及选定的规范资源、manifest 和 dependencies 作为 Source，完成一次完整实现交付。
+$long-task-workflow 将 docs/initial-proposal.md、<handoff.md>、<feasibility.json> 以及选定的规范资源、manifest 和 dependencies 作为 Source，完成一次完整实现交付。
 ```
 
 上面的路径只是示例，不是固定目录。候选图片或可编辑探索本身不构成保真实现权威；下游实现使用选定的不可变规范资源及其已校验 handoff。
@@ -179,6 +179,8 @@ Shared Engineering Quality 在不增加工作流的前提下扩展原有架构
 
 实现顺序、方法和反馈节奏仍由 Goal 决定。轻量纪律只要求复用 owning service/facade/adapter 与唯一 source of truth，做最小而完整的变化，保留明确 failure/resource 语义，并仅为稳定概念或有证据的变化轴增加抽象。精确产品/技术谓词继续由 Semantic Facts 拥有，精确选定 UI/UX 值由 selected-design closure 拥有。
 
+`context_development_engineer` 按任务实质而不是通用编码动词触发：只有 material 的 owner/source-of-truth、architecture/dependency、API/schema/data/state/lifecycle、复杂替代、concurrency/recovery、external integration/shared abstraction、performance/security/compatibility/migration 或 architecture audit 判断才加载按需工程推理；单凭 implement/fix/refactor、角色/agent 字样以及普通局部代码、测试、文档或样式工作不会触发。reference 会区分事实/约束/假设/未知、驱动与路径依赖、材料性替代、反证和最小实验，再把决策投影到具体 owner、接口、data/state/lifecycle/failure 与检查；它不是强制方法清单或第二工作流。
+
 实现和项目验证之后，`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 不自动扩张任务范围，但本次触达、依赖或加重的债不能隐藏。
@@ -191,7 +193,7 @@ Harness 只路由仓库原生 type/compiler/lint/AST/dependency/contract/behavio
 
 ### 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。
+`context_surface_contract` 继续使用现有 `contract`、area/subdomain 和 verification 角色。`product-surface-contract.md` 负责跨页面、主层/下钻与共享职责；可选且按需读取的 `screen-contract.md` 还负责单屏 target user/usage context 引用、主任务结果/工作对象/闭环、operation-object-feedback 关系、必须持续可见的关键上下文、entry/exit/shared state、信息层级、语义区域、重复滚动/上下文切换边界、client/size-class topology、导航/变体、material controls 和 target/verification 引用。`context_uiux_design` 可以为 material 的新页面/流程/复杂控件、层级/拓扑、任务反馈、客户端适配、恢复/状态/无障碍或 UI/UX 审计加载非权威任务分析，但其 durable owner 仍只有 Design Authority，页面职责仍归 Surface/Screen Source。分析或 Skill 激活本身不授权写入；只有产品/UI 实现已经获准且当前 Goal 独立判断 `Context Delta: required` 时，才更新最小 Surface owner。局部 CSS/文案/icon/image、exact-target 局部对齐和单控件预览仍保持轻量。
 
 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 或实现截图不能静默胜出。
 
@@ -211,12 +213,18 @@ Long-Task Source authoring 必须完整索引 material 请求片段、附件、c
 
 ### 视觉交付指导
 
-两种开发路径共享选定设计 Source 权威，但不共享形式化证明等级。正式 handoff 仍必须提供机器可读的完整输入并通过精确 preflight；默认路线随后打开受影响 target/condition，路由到生产 owner 和最终候选项目检查，并报告未被检查建立的条件；Long-Task 额外提供逐 Fact/Rule 的精确机器闭包。两者都不授权从静态图推断未表达交互，也不能证明用户没有遗漏要求。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 只能作为派生视觉基线，不能成为唯一实现源。
+两种开发路径共享选定设计 Source 权威，但不共享形式化证明等级。正式 handoff 仍必须提供机器可读的完整输入并通过精确 preflight；默认路线随后打开受影响 target/condition 与真实载体 feasibility Source，在 Architecture Deliberation 中选择生产策略，再路由到最终候选项目检查并报告未被检查建立的条件；Long-Task 通过现有 Source、binding 与唯一 Final Gate 额外提供逐 Fact/Rule 的精确机器闭包。两者都不授权从静态图推断未表达交互，也不能证明用户没有遗漏要求。Open Design 有能力输出实现级 HTML/CSS/JS、spec、token 与 asset，但“有能力”不等于每次都产出：选定 Web/App 实现 handoff 时，`design-resource-authoring` 必须显式委托并完整取得一个机器可读 canonical entry 及其精确 dependency closure，逐文件冻结 digest，并暴露稳定的 typed locator；正式发布前，还要在这些不可变字节上逐项执行声明的 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 推断其他适用组合。
 
+正式 Web/App handoff 还为每个 target 索引一份独立的 `design-resource-implementation-feasibility-v1` JSON Source。它记录当前 platform、framework/runtime、UI system、token/theming adapter、component-owner roots 与 route-owner roots；非 observed disposition 必须给出理由，不能伪造值。每个 material component-family × target × condition profile 必须精确绑定完整匹配的 V1 Fact 或相交的 V2 Rule 集，并提供一条或多条同时有 capability/feasibility Source 支撑的 reuse/compose/extend/theme/create 候选，或显式 blocker；组合多个 Primitive、按平台使用不同候选和已授权 planned owner 都合法。仅有 Browser 能力时不能冒充 native-App/React Native substrate。精确视觉值仍只属于 canonical resources，也不得塞入 feasibility 自由文本；没有独立 technical authority 时，DRA 不能指定 required production realization。V1 使用精确 condition partition，Symbolic V2 使用 reachable、互斥且穷尽的 regions。新 V1 bundle 发布要求该输入；direct preflight 继续读取 legacy implementation handoff，并在缺失时明确报告 `technical feasibility not declared`，而 `reference` target 可以如实省略且不产生该限制。
+
+未决 substrate observation 是 target-wide 事实，而不是抽样信息：每个 `decision_required` 或 `unavailable` observation 都必须由每个 material family × condition cell 的精确 blocker 引用，blocker 与 marked-Source projection 的 observation-ref 集必须完全一致，零 family 时也不能真空通过。带候选的 cell 必须有 observed component-owner roots。精确动效时间或语义不明的时间值仍归 canonical resource；明确的 build/compile/test/startup/latency/timeout/network/benchmark/runtime-cost 时长可以作为技术 feasibility 文本。
+
+Long-Task 消费时，系统会逐条证明每个 `file`/`path_glob` target 与 carrier、每个 `verified` carrier、以及每个 planned 非空 carrier 完全位于 observed component/route roots 内；部分匹配或无法证明都失败。独立 Contract 结构校验仍拒绝空 component refs。只有完整 activation 调用可以暂缓这一条，并且仅在整个 surface 的 target 全部为 blocker-only、route 与精确 blocker 闭包有效时通过；candidate、mixed、legacy、缺失 feasibility 和伪 component binding 都失败。开放的 target-blocking External Confirmation 只能到达 `blocked_external`，不能 `machine_accepted`，也不会增加或改变唯一 Final Gate。
+
 `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 只保留读取兼容。UI symbolic V2 仍是显式 opt-in，V1 仍是默认；V2 可以保留旧式精确 remainder rows，也可以用 package-owned property profiles、冻结 Inspector custom-property closure 和唯一 instance exceptions 消除物理 N/A 矩阵，但每个逻辑 subject-property 点仍必须得到唯一 disposition。Rule 省略轴时，Source-side 与 production-side 都必须由冻结闭世界静态依赖闭包、受限 IR 精确等价或有限完整域真实穷举等价之一证明；动态加载、反射、未冻结隐式输入、外部设备、代表点与抽样均阻断。`exact_target` 的每个适用 condition 还必须分别闭合 full-target layout 与 pixel Facts。preflight 会在不可变本地资源上解析 manifest 与全部 typed locator，校验 dependency/Census/Fact/proof closure，并拒绝 missing、duplicate、unresolved、unsupported、stale、media 不兼容或数值冲突；探索候选仍不需要 schema。
 
 每一种 non-interference 方法都必须使用带 digest 的 frozen executable Oracle，并声明精确的 `symbolic_noninterference.<side>.<method>` capability。Source 侧的完整 Inspector 输入集合必须为每个 admitted scope 包含唯一、canonical、无执行能力的 `design-resource-symbolic-source-ir-v1` 资源；package 将它绑定到当前 target、certificate 与 Rule scope，重新解析当前 bytes，并自行派生 dependency DAG、canonical predicate 或有限完整域逐点结果。提交的 graph/root、side/axis-erased predicate、evaluation claim 与 passed verdict 只是 Oracle 输出缓存；preflight 强制 `当前复算 = artifact bytes = proof binding/cache`，且 artifact 不进入语义输入闭包。因而静态证明不能由轴列表自证，也不能从 Rule refs 反造 Source graph。JavaScript、CSS cascade/隐式 DOM、可执行 template、dynamic load/fetch/import、reflection、computed access、未冻结扩展和外部 runtime/device dependency 在存在 package-owned 完整 extractor 前全部阻断；production 侧继续只接纳 package 可完整解释的静态 HTML 与 inert JSON 子集。两侧都绑定 Oracle implementation closure/version/capability、environment、每个输入的 path/declared/current digest、当前 Source-manifest 或 production-target snapshot、精确 Rule/certificate scope、omitted axes、派生 method result、artifact path/digest 和可归因 failure witness。两侧 proof digest 进入 certificate identity，并在存在省略轴时进入既有 Contract expectation/current Final-Gate result；admitted 表示之外的抽取正确性保持为明确 TCB 边界。
@@ -229,7 +237,11 @@ provider-neutral handoff 是残余语义与绑定层，不是 CSS 文本副本
 
 只要是已经选定、准备进入实现的设计资源，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 把每个受影响的 selected target 和声明 condition 追踪到生产 route/component owner、冷启动真实用户旅程及适用的渲染/交互检查。第一个有价值的可运行纵向切片只是建议性的真实入口反馈点，不是实现门禁；最终候选仍必须重跑受影响的冷启动旅程。Source 已明确要求的组合不能静默删减，但默认路线应报告未被证据建立的条件，而不是声称精确机器闭包。资源哈希、manifest 和数量只证明资源完整性，实现截图既不能成为自己的目标，也不能单独证明实现一致性。
+Long-Task 投影继续要求每个 Claim-bearing Assertion 只绑定一个 Claim。对每个 selected-design verification method，target 的 root conformance Assertion 与该方法的独立 Assertion 以并集覆盖其 Fact/Rule 引用的 Source Claims；该并集只补齐覆盖，不合并方法 capability、证据、结果或失败归因。
+
+repository pattern 只把圆括号作为经过转义的 route-group 字面字符，不把它们解释成正则分组或 extglob；现有 `*`、`**`、`?` 语义保持不变，`[]`/`{}` 仍不受支持。
+
+对 material 工作，`context_uiux_design` 在默认路线和有效 Long-Task 绑定下都可用非权威 task-level UI/UX analysis 比较候选，并保持 durable Design Authority owner 不变；Product/Surface/Screen Source 继续唯一拥有页面职责与信息/操作/反馈/交互拓扑，`DESIGN.md` 和 selected exact-target/constraint Source 则拥有视觉系统及选定设计事实。有效 Long-Task 绑定下，`long-task-workflow` 仍唯一拥有 Source/Contract 生命周期、正式验证、Final Gate 和完成权；UI/UX Skill 也可贡献 Design Authority closure，但不创建第二计划、生命周期、Authority、Gate 或验收路径。`context_development_engineer` 用稳定 surface/control key 把每个受影响的 selected target 和声明 condition 追踪到生产 route/component owner、冷启动真实用户旅程及适用的渲染/交互检查。候选若与 controlling Product/Surface/Screen/Design Source 冲突，就不能进入资源生成或实现，必须先在已有授权下更新 stale owner，或返回 genuine decision-required。第一个有价值的可运行纵向切片只是建议性的真实入口反馈点，不是实现门禁；最终候选仍必须重跑受影响的冷启动旅程。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。只有 package-admitted observer 能提供匹配的 `fact_results` Actual/comparison row。当前 slice 中，项目 `design_conformance`、`design_method` 与 `fact_results` record 只作诊断；受影响的 UI/design obligation 必须保留阻断性 External Confirmation，不能成为 machine proof。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 权威。
 
@@ -237,7 +249,7 @@ combined design-and-implementation 可以先用普通 Outcome/Stage 生成候选
 
 `ty-context doctor` 保留兼容的项目级 `missing | unconfigured | configured` 状态，并增加 Design Authority Index、token source 和已分类 reference 的 advisory 信号。它明确不推断页面实现就绪；material surface 仍需 owning Screen/Control meaning、selected target/constraints 与项目自己的验证路径。
 
-静态 guidance 测试只能证明分发、投影与 canonical ownership 文案存在，不能证明 Agent 实际恢复了全部 UI/UX 信息。可选 delivery-mechanism benchmark 提供固定 fresh-agent UI/UX Context/target recovery task、routing gold 和隐藏 production oracle；只有独立配对运行才可以支持 effectiveness/ROI 结论。
+静态 guidance 测试只能证明路由文案、正负分析规则、分发、投影与 canonical ownership，不能证明宿主真实激活了 Skill、Agent 遵循程度、地图设计质量、运行成本、性能或 ROI。可选 delivery-mechanism benchmark 提供固定 fresh-agent UI/UX Context/target recovery task、routing gold 和隐藏 production oracle；只有独立配对运行才可以支持 effectiveness/ROI 结论。
 
 ### 显式 Design System Authoring
 
@@ -249,11 +261,13 @@ combined design-and-implementation 可以先用普通 Outcome/Stage 生成候选
 
 只有在用户明确要求生成、迭代、准备独立设计资源、为一段明确开发内容准备设计资源或使用 Open Design 时，才使用 `design-resource-authoring`。输入可以是零散笔记或初始方案、产品/技术方案、专门视觉 brief、截图、已有资源或其他已有计划文档。独立的中间 authoring 文档不是前置项，也不再是推荐步骤。
 
-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。局部功能只可带上定位它所需的周边上下文；再丰富的背景也不能把生成范围扩成页面其余部分或整个产品。生成 page/flow/complex control 之前，必须分别消费：controlling Product/Surface/Screen Source 中的 target user/context、client/host、页面职责、主任务结果、主工作对象/任务闭环、operation-object-feedback 以及适用的 state/recovery/accessibility 含义；`DESIGN.md` 和 selected exact-target/constraint Source 中的视觉系统及选定设计条件。非权威 task-level UI/UX analysis 只能帮助比较候选，不能提供缺失的产品或 Surface 含义；Provider 也不得从功能列表、截图、route tree、component inventory 或 analysis output 发明这些含义。面向实现 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`。
+
+在 ceiling 内，DRA 会记录已有选定资源的覆盖、新缺口和 preservation 义务。发现 ceiling 外影响时只返回现有 `decision-required`，理由为 `scope-expansion-required`；只有用户可以扩大 ceiling。需要改变耐久 Product/Surface/Screen/Design 含义时，必须先更新真实 owner，重新读取后再恢复生成。style-bearing commission 只携带确有 Source 的 `style_application` 字段，并增加按资源 archetype 定义的 `quality_commission`：主要设计挑战、希望/避免的视觉特征、真实 copy/data、每个参考的角色，以及设计侧 shared-family reuse。它们只是任务局部 Provider 输入，不是文件、状态、分数、Authority 或 routing record。
 
 正式首次生成、重大设计修订和关键重新生成使用实时发现后满足工具、视觉/上下文能力、认证与数据边界的最高能力模型，以及该模型实际支持的最高 reasoning effort。排序只能依据 provider 明确的能力等级、推荐替换关系或唯一且有版本依据的 provider-local fallback；不得从价格、模型名、发布时间或列表顺序猜测。多个 eligible model 无法排序时以 `highest_performance_unverified` fail closed；provider 不可控制或不能回报实际 model/effort 时也必须保留同一限定，不能声称已执行最高档。该策略不创建 model registry、scheduler 或持久 routing state。
 
-正式 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 义务，并读取真实技术 Source 中的平台、framework/runtime、UI system、token/theming adapter、component owner 与 route owner；随后按资源 archetype 匹配实时 Provider 能力，把这些约束连同已采纳 design-system identity 一起传给 Open Design，并要求返回的 canonical source/manifest 表达每个适用 cell。Skill 另行生成上述 feasibility Source，每个 material family/condition 必须有候选或 blocker，而 production-owner 选择仍归下游；不能等下游实现时才发现或自行补设计 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` 验证一致。
 
@@ -261,13 +275,15 @@ Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）
 
 面向 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 只做一次合并、幂等的初始方案回改，并在任意获准的项目路径按 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 或验收结果。除唯一被明确授权的 Proposal 写回目标外，Skill 不会修改调用方已有计划/提案 Source、`project_context/**`、`DESIGN.md`、生产代码或 Delivery Contract。
+Provider execution、Artifact readiness 与 Design suitability 保持分离。正式高保真工作至少检查一次真实渲染；Suitability 会按意图深度检查 scope/Source、机械完整性、Design-System 应用、visual craft/language、产品辨识度、内容真实性、设计侧组件复用、技术可实施性、state/condition 覆盖和 preservation。首个候选没有 material grounded defect 时可直接进入选择；存在缺陷时只修最高影响问题的最小范围，然后重新渲染并重审受影响项，不设美容式修订次数。它不能替代人工选择，也不能单独产生 readiness。持久依赖的 Provider 行为必须固定到 immutable version/tag/commit，而不是浮动 branch。
+
+探索模式只做最小完整性检查并尽快展示指定候选，不需要 handoff schema。`Design Resource Review & Selection Stop` 允许用户修正、选择、拒绝、保留未决、扩大范围或路由耐久 owner 变化；它不是批准记录、Gate、验收或正式完整性声明。普通对话式选择不创建持久状态；需要确定性跨中断恢复时，只复用现有 marked Source、authority、selected-source 和 recovery checkpoint owner。选择身份绑定 canonical selected-source digest、target、声明 conditions 以及 controlling Source/Design-Authority identity；被证明等价的派生导出不会使选择失效，可见或语义差异则回到 suitability 与审查。选定 formal Web/App 方向完成 canonical source/dependency/Census/manifest/preflight 闭包后，任何新可见决定都返回同一停点；只有稳定闭包之后才做一次合并、幂等的初始 Proposal reconciliation 并生成 provider-neutral marked handoff。共享 preflight 不能把取得不完整、不可寻址、`decision_required`、`unavailable`、证据不成立或过期的输入称为 ready。除唯一被明确授权的 Proposal 写回目标外，Skill 不会修改调用方已有计划/提案 Source、`project_context/**`、`DESIGN.md`、生产代码或 Delivery Contract。
 
 材料性的 DRA 修订循环只从绑定 raw-byte digest 的 Base 与完整有序 Delta 语义重放。确定性 accepted authority 还必须在同一个、受文本 digest 覆盖的 marked Source Item 内提供严格 `ty-dra-authority-v1` 投影：explicit choice 精确绑定 target/kind/origin/meaning digest，delegation 只绑定其选择范围，绝不会自动成为非视觉 meaning Source。每个 semantic target 最多只有一个 active accepted Delta owner；rejected、unresolved 与 superseded Delta 组成精确 leakage 全集。单一 v3 audit-expectations catalog 冻结 changed/unchanged/resource-decision/blast-radius/leakage rows 与 selected-resource conditions，当前审计必须 set-equal 且不得有重复 identity。exact-patch-v2 把每个 active non-preserve `Delta × target` 恰好一次绑定到 Proposal 文本区间与语义 digest；每个 binding 恰有一个 `proposal-written` owner，或一个结构化且仓库可读取的 `resource-owned-exact-visual` owner。只有真实跨中断需求才可显式 `create` 一个 ignored、任务局部、非权威 checkpoint；`update` 只能通过调用方给出的 checkpoint digest CAS 替换，`inspect`/`preview` 重新派生当前状态。`apply` 使用写前/写后 raw-byte CAS 与写后重读对账，只报告 applied、idempotent、blocked 或 external-resource revalidation pending，而不报告 handoff readiness。`remove` 仅在目录清单证明其中只有 digest 匹配的 helper checkpoint 时完整删除；否则返回 `partial` 并保留非 helper 内容。简单 preview 不创建 checkpoint、持久字节、暂停、Provider run、正式 handoff、Proposal 写回或 helper transaction。checkpoint 与 reconciliation 只是上游恢复/诊断数据，绝不是 Design Authority、Long-Task Source/Evidence 或完成证明。
 
 实际生成仍由已配置的 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，不能自我授权为目标。
 
-维护者可以设置 `TY_CONTEXT_OPEN_DESIGN_MCP_COMMAND` 与可选 `TY_CONTEXT_OPEN_DESIGN_MCP_ARGS_JSON`，运行 `npm run smoke:open-design` 做显式启用、只读的 discovery smoke。正常测试使用本地 mock MCP，不依赖 Open Design、登录、付费能力或不确定的设计输出。
+维护者可以设置 `TY_CONTEXT_OPEN_DESIGN_MCP_COMMAND` 与可选 `TY_CONTEXT_OPEN_DESIGN_MCP_ARGS_JSON`，运行 `npm run smoke:open-design` 做显式启用、只读的 discovery smoke。现有 delivery-benchmark owner 还包含一个 opt-in DRA visual diagnostic：8 个固定 case、5 条固定身份 route、随机盲评与重复的描述性观察；它不影响 admission、发布、排名、路由或设计选择。正常测试使用本地 mock MCP，不依赖 Open Design、登录、付费能力或不确定的设计输出。
 
 ### 退役独立 Authoring 兼容
 
@@ -281,8 +297,8 @@ Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）
 - 一个用户选定的仓库与最终验证/收敛 worktree；
 - 一次完整选定交付、一个 Contract、一个 Final Gate；
 - Outcome 依赖只表示验收与中间证明就绪关系，不限制实现顺序，也不表示 Worker 调度；
-- 第一次 Authority Lock 后、正式实现前有一次无条件的宿主模型更换检查点；Agent 结束当前回合，用户处理后发送普通“继续”，Harness 不观察或验证模型是否改变；
-- 当前 Goal 自主选择实现顺序、局部计划、工具，并可按 ROI 选择单 agent 或多开平台原生 agent/subagent；Harness 不负责分配、调度、重试或恢复，agent 报告不是 Progress 或证明，所有结果必须汇入同一验证 worktree；Frontier 只提供验收/验证建议；
+- 第一次 Authority Lock 后、正式实现前有一次无条件的宿主模型更换检查点；Agent 结束当前回合，用户处理后只回复 `模型切换卡点解除，继续`，普通“继续”不满足 package-managed prompt protocol，Harness 不观察或验证模型是否改变；
+- 当前 Goal 自主选择实现顺序、局部计划、工具、具体工作包分解与动态 Worker 数量；满足正向默认谓词时必须实际调用多个精确 `long_task_implementation`，否则声明一个许可的 solo 理由并由父 Goal 执行。Harness 不负责分配、调度、重试或恢复，agent 报告不是 Progress 或证明，所有结果必须汇入同一验证 worktree；Frontier 只提供验收/验证建议；
 - targeted verify 是可选反馈与修复证据，永远不能 accepted，也不构成继续实现或进入 Final Gate 的门禁；
 - scope-only revision 可先做无状态候选诊断，机械边界内的修复自动采用；只有稳定且确需用户决策的候选才至多询问一次精确 identity；
 - Final Gate 在一个当前快照上重跑全部 Check；
@@ -290,7 +306,7 @@ Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）
 
 它的证明命题有明确前提：Source 在声明观察粒度下完整且准确、Source→Contract 投影保持语义、所有实际适用单元被展开；在这些前提下，只有每个机器义务同时具有冻结 Expected 权威、package-admitted 当前 Actual、Harness 计算的 comparison/verdict、可归因静态生产载体或直接 process observation、因果 Counterfactual 与当前 Final Gate 快照证明时，fresh `machine_accepted` 且无待定 External Confirmation 的 `AcceptedDeliveryTerminal` 才推出声明内机器可观察漂移为空。`machine_accepted_external_pending` 只证明已准入机器范围，完整交付仍未完成。Harness 无法发现未声明要求，也不声称任意物理/外部观察绝对可靠。
 
-Compile 为每个机器 Claim 或 Fact × required-method obligation 派生内部 `CompiledObservationAuthority`，它不是新的 Contract Authority、状态或 registry。首版只有两条机器路径：`package_static_json_exact` 读取 runner 前快照中已存在、runner 后 no-follow 文件 identity/digest 不变、匹配生产 Binding 且不属于 Source/Context/Contract/expected/evidence/report/status/verifier output 的 UTF-8 JSON 静态结构；prepare-all mutation observation 与逐文件 pre/post identity/hash 共同拒绝 transient/persistent swap，它只证明静态内容，不证明运行时消费。`package_process_json_exact` 只支持 Source-backed 的 `runtime_family: process`、`role: product` 目标，以及 target 和完整 argv 与该权威一致的直接 root `project_binary`。每个 required target 都由一项 canonical Source technical obligation 精确覆盖 key、role、family、root、完整 argv 和 capabilities。Compile 生成声明稳定的 process runtime closure：精确 Source-backed root、当前 Claim/Counterfactual production carriers，以及由有限 argv→production Binding 匹配得到的路径。匹配只读取独立参数或显式 `--key=value`，从声明 `cwd` 规范化安全仓库相对路径，并要求 exact 或 pattern Binding 覆盖结果；glob 与无扩展名文件都受支持。未匹配的安全相对值被忽略且不复制；绝对路径、仓库逃逸、`file:` URL 与网络 URL fail closed，除非其语义被显式转到既有 external TCB/External Confirmation 边界。Compile 不广域扫描或复制全部 `input_paths`，角色分离只检查实际 closure 成员。Global Check 将 Outcome Binding 投影成内部 `{ outcome_key, local_key, binding_ref, binding }`，并复用 `<outcome>.<binding>`：逻辑 ref 保持独立，相同物理路径可只复制一次，不改变 authored Contract 或建立 registry。Exact planned closure member 可以到 Final Gate 才 materialize。Harness 仅复制这份 closure，并把其 identity 绑定到 host attestation。兼容的 Cross-Check 与 implicit-preserved Facts 共享一个受限 stdout `ty-context-product-observation-v1` envelope，同时保留独立 result identity。无法显式 production-bind 的嵌入式依赖或无法直接绑定 root 输出面的 Claim 必须 External Confirmation。项目 payload 继续使用 v3，不发布 v4，也不建设通用 UI/native observer 或语言依赖解析器。
+Compile 为每个机器 Claim 或 Fact × required-method obligation 派生内部 `CompiledObservationAuthority`，它不是新的 Contract Authority、状态或 registry。首版只有两条机器路径：`package_static_json_exact` 读取 runner 前快照中已存在、runner 后 no-follow 文件 identity/digest 不变、匹配生产 Binding 且不属于 Source/Context/Contract/expected/evidence/report/status/verifier output 的 UTF-8 JSON 静态结构；prepare-all mutation observation 与逐文件 pre/post identity/hash 共同拒绝 transient/persistent swap，它只证明静态内容，不证明运行时消费。`package_process_json_exact` 只支持 Source-backed 的 `runtime_family: process`、`role: product` 目标，以及 target 和完整 argv 与该权威一致的直接 root `project_binary`。每个 required target 都由一项 canonical Source technical obligation 精确覆盖 key、role、family、root、完整 argv 和 capabilities。Compile 生成声明稳定的 process runtime closure：精确 Source-backed root、当前 Claim/Counterfactual production carriers，以及由有限 argv→production Binding 匹配得到的路径。每个 `root_argv` 数组成员始终是 child-visible exact token；分类器不拆空格、不去引号、不重写反斜杠。封闭语法只检查独立 token 或一个显式 `--name=value`，支持的 standalone switch 是 label，其他 compound form 不获得机器闭包；raw token 与派生 locator 分离。quote、POSIX/UNC absolute、drive-prefixed、slash/backslash 平台歧义、除精确小写十进制 `node:<number>` 外的所有 scheme-shaped colon prefix 和 unsupported compound 在执行前 fail closed，除非显式转到既有 external TCB/External Confirmation。parent segment 先结合声明 `cwd` 解析，再判断是否真实越出仓库，因此仓库内 `..` 合法，真实 escape 才失败。exact/pattern Binding 支持 glob、无扩展名和含空格单 token 文件；安全 unmatched 以及精确小写十进制 `node:<number>` 和纯数字 `<hours>:<minutes>` 两种 colon scalar 允许但不复制。Compile 不广域扫描或复制全部 `input_paths`，角色分离只检查实际 closure 成员。Global Check 将 Outcome Binding 投影成内部 `{ outcome_key, local_key, binding_ref, binding }`，并复用 `<outcome>.<binding>`：逻辑 ref 保持独立，相同物理路径可只复制一次，不改变 authored Contract 或建立 registry。Exact planned closure member 可以到 Final Gate 才 materialize。Harness 仅复制这份 closure，把其 identity 绑定到 host attestation，并把未修改的 raw argv 传给 child。兼容的 Cross-Check 与 implicit-preserved Facts 共享一个受限 stdout `ty-context-product-observation-v1` envelope，同时保留独立 result identity。无法显式 production-bind 的嵌入式依赖或无法直接绑定 root 输出面的 Claim 必须 External Confirmation。项目 payload 继续使用 v3，不发布 v4，也不建设 shell/URI/dependency parser 或通用 UI/native observer。
 
 项目自报的 v3 actual/value digest、comparison、`passed`、verdict 与 capability record 只作兼容诊断，不能提供 Actual 或完成权威。当前 package 可派生范围只有 exact/presence 与 host-derived `target_runtime`；`interaction_trace`、`state_delta`、`design_conformance` 以及其他尚无 package derivation 的 capability 即使有项目 record 也必须保留阻断性 External Confirmation。custom/`named_external_tcb` Oracle、间接 wrapper、browser/native/device session、layout/pixel/accessibility/motion、protected observation、tolerance/mask 与 custom locator 同样不能关闭 machine obligation。每个机器 Counterfactual 都要有 package-admitted baseline/mutated observation、相同 compiled closure identity、属于 production carrier 集合的 mutation target、affected/preserved/allowed-fan-out 精确集合与相同 obligation universe，并在适用时保持 host-derived process liveness；没有 admitted observation 时不得跳过。旧 Contract 不会被静默改写，target/closure TCB 变化会使旧 Active Authority、Progress、Evidence 与 Receipt 失去验收效力。
 
@@ -310,34 +326,44 @@ Direct-process observer 提供的是受限 containment，不是针对恶意代
     "required": true,
     "phase": "post_authority_lock_pre_implementation",
     "action": "change_model_in_host_then_continue",
-    "resume_token": "continue",
+    "resume_token": "model checkpoint cleared, continue",
     "turn_boundary": "end_current_turn",
     "blocked_until_resume": ["product_implementation", "file_edits", "build", "test_execution"],
     "model_change_owner": "host_or_user",
     "model_change_observable_by_harness": false,
-    "generic_continue_satisfies": true,
-    "message": "处理好模型更换之后，请发送【继续】。"
+    "generic_continue_satisfies": false,
+    "message": "处理好模型更换后，请仅回复：模型切换卡点解除，继续"
   }
 }
 ```
 
-这是无条件的终止当前回合边界。Agent 在该结果后不得继续产品实现、文件编辑、构建或测试，必须输出 `处理好模型更换之后，请发送【继续】。` 并结束当前回合；用户此前写过任何模型策略都不能跳过。之后用户发送普通“继续”即可恢复，Harness 不观察、不验证宿主模型是否改变。后续 `compile --revise` 返回 `required: false`，不会重复暂停。Harness 不会自动切换模型，也不持久化 acknowledgement、model route 或 checkpoint state；该检查点不是验收证据。
+这是无条件的终止当前回合边界。Agent 在该结果后不得继续产品实现、文件编辑、构建或测试，必须输出 `处理好模型更换后，请仅回复：模型切换卡点解除，继续` 并结束当前回合；用户此前写过任何模型策略都不能跳过，普通“继续”不满足 managed prompt protocol。它仍是人工宿主提示，不是 Harness 强制执行的解锁：Harness 不观察下一条宿主消息，也不验证模型是否改变。后续 `compile --revise` 返回 `required: false`，不会重复暂停。Harness 不会自动切换模型，也不持久化 acknowledgement、model route 或 checkpoint state；该检查点不是验收证据。
 
-锁定后的修订把“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，并返回滚动实现，绝不表示完成。
+锁定后的修订把“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，风险降级直接拒绝。verifier 内容 identity 变化会使旧证据失效；没有旧 Authority 或可信发布来源提供的独立保持证明时仍保持 fail-closed，但 digest 变化本身不再被误报为已经证实的 acceptance/proof reduction，brief 会列出变化文件并明确“语义保持尚未独立建立”。`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 承载点，只证明该声明、项目检查绑定的集合。
 
-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。
+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 实现、检查或返工，并应用上述正向默认精确 Worker 规则；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、完整 root argv 和显式 capabilities。每个 required target 还必须通过 Source Claim disposition 映射到一项相同 identity 的 canonical Source technical obligation；process root 与有限 exact/pattern 匹配实际准入的每个 argv 路径同时属于 production owner 与 production Binding。Compile 只从 root、已匹配 argv 路径与必需 carriers 生成声明稳定的 runtime closure，不复制或广域扫描全部 `input_paths` 或 manifest sibling。安全但未匹配的相对参数不是依赖；绝对、逃逸、file-URL 或网络引用 fail closed，除非显式进入外部边界。已匹配路径可以是 `planned` 并在 Preflight/Compile 时尚不存在，但 Final Gate 必须在当前 candidate 中看到它们；仅 materialize 不改变 Authority identity。Web/process 代理不能代替单独要求的 Native/desktop 目标。当前机器 `target_runtime` 只有 Harness 直接启动该 Source-backed process product root 才能成立；browser/native/desktop/device 要求保留阻断性 External Confirmation。每个 `critical_user_path` Outcome 和 Stage gate 都必须通过 admitted root proof 或对应 External Confirmation 处理每个 required target。
 
 如果声明结果可能在代理表面通过、却在目标运行时独立失败，最早 owning Outcome 必须使用 admitted direct-process root Check 或阻断性 External Confirmation。项目 payload、仓库内状态报告、截图、二进制、日志、历史运行、新 session id 和代理表面都不是 runtime Authority。Check 仍声明精确 Given/When、journey 与 applicability，所有 Claim/证明单元仍独立可归因；项目 capability record 只作兼容诊断，只有当前准入的 exact/presence 与 host `target_runtime` 结果能满足对应 all-of cell，其余 capability 继续 external。每个行为型 machine Assertion 的同 Check Counterfactual 必须观察 affected Facts 变化、preserved Facts/liveness 不变、其他变化属于显式 fan-out，并保持相同 obligation universe 与 compiled process-closure identity。Binding 或路径不是 production reachability：静态 mutation 只证明该结构，runtime 必须经过 `Harness mutation of compiled production carrier → direct Source-backed product-root execution → package-observed Actual change`；Authority/verification/evidence/status/report/Receipt/verifier input 都不能进入 closure。既有最小失效范围、targeted feedback 与当前 Final Gate 规则不变，不新增通用 reachability scanner、实现 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——具体表现为有证据的高 total-cost ROI 与高效率；“高”表示显著、稳定余量，不是全局或局部最优。目的有效性、相对非劣化、must-allow、结构成本和适用的实测总成本阈值闭合后即停止扩建，除非出现新的真实反例、反复出现的重大成本热点或显著额外净收益证据。该保障复用现有 Context、索引、测试、关键哨兵、路由和一致性门禁，不新增第二 Authority、Gate 或状态；它也不能补出未表达/不可观察的需求，或对拥有全部修改权限者的蓄意联合弱化提供绝对不可变保证。
+长程任务工作流的“防劣化保障”同时保护当前因果链的真实性、跨版本的漂移拦截强度，以及相邻的 `F = 实现自由边界（Implementation Freedom Boundary）`。Context 对“当前实现”的描述必须与索引到的真实代码/运行逻辑一致；当前实现必须继续承担“需求/架构意义表达”和“fail-closed 识别、返工、最终快照复验”两项共同必要职责，并在明确的 Source 完整性、语义绑定、可观察性和可信边界下推出“不错误完成”的设计目的。`F` 是效率与反流程膨胀边界，不是第三项机制职责或无漂移定理前提：在 Source/Contract、架构、安全、禁止捷径、不可逆影响与外部动作边界内，实现顺序、方法、局部反馈节奏、具体工作包分解与动态 Worker 数量由当前 Goal 决定；当前正向默认规则只在上述有界谓词成立时要求多个精确 Worker，否则要求一个许可的 solo 理由。Harness 不建立开发阶段/方法 Gate、逐编辑强制验证、固定分配、agent 调度/状态或委派证明。设计目的、关键逻辑、两项职责、成立边界和 `F` 都属于受保护设计不变量；弱化或替换它们必须由项目 owner 显式作出设计目的变更决策并给出替代证明，不能由 Agent 推断、文档/代码/测试同步改写或成本理由暗中授权。新增开发期限制还必须解决 Final Gate 或更轻项目检查无法覆盖的独立风险，并在全部安全/证明硬约束之后证明正的净 ROI——具体表现为有证据的高 total-cost ROI 与高效率；“高”表示显著、稳定余量，不是全局或局部最优。目的有效性、相对非劣化、must-allow、结构成本和适用的实测总成本阈值闭合后即停止扩建，除非出现新的真实反例、反复出现的重大成本热点或显著额外净收益证据。该保障复用现有 Context、索引、测试、关键哨兵、路由和一致性门禁，不新增第二 Authority、Gate 或状态；它也不能补出未表达/不可观察的需求，或对拥有全部修改权限者的蓄意联合弱化提供绝对不可变保证。
+
+因此机制开发和发布结论只使用四级证据措辞：已设计、已实现、已建立声明中的已知反例保护、在明确 TCB 内高水准实现。当前 observer 修订保持 Level 3。R9/R10 各自保留三层不可互换证明：未消费的非闭包 evidence/verification 输入 must-allow；产品尝试读取非闭包文件时由运行隔离阻止接受；显式 production-bound 的 argv closure 成员若兼任 evidence/verification 角色则 Compile-reject。后续 raw argv 分类反例由 owner regression、完整 current-candidate lifecycle matrix 与独立审计证明；历史 real-process ROI workload 不证明该反例，也不新增 `CASE_ID`。Compile owner diagnostic 绑定完整已提交攻击候选；stale-Authority 防复用另由 legal-neighbor Authority 后在同一攻击候选上触发 Final-Gate freshness 拒绝证明，`active_task_missing`、dirty candidate 或 fresh Compile rejection 均不能替代。当前 machine report 持有准确 attack/control 集合与 terminal，不新增 registry。Level 4 仍要求未改变的完整 total-cost ROI 定理、无开放 critical false acceptance 的独立能力审计和项目所有者单独明确批准。prose 审计、测试数量、fresh-Agent 实验、observed lifecycle 胜出和脱敏 fixture 都不能单独提升等级或证明真实事故代表性。
+
+真实 process ROI 的实现 owner 是 `examples/delivery-benchmark/real-process-workload/**`、real-process runner/policy/scoring、唯一 package materializer、formal acquisition modules 与 `tools/verify_long_task_real_process_roi.mjs`。它冻结 8 个 Fact、normal/degraded modes、两个 Counterfactual、独立 semantic gold、A/B/C 角色及每个 fixture 的已提交候选 identity。Real-process v5 总是采集五组 A/B/C repeat；前三组结果只作诊断。唯一 materializer 负责 detached checkout、`npm ci`、build、source parity 与禁用 scripts 的 pack，并绑定 exact commit/tree/lockfile/runtime/clean status。Workload、collection、summary、aggregate 与 attestation 只拥有 immutable raw 或可重算 `observed_lifecycle_*`，formal status 只能是 `not_evaluated`；formal-v2 packet 只声明一对一路径。顶层 verifier 在验证实际 manifest-v2 run set 后构造 immutable artifact index，并继续是 evidence admission、normalized exclusive ownership、`total_roi_supported`、`total_roi_positive` 与 formal status 的唯一 owner；packet 自报 bytes、digest、role、verified、normalized value、事故货币总额、event ID 或结论都会被拒绝。Verifier 绑定 A/B/C commit/tree/materialized-package、benchmark implementation、acquisition runtime/TCB、scenario、collector、precollection、retention 与 redaction identities。本轮口径仍为 1 NCU=CNY 1、active/wait 每小时 CNY 200/50、十次交付周期、repeatable cost 的五组中位数投影、maintenance/recovery 每周期一次、introduction/adoption/migration 一次性、以及一个事故 benefit 中位数。Provider/compute/storage 只从 prelocked 实际账单或官方价格材料换算，事故 benefit 从 raw time/usage 重算；benefit 至少为正增量成本 1.25 倍、至少 4/5 paired net 为正且 sample CV 不超过 20%，成本下降另报。缺失证据即 unsupported。Provider-event v1-v2、其他已列 formal v1 schema、real-process v1-v4 与 manifest v1 均须重新采集；机器测量、独立审计与 owner promotion 保持分离。
+
+当前精确 schema 矩阵为：accounting-policy、evidence-packet、precollection-plan、raw-event、scenario-catalog 和 source-manifest 为 v2；Provider event 为 v3；real-process 为 v5；run-set manifest 为 v2。Provider-event v1-v2、其他已列 formal v1 schema、real-process v1-v4 和 manifest v1 均须重新采集；`next` 未分配。
 
-因此机制开发和发布结论只使用四级证据措辞：已设计、已实现、已建立声明中的已知反例保护、在明确 TCB 内高水准实现。当前 observer 修订保持 Level 3。R9/R10 各自保留三层不可互换证明：未消费的非闭包 evidence/verification 输入 must-allow；产品尝试读取非闭包文件时由运行隔离阻止接受；显式 production-bound 的 argv closure 成员若兼任 evidence/verification 角色则 Compile-reject。Compile owner diagnostic 绑定完整已提交攻击候选；stale-Authority 防复用另由 legal-neighbor Authority 后在同一攻击候选上触发 Final-Gate freshness 拒绝证明，`active_task_missing`、dirty candidate 或 fresh Compile rejection 均不能替代。当前 machine report 持有准确 attack/control 集合与 terminal，不新增 registry。Level 4 仍要求未改变的完整 total-cost ROI 定理及无开放 critical false acceptance 的独立能力审计。prose 审计、测试数量、fresh-Agent 实验、observed lifecycle 胜出和脱敏 fixture 都不能单独提升等级或证明真实事故代表性。
+Formal collection 的 11-scenario catalog 是 scenario/source/zero policy 的唯一 owner；collector 只声明 capabilities，所有 source 只能是 `required|forbidden`。Human time 来自 runner contemporaneous interaction recorder，compute 来自 Job-contained 完整 process tree，State 来自 runner exact payload/ledger 与预冻结 retention，Provider usage 来自 invocation-bound Provider correlation。Module-private branded acquisition runtime 自行构造 recorder、Windows Job supervisor、固定 Provider bridge 与 State capture；缺失 source、sampling/default-zero proxy、普通 spawn fallback 或 stream overflow 均 fail closed。`invocation_id` 在 spawn 前派生，record SHA 与 `execution_id` 在 tree close 后派生；human/process/wall/Provider clock 各有独立 ID，250ms 与 5000ms 容差不能替代因果 correlation。 Parent 捕获 exact prompt，并只用 `process.execPath`、空 `execArgv`、`shell:false`、bounded pipes 和 allowlist 环境启动 candidate-owned isolated Provider worker；proxy、自定义 CA 与 Node preload/loader 不受支持并 fail closed。单一 protocol owner 冻结 request/result shape、endpoint、prompt/response/stdout/stderr/deadline/abort/output-token limits 与 error code。Worker 单独拥有 `node:https`、bounded streaming 和固定 parser，四个 create-new/no-follow 临时文件在 worker/bridge 完全关闭后必须整体删除且不进入 run-set。Provider event 绑定未保留 response 的 digest、parser 与 worker identity；verifier 校验 acquisition TCB，但不声称独立重解析未保留的 response bytes。
 
-真实 process ROI 的 owner 是 `examples/delivery-benchmark/real-process-workload/**`、`tools/long_task_real_process_roi_{policy,runner,scoring}.mjs` 与 `tools/verify_long_task_real_process_roi.mjs`。它冻结 8 个 Fact、normal/degraded modes、两个 Counterfactual、独立 semantic gold、A/B/C 比较角色及每个 fixture 的已提交候选 identity。每个 fixture 生命周期前后的 HEAD/tree/status 原始命令记录绑定该 identity，并要求候选保持 clean 且不变。版本化报告可以暴露可重算的 `observed_lifecycle_*` 有效性、配对胜出、余量、方差、阶段、正确路径、资源及错误完成/错误阻断事实，但它们没有准入含义，也不使用 `qualified_positive_*`。完整 total-cost 支持还要求独立可归因且已验证的 Authoring、Runtime、State、Recovery、maintenance、test、process、introduction、adoption 与 migration 证据。当前 v2 尚未实现独立正式成本证据接入，也不准入自报的 `verified` 记录；任一类别缺失、未验证或未准入都强制 `total_roi_supported=false`，并禁止 `total_roi_positive=true`。机器测量与独立治理准入保持分离；报告结构变化必须升级 schema，或提供明确、有测试且保留缺失证据语义的兼容读取器。
+Catalog 派生 86 次 execution 与 586 个 formal artifact：516 个 base file、30 个 compute record、10 个 State ledger 加 10 个 payload、10 个 prompt 加 10 个 Provider event。Formal fuse 为 650 files/364.625 MiB，完整 run-set fuse 为 4,379 files/974.3125 MiB。Evidence Candidate 冻结全部 code/schema/Context/test/package-version/protocol bytes；Promotion Commit 必须是其直接子提交，只新增四个 package-/TCB-external governance record，并保持 materialized-package、benchmark 与 runtime/TCB identities 不变，否则重新采集与审计。 Runtime TCB v2 绑定 clean Node launch、executable path/hash、worker/protocol、parser/transport 与 limits。Benchmark implementation identity 纳入 `npm_command_spec.mjs`、Provider protocol/worker 与有限 local-dependency closure checker；working-tree、Git object、collection 与 Promotion 路径都重算闭包并绑定实际执行源码根。
+
+真实采集当前为 `external_pending`：Starward-derived fixture 缺少获授权的原始事故 design/runtime evidence、完整 original-to-sanitized mapping 及 retention/publication authorization；本轮也没有可保留的 invocation-bound Provider usage/price material 或 State-retention Source。Synthetic control 只能证明结构，不能作为 formal-positive evidence。完成这些真实外部输入、唯一 verifier 的完整正向报告、独立审计与 owner promotion 前，能力保持 Level 3。Package 0.8.15 是历史冻结的 Evidence Candidate identity；Package 0.8.17 是当前 Level-3 package candidate，不继承其 package、benchmark 或 runtime/TCB evidence。`capability_level=level_3`、`level_4_claimed=false`，没有 formal-positive 或实际 Promotion。Provider readiness 只表示本地配置、credential presence 与 clean worker launch envelope 足以发起一次有界尝试；public `independent_evidence_admitted` 只表示 packet structure/source binding，完整证据与正 ROI 仍分别由 `total_roi_supported`、`total_roi_positive` 表示。
+
+Formal collection 还会在执行前锁定一个固定 scenario catalog，覆盖十类成本和一个 controlled incident 的 exact task/gold bytes。每个 event 绑定唯一 raw output：成本 B/C 都必须命中共同 gold；事故 B 必须错误而 C 必须命中它。这样只提交时间/usage 不能制造 purpose benefit，也不会新增通用 scenario registry。
 
 本机制自己的 Final-Gate Oracle 读取固定 test-id 的 machine report，并对完整 wrong-candidate 与 correct-control workflow status 做对照。runtime capability 必须通过真实生命周期得到 `wrong candidate != machine_accepted` 且 `correct candidate == machine_accepted`；“命令 exit 0 + token/string 存在”只能证明文档一致。ROI 由独立 verifier 计算，绝不进入 safety Fact verdict。
 
@@ -436,6 +462,7 @@ npm run typecheck --workspace project-tiny-context-harness
 npm run build --workspace project-tiny-context-harness
 npm run test:affected:list
 npm run test:affected
+npm run verify:active-source-portability
 npm run test:long-task:trust
 npm run test:long-task-performance --workspace project-tiny-context-harness
 npm test
@@ -448,6 +475,8 @@ 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 显式执行。
 
+`verify:active-source-portability` 只扫描声明的当前 owner：managed guidance/assets、公开可执行文档、durable Context、source mappings 与 runtime-resolved Source。当前交付文件可用 `-- --active-source <仓库相对文件>` 精确加入。它会拒绝真实机器的用户主目录 locator，但不会枚举全部 Git 文件、改写冻结 Contract/Receipt/fixture 或删除内容。
+
 模块化门禁是 capability-aware 的 `ty-context check-modularity`；例外必须包含 `owner`、`introduced_at`、`reason`、`tracking_issue` 和 `expiry_condition`，不支持指标不会以零值制造通过假象。
 
 ## 诚实限制
@@ -457,7 +486,7 @@ make validate-harness
 - 默认 Workflow 提供 model-led、证据边界内的符合性，不提供声明范围零漂移证明或机器完成权威；未验证和外部待确认范围必须显式保留。
 - bounded Context keyword search 仍可能漏掉同义词或间接依赖，只能补充语义判断。
 - Harness 不能切换 host 选择的模型，只能在第一次 Authority Lock 后要求一次用户选择。
-- Tiny Context 不提供并行 mutation/delegation runtime；平台 Goal 可使用自身 opaque implementation delegation，但 Harness 不持久化它，也不把它当证据。
+- Tiny Context 不提供并行 mutation/delegation runtime；package-managed Skill 的有界谓词成立时，平台 Goal 必须实际调用多个精确 `long_task_implementation`，但 Harness 不负责分配或持久化这些行为，也不把它们当证据。
 - 它不观测平台 token 或模型调用数。
 - Network policy 会约束传给 runner 的代理环境。准入的 direct-process 路径还会运行冻结 runtime-closure 副本并监视/清理进程树，但两者都不是 OS 安全 sandbox，也不能证明恶意代码无法访问环境中的文件系统、网络或进程资源。
 - 同用户/管理员文件篡改、系统级 Hook 绕过不在安全边界内。

package/assets/agents/AGENTS_CORE.md

@@ -63,11 +63,11 @@ Route by required assurance, not task size. Select Long-Task when stable machine
 
 The loaded Skill and its progressive references own Source/Contract authoring, Control/applicability closure, selected-design projection, evidence design, protected revision, rolling repair and lifecycle commands. Do not duplicate those low-frequency rules in this startup router. During Draft/proof/lifecycle work, read the applicable Skill reference and use `ty-context long-task help` for CLI syntax.
 
-After the first Authority Lock, `execution_model_checkpoint.required: true` is an unconditional terminal-turn boundary. Stop before product implementation, edits, builds or tests even when an earlier message stated a model strategy. Tell a Chinese-speaking user exactly `处理好模型更换之后，请发送【继续】。`; use `After handling the model change, send [continue].` in English. Harness cannot observe or verify the host model change; later revisions do not repeat the pause and no acknowledgement, model route or checkpoint state is recorded.
+After the first Authority Lock, `execution_model_checkpoint.required: true` is an unconditional terminal-turn boundary. Stop before product implementation, edits, builds or tests even when an earlier message stated a model strategy. Tell a Chinese-speaking user exactly `处理好模型更换后，请仅回复：模型切换卡点解除，继续`; use `After handling the model change, reply exactly: model checkpoint cleared, continue` in English. A generic continuation does not satisfy the package-managed prompt protocol. Harness cannot observe the next host message or verify the host model change; later revisions do not repeat the pause and no acknowledgement, model route or checkpoint state is recorded.
 
 Long-Task Final Gate is the sole `Engineering Quality Conformance`, `Architecture Conformance` and selected-design closure owner. It source-recompiles and reruns every declared Check on one current snapshot; targeted Progress, prose, historical tests, Receipts, compiled cache or Agent judgment never create acceptance. It proves the declared falsifiable project-check-bound invariants, not overall code quality. Exactly fresh `machine_accepted` with no pending External Confirmation is the complete declared-machine terminal; qualified/external-pending results never complete the platform-native Goal.
 
-The `F = Implementation Freedom Boundary` keeps implementation order, methods and local feedback cadence Goal-owned within Source/Contract, architecture, safety, forbidden-shortcut and external-action boundaries. After the checkpoint, follow the loaded Skill's parent-owned Delegation Suitability policy for optional fixed-profile workers. Harness creates no development method Gate, per-edit mandate, fixed agent allocation, scheduler/delegation state or proof from delegated reports; all proof-bearing output converges into the selected verification workspace.
+The `F = Implementation Freedom Boundary` keeps implementation order, methods, local feedback cadence, concrete packet decomposition and dynamic worker count Goal-owned within Source/Contract, architecture, safety, forbidden-shortcut and external-action boundaries. After the checkpoint, follow the loaded Skill's packet-first positive-default policy: a qualifying packet set requires actual calls for multiple exact fixed-profile workers; zero-start and partial-delegation outcomes use its admitted reason and integration rules. Harness creates no development method Gate, per-edit mandate, fixed agent allocation, scheduler/delegation state or proof from delegated reports; all proof-bearing output converges into the selected verification workspace.
 
 Long-Task Anti-Degradation Assurance requires mechanism changes to preserve or strengthen coverage, false-negative resistance, fail-closed Authority and final-snapshot proof before total-cost ROI matters. Admission targets evidenced high ROI and high efficiency with a significant stable margin, not a global/local optimum; the complete formal cost theorem is unchanged and `observed_lifecycle_*` facts have no admission meaning. Once validity, relative non-degradation, must-allow behavior, structural-cost limits and applicable measured total-cost thresholds close, construction stops unless a new real counterexample, repeated material cost hot spot or significant additional-benefit evidence appears. Replacing the controlling purpose requires an explicit project-owner design-purpose decision plus replacement proof.
 

package/assets/agents/long-task-implementation.toml

@@ -1,6 +1,6 @@
 # ty-context:managed:long-task-implementation-worker
 name = "long_task_implementation"
-description = "Optional implementation worker for bounded Long-Task rolling code and repair after the parent Goal satisfies the execution-model checkpoint."
+description = "Package-owned implementation worker for bounded Long-Task rolling code and repair after the parent Goal satisfies the execution-model checkpoint."
 model = "gpt-5.6-luna"
 model_reasoning_effort = "max"
 developer_instructions = """

package/assets/context_templates/screen-contract.md

@@ -24,7 +24,11 @@ If these owners conflict, update the stale owner or retain a genuine decision. D
 - Surface / Route / Command:
 - Platform:
 - Owning Product Domain:
+- Target User / Usage Context Reference:
 - Primary User Question:
+- Primary Task Outcome:
+- Primary Work Object:
+- Primary Task Loop:
 - In-Scope User Tasks:
 - Explicit Non-Goals:
 
@@ -49,6 +53,7 @@ Record semantic order and responsibility, not pixel coordinates.
 4. Secondary actions:
 5. Drilldown / evidence / diagnostics:
 6. Information forbidden from permanent main-surface placement:
+7. Critical context that must remain visible while acting:
 
 ## Layout Contract
 
@@ -67,6 +72,16 @@ Record semantic order and responsibility, not pixel coordinates.
 - Map / canvas / media visible-area contract:
 - Keyboard / input-method behavior:
 - Gesture competition / pointer ownership:
+- Repeated-scroll / navigation / context-switch boundary:
+- Client / host constraints:
+
+## Task Loop And Feedback
+
+- Primary operation sequence:
+- Operation–affected-object relationship:
+- Progress / success / failure feedback relationship:
+- Commit / cancel / retry / undo / recovery:
+- Work-object visibility and focus/selection restoration:
 
 ## Control Inventory
 
@@ -113,6 +128,7 @@ Describe composition or responsibility changes, not one-off screenshots.
 ## Responsive, Mode And Content Variants
 
 - Viewport / size-class boundaries:
+- Size-class interaction topology (remain / reflow / collapse / sheet / sidebar / modal / separate surface):
 - Orientation / window-resize behavior:
 - Theme / product-mode differences:
 - Text scaling / localization / long-content behavior:

package/assets/skills/context_development_engineer/SKILL.md

@@ -1,65 +1,51 @@
 ---
 name: context_development_engineer
-description: Use when the user explicitly asks for an architecture or engineering design, technical design/plan, complex implementation design, system decomposition, API/data/state/lifecycle design, engineering trade-off, or high-level engineering assessment; or asks for 架构方案, 工程设计, 技术设计, 复杂实现方案, 系统拆分, 接口/数据/状态/生命周期设计, 工程取舍, or 高层工程评估 in a Minimal Context Harness project. Do not trigger for routine coding, bug fixes, small refactors, package/release work, generic requests to implement/build/change code, a generic implementation plan, role-only mentions such as developer/software engineer, or requests merely mentioning multi-agent, subagent, or parallel work.
+description: Use when the user asks for an architecture or engineering design, technical design/plan, complex implementation design, high-level engineering assessment, 架构方案/工程设计/技术设计/复杂实现方案/系统拆分/工程取舍/架构审计, or when the actual task content materially requires owner/source-of-truth, API/schema/data/state/lifecycle, dependency, complex alternatives, concurrency/recovery, external-integration/shared-abstraction, performance, security, compatibility/migration, implementation tradeoff, or architecture-audit judgment. Do not trigger merely for routine coding, local bug fixes, small refactors, tests, documentation, styling, package/release work, generic requests to implement/build/change code, a generic implementation plan, role-only mentions, or mentions of multi-agent, subagent, or parallel work.
 ---
 
 # Context Development Engineer
 
 ## Scope
 
-Add explicit engineering-design and architecture judgment to the repository's default Workflow Contract. This Skill is not the default implementation workflow, a coding persona, a planning artifact, an agent allocator or a verification authority. Routine implementation continues under root `AGENTS.md` without this Skill.
+Add engineering-design and architecture judgment to the default Workflow Contract. This Skill is not the default implementation workflow, a coding persona, planner, agent allocator or verification authority. Routine implementation continues under root `AGENTS.md`.
 
 Project-specific engineering 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 a valid Long-Task binding is active, `long-task-workflow` alone owns Source/Contract lifecycle, selected workspace, Progress, formal verification and Final Gate. This Skill contributes architecture judgment only and creates no second plan, stage, delegation policy/state or acceptance path.
+With a valid Long-Task binding, `long-task-workflow` alone owns its lifecycle and Final Gate. This Skill contributes architecture judgment only and creates no second plan, stage, delegation policy/state or acceptance path.
+
+## Progressive reasoning reference
+
+Read [engineering-design-reasoning.md](references/engineering-design-reasoning.md) completely. Apply only the methods triggered by actual uncertainty and risk; this is not a checklist, artifact schema or required sequence. An explicit-owner task without material design uncertainty stays on the lightweight default path.
 
 ## Engineering-design workflow
 
-1. Read the core/default Context required by `AGENTS.md`, then the owners implicated by the proposed architecture. Before `Context Delta`, run the bounded high-signal Context search already required by the default Workflow; widen only when dependency or semantic ownership demands it.
-2. State the problem, success boundary and non-goals. Separate intended Source/Context requirements from current-code behavior; code cannot silently redefine missing authority.
+1. Read required core/default and implicated-owner Context. Before `Context Delta`, run the default bounded high-signal Context search; widen only for discovered dependency or semantic ownership.
+2. State the problem, success boundary and non-goals. Separate facts, constraints, assumptions and unknowns, and Source/Context requirements from current-code behavior.
 3. Identify the existing source of truth and extension point, affected owners, dependency direction, public/internal interfaces, state and lifecycle, failure/recovery boundaries, compatibility constraints and project-native verification entries.
 4. Compare the smallest material alternatives. Prefer the existing owner/facade/adapter when it carries the stable concept; introduce an abstraction only for an evidenced change axis or durable boundary with positive net value. When foundational machinery, a mature protocol/security boundary, a dependency/shared abstraction or a nearby extension point makes sourcing material, add the risk-triggered Build / Reuse / Buy judgment below.
-5. Surface one externally observable, repository-bound `Architecture Deliberation` before implementation edits. Include the selected design, rejected material alternatives, one plausible future-change challenge, touched technical debt and disposition, forbidden shortcuts, checks and triggered quality attributes or concrete preservation basis.
+5. Before implementation edits, surface one externally observable, repository-bound `Architecture Deliberation`: selected design, rejected material alternatives, one plausible future-change challenge, touched technical debt and disposition, forbidden shortcuts, checks, and triggered quality attributes or preservation basis.
 6. Decide exactly one `Context Delta: none|required`. Durable ownership, architecture, API/schema/data, state/recovery, dependency, compatibility, verification/deployment or rationale changes are `required` and update the smallest owning Context before code. A task-local design that preserves those facts is `none`.
-7. Hand the design to the current Goal for implementation under the existing Workflow Contract. After current-candidate project checks, include Engineering/Architecture Conformance in the default Contract Conformance and run the separate Context drift check. Do not add another gate or proof ledger.
+7. Implement under the current Goal and Workflow Contract. After current-candidate checks, include Engineering/Architecture Conformance in default Contract Conformance, then run the separate Context drift check. Add no gate or proof ledger.
 
 ## Architecture Deliberation content
 
-Risk changes depth, never whether the checkpoint occurs. A small design may say that it preserves the existing boundary, but it must still name the concrete owner/extension point and verification entry.
-
-Cover what is material:
-
-- controlling Context and current code symbol/path;
-- owner and unique source of truth;
-- allowed dependency direction and prohibited bypass;
-- inputs/outputs, interface and state/persistence/lifecycle boundaries;
-- failure, retry, timeout, cancellation, degradation, recovery and resource release;
-- concurrency/consistency and security/privacy/safety boundaries when triggered;
-- compatibility, migration and rollout when a public/schema/config/versioned boundary changes;
-- selected design, material alternatives and why they lose;
-- a realistic adjacent future change and where it lands without duplicate truth or reverse dependency;
-- technical debt eliminated, isolated without worsening, or blocked pending a bounded project-owned exception with owner/reason/tracking/removal condition;
-- project-owned type/lint/AST/dependency/contract/behavior/benchmark/probe checks.
+Risk changes depth, not whether the checkpoint occurs. Name the controlling Context/code path, concrete owner and unique source of truth, extension point, dependency direction and prohibited bypass; API/schema/data inputs/outputs; interface, state and lifecycle boundaries; material failure/recovery/resource-release behavior; and triggered concurrency, security or compatibility boundaries. State the selected design, material alternatives, a realistic future-change landing without duplicate truth or reverse dependency, technical debt disposition or bounded project-owned exception, forbidden shortcuts, and project-owned type/lint/AST/dependency/contract/behavior/benchmark/probe checks.
 
-Correctness/invariants and maintainability/changeability always receive at least a preservation judgment. Reliability/resource lifecycle, concurrency/consistency, performance/capacity/cost, security/privacy/safety, compatibility/migration/rollout and operability/observability/testability activate only when the design makes them material. A performance claim additionally requires workload, metric, baseline/budget, environment, comparator/tolerance and a project-owned measurement; static shape is not runtime proof.
+Always judge correctness/invariants and maintainability/changeability. Activate reliability/resource lifecycle, concurrency/consistency, performance/capacity/cost, security/privacy/safety, compatibility/migration/rollout and operability/observability/testability only when material. A performance claim requires workload, metric, baseline/budget, environment, comparator/tolerance and project-owned measurement; static shape is not runtime proof.
 
 Refresh the deliberation if scope, ownership, dependency direction, selected design, quality applicability or debt disposition materially changes.
 
 ### Risk-triggered Build / Reuse / Buy
 
-Express the judgment as an `allowed solution set`, `prohibited failure modes` and `required rationale/evidence`, never a single required library or abstraction. Allowed choices may include the owning repository service/facade/adapter, standard library, installed dependency, mature compatible external library, a small bounded self-implementation or intentional non-abstraction.
+Record an `allowed solution set`, `prohibited failure modes` and `required rationale/evidence`, not one required library or abstraction. Choices may include the owning service/facade/adapter, standard library, installed dependency, mature compatible external library, small bounded self-implementation or intentional non-abstraction.
 
-Enumerate every materially supported member before selecting one; selection never removes another supported member from the allowed set. Judge the task's viable set, not its first proposal. If one member has current support, allow and select it while keeping every unselected but legal member as an alternative. Only a choice which actually exhibits a prohibited failure mode belongs in the prohibited list. Use `block` only when no member is supported or safety/compatibility evidence is missing; use `decision-required` only for a genuine user/product/external choice, never for multiple implementation-equivalent options.
+Enumerate every materially supported member before selecting one; selection never removes another supported member from the allowed set. Judge the viable set, retain each unselected but legal member as an alternative, and prohibit only a choice which actually exhibits a prohibited failure mode. `block` needs no supported member or missing safety/compatibility evidence; `decision-required` needs a genuine user/product/external choice.
 
 Reject duplicate owner-held rules, extension-point bypass, an unjustified heavy dependency, plainly incomplete reinvention of mature security-sensitive behavior, incompatible license/platform support, forced abstraction over structurally similar but semantically different code and a second source of truth for one stable rule. Do not add a mandatory open-source preference, DRY rule, generic quality score, artifact, stage or Gate. Conformance asks only whether the selected choice is in the allowed set, avoids prohibited failures and has risk-proportional current evidence.
 
 ## Boundary routing
 
-- Product goals, business/user rules, flows and acceptance meaning belong to `context_product_plan`.
-- Durable main/drilldown/surface information/action/feedback responsibility belongs to `context_surface_contract`.
-- Durable Design Authority, tokens, rationale, adopted target interpretation and UI Authority Closure belong to `context_uiux_design`.
-- New design-resource generation/handoff belongs to `design-resource-authoring`.
-- Exact non-UI semantic facts remain owned by Source/Context; exact selected UI values remain owned by selected-design closure. This Skill does not invent either.
+Product goals and acceptance meaning belong to `context_product_plan`. Durable main/drilldown/surface information/action/feedback responsibility belongs to `context_surface_contract`. Durable Design Authority and UI Authority Closure belong to `context_uiux_design`. New design-resource generation/handoff belongs to `design-resource-authoring`. Exact non-UI semantic facts remain owned by Source/Context; exact selected UI values remain owned by selected-design closure.
 
 For monorepos, distinguish expandable read scope from intended/supporting workspaces. Existing Context workspace mappings are semantic routing rather than edit authorization or read ACLs. Do not add workspace registries, topology scans or empty Context mirrors.