project-tiny-context-harness 0.8.16 → 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 必须在实现前无条件结束当前回合，并输出 `处理好模型更换后，请仅回复：模型切换卡点解除，继续`。普通“继续”不满足 managed prompt protocol；此前任何模型策略文字都不能跳过该边界，Harness 也不能观察下一条宿主消息或模型是否真的改变。用户恢复后，父 Goal 先识别合格的有界工作包，再判断 profile/capacity；没有用户或宿主显式禁止时，合格集合必须实际调用多个精确 `long_task_implementation`，由宿主结果进入六理由 zero-start 或 partial delegation。数量保持动态，禁止 generic 替代项；Source、Contract、Authority、架构、Context、工作包选择、集成、当前候选检查、正式验证、Final Gate、close 与 completion 始终只由父 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 边界。
@@ -233,7 +241,7 @@ Long-Task 投影继续要求每个 Claim-bearing Assertion 只绑定一个 Claim
 
 repository pattern 只把圆括号作为经过转义的 route-group 字面字符，不把它们解释成正则分组或 extglob；现有 `*`、`**`、`?` 语义保持不变，`[]`/`{}` 仍不受支持。
 
-对 material 工作，`context_uiux_design` 应用上面的投影规则并让风险比例化 coverage reasoning 保持 task-local。`context_development_engineer` 用稳定 surface/control key 把每个受影响的 selected target 和声明 condition 追踪到生产 route/component owner、冷启动真实用户旅程及适用的渲染/交互检查。第一个有价值的可运行纵向切片只是建议性的真实入口反馈点，不是实现门禁；最终候选仍必须重跑受影响的冷启动旅程。Source 已明确要求的组合不能静默删减，但默认路线应报告未被证据建立的条件，而不是声称精确机器闭包。资源哈希、manifest 和数量只证明资源完整性，实现截图既不能成为自己的目标，也不能单独证明实现一致性。
+对 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 权威。
 
@@ -241,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
 
@@ -253,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` 验证一致。
 
@@ -265,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 兼容
 
@@ -349,7 +361,7 @@ Formal collection 的 11-scenario catalog 是 scenario/source/zero policy 的唯
 
 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.16 是当前 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` 表示。
+真实采集当前为 `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。
 
@@ -450,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
@@ -462,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`，不支持指标不会以零值制造通过假象。
 
 ## 诚实限制

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.
 

package/assets/skills/context_development_engineer/references/engineering-design-reasoning.md

