project-tiny-context-harness 0.8.12 → 0.8.13

package/assets/README.zh-CN.md

@@ -73,7 +73,7 @@ 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，也不要求经过 Source Plan 阶段。
+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 持有。
 
@@ -98,7 +98,7 @@ $long-task-workflow 将 docs/initial-proposal.md、<handoff.md> 以及选定的
 - **交付前确实需要设计资源：** 按上面的设计优先顺序执行，再根据恢复与完成权威需求，把修订方案、已校验 handoff 和选定的不可变规范资源集合交给默认 Workflow Contract 或 `long-task-workflow`。
 - **只需要设计资源：** 在 `design-resource-authoring` 完成后结束；除非还明确选择了实现交付，否则不创建 Long-Task Contract。
 
-设计系统通常在项目冷启动时确定，但该 Skill 只由用户选择，`init`、`sync` 与下游 Skill 都不会自动执行。`design-resource-authoring` 只对高保真、品牌化、视觉处理等 style-bearing 资源设门禁；低保真结构、IA/流程与纯语义状态研究不受此门禁。旧 Source Plan 仍可作为 Source，但不再是推荐中间服务。
+设计系统通常在项目冷启动时确定，但该 Skill 只由用户选择，`init`、`sync` 与下游 Skill 都不会自动执行。`design-resource-authoring` 只对高保真、品牌化、视觉处理等 style-bearing 资源设门禁；低保真结构、IA/流程与纯语义状态研究不受此门禁。已有计划或提案文档仍是普通 Source，但不再是推荐中间服务。
 
 ## Minimal Context 与默认工作流
 
@@ -175,6 +175,8 @@ Context: no durable fact change
 
 Shared Engineering Quality 在不增加工作流的前提下扩展原有架构义务。每个实现需求都在第一处实现编辑前，对用户可见地完成一次 `Architecture Deliberation`；风险改变深度，不取消这个环节。小修改要指出具体 owner / 当前 extension point、未改变的耐久边界、适用质量属性的 preservation，以及为何没有新增或加重技术债。material 工作还要覆盖唯一 source of truth、dependency 与 interface/state/resource lifecycle 边界、选中和拒绝的方案、至少一个合理未来变化及其扩展点、触达的技术债、forbidden shortcuts、项目原生可执行检查和触发的 failure/load/threat 场景。correctness/invariant 与 maintainability/changeability 至少给出 preservation；reliability/resource lifecycle、concurrency/consistency、performance/capacity/cost、security/privacy/safety、compatibility/migration/rollout、operability/observability/testability 只在 material 时激活。
 
+当工作新增基础设施、实现成熟协议/安全边界、引入依赖或共享抽象，或遇到邻近 extension point 时，Architecture Deliberation 会按风险增加 Build / Reuse / Buy 判断。它记录 allowed solution set、prohibited failure modes 与 required rationale/evidence，而不指定唯一库或抽象。复用现有 owner、标准能力、已安装依赖、成熟且兼容的外部库、小型有界自研和有意不抽象都可能合法；重复 owner 规则、绕过 extension point、无依据重依赖、不完整安全能力自研、许可证/平台不兼容、强行抽象与第二 source of truth 均不允许。这里不增加强制开源/DRY 规则、通用评分、阶段或 Gate。
+
 实现顺序、方法和反馈节奏仍由 Goal 决定。轻量纪律只要求复用 owning service/facade/adapter 与唯一 source of truth，做最小而完整的变化，保留明确 failure/resource 语义，并仅为稳定概念或有证据的变化轴增加抽象。精确产品/技术谓词继续由 Semantic Facts 拥有，精确选定 UI/UX 值由 selected-design closure 拥有。
 
 实现和项目验证之后，`Engineering Quality Conformance` 包含 `Architecture Conformance`，对当前候选快照检查 scope/path escape、owner/dependency 违规或 bypass、重复 truth、未声明 boundary/lifecycle 变化、silent failure、适用 resource/concurrency/security/compatibility/operability 缺陷、无证据性能声称、缺失声明检查和新增/加重技术债。性能声称必须绑定 workload、metric、baseline 或 budget、environment、comparator/tolerance 和项目原生 benchmark/probe；静态形状不证明运行时性能。候选或 controlling input 再变化就使结果失效。默认路线把它放在 Contract Conformance 内；Long-Task 用已有 Source-backed obligation/constraint/forbidden shortcut、owner/path/Binding、executable Check，以及功能 pass 时仍可能独立失败的 Assertion 表达不变量。Final Gate 是唯一 Long-Task carrier，只证明该声明、可证伪、项目检查绑定的集合，不证明整体代码质量；同一候选不会执行两套 carrier。
@@ -221,7 +223,7 @@ provider-neutral handoff 是残余语义与绑定层，不是 CSS 文本副本
 
 容量优化发生在生成表示上，不是生成后拆分。写 Markdown 前，DSA 冻结明确的 canonical manifest 路径集合、target/scope identity、文件 SHA-256 与每个 collection 的精确 count/identity digest，并声明实际 UTF-8 上限；随后直接生成一 target 一份的小型 manifest-backed draft，其中不再复制 axes/conditions/subjects/variations/properties/lineage/Fact Cells/Facts/evidence/proofs/Oracles/environments/assets/blockers。共享含义用唯一 key 的 target-attributed Source Fact 保留原 predicate 与 provenance。`ty-context design-resource bundle` 对完整 draft/manifest 集合逐 target 做单快照 preflight，拒绝嵌入式全量数组、多 target draft、超限 descriptor、target 缺失/多出/重复及任何 manifest/digest/语义漂移，再用同卷临时目录把整组原子发布到此前不存在的最终目录。失败只删除命令自己的临时目录，不覆盖、拆分或改写 draft/已采纳 handoff。字节检查只是防止生成器违约或后续突变，不是 post-hoc split；真实 residual 数据若无法满足所选上限，就判定该上限不兼容并 fail closed，绝不拆 target、抽样、截断、粗化 Fact 或扩大 exclusion。Long-Task 只在既有读取接缝逐 target 消费规范化对象，不改变 Contract、Authority、Outcome、Final Gate、状态恢复或完成判定。
 
