project-tiny-context-harness 0.8.17 → 0.11.0

package/assets/README.zh-CN.md

@@ -16,18 +16,18 @@ Tiny Context 将这些能力保持为窄边界。两条实现路径共用一次
 
 ## 三个机制如何配合
 
-| 机制 | 何时、如何使用 | 负责什么 |
-|---|---|---|
-| **Minimal Context** | 默认安装；每种交付路径都会读取并按需更新 `project_context/**`。 | 保存目标、归属、架构/接口/状态边界和可重复验证/部署等耐久事实；不声称实现或测试已经通过。 |
-| **Workflow Contract** | `init` 后自动生效，适用于任何复杂度；只有显式选择或已有有效绑定时才不走此路线。没有 Skill 命令，也不创建 `delivery-contract.yaml`。 | 执行 model-led 轻量循环：Context 发现、风险比例化需求/架构判断、唯一 `Context Delta`、Goal-owned 实现、当前候选项目检查、失败返工、证据边界内 Contract Conformance 与 Context drift；不产生精确 Fact 账本、validator 结果、Receipt、持久状态或机器完成权威。 |
-| **Long-Task Workflow** | 先启用一次 `long-task` profile；需要机器完成权威、跨压缩/会话恢复或审计时显式选择 `long-task-workflow`，已有有效绑定时恢复。任务大小不会自动启用。 | 持有一份 Source-bound Delivery Contract、Authority Lock、可恢复局部进度、受保护修订、精确声明义务证据和当前快照 Live Final Gate。 |
+| 机制                   | 何时、如何使用                                                                                                                                     | 负责什么                                                                                                                                                                                                                                                     |
+| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **Minimal Context**    | 默认安装；每种交付路径都会读取并按需更新 `project_context/**`。                                                                                    | 保存目标、归属、架构/接口/状态边界和可重复验证/部署等耐久事实；不声称实现或测试已经通过。                                                                                                                                                                    |
+| **Workflow Contract**  | `init` 后自动生效，适用于任何复杂度；只有显式选择或已有有效绑定时才不走此路线。没有 Skill 命令，也不创建 `delivery-contract.yaml`。                | 执行 model-led 轻量循环：Context 发现、风险比例化需求/架构判断、唯一 `Context Delta`、Goal-owned 实现、当前候选项目检查、失败返工、证据边界内 Contract Conformance 与 Context drift；不产生精确 Fact 账本、validator 结果、Receipt、持久状态或机器完成权威。 |
+| **Long-Task Workflow** | 先启用一次 `long-task` profile；需要机器完成权威、跨压缩/会话恢复或审计时显式选择 `long-task-workflow`，已有有效绑定时恢复。任务大小不会自动启用。 | 持有一份 Source-bound Delivery Contract、Authority Lock、可恢复局部进度、受保护修订、精确声明义务证据和当前快照 Live Final Gate。                                                                                                                            |
 
 三者的关系是：每个任务都使用 Minimal Context；未显式选择且没有有效绑定时，默认 Workflow Contract 自动适用；只有显式选择或恢复有效绑定时，才由 `long-task-workflow` 承担执行与完成权威。复杂度决定执行与验证深度；所需完成权威与恢复能力决定工作流路线；Long-Task 内部风险决定证明强度。Long-Task 的 Final Gate 承载 Engineering Quality/Architecture Conformance 与选定设计闭环，不再重复默认 Contract Conformance。
 
-| 任务形态 | model-led、证据边界内交付足够 | 要求机器可信完整闭包 |
-|---|---|---|
-| 局部或简单 | 默认 Workflow Contract | 可显式使用 Long-Task |
-| 跨模块或复杂 | 默认 Workflow Contract 仍然有效 | 显式使用 Long-Task |
+| 任务形态     | model-led、证据边界内交付足够   | 要求机器可信完整闭包 |
+| ------------ | ------------------------------- | -------------------- |
+| 局部或简单   | 默认 Workflow Contract          | 可显式使用 Long-Task |
+| 跨模块或复杂 | 默认 Workflow Contract 仍然有效 | 显式使用 Long-Task   |
 
 `design-system-authoring` 与 `design-resource-authoring` 是基础 Profile 中独立、可选的上游设计 Skill，不是第四个机制，也不是 Long-Task 的阶段。其选定产物可以进入默认或 Long-Task 任一路径；当前唯一活跃的长程执行 Skill 是 `long-task-workflow`。
 
@@ -72,7 +72,7 @@ ty-context enable long-task
 这条路径适合既确实需要新 style-bearing 设计资源，又要求 Long-Task 机器保障/恢复/审计边界的实现交付。它组合已有能力，但不是所有 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 时跳过这一步。
+2. **仅在需要时建立或修订 Design Authority。** 项目尚无 Authority，或选定任务设计产生了可复用系统变化时，显式选择 `$design-system-authoring` 的 `bootstrap`、`revise` 或 `reconcile` 模式。候选选择与 Authority adoption 是两个决定：Skill 展示精确项目 diff 和迁移影响后，用户还要单独明确确认 adoption。当前完整 Authority closure 已覆盖该 style-bearing 范围时跳过。
 3. **准备一份可写的初始方案。** 将项目原生的产品/技术方案放在明确路径，例如 `docs/initial-proposal.md`。它可以由用户、外部服务或显式请求的适用方案能力编写。`design-resource-authoring` 不负责初始方案 authoring，也不要求经过独立的中间 authoring 阶段。
 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 持有。
