20 · 独立复审、修订证据与最新版本差异¶
本章回答两个问题：课程中的结论是否真正对应源码；哪些行为来自当前稳定版本，哪些来自发布后的主分支。复审是重新追源码与运行探针，不是重复四次同一个构建命令。
20.1 版本快照¶
本轮于 2026-10-03（Asia/Shanghai）重新 git fetch origin --tags，将 upstream/ fast-forward 到 9fba660cf1caca0ade5bea72269352416e595a19。官方 latest release 和 npm 最新稳定包仍为 v1.0.0 / 1.0.0。课程的稳定研究源码与实验依赖仍固定 a13d35a742c6ef8462812a28fbe1d8c8b7431c32，不会把 main 当成已发布 npm 1.0 的内容。
此前下载快照是 1387af7b427c5328eba734715f61b97b0b822688；这次新增 WezTerm 图片滚动修复及审计脚本改动。main 中其余发布后变化此前已下载，但现在补充其教学影响，而不只列 diffstat。
官方稳定发布 · 本次 main 快照 · 版本核对证据
20.2 对课程有实际影响的 main 差异¶
| 主题 | v1.0.0 稳定基线 | 本次 main 快照 | 教学影响 |
|---|---|---|---|
| Code Mode 输出累计 | VM 内存、store 值、模型输出裁剪等各有边界；没有新的宿主累计输出字符/条目上限 | 新 MAX_OUTPUT_CHARS=16777216、MAX_OUTPUT_ITEMS=100000；超限使脚本失败 |
不能把后加保护写成 1.0 已保证；print 循环影响宿主内存，VM 内存上限不能覆盖它 |
| MCP 项目覆盖 | 同名完整项目 server entry 整体替换 global | 无 command/url/type 的设置型 entry 可覆写 enabled/exposure/toolExposure，保留 global 其他字段 | {enabled:false} 这种片段不能无条件用于 1.0 |
| Coding Agent MCP OAuth 配置 | 没有新的 oauth.clientRegistration 选择项 |
可选 dcr/cimd，CIMD 对 clientId/clientName 与 callbackUrl 有校验 | 指的是 CLI 配置与集成变化；底层 pi-mcp 在 1.0 已有可选 clientMetadataUrl 支持，不能说整个协议从未支持 |
| Anthropic 中途工具变更 | native 路径用工具引用，重定义同名工具会回退 current tool list | inline tool_definition，可表达同名重定义；top-level tool list 保持 initial + placeholder | 1.0 的 hasToolRedefinitions 回退仍须解释；不能用 main 编码推导 release payload |
| 依赖安装与审计 | npm 包含 shrinkwrap，实验当前发现 brace-expansion 5.0.9 high finding | 直接固定 5.0.12、删除 shrinkwrap、推荐 managed installer；根仓库审计脚本另有 node-forge advisory 的限定例外 | main 修复不自动改变已发布 1.0 npm 依赖；上游私有 gondolin 例外也不代表实验项目可忽略自己的 advisory |
| provider 模型与价格 | 稳定快照中的目录/映射 | Cloudflare Clef 分类器、Together ID、Cloudflare Claude ID、Bedrock tier 等更新 | 实际服务调用前查目录，不以旧 ID 或价格作长期保证 |
| provider 暂时错误 | 1.0 retry classifier | 新增 capacity 错误重试识别 | 不能将 main 重试覆盖推断给稳定依赖 |
| 模型选择参数 | 原 --models 行为 |
忽略空 entries | 逗号后的空值行为跟版本走 |
| 全屏终端图片 | 1.0 渲染边界 | 修复 WezTerm 滚动后的图片保留 | 终端视觉故障不能直接据 main 改动认定稳定版已修复 |
| 仓库打包 | npm / repo 现有方式 | 新 Nix flake | 分发方式变化，不修改 Core 工具循环合约 |
差异源码：输出累计限制、MCP override、OAuth 配置校验、Anthropic native 选择、审计脚本。
未列的 logo、快捷键展示和 README 修改可查完整 diffstat。表中只称“对应变化”，不声称所有 main 行都完成安全审计。主循环、SDK 工厂、SessionManager 的主要实现与这次 stable 基线一致，transcript 中部分辅助函数注释/弃用标记有变化。
20.3 三位独立审查者与第四轮最终核验¶
| 审查 | 独立范围 | 方法与证据 |
|---|---|---|
| A · 核心语义 | 02、04–07 的 Agent / loop / SDK / session projection | 完整函数上下文，独立验证 normalizeContext、branch 与 fork 语义 |
| B · 工具与集成 | 08–12 的 tools / extension / MCP / VM / RPC / Durable / Chord | 对照源码类型和运行路径，核对每张相关图与 main 差异 |
| C · 实战与验证 | 03、13–16、18–19 及所有自写 TypeScript | 独立 check/test/demo；对原弱测试做负控；真实恶意项目指令哨兵探针 |
| D · 最终交付 | 当前版本、跨章节一致性、引用、测试证据、构建与公网产物 | 源码引用对象与行号校验；修订追踪；下载包独立运行和重建；浏览器实测 |
A/B/C 是独立代理；D 是作者对修订后交付执行的第四轮核验，不把作者自查冒充第四个独立代理。构建、源码链接检查和测试是证据，不能替代 A/B 的语义审查。审查 PASS 的范围是本课程及其对应执行路径，不是“整个 Pi 仓库绝无 bug”。
20.4 初审为什么没有通过¶
初审 A、B、C 均给出 FAIL，并保留原报告。以下为修订的具体内容：
| 发现 | 修订 / 验证 |
|---|---|
| normalizeContext 被说成完整协议规范化 | 04 章解释它只 fold 兼容外置字段；补 provider adapter 节点与能力差异 |
| 图片按本次最终模型处理的说法过强 | 06 章区分历史 routedModel、_limitsModel、后来 resolveModel，增加时间线图 |
| branch 光标持久化与 fork 范围混淆 | 07 章列具体 API；真实磁盘测试未 append 重开；验证路径提取与全树 fork |
| Compaction 只有概述 | 补 token usage 失效、合法切点、split-turn、摘要失败与 checkpoint，并补图 |
| StreamFn 任意 throw 的边界没讲清 | 05 章区分底层 EventStream、await run、Agent lifecycle 与 observer 错误 |
| loop 图漏 length 拒绝 | 加整批 error results 分支及 turn_end / agent_end 终点 |
| 扩展只在 session_start 重放分支状态 | 增 session_tree 与每次工具调用按 getBranch 重算策略 |
| Core hook 改参不二次校验未说明 | 08 章画 validate → mutable hook → execute；区分 Durable 的二次验证 |
| MCP structured error 与 fulfilled 混淆 | 09 章补 result.isError 检查；说明 structuredContent 优先与 _meta 边界 |
| OAuth iss 条件与重试例外遗漏 | 09 章按源码分条件，补 session-expired 特例 |
| RPC accepted 值错误 | 改为 started / queued / handled，补真实 response 与完成等待竞态 |
| Durable 普通 isError 被误当 failed | 11 章列 completed / thrown / aborted / interrupted，补第二个崩溃窗口 |
| Storage 单 owner 前提遗漏 | 11 章明确无跨进程锁与唯一进程 owner |
| SDK 示例仍可能接受目标 SYSTEM.md | 共用研究 loader 显式来源隔离；真实 AGENTS / SYSTEM / APPEND / extension 哨兵验证到 provider messages |
| 原 sequential 测试只看同步启动顺序 | mixed batch 有真实异步完成断言，并用去掉 sequential 的负控验证能失败 |
| 原 listener 测试只有一个微任务 | 未释放 gate 时断言 prompt 未结束，负控忽略 Promise 会失败 |
| store 测试没跨 execute 提交 | 宿主显式 apply storeWrites，再次执行 load；失败脚本不提交，已发生副作用仍存在 |
| 八轮停止缺少运行验证 | 真实示例与测试共用预算；九个脚本响应只派发八次 |
| 120 秒定时 abort 被误解为硬停止 | 13/14 章明确合作取消与外部 watchdog；图中模型经 Agent/宿主输出给用户 |
20.5 怎样读复审证据¶
初审报告中的旧行号对应当时原稿；修订后用章节名、问题 ID 和固定源码定位核对。初审 FAIL 不会被覆盖成 PASS；后续报告另外保存，让读者能看到失败、修改和复验这条链。
三位独立审查者已全部完成修订复验：
| 审查 | 初审 | 修订后复验 | 原报告 |
|---|---|---|---|
| A · 核心语义 | FAIL | PASS，7 项闭环，另纠正 active branch 路径尾措辞 | 初审 / 复验 |
| B · 工具与集成 | FAIL | PASS，9 项闭环，6 张图语义核对 | 初审 / 复验 |
| C · 实战与验证 | FAIL | PASS，7 项闭环，21 项测试及 5 个错误行为负控 | 初审 / 复验 |
| D · 作者第四轮交付核验 | 公网旧 ZIP / 手机行号遮挡曾阻断通过 | PASS，修复后全站、下载包重建、浏览器实际下载均通过 | 最终报告 |
C 的五个负控是故意破坏串行、listener await、预算 hook、store commit、SYSTEM 来源隔离；目标测试均用 AssertionError 检出，排除了 import/setup 错误造成的假失败。正确版本的 21 项测试全部通过。负控失败是符合预期的证据，不是正式实验测试失败。
独立探针与日志：A 的 compaction 探针、C 负控脚本、C 负控日志。脚本在项目根目录且 examples 依赖已安装时运行；它们不是可直接在浏览器执行的 Agent 服务。
20.6 以后升级时复用这套方法¶
- 拉取官方 release / tag / main 与 npm metadata，记录获取时间和 commits。
- 将 stable 与 unreleased 分开读，复查 main 差异表。
- 检查所有 import、配置、枚举和 schema，运行与产品相同的资源加载路径。
- 对停止、取消、串行、完成屏障、授权与恢复建立能检出错误的测试；用负控确认断言有区分能力。
- 审核每张图的箭头、条件、失败分支与持久化时刻。
- 独立语义审查、引用检查、实验包运行、Markdown 重建、浏览器与公网下载验证全部通过后再发布。
这套流程不能保证未来版本不变；它能让你知道这份文档何时验证、针对什么源码，以及哪里需要重新查证。