@@ -0,0 +1,93 @@
+# Engineering Design Reasoning
+
+Use this reference only after `context_development_engineer` has been selected for material engineering-design or architecture judgment. It deepens the existing Architecture Deliberation; it does not create a design phase, plan artifact, evidence ledger, second workflow or acceptance carrier. Apply the smallest useful subset below and state when a method is not material.
+
+## 1. Frame what is actually known
+
+Separate four categories before choosing a design:
+
+- **Facts:** user/Source/Context requirements, repository owners and extension points, observed code/test behavior and externally verified dependency facts.
+- **Constraints:** compatibility, platform, policy, budget, rollout, security, data, lifecycle and scope boundaries that a legal solution must preserve.
+- **Assumptions:** plausible but unproved premises currently needed to proceed. Name who can validate them and what changes if they are false.
+- **Unknowns:** missing information that distinguishes alternatives, changes safety or makes an acceptance claim unsupported.
+
+Current code is implementation evidence, not silent product or architecture authority. A genuine product, legal, security, commercial, safety or external choice remains `decision-required`; implementation-equivalent freedom belongs to the current Goal.
+
+## 2. Identify drivers and path dependence
+
+Name the few forces that materially shape the solution: owner/source-of-truth location, dependency direction, data/state boundaries, lifecycle and failure semantics, compatibility commitments, load/threat conditions and verification reachability. Distinguish an enduring invariant from historical path dependence such as an old API, migration window, installed dependency or deployment constraint. Preserve path dependence only while its reason still applies; do not mistake legacy shape for the desired architecture.
+
+For each material driver, point to repository evidence or authoritative external evidence. If current dependency/library behavior matters and may have changed, use current primary documentation rather than memory.
+
+## 3. Build the smallest material alternative set
+
+Enumerate only alternatives that could plausibly change an owner, boundary, lifecycle, dependency, operational risk or future change cost. Include the current extension point or intentional non-abstraction when viable. When sourcing is material, express Build / Reuse / Buy as the existing allowed solution set, prohibited failure modes and required rationale/evidence.
+
+Steelman every material alternative before rejecting it:
+
+- where it fits the requirements well;
+- its cleanest owner and dependency direction;
+- the strongest reason a competent maintainer would select it; and
+- the evidence or condition under which it would become preferable.
+
+Do not manufacture alternatives for a local choice whose owner and semantics are already explicit. Do not relabel an unselected allowed option as a prohibited failure.
+
+## 4. Use counterfactuals and failure paths
+
+Challenge the leading design with at least one realistic adjacent change and one relevant failure:
+
+- If the next client, provider, state, data volume, permission model or workflow variation arrives, which existing extension point absorbs it?
+- If the selected dependency is unavailable, stale, slow, partial or incompatible, which failure is visible and where does recovery live?
+- If the main assumption is false, which decision changes and which parts remain valid?
+- What would make the rejected alternative win?
+
+Trace only triggered retry, timeout, cancellation, idempotency, transaction, concurrency, consistency, degradation, recovery and resource-release semantics. A family that is not material gets a concise preservation basis rather than invented machinery.
+
+## 5. Select risk-triggered methods
+
+Choose methods for the actual uncertainty; never run all of them by default:
+
+| Trigger | Useful method | Minimum output |
+| --- | --- | --- |
+| Unclear owner or dependency boundary | Repository owner/extension-point trace | One source of truth, legal dependency direction and prohibited bypass |
+| API/schema/data/state change | Contract and state-transition analysis | Inputs/outputs/errors, invariants, ownership, compatibility and recovery |
+| Shared mutable state or parallel execution | Interleaving/consistency analysis | Atomicity boundary, ordering, idempotency and failure recovery |
+| External integration or mature protocol | Current primary-source and repository-fit research | Supported allowed set, compatibility/security/maintenance evidence |
+| Material performance/capacity/cost risk | Complexity model plus project-owned measurement | Workload, metric, baseline/budget, environment and comparator/tolerance |
+| Trust, permission or sensitive data boundary | Threat/abuse-path analysis | Assets, actors, trust crossings, prohibited failures and attributable checks |
+| Public or versioned compatibility change | Migration/rollout analysis | Compatibility window, upgrade/rollback path and current-version evidence |
+| High uncertainty that code can cheaply resolve | Minimum architecture experiment | Hypothesis, smallest observable probe, budget and exit condition |
+
+Research or an experiment informs the decision but is not durable authority or product acceptance. Preserve only stable conclusions in their owning Context.
+
+## 6. Design a minimum architecture experiment
+
+Use an experiment only when a material unknown distinguishes legal alternatives and repository inspection or authoritative documentation cannot answer it cheaply. Define:
+
+- the exact question and competing hypotheses;
+- the smallest representative fixture or probe that can falsify the leading assumption;
+- environment, inputs, metric/observation and comparator;
+- time/resource budget and stop condition; and
+- how each possible result changes the design.
+
+Do not turn a spike into production by default. Representative input proves only its declared scope; it cannot establish an all-provider, all-interface, all-platform or full-population claim.
+
+## 7. Project the decision into implementation
+
+Before handoff to the current Goal, make the design concrete enough to implement without inventing a second architecture:
+
+- owning modules, paths and symbols plus the existing extension point;
+- public/internal interfaces, inputs, outputs and explicit error semantics;
+- data and state owner, persistence boundary and invariants;
+- runtime/resource lifecycle, initialization, cleanup, recovery and observability;
+- dependency direction and forbidden shortcuts;
+- compatibility/migration/rollout handling when applicable;
+- the smallest complete implementation surface and any intentional non-goals;
+- project-owned type/lint/AST/dependency/contract/behavior/benchmark/probe checks; and
+- `Context Delta: none|required`, with the smallest durable owner updated before code when required.
+
+## Architecture audit route
+
+For an audit, compare the current implementation against controlling Source/Context and the concrete owner/boundary model above. Report wrong owner, duplicate truth, reversed dependency, extension-point bypass, silent failure, incomplete lifecycle/recovery, unsupported quality claim and new/worsened debt separately. Distinguish observed defects from assumptions and unverified risks. Do not implement repairs unless the request also authorizes change.
+
+The final current-candidate Engineering/Architecture Conformance remains in the existing default Contract Conformance or, when validly active, the sole Long-Task Final Gate. This reference creates neither.

