frontend-project-context 1.3.0 → 1.6.0

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

@@ -0,0 +1,579 @@
+# 19 — `1.3.1` 后 AI 接管、证据反馈与目标项目升级总体设计
+
+> 权威说明：本文收敛 `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`
+>
+> 基线：`frontend-project-context@1.3.1` 是当前已发布版本；仓库内 `1.6.0` Phase C 已完成本地实现与 120/120 验收但未发布，也未在真实目标项目验证。
+
+## 1. 总结论
+
+`1.3.1` 已经完成 Project Contract、上下文编译、AI Exchange Boundary 和跨窗口分阶段交接，但目标项目的真实使用仍有四个断点：
+
+1. 安装不等于接管；新 AI 窗口不一定知道要检查或调用 `project-context`。
+2. `setup` 只创建安全的 store 和 proposed 候选，没有将项目入口梳理、人工决策、投影发布和最终健康恢复连成用户级闭环。
+3. 任务结束后缺少统一收尾规则，容易把审核、receipt、计划、日志或“待整理真源”长期留在项目里。
+4. 已安装的目标项目没有正式升级协议，现有 `UPGRADING.md` 仍依赖人或 AI 解读逐版本文字。
+
+后续产品方向因此固定为：
+
+> 人类管理长期真源和有影响的授权；外部 AI 按项目入口自动识别、准备和执行已授权流程；Frontend Project Context 提供模型无关、机器可读、失败封闭的状态、计划、迁移和验证合同。
+
+本方向不在目标项目中修改 `node_modules` 或让 AI 自行重写工具内核，也不将用户变成 CLI 流程操作员。
+
+## 2. 产品层次与责任
+
+| 层次 | 责任 | 不负责 |
+| --- | --- | --- |
+| 人 | 确认长期事实/规则、语义变更、冲突、目标版本和外部权限 | 记忆低层 CLI 顺序、逐文件维护状态 |
+| Host Agent | 读入口、调用机器协议、渐进读取、准备变更、执行已授权命令、恢复健康 | 自己批准真源、伪造人类身份、无权扩大执行范围 |
+| Frontend Project Context | 确定性识别状态、编译上下文、预检计划、迁移产品自有数据、检查漂移与所有权 | Provider、Agent loop、Git、包安装、业务代码执行、外部发布 |
+| 项目现有工具 | 包管理、Git/CI、测试、构建、业务发布 | 批准 Project Contract |
+| 中心产品项目 | 收集人工转交的证据，聚类、复现、设计、验收并发布新版本 | 直接连接和遥控所有目标项目 |
+
+### 2.1 本轮分类
+
+- AI 接管入口：可选 Host Agent 适配协议，不是内置 Agent Runtime。
+- 机器可读的项目状态与升级计划：服务 AI Exchange Boundary、Projection Boundary 与漂移检查的产品演进。
+- 证据包：可选、短生命交换协议，不是新真源或自动需求队列。
+- 中心分析与新版本发布：产品项目的研发流程，不嵌入目标项目运行时。
+
+这些能力不需要新增第八项内核，也不要求修改宪法中的永久边界。
+
+## 3. 目标项目的统一生命周期
+
+```text
+安装或打开项目
+→ AI 读取稳定入口
+→ 只读识别 absent / uninitialized / partial / healthy / attention / upgrade
+→ 初始化或恢复现有健康状态
+→ 人确认首批长期真源和投影范围
+→ AI 完成所有机械动作
+→ 正常执行项目需求
+→ 任务收尾时区分短期证据与长期事实
+→ 有持久变更才维护 Contract
+→ sync / check / 项目验证
+→ 清理短期工件，回到 healthy
+→ 需要时由人将证据转交回中心产品项目
+```
+
+任何子流程都不能把项目长期留在“待审核、待整理真源、升级中或待恢复”。如果客观阻断尚未解决，AI 必须说明阻断与恢复入口，不能将其包装为完成。
+
+## 4. 新窗口 AI 的稳定接管入口
+
+### 4.1 为什么必须改造项目入口
+
+安装 npm 依赖只会使 CLI 可用，不会使未知情的 AI 自动调用它。只把状态放在 `.project-context/` 也不足够，因为多数 AI 工具首先读取的是根或目录级指导文件。
+
+因此每个已接管目标项目必须有一个稳定、短小、模型无关的 AI Entry Projection。默认优先使用项目已采用的 `AGENTS.md`；如项目使用 Ruler 或其他现有入口，应将同一内容投影到对应消费端，不复制第二份真源。
+
+### 4.2 入口只做路由
+
+AI Entry 只应告诉新 AI：
+
+1. 先调用哪个只读状态入口；
+2. 如何区分未初始化、partial、待维护、健康和待升级；
+3. 如何根据 `readTargets` 和 `workUnits` 渐进读取；
+4. 哪些动作可自动预览，哪些必须人确认；
+5. 任务结束前如何回到 healthy。
+
+入口不应复制完整 Contract、版本升级文字、当前任务计划或审核历史。
+
+### 4.3 `AGENTS.md` 所有权
+
+推荐投影一个带边界的受管区域：
+
+```md
+<!-- project-context:managed:start -->
+由工具生成的 AI 接管路由
+<!-- project-context:managed:end -->
+```
+
+具体规则：
+
+- 不存在 `AGENTS.md`：可在明确发布授权下创建受管文件。
+- 已有人工 `AGENTS.md`：不覆盖；AI 先梳理现有入口，展示最小接入位置，人确认后只写受管区域。
+- 已有受管区域且 digest 一致：可显式 republish。
+- 受管区域被人工改动：报告 ownership conflict，禁止覆盖。
+- 受管区域外的任何内容：永远保留。
+- 无法在根入口安全共存：可在合适子目录生成嵌套 `AGENTS.md`，或使用项目现有投影工具。
+
+## 5. 统一状态识别
+
+Host Agent 应先消费一份只读、机器可读的 Project Status，不先猜测下一条命令。后续可在既有 `capabilities`/`setup`/`sync` 上收敛一个聚合入口，命令名在实现设计阶段冻结。
+
+### 5.1 必须区分的状态
+
+| 状态 | 含义 | AI 动作 |
+| --- | --- | --- |
+| `tool-absent` | 项目未声明工具依赖 | 说明安装影响；获得依赖/网络权限后由宿主安装 |
+| `uninitialized` | 三份 store 均不存在 | 预览 setup，准备项目 ID/name 和候选 |
+| `partial` | 只存在部分 store | 失败封闭；只从 Git/备份/明确人类输入恢复 |
+| `initialized-attention` | 存在 drift、pending、stale 或 conflict | 按 work unit 维护，不隐式修复 |
+| `healthy` | Contract/store/projection 均可读且 check clean | 进入正常需求工作 |
+| `upgrade-available` | 宿主已提供目标版本，本地版本较旧 | 只读生成兼容性与升级计划 |
+| `upgrade-blocked` | 当前状态或版本路径不可安全迁移 | 维持现场，报告精确恢复条件 |
+
+### 5.2 partial 的固定处理
+
+`setup-state-partial` 的当前失败封闭语义保留。问题不在于工具“没有 init”，而在于它无法判断已存在目录是：
+
+- 失败的初始化残留；
+- 被误删的真源；
+- 其他版本或其他项目的数据；
+- 尚未写完的并发操作。
+
+任何自动补齐都可能将真实损坏包装成新项目。因此只能由宿主 AI 在项目既有权限下查找 Git 或备份，再向人展示恢复根据；核心工具不猜测、不删除、不重创。
+
+## 6. `setup` 后的 AI 全流程
+
+`setup` 仍是安全的底层原语，不应把批准、发布和业务执行塞进一条无边界命令。但用户体验应改为：用户说“接管这个项目”，AI 负责运行完整协议。
+
+### 6.1 未初始化项目
+
+1. AI 只读检查项目、包版本和入口文件。
+2. 调用 `setup` preview，不产生写入。
+3. 只按 `readTargets` 梳理 package/config/docs/现有 AI 入口。
+4. 归并确定性 fact/reference，起草 policy 和 validation-description。
+5. 向人集中展示：项目身份、长期来源、候选规则、作用域、AI 入口位置和投影路径。
+6. 人明确确认项目身份、项和路径后，AI 执行 setup write、proposal preview/approve 与 publish。
+7. AI 运行 sync/check，清理 create-only proposal 等短期产物，回到 healthy。
+8. 用一个无历史对话的独立窗口验证入口可发现和接管。
+
+### 6.2 已初始化项目
+
+1. AI 不重写 store，先验证 project ID/name 和 schema 可读性。
+2. 运行 sync，识别 source drift、pending item、projection finding 和 ownership。
+3. 无问题直接进入任务；有问题只处理影响子集。
+4. 已有人工入口时，先梳理它如何与受管路由共存，不重新发明第二套项目规则。
+
+## 7. 人和 AI 的授权边界
+
+### 7.1 AI 可自动完成
+
+- 读取项目入口和机器状态；
+- 运行只读 capabilities/setup preview/sync/check/preflight/upgrade check；
+- 根据精确 read target 渐进读取；
+- 起草 proposal、Action Plan、Migration Plan 和 Evidence Bundle；
+- 展示影响、冲突、基线、可逆性和验收；
+- 在用户已对一组精确动作授权后，顺序执行机械写入；
+- 失败后停止、重读状态并提供恢复入口；
+- 完成后清理短期工件、验证 healthy。
+
+### 7.2 必须由人决定
+
+- 首次进入 Contract 的长期事实、规则和作用域；
+- 来源变更是继续接受、修订、替换还是废弃；
+- 相互冲突的规范和 ownership conflict；
+- 依赖安装、联网、Git 写入、发布、外部系统修改；
+- 目标升级版本和重大语义/不可逆迁移；
+- 是否将某份证据转交给中心产品项目。
+
+人确认的是决策和影响，不是 CLI 指令细节。
+
+## 8. 健康状态与任务收尾
+
+### 8.1 healthy 的固定含义
+
+一个目标项目只有同时满足以下条件才是 healthy：
+
+- 三份 store 完整且 schema 可读；
+- Contract 中没有本轮未结算的 pending item；
+- active 本地来源 digest 与 lock 一致；
+- 受管 projection 不 stale、不 diverged、没有 ownership conflict；
+- 不存在未执行的当前迁移；
+- `sync`/`check` 按合同通过；
+- 当前任务需要的项目测试或 CI 已由宿主执行并记录结果；
+- 没有为继续对话而保留的必需聊天历史。
+
+### 8.2 短生命工件的处理
+
+| 工件 | 默认归属 | 任务后处理 |
+| --- | --- | --- |
+| setup proposal | 审查输入 | 批准、拒绝或替换后不再参与正常上下文 |
+| Assist/Context/Review Bundle | 派生交换工件 | 用完即失效，不写入 Contract |
+| Task Plan/Stage Receipt | 任务交接 | 任务关闭后由宿主归档或删除，不由核心保管 |
+| Migration Plan/Upgrade Result | 升级证据 | 升级验收后清理；需要反馈时由人带回中心项目 |
+| 测试日志/diff/聊天 | 外部执行证据 | 不自动进入 Project Contract |
+
+“保持健康”不是删掉一切可追溯记录；Git、CI 或外部工单可以保留它们。它只意味着不把过程工件当成未来每个 AI 都必须读取的长期项目指导。
+
+## 9. 什么时候整理长期真源
+
+任务结束时不再固定进入“整理真源”状态。AI 只先执行一次候选判定。
+
+### 9.1 应进入 Contract 维护的条件
+
+候选内容至少满足以下任一条，才值得提请人审查：
+
+- 对未来多个任务仍然有效的项目事实；
+- 已稳定采用的架构或业务 policy；
+- 不记录就会让后续 AI 重复犯错的边界；
+- 已成为稳定正式入口的文档、配置或参考源；
+- 能够稳定、可重复表达的验证方式；
+- 已批准来源发生持久语义变更，需要修订或废弃现有 item。
+
+### 9.2 不应进入 Contract
+
+- 单次任务步骤、时间线、聊天摘要；
+- 未合并 diff、临时 debug 命令、详细测试日志；
+- 未被项目采用的 AI 建议或备选方案；
+- 个人经验推断、confidence 和模型推理；
+- 只对当前分支/临时发布有效的约束；
+- 为了证明 AI 做过什么而保留的审计材料。
+
+### 9.3 收尾判定
+
+```text
+没有长期候选
+→ 不发起真源维护
+→ check clean
+→ 结束
+
+存在长期候选
+→ AI 只列候选、来源、作用域和影响
+→ 人批准或拒绝
+→ AI 完成 propose/revise/approve/publish
+→ sync/check clean
+→ 结束
+```
+
+## 10. 目标项目证据反馈与产品进化
+
+### 10.1 不在目标项目自我修复内核
+
+已安装包是版本化、可复现的产品边界。目标项目中的 AI 不得：
+
+- 修改 `node_modules/frontend-project-context`；
+- 将本项目的差异直接当成通用需求；
+- 生成并自动安装未经中心验证的补丁；
+- 把本地 workaround 写入 Project Contract 作为产品内核规则；
+- 自动上传项目代码、真源正文、路径细节或凭据。
+
+### 10.2 Evidence Bundle
+
+目标项目可以生成一份短生命、可脱敏、机器可读的 Evidence Bundle，但只有人类可决定是否将它带回中心产品项目。
+
+建议字段：
+
+```json
+{
+  "schemaVersion": 1,
+  "kind": "target-project-evidence",
+  "productVersion": "1.3.1",
+  "capability": "setup | takeover | maintenance | staged-context | upgrade",
+  "environment": {
+    "runtime": "node",
+    "packageManager": "redacted-or-declared",
+    "projectShape": "single | monorepo | multi-context"
+  },
+  "expected": "stable protocol expectation",
+  "observed": "minimal reproducible observation",
+  "result": "passed | degraded | blocked | failed",
+  "errorCodes": [],
+  "reproduction": [],
+  "artifactDigests": [],
+  "redactions": [],
+  "humanNotes": []
+}
+```
+
+默认不包含：
+
+- Project Contract 正文；
+- source body、业务代码、diff 全文；
+- 仓库 URL、内网地址、token 或个人信息；
+- 聊天推理、自动上传地址或下一版本承诺。
+
+### 10.3 中心分析闭环
+
+```text
+多个目标项目产生证据
+→ 人工检查、脱敏和转交
+→ 中心项目按能力/版本/错误码聚类
+→ 复现是否违反已定不变量
+→ 分类为内核缺陷 / 产品演进 / 项目数据 / 适配器 / 外部工具
+→ 人选择产品方向
+→ 设计、验收、发布正式版本
+→ 目标项目按升级协议消费
+```
+
+多个项目重复出现只会提高证据优先级，不能绕过产品宪法的需求分类和人工决策。
+
+## 11. 目标项目升级协议
+
+### 11.1 原则
+
+> 人授权目标版本，AI 执行闭环，机器清单定义迁移，未知或冲突失败封闭，完成后恢复 healthy。
+
+核心工具不自动联网查询 `latest`，也不执行包管理器。新版本来源由人、企业依赖策略或获得外部权限的 Host Agent 提供。目标项目应 pin 精确版本并更新 lockfile，不依赖浮动 `latest`。
+
+### 11.2 两阶段升级
+
+旧 CLI 不可能理解尚未发布的新迁移，因此升级必须分两段：
+
+#### A. 旧版本基线
+
+1. 用当前 pin 版本运行 sync/check。
+2. 如果存在 drift、pending、ownership conflict 或 partial，默认先恢复旧版本健康。
+3. 记录包版本、store/schema/renderer 版本、文件 digest 和进行中的短期任务。
+4. 记录由项目 Git/备份提供的可恢复点；产品本身不执行 Git。
+
+#### B. 新版本迁移
+
+1. 人明确授权目标版本、依赖/lockfile 修改及必要联网。
+2. Host Agent 用项目现有包管理器更新依赖。
+3. 新 CLI 读取旧 store，只读产生 Upgrade Assessment/Migration Plan。
+4. 机械可逆、范围已明确的修改可在已授权升级任务内由 AI 执行；语义、冲突和不可逆修改必须再由人确认。
+5. 执行原子迁移，然后显式 republish AI 入口和其他受管 projection。
+6. 运行 sync/check、项目自身测试/CI 和独立新窗口接管验证。
+7. 产生 Upgrade Result Bundle，清理迁移计划和短期工件，回到 healthy。
+
+### 11.3 机器可读升级清单
+
+`UPGRADING.md` 继续作为人类文档，但不再是 AI 执行迁移的唯一依据。每个正式版本应随包携带经验收的 machine-readable migration manifest，至少声明：
+
+```json
+{
+  "schemaVersion": 1,
+  "release": "1.4.0",
+  "upgradeFrom": [">=1.2.0 <1.4.0"],
+  "readableStores": {
+    "contract": [1, 2],
+    "sourcesLock": [1],
+    "projectionsLock": [1]
+  },
+  "writes": [],
+  "projectionRenderers": { "readable": [1, 2, 3], "target": 4 },
+  "consumerChanges": [],
+  "protocolCompatibility": [],
+  "rollbackClass": "package-only | reversible-data | forward-only",
+  "requiresHumanReview": false,
+  "acceptance": []
+}
+```
+
+发布包必须保证：
+
+- 清单与运行时验证一致；
+- 每个声称可读的旧 store 都有 fixture 验收；
+- 每个写迁移都有 old → new、并发基线、中途失败和重跑验收；
+- 协议参数变化明确列入 consumer changes；
+- 降级不可行时明确声明 forward-only；
+- 不支持的跨版本路径在写入前失败封闭。
+
+### 11.4 升级命令边界
+
+后续可设计三个概念能力，命令名和 schema 版本需在实现文档中另行冻结：
+
+- `upgrade check`：只读，输出当前/目标版本、schema、入口所有权、阻断、迁移和回滚等级。
+- `upgrade plan`：只读，生成短生命 Migration Plan，精确列出 path、before digest、action、semantic impact 和 acceptance。
+- `upgrade apply`：只执行已展示计划中属于产品自有 store/projection 的迁移；不调包管理器、Git、网络、项目测试或业务发布。
+
+### 11.5 升级场景决策
+
+| 场景 | 默认决策 |
+| --- | --- |
+| 已初始化且 healthy | 正常生成升级计划 |
+| 存在 pending/drift/stale | 先恢复旧版本 healthy；除非 manifest 明确该升级专门修复此格式问题 |
+| partial/invalid store | 禁止迁移，不猜测修复 |
+| 人工 `AGENTS.md` 无受管区域 | 先生成接入方案，不覆盖 |
+| 旧受管 renderer | 所有权健康时显式 republish |
+| 受管区域被人改动 | 报告 ownership conflict，人决定保留还是重建 |
+| 分阶段任务进行中 | 默认先关闭/终止任务；协议不兼容时重生成 plan/receipt/bundle |
+| 多 worktree/多分支 | 只选一个基准分支升级；其他通过外部 Git 合并，禁止并发迁移 |
+| monorepo/多 context | 根依赖版本统一管理，每个 context 独立检查和迁移，根 AI Entry 负责路由 |
+
+### 11.6 升级类型
+
+| 类型 | 要求 |
+| --- | --- |
+| patch/runtime/docs | 通常无 store 迁移，仍需版本、check 和新窗口验证 |
+| additive capability | 旧行为默认保持，新能力是否采用另行决定 |
+| renderer/entry | 只重生成仍由工具拥有的受管区域 |
+| store schema | 必须提供读取兼容、原子迁移、恢复等级和 fixture |
+| protocol/consumer | 明确宿主参数或工件的不兼容点；旧短期工件可能必须废弃 |
+| semantic/major | 必须人工审查，不能通过升级自动改写 Project Contract 意义 |
+| security | 可以加速选择和执行，但不取消精确写入范围与最终健康验收 |
+
+### 11.7 回滚
+
+依赖回滚和数据回滚必须分开：
+
+- 如新版本没有写 store/projection，且旧 reader 仍兼容，可回滚包与 lockfile。
+- 如已写入旧 reader 不能理解的 schema，只回滚 package.json 不等于恢复数据。
+- 只有 manifest 明确提供 reverse migration 时才能自动数据降级。
+- 迁移必须使用 before digest/CAS；如迁移后文件又被人或其他窗口改动，禁止用旧快照覆盖。
+- 失败时保留可解释的中间状态，不删除无法确认归属的文件。
+
+## 12. 升级完成条件
+
+仅当以下条件全部成立，AI 才能声称升级完成：
+
+1. `package.json` 与 lockfile 指向同一目标版本；
+2. capabilities/status 报告新版本与可读 schema；
+3. 三份 store 完整且没有待执行迁移；
+4. AI Entry/projection renderer 当前且 ownership 健康；
+5. sync/check 通过，pending/workUnits/findings 已结算；
+6. 项目自身必要测试或 CI 通过；
+7. Migration Plan、Review Bundle 等短期产物不再污染正常工作上下文；
+8. 一个独立、没有继承旧对话的 AI 窗口可以识别项目、读取正确入口并得到同样的 healthy 结论。
+
+Upgrade Result Bundle 可以记录 before/after 版本、schema、renderer、迁移 ID、健康结果和新窗口结果，但它仍不是 Project Contract。
+
+## 13. AI 操作手册
+
+### 13.1 新窗口
+
+```text
+1. 读取当前目录生效的 AI Entry/AGENTS。
+2. 查询工具和项目状态，不猜测是否已 init。
+3. partial 立即停止写入；用外部项目证据准备恢复方案。
+4. uninitialized 运行 setup preview；已初始化运行 sync/check。
+5. healthy 后才进入用户需求；紧急修复可以由人显式允许带阻断进入。
+```
+
+### 13.2 日常需求
+
+```text
+1. 用 Context/Stage Bundle 只读当前任务所需内容。
+2. 不用聊天历史替代 Project Contract 或代码当前事实。
+3. 宿主负责代码、Git、测试和 CI；核心工具只管上下文协议。
+4. 任务后只提请真正持久的知识候选。
+5. 完成已授权维护并运行 sync/check。
+6. 清理短期工件，报告完成或精确阻断。
+```
+
+### 13.3 升级
+
+```text
+1. 在旧版本下取得 healthy baseline。
+2. 获取人对目标版本、依赖/lockfile 和必要网络权限的授权。
+3. 更新精确版本，不永久依赖 latest。
+4. 用新 CLI 只读生成升级计划。
+5. 将语义、不可逆、冲突与超出既授权范围的项目集中交给人。
+6. 执行迁移和受管 republish。
+7. 验证工具健康、项目测试和独立新窗口。
+8. 产生可选证据包并清理现场。
+```
+
+### 13.4 AI 注意点
+
+- 不因为用户说“交给 AI”就自行批准长期规则。
+- 不在 partial 或 ownership conflict 上尝试“先跑起来再说”。
+- 不把新能力出现解读为目标项目已选择采用。
+- 不把 receipt、plan、bundle、review 或 evidence 解读为 approval。
+- 不读取全仓库来代替 `readTargets` 和作用域编译。
+- 不通过自动接受来源 digest 来让 check 表面变绿。
+- 不在没有回滚等级和 before digest 时写迁移。
+- 不用包降级冒充数据回滚。
+- 不把临时审核状态留给下一个 AI 窗口。
+- 对外报告“完成”前，必须重读当前状态而不是依赖旧计划。
+
+## 14. 分期实施路线
+
+本文是总体设计基线，不将所有内容塞入一个版本。推荐以下顺序：
+
+### Phase A — AI Takeover & Health Closure
+
+目标：先解决“安装了但新 AI 不知道怎么开始”的最短主链。
+
+状态：已按 [20-PHASE-A-AI-TAKEOVER-AND-HEALTH-CLOSURE-DESIGN.md](./20-PHASE-A-AI-TAKEOVER-AND-HEALTH-CLOSURE-DESIGN.md) 完成本地实现与 96/96 验收，未发布、未做真实 Host 验证。
+
+- 统一 Project Status 机器输出；
+- absent/uninitialized/partial/attention/healthy 分类；
+- AI Entry 受管投影与已有 `AGENTS.md` 共存；
+- setup 后 Host Agent 协作流程；
+- 收尾健康验收和新窗口 fixture。
+- 为受管区域所有权提供 projection lock 的延迟兼容迁移，并随包发布最小机器迁移清单；完整升级编排仍属于 Phase C。
+
+本阶段不迁移 Contract、source lock 或 proposal，也不新增 Agent Runtime；仅当首次写入区域型 AI Entry 时，projection lock 才从 schema 1 延迟升级到 schema 2。
+
+### Phase B — Evidence Feedback Protocol
+
+目标：使目标项目的真实问题能被安全、可复现地带回产品项目。
+
+状态：`1.5.0` 已按 [21-PHASE-B-EVIDENCE-FEEDBACK-PROTOCOL-DESIGN.md](./21-PHASE-B-EVIDENCE-FEEDBACK-PROTOCOL-DESIGN.md) 完成本地实现并通过 106/106；真实项目验证与发布未授权。
+
+- Evidence Bundle schema；
+- 脱敏和禁止字段；
+- 人工导出/转交边界；
+- 中心聚类与需求分类模板；
+- 证据不自动成为 Contract 或产品需求的验收。
+
+### Phase C — Target Upgrade Protocol
+
+目标：把目标项目从旧版本安全、可解释地带到新版本并回到 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 复验授权；真实目标项目升级仍不在本次范围。
+
+- migration manifest schema 和包内发布义务；
+- upgrade check/plan/apply 详细合同；
+- AI Entry/renderer/store/protocol 兼容矩阵；
+- old → new、partial、并发、失败、重跑、回滚验收；
+- monorepo、worktree 和进行中 staged task 边界；
+- 升级后独立新窗口验收。
+
+### Phase D — Operations Manual & Optional Adapters
+
+目标：为 Codex、Claude 等 Host Agent 提供很薄的触发指导，并为团队提供面向人的操作手册。
+
+- 通用 AGENTS 入口模板；
+- 宿主特定适配器，只负责调用公开协议；
+- 首次接管、日常需求、知识维护、升级和故障恢复手册；
+- 可选 CI 只读健康检查，不引入 scheduler、自动批准或自动修复。
+
+## 15. 后续实现设计必须冻结的问题
+
+本总体文档已确定产品边界和顺序，但下列细节必须在每个 Phase 实现前分别冻结：
+
+1. Project Status 是扩展 `capabilities`、聚合 `setup/sync`，还是新增只读命令；
+2. AI Entry 是现有 projection target 的 renderer 4，还是新的通用受管区域类型；
+3. 已有根 `AGENTS.md` 的区域插入、定位、字节级所有权和恢复合同；
+4. healthy 是否需要独立 schema，以及如何表达“工具健康但宿主项目测试未执行”；
+5. Evidence Bundle 中的路径、文本和环境字段如何默认脱敏；
+6. migration manifest 的 SemVer range、多步迁移选路、签名/包完整性和反向迁移表达；
+7. 是否支持 N-1/N-2，还是对每个版本明示可读范围；
+8. Upgrade Result Bundle 与 Evidence Bundle 是共用 schema 还是分开；
+9. “独立新窗口”在自动 fixture 中如何证明未继承上一窗口上下文；
+10. 各 Phase 的精确 schema、错误码、CLI 参数、文件列表和编号验收用例。
+
+## 16. 验收总则
+
+后续任何 Phase 都必须证明：
+
+1. 未知、partial、baseline 过期和 ownership conflict 仍失败封闭；
+2. 无人授权不产生 Project Contract 批准或不可逆持久写入；
+3. 新窗口只凭项目文件和公开协议就能接管，不依赖历史聊天；
+4. 日常无变更时不要求人工处理真源；
+5. 任务和升级完成后能回到一个确定、可检查的 healthy 状态；
+6. Evidence/Plan/Receipt/Review/Upgrade Result 均不成为第二真源；
+7. 不内置 Provider、Agent Runtime、Git、网络、包安装、业务任务执行或外部上传；
+8. 现有 A-01 至 A-76、B0、CLI、schema 和发布工件回归保持通过；
+9. 包内人类文档、机器清单和运行时验证不得相互漂移；
+10. 所有真实目标项目证据仍需预先声明可证伪假设，不自动转换成内核开发需求。
+
+## 17. 明确不做
+
+- 不创建能够自行规划和执行任务的 Project Context Agent。
+- 不自动初始化一个含义不明的 partial 项目。
+- 不覆盖完整的现有 `AGENTS.md`、`CLAUDE.md` 或其他人工入口。
+- 不把“用户不操作 CLI”误解为“人不再拥有长期真源决定权”。
+- 不在每个任务后固定产生新知识、审核队列或总结文档。
+- 不自动从目标项目回传数据，不内建遥测服务或中心控制面。
+- 不允许目标项目 AI 修改已安装包来“就地进化”。
+- 不在核心中调用 npm/pnpm/yarn、Git、CI、Provider 或项目测试。
+- 不将 `UPGRADING.md` 的自然语言解读作为唯一迁移实现。
+- 不在没有反向迁移时声称可以通过回滚 lockfile 恢复数据。
+
+## 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。到此仍应停止，不得自动：
+
+- 修改产品代码、CLI 或 schema；
+- 修改产品宪法；
+- 访问真实目标项目或安装新版本；
+- 创建 Git 分支、提交、tag、push 或发布 npm；
+- 把 Phase A、B、C 或 D 的顺序解读为实现授权。
+
+用户于 `2026-09-11` 进一步授权 `1.6.0` 发布候选整理、Git commit/tag/push、公开 npm 发布与 registry 独立复验。当前唯一下一步是完成该有界发布流程；Phase D 其余适配器和真实目标项目验收仍未授权。