frontend-project-context 1.6.0 → 1.7.0

package/docs/14-FORMAL-RELEASE-READINESS.md

@@ -115,14 +115,18 @@ registry/可见性决策、发布者认证、A-39/pack、release commit、`v1.0.
 
 本次授权只完成既定 `1.3.1` 修复发布，不授权 `ci-reconciliation-artifacts`、Provider、Agent Runtime、任务执行、自动批准、产品内 Git/网络能力、真实业务项目试用、团队验收、公共源码仓库创建或后续发布。发布授权已经消耗。
 
-## 12. `1.6.0` Target Upgrade Protocol 发布候选
+## 12. `1.6.0` Target Upgrade Protocol 正式发布
 
-用户于 `2026-09-11` 明确授权 `1.6.0` 发布候选整理、Git commit/tag/push、官方公共 npm 发布与 registry 独立复验。候选必须在发布前完成：
+用户于 `2026-09-11` 明确授权 `1.6.0` 发布候选整理、Git commit/tag/push、官方公共 npm 发布与 registry 独立复验。冻结候选来自提交 `14fc66ec2dd0524bfb94bd735c8ddc4dfd9a9e14`，远端 `v1.6.0` 精确指向该提交；发布后状态记录留在后续提交，避免改变标签对应的包源码。
 
-1. `npm run check` 120/120；
+发布验证记录：
+
+1. `npm run check` 120/120 通过；
 2. tarball 白名单审查，不包含测试、Git、自托管 `.project-context/`、`PROJECT_STATE.json` 或 `RTK.md`；
 3. 候选 tarball 全新安装后的 version/help/capabilities/status/init/clean-check 冒烟；
 4. 通过包内 manifest 完成 `1.3.1 → check → plan → preview → apply → recheck` 独立冒烟；
-5. tag 与候选提交绑定，registry tarball 与候选字节一致，且 registry 安装后重复关键冒烟。
+5. tarball 包含 83 个文件，压缩大小 272766 bytes、解包大小 972317 bytes，SHA-1 为 `9d3d196900460af86801e9cd543be4d2d9e326ca`，integrity 为 `sha512-dIwhRxARBSvz1uxt+mvXsJEtZfNs1pQVxrVjFQxbw9arbBHzbF4hiUfoURpP+YEazI5dRjZOsDJpIguw0EDJow==`；
+6. `fushanyx1` 于 `2026-09-11T05:45:25.010Z` 向官方 registry public 发布 `frontend-project-context@1.6.0`，`latest` 已指向该版本；
+7. 从 registry 重新下载的 tarball 与候选逐字节一致，随后在全新目录从 registry 安装，version/help/capabilities/status/init/publish-entry/clean-check 全部通过。
 
-该授权不包含真实目标项目升级、Phase D 其余适配器、Provider/Agent Runtime、自动批准或新产品能力。最终候选摘要与 registry 证据只能在实际生成和核验后填写。
+该授权不包含真实目标项目升级、Phase D 其余适配器、Provider/Agent Runtime、自动批准或新产品能力。本次实现与发布授权均已消耗。

package/docs/19-POST-1.3.1-AI-TAKEOVER-EVIDENCE-AND-UPGRADE-PLAN.md

@@ -2,9 +2,9 @@
 
 > 权威说明：本文收敛 `frontend-project-context@1.3.1` 发布后的产品讨论，定义后续设计基线和分期路线。如与 [00-PRODUCT-CONSTITUTION.md](./00-PRODUCT-CONSTITUTION.md) 冲突，以产品宪法为准。
 >
-> 状态：`frozen-overall-design; phase-a-implemented-local; phase-b-detailed-design-frozen`
+> 状态：`frozen-overall-design; phases-a-b-c-implemented-and-published-in-1.6.0`
 >
-> 基线：`frontend-project-context@1.3.1` 是当前已发布版本；仓库内 `1.6.0` Phase C 已完成本地实现与 120/120 验收但未发布，也未在真实目标项目验证。
+> 基线：`frontend-project-context@1.6.0` 是当前已发布并完成 registry 独立复验的版本；真实目标项目升级与 Host 验收尚未授权。
 
 ## 1. 总结论
 
@@ -505,7 +505,7 @@ Upgrade Result Bundle 可以记录 before/after 版本、schema、renderer、迁
 
 目标：把目标项目从旧版本安全、可解释地带到新版本并回到 healthy。
 
-状态：`1.6.0` 已按 [22-PHASE-C-TARGET-UPGRADE-PROTOCOL-DESIGN.md](./22-PHASE-C-TARGET-UPGRADE-PROTOCOL-DESIGN.md) 完成本地实现与 120/120 验收，并已获得 Git、候选打包、公开 npm 发布与 registry 复验授权；真实目标项目升级仍不在本次范围。
+状态：`1.6.0` 已按 [22-PHASE-C-TARGET-UPGRADE-PROTOCOL-DESIGN.md](./22-PHASE-C-TARGET-UPGRADE-PROTOCOL-DESIGN.md) 完成本地实现与 120/120 验收，Git、候选打包、公开 npm 发布与 registry 逐字节一致性/全新安装复验均已完成；真实目标项目升级仍不在本次范围。
 
 - migration manifest schema 和包内发布义务；
 - upgrade check/plan/apply 详细合同；
@@ -568,7 +568,7 @@ Upgrade Result Bundle 可以记录 before/after 版本、schema、renderer、迁
 
 ## 18. 本文停止点
 
-本文已将 `1.3.1` 后讨论收敛并归档为冻结总体设计。Phase A 合同见 [20-PHASE-A-AI-TAKEOVER-AND-HEALTH-CLOSURE-DESIGN.md](./20-PHASE-A-AI-TAKEOVER-AND-HEALTH-CLOSURE-DESIGN.md)，已完成 `1.4.0` 本地实现；Phase B 合同见 [21-PHASE-B-EVIDENCE-FEEDBACK-PROTOCOL-DESIGN.md](./21-PHASE-B-EVIDENCE-FEEDBACK-PROTOCOL-DESIGN.md)，已完成 `1.5.0` 本地实现；Phase C 合同见 [22-PHASE-C-TARGET-UPGRADE-PROTOCOL-DESIGN.md](./22-PHASE-C-TARGET-UPGRADE-PROTOCOL-DESIGN.md)，现已完成 `1.6.0` 本地实现与 120/120。到此仍应停止，不得自动：
+本文已将 `1.3.1` 后讨论收敛并归档为冻结总体设计。Phase A 合同见 [20-PHASE-A-AI-TAKEOVER-AND-HEALTH-CLOSURE-DESIGN.md](./20-PHASE-A-AI-TAKEOVER-AND-HEALTH-CLOSURE-DESIGN.md)，已完成 `1.4.0` 本地实现；Phase B 合同见 [21-PHASE-B-EVIDENCE-FEEDBACK-PROTOCOL-DESIGN.md](./21-PHASE-B-EVIDENCE-FEEDBACK-PROTOCOL-DESIGN.md)，已完成 `1.5.0` 本地实现；Phase C 合同见 [22-PHASE-C-TARGET-UPGRADE-PROTOCOL-DESIGN.md](./22-PHASE-C-TARGET-UPGRADE-PROTOCOL-DESIGN.md)，现已随 `1.6.0` 完成 120/120、正式发布与 registry 独立复验。到此仍应停止，不得自动：
 
 - 修改产品代码、CLI 或 schema；
 - 修改产品宪法；
@@ -576,4 +576,4 @@ Upgrade Result Bundle 可以记录 before/after 版本、schema、renderer、迁
 - 创建 Git 分支、提交、tag、push 或发布 npm；
 - 把 Phase A、B、C 或 D 的顺序解读为实现授权。
 
-用户于 `2026-09-11` 进一步授权 `1.6.0` 发布候选整理、Git commit/tag/push、公开 npm 发布与 registry 独立复验。当前唯一下一步是完成该有界发布流程；Phase D 其余适配器和真实目标项目验收仍未授权。
+用户于 `2026-09-11` 进一步授权 `1.6.0` 发布候选整理、Git commit/tag/push、公开 npm 发布与 registry 独立复验；该有界发布流程已完成，授权已消耗。当前唯一下一步是等待用户选择 `1.6.0` 之后的产品方向；Phase D 其余适配器和真实目标项目验收仍未授权。

package/docs/20-PHASE-A-AI-TAKEOVER-AND-HEALTH-CLOSURE-DESIGN.md

@@ -185,20 +185,20 @@ partial / invalid
 
 ```md
 <!-- project-context:ai-entry:start -->