package/assets/skills/context_surface_contract/SKILL.md

@@ -45,7 +45,7 @@ Use the narrowest mode that matches the request:
 
 - Audit Mode: inspect whether existing surfaces have clear responsibility.
 - Compile Mode: turn audit findings or user decisions into Context candidates.
-- Apply Mode: write durable Context only when the user explicitly allows durable writes.
+- Apply Mode: write durable Context only when the user explicitly allows durable writes, or when already-authorized product/UI implementation independently yields `Context Delta: required` in the current Goal.
 - Conformance Mode: check implementation against an existing Product Surface Contract.
 
 Do not run implementation, long validation, browser smoke, app smoke or CLI smoke unless the user explicitly asks for execution.
@@ -85,7 +85,7 @@ Do not assume business responsibilities from current code shape alone. Ask for c
 
 ## Apply Mode
 
-Use only when the user explicitly allows durable writes.
+Use only when the user explicitly allows durable writes, or when product/UI implementation is already authorized and the current Goal independently decides that durable Surface/Screen responsibility changed. Skill activation, analysis, audit, candidate comparison or resource generation alone never grants write authority.
 
 Allowed writes:
 
@@ -126,7 +126,13 @@ For each touched surface, answer only what is relevant:
 
 - What surface is being touched?
 - What platform shape does it have?
+- Which authoritative target-user and usage-context reference applies?
 - What primary user question does it answer?
+- What primary task outcome, primary work object and shortest task loop does it support?
+- Which critical context must remain visible while the user acts?
+- How are each material operation, affected object and feedback related?
+- Does the task force repeated scrolling, navigation or context switching to make one judgment?
+- Which client/host, input-method and size-class constraints change the interaction topology?
 - What belongs on the main surface?
 - What must move to drilldown, diagnostics, operations, evidence or technical detail?
 - Which long-running or mutating actions require task id, progress, retry, import, recovery or history?
@@ -138,6 +144,7 @@ When screen depth is material, also answer only the applicable questions:
 
 - What stable surface/route key, entry context, exit outcome, inherited state and committed state identify the screen?
 - What is the semantic information order and which regions are fixed, scrolling or overlay-owned?
+- Across supported size classes, which regions remain, reflow, collapse, become sheets/sidebars/modals or move to another surface, and how is the primary work object preserved?
 - Which navigation, back/cancel, focus restoration, interruption and responsive/mode/state variants are durable?
 - For each material stable control key, what are its region/location, type/label, user task, visibility/availability, trigger/input/validation/default, interaction/navigation, loading/empty/success/failure/recovery/permission/feedback and accessibility semantics?
 - Which exact-target/constraint/inspiration IDs govern which declared conditions, and which verification path proves each independent claim?
@@ -158,6 +165,10 @@ For any task touching user-facing surfaces, information placement, forms, filter
 - Surface Platform: `<web | mobile | desktop | game | cli-tui | extension | embedded | mixed>`
 - Owning Product Domain: `<area / subdomain>`
 - Primary User Question: `<one concrete user judgment>`
+- Primary Task Outcome / Work Object / Loop: `<outcome; object; orient-act-feedback-finish loop>`
+- Critical Context Kept Visible: `<context required while acting>`
+- Operation–Object–Feedback: `<material relationship>`
+- Client / Size-Class Topology: `<host/input constraints and region changes>`
 - Main Surface Allows: `<durable visible information and actions>`
 - Main Surface Forbids: `<backend fields, raw payloads, diagnostics, debug ids, fake states, etc.>`
 - Drilldown Ownership: `<details / evidence / operations / diagnostics / technical details>`

