独立审查 C：实战代码、契约测试、权限与部署（初审）¶
审查日期：2026-10-03。结论：FAIL，修复与独立复验之前不能结束任务。
范围与方法¶
完整阅读 docs/03-usage.md、docs/labs/13-core.md、14-sdk.md、15-production.md、docs/16-troubleshooting.md、18-validation.md、19-deployment.md；完整阅读 examples 所有自行编写的 TS 源码、测试、README、package manifests、tsconfig、研究扩展、skill 与 prompt。未将 node_modules 中每个依赖文件算作人工完整审查。已读上游 AGENTS.md，不改上游与父代理负责的交付文件。
对照 pi-1.0 官方 v1.0.0 commit a13d35a742c6ef8462812a28fbe1d8c8b7431c32 的 Agent 循环、订阅等待、资源加载、trust 默认值、SDK 与 Code Mode 实现；检验版本固定的本地 npm 包实际行为。主分支已由父代理刷新到 9fba660cf1caca0ade5bea72269352416e595a19，本审查中的 API 与实验契约针对明确声明的稳定版本 1.0.0，不把 main 的功能自动当作 release 功能。
独立运行：
| 检查 | 实际结果 | 证据 |
|---|---|---|
npm run check |
通过，tsc --noEmit | reviewer-c-typescript.txt |
npm test |
15 / 15 通过，0 skipped | reviewer-c-tests.txt |
npm run demo |
三轮、两工具、七条 transcript | reviewer-c-demo.txt |
| 负控与资源哨兵探针 | 三项均复现 | reviewer-c-probes.ts、reviewer-c-probes.txt |
| 当前 Nginx 配置语法 | sudo -n /usr/sbin/nginx -t 通过 |
审查工具输出 |
上表证明命令可运行，不意味着每个测试都足够区分错误实现。下列负控明确表明“测试全通过”不能直接作内容验收通过。
C-01 · 高：SDK 研究示例仍接受仓库的 SYSTEM.md¶
位置：examples/src/sdk-agent.ts:8–20；docs/labs/14-sdk.md:7、25–35。
示例把 agentsFilesOverride 设为空、替换 append，但没有指定 systemPromptOverride。SettingsManager.inMemory 默认项目受信：上游 packages/coding-agent/src/core/settings-manager.ts:442、466–471。因此上游 resource-loader.ts:645–647、1201–1209 仍发现、读取 cwd/.pi/SYSTEM.md，将其作为替换基础 prompt 的输入。
独立探针创建临时仓库 .pi/SYSTEM.md，内容为 REVIEWER_C_UNTRUSTED_SYSTEM_SENTINEL；使用示例原始 loader 选项后，loader.getSystemPrompt() 精确返回该字符串。关闭 AGENTS 与 APPEND 并未关闭 SYSTEM 输入。与“关闭项目 context 注入”的表述及应用自控指令的示例目的不符。
修复建议：显式设置项目不受信、noContextFiles: true，并用 systemPromptOverride: () => undefined 保留 SDK 自带基础指令而覆盖发现结果。文档解释各开关不同职责。新增真实 AGENTS、SYSTEM、APPEND 哨兵测试，确保不仅配置字面存在，而是送到 provider 的上下文中没有哨兵。
注意：这不表示只读工具因此获得写能力；本问题是输入控制与文档准确性，不夸大成任意 shell 沙箱逃逸。
C-02 · 中：sequential 测试不能检出并行执行¶
位置：examples/test/contracts.test.ts:107–119；docs/labs/13-core.md:119；docs/18-validation.md:25。
两个工具 execute 都先同步记录 key，再立刻返回结果。即使运行器并行调用，它们启动顺序仍是 a、b，原断言照样通过。独立探针把 executionMode 分别设为 sequential、parallel，二者均得到 [a,b]。另外，测试只用一个 sequential 工具的两个调用，并未覆盖一个 sequential 工具使其他 parallel 工具在同批次串行。
修复建议：真实 mixed batch，至少 parallel A + sequential B + parallel C；让 A 等待一个显式 gate。gate 未释放时断言 B / C 没有开始，释放后断言开始/结束交错顺序。测试应在“取消 sequential 设置”的负控下失败，必要时使用有限超时避免错误实现挂死。
C-03 · 中：监听器测试不能检出忽略 Promise¶
位置：examples/test/contracts.test.ts:122–134；docs/labs/13-core.md:120；docs/18-validation.md:25。
监听器只 await Promise.resolve()。一次微任务有机会在 prompt Promise 完成之前自行完成；并不需要 runtime 真正 await listener。独立探针用 fire-and-forget wrapper 显式丢弃异步监听器返回值，原全部断言仍通过。
修复建议：agent_end listener 等一个宿主控制的 Promise gate。先等待进入 agent_end，然后在 gate 未释放时断言 prompt 仍未 resolved、isStreaming 仍 true；释放后再断言 idle。此测试才支持“完成屏障”说法。
C-04 · 中：store 测试名称超过实际验证范围¶
位置：examples/test/codemode.test.ts:17–25；docs/18-validation.md:25。
名称写“成功 store 写入由宿主提交，load 获得上次状态”，实际只调用一次 sandbox.execute，传入预置 {runs:2}，检查当前执行得到 3 与 storeWrites.set。没有宿主 apply delta，也没有第二次 execute。当前测试可证明 store delta 和当次 load 行为，不能证明跨执行持久状态提交。
上游确有宿主提交逻辑 packages/coding-agent/src/extensions/codemode/execute.ts:407；事实本身不假，但测试覆盖说明不准确。
修复建议：把成功 delta 提交到真实宿主对象（包括 delete），再调用 sandbox.execute 并 assert load 得到提交状态。或收窄名称和验收描述，不宣称未执行的步骤。
C-05 · 中：预算规则缺少 action:end 边界验证¶
位置：examples/src/core-agent.ts:20–24；examples/test/contracts.test.ts:137–143；docs/labs/13-core.md:88–90。
实现含八轮上限，但契约测试只验证一次 action:continue。没有在持续 toolUse 的模型脚本中证明第八轮完成后不会第九次 dispatch；用户要求严格代码审核时，应把此关键示例边界补为有意义测试，而非仅依赖类型检查。
建议使用 Faux 持续请求安全工具，在 finishTurn >=8 返回 end；验证八次 provider call、八次工具结果、正常 idle，并区分“预算停止”和“任务完成”。此项是验证不足，不声称现有上限实现错误。
C-06 · 低：120 秒定时取消不等于硬终止¶
位置：examples/src/core-agent.ts:31、sdk-agent.ts:32；docs/labs/13-core.md:88、docs/labs/14-sdk.md:72。
定时器调用 abort，依赖 provider / tools / listeners 合作处理 signal。Core await executor、SDK abort await idle；如果工具不响应取消，不能承诺整个进程在 120 秒内退出。当前窄内存笔记工具不产生此长任务风险，但教学应说明定时器代表取消请求截止。
建议补充：硬时间边界需要独立 worker/进程与外部 watchdog；超时不回滚已发生的外部动作。此处不要求课程构建额外产品，只要求避免把合作取消写成物理停止保证。
C-07 · 低：笔记助手时序图隐藏宿主输出¶
位置：docs/labs/13-core.md:23。
目前 M-->>U 把模型服务直接画到用户。实际回复先返回 Agent Core，再由宿主订阅流事件输出到 stdout。建议改成 M-->>A 最终答复，再 A-->>U 流输出 / 最终结果，使图与本章强调的 model/harness 边界一致。
已核实且未发现问题的事项¶
- 新 npm scope、provider 工厂与 Faux API 正确；tools 名称列表符合 1.0 SDK，未继续套用旧工具对象 API。
- Core / SDK 例子和离线示例实际可运行；所有第三方直接依赖固定版本，使用 ignore-scripts；tsconfig 覆盖全部自写 TS 与扩展。
- 工具只查询固定内存笔记；无任意 shell / 文件写能力；错误 id throw 由真实循环生成 toolResult isError。
- 并行 completion 与 transcript 顺序测试使用 gate，并具有实际区分能力；参数校验、beforeToolCall 拦截、length 截断、副作用不回滚、SDK canonical projection 与研究包 edit 拦截的测试均有实质断言。
- 文档正确说明 cwd 不是 OS 沙箱、project trust 不是工具权限、扩展在宿主 Node 执行、取消不回滚、真实模型质量尚未验证、多租户授权需要宿主实现。
- SessionManager 树分支测试保存真实临时 JSONL，再 open 检查当前分支；未把整个历史丢失误称成功恢复。
- 未调用真实 provider、未访问用户 API 凭据，不把 Faux 结果当作模型智能质量；docs18 对全仓逐行审核与 provider E2E 的未完成范围明确。
- 部署为现有 Nginx 的静态课程；rsync 更新保留 ACME challenge；证书、续期与源站/Cloudflare 双 TLS 链路说明准确。本审查只独立确认 Nginx 语法，不代替父代理最终网页、TLS 与下载包复验。
通过条件¶
C-01 修复并加入实际上下文隔离验证；C-02 / C-03 的负控必须失败；C-04 测试名称与跨调用提交证据一致；C-05 至 C-07 补齐边界和图示。修订后重新独立运行完整示例 check/test/demo，读最终修改与相关文档，再出带明确 PASS/FAIL 的复验报告。父代理 final 全部通过前不能把本报告写成 PASS。