-<!-- project-context:ai-entry; schema-version: 1; renderer-version: 1 -->
-## Project Context startup
+<!-- project-context:ai-entry; schema-version: 1; renderer-version: 3 -->
+## Project Context 启动流程
 
-Before project work, use the project-local `frontend-project-context` CLI without downloading another version.
+开始项目工作前，使用项目本地安装的 `frontend-project-context` CLI，不要临时下载其他版本。
 
-1. Run `project-context status --project . --json`.
-2. If state is `partial` or `invalid`, stop writes and report the exact recovery evidence required.
-3. If uninitialized, preview `setup`; if initialized with attention, use `sync` work units; if clean, continue the user task.
-4. Never treat a plan, bundle, receipt, review, or AI suggestion as human approval.
-5. Before declaring completion, restore Project Context to `clean` or report the exact blocker.
+1. 运行 `npm exec --offline -- project-context status --project . --json`；如果本地依赖不存在，停止并报告，不要临时下载同名包。
+2. 如果状态为 `partial` 或 `invalid`，停止写入并报告准确的恢复证据。
+3. 如果尚未初始化，先预览 `setup`；如果已初始化但需要处理，使用 `sync` 工作单元；如果为 `clean`，继续遵守本文件其余仓库规则，并执行已获授权的用户任务。
+4. 任何 plan、bundle、receipt、review 或 AI 建议都不代表人工批准。
+5. 声明完成前，将 Project Context 恢复为 `clean`，否则报告准确的阻断项。
 <!-- project-context:ai-entry:end -->
 ```
 
-正式文案可在实现时做不改变语义的中英双语排版调整，但不得增加项目特定事实、当前任务、升级指令或联网安装。
+`1.7.0` 将默认人类可读文案调整为中文，并把 AI Entry renderer 升为 3。renderer 1/2 区域继续可读但报告 stale，只有显式 republish 才升级；机器字段、命令、marker、ID 和枚举继续使用稳定英文。renderer 3 使用 `npm exec --offline -- project-context`，本地依赖缺失时失败封闭，不允许 `npx project-context` 回退下载无关同名包。文案不得增加项目特定事实、当前任务、升级指令或联网安装。
 
 ### 6.2 字节级所有权
 
@@ -309,7 +309,7 @@ Assist Bundle、Task Context Plan、Stage Receipt、Stage Context Bundle 和 Int
 - `schemas.projectStatus: 1`；
 - `schemas.projectionLockReadable: [1, 2]`；
 - `schemas.projectionLockWritten: 1 | 2` 的状态说明；
-- `schemas.aiEntryRenderer: 1`；
+- `schemas.aiEntryRenderer: 3`（renderer 1/2 继续可读，显式 republish 后写 renderer 3 中文安全入口）；
 - `commands` 中的 `status`、`publish-entry`、`remove-entry`；
 - `actionKinds` 中的两种 AI Entry action；
 - `boundaries.telemetry: false`、`boundaries.selfUpdate: false`。
@@ -491,7 +491,7 @@ status: uninitialized | initialized-attention
 - **A-77 未初始化状态**：空项目连续调用 `status` 输出稳定、零写入，state/health/nextActions 正确，不创建 `.project-context`。
 - **A-78 partial 与 invalid**：三种 partial 组合和代表性 schema/JSON 损坏均返回结构化状态与退出码 2，所有 bytes 不变，不猜测修复。
 - **A-79 initialized health**：clean、source changed、pending、verification failed、projection stale 和 ownership conflict 的分类与现有 check/sync 完全一致。
-- **A-80 Entry preview/create**：无 `AGENTS.md` 和已有人工文件的 preview 均零写入；write 只创建/插入精确区域，区域外字节、BOM 和换行保持。
+- **A-80 Entry preview/create**：无 `AGENTS.md` 和已有人工文件的 preview 均零写入；write 只创建/插入精确区域，区域外字节、BOM 和换行保持；入口只调用离线项目本地 CLI，禁止模糊 `npx project-context`。
 - **A-81 区域所有权**：区域外人工编辑不冲突；区域内编辑、marker 缺失/重复/嵌套、lock 错配均失败封闭且不覆盖。
 - **A-82 Entry 更新与移除**：可信区域可确定性 unchanged/update/remove；remove 只移除受管字节和 lock entry，不删文件或区域外内容。
 - **A-83 source 共存**：已登记人工 `AGENTS.md` 时，preview 完整列出影响；写入后仍必须经 accept/reapprove 才恢复 clean，不隐式接受 digest。

package/docs/22-PHASE-C-TARGET-UPGRADE-PROTOCOL-DESIGN.md

@@ -2,11 +2,11 @@
 
 > 权威说明：本文是 [19-POST-1.3.1-AI-TAKEOVER-EVIDENCE-AND-UPGRADE-PLAN.md](./19-POST-1.3.1-AI-TAKEOVER-EVIDENCE-AND-UPGRADE-PLAN.md) 中 Phase C 的可开发合同。如与 [00-PRODUCT-CONSTITUTION.md](./00-PRODUCT-CONSTITUTION.md) 冲突，以产品宪法为准。
 >
-> 状态：`implemented-local-verified; release-candidate-authorized`
+> 状态：`implemented-and-published-public-npm-verified`
 >
 > 目标版本：`frontend-project-context@1.6.0`
 >
-> 实现基线：仓库内 `1.5.0` 已完成本地实现并通过 106/106；公开 npm 中已独立核验的最新版本仍为 `1.3.1`。本文不把设计授权解读为实现、Git、真实项目或发布授权。
+> 发布基线：`frontend-project-context@1.6.0` 已于 `2026-09-11` 发布到官方公共 npm，候选与 registry tarball 逐字节一致，并完成全新 registry 安装冒烟。真实目标项目升级仍未授权。
 
 ## 1. 结论
 
@@ -389,10 +389,10 @@ Frontend Project Context 最多声称 `coreMigration: complete`。整体升级
 3. 在真实目标项目中升级依赖、写 store/projection、执行测试或新窗口验收需要独立范围授权；
 4. Git commit/tag/push、候选打包、网络和 npm 发布需要新的明确授权。
 
-用户于 `2026-09-11` 已给予第 4 项授权，范围限于 `1.6.0` 发布候选整理、Git commit/tag/push、公开 npm 发布与 registry 独立复验；不包含真实目标项目升级或新产品能力。
+用户于 `2026-09-11` 已给予第 4 项授权，范围限于 `1.6.0` 发布候选整理、Git commit/tag/push、公开 npm 发布与 registry 独立复验；该授权已全部执行并消耗，不包含真实目标项目升级或新产品能力。
 
 ## 19. 停止点
 
 本文已冻结 `1.6.0` 的用户问题、产品边界、CLI、manifest 与三份工件 schema、单步收敛、兼容矩阵、并发/失败/回滚、协议版本、文件范围与 A-101 至 A-114。
 
-用户于 `2026-09-11` 明确授权“按 docs/22 实现 1.6.0”；该实现权限已用于源码、schema、测试、package version、manifest 与实现事实文档。A-101 至 A-114 与全部既有回归现已 120/120 通过。当前应停止：Git commit/tag/push、候选打包、网络、npm 发布、真实目标项目升级与 Host 验收均未授权。
+用户于 `2026-09-11` 明确授权“按 docs/22 实现 1.6.0”，随后又授权完整发布流程。实现与 A-01 至 A-114 共 120/120、候选打包、`v1.6.0` tag/push、官方公共 npm 发布、registry 逐字节一致性和全新安装冒烟均已完成。当前应停止：实现与发布授权均已消耗，真实目标项目升级、Host 验收、Phase D 其余适配器、新产品实现或后续发布均需要新的明确授权。

package/docs/23-ADAPTIVE-BOUNDED-TASK-CONTEXT-DESIGN.md

@@ -0,0 +1,432 @@
+# 23 — `1.6.0` 后自适应有界任务上下文反证设计
+
+> 权威说明：本文是 `frontend-project-context@1.6.0` 发布后“真源覆盖、大项目检索与真实需求 token 消耗”的冻结设计与可证伪验收合同。如与 [00-PRODUCT-CONSTITUTION.md](./00-PRODUCT-CONSTITUTION.md) 冲突，以产品宪法为准。
+>
+> 状态：`1.7.0-docs-26-local-implementation-complete; 195/195; bounded-provider-revalidation-not-authorized; release-blocked`
+>
+> 版本：实现新增公开 CLI 与四份 schema，因此本地目标版本确定为 `1.7.0`；发布仍未授权。
+>
+> 基线：`frontend-project-context@1.6.0`，120/120 验收、公共 npm 发布与 registry 独立复验已完成。A-130 历史两次真实对照均为完整 8/8、自适应 7/8。docs/26 的协议与有界评测闭环已本地实现并通过 195/195；新的 Host/Provider 复验尚未授权，`1.7.0` 继续阻断发布。
+
+## 1. 结论先行
+
+本轮反证否定的不是“减少上下文”，而是以下简化方案：
+
+1. 用一个固定小数量或固定小字节数硬截断每次需求的上下文；
+2. 让派生索引代替 Project Contract 或原始来源回答事实；
+3. 宣称自动 discovery 能理解并找全任意项目的所有真源；
+4. 每个小需求都重复做全项目 discovery、全量 source digest 和完整 `check`；
+5. 仅用词法相似度删除上下文，并把未命中解释为“不需要”。
+
+本轮选定的设计是：
+
+> **Adaptive Bounded Task Context（自适应有界任务上下文）**：初始化或显式审计时允许做昂贵的覆盖复核和派生索引重建；真实需求时先返回完整的必选规则、高召回候选和证据闭包，只对相关来源做即时校验；证据不足、冲突、跨模块或预算不足时显式扩展或阻断，不猜测、不静默截断。
+
+“有界”是可观测和可阻断，不是为了最小而最小。优先级固定为：
+
+```text
+需求完成质量
+> 必要规则与证据的召回
+> 可追溯与失败封闭
+> token、读文件数和耗时收益
+```
+
+## 2. 问题边界
+
+### 2.1 本设计解决的问题
+
+用户已确认：初始化阶段的较高消耗可接受，主要问题是项目接入后，一个真实小需求仍可能发生：
+
+- 为了确认上下文健康，重复扫描和哈希无关来源；
+- 路径选择后输出所有适用项，任务文本不参与选择；
+- 摘要、候选、原文和健康检查在多次工具往返中重复产生；
+- 项目越大，全量校验成本越接近项目规模，而不是本次需求的证据规模；
+- 对“没有检索到”、“没有登记”和“已证明不存在”没有严格区分。
+
+### 2.2 本设计不解决的问题
+
+- 不为 Host Agent 实现通用业务代码语义搜索、调用图或 Agent Runtime；
+- 不保证自动理解任意文件中未经人确认的业务含义；
+- 不使用 Provider、embedding 服务、向量数据库、Git 变更检测、文件监听器或 daemon；
+- 不以降低模型推理档位、省略验收或减少必要证据换取数字上的 token 下降；
+- 不把一次真实项目观察直接提升为新内核需求。
+
+## 3. `1.6.0` 基线证据
+
+本设计不假设基线已经有“语义任务检索”。当前代码表明：
+
+1. `context` 先运行完整 `checkProject`，再根据 `--path` 编译上下文；
+2. `renderer.collectBundle` 只用目标路径调用 `effectiveItems`，`task` 只被渲染在输出中，不影响选择；
+3. 每个选中项默认输出 statement、scope、sources 和完整 canonical JSON value；
+4. `sync` 先复核来源，后续又调用 `checkProject`，同一来源可被重复读取或哈希；
+5. `file` 类型的目录来源递归读取并哈希除默认忽略外的所有文件，`path` 来源只校验存在类型；
+6. 自动 discovery 有固定的 config/dependency 列表，规则文件递归深度上限为 8，它是保守候选器，不是完整真源证明；
+7. `stage-context` 已有 canonical UTF-8 和 read-target 预算，且必需内容超预算时阻断，但普通 `context` 尚未共享这套语义。
+
+因此，“慢”和“消耗高”不能只归因于文件 I/O；至少要分开测量来源读取、上下文字节、工具往返和 Host 任务结果。
+
+## 4. 反证法与否证结果
+
+本节不问“方案看起来是否合理”，而是为每个主张寻找一个足以使它失败的反例。
+
+### H1：固定小预算不会伤害需求质量
+
+**反例**：一个看似只改单文件的登录字段，同时受项目级隐私 policy、目录级 API policy、文件级兼容规则和两个 validation-description 约束。如果硬限 8 项，第 9 项仍可能是必要条件。
+
+**结果**：否证。数量与字节只能是软目标和传输安全上限，不能是静默丢失的理由。
+
+### H2：派生索引可以代替原始真源
+
+**反例**：索引中保留了“使用 A”的旧摘要，Project Contract 已被人修订为“使用 B”；或索引摘要省略了例外条件。
+
+**结果**：否证。索引只能找候选，所有输出必须回到当前 Project Contract 与原始来源，并绑定 digest。
+
+### H3：一次自动全扫可以证明所有真源已找全
+
+**反例**：规则存在于内网页面、人工决策、未命名为规则的业务文档，或语句需要业务背景才能判断是否为规范。
+
+**结果**：否证。产品只能证明“已声明覆盖范围内的候选已经审查闭合”，不宣称理解全部项目语义。
+
+### H4：任务局部校验在任何情况下都等价于全局 `check`
+
+**反例**：被延后的项与当前项共用一个 source，或具有 project scope 的 policy 发生 drift；局部路径看似无关，实际上会改变当前任务结论。
+
+**结果**：否证。局部快速路径必须计算 scope、override、subject 和 source 共享的证据闭包；项目级规则永远不能因路径局部而被跳过。
+
+### H5：无变化信号、无全扫，仍可证明项目没有新真源或无关来源变更
+
+**反例**：在上次 clean 快照后，某人新增一个不在已登记集中的规则文件；运行时既不扫描目录，也不接收 Host 的 changed paths。
+
+**结果**：逻辑上不可能证明。必须三选一：接受 snapshot/signal-bound 保证、接收 Host 变化信号，或回退显式全局审计。产品不得把未校验包装为 `clean`。
+
+### H6：输出字节越少，真实需求就必然更快、更省 token
+
+**反例**：首轮输出很小，但 Host 需要连续调用五次工具才补齐证据；总模型输入、思考和往返时间反而更高。
+
+**结果**：否证。验收必须测量完整需求链路，不得只比较首包字节数。
+
+### H7：每次先运行全量 `check` 就能解决真源不彻底
+
+**反例**：全量 `check` 可以证明已登记来源的当前状态，却不能发现从未登记、也不在 discovery 候选中的业务规则。
+
+**结果**：否证。“登记覆盖”和“已登记来源新鲜度”是两个不同问题，必须分开报告。
+
+### H8：Adaptive Bundle 的传输包络天然小于完整 Context
+
+**反例**：真实项目的小型 Contract 只有少量必选项，但 initial bundle 为每个延后项携带 ID、digest、kind、scope、source 和 reason，同时还携带 source、健康与预算元数据。即使水合正文更少，完整 JSON 包络仍可能更大。
+
+**结果**：A-130 否证。完整 Context 初始提示为 12,351 UTF-8 字节，自适应提示为 14,466 字节，反增 17.1%。延后目录必须继续可审查，但不能再假设当前 schema 的完整机器包络本身就是字节优化。
+
+### H9：把机器审查 Bundle 整体传给模型不会干扰任务推理
+
+**反例**：A-130 的自适应臂将 deferred item 目录、digest、健康与预算元数据一起放入模型首轮输入。这些字段对 Host 审计有用，但不是业务任务证据；小 Contract 时它们比完整 Context 更大。
+
+**结果**：否证并修复。`context-query --json` 保留完整可审计 Bundle，`context-query --prompt` 只输出 digest-bound 的模型面向 Markdown。当完整适用 Context 字节数不大于机器 Review Bundle 时，投影确定性选择 `complete-fallback`；否则使用自适应证据闭包。Host 不再需要把审查包络传给模型。
+
+## 5. 三类保证，不再混用“真源完整”
+
+| 保证 | 回答的问题 | 可以证明 | 不可以证明 |
+| --- | --- | --- | --- |
+| Registration Coverage | 应该纳入治理的来源是否被审查 | 显式覆盖范围内的候选均已登记、排除或待决策 | 任意项目的全部隐式业务语义已被 AI 理解 |
+| Contract Coverage | 当前需求需要的长期规则是否有批准项 | 已批准 item、scope、override 和 provenance 的确定性闭包 | 未经人批准的候选自动成为规范 |
+| Freshness | 这些规则依赖的来源现在是否一致 | 已校验证据闭包与快照一致 | 未扫描、无变化信号的全项目仍然 clean |
+
+任何机器输出必须分别展示这三项，不能用一个 `complete: true` 混淆。
+
+## 6. 总体架构
+
+```text
+初始化 / 显式全局审计（可昂贵）
+→ 覆盖候选与人工决策闭合
+→ 批准的 Project Contract（唯一长期真源）
+→ 可重建 Routing Index + coverage/source snapshot（派生）
+
+真实需求快速路径
+Host task + target paths + topics + changed-path signals
+→ 校验 Contract/index 基线
+→ 必选项 + 高召回候选 + provenance/source 闭包
+→ 只校验相关来源
+→ 一次返回已水合内容、延后目录、扩展原因和健康级别
+→ 证据足够则进入需求；不足则扩展一层或阻断
+```
+
+实现必须共享一个选择内核，普通 task context 与 `stage-context` 不得形成两套相互矛盾的召回语义。
+
+## 7. 初始化与显式审计路径
+
+### 7.1 Coverage Profile 的归属
+
+覆盖根、明确排除和人工判定属于规范决策，必须以带 provenance 的普通 Project Contract item 表达，不新增第二份治理真源。
+
+产品可以定义一个机器可读的 coverage value 结构，但它只有在 item 被人明确批准后才生效。自动扫描生成的排除建议始终是 proposed candidate。
+
+### 7.2 Coverage Audit
+
+新的只读审计能力暂定为：
+
+```text
+project-context coverage-audit --project PATH [--changed-path PATH...] [--json]
+```
+
+它只在初始化、覆盖规则变更、发布、显式审计或无可信变化信号且要求严格新鲜度时执行。
+
+输出将候选分为：
+
+- `registered`：已有 active source 登记；
+- `excluded-approved`：有已批准、可追溯的排除决策；
+- `review-required`：位于已声明覆盖范围，但无登记或排除结论；
+- `outside-declared-coverage`：不在产品当前声明能证明的范围。
+
+只有 `review-required` 为空时，Registration Coverage 才能为 `closed-for-declared-scope`。它永远不输出 `all-project-truth-discovered`。
+
+### 7.3 Routing Index
+
+派生索引位于 `.project-context/derived/`，必须满足：
+
+- 只从当前 Contract、source registration、scope、subject、statement 和 locator 确定性重建；
+- 可以保留 token/term、path-prefix、item/source 反向边和内容 digest，不保留未批准真源副本；
+- 包含 contract/source-lock/schema/selector version 基线和 self-digest；
+- 丢失或过期时可从 Contract 内存重建，不得因索引缺失返回“无规则”；
+- 默认只读命令不写缓存；只有明确 `--write` 才能持久化重建结果；
+- 不是 store、Project Contract、approval 或健康证明，删除它不影响长期真源。
+
+## 8. 真实需求快速路径
+
+### 8.1 Host 输入
+
+Host Agent 根据用户原始需求准备一份短生命 `Context Query`，至少包含：
+
+- 原始 task text，不得只传 AI 摘要；
+- 已知 target paths，允许为空但会降低保证；
+- 由 Host 提取的 topics，作为候选信号而非真理；
+- 用户或 Host 明确要求的 item IDs；
+- Host 已知 changed paths；
+- 快照基线、freshness mode 和软/硬预算。
+
+Host 生成的 topic、path 和扩展请求不产生 approval，也不能扩大任务权限。
+
+### 8.2 选择顺序
+
+一次编译按以下顺序生成证据闭包：
+
+1. 验证 Contract、source lock 和 query snapshots；
+2. 对每个 target path 运行当前 scope/override/conflict 语义；
+3. 无条件纳入明确 item IDs；
+4. 无条件纳入所有适用的 `policy` 和 `validation-description`；
+5. 路径先通过既有 scope/override 语义约束候选；再纳入与原始 task text/topics 匹配的 fact/reference。`src`、`admin` 等通用路径段不能单独成为语义命中，否则会把同一 scope 的无关 fact/reference 全部水合；
+6. 纳入上述项的 override、subject-conflict 和 provenance/source 闭包；
+7. 对共享 source、project scope 和跨 target path 关系扩展一层；
+8. 校验闭包内的 active local sources；
+9. 返回已水合项、延后候选目录、选择原因、预算和健康声明。
+
+“所有适用 policy/validation 必选”是质量优先的故意取舍。如果这一集合本身巨大，应改善 Contract 的 scope 和内容粒度，不应在运行时偷偷丢掉规则。
+
+### 8.3 两类预算
+
+- `targetUtf8Bytes` / `targetReadTargets`：软目标。证据闭包可以超过，输出必须说明原因。
+- `maxUtf8Bytes` / `maxReadTargets`：传输安全上限。必需内容超过时返回 `blocked/context-budget-insufficient`，不截断、不返回假 `ready`。
+
+本设计不冻结“8 个候选 / 16 KiB”为产品真理。默认值只能由基准数据决定，且用户或 Host 可在硬上限内调高软目标。
+
+## 9. 自适应扩展
+
+### 9.1 必须扩展或阻断的触发器
+
+- 没有命中任何任务候选，但存在适用 Contract items；
+- task/topic 命中多个不兼容 subject；
+- target path 未知、不存在或越出已声明 coverage；
+- 需求跨顶层模块、shared package、公共组件或多个 scope；
+- 命中项、project-scope 项或共享 source 发生 drift；
+- 相关 coverage 中存在 `review-required`；
+- 验收、API、业务语义或影响边界不完整；
+- Host Agent 明确声明 evidence insufficient；
+- 必选闭包超过硬预算。
+
+### 9.2 扩展级别
+
+| 级别 | 用途 | 语义 |
+| --- | --- | --- |
+| `initial` | 普通局部需求 | 必选项 + 高召回候选 + 一层证据闭包 |
+| `expanded` | 证据不足或跨模块 | 在原 bundle digest 上增加指定 subject/source/scope 邻接项，不重复已水合正文 |
+| `complete` | 显式深度工作或基线对照 | 当前 target paths 的全部有效项，并运行严格健康校验 |
+
+`expanded` 必须绑定前一 bundle digest 和当前 snapshots。任何基线变化都使扩展请求失效，防止把新旧上下文拼在一起。
+
+## 10. 任务健康与全局健康
+
+新协议不重定义已有 `status.health=clean`。它在任务 bundle 中并列报告：
+
+- `globalHealth`：来自本次 strict check 或 Host 提供的快照，可为 `clean | attention | conflict | not-checked | snapshot-stale`；
+- `taskHealth`：对当前 item/source/coverage 证据闭包的结论，可为 `ready | needs-expansion | blocked`；
+- `freshnessGuarantee`：`strict-current | snapshot-and-signal-bound | unverifiable`。
+
+规则如下：
+
+1. `globalHealth=clean` 只能由本次完整健康检查得出；
+2. 快速路径可在 `globalHealth=not-checked` 时返回 `taskHealth=ready`，但必须明示 snapshot/signal-bound；
+3. 相关 source drift、project-scope drift、冲突、coverage 未决或基线过期时，`taskHealth` 必须为 `blocked` 或 `needs-expansion`；
+4. 不相关但已知的全局 finding 不得被删除，必须作为 warning 携带；
+5. 用户要求绝对当前新鲜度，但无 Host changed paths 或其他可信信号时，自动进入 `complete/strict`，不在快速路径中猜测。
+
+## 11. 公开协议草案
+
+### 11.1 CLI
+
+```text
+project-context coverage-audit --project PATH [--changed-path PATH...] [--json]
+project-context index-context --project PATH [--write] [--json]
+project-context context-query --project PATH --input FILE [--previous FILE] [--json]
+project-context context-query --project PATH --input FILE [--previous FILE] --prompt
+```
+
+- 三个命令均默认只读；
+- `index-context --write` 只写可重建派生索引，不修改 Contract、source lock 或 projection；
+- `context-query` 不读业务代码正文，只水合 Contract 内容并为 Host 返回精确 read targets；
+- `--json` 是 Host 审查面，`--prompt` 是单次工具调用的紧凑模型投影，两者互斥；
+- `--previous` 只接受通过 schema/self-digest/snapshot 校验的上一份 bundle；
+- 旧 `context` 保持兼容的按路径完整输出，并作为 correctness baseline；
+- `stage-context` 在同一实现阶段复用新 selector，但 schema 1 输入仍保留现有完整语义。
+
+### 11.2 `Context Query` schema 1
+
+固定字段：
+
+```json
+{
+  "schemaVersion": 1,
+  "kind": "context-query",
+  "projectId": "example",
+  "snapshots": {
+    "contract": "sha256:...",
+    "sourcesLock": "sha256:...",
+    "projectionsLock": "sha256:..."
+  },
+  "task": {
+    "text": "original user request",
+    "paths": ["src/feature/example.ts"],
+    "topics": ["authentication"],
+    "itemIds": [],
+    "changedPaths": []
+  },
+  "level": "initial",
+  "freshness": "snapshot-and-signal-bound",
+  "budget": {
+    "targetUtf8Bytes": 32768,
+    "targetReadTargets": 12,
+    "maxUtf8Bytes": 131072,
+    "maxReadTargets": 64
+  }
+}
+```
+
+示例数字只用于说明软/硬预算的区别，不是已冻结默认值。最终默认值必须由验收基准决定。
+
+### 11.3 `Adaptive Context Bundle` schema 1
+
+至少包含：
+
+- project/task/snapshot/index/self digests；
+- `globalHealth`、`taskHealth` 和 `freshnessGuarantee`；
+- 已水合的完整 item 内容；
+- deferred item 的 ID、kind、subject、scope、digest 和延后原因，不含 value/statement 正文；
+- item/source/override/conflict 证据闭包；
+- read targets 及选中原因；
+- coverage 三类保证和已知降级；
+- 软/硬预算使用量；
+- expansion triggers 和可请求的精确 item/source/subject IDs；
+- 固定 excluded bodies/boundaries，确保无 Provider、authority、shell 或 business-code body。
+- `delivery`：记录 `adaptive | complete-fallback`、精确 item IDs、Markdown content digest 与字节数，不在 JSON 中重复模型正文。
+
+## 12. 性能收益必须从哪里来
+
+允许的优化来源只有：
+
+1. 初始化/审计时建立可重建路由结构，任务时不重做全局 discovery；
+2. 同一请求内的 source read/digest 去重与 memoization，避免 `sync`/健康分类反复读同一来源；
+3. 任务路径只校验证据闭包，全局健康保留为独立声明；
+4. 相同项跨多路径只水合一次，不重复输出 value/statement/source index；
+5. 首包同时返回水合内容、延后目录和扩展入口，减少 Host 为了搞清“还缺什么”的串行工具往返；
+6. 扩展包只输出新增内容，通过 digest 与首包组合，不重发旧正文。
+
+不允许通过以下方式制造“收益”：丢掉适用 policy、只给摘要不给原文、降低验收要求、把 blocked 计为快速成功、或忽略为补证据产生的后续工具往返。
+
+## 13. 可证伪验收合同
+
+以下编号从已发布的 A-114 后延续。A-115 至 A-129 已成为本地自动验收；A-130 已在真实 Host/目标项目执行并因质量下降失败，详细证据见 [24-A130-REAL-HOST-TARGET-PROJECT-COMPARISON.md](./24-A130-REAL-HOST-TARGET-PROJECT-COMPARISON.md)。
+
+| ID | 反例/场景 | 必须成立的结果 |
+| --- | --- | --- |
+| A-115 | 单路径小需求同时有项目、目录和文件级 policy | 所有适用 policy/validation 均水合，与完整 `context` oracle 一致 |
+| A-116 | 关键规则位于第 9 项且软目标为 8 | 超软目标但不丢失；超硬上限则 blocked，不截断 |
+| A-117 | 任务文本与路径同时命中两个冲突 subject | 返回 needs-expansion/blocked 和完整冲突边，不自动择一 |
+| A-118 | 修改 Contract 后保留旧 Routing Index | 旧索引被拒绝；从当前 Contract 内存重建或明示降级，不返回旧事实 |
+| A-119 | 删除 Routing Index | 不返回“无规则”；只读内存重建可继续，且不产生写入 |
+| A-120 | 相关 source 或 project-scope policy source 发生 drift | 快速路径阻断，列出精确 source/item 和恢复入口 |
+| A-121 | 已知 finding 仅影响 sibling scope | 任务可为 ready，但 global warning 仍保留，不宣称 global clean |
+| A-122 | 上次快照后新增未登记规则文件，且无 changed-path 信号 | signal-bound 模式不声称绝对新鲜；strict 模式必须全局审计或阻断 |
+| A-123 | 一个 source 被已水合与延后项共享 | source 进入证据闭包并只校验一次 |
+| A-124 | 一个需求跨 feature 与 shared package | initial 包识别跨模块信号，expanded 包补全邻接 scope 且不重发旧正文 |
+| A-125 | 同一 paths，不同 task/topics | 选中的 fact/reference 可以不同；必选 policy/validation 必须相同 |
+| A-126 | coverage 中存在未登记且未排除候选 | Registration Coverage 只能为 review-required，不得输出 closed |
+| A-127 | 为同一小需求比较 1.6.0 与新路径 | 全链路必选 item 召回 100%，且新路径不得增加 Host 工具往返 |
+| A-128 | 全部敌意 fixture 和人工标注 task corpus | 最终 bundle 对 required Contract items 召回 100%，任一缺失直接否决发布 |
+| A-129 | 效率对照 | 在不触发扩展的局部 task corpus 上，相比 1.6.0 至少减少 40% 的 context UTF-8 字节且减少 50% 的 source body/digest reads；未达到则不宣称解决性能问题 |
+| A-130 | 端到端 Host 对照 | 模型只接收 `--prompt` 投影；完成同一需求的总输入字节、总工具调用、总耗时和结果质量同时记录；任务质量下降则即使 token 更少也失败 |
+| A-130R | 小 Contract 的审查包络大于完整 Context | `delivery.mode=complete-fallback`，`--prompt` 与完整 Context 字节等价，不携带 deferred/review 包络 |
+
+### 13.1 评测 oracle
+
+必须建立两类 oracle：
+
+1. **确定性 oracle**：用完整 `context` + 手工标注的 required item/source 集合，验证 selector 没有丢失必要 Contract 证据。
+2. **Host 结果 oracle**：在获得真实 Host/项目验收授权后，使用相同任务、验收和模型配置比较完整上下文与自适应上下文。
+
+本地实现证据没有推翻 H1 至 H7，A-115 至 A-129 已通过；其中 A-129 只证明隔离局部 task corpus 达到 `>=40%` context UTF-8 字节与 `>=50%` source body reads 的门槛。A-130R 已证明小 Contract 会通过紧凑 `--prompt` 退回与完整 Context 字节等价的输入，但随后的真实复验仍为完整 8/8、自适应 7/8；因此本地 fixture 成功不构成外部 Host 成功结论。
+
+## 14. 分段实现结果
+
+本地实现已按以下顺序完成前五段，没有先建设语义索引大工程：
+
+1. **基准与去重**：为现有 `context`/`sync` 记录 source reads、bytes、tool calls；同一命令内复用 digest/read 结果。
+2. **共享 selector 与结构化 bundle**：先实现必选项、证据闭包、延后目录和软/硬预算，不持久化索引。
+3. **任务健康**：实现 task/global/freshness 分离和 strict 回退，保持现有 `clean` 语义。
+4. **派生 Routing Index**：只在无索引内存路径已通过 correctness 后加入，证明它只优化耗时而不改变选择结果。
+5. **Coverage Audit**：将登记覆盖问题与新鲜度问题分开验收，不扩充框架白名单。
+6. **A-130 本地修复**：分离审查 JSON 与模型投影，增加小 Contract 完整上下文回退与 A-130R。
+7. **Host 重验**：已在单独授权后用相同模型/任务/oracle 执行；结果 8/8 对 7/8，门禁失败，通过前不得发布。
+
+实现中第一次敌意路由 fixture 发现：如果把通用 path segment 直接当词法命中，同 scope 的无关 fact/reference 会被错误水合。这一证据没有推翻“路径参与选择”，但修订了其语义：路径负责 scope narrowing，原始 task text/topics 负责内容路由，显式 item ID 继续无条件进入。修订后的 A-124/A-125/A-127/A-128 均通过。
+
+任一阶段发现 required-item 召回下降，必须回退到上一阶段；不得通过放宽评测标注继续推进。
+
+## 15. 兼容、迁移与边界
+
+- Project Contract 仍是唯一批准真源，现有 contract/source/projection store 不因索引必然升级；
+- 旧 `context` 输出语义保留，不在没有兼容入口时强制消费者迁移；
+- 派生索引不进入 approval、projection ownership 或 source lock；
+- 不新增 Provider、Agent loop、Git、network、dependency install、business-code write、scheduler、daemon 或 telemetry；
+- 不引入按框架增长的 discovery 白名单；
+- Host 的业务代码搜索与任务执行仍属于外部 Coding Agent，本产品只返回项目已治理来源的 read targets。
+
+## 16. 宪法分类
+
+本设计属于：
+
+- Scope Compiler / Context Renderer 对“按目录和任务生成必要上下文”的质量与效率完善；
+- Source Registration & Provenance 的覆盖证据完善；
+- AI Exchange Boundary 的短生命、无权限查询与 bundle 协议；
+- 可选 Host Adapter 的任务信号输入，不是 Agent Runtime。
+
+它不新增第八项内核，不改变产品宪法第 2 至第 6 节，因此基线下不需要宪法版本变更。
+
+## 17. 停止规则与当前授权
+
+用户于 `2026-09-11` 单独授权本设计的本地实现，并要求实现证据若与反证结论冲突则修订结论；又于 `2026-09-11` 至 `2026-09-12` 分两步授权 A-130 真实目标项目、真实 Host 与既定评测内容的 Provider 传输。两项授权均已消费。它们不授权：
+
+- 再次运行、扩大样本或更换模型继续做 Host 对照；
+- 修改业务代码、安装依赖，或把 Provider 访问扩大到本次两次只读运行之外；
+- Git commit/tag/push、npm 发布或下一版本号确定。
+
+用户于 `2026-09-12` 授权将 A-130 修复与 `docs/25` 协议正确性统一处理，随后单独授权并确认向当前 `custom` Provider 发送披露的私有评测材料，执行两次只读复验。本地修复与 Provider 复验权限均已消费，没有扩张为再次修复、新的 Provider 调用、真实项目写入、Git 或发布权限。当前唯一下一步是：
+
+> 复验已按 `--prompt`、同一任务/模型/oracle 执行并失败。下一轮协议与有界评测修订已按 [26-A130-QUALITY-CLOSURE-AND-ADAPTIVE-DELIVERY-REPAIR-DESIGN.md](./26-A130-QUALITY-CLOSURE-AND-ADAPTIVE-DELIVERY-REPAIR-DESIGN.md) 完成本地实现并通过 195/195；S 一对、L 三对、最多八次的新 Provider 重验、Git 和发布仍各自需独立授权。