package/assets/skills/context_uiux_design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: context_uiux_design
-description: Use when the user explicitly asks to establish, adopt or repair durable UI/UX Design Authority, DESIGN.md, design-system governance, visual tokens/rationale, adopted target interpretation, UI Authority Closure, selected-design alignment, or durable visual standards in a Minimal Context Harness project. Do not trigger for product/surface responsibility, design-resource generation, ordinary UI implementation, local CSS/UI fixes, copy edits, or an unselected visual exploration.
+description: Use when the user explicitly asks to establish, adopt or repair durable UI/UX Design Authority, DESIGN.md, design-system governance, visual tokens/rationale, adopted target interpretation, UI Authority Closure, selected-design alignment or durable visual standards; or when actual task content requires material UI/UX analysis or audit for a new page/flow/complex control, information hierarchy, fixed/scroll/overlay/sheet/sidebar/modal topology, map/canvas/editor work, primary task and feedback loop, client adaptation, navigation/recovery/states or accessibility in a Minimal Context Harness project. Do not trigger merely for product/surface responsibility, design-resource generation, ordinary local UI implementation, CSS/copy/icon/image fixes, local exact-target alignment, a single-control visual preview or an unselected visual exploration.
 ---
 
 # Context UI/UX Design
@@ -11,7 +11,11 @@ Own durable Design Authority only: root `DESIGN.md`, visual identity and exact-v
 
 This Skill does not own product goals/business rules/acceptance (`context_product_plan`), information/action/feedback and main/drilldown responsibility (`context_surface_contract`), resource generation (`design-resource-authoring`), implementation, or acceptance. Route rather than duplicate those owners.
 
-Project-specific UI/UX rules may live in `<harnessRoot>/skills/uiux_design/SKILL.md`; durable facts remain in `DESIGN.md` and owning `project_context/**`. Active Long-Task retains its one Source/Contract lifecycle and Final Gate; this Skill contributes authority closure only.
+Project-specific UI/UX rules may live in `<harnessRoot>/skills/uiux_design/SKILL.md`; durable facts remain in `DESIGN.md` and owning `project_context/**`. When a valid Long-Task binding is active, `long-task-workflow` alone owns Source/Contract lifecycle, formal verification, Final Gate and completion. This Skill may contribute non-authoritative task-level UI/UX analysis and Design Authority closure, but creates no second plan, lifecycle, Authority, Gate or acceptance path.
+
+## Task-level analysis adapter
+
+For a material task-analysis trigger, read [task-uiux-analysis.md](references/task-uiux-analysis.md) completely and apply only the relevant methods. This adapter is non-authoritative: Product/Surface/Screen Source owns the user, page duty, primary task/work object, information/action/feedback and interaction-topology facts; this Skill still owns durable Design Authority only. The current Goal may compare and select implementation candidates under those constraints. A conflicting candidate cannot proceed to resource generation or implementation until the stale owner is authoritatively updated or a genuine decision is obtained.
 
 ## UI Authority Closure
 
@@ -23,7 +27,7 @@ Project-specific UI/UX rules may live in `<harnessRoot>/skills/uiux_design/SKILL
    - screen/interaction targets are fully owned by the owning Screen Contract, with `DESIGN.md` keeping only the stable key and owner/anchor;
    - the record preserves interpretation, selection basis, immutable path/URI and digest, applicable conditions and editable upstream owner/locator/update route.
 5. Never overwrite an adopted baseline. Create a new immutable version/digest, review it deliberately and update the unique canonical record. An implementation render/diff is evidence and cannot become the target it claims to match.
-6. Decide exactly one `Context Delta: none|required`. Durable visual-system, token, rationale, adopted interpretation, owner/anchor or verification-route change is `required`; ordinary UI/CSS fixes that preserve authority are `none`.
+6. Decide exactly one `Context Delta: none|required`. Skill activation, analysis, audit or candidate comparison alone authorizes no durable write. Durable visual-system, token, rationale, adopted interpretation, owner/anchor or verification-route change is `required`; ordinary UI/CSS fixes that preserve authority are `none`. When product/UI implementation is already authorized and the current Goal independently finds a durable Surface/Screen change, update the smallest owning Surface Context before code or return `decision-required`.
 7. Route unresolved surface placement to `context_surface_contract`; route any request to generate/iterate a wireframe, prototype, visual candidate, state study or handoff to `design-resource-authoring`. Do not invoke resource generation implicitly.
 
 ## Selected-design alignment