@@ -80,7 +80,9 @@ ty-context enable long-task
 一组可以直接改写使用的调用顺序如下：
 
 ```text
-$design-system-authoring 为这个 style-bearing 范围生成、选择并采用项目设计系统；如果 DESIGN.md 已经配置，则跳过本请求。
+$design-system-authoring 为这个 style-bearing 范围 bootstrap 项目设计系统，展示候选和精确项目 diff，并停在单独 adoption 确认之前；当前完整 Authority closure 已覆盖范围时跳过。
+
+查看选定候选与精确 diff 后：明确采用 design-system candidate <candidate-id>。
 
 为 <交付范围> 在 docs/initial-proposal.md 准备一份可写、项目原生的初始方案。
 
@@ -98,7 +100,7 @@ $long-task-workflow 将 docs/initial-proposal.md、<handoff.md>、<feasibility.j
 - **交付前确实需要设计资源：** 按上面的设计优先顺序执行，再根据恢复与完成权威需求，把修订方案、已校验 handoff 和选定的不可变规范资源集合交给默认 Workflow Contract 或 `long-task-workflow`。
 - **只需要设计资源：** 在 `design-resource-authoring` 完成后结束；除非还明确选择了实现交付，否则不创建 Long-Task Contract。
 
-设计系统通常在项目冷启动时确定，但该 Skill 只由用户选择，`init`、`sync` 与下游 Skill 都不会自动执行。`design-resource-authoring` 只对高保真、品牌化、视觉处理等 style-bearing 资源设门禁；低保真结构、IA/流程与纯语义状态研究不受此门禁。已有计划或提案文档仍是普通 Source，但不再是推荐中间服务。
+设计系统步骤只由用户选择，`init`、`sync` 与下游 Skill 都不会自动执行。它可以 bootstrap 新 Authority、revise 现有 Authority，或 reconcile 用户提升的 DRA Authority delta candidate。`design-resource-authoring` 只对高保真、品牌化、视觉处理等 style-bearing 资源设门禁，任务资源选择绝不等于系统 adoption；低保真结构、IA/流程与纯语义状态研究不受此门禁。已有计划或提案文档仍是普通 Source，但不再是推荐中间服务。
 
 ## Minimal Context 与默认工作流
 
@@ -125,7 +127,32 @@ manifest/trigger 命中的少量 area/role Context
 
 这次搜索只补充语义判断，不会把所有关键词命中都当成 Authority，也不会创建向量/持久索引、缓存、Registry、search state 或第二权威。它仍可能漏掉完全不同的同义词或间接依赖，因此每个实现需求仍要执行 Architecture Deliberation 与收尾 Conformance。
 
-`ty-context doctor` 会报告确定性的默认 Context 文件/字节规模、单文件与总量软预算超限、字节完全相同的默认文件，以及 `DESIGN.md` 权威状态。这些只是维护提示，不是新验证 Gate 或运行时状态。如果真实的近乎通用恢复事实超过字节启发式预算，应保留事实并接受 warning；绝不能为了满足预算而遗漏、过度压缩或错误分类必需 Context。
+`ty-context doctor` 保留确定性的默认 footprint 报告，并检查全部 Context Markdown（包括未登记文件）。它会报告 default/on-demand/legacy/unregistered 的文件与字节分布、最大的 on-demand 文件、逐文件大小和最大行长、trigger fan-out、显式本地 Markdown 链接完整性，以及 `<!-- ty-context-declare Fact-ID: OBS-001 -->` 这类显式声明的重复 owner。新增发现默认都是 advisory；`--strict` 必须由项目显式采用，工具不会自行把它加入 CI。真实恢复事实始终优先于字节或行长启发式阈值。
+
+Schema v4 继续接受 `default`、`on-demand`、`always`、`optional` 和 `never-default`。只有 `default` 会因自身策略直接进入默认集合；任何由 `default_children` 引用的已登记节点都会递归进入，不受自身 policy 影响。0.10 只为三个 legacy 值提供 warning，不重新解释或自动迁移。尤其是 `always -> default` 可能扩大 footprint，而 `never-default` 与入向 default-child 边在当前版本仍兼容执行、但属于未来迁移必须显式消除的矛盾输入。
+
+独立的显式 `ty-context upgrade` 可以迁移 v4 之前的旧 `[[context_units]]` 表名，但只处理每个旧表都能证明为简单单行字段的情况。它只重命名表、删除已废弃的 `id`/`area` 字段，并保留所有未触碰字节和原始换行；复杂或混合格式 TOML、当前/旧路径冲突都会变成 `manual_required`。普通 `sync` 永不执行该迁移。
+
+验证、Doctor 与下面这些 Context 维护命令共用同一套 Catalog 解释：
+
+```bash
+ty-context route --task "修改天气地图契约" --path apps/client/src/map.ts --explain
+ty-context context inspect project_context/areas/main/weather.md --task "修改天气地图契约"
+ty-context context create --path project_context/areas/main/weather.md --role domain
+ty-context context register --path project_context/areas/main/weather.md --role domain
+ty-context context move --from project_context/deployment.md --to project_context/deployment/index.md
+ty-context context transaction status
+```
+
+`route` 是实验性、无状态的字面量候选诊断，会扫描全部符合条件的 `project_context/**`，并明确标记未登记文件。其版本化 JSON、固定候选/内容/输出预算、稳定顺序、选择原因与字节成本不建立 Authority、不参与默认 footprint，也不能替代 Workflow 仍然必需的 bounded search；预算超限会显式返回不完整结果。这些 Router 预算是在 Shared Catalog 完成仓库级 Context 发现与元数据收集后才生效；0.10 刻意保持这一步完整遍历。未来若增加总发现预算，必须由 Catalog 统一拥有、向所有消费方传播类型化的不完整状态，并让 Router 返回 `complete: false`/退出码 `4`；禁止另建 Router 专用 walker，也禁止静默截断 Validate/Doctor。`context inspect` 只读报告单个文件的登记状态、Role、读取元数据、默认选择原因、显式反向引用、稳定 key 冲突和可选路由解释。
+
+0.10.1 只增加边界明确的 `context create` 写入：它在 `project_context/**` 下发布一个 Role 专属、仅含 TODO 的 Markdown scaffold，明确标记为未登记，拒绝不安全路径、既有目标和并发出现的目标，并报告 default footprint 未变化。它不会修改 `context.toml`，不会自动创作产品或架构事实，也没有“创建并登记”或强制覆盖选项。必须先用真实 owner facts 替换全部 TODO，再单独登记；占位 scaffold 一旦登记会故意无法通过恢复性验证。
+
+后续 0.10.x mutation 命令默认都是 dry-run。`context register` 只接受一个现有、可恢复、未登记的文件，只生成规范的 `default`/`on-demand` policy，并在不改写其他 TOML 字节的前提下追加一个经 parser 验证的 `[[context]]` block。`context move` 只接受唯一登记的 Context/Area owner，同时更新 owner 与结构化 `default_children`，用 CommonMark AST 重基全部 Context Markdown 中的显式本地链接；正文、代码和配置中的精确旧路径只报告不改写。只要 bounded repository scan 不完整或仍有未决引用，apply 就会拒绝；缺失的目标目录也属于可恢复计划。
+
+实际应用的 register/move 共用当前字节与文件 identity CAS、同目录同步临时文件、完整 candidate-tree overlay 验证、确定性提交顺序、live after-state 复核，以及 `context transaction status|rollback|complete`。当前写入使用 `context-mutation-journal-v3`：不可变摘要链 generation 会把每个 NFC 逻辑 key 绑定到精确物理路径；`context-mutation-journal-v2` 仍可恢复读取，并把逻辑路径与物理路径视为相同。pre-v2 journal 必须使用匹配版本或显式人工恢复，绝不猜测或重写。恢复会记录并比较完整 before/已发布端点快照（内容、mode 和平台可用的文件 identity），只接受 journal 精确拥有的部分临时文件，并拒绝外部冲突、无 owner 链接或后来激活的 Long-Task。Long-Task 首次 Compile、activation、原位 Revision 与 mutation recovery 复用既有 Active Authority lock 串行化，而且每条 Long-Task 写路径都拒绝未完成 journal。若崩溃恢复与已激活绑定冲突，恢复不会写入：先通过合法 Long-Task lifecycle 结束该绑定，再完成或回滚事务，最后重新 Compile/rebind，并执行任何必要的 Authority Revision。这里承诺的是协作进程边界内的确定性崩溃恢复，不是文件系统级跨文件物理原子性或 hostile-writer 互斥；不存在 `--force`、手工删锁或隐式全 Manifest normalize 路径。
+
+这些 Context 命令使用统一退出码：`0` 完成，`2` 参数错误，`3` Catalog 阻断错误，`4` 扫描预算导致结果不完整，`5` I/O 或路径安全错误，`6` 内部错误；普通 route ambiguous/unresolved 仍是已完成的诊断结果。
 
 Context 负责耐久的意图和边界，代码负责当前实现，测试/CI/浏览器或运行时证据/人工负责行为与产品验收。
 
@@ -221,9 +248,9 @@ provider-neutral handoff 是残余语义与绑定层，不是 CSS 文本副本
 
 正式 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 文本。
+未决 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。observation reason、cost、risk 与 blocker description 共用一个时间分类器，识别紧凑或带空格、单复数的 `millisecond|msec|ms|second|sec|s`：出现 motion 上下文一律阻断；明确的 build/compile/test/startup/latency/timeout/network/benchmark/runtime/render cost 上下文合法；没有上下文的时间字面量 fail closed。精确动效时间或语义不明的时间值仍归 canonical resource。
 
-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。
+Long-Task 消费时，系统会逐条证明每个 `file`/`path_glob` target 与 carrier、每个 `verified` carrier、以及每个 planned 非空 carrier 完全位于 observed component/route roots 内；部分匹配或无法证明都失败。独立 Contract 结构校验仍拒绝空 component refs。只有完整 activation 调用可以暂缓这一条，并且仅当 surface 的每个 target 都是 modern blocker-only、route 与精确 blocker 闭包有效时通过；legacy target 不能借用该例外。纯 legacy surface 保留历史上的非空 component-Binding 兼容，但不获得 feasibility 声明。surface 一旦出现 modern feasibility target，每个 component Binding 都必须由 modern candidate-bearing cell 的实际唯一匹配消费；legacy 消费空集，因此不能在 mixed surface 中洗入额外 Binding，而多个 modern target 可以共享各自明确匹配的同一 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。
 
@@ -247,15 +274,25 @@ repository pattern 只把圆括号作为经过转义的 route-group 字面字符
 
 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 与项目自己的验证路径。
+`ty-context doctor` 保留兼容的项目级 `missing | unconfigured | configured` 状态，并增加完整 closure、Token 投影、额外文件和规范性本地链接的 advisory 诊断。结构性 bundle 错误会明确展示，但不会把视觉判断冒充机器结论。Doctor 不推断页面实现就绪；material surface 仍需 owning Screen/Control meaning、selected target/constraints 与项目自己的验证路径。
 
 静态 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
 
-只有用户明确要求初始化、生成、选择、采纳、替换或修复项目设计系统/设计风格时，才使用 `design-system-authoring`。安装只让冷启动能力可用，不会自动运行。Skill 会发现 Open Design 当前真实 MCP resource/tool；若当前版本只通过 MCP 读取设计系统而没有创建 tool，则使用同一个已安装 Open Design daemon 的官方 generation/revision/accept API，不复制 provider prompt，也不把 daemon 调用冒充 MCP。
+只有用户明确要求以 `bootstrap`、`revise` 或 `reconcile` 模式建立、修订或吸收项目设计系统变化时，才使用 `design-system-authoring`。DRA 的 `authority_delta_candidate`、缺失 `DESIGN.md` 或普通 UI 工作都不会自动调用它。Skill 发现 Open Design 当前真实能力，provider 执行仍在 Skill 层；package-local `@google/design.md` adapter 只做确定性的 lint/parse/export/diff，不是生成器或 provider runtime。
+
+根 `DESIGN.md` 是唯一 Authority 入口、人工 revision owner，也是首版 bundle 中唯一可编辑 exact-Token owner。采用 Bundle 时，必须把精确的 `<!-- ty-context-design-authority-format: bundle-v1 -->` 机器声明写在受支持 YAML front matter 之后第一个非空 Markdown 正文行，并创建稀疏 `design_system/authority.manifest.json`；marker 与 manifest 必须成对存在。manifest 只拥有排序后的 closure membership 和 `closure_digest`，不复制 revision、方向或 Token 值。marker 保留时 manifest 缺失、重命名、空或非法，manifest 孤立存在，marker 被移动、重复或非规范拼写，以及物理路径大小写不可移植，都会使 closure fail closed。`design_system/tokens.json` 是从受支持 DESIGN front matter 确定性导出的 DTCG 生成物，不能独立编辑为第二权威。只有出现真实、可复用、长期规则时才建立 component、pattern、motion 或 platform 子 owner。真正未标记且没有 manifest 的项目继续是兼容的单文件 closure。
+
+机器身份由入口与完整 closure digest 组成，人工 revision 只用于诊断。closure 校验会拒绝不安全/重复路径、大小写冲突、symlink/hardlink 别名、非法 UTF-8/BOM、生成 Token 漂移和不完整的规范性本地链接。即使 revision 文本没变，只要子 owner 改变，旧 DRA recovery/handoff 与 Long-Task binding 也会失效。只读检查命令为：
+
+```bash
+ty-context design-authority inspect --format json
+ty-context design-authority tokens
+ty-context design-authority tokens --from-entry
+```
 
-生成结果先是候选。必须有明确人工选择，或用户明确委托且选择标准已知，才会采纳到项目 canonical `DESIGN.md`、唯一 authored exact-value token source/generation direction，以及真正拥有 surface/interaction 耐久事实的 Context。Open Design provider ID、revision、digest 与 project binding 只是同步 provenance，不是第二权威。provider 执行成功、artifact ready、selected、authority adopted 与 `get_project.designSystemId` binding verified 会分开报告。
+生成结果先是候选。必须先有明确人工选择，或用户明确委托且标准已知；看到精确项目 diff 和迁移影响后，还必须单独明确确认 adoption。adoption 更新根入口和必要的稀疏 owner，确定性重建 Tokens，发布新 closure digest，重绑受影响 DRA 资源并重跑检查。Open Design provider ID、revision、digest 与 project binding 只是同步 provenance，不是第二权威；provider 执行成功、artifact ready、selected、authority adopted 与 `get_project.designSystemId` binding verified 会分开报告。
 
 ### 可选 Design Resource Authoring
 
@@ -265,6 +302,8 @@ Skill 把明确输出或开发内容当作硬 scope ceiling。局部功能只可
 
 在 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。
 
+任务方向选定后，DRA 会针对精确当前 closure 做一次非权威 Authority Delta Assessment：`consistent_with_current_authority`、`task_local_variance` 或 `authority_delta_candidate`。一次性偏差必须声明 `precedent: forbidden`；需要跨任务复用的局部偏差必须进入一个明确 Screen Contract owner。系统变化只能形成纯候选数据包，DRA 到此停止，等待用户单独显式启动 DSA `reconcile`。可选严格 JSON 只用 `ty-context design-resource authority-delta validate <assessment.json> --json` 做只读校验，不能选择、adopt、写 Authority 或调用 provider。adoption 后 handoff 必须绑定新 closure，并重跑受影响 preflight/resource 检查。
+
 正式首次生成、重大设计修订和关键重新生成使用实时发现后满足工具、视觉/上下文能力、认证与数据边界的最高能力模型，以及该模型实际支持的最高 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 义务，并读取真实技术 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、动效、无障碍、资产或基本可实施性。
@@ -304,15 +343,19 @@ Provider execution、Artifact readiness 与 Design suitability 保持分离。
 - Final Gate 在一个当前快照上重跑全部 Check；
 - Stop Hook 在结果 stale 时阻止完成。
 
-它的证明命题有明确前提：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 无法发现未声明要求，也不声称任意物理/外部观察绝对可靠。
+它的证明命题有明确前提：Source 在声明观察粒度下完整且准确、Source→Contract 投影保持语义、所有实际适用单元被展开。在此前提下，`AcceptedDeliveryTerminal` 只有两种：不需要阻断性外部履约时的 fresh `machine_accepted`，以及全部阻断性外部义务已有 fresh、有效、逐义务精确记录时的 `delivery_accepted`。机器义务仍必须具有冻结 Expected 权威、package-admitted 当前 Actual、Harness 计算的 comparison/verdict、可归因静态生产载体或直接 process observation、因果 Counterfactual 与当前 Final Gate 快照证明。每份阻断性 External Record v2 都携带逐义务身份/证据、当前 challenge、whole-candidate 身份、不可变 artifact snapshot，以及由受保护 Source 公钥校验的 detached Ed25519 签名；这证明签名者持有绑定私钥，但不会在 Source 绑定之外独立证明真实世界身份。Record v1 与旧 `machine_accepted_external_pending` 仅可审计，不能关闭 Authority。Harness 无法发现未声明要求，也不能声称任意物理/外部观察绝对可靠。
+
+Compile 会在 Source Item 之下继续守恒语义：从既有 Semantic Fact Manifest 派生一个内部视图，覆盖全部 Source Item，以及可严格按 UTF-8 读取的 attachment、canonical specification、repository-preservation input、external constraint、delegated instruction 和文本型 design resource；它不按扩展名猜测，无法读取或类型含糊的文本会阻断。扫描器覆盖标题、段落、嵌套列表、表格、引用、Given/When/Then、代码/配置块和文本 HTML，并证明全部非空材料行恰好等于互不重叠的 Fragment 行与允许的纯分隔符行之并。每个 Fragment 恰有一个显式 `fact_bearing | supporting_basis | superseded | decision_required | scope_excluded` disposition；反向 delivery-Fact provenance、Anchor、semantic-cell identity 与 Claim modal polarity 防止 supporting、supersession 或 exclusion 隐藏独立要求。`source_integrity` Fact 不能代替 `delivery_semantic` 含义；这仍复用既有 Source inventory 与 Semantic Fact Manifest，不建立第二份总账。
+
+Proof Adequacy 同样是结构约束：封闭的 method 与标准 property profile 会同 observation-scope、quantifier、Claim-kind 和 Control-field floor 取并集，文本关键词只能诊断，不能改变权威。presence 只能证明存在；transition/sequence、产品结果、边界 provenance、持久化 readback、身份/数据状态、population、fault/recovery、concurrency/idempotency、performance/capacity、选定设计与目标运行时分别保留更强 typed capability。新增但未分类的标准 property 会失败；无标准 profile 的 `custom.*` method/property 不能 Machine close。Preflight 先按精确 Claim/Fact × method × applicability obligation 生成 machine/external 候选，再要求恰好一条路线；machine/external 重叠、同类多路或无路线均为 `unreachable`，宽泛 `impact_claims` 不得删除 machine Assertion。
 
 Compile 为每个机器 Claim 或 Fact × required-method obligation 派生内部 `CompiledObservationAuthority`，它不是新的 Contract Authority、状态或 registry。首版只有两条机器路径：`package_static_json_exact` 读取 runner 前快照中已存在、runner 后 no-follow 文件 identity/digest 不变、匹配生产 Binding 且不属于 Source/Context/Contract/expected/evidence/report/status/verifier output 的 UTF-8 JSON 静态结构；prepare-all mutation observation 与逐文件 pre/post identity/hash 共同拒绝 transient/persistent swap，它只证明静态内容，不证明运行时消费。`package_process_json_exact` 只支持 Source-backed 的 `runtime_family: process`、`role: product` 目标，以及 target 和完整 argv 与该权威一致的直接 root `project_binary`。每个 required target 都由一项 canonical Source technical obligation 精确覆盖 key、role、family、root、完整 argv 和 capabilities。Compile 生成声明稳定的 process runtime closure：精确 Source-backed root、当前 Claim/Counterfactual production carriers，以及由有限 argv→production Binding 匹配得到的路径。每个 `root_argv` 数组成员始终是 child-visible exact token；分类器不拆空格、不去引号、不重写反斜杠。封闭语法只检查独立 token 或一个显式 `--name=value`，支持的 standalone switch 是 label，其他 compound form 不获得机器闭包；raw token 与派生 locator 分离。quote、POSIX/UNC absolute、drive-prefixed、slash/backslash 平台歧义、除精确小写十进制 `node:<number>` 外的所有 scheme-shaped colon prefix 和 unsupported compound 在执行前 fail closed，除非显式转到既有 external TCB/External Confirmation。parent segment 先结合声明 `cwd` 解析，再判断是否真实越出仓库，因此仓库内 `..` 合法，真实 escape 才失败。exact/pattern Binding 支持 glob、无扩展名和含空格单 token 文件；安全 unmatched 以及精确小写十进制 `node:<number>` 和纯数字 `<hours>:<minutes>` 两种 colon scalar 允许但不复制。Compile 不广域扫描或复制全部 `input_paths`，角色分离只检查实际 closure 成员。Global Check 将 Outcome Binding 投影成内部 `{ outcome_key, local_key, binding_ref, binding }`，并复用 `<outcome>.<binding>`：逻辑 ref 保持独立，相同物理路径可只复制一次，不改变 authored Contract 或建立 registry。Exact planned closure member 可以到 Final Gate 才 materialize。Harness 仅复制这份 closure，把其 identity 绑定到 host attestation，并把未修改的 raw argv 传给 child。兼容的 Cross-Check 与 implicit-preserved Facts 共享一个受限 stdout `ty-context-product-observation-v1` envelope，同时保留独立 result identity。无法显式 production-bind 的嵌入式依赖或无法直接绑定 root 输出面的 Claim 必须 External Confirmation。项目 payload 继续使用 v3，不发布 v4，也不建设 shell/URI/dependency parser 或通用 UI/native observer。
 
 项目自报的 v3 actual/value digest、comparison、`passed`、verdict 与 capability record 只作兼容诊断，不能提供 Actual 或完成权威。当前 package 可派生范围只有 exact/presence 与 host-derived `target_runtime`；`interaction_trace`、`state_delta`、`design_conformance` 以及其他尚无 package derivation 的 capability 即使有项目 record 也必须保留阻断性 External Confirmation。custom/`named_external_tcb` Oracle、间接 wrapper、browser/native/device session、layout/pixel/accessibility/motion、protected observation、tolerance/mask 与 custom locator 同样不能关闭 machine obligation。每个机器 Counterfactual 都要有 package-admitted baseline/mutated observation、相同 compiled closure identity、属于 production carrier 集合的 mutation target、affected/preserved/allowed-fan-out 精确集合与相同 obligation universe，并在适用时保持 host-derived process liveness；没有 admitted observation 时不得跳过。旧 Contract 不会被静默改写，target/closure TCB 变化会使旧 Active Authority、Progress、Evidence 与 Receipt 失去验收效力。
 
-诚实声明为不支持的 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 状态。
+诚实声明为不支持的 Contract 不需要伪造 verifier。`target_profile.completion_authority` 可选 `machine_only` 或 `declared_authorities`；旧 Contract 缺失时确定性地按更安全的 `machine_only` 处理，并由 Preflight 给出迁移提示。`declared_authorities` 下的阻断性 External Confirmation 必须声明 actor/owner、target、environment、Given/When、证据要求，以及带 Claim、applicability、Fact/proof/method/capability 和 Expected authority lineage 的逐义务明细。完全 external 的 Outcome 设置 `success_path_required: false`；Stage Gate 只有在阻断 confirmation 精确覆盖该 gate 的 result Claim 时才可不声明 machine Check。缺少分解/result lineage、聚合 Boolean、非阻断 confirmation 或声明了机器 success path 却没有真实 success Check都会使 Preflight/Compile 失败。合法但未履约的路径得到 `blocked_external`；提交精确 fresh 记录且完整 Final Gate 通过后得到 `delivery_accepted`，不会冒充 machine accepted。
 
-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。
+Direct-process observer 提供的是受限 containment，不是针对恶意代码的绝对 sandbox。Windows 上每次 contained execution 都使用 package-owned 且纳入字节身份的 PowerShell 5.1/7 与 C# helper：先以 suspended 状态创建声明的 executable，分配到带 `KILL_ON_JOB_CLOSE` 的新 Job，只有分配成功才 resume；stream/timeout/overflow 均有界，并且只有在 `ActiveProcesses == 0` 后才接纳 evidence。短命 root 不能抢在 descendant enrollment 前退出，helper/identity/protocol 漂移一律 fail closed，也没有 PID/CIM polling fallback。非 Windows 继续使用原有 process-group/tree 路径；无需 containment 的普通 direct spawn 不变。更广的 TCB 仍包含 host OS/文件系统/进程 API、Node runtime、快照复制与 no-follow/digest 校验及 stdout 捕获/解码。它不声称能阻止蓄意恶意代码逃出复制闭包或访问环境中的机器/网络资源；需要这类对手边界的 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`。已有计划文档的旧结构本身不构成阻塞。
 
@@ -328,7 +371,12 @@ Direct-process observer 提供的是受限 containment，不是针对恶意代
     "action": "change_model_in_host_then_continue",
     "resume_token": "model checkpoint cleared, continue",
     "turn_boundary": "end_current_turn",
-    "blocked_until_resume": ["product_implementation", "file_edits", "build", "test_execution"],
+    "blocked_until_resume": [
+      "product_implementation",
+      "file_edits",
+      "build",
+      "test_execution"
+    ],
     "model_change_owner": "host_or_user",
     "model_change_observable_by_harness": false,
     "generic_continue_satisfies": false,
@@ -361,7 +409,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.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` 表示。
+真实采集当前为 `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.18 是已发布的前序版本；Package 0.9.0 是此前未 Promotion 的 Level-3 candidate；Package 0.11.0 是当前 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。
 
@@ -373,7 +421,7 @@ package-owned 的非 UI Compact Carrier 在不新增 Authority、状态或 Gate
 
 只有 `weak_observability` 同时遇到多 Stage 或多个 required product runtime family 时，才额外要求一个只读 Global Product Conformance Check。它从 required root product target 启动，使用独立 Raw Execution，并在既有 Final Gate 内运行。单 Stage、单 family 继续使用原有 same-Check sensitivity，不支付额外 conformance 执行成本。
 
-平台负责物理 Goal/会话生命周期。新会话通过 `resume` 恢复语义状态；Tiny Context 不会重建此前的物理 Turn。机器接受只覆盖 `declared_machine_authority`，并报告 `native_goal_effect: none`。完成平台原生 Goal 前，Agent 只做一次否决型核对：当前 Goal/用户语义是否全部进入 accepted marked Source，且没有 pending revision、未解 blocker 或遗漏；它只能阻止并触发修复，不能增加验收证据。
+平台负责物理 Goal/会话生命周期。新会话通过 `resume` 恢复语义状态；Tiny Context 不会重建此前的物理 Turn。accepted Final/Stop/close 覆盖 `declared_delivery_authority`，并报告 `native_goal_effect: none`；Harness 本身不会完成平台原生 Goal。完成该 Goal 前，Agent 只做一次否决型核对：当前 Goal/用户语义是否全部进入 accepted marked Source，且没有 pending revision、未解 blocker 或遗漏；它只能阻止并触发修复，不能增加验收证据。
 
 ### CLI
 
@@ -389,6 +437,11 @@ ty-context long-task verify <workdir> [--outcome <key>] [--check <key>] [--expla
 ty-context long-task status <workdir>
 ty-context long-task resume <workdir>
 ty-context long-task doctor <workdir>
+ty-context long-task external prepare <workdir> [--confirmation <key>]
+ty-context long-task external submit <workdir> --confirmation <key> --record <path>
+ty-context long-task external status <workdir>
+ty-context long-task external rotate <workdir> --confirmation <key>
+ty-context long-task external revoke <workdir> --confirmation <key>
 ty-context long-task final-gate <workdir>
 ty-context long-task stop-check <workdir> [--message <text>]
 ty-context long-task close <workdir>
@@ -401,10 +454,12 @@ ty-context long-task abandon <workdir> [--force-corrupt-state]
 - `diagnose-revision` 只做无副作用候选 Compile；仅 scope-only 候选能运行 Active Authority 已有且未更换的 Check，输出固定为非验收、非 Progress、非 pending。
 - `compile --revise` 自动采用单调或机械边界内的修订；需要用户决策时返回 `authority_revision_pending`、精确 id、确定性 material 摘要、`user_decision_reasons` 和自包含 `decision_brief`。先展示 brief；只有已明确且精确覆盖全部 reason 的当前任务指令可直接承载该 id。候选再变会生成新 id 并使旧批准失效。采用后证据失效、输出 `authority_revision_adopted` 并回到滚动执行，不表示交付完成。
 - `verify` 在重查 active task/revision/compiled/worktree identity 并依据 immutable baseline 应用同一 workspace 分类后写 scoped Progress；targeted verify 始终只是可选反馈/修复证据。`verify --explain` 只读地合并 Main Raw Execution、列出适用 Counterfactual 调用与声明的重试次数上界，不执行命令、不写 Progress，也不预测耗时或 runner 内部子进程。
-- `status` 输出 `unverified`、`progress_passing`、`progress_failing`、`progress_stale` 或 `blocked_external`，由当前 Progress 派生 `stages`、`ready_stages` 和建议性的验收/验证 Outcome frontier，不持久化 Stage 完成。兼容字段 `ready_for_implementation` 只是该投影的别名，不是实现门禁。它同时报告 fresh `final_workflow_status`、target profile/state、完整 `external_confirmations` 与唯一的 `pending_authority_revision`。`progress_passing` 只能表述为定向修复证据，不能简称“Outcome 完成”；`progress_stale` 是证据新鲜度事实，不是当前通过或每次编辑后立即重跑的指令；`final_workflow_status: null` 表示 Goal 尚未完成。
-- `resume` 完全只读，恢复 task/contract identity、风险、相关 Context、Git 状态、相同的 Final/target/Stage/external/pending surface、ready Outcome、findings 和建议性的验证/修复 next action；该建议不限制实现顺序。
-- `final-gate` 在执行前重新编译 Source Authority，并捕获 Contract/fragments、Source、Controlling Context、verifier/runner、verification inputs 和 workdir inputs 的语义与原始受保护身份；完成全部 Check 后，再次编译并哈希同一完整集合。任一输入竞争变化都会 fail closed，并发 revision 也不能产生 accepted。Receipt 把每个 Stage 派生为 `passed`、`failed`、`blocked_external` 或 `blocked_dependency`，把 `target_state` 派生为 `not_accepted`、`blocked_external` 或 Contract 精确声明的 `implementation_complete`、`target_profile_usable`、`production_release_ready`。
-- `stop-check` 与 `close` 自己运行 Live Final Gate，并只用 accepted identity 做 CAS clear。每次机器接受的 Stop 都给一个非阻塞 terminal-scope `systemMessage`；外部待确认时同时列出全部确认项。Final/Stop/close 输出 `acceptance_scope: declared_machine_authority` 与 `native_goal_effect: none`，close 另输出 `closed_scope: machine_authority`。`status: closed` 只表示机器 Authority 已清理，不表示原生 Goal 或完整外部交付完成。
+- `status` 输出 `unverified`、`progress_passing`、`progress_failing`、`progress_stale` 或 `blocked_external`，由当前 Progress 派生 `stages`、`ready_stages` 和建议性的验收/验证 Outcome frontier，不持久化 Stage 完成。兼容字段 `ready_for_implementation` 只是该投影的别名，不是实现门禁。它同时报告 fresh `final_workflow_status`、target profile/state、声明及实时逐确认履约结果、唯一 pending Authority Revision，以及非持久、无验收权的 `repair_frontier`。后者按 root 聚合 Finding，列出 Source fragment、Fact/proof、Expected/Actual evidence、实现/验证 owner、最小诊断重跑和仍 fresh 的诊断 Progress，并明确 Source、Expected、Claim、proof authority、external scope、comparator 与 applicability 未经 Authority Revision 不可在修复中改变。
+- `resume` 完全只读，恢复 task/contract identity、风险、相关 Context、Git 状态、相同的 Final/target/Stage/external/pending surface、ready Outcome、增强 Finding、Repair Frontier 和建议性 next action；该建议不限制实现顺序。
+- `external prepare` 输出当前候选 Packet、current challenge、Source-bound actor/key identity、signable canonical payload digest、逐义务 Expected/method/capability 与证据要求，并明确不产生接受。`external submit` 接受严格 `long-task-external-confirmation-record-v2`，依次校验 Active Authority/freshness、schema、whole candidate、challenge、actor、Ed25519 签名、精确义务/result-kind 集、不可变 artifact snapshot 与客观 comparator 后原子保存。`external status` 重算 identity/signature/challenge/artifact integrity；`external rotate` 轮换 challenge；`external revoke` 删除命名记录并轮换 challenge。这些写操作与 finalization 共用 Active Authority lock。failed/unable、declared-only actor 与 Record v1 均不能接受。
+- 程序化 v2 记录生产者可从 package 根入口导入 `parseExternalConfirmationRecordV2`、`externalConfirmationRecordV2Hash` 与 `externalConfirmationV2SignablePayload`，在 Harness 外使用 actor 自持私钥签署 canonical payload，再提交完整记录。Harness 只提供验证，不提供私钥读取或 v2 代签命令/helper。导出的 v1 parser/hash/`signExternalConfirmationRecordV1` 只用于 legacy 审计兼容；其本地哈希不是认证，也不能完成阻断义务。
+- `final-gate` 要求 clean candidate commit，拒绝 stale Authority 输入，重编译 Source Authority，捕获完整受保护输入与 provisional Finalization Identity，并在一个 Git-tree snapshot 上只运行一次全部 semantic Check。随后进入现有 lock 下的短 Finalization CAS，不重跑 machine Check，而是重查 Authority、candidate/workspace fingerprint、compiled/verifier freshness、全部 external record/challenge/signature/artifact/evaluation 与精确 Finalization Identity。Final Receipt v3 绑定 `finalization_identity_sha256`，只产生 `machine_accepted`、`delivery_accepted`、`blocked_external` 或 `needs_work`。
+- `stop-check` 与 `close` 运行同一个 Live Final Gate，并在同一事务中发布 Receipt；只有 fresh accepted identity 才清理 Active Authority。任一覆盖竞态都会产生非接受结果、保留 Authority，且不能留下 fresh accepted Receipt。缺少 `finalization_identity_sha256` 的历史 v3 Receipt、旧 `machine_accepted_external_pending`、pending、failed、stale 或 invalid 均只可审计并 fail closed。Final/Stop/close 输出 `acceptance_scope: declared_delivery_authority` 与 `native_goal_effect: none`，close 另输出 `closed_scope: complete_long_task_authority`。
 - `abandon --force-corrupt-state` 仅用于损坏/mismatch/legacy-unrecoverable 状态或遗留锁，只删除确定性 active state 与 `<workdir>/.ty-context/**`。
 
 ### Delivery Contract
@@ -447,10 +502,14 @@ active Long-Task 内部原有 `risk.requested_level: auto | standard | strict` p
 
 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，从 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`；后者仍列出阻断性外部确认，不属于完整无漂移定理的前件。
+Targeted verify、Progress、status、Receipt、external record 与 compiled cache 都不是完成权威。Final Gate 要求 clean candidate commit，从 Source 重编译 observer plan，在同一 Git-tree snapshot 上重跑全部 semantic 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 全部不变且无需阻断 external fulfillment 时可生成 `machine_accepted`；所有阻断 external rows fresh、valid、fulfilled 时生成 `delivery_accepted`；pending 为 `blocked_external`，failed/unable/invalid/stale/unreachable 为 `needs_work`。
 
 ## 兼容与迁移
 
+0.10 系列继续使用 Schema v4，保留五种 read policy 与既有 default-footprint 的精确行为。Router 仍是实验性工具，不替代 Workflow bounded search；`context create` 不登记文件，`register` 与 `move` 是显式、默认 dry-run、可恢复事务。不会自动转换 legacy policy，也不会迁移 Workspace。
+
+0.11 增加可选稀疏 Design Authority bundle，但不自动迁移既有项目。只有未标记根 `DESIGN.md` 的项目仍是合法单文件 closure；采用 Bundle 是一次显式 DSA/Authority Revision，必须同时插入规范 `bundle-v1` marker 并创建 `design_system/authority.manifest.json`，`tokens.json` 从 DESIGN 生成而不是第二个可编辑 owner。旧 DRA handoff 只有在项目仍是真实单文件 closure 时才可省略完整身份；采用后保留任意一半却删除或损坏另一半都会 fail closed，原始 `DESIGN.md`-only binding 必须按完整当前 closure 重新生成或 rebind。回到单文件 Authority 必须通过显式 DSA adoption/Authority Revision 同时移除两半；package 能验证当前 marker/manifest 配对并使旧 active binding 失效，但一个两者都不存在的新 checkout 没有认证历史 registry 可供推断曾经的 bundle。Upgrade 不会发明子 owner、Token 值、adoption 或 Authority revision。
+
 当前 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 保持兼容，但其自报证明字段不具权威。
 
 ## 开发与验证

package/assets/agents/AGENTS_CORE.md

@@ -65,7 +65,7 @@ The loaded Skill and its progressive references own Source/Contract authoring, C
 
 After the first Authority Lock, `execution_model_checkpoint.required: true` is an unconditional terminal-turn boundary. Stop before product implementation, edits, builds or tests even when an earlier message stated a model strategy. Tell a Chinese-speaking user exactly `处理好模型更换后，请仅回复：模型切换卡点解除，继续`; use `After handling the model change, reply exactly: model checkpoint cleared, continue` in English. A generic continuation does not satisfy the package-managed prompt protocol. Harness cannot observe the next host message or verify the host model change; later revisions do not repeat the pause and no acknowledgement, model route or checkpoint state is recorded.
 
-Long-Task Final Gate is the sole `Engineering Quality Conformance`, `Architecture Conformance` and selected-design closure owner. It source-recompiles and reruns every declared Check on one current snapshot; targeted Progress, prose, historical tests, Receipts, compiled cache or Agent judgment never create acceptance. It proves the declared falsifiable project-check-bound invariants, not overall code quality. Exactly fresh `machine_accepted` with no pending External Confirmation is the complete declared-machine terminal; qualified/external-pending results never complete the platform-native Goal.
+Long-Task Final Gate is the sole `Engineering Quality Conformance`, `Architecture Conformance` and selected-design closure owner. It source-recompiles and reruns every declared Check on one current snapshot, and revalidates every exact external-fulfillment record against the same candidate and Authority; targeted Progress, prose, historical tests, Receipts, compiled cache, external records by themselves or Agent judgment never create acceptance. It proves the declared falsifiable project-check-bound invariants, not overall code quality. `AcceptedDeliveryTerminal` is exactly a fresh `machine_accepted` when no blocking external fulfillment is required or a fresh `delivery_accepted` when every blocking external obligation is also freshly and exactly fulfilled. `blocked_external`, `needs_work` and legacy `machine_accepted_external_pending` never complete the platform-native Goal.
 
 The `F = Implementation Freedom Boundary` keeps implementation order, methods, local feedback cadence, concrete packet decomposition and dynamic worker count Goal-owned within Source/Contract, architecture, safety, forbidden-shortcut and external-action boundaries. After the checkpoint, follow the loaded Skill's packet-first positive-default policy: a qualifying packet set requires actual calls for multiple exact fixed-profile workers; zero-start and partial-delegation outcomes use its admitted reason and integration rules. Harness creates no development method Gate, per-edit mandate, fixed agent allocation, scheduler/delegation state or proof from delegated reports; all proof-bearing output converges into the selected verification workspace.
 
@@ -84,7 +84,7 @@ Tiny Context does not create or restore platform Goals, invoke models, spawn age
 
 - `make validate-context`: Context recoverability.
 - `make validate-harness`: Context plus touched-source modularity.
-- `ty-context doctor`: installation health plus advisory default Context footprint and Design Authority status.
+- `ty-context doctor`: installation health plus advisory default/all-Context diagnostics and Design Authority status.
 - `node packages/ty-context/dist/cli.js package check-source`: managed-source/package parity in this source workspace.
 
 Every handoff reports exactly one of `Context: updated ...` or `Context: no durable fact change`. Never claim tests, deployment or acceptance from Context alone.

package/assets/context_templates/context.toml

@@ -14,7 +14,12 @@
 # widen to any relevant area/shared Context when task dependencies require it.
 # This optional sparse mirror adds no workspace schema or read/edit ACL. Use
 # project-owned scope checks for task-local intended/supporting changed paths.
-# `ty-context doctor` reports the deterministic default read footprint and exact duplicates.
+# Schema v4 also accepts legacy always/optional/never-default values without
+# reinterpreting them. Doctor warns, but migration is explicit: only default is
+# directly selected and every registered default_children target is selected.
+# `ty-context doctor` reports default and all-Context advisory diagnostics.
+# Experimental `ty-context route` is read-only and does not replace the
+# Workflow-required bounded Context search.
 # When migrating deep files under project_context/areas/**, refine obvious
 # contract/foundation/subdomain/verification/deployment/implementation-index/
 # decision-rationale/archive files into [[context]] entries instead of keeping