-这些输入仍是 Source。默认 Workflow 打开受影响的 exact target/constraint 及其声明条件，把它们路由到生产 owner 和冷启动旅程，在最终候选运行适用的视觉、交互、无障碍或 runtime 检查，并报告检查未建立的条件；它不重建完整 UI Fact Cell universe 或逐 Fact×method 生产结果账本。Long-Task 把精确 universe 投影进已有 Claims/Assertions/Checks/Bindings：每个 method/condition cell 保存精确 `fact_refs`，每个 Fact/proof obligation 有一个 `fact_expectations` row，再由一个当前 `fact_results` row 保存同一 observation/comparison/authority 元组；Final Gate 要求 expectation/result 集合精确相等且同一当前快照上全部通过。受保护/敏感 observation 只可 redacted 或 digest-only，但不能丢失 comparison authority。两种 carrier 互斥。生成成功、截图、hash、Census 与 preflight 只证明输入完整性/完整性，不证明生产一致性。
+这些输入仍是 Source。默认 Workflow 打开受影响的 exact target/constraint 及其声明条件，把它们路由到生产 owner 和冷启动旅程，在最终候选运行适用的视觉、交互、无障碍或 runtime 检查，并报告检查未建立的条件；它不重建完整 UI Fact Cell universe 或逐 Fact×method 生产结果账本。Long-Task 把精确 expected universe 投影进已有 Claims/Assertions/Checks/Bindings：每个 method/condition cell 保存精确 `fact_refs`，每个 Fact/proof obligation 有一个 `fact_expectations` row。只有 package-admitted observer 提供 Actual 且由 Harness 完成 comparison 时，当前 `fact_results` row 才能关闭该 cell；否则保留阻断性 External Confirmation，Final Gate 不会伪造 result。当前 slice 不准入 UI layout/pixel/accessibility/motion、browser/native/device、protected 或 tolerance/mask observation。两种 carrier 互斥。生成成功、截图、hash、Census 与 preflight 只证明输入完整性/完整性，不证明生产一致性。
 
 默认 Workflow 会在 material 产品、设计、实现或验收判断前执行 UI Authority Closure 和条件式 Design Authority Check。它沿稳定 key 到 exactly-one canonical adoption record，再主动打开每个受影响的 selected `exact-target`/`constraint`；只看到 registry 或 handoff index 不算已消费。项目/系统/component-family target 由 `DESIGN.md` canonical 记录，单 screen/interaction target 由 owning Screen Contract 记录；该 record 独占 interpretation、selection basis、immutable locator/digest、condition coverage 和 editable upstream/update route，其他层只保留 stable key、owner/anchor 和 local applicability。缺失、不可读、过期或冲突时 fail closed；更新必须产生新 immutable version，不能覆盖旧基线。未配置 starter、候选稿、只有风格文字或灵感图都不能授权 agent 发明生产布局。明确的设计系统采纳请求路由到 `design-system-authoring`，独立资源生成请求路由到 `design-resource-authoring`；已有充分权威的实现、局部样式修复和 throwaway prototype 仍保持轻量。
 
@@ -229,9 +231,9 @@ provider-neutral handoff 是残余语义与绑定层，不是 CSS 文本副本
 
 对 material 工作，`context_uiux_design` 应用上面的投影规则并让风险比例化 coverage reasoning 保持 task-local。`context_development_engineer` 用稳定 surface/control key 把每个受影响的 selected target 和声明 condition 追踪到生产 route/component owner、冷启动真实用户旅程及适用的渲染/交互检查。第一个有价值的可运行纵向切片只是建议性的真实入口反馈点，不是实现门禁；最终候选仍必须重跑受影响的冷启动旅程。Source 已明确要求的组合不能静默删减，但默认路线应报告未被证据建立的条件，而不是声称精确机器闭包。资源哈希、manifest 和数量只证明资源完整性，实现截图既不能成为自己的目标，也不能单独证明实现一致性。
 
-显式 Long-Task 是同一共享义务的强机器载体。它在 Compile 前解决缺失/冲突的 UI 权威，并用 `field_coverage` 闭合每个真实 Product Control 的全部 22 个 canonical 字段；这条产品语义投影与更细的 design Fact universe 相互独立，绝不构成粒度上限。选定 target 冻结 canonical manifest identity/digest，并把每个原子 Fact/required-method 对投影为一个 `fact_expectations` row，其中包含 subject/target/condition/variation/property identity、expected located-value digest、comparator/parameter/tolerance/mask、Oracle identity/capability、environment 和 sensitivity。当前 Check evidence 提供精确匹配的 `fact_results` row，包含 actual observation/environment、comparison 与 pass/fail；observation 重复/复用、result 缺失、authority 过期或任一失败都阻断 Final Gate。`design_conformance` 仍是 target-level actual/comparison artifact 的 typed 当前执行记录，`design_method` 则绑定可独立失败的 method/condition cell 及其逐 Fact rows；任何聚合记录都不能替代原子 Fact 证明。Product `surface_bindings`、Control Claims/relations 与 root-entry journey 继续承载产品语义，已有 Claim、Assertion、Check、Stage、Binding、revision 与 Final Gate 仍是唯一 Long-Task 生命周期和 closure。每个 blocker 保留精确 Source-item/method/capability lineage，不能在 Contract 内自行豁免；缩减范围必须修订 Source/Contract 权威。
+显式 Long-Task 是同一共享义务的强权威载体。它在 Compile 前解决缺失/冲突的 UI 权威，并用 `field_coverage` 闭合每个真实 Product Control 的全部 22 个 canonical 字段；这条产品语义投影与更细的 design Fact universe 相互独立，绝不构成粒度上限。选定 target 冻结 canonical manifest identity/digest，并把每个原子 Fact/required-method 对投影为一个 `fact_expectations` row，其中包含 subject/target/condition/variation/property identity、expected located-value digest、comparator/parameter/tolerance/mask、Oracle identity/capability、environment 和 sensitivity。只有 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 权威。
 
-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、必需设计目录、逐控件截图矩阵或通用像素阈值。
+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` 做诊断定位，但当前 machine closure 仍是 External Confirmation；浏览器代理、独立 route 或深链接不能证明可独立失败的原生/root 旅程。资源完整性和 `visual_render` 不能替代选定目标的实现一致性。冻结 baseline 是 verifier input，生成的 actual render/diff 是当前 artifact，主观批准保持外部。这不新增 `uiux_delivery`、视觉 Claim type、resource registry、risk level、lifecycle state、Gate、必需设计目录、逐控件截图矩阵或通用像素阈值。
 
 `ty-context doctor` 保留兼容的项目级 `missing | unconfigured | configured` 状态，并增加 Design Authority Index、token source 和已分类 reference 的 advisory 信号。它明确不推断页面实现就绪；material surface 仍需 owning Screen/Control meaning、selected target/constraints 与项目自己的验证路径。
 
@@ -245,10 +247,12 @@ combined design-and-implementation 可以先用普通 Outcome/Stage 生成候选
 
 ### 可选 Design Resource Authoring
 
-只有在用户明确要求生成、迭代、准备独立设计资源、为一段明确开发内容准备设计资源或使用 Open Design 时，才使用 `design-resource-authoring`。输入可以是零散笔记或初始方案、产品/技术方案、专门视觉 brief、截图、已有资源或历史 Source Plan。独立 Source Plan 不是前置项，也不再是推荐中间步骤。
+只有在用户明确要求生成、迭代、准备独立设计资源、为一段明确开发内容准备设计资源或使用 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`。
 
