frontend-project-context 1.7.0 → 1.9.1

package/docs/30-TASK-CONTEXT-CONSUMPTION-CLOSURE-DESIGN.md

@@ -0,0 +1,563 @@
+# 30 — Task Context Consumption Closure 设计
+
+> 日期：`2026-09-21`
+>
+> 状态：`local-implementation-complete; real-project-revalidation-not-authorized; release-not-authorized`
+>
+> 目标版本：`1.9.0 — Task Context Consumption Closure`
+>
+> 证据基线：`docs/09`、`docs/10` 的两个真实项目 B0 对照，以及 `docs/29` 的 `1.8.0` 正式初始化后观察。
+>
+> 授权边界：冻结设计后的本地实现授权已消费；真实项目访问或写入、Provider、依赖安装、Git、网络、打包、发布和业务代码修改仍未授权。
+
+## 1. 为什么在 `1.8.0` 之后继续修
+
+`1.8.0` 已经关闭“如何把产品正确安装进项目并让新 Host 消费 Project Contract”这一问题。真实安装证明以下基础成立：
+
+- 安装包提供唯一初始化指令；
+- Host 被限制在明确的 `targetRoot`；
+- Project Contract、source lock、projection lock 和 AI Entry 能回到 `clean / contract-ready`；
+- project、path-prefix、file scope 与 sibling isolation 生效；
+- 新 Host 能先消费 Contract，再进入真实源码分析。
+
+安装成功以后，两个真实项目的观察又暴露了下一层问题：Host 已经能进入 Contract，但从模糊任务到精确开发上下文之间仍有断点。
+
+当前链路是：
+
+```text
+收到任务
+→ 必须先知道一个目标路径
+→ 调用 context
+→ 得到 Markdown content 和 Source index
+→ Host 自己猜哪些 source 要读、是否要补充其他目标路径、是否有业务代码修改权限
+```
+
+目标链路应收口为：
+
+```text
+收到任务
+→ 路径未知时先消费定位级 Context
+→ Host 在 targetRoot 内定位最小候选路径
+→ 用完整影响路径集合编译精确 Context
+→ 机器结果明确 item、scope、读取职责、coverage 与权限交接
+→ Host 只读取必要内容；Context 不足时明确报告 gap 并进行获准的动态调查
+→ 任务结束后 Project Context 仍为 clean
+```
+
+这仍直接服务宪法第 3 节的“确定性上下文编译”和第 4 节的 Context Renderer / AI Exchange Boundary，不改变产品身份或永久边界，因此不需要修改产品宪法。
+
+## 2. 证据归类与设计裁决
+
+### 2.1 本版本确认修复
+
+| 观察 | 分类 | 本设计裁决 |
+| --- | --- | --- |
+| O-02 未知路径时启动循环 | 内核消费入口缺陷 | 增加只读定位模式，并强制随后重新编译精确多路径 Context |
+| O-03 单路径示例不足 | AI Entry / 消费者适配缺陷 | renderer 5 明确多路径调用和发现新路径后的重编译 |
+| O-04 read targets 无结构化输出 | 机器交换合同缺陷 | 新增 Context Bundle schema 1 与明确的 required / conditional / provenance-only 分类 |
+| O-05 AGENTS 与 Contract 重复读取 | 消费与入口治理缺陷 | 用读取职责代替 Source index 猜测，并在初始化审查中显式处置重复规则 |
+| O-06 人工真源与受管 marker 共用摘要 | 来源追溯缺陷 | Contract schema 3 增加显式 digest mode，允许只摘要受管 AI Entry 之外的人工字节 |
+| O-07 coverage 结论没有持久交付 | Project Contract / Coverage Audit 缺陷 | 冻结 coverage profile v2 与 Coverage Audit schema 2 |
+| O-08 产品边界与 Host 权限交接不清 | AI Entry / 机器合同缺陷 | 明确产品无执行权限不等于 Host 被当前用户禁止开发 |
+
+### 2.2 不作为自动内核修复
+
+O-01“普通业务文件 Context 区分度不足”由两部分组成：
+
+1. 如果项目已经批准稳定的域级或组件级 Contract item，而编译器没有按 scope 选择它，是产品缺陷；
+2. 如果目标项目没有录入稳定业务语义，这是项目 Contract 数据缺口，不是扩大 discovery 的理由。
+
+因此本版本只提供明确的 `scopeCoverage`、coverage disposition、读取职责和 gap 输出，不扫描全部业务源码，不自动把调用链、接口字段或临时实现写入长期 Contract。
+
+以下内容继续排除：
+
+- Vue、uni-app、Vuex、路由、构建器、租户或业务域专用白名单；
+- OpenSpec、Kiro、Ruler、Rulesync 或其他工具的完整重实现；
+- Provider、Agent Runtime、自动任务规划、自动业务代码修改或自动验证；
+- Git、CI、分支、合并、发布和 Sidecar；
+- Persistent KV、embedding、向量数据库、全仓缓存、daemon 或文件监听器；
+- 自动读取 Source index 中的所有文件；
+- 把真实项目一次现象直接提升为长期规范。
+
+### 2.3 保留为风险而非缺陷
+
+- R-01：`attention` 是否抢占无关任务，等待真实分支重复证据；
+- R-02：平台级外部 memory 注入，不由本产品越权阻止；
+- R-03：Host 手工统计 item 数量错误，由结构化结果降低风险，但不实现 Host Runtime。
+
+## 3. 版本和固定边界
+
+本闭环目标版本固定为 `1.9.0`，属于现有内核的向后兼容扩展，不新增持久 store。
+
+冻结版本目标：
+
+| 合同 | `1.8.0` | `1.9.0` 目标 |
+| --- | --- | --- |
+| Contract | 读 1/2，写 2 | 读 1/2/3；只有使用 schema-3 字段的显式治理写入才写 3 |
+| Context Bundle | 无公开 schema；`--json` 仅 `{content}` | schema 1 |
+| Coverage Audit | schema 1 | 读 1、写 2 |
+| Initialization Instruction | schema 1 | schema 2 |
+| AI Entry | renderer 4 | renderer 5；1–4 仍可识别并报告 stale |
+| Capabilities / Exchange Protocol | 8 | 9 |
+| Project Status | schema 2 | 保持 schema 2 |
+| Projection renderer | 3 | 保持 3 |
+| 其他 Action / Review / Evidence / Upgrade / Stage schema | 现状 | 不变 |
+
+永久边界保持：默认只读、零 Provider、零 Agent loop、零 Git、零网络、零依赖安装、零自动批准、零业务代码执行。
+
+## 4. 两阶段任务入口
+
+### 4.1 冻结命令接口
+
+`context` 扩展为：
+
+```text
+project-context context --project PATH --locate --task TEXT [--locale zh-CN|en|all] [--json]
+project-context context --project PATH --path RELATIVE_PATH... [--task TEXT] [--locale zh-CN|en|all] [--json]
+```
+
+规则：
+
+- `--locate` 与 `--path` 必须且只能出现一种；
+- `--locate` 必须提供非空 `--task`；
+- `--locate` 不搜索仓库、不读取任务路径正文、不执行 Git，只编译 project scope 的已批准内容；
+- 已知目标路径继续使用 `--path`，并允许一次传入多个路径；
+- Host 发现新的受影响文件后，必须用完整的最小路径集合重新运行 targeted Context；
+- 重复运行完全只读，不写 Contract、索引、缓存、计划或 receipt；
+- `partial`、`invalid`、阻断性 source/contract/projection finding 继续失败封闭。
+
+### 4.2 定位模式
+
+定位模式只回答：
+
+- 当前项目是谁；
+- 哪些 project-scope policy/fact/reference/validation 适用；
+- 当前任务受哪些安全和治理边界约束；
+- Host 下一步应在 `targetRoot` 内定位哪些最小候选路径；
+- 找到路径后必须如何重新调用 targeted Context。
+
+定位模式不声明已经获得业务语义，也不把一级目录、Source index 或 routing term 猜测为真实目标文件。
+
+### 4.3 精确多路径模式
+
+targeted Context 对每个输入路径分别计算 effective items，同时输出：
+
+- 所有目标共同适用的 item；
+- 每个路径独有的 scope delta；
+- 实际命中的 item IDs 与 scope；
+- typed read targets；
+- provenance-only sources；
+- 每个目标的 `scopeCoverage`；
+- 不扩张权限的 Host handoff。
+
+路径顺序不影响 bundle 语义、摘要或 item 选择；规范化后去重并按字典序输出。
+
+## 5. Context Bundle schema 1
+
+### 5.1 顶层结构
+
+`context --json` 不再只输出 `{ "content": "..." }`，而是输出公开、严格、可校验的短生命周期工件：
+
+```json
+{
+  "schemaVersion": 1,
+  "kind": "context-bundle",
+  "project": { "id": "...", "name": "..." },
+  "mode": "locate | targeted",
+  "task": { "text": "...", "paths": [] },
+  "snapshots": {
+    "contract": "sha256:...",
+    "sourcesLock": "sha256:...",
+    "projectionsLock": "sha256:..."
+  },
+  "semanticCompleteness": "not-claimed",
+  "targets": [],
+  "items": [],
+  "readTargets": [],
+  "provenanceSources": [],
+  "coverage": {},
+  "authority": {},
+  "gaps": [],
+  "nextActions": [],
+  "content": "# Project Context Bundle\n...",
+  "bundleDigest": "sha256:..."
+}
+```
+
+该 bundle：
+
+- 只存在于 stdout 或 Host 明确指定的外部临时位置；
+- 不是 Project Contract、approval、Action Plan、receipt 或执行权限；
+- 不保存聊天、推理、源码正文、Git diff、测试日志或 Provider 请求；
+- `bundleDigest` 覆盖除自身外的规范 JSON；
+- `content` 从同一结构化选择结果渲染，不能形成第二套 item 选择逻辑。
+
+为了兼容既有消费者，顶层 `content` 保留；只读取 `JSON.parse(stdout).content` 的宽松消费者继续工作。纯文本 targeted 输出保持现有语义和格式，除新增明确的 gap / next-action 段落外不得改变 item 选择。
+
+### 5.2 targets 与 items
+
+每个 `targets[]` 至少包含：
+
+```json
+{
+  "path": "src/example.vue",
+  "scopeCoverage": "scoped | project-only | none",
+  "itemIds": ["..."],
+  "scopedItemIds": ["..."]
+}
+```
+
+判断固定为：
+
+- `scoped`：至少一个最终 effective item 来自 file 或 path-prefix scope；
+- `project-only`：只有 project-scope item；
+- `none`：没有 approved effective item。
+
+该字段只描述 Contract 命中情况，不宣称业务语义完整。`items[]` 是所有目标 effective item 的去重联合，至少携带 `id`、`kind`、`subject`、`scope`、`sourceIds`、`statement`、`value` 和可选 verification/consumption；每个数组均稳定排序。
+
+### 5.3 gaps 与 nextActions
+
+固定 gap code：
+
+- `target-path-not-yet-known`：定位模式的预期 gap；
+- `project-scope-only`：具体目标只有 project-scope 内容；
+- `no-applicable-contract-item`：目标没有任何适用 item；
+- `registration-coverage-not-declared`：项目没有 coverage profile；
+- `registration-coverage-review-required`：目标落入待审查域；
+- `required-read-target-unavailable`：显式 required source 无法解析为可信本地目标。
+
+gap 不自动授予读取、写入或修复权限。Host 根据当前用户请求和人工项目规则，可以执行正常的只读源码定位或动态调查；如果任务需要持久修改，权限仍来自当前用户请求，而不是 bundle。
+
+## 6. Contract schema 3：来源消费职责
+
+### 6.1 item consumption
+
+Contract item 新增可选字段：
+
+```json
+{
+  "consumption": {
+    "requiredSources": ["source.api-contract"],
+    "conditionalSources": ["source.adjacent-example"]
+  }
+}
+```
+
+约束：
+
+- 两个数组只能引用该 item 自身 `sources` 中的 ID；
+- 两个数组内部唯一、排序且互斥；
+- 只能把可定位的 file、path 或 json-pointer source 作为 read target；
+- 未出现在两个数组中的 source 是 `provenance-only`；
+- `requiredSources` 表示 Contract statement/value 不足以替代该来源正文；
+- `conditionalSources` 表示 Host 仅在当前任务确实需要时读取；
+- provenance-only source 只用于追溯和漂移验证，不能因出现在 Source index 就被当作必读文件。
+
+对 schema 1/2 和没有 `consumption` 的 schema-3 item，兼容推导固定为：
+
+- reference item 的本地 sources 为 `conditional`；
+- fact、policy、validation-description 的 sources 为 `provenance-only`；
+- 任务输入路径本身始终作为 `required / task-target` 输出。
+
+聚合同一路径时按 `required > conditional > provenance-only` 取最强职责，并保留全部关联 item/source ID，不重复输出路径。
+
+### 6.2 authoring 接口
+
+`propose` 与 `revise` 新增：
+
+```text
+[--required-source SOURCE_ID...]
+[--conditional-source SOURCE_ID...]
+```
+
+它们只是 item `sources` 的职责子集，不替代现有 `--sources`。非法、重复、交叉或不属于 `--sources` 的 ID 失败封闭。没有这些参数时保持兼容推导，不自动修改既有 item。
+
+## 7. Contract schema 3：受管区域外摘要
+
+### 7.1 source digestMode
+
+file source 新增可选：
+
+```json
+{
+  "kind": "file",
+  "path": "AGENTS.md",
+  "digestMode": "full-file | outside-owned-ai-entry"
+}
+```
+
+默认值为 `full-file`，与 schema 1/2 完全一致。
+
+`outside-owned-ai-entry` 只在以下条件全部满足时有效：
+
+1. 目标文件存在且位于 `targetRoot`；
+2. projection lock 中存在同路径、`ownership=region`、`target=ai-entry`、`regionId=project-context-ai-entry` 的可信记录；
+3. 文件中恰好存在一对合法 AI Entry marker；
+4. marker region 与 projection lock 的当前 digest/renderer 状态一致。
+
+摘要算法固定为：
+
+```text
+sha256(canonicalJson({ before: <marker 前精确字节>, after: <marker 后精确字节> }))
+```
+
+因此 renderer 文案或受管 marker 的合法升级不会改变人工来源摘要；marker 外任一人工字节变化仍产生 source drift。marker 缺失、重复、嵌套、顺序错误或所有权不可信时失败封闭，绝不退回 whole-file 摘要。
+
+`register` 新增：
+
+```text
+[--digest-mode full-file|outside-owned-ai-entry]
+```
+
+只允许 file source 使用。已有 whole-file source 不自动迁移；采用新模式必须经过精确 source review、影响集和人工批准。
+
+### 7.2 初始化入口重复处置
+
+Initialization Instruction schema 2 的集中审查必须把人工 `AGENTS.md` 与 Contract 的重复规则逐类标记为：
+
+- `migrated-to-contract`；
+- `kept-in-entry-intentionally`；
+- `excluded-as-stale`；
+- `unresolved-blocker`。
+
+产品不得自动删除人工规则。存在 `unresolved-blocker` 时初始化不能完成；保留重复规则必须展示理由。若 `AGENTS.md` 同时是真源和 AI Entry，默认使用 `outside-owned-ai-entry`，不能继续把产品自己的 marker 计入人工真源摘要。
+
+## 8. Coverage profile v2
+
+### 8.1 持久位置
+
+coverage 继续以人工批准的 `policy` item、subject `project.registration-coverage` 存在于唯一 Project Contract 中，不新增 coverage store。
+
+v2 value 固定为：
+
+```json
+{
+  "version": 2,
+  "domains": [
+    {
+      "id": "flight-ui",
+      "path": "src/views/flight",
+      "disposition": "contract-covered | dynamic-investigation | excluded-approved | unresolved",
+      "itemIds": ["..."],
+      "rationale": "..."
+    }
+  ]
+}
+```
+
+约束：
+
+- `id`、`path` 唯一且稳定排序；
+- `contract-covered` 的 `itemIds` 必须引用 approved 且对该路径有效的 item；
+- `dynamic-investigation` 明确表示调用链、接口或临时实现继续由 Host 按任务调查；
+- `excluded-approved` 必须有非空 rationale；
+- `unresolved` 是阻断状态，不能被 `contract-ready` 误解为语义完整；
+- profile 永远只对声明域负责，不宣称全仓知识完整。
+
+### 8.2 Coverage Audit schema 2
+
+`coverage-audit` schema 2 输出：
+
+- profile item ID/digest；
+- 每个 domain 的 disposition、item IDs 和当前一致性；
+- `registered`、`dynamic-investigation`、`excluded-approved`、`review-required`、`unresolved`、`outside-declared-coverage` 分类；
+- `registrationCoverage`：`not-declared | review-required | unresolved | closed-for-declared-scope`；
+- 固定保证：`declared-scope-only-never-all-project-truth`。
+
+schema-1 profile 继续可读并确定性映射到 schema-2 audit；不会因升级自动增加、删除或批准 domain。
+
+## 9. AI Entry renderer 5 与权限交接
+
+renderer 5 的 clean 分支固定为：
+
+```text
+若目标路径未知：运行 context --locate --task ...
+→ 消费 project-scope Contract
+→ 仅在 targetRoot 内定位最小候选路径
+→ 用全部候选路径重新运行 context --path ... --task ... --json
+
+若目标路径已知：直接运行多路径 context --path ... --task ... --json
+→ 报告实际 item IDs、scopeCoverage、required/conditional read targets 与 gaps
+→ 只读取 required，按任务判断 conditional，不重读 provenance-only
+→ 发现新影响路径后重新编译
+```
+
+权限说明固定为：
+
+- `businessCodeWrites=false`、`taskExecution=false` 只描述 Project Context 产品自身不会执行开发任务；
+- Context Bundle 不向 Host 授予任何权限；
+- Host 是否可以读取或修改业务代码，只能由当前用户请求、人工维护的项目规则和更高优先级安全约束决定；
+- 没有明确持久修改授权时，Host 保持只读；有明确开发授权时，不得把产品边界误读为禁止完成用户任务；
+- plan、bundle、receipt、review、coverage 或 Context 都不等于人工批准长期 Contract 或外部副作用。
+
+机器 bundle 中同步输出：
+
+```json
+{
+  "authority": {
+    "productTaskExecution": false,
+    "productBusinessCodeWrites": false,
+    "hostTaskAuthority": "external-to-project-context",
+    "resolveFrom": ["current-user-request", "human-authored-project-instructions", "higher-priority-safety-constraints"]
+  }
+}
+```
+
+## 10. 兼容与升级
+
+### 10.1 Contract
+
+- reader 支持 schema 1、2、3；
+- schema 1/2 在纯读取、check、status、普通 context 时保持字节不变；
+- 只有显式使用 `consumption` 或 `digestMode` 的 register/propose/revise/accept 流程才需要写 schema 3；
+- 任何转换必须经现有 baseline、影响集、CAS 和人工批准；
+- source lock schema 1 不变，只保存最终计算出的 digest；
+- downgrade 时，使用 schema-3 专有字段的项目属于 `forward-only` 数据；未使用专有字段的纯包升级属于 `package-only`。
+
+### 10.2 Context consumer
+
+- 纯文本 targeted Context 保留；
+- `--json.content` 保留；
+- 新字段只增加机器确定性，不要求消费者解析 Markdown；
+- Context Bundle 是短生命周期 schema，升级后重新生成，不持久迁移。
+
+### 10.3 AI Entry 与初始化指令
+
+- renderer 1–4 可读并报告 stale；只有显式 `publish-entry --write` 才升级到 5；
+- Initialization Instruction schema 1 仍可识别，但 `1.9.0` 写出 schema 2；
+- 目标项目升级必须先走既有 `upgrade-check → upgrade-plan → upgrade-apply`，不能由 postinstall 静默重写。
+
+## 11. 有界实施单元
+
+### 工作单元 1：Context Bundle 与两阶段入口
+
+- 新增 Context Bundle schema 1 和严格 validator；
+- 实现 `context --locate`；
+- targeted `--json` 输出 item/scope/coverage/gap/authority；
+- 保持纯文本和 `.content` 兼容；
+- 完成 TC-01 至 TC-05。
+
+### 工作单元 2：读取职责与最小消费
+
+- Contract schema 3 的 `consumption`；
+- propose/revise authoring 参数；
+- required / conditional / provenance-only 聚合；
+- multipath 去重、稳定排序和 bundle digest；
+- 完成 TC-06 至 TC-09。
+
+### 工作单元 3：人工真源与受管 marker 解耦
+
+- Contract schema 3 的 `digestMode`；
+- outside-owned-ai-entry 摘要和 fail-closed ownership 验证；
+- 初始化审查中的重复规则处置；
+- 完成 TC-10 至 TC-12。
+
+### 工作单元 4：coverage 与 Host 入口
+
+- coverage profile v2 与 Coverage Audit schema 2；
+- Initialization Instruction schema 2；
+- AI Entry renderer 5；
+- capabilities / Exchange Protocol 9；
+- 文档、migration manifest、package whitelist 与回归；
+- 完成 TC-13 至 TC-16。
+
+每个单元只修本设计冻结的问题。若实现需要 Provider、Agent Runtime、自动读业务源码、框架白名单、新持久 store、Git/CI 或任意业务写入器，立即停止并判定超出设计。
+
+## 12. 冻结验收合同
+
+| ID | 验收事实 |
+| --- | --- |
+| TC-01 | 路径未知时 `context --locate --task` 可离线、只读、确定性返回 project-scope Context，不扫描任务源码。 |
+| TC-02 | `--locate`/`--path` 缺失、并存或 locate 无 task 均失败封闭，路径仍受 targetRoot 与 symlink 安全约束。 |
+| TC-03 | 多路径 targeted Context 返回逐路径 item IDs、scope 和 delta，输入顺序与重复路径不改变规范结果，sibling isolation 保持。 |
+| TC-04 | Context Bundle schema 1 严格校验、自身 digest 可重算，`content` 与结构化选择完全一致。 |
+| TC-05 | 既有宽松 JSON consumer 仍可读取 `.content`，纯文本 targeted 输出不丢失任何既有批准内容。 |
+| TC-06 | required、conditional、provenance-only 三类职责按最强级别聚合且稳定去重；Source index 不再等同必读清单。 |
+| TC-07 | schema-1/2 Contract 使用固定兼容推导，不发生持久写入；schema-3 consumption 可由 propose/revise 正常 authoring。 |
+| TC-08 | project-only、none、coverage 未声明等状态产生准确 gap，但不声称语义完整，也不自动授予动态调查或写入权限。 |
+| TC-09 | bundle 与 renderer 5 同时区分产品边界和 Host 外部授权；任何 Context 都不能扩张权限。 |
+| TC-10 | 合法更新受管 AI Entry region 不改变 outside-owned-ai-entry source digest。 |
+| TC-11 | marker 外人工字节变化产生 source drift；marker/lock/ownership 异常失败封闭，绝不降级为忽略变化。 |
+| TC-12 | 既有 full-file source 保持原摘要；采用新 digest mode 必须显式 review、影响集和人工批准。 |
+| TC-13 | coverage profile v2 持久表达 contract-covered、dynamic-investigation、excluded-approved、unresolved，并验证 item/path 引用。 |
+| TC-14 | Coverage Audit schema 2 只声明已列域；unresolved/review-required 不会被 contract-ready 掩盖。 |
+| TC-15 | Initialization Instruction schema 2 集中展示入口重复规则处置；不自动删除人工 AGENTS 内容。 |
+| TC-16 | capabilities 9、Exchange Protocol 9、AI Entry renderer 5、migration manifest、schema/package whitelist 和全部既有 207 项回归通过；无新 store、Provider、Git、网络、依赖安装或业务代码写入。 |
+
+实现完成时只允许声明：`local-implementation-complete; real-project-revalidation-not-authorized; release-not-authorized`。
+
+### 12.1 本地实现结果
+
+`2026-09-21` 已按冻结合同完成 `1.9.0` 本地实现：Context Bundle schema 1、locate/精确多路径入口、Contract schema 3 的 consumption/digestMode、coverage profile v2、Coverage Audit schema 2、Initialization Instruction schema 2、AI Entry renderer 5，以及 capabilities / Exchange Protocol 9 均已落地。TC-01 至 TC-16 与全部回归共 `223/223` 通过。
+
+本地实现没有新增持久 store，没有访问真实目标项目，没有调用 Provider，没有安装依赖，也没有执行 Git、网络或发布。初轮回归中的旧 O-12 曾触发一次 `npm pack --dry-run`；没有生成或保留 tarball，随后 O-12 已改为纯 package whitelist 校验，最终 223/223 回归不再调用 pack。该 dry-run 是本轮对“不得打包命令”边界的偏离，不能据此声称边界完全未触碰；本地结果也不构成两项目真实 Host 复验或发布结论。
+
+## 13. 两项目外部验收门
+
+本地 TC-01 至 TC-16 与全部回归通过后，仍不能直接发布。真实项目复验需要新的独立授权，并应在两个项目上使用同一冻结候选包执行：
+
+1. 一个目标路径未知的真实任务；
+2. 一个明确跨页面、组件、API/store 的多路径任务；
+3. Host 从目标项目入口发现 renderer 5；
+4. 先 locate，再 targeted；发现新路径后重新编译；
+5. Host 准确报告 item IDs、scopeCoverage、required/conditional/provenance-only；
+6. 不重复读取 provenance-only 来源；
+7. 业务语义缺失时报告 Contract gap，并按用户权限做最小动态调查；
+8. 不把产品的 `businessCodeWrites=false` 误读为 Host 不能完成已授权开发；
+9. 不读取目标根外的自研仓库、历史对话或其他项目真源；
+10. 结束时 Project Context 为 clean，原项目无未授权副作用。
+
+两个项目同属一个产品族时，只能证明已知工作流的重复可用性，不能宣称跨团队普适性。发布门只验证本设计的可证伪假设，不继续增加第三个项目、框架识别或新产品能力。
+
+## 14. 预计实现文件边界
+
+允许范围：
+
+- `src/project-context/cli.mjs`、`renderer.mjs`、`ai-entry.mjs`；
+- Contract/source reader、coverage、capabilities 与对应 schema validator；
+- 新增 `schemas/context-bundle.schema.json`，升级 coverage/capabilities/initialization 相关 schema；
+- `migration-manifest.json`、README、操作手册、升级说明；
+- `test/project-context/` 和 `test/release/` 中 TC-01 至 TC-16 与回归；
+- 实现事实完成后的 `PROJECT_STATE.json`、`RTK.md` 与本设计文档状态段。
+
+禁止范围：
+
+- 修改产品宪法；
+- 新增 Provider、Agent Runtime、模型提示缓存或自动任务执行；
+- 读取或修改真实目标项目；
+- 新增框架/业务白名单；
+- 自动修改用户业务代码、Git、CI 或发布系统；
+- 新增长期 plan、receipt、日志、Context cache 或中心遥测；
+- 自动批准 Contract、coverage 或入口人工区域变更。
+
+## 15. 授权门与停止条件
+
+本设计的本地实现授权已消费。当前唯一下一步是等待用户对“两项目真实 Host 复验”单独授权；在该授权到来前停止，不安装候选包、不访问真实项目、不调用 Provider，也不进入 Git、打包或发布。
+
+已消费的本地实现授权语句为：
+
+> 按 `docs/30-TASK-CONTEXT-CONSUMPTION-CLOSURE-DESIGN.md` 冻结合同实现 `1.9.0`，范围仅限本地产品代码、schema、文档和 TC-01 至 TC-16 及全部回归；保护现有工作，不访问真实目标项目，不调用 Provider，不执行依赖安装、Git、网络、打包或发布。完成后同步实现事实并停止，等待两项目真实 Host 复验授权。
+
+该授权即使给出，也只消费本地实现门。以下必须继续分别授权：
+
+1. 两个真实项目的候选包安装、Host 复验及任何目标项目写入；
+2. Provider 或外部服务调用；
+3. Git commit、tag、push；
+4. npm 打包、网络验证和正式发布；
+5. A-144、Sidecar、Persistent KV 或本设计之外的新方向。
+
+出现下列任一情况立即停止：
+
+- 需要修改宪法或产品身份；
+- 需要自动读取业务源码才能生成 Context Bundle；
+- schema-3 迁移无法保持旧 Contract 只读兼容；
+- managed-region 摘要不能在所有权异常时失败封闭；
+- Context Bundle 被用于授予任务、写入或审批权限；
+- 本地回归失败且修复需要超出本设计范围；
+- Project Context 无法恢复为 clean。
+
+## 16. 后续审计与门序变更
+
+`2026-09-22` 的仓库内自托管只读审计在 `1.9.0` 既有 223 项验收之外确认了三项完整性缺陷：task target 与 registered source 同路径时的重复 read target、同路径多 json-pointer 聚合丢失，以及 Context Bundle 与 Coverage Audit 的 coverage profile 解析不一致。
+
+本文继续作为 `1.9.0` 冻结合同和本地实现事实归档，不回写其历史验收结论；新的缺陷分类、补丁语义、HC-01 至 HC-14 和授权门由 [31-TASK-CONTEXT-INTEGRITY-REPAIR-DESIGN.md](./31-TASK-CONTEXT-INTEGRITY-REPAIR-DESIGN.md) 接管。原“下一步直接进行两个真实项目 Host 复验”的门序暂停，必须先单独授权并完成 `1.9.1` 本地修复，之后再决定真实项目复验授权。