25 · 独立审查、修正与交付验收¶
25.1 用户要求如何落实¶
用户要求足够细致地研究代码、Markdown课程与必要图示，并在完成后独立检查超过三遍，或由多个Agent独立审查全部通过。我们采用三位审查者交叉核对其他作者的范围，并由主作者另做网站/源码引用/归档/下载重建/公网验证。
作者自己检查行号、fence或编译不算独立审查。审查者A写过02/03/05/06/07/08/13，因此独立检查B的04/09/10/11/12与主作者整合；审查者B写过后者，因此独立检查C的14–17与主作者18–20/26；审查者C写过14–17，因此独立检查A七章和主作者examples。各自只对自己实际审的范围出结论。
25.2 原报告与纠错过程¶
初审保留当时的FAIL、原文和源码证据，修正后另建复验报告，不把初审覆盖成“第一次就PASS”。关键修正包括：MCP无法确认closed时实际只log后resolve、fswrite/edit版本归属与已提交副作用、Codexhookpayload字段、present工具名、SDK官方providerfallback、实战测试覆盖不能夸大。最终问题列表与文件指纹以报告为准。首轮真实浏览器验收还发现09/16两张时序图使用保留字Loop，已将参与者ID改为Driver再逐图重验；初轮失败记录保留在公开研究附件。
25.3 交付验证的另一条证据链¶
| 检查 | 证据 | 判断对象 |
|---|---|---|
| 官方身份与版本 | version / version-recheck | repo/tag/npm/PyPI时点分开 |
| 固定源码引用 | source-citations-check | Git对象、路径、40位SHA、行界限 |
| 全文件/包覆盖 | source-inventory / package-inventory | 可追溯全仓清单，无人工全读夸称 |
| 文档构建 | mkdocs-build / course-check | strict、内部链接/anchor、必需artifact |
| 原码与归档 | artifacts-check | source reader逐行、ZIP逐字节、Pythonvendor与tag一致 |
| 下载重建 | download-packages-check | 从空目录ZIP编译、18tests、双语言demo |
| 浏览器 | browser-check | 每页真实SVG、搜索、手机导航、源码跳转、下载 |
| HTTPS与服务器 | deployment-final | public/originTLS、Nginx配置、dotfile、续期 |
| 公网下载 | public-downloads-final | 三个公网文件逐字节匹配本地SHA256 |
最终交付记录 汇总实际值。三位交叉审查者的限定范围与上述实际交付检查均通过。原始失败记录保留，最终构建、下载和浏览器记录可分别核对；ZIP保存打包时证据，在线research资产会更新到冻结后的最终复核。
25.4 通过的含义与限制¶
独立审查通过是对明确快照、明确源码范围与本次实验的检查结果，不是对整个快速变化项目或所有生产场景的形式化证明。没有真实模型付费调用、跨平台/远程/电脑/语音服务测试，也没有上游全仓全部测试；这些限制保留在正文与研究索引，不以“通过”二字抹掉。
如果之后课程更新，旧报告的文件指纹不能证明新稿；应重新审新增和变动范围、生成新的报告与revision。读者发现问题可从固定source link和原记录定位，并将其与当前远端变化分开处理。