+正式首次生成、重大设计修订和关键重新生成使用实时发现后满足工具、视觉/上下文能力、认证与数据边界的最高能力模型，以及该模型实际支持的最高 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、动效、无障碍或资产事实。
 
 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` 验证一致。
@@ -257,15 +261,17 @@ 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 或验收结果。Skill 不会修改 Source Plan、`project_context/**`、`DESIGN.md`、生产代码或 Delivery Contract。
+探索模式只做最小完整性检查并尽快展示指定候选，不需要 handoff schema。明确或受托最终选择且资源将进入实现时，Skill 只做一次合并、幂等的初始方案回改，并在任意获准的项目路径按 target 写 provider-neutral、带 Source marker、且只含一个严格 manifest-backed `design-resource-handoff-v1` block 的 Markdown。canonical manifest 保留完整 Inspector/Census/Fact/proof universe；小 YAML 只记录其不可变 resource/target 绑定及 residual 产品/coverage/Source/proposal 含义。共享 preflight 还原同一个完整校验对象，不能把取得不完整、不可寻址、`decision_required`、`unavailable`、证据不成立或过期的输入称为 ready。这里没有固定目录、provider pack 或逐控件一份稿；适配器只是普通 Source，不是 Design Authority 或验收结果。除唯一被明确授权的 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、登录、付费能力或不确定的设计输出。
 
-### 退役 Source Plan 兼容入口
+### 退役独立 Authoring 兼容
 
-`source-plan-authoring` 不再安装或由 package 管理。升级迁移只删除字节完全等于原 package 指引的副本；同名但已修改的内容保留并要求人工处理，普通 sync 不维护 tombstone 或盲删规则。`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 或第二份计划。
+退役的独立 authoring 指针不再安装或由 package 管理。升级迁移只删除字节完全等于原 package 内容的副本；同名但已修改的内容保留并要求人工处理，普通 sync 不维护 tombstone 或盲删规则。`long-task-workflow` 从入口立即打开非权威 Contract Draft，并让完整 input inventory、混合输入综合/细化、稳定 Key、Product Control 级语义、偏好/调研/委托溯源、Source marker/provenance、acceptance/risk 与 Contract 映射在同一循环中收敛。这里的 Control 语义投影不限制另一条选定资源“完整可观察设计事实”清单的粒度。已有计划或提案文档仍是有效普通 Source，但不再创建独立或内部 Source-authoring 阶段、handoff、Schema、Gate、State 或第二份计划。
 
 ## Single-Goal Rolling Delivery
 
@@ -282,9 +288,17 @@ Skill 只通过结构化 MCP（必要时有限使用 CLI/daemon/UI fallback）
 - Final Gate 在一个当前快照上重跑全部 Check；
 - Stop Hook 在结果 stale 时阻止完成。
 
-它的证明命题有明确前提：Source 在声明观察粒度下完整且准确，Source→Contract 投影保持语义，所有实际适用单元被展开，且具名项目 Oracle 与 verifier/runtime 可信边界语义正确；在这些前提下，只有 fresh `machine_accepted` 且没有任何待定 External Confirmation 的 `AcceptedDeliveryTerminal` 才严格推出完整声明可观察漂移为空。`machine_accepted_external_pending` 只能推出机器可验证范围内的声明漂移为空，完整交付仍是带限定的未完成状态，Harness 不完成原生 Goal。Harness 会机械强制并冻结其中许多前提，但无法发现未声明要求，也无法自动证明任意项目 Oracle 对现实语义忠实。
+它的证明命题有明确前提：Source 在声明观察粒度下完整且准确、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 或语言依赖解析器。
+
+项目自报的 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 失去验收效力。
+
+诚实声明为不支持的 Contract 不需要伪造 verifier。现有 External Confirmation 可通过 `impact_claims` 覆盖精确的普通 Outcome/Global Claim 与 Semantic Fact Claim，而每个 Semantic Fact proof 仍保留显式 `confirmation_ref`。完全 external 的 Outcome 设置 `success_path_required: false`；Stage Gate 只有在 `blocks_target: true` 的 confirmation 明确影响该 gate 的 result Claim 时才可不声明 machine Check。缺少 result lineage、非阻断 confirmation 或声明了机器 success path 却没有真实 success Check 都会使 Preflight/Compile 失败。合法的 external-only 路径最终只能得到 `blocked_external`，不会得到任何 machine-accepted 状态。
 
-原始/修订方案、选定设计资源和混合附件会立即进入一个 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 结构本身不构成阻塞。
+Direct-process observer 提供的是受限 containment，不是针对恶意代码的绝对 sandbox。它的 TCB 包括 host OS/文件系统/进程 API、Node runtime、快照复制与 no-follow/digest 校验、stdout 捕获/解码、timeout、进程树检查和清理。冻结的 subtraction controls 表明移除 watcher/pre-post 或 containment/cleanup 会重新打开 transient/persistent swap 或 descendant/timeout leak，因此保留这些既有责任，不新增 edge mechanism。它不声称能阻止蓄意恶意 executable 逃出复制闭包、访问环境中的机器/网络资源或规避所有 OS 进程树机制。需要这类对手边界的 workload 必须使用外部 sandbox 或 External Confirmation。
+
+原始/修订方案、选定设计资源和混合附件会立即进入一个 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`。已有计划文档的旧结构本身不构成阻塞。
 
 第一次正式 Compile 成功前，`delivery-contract.yaml` 是同一份非权威 Contract Draft。`long-task-workflow` 从入口开始，跨 Source 细化、仓库/Context 读取、映射和 Preflight 修复持续修改它，不要求一次响应生成完整 Contract。Source 完备性是 Preflight/Compile 的收敛条件，不是前置阶段。不存在单独 Contract Draft Skill、Draft Receipt 或 Authoring State。
 
@@ -315,13 +329,19 @@ Long-Task Skill 采用渐进读取：主 `SKILL.md` 只保留目标、硬边界
 
 Draft Outcome 只是 Authority Lock 前的 Outcome。Outcome 按可独立观察、判断、纵向闭环和定向验证的结果拆分，用于投影 acceptance/verification-ready 工作集、定位失败、恢复 finding 并精确失效旧局部结果。`depends_on` 只表示 acceptance 与中间证明 readiness，不授权或禁止实现编辑。每个 Outcome 属于一个有序 Stage；Stage gate 传递依赖同 Stage 其余 Outcome，后续 Stage 依赖前置 gate。Rolling Frontier 和 Stage 状态都由普通 Outcome Progress 临时派生，只是建议性验证/诊断投影。当前 Goal 可按代码现实跨 Outcome/Stage 实现、检查或返工，也可使用平台原生 opaque delegation；Harness 不创建 delegation scheduler、不把委派当证明，所有结果必须汇入选定验证 worktree。Outcome 不是 Worker、scheduler task、queue 或并行单元，Stage 也没有 Receipt 或第二个 Gate。Outcome 拆分诊断和证明归属，不拆分完成权威，因此最终仍必须在当前最终快照运行一次完整 Final Gate。
 
-Contract 声明一个有界 target profile、非空 required product target refs，以及每个 target 的 runtime family、root entrypoint 和显式 capabilities；required product target 必须声明对应 family、`cold-start` 与 `production-root` 能力。Web/process 代理不能代替单独要求的 Native/desktop 目标；browser 目标由 Playwright 证明，Native/desktop 目标由 project binary 证明。每个 `critical_user_path` Outcome 和 Stage gate 都必须从每个 required target 的 root 证明 `target_runtime`；多 Outcome Stage gate 还必须证明至少两个不同 surface 对应同一运行时状态。
+Contract 声明一个有界 target profile、非空 required product target refs，以及每个 target 的 runtime family、root entrypoint、完整 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 或状态；它也不能补出未表达/不可观察的需求，或对拥有全部修改权限者的蓄意联合弱化提供绝对不可变保证。
 
-如果一个声明结果可能在代理表面通过、却在目标运行时独立失败，最早拥有可运行边界的 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 仍是接受权所有者。
+因此机制开发和发布结论只使用四级证据措辞：已设计、已实现、已建立声明中的已知反例保护、在明确 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 都不能单独提升等级或证明真实事故代表性。
 
-长程任务工作流的“防劣化保障”同时保护当前因果链的真实性、跨版本的漂移拦截强度，以及相邻的 `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 或状态；它也不能补出未表达/不可观察的需求，或对拥有全部修改权限者的蓄意联合弱化提供绝对不可变保证。
+真实 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，或提供明确、有测试且保留缺失证据语义的兼容读取器。
 
-工作流机制变更按字典序准入：Safety/Coverage → Semantic Granularity → Proof Strength/TCB 与不可绕过 Authority/fail-closed/当前最终快照证明 → Structural Closure Cost Non-Degradation → Total-cost ROI。其效率目标是 **Fine-Grained Semantic Purpose-Fulfillment Efficiency**：完整达到细粒度语义与证明效果，同时在声明机制边界内消除与独立语义单元、必要证明、可信边界或适配器无关的成本。逻辑 Fact/obligation 粒度可以细于持久化粒度；无关笛卡尔轴、可推导重复与共享元数据复制不是合法的长期成本来源。等价效果下，Source/Contract/evidence bytes、DAG、Compile/Preflight/Final Gate、峰值 RSS、默认 Context 读取量和单 Fact revision blast radius 不得因这类结构原因增长。任何成本下降都不能补偿粒度、证明或漂移识别能力下降；正净 ROI 只使候选进入考虑集，不代表自动采用，也不新增 Authority、Gate、状态或固定执行流程。
+本机制自己的 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。
+
+工作流机制变更按字典序准入：Safety/Coverage → Semantic Granularity → Proof Strength/TCB 与不可绕过 Authority/fail-closed/当前最终快照证明 → Structural Closure Cost Non-Degradation → Total-cost ROI。其效率目标是 **Fine-Grained Semantic Purpose-Fulfillment Efficiency**：以有证据的高效率和高 total-cost ROI 完整达到细粒度语义与证明效果，同时在声明机制边界内消除与独立语义单元、必要证明、可信边界或适配器无关的成本。逻辑 Fact/obligation 粒度可以细于持久化粒度；无关笛卡尔轴、可推导重复与共享元数据复制不是合法的长期成本来源。等价效果下，Source/Contract/evidence bytes、DAG、Compile/Preflight/Final Gate、峰值 RSS、默认 Context 读取量和单 Fact revision blast radius 不得因这类结构原因增长。任何成本下降都不能补偿粒度、证明或漂移识别能力下降。“高”要求完整已验证成本集上的显著稳定余量，不要求穷举比较或证明最优；它只使候选进入考虑集，并受上述充分性停止规则约束，不代表自动采用，也不新增 Authority、Gate、状态或固定执行流程。
 
 package-owned 的非 UI Compact Carrier 在不新增 Authority、状态或 Gate 的前提下实现“逻辑粒度细于持久化粒度”。共享 catalogs、selectors、Fact sets、proof templates、projections 和显式 exceptions 物化后继续进入既有 validator 与唯一 Final Gate。Fact 与 obligation 分别保持独立 exact-set 闭包；typed result 先绑定稳定 `obligation_key + obligation_revision_digest`，再投影到稳定 `fact_key + fact_revision_digest`。Fact revision 覆盖规范化 Fact 语义及其全部显式关联的当前输入 revision，obligation revision 覆盖规范化证明语义及当前 Fact revision，因而 Source 语义不能藏在不变的 identity pair 后。实现只可用有界数组和 `Map` 索引物化已测量集合，不能构造理论 ground universe。expanded 输入仍可兼容读取，但每份已采用的 Source/Contract 只能持久化一种表示，迁移会删除等价机械展开而不保留影子 Authority。
 
@@ -373,7 +393,7 @@ Contract 顶层包含：
 - `global`：非目标、owner boundary、技术约束、禁止路径/捷径和全局 Check；
 - `outcomes`：可独立判断并可定向验证的纵向结果、所属 Stage、依赖、明确 success/degradation 要求、REQ、产品/控件状态与位置、稳定技术义务和命名 AC。
 
-Runner 支持 `package_script`、`project_binary`、`node_oracle`、`playwright_test`；正式验收中的 package script 必须能恢复静态 Node entry 及其本地依赖闭包。Proof surface 支持 `ui_browser`、`runtime_behavior`、`api_contract`、`data_state`、`security_boundary`、`population_coverage`、`implementation_structure`。Execution target family 是有界的 `browser`、`native`、`desktop`、`service`、`process`、`external`，role 是 `product`、`support`、`observer`；required ref 只能指向具有 family/cold-start/production-root capabilities 的 product target。Browser target 只能由 `playwright_test` 证明，Native/desktop target 只能由 `project_binary` 证明。
+Runner 声明仍支持 `package_script`、`project_binary`、`node_oracle`、`playwright_test`，proof surface 与 execution-target family 名称也保持兼容；但 runner type 只决定执行与 payload decode，不决定观察权威。当前 machine admission 仅允许 runner 前冻结的静态 JSON exact structure，以及 Harness 直接启动的 `project_binary` process product root；browser/native/desktop/device 与 project Oracle observation 必须进入阻断性 External Confirmation。
 
 ### 一个 Contract 与 Source Claim
 
@@ -393,17 +413,19 @@ active Long-Task 内部原有 `risk.requested_level: auto | standard | strict` p
 
 ## Evidence 与完成权威
 
-最终接受来自当前可执行证据，不来自 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` 能力。
+最终接受来自当前可执行证据，不来自 Agent 文本。Runner kind 仍选择 `playwright_json_v1` 或 `structured_json_v2` decode，项目 capability payload 仍是 `long-task-check-result-v3`，但 decode 不是 Actual Authority。Compile 必须把每个 machine obligation 分配到 `package_static_json_exact` 或 `package_process_json_exact`；不支持的义务保留阻断性 External Confirmation。admitted adapter 及 expected/actual/comparison identities 进入 acceptance、Raw Execution、compiled、Progress 与 Receipt identity。
+
+每个 Check 仍声明精确 scenario、journey、applicability 与 all-of Evidence Capabilities，但项目提交的 capability record 只作兼容数据。Harness 当前从 admitted static/process observation 派生 exact/presence，并仅对直接 process root 派生 host `target_runtime`；项目副本缺失不削弱这些 package proof，存在但不一致时 fail closed。`interaction_trace`、`state_delta`、`design_conformance` 与其他没有 package derivation 的 capability 必须保留阻断性 External Confirmation，不能制造 machine row。
 
-每个 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` 仅允许 admitted 静态 `implementation_structure`。V1 ground、V2 symbolic、non-UI、static 与 process exact 全部调用同一个 Harness evaluator：actual≠expected 直接失败，tolerance/mask 不准入，result identity 由 Harness 重算，submitted pass/verdict 不参与计算。Playwright/aggregate decoder 字段只作诊断，不能证明 browser/UI Claim。
 
-每个 Outcome 至少有一个非 Result 原子 Claim，且 `required_proof_surfaces` 必须 all-of 全覆盖。Claim-bearing Assertion 使用显式 Expected 比较；`truthy/falsy` 禁止，`exists` 仅允许证明 `implementation_structure` Obligation。每个行为型 Claim-bearing Assertion 还必须用 same-Check、Claim-local 的 `replace_json_value` 或 `replace_text` 替换错误语义，并要求无 Claim 的 target-runtime liveness Assertion 在 `preserved_assertions` 中继续通过；`replace_file` 仅保留兼容性，不能证明语义绑定。Population 必须通过真实 universe Binding 证明全集，但不能豁免这条语义 witness。
+Outcome/Global Counterfactual 的 Binding/path 本身不是生产可达性证明。静态 Counterfactual 只证明冻结结构对象；runtime Counterfactual 必须由 Harness 修改声明的生产 carrier、直接运行相同 process product root 并通过 package 观察 Actual 变化。每个 machine witness 声明 affected、preserved 与 allowed-fan-out Facts，保持 obligation universe 和 host-derived liveness；缺少 admitted baseline/mutated observation 时直接失败。Source/Context/expected、status/report/evidence/Receipt/verifier output 都不是 mutation carrier。
 
-Targeted verify、Progress、status、Receipt 与 compiled cache 都不是完成权威。Final Gate 要求 clean candidate commit，先拒绝已经 stale 的 accepted authority inputs，再从 Source 重新 Compile，在同一 Git-tree snapshot 上运行全部 Global/Outcome Check；执行前后都重新编译并核对 Contract/fragments、Source、完整 Controlling Context、verifier/runner、受支持 direct-literal 本地 verifier graph、verification inputs 与 workdir inputs 的完整受保护身份，同时复核 active identity。只有全部不变时它才可以生成 `machine_accepted` 或 `machine_accepted_external_pending`；后者仍必须明确列出外部确认项，并且不属于完整交付无漂移定理的前件。
+Targeted verify、Progress、status、Receipt 与 compiled cache 都不是完成权威。Final Gate 要求 clean candidate commit，从 Source 重编译 observer plan，在同一 Git-tree snapshot 上重跑全部 Check，并核对全部受保护身份。Direct-process 的内部 host attestation 还绑定 executable/root/argv equality、PID/times/exit、candidate snapshot digest、内部 execution nonce 与捕获的 stdout-envelope digest；这些 host 字段都不来自 child。nonce 不向 child 暴露，也不能单独认证产品语义。只有当前 Authority 与 observation chain 全部不变时才可生成 `machine_accepted` 或 `machine_accepted_external_pending`；后者仍列出阻断性外部确认，不属于完整无漂移定理的前件。
 
 ## 兼容与迁移
 
-当前 V2 的语义保证闭包还要求 full Context、architecture-classified Source obligation、原子 applicability dimensions、显式 target capabilities、带 applicability 的 Control-relation closure、Population universe carrier、Claim-local 语义 mutation、逐 method/condition 的 method-record/primary-observation artifacts、blocker-required capabilities 与受支持 direct-literal verifier dependency closure。缺少这些含义的旧 V2 Contract 会报告可索引的人工迁移 `long-task-v2-semantic-drift-authority`；必须依据 Source 重新表达。Upgrade 不会猜测这些含义，也不会把旧 Progress/Receipt 当作通过证据。
+当前 V2 的语义保证闭包还要求 full Context、architecture-classified Source obligation、原子 applicability dimensions、显式 target/blocker capabilities、Control-relation closure、Population universe、Claim-local mutation 与 admitted observation chain。含 custom machine Oracle、不支持 method/family、wrapper root、缺失或未绑定 process argv，或缺少 admitted Counterfactual observation 的旧 V2 Contract 会收到精确人工迁移诊断；必须依据 Source 明确改成 static exact、direct-process exact 或阻断性 External Confirmation。Exact planned process root/argv/carrier 可以到 Final Gate 才存在，但 pattern 或未声明 runtime dependency 不能冒充它们。相关诊断包括 `machine_observer_not_admitted`、`unsupported_observer_requires_external_confirmation`、`custom_oracle_machine_completion_forbidden`、`static_observation_not_in_pre_run_snapshot`、`static_observation_changed_by_runner`、`process_observer_direct_root_required`、`process_observer_root_invocation_required`、`process_observer_root_argv_mismatch`、`process_root_production_binding_required`、`process_runtime_carrier_exact_path_required`、`process_runtime_input_missing`、`process_observation_input_changed_by_runner`、`legacy_target_runtime_non_authoritative`、`counterfactual_admitted_observation_required`、`counterfactual_runtime_reachability_unproven` 与 `project_submitted_verdict_disagrees_with_harness`。Upgrade 不会代选，也不会把旧 Active Authority、Progress/Receipt 当作通过证据；public result payload v3 保持兼容，但其自报证明字段不具权威。
 
 ## 开发与验证
 
@@ -437,7 +459,7 @@ make validate-harness
 - Harness 不能切换 host 选择的模型，只能在第一次 Authority Lock 后要求一次用户选择。
 - Tiny Context 不提供并行 mutation/delegation runtime；平台 Goal 可使用自身 opaque implementation delegation，但 Harness 不持久化它，也不把它当证据。
 - 它不观测平台 token 或模型调用数。
-- Network policy 会约束传给 runner 的代理环境，但不是操作系统 sandbox。
+- Network policy 会约束传给 runner 的代理环境。准入的 direct-process 路径还会运行冻结 runtime-closure 副本并监视/清理进程树，但两者都不是 OS 安全 sandbox，也不能证明恶意代码无法访问环境中的文件系统、网络或进程资源。
 - 同用户/管理员文件篡改、系统级 Hook 绕过不在安全边界内。
 - Git/PR/CI、部署与人工产品确认仍由外部系统负责。
 

package/assets/agents/AGENTS_CORE.md

@@ -6,6 +6,8 @@ This project uses Tiny Context. The Harness maintains durable Context and workfl
 
 Before the first implementation edit, every delivery surfaces one externally observable, repository-bound `Architecture Deliberation`. Depth is risk-proportional, but the checkpoint always names affected owners, the current extension point/source of truth, dependency and state/lifecycle boundaries, the selected design and material alternatives, one plausible future-change challenge, touched technical debt and its disposition, forbidden shortcuts, project-owned checks and triggered engineering-quality attributes or their concrete preservation basis. 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 change or an explicit claim makes them material. Exact product/technical predicates remain owned by Semantic Facts and exact selected UI/UX values by selected-design closure. Refresh the checkpoint when scope, ownership, selected design, quality applicability or debt disposition materially changes.
 
+When foundational machinery, a mature protocol/security boundary, a dependency/shared abstraction or a nearby extension point makes sourcing material, include a risk-triggered `Build / Reuse / Buy` judgment. Record an allowed solution set, prohibited failure modes and required rationale/evidence; do not prescribe one library or abstraction. Reusing an owner, the standard library, an installed dependency, a mature compatible external library, a bounded self-implementation and intentional non-abstraction may all be valid. Enumerate every materially supported member before selection; choosing one never removes another supported member from the allowed set or turns it into a prohibited failure. Judge the task's viable set, not one rejected proposal: when at least one supported allowed choice exists, allow and select one; block only when no supported allowed choice exists, and reserve decision-required for a genuine external choice. Reject duplicate owner-held rules, extension-point bypass, unjustified heavy dependencies, plainly incomplete security-sensitive reinvention, license/platform incompatibility, forced abstraction over merely similar semantics and a second source of truth. This adds no mandatory open-source/DRY rule, quality score, stage or Gate.
+
 Implementation order, method and feedback cadence remain Goal-owned. Reuse the owning service/facade/adapter and one source of truth, keep the change minimal but complete, preserve explicit failure and resource-lifecycle semantics, and add abstraction only for a stable concept or evidenced change axis. These are guardrails, not a phase, per-edit mandate or proof that code is globally clean.
 
 After implementation and project verification, perform one current-candidate `Engineering Quality Conformance` that includes `Architecture Conformance` and every triggered falsifiable invariant. Default work embeds it in Contract Conformance; an active Long-Task embeds it only in Final Gate through existing Source-backed obligations/constraints/forbidden shortcuts, owner/path/Bindings, executable Checks and independent Assertions when functional behavior could pass separately. Never schedule both carriers, and recheck after any candidate or controlling-input change. Final Gate proves only that declared project-check-bound set, not overall code quality. A performance claim additionally requires a workload, metric, baseline or budget, environment, comparator/tolerance and project-owned measurement; static shape is not runtime proof. New/worsened debt, duplicate truth, wrong dependency direction, owner bypass, silent failure, resource-lifecycle defect, scope escape, unsupported quality claim or forbidden shortcut blocks handoff unless a bounded project-owned exception records owner, rationale, tracking and removal condition. This creates no quality artifact, matrix, second Authority, Contract field/aspect/Claim/risk type, Gate, workflow state or generic analyzer.
@@ -31,11 +33,13 @@ Both routes preserve Source authority: explicit product, business, API, data, st
 
 An active Long-Task owns the exact non-UI semantic carrier instead. Its package-managed Skill and progressive references preserve the complete Source inventory/Census, standard plus custom semantic families, atomic Fact and condition identities, Fact×required-method obligations, comparison authority, current typed results and sole Final-Gate equality. Never run a nested default semantic closure. Durable meaning still belongs in its existing owning Context; Source remains task authority, code remains implementation truth and Contract stores bindings rather than copied values. Neither route can discover unexpressed intent or prove an arbitrary Oracle semantically sound.
 
+Every machine-closing Long-Task Claim or Fact×method obligation must compile to a package-admitted current-Actual channel. The first bounded slice is plain exact JSON only: either a static implementation/configuration carrier that existed in the pre-run snapshot and is byte/identity unchanged after the runner, or a `process` product root directly spawned and observed by Harness through one temporary `ty-context-product-observation-v1` envelope. Harness owns comparison/result identity/verdict and process-runtime derivation. Custom/named project Oracles, wrappers, project actual/pass/verdict/runtime/interaction/state rows, historical sessions, browser/native/device/layout/pixel/accessibility/motion, protected values, tolerance/mask and custom locators cannot machine-close the obligation and require blocking External Confirmation. A machine Counterfactual without admitted baseline/mutated actual fails; static structure never proves runtime reachability. Public project results remain v3, and this compiled projection adds no Contract Authority, Gate, state or Observer registry.
+
 ## Selected-Design Conformance Obligation
 
 This obligation activates only for a selected implementation handoff. Run `ty-context design-resource preflight <handoff.md>` before UI Authority Closure. A formal Web/App target needs one completely acquired machine-readable canonical entry, its exact dependency closure and one frozen-Inspector observable-Fact manifest. Authoring derives the complete scoped `subject × target × condition × variation × atomic property` Expected Fact Universe before generation; complete Census, axis/combination/property expansion, explicit N/A/exclusions and non-sampling/non-truncation must prove `Expected Fact Universe = Canonical Resource Facts = Handoff Indexed Facts`. Product Control and eight-dimension roll-ups are not the Fact ceiling. Preserve exact located values and design-system lineage in canonical resources, every property-required Fact × method obligation, comparator/tolerance/mask, Oracle/environment and sensitive-observation policy; an exact target also needs full-target layout and pixel Facts for every condition. Deliberately partial input remains a constraint or blocking unresolved. Incomplete acquisition, aggregate labels, unreadable Census/locators, missing/extra Fact Cells or proofs, unresolved conflicts/blockers, unsupported evidence or stale digests fail closed. Preflight proves input completeness/integrity relative to the named Inspector/Oracle TCB, never production conformance.
 
-UI symbolic V2 is explicit opt-in; V1 remains the default. A V2 target must preserve the complete extensional `subject/relation × target × reachable condition/variation × applicable atomic property × population/quantifier` denotation, with constant located Rule values, mutually exclusive exhaustive regions and distinct Fact Rule, proof-obligation and set-valued certificate identities. Applicability may retain exact physical remainder partitions or use package-owned subject property profiles plus frozen Inspector custom-property closure and explicit unique instance exceptions; every logical subject-property point still has exactly one disposition. An omitted axis requires both Source-side and production-side proof through frozen closed-world static dependency closure, restricted-IR exact equivalence or finite complete-domain exhaustive equivalence; dynamic/reflected/unfrozen/external or sampled dependencies block. One Contract may mix V1 and V2 targets; bind V1 to exact Fact results and V2 to exact Rule-method-region plus freshly recomputed certificate results in the existing sole Final Gate. V1 admission uses stat/bounded-prefix capacity checks and fails rather than truncating or silently switching. Purpose-fulfillment efficiency non-degradation is a package mechanism-change admission property, not an AcceptedDeliveryTerminal condition. Non-UI symbolic admission and Provider/P0 trust-boundary work remain out of scope.
+UI symbolic V2 is explicit opt-in; V1 remains the default. A V2 target must preserve the complete extensional `subject/relation × target × reachable condition/variation × applicable atomic property × population/quantifier` denotation, with constant located Rule values, mutually exclusive exhaustive regions and distinct Fact Rule, proof-obligation and set-valued certificate identities. Applicability may retain exact physical remainder partitions or use package-owned subject property profiles plus frozen Inspector custom-property closure and explicit unique instance exceptions; every logical subject-property point still has exactly one disposition. An omitted axis requires both Source-side and production-side proof through frozen closed-world static dependency closure, restricted-IR exact equivalence or finite complete-domain exhaustive equivalence; dynamic/reflected/unfrozen/external or sampled dependencies block. One Contract may mix V1 and V2 targets; bind V1 to exact Fact results and V2 to exact Rule-method-region plus freshly recomputed certificate results in the existing sole Final Gate. V1 admission uses stat/bounded-prefix capacity checks and fails rather than truncating or silently switching. Purpose-fulfillment efficiency non-degradation is a package mechanism-change admission property, not an AcceptedDeliveryTerminal condition. Non-UI symbolic admission remains out of scope; machine-observer and verifier/runner trust-boundary closure is mandatory rather than deferred Provider/P0 work.
 
 Every non-interference proof needs a digest-identified frozen executable Oracle with the exact `symbolic_noninterference.<side>.<method>` capability. Source proof uses one canonical package-owned restricted Source IR in the complete current Inspector inputs; the package binds its current bytes to target/certificate/Rule scope and derives the DAG, predicate or complete finite-domain evaluation itself. Submitted graph/predicate/evaluation/pass fields and the immutable artifact are cache/bindings only: preflight requires current recomputation, artifact bytes and proof cache to agree, while excluding the artifact from semantic inputs. Executable/CSS/implicit-DOM/template/dynamic/reflected/computed/unfrozen/external Source blocks. Production remains limited to the package-parsed static HTML plus inert JSON subset. Both sides bind implementation closure/version/capability, environment, exact current inputs, side snapshot, scopes, omitted axes, method result, artifact and witness; their proof digests bind the existing current Final-Gate certificate result. Extraction outside admitted representations remains an explicit TCB boundary.
 
@@ -65,16 +69,16 @@ Long-Task Final Gate is the sole `Engineering Quality Conformance`, `Architectur
 
 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.
 
-Long-Task Anti-Degradation Assurance requires mechanism changes to preserve or strengthen coverage, false-negative resistance, fail-closed Authority and final-snapshot proof before positive net ROI matters. Replacing the controlling purpose requires an explicit project-owner design-purpose decision plus replacement proof.
+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.
 
-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 sole Long-Task Workflow Skill and package-owned lifecycle Hooks; an exact `.codex` root may also receive the optional fixed Codex worker profile. The retired Source Plan pointer is not installed. `design-system-authoring` is explicit-only.
+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 sole Long-Task Workflow Skill and package-owned lifecycle Hooks; an exact `.codex` root may also receive the optional fixed Codex worker profile. Retired standalone authoring pointers are not installed. `design-system-authoring` is explicit-only.
 
 ## Durable Facts And Generated Surfaces
 
 - Context is intended ownership/boundary/contract truth; code is current implementation truth. Treat disagreement as drift, missing work or stale Context.
 - Long-term facts live only in `project_context/**` or `DESIGN.md`. Selected targets remain Context-reachable Source/verifier inputs; generated screenshots/diffs/logs/raw evidence/runtime state/Receipts do not become Context.
 - Managed `AGENTS.md` blocks, `<harnessRoot>/ty-context-managed/**` and package-managed Skills are generated and sync-overwritten.
-- Explicit upgrades use `context_harness_upgrade`; package sync never imports retired Campaign or development-period authority state.
+- Explicit upgrades use `context_harness_upgrade`; package sync never imports retired orchestration or development-period authority state.
 
 ## Verification
 

package/assets/skills/context_development_engineer/SKILL.md

@@ -18,7 +18,7 @@ When a valid Long-Task binding is active, `long-task-workflow` alone owns Source
 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.
 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.
+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.
 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.
@@ -45,6 +45,14 @@ Correctness/invariants and maintainability/changeability always receive at least
 
 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.
+
+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.
+
+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`.

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

@@ -1,6 +1,6 @@
 ---
 name: design-resource-authoring
-description: Use when the user explicitly asks to generate, author, commission or iterate design resources; use Open Design; create a scoped wireframe, prototype, visual candidate, component/control state study or implementation handoff; or asks to 生成设计资源, 使用 Open Design, 生成原型图, 生成高保真/低保真设计, 为开发准备设计资源, or 先看一个控件/页面效果 in a Minimal Context Harness project. Do not trigger for generic design discussion, UX audits, ordinary UI implementation, local CSS fixes, durable Design Authority adoption, initial product-proposal authoring or Long-Task execution.
+description: Use when the user explicitly asks to generate, author, commission, iterate or recover design resources; use Open Design; create a scoped wireframe, prototype, visual candidate, component/control state study or implementation handoff; or asks to 生成设计资源, 使用 Open Design, 生成原型图, 生成高保真/低保真设计, 为开发准备设计资源, 恢复设计资源任务, or 先看一个控件/页面效果 in a Minimal Context Harness project. Do not trigger for generic design discussion, UX audits, ordinary UI implementation, local CSS fixes, durable Design Authority adoption, initial product-proposal authoring or Long-Task execution.
 ---
 
 # Design Resource Authoring
@@ -9,14 +9,14 @@ Commission the smallest sufficient resource set for the user's explicit output/d
 
 ## Hard boundaries
 
-- A raw proposal, plan, brief, screenshot or existing resource is valid input. Never require, create, invoke, regenerate or edit a Source Plan.
+- A raw proposal, plan, brief, screenshot or existing resource is valid input. Never require or create a special intermediary planning format, and never rewrite caller-owned Source except for the one explicitly selected proposal reconciliation.
 - The explicit output/development scope is a hard ceiling. Necessary surrounding context may orient the slice but cannot expand it.
 - Candidates are ordinary external Source. They do not select themselves, become `exact-target`, update `DESIGN.md`/Context or prove implementation acceptance.
 - Keep candidate effects in a task-local buffer. Only after explicit selection or explicitly delegated selection may accepted decisions be reconciled once and idempotently into the initial proposal; never write rejected/unresolved meaning as accepted.
 - Never mutate `project_context/**`, `DESIGN.md`, a Delivery Contract, production code or tests as a resource-authoring side effect.
 - Do not require a prototype, fidelity pair, provider-native file, fixed directory, variant count, resource pack or one artifact per control. Reuse selected component families and group repeated controls.
 - Visual resources may express user-visible interaction/presentation but cannot invent or become sole owner of business, data, permission or algorithmic rules.
-- Do not install/configure MCP, plugins, authentication or disclosure paths without separate authorization. Create no provider registry, workflow state, authority lifecycle, scheduler or acceptance record.
+- Do not install/configure MCP, plugins, authentication or disclosure paths without separate authorization. Create no provider registry, global workflow state, authority lifecycle, scheduler or acceptance record.
 
 ## Progressive references
 
@@ -25,6 +25,8 @@ Commission the smallest sufficient resource set for the user's explicit output/d
 3. Read [downstream-handoff.md](references/downstream-handoff.md) only when selection, proposal reconciliation or downstream handoff is material. A simple unselected preview may stop without it.
 4. Read [formal-selected-web-app-handoff.md](references/formal-selected-web-app-handoff.md) completely only for an explicitly final selected Web/App implementation handoff. Exploration, unselected previews, reference-only resources and non-Web/App commissions never load this reference.
 
+For simple-preview overhead accounting, the requested preview is neither additional Provider generation nor an added tool action.
+
 ## Workflow
 
 1. Name in-scope surfaces/flows/regions/component families/unique controls, conditions, necessary context, exclusions and intent: `exploration`, `handoff` or `selected-source-preparation`.
@@ -32,8 +34,8 @@ Commission the smallest sufficient resource set for the user's explicit output/d
 3. Classify the commission `style-bearing` or `non-fidelity`. Style-bearing means high fidelity/brand/visual direction/typography/color/density/component treatment/production-style prototype. IA/flow topology, low-fidelity structure and semantics-only state studies are non-fidelity.
 4. For style-bearing work, read configured Design Authority and its exact-value token source. If unconfigured, stop before provider project/run creation and route the user to explicit `$design-system-authoring`; never invoke it automatically. Non-fidelity work remains allowed.
    A combined explicit request authorizes running `$design-system-authoring` first and then resuming this Skill.
-5. Discover only the live provider capabilities needed by the bounded commission. Give every considered resource one disposition—`selected`, `optional`, `not-needed`, `unavailable` or `decision-required`—with a reason. Ask only when a missing preference materially changes the result.
-6. Bind style-bearing provider work to the adopted design-system identity, send only the scoped product/resource commission and keep provider execution, artifact readiness, design suitability, final selection and authority adoption distinct.
+5. Discover only the live provider capabilities needed by the bounded commission. For a formal generation, major revision or critical regeneration, apply the provider reference's `highest_available_capability + highest_supported_reasoning_effort` policy and fail closed when eligible candidates cannot be authoritatively ranked; never infer rank from price, name, release date or list order, and never claim an effective model/effort the run cannot confirm. Give every considered resource one disposition—`selected`, `optional`, `not-needed`, `unavailable` or `decision-required`—with a reason. Ask only when a missing preference materially changes the result.
+6. Bind style-bearing provider work to the adopted design-system identity, send only the scoped product/resource commission and keep provider execution, model-selection verification, artifact readiness, design suitability, final selection and authority adoption distinct.
 7. Iterate within scope. Exploration returns a visible candidate after minimal sanity review. Do not burden it with handoff schema, hashes, complete Fact closure or downstream validation.
 8. After final selection, preserve immutable identity and editable-upstream provenance; reconcile accepted proposal effects once. If an implementation handoff was requested, use the applicable downstream reference—and the formal reference only for selected Web/App targets.
 

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

@@ -18,7 +18,7 @@ Design resources may show user-visible triggers, transitions, states, feedback a
 
 ## Reconcile the initial proposal once
 
-During iteration, keep a task-local buffer of selection basis, selected immutable/editable identities, accepted decisions, rejected alternatives, unresolved choices and affected product/surface/control/state/interaction/visual keys. This is reasoning, not a schema or required file.
+During a simple iteration, keep a task-local buffer of selection basis, selected immutable/editable identities, accepted decisions, rejected alternatives, unresolved choices and affected product/surface/control/state/interaction/visual keys. This is reasoning, not a schema or required file. If the loop is material enough to require replayable Delta, a file writeback or interruption recovery, stop and read [recovery-and-writeback.md](recovery-and-writeback.md); do not approximate safe recovery/CAS from this lightweight reference.
 
 After final selection:
 
@@ -30,7 +30,7 @@ After final selection:
 6. make reruns idempotent by updating the existing decision/reference;
 7. edit the authorized writable initial-proposal file, or return one complete revised proposal when it exists only in conversation.
 
-Never mutate a Source Plan, Context, `DESIGN.md`, Contract, production code or tests. If no selection occurs, return candidates and the pending delta without changing the proposal.
+Never mutate other caller-owned Source, Context, `DESIGN.md`, Contract, production code or tests. If no selection occurs, return candidates and the pending delta without changing the proposal.
 
 Small requests may complete generation, selection and reconciliation in one turn; “once” describes the semantic writeback, not a required pause.
 

package/assets/skills/design-resource-authoring/references/open-design-provider.md

@@ -25,6 +25,25 @@ Current structured tool names may include `list_agents`, `list_skills`, `list_pl
 
 Functional skills and rendering templates are different registries. Finding `frontend-design` does not prove that a `mobile-app` or `wireframe-mobile-flow` template is installed, and a remembered template ID is not live capability evidence.
 
+## Highest-performance generation selection
+
+Open Design quality takes precedence over model-call price for every formal first generation, every major revision and every final-candidate defect repair that requires material regeneration. A major revision changes the adopted visual direction or design system, cross-surface information architecture, primary interaction model, or enough of the selected canonical source/Fact manifest to invalidate the former candidate. Pure discovery, reads, resource enumeration, metadata queries and review of an already sufficient selected resource do not trigger this policy.
+
+The durable policy is `highest_available_capability + highest_supported_reasoning_effort`, not a permanent model name. Apply it immediately before each applicable run:
+
+1. Discover the live provider/tool schemas and returned agent/model metadata. Determine whether the actual run surface exposes model, reasoning-effort or service-tier inputs and which run/project/result fields can confirm their effective values. Never invent an input or result field that the provider does not expose.
+2. Filter to eligible models before ranking. Eligibility requires every tool, visual/multimodal capability, context capacity, authentication path and data-residency/disclosure boundary required by the commission. An ineligible model cannot win on nominal capability.
+3. Rank eligible models only by the provider's explicit capability order or documented recommended-replacement relation. If that is absent, the sole permitted fallback is one versioned, evidence-linked provider-local mapping owned in this reference; do not duplicate it in the main Skill, Context, README, tests or adapters. Price, model-name shape, publication date, apparent generation number and provider list order are not ranking evidence. This reference currently defines no fallback entries: when live provider evidence cannot order two or more eligible candidates, stop formal generation or major revision with `highest_performance_unverified` instead of guessing.
+4. For the selected model, use its actually declared ordered legal reasoning-effort values and select the highest supported value. Examples such as `max` or `xhigh` illustrate possible highest values; they are not a cross-provider ordering or permanent product vocabulary. If several advertised values cannot be authoritatively ordered, the highest effort is unverified and the applicable generation must fail closed.
+5. Keep service tier distinct from model capability and reasoning effort. Discover and report it when the provider exposes control or provenance, but never use price, latency tier or a service-tier label to rank model capability.
+6. When model selection is controllable, requesting anything below the proved highest eligible model is an invocation error. When reasoning is controllable, requesting anything below the proved highest supported effort is likewise an error. A missing remembered example model is not an error when live evidence selects a different actual highest model.
+7. Compare requested values with the effective model, reasoning effort and service tier reported by the completed run. A mismatch fails the run. If the provider accepts a request but does not expose effective provenance, keep the result `highest_performance_unverified`; do not claim the requested values were used.
+8. If the provider exposes reasoning control but no model control, request the proved highest effort and report that model selection could not be independently enforced. If it exposes neither control nor enough candidates to create an unresolved ranking choice, its current default generation path may be used, but the result remains `highest_performance_unverified`. If it explicitly exposes multiple eligible models and no authoritative order, rule 3 blocks the run.
+
+Capability discovery happens at call time so a provider's new highest model or effort can replace an older example without a Skill edit. This is a provider adapter policy, not a scheduler: create no persistent model registry, routing state, retry loop or cross-provider optimizer. Reduce cost by avoiding unnecessary generations, irrelevant resources and separable revisions, or by reusing a sufficient selected resource—never by lowering the generation model or effort.
+
+Repository tests can prove only that these branches remain distributed in the managed guidance. Only a normalized live provider trace that freezes provider/version, candidate and eligibility metadata, ranking authority, request fields and effective result provenance can prove the model and effort actually used. Without that trace, report the boundary as unverified.
+
 ### Rendering-template discovery compatibility
 
 Prefer, in order:
@@ -56,14 +75,14 @@ Never silently use the provider's default or a different system. A provider-side
 
 ## Structured commission sequence
 
-1. Record provider version, selected agent/model, functional capability, rendering template, adopted design system and relevant plugin/export readiness as reported live.
+1. Record provider version, selected agent/model, reasoning effort and service tier when exposed, functional capability, rendering template, adopted design system and relevant plugin/export readiness as reported live. For an applicable generation, retain the eligibility/ranking basis and the request-versus-effective comparison required by the highest-performance policy.
 2. Reuse an existing task-local project only when its scope, prior inputs and required design-system binding match; otherwise create a bounded project. For style-bearing work, pass `designSystem` and verify `get_project.designSystemId` before the run.
 3. Start a run with the product-specific commission envelope, provider-native capability identifier and—when the intent is a formal Web/App implementation handoff—the complete prederived authoring obligation universe. That universe is based on requested scope, product semantics, adopted design system and target environments; it must not be inferred only from provider output.
 4. Poll with a bounded cadence. During a long run, report meaningful progress at least once per minute without flooding the user.
 5. Preserve run IDs and the latest provider diagnostic. Support cancellation when the user requests it and the provider exposes it.
 6. Resolve the actual entry explicitly, retrieve the artifact/source, inspect it according to intent and preserve its immutable identity before later iterations or handoff.
 
-Open Design may launch Codex CLI as its configured inner agent. That is provider execution, not recursive invocation of this outer Skill. Do not hardcode a model when the provider can report the current configured model.
+Open Design may launch Codex CLI as its configured inner agent. That is provider execution, not recursive invocation of this outer Skill. Do not hardcode a remembered model when live discovery and authoritative ranking can select the current highest eligible model.
 
 ## Separate three kinds of state
 
@@ -138,3 +157,4 @@ Figma, Penpot, OpenPencil, image, video, 3D/WebGL and other providers are option
 - Re-discover capability after provider upgrades or registry mismatches.
 - If structured paths fail but a UI artifact exists, UI inspection may recover it while retaining the degraded-provider qualifier.
 - If the provider is unavailable and no justified fallback exists, return `unavailable` with the minimum setup needed rather than generating with an unrelated image tool and calling it equivalent.
+- Provider recovery and DRA semantic recovery are separate: this reference may re-read the current run/resource identity, while [recovery-and-writeback.md](recovery-and-writeback.md) alone owns Base/Delta replay, the conditional checkpoint and Proposal CAS. Never restore a live Provider state or suitability conclusion from that checkpoint.