SnowsonZ · Sep 28, 2026 · Sep 28, 2026
diff --git a/AGENTS.md b/AGENTS.md
@@ -8,6 +8,7 @@
 - 统一验证：`bin/verify`（lint、仓库卫生、Python 测试、macOS 上的 Swift 测试，与 CI 同口径）。修复提交带 `Defect: <编号>` trailer，通过与否只认 verify 与 CI 输出，不手写。约定与护栏见 docs/specs/delivery-harness.md；harness 的愿景、理念出处与组件对照见 harness/README.md。
 - 新环境准备由 Agent 自行完成，不交给人（均幂等，可重复执行）：`scratch/iterm-probe-venv` 缺失时按 README.zh-CN.md「快速上手」重建；`scratch/iterm-probe-venv/bin/python -m pip install -r requirements-dev.txt`；`python3 harness/git_guard.py install`；最后 `bin/verify`，它会检查前两步。
 - Agent 工具的项目守卫需要人确认一次信任，Agent 不得代为授权（自授信任等于执行者给自己放行）：Agent 不得替执行方信任槽位或仓库里执行方能改的项目文件。`bin/dispatch` 派发 Pi 时用 `-na` 忽略槽位中的全部项目文件、`-e` 显式加载从 origin/main 导出的守卫，守卫来自经用户批准合并的 harness，不需要也不构成对槽位的信任（用户 2026-09-28 确认）。开工时自查，未信任就把命令交给用户：Zcode 用 `zcode hooks trust status --workspace <仓库根>` 查看，按其提示由用户 `grant`；Pi 由用户在仓库根启动 `pi` 执行 `/trust`；Claude Code 首次启动时由用户确认项目钩子；OpenCode 无需确认。未信任时 Agent 层守卫不生效，只剩 git 与服务端两层。
+- 派发与评审：执行方任务先写任务书（`docs/templates/task.md`，合并后）再用 `bin/dispatch run <任务书>` 派发，不在主目录运行执行方；设计方自己实现的工作也写任务书，与实现同一个 PR。R2 以上 PR 的独立评审用 `bin/dispatch review`（本机常驻 `--watch`）。现状与下一阶段见 docs/review/2026-09-29-harness-status.md。
 - Python 检查：`python3 -W error::ResourceWarning -m unittest discover -s tests -v`（ResourceWarning 按错误对待，与 CI 同口径）。
 - Zcode 辅助程序：`xcrun swiftc native/ZcodeFocus.swift -o build/zcode-focus`；无 UI 自检：`build/zcode-focus --self-test`。
 - 原生收件箱构建：`python3 scripts/build_inbox_app.py`；先退出正在运行的本项目 App，再覆盖可执行文件。

diff --git a/README.zh-CN.md b/README.zh-CN.md
@@ -128,7 +128,7 @@ python3 -W error::ResourceWarning -m unittest discover -s tests -v
 | [会话收件箱方案](docs/plans/session-inbox.md) | 设计方案 | 五路接入、通知抓取评估与实现路径 |
 | [系统 Terminal 备选](docs/plans/terminal-migration.md) | 设计方案 | 无额外依赖的备用终端探针（暂缓） |
 | [用量金额与桌面组件执行计划](docs/plans/usage-cost-widgets-execution.md) | 设计方案 | 工作包、里程碑评审关口与交付要求 |
-| [可验证交付 harness](docs/specs/delivery-harness.md) | 规范 | bin/verify、修复证据、风险等级、三层护栏、一次性设置与验证状态 |
+| [可验证交付 harness](docs/specs/delivery-harness.md) | 规范 | bin/verify、任务书准入、风险等级与合并路由、派发（bin/dispatch）与运行记录、独立评审、周报、三层护栏、停机与恢复、一次性设置与验证状态 |
 | [任务模板](docs/templates/task.md) | 模板 | 任务书即合同：YAML 头部（类别、风险、设计方、预算）、终态、非目标、挂规格编号的验收、步骤与提交顺序、升级包；`harness/taskbook.py` 准入。[计划模板](docs/templates/archive/plan.md)已归档（并入任务书） |
 | [评审清单](docs/templates/review-checklist.md)、[评审提示词](docs/templates/review-prompt.md) | 模板 | 由失败分类生成的评审清单与评审方工作方式，配合 `harness/review_pack.py` 证据包 |
 | [试跑任务 001：补 DR14 测试](docs/plans/trial-001-dr14.md) | 设计方案 | 可验证交付首个真实任务试跑：任务说明、预算与试跑记录表 |
@@ -150,6 +150,7 @@ python3 -W error::ResourceWarning -m unittest discover -s tests -v
 | [Zcode 状态语义排查](docs/research/2026-09-14-zcode-state-semantics.md) | 调研记录 | 等待权限状态的可达性边界 |
 | [Codex 受管理可行性论证](docs/research/2026-09-16-codex-managed-feasibility.md) | 调研记录 | notify/插件/rollout 三通道实测与暂缓决策 |
 | [各来源推送通道盘点](docs/research/2026-09-20-push-channels-per-source.md) | 调研记录 | 七家消息通道现状；codex hooks.json 全生命周期实测（含信任门禁）与 zcode 文件事件方案 |
+| [harness 现状复核](docs/review/2026-09-29-harness-status.md) | 评审记录 | 对照调研报告与目标态设计逐项复核：阶段一、二已落地，M1 完整、M2 准入数据未满足，下一阶段（阶段三放权）的顺序与完成标准 |
 | [harness 全链路审计](docs/review/2026-09-27-harness-audit.md) | 评审记录 | 8 个环节与 3 个横切面逐节点审计：现状、差距、可实现性与补齐计划（2026-09-27） |
 | [harness 评审交接](docs/review/2026-09-25-harness-review-brief.md) | 评审记录 | 交给独立评审方的范围、阅读顺序、复现命令、重点质疑与产出要求 |
 | [可验证交付基线](docs/review/2026-09-25-harness-baseline.md) | 评审记录 | v0.8.0 失败分类（R1–R19 与过程失败）、基线指标、Agent 就绪度与可验证性地图 |

diff --git a/docs/plans/backlog.md b/docs/plans/backlog.md
@@ -33,6 +33,14 @@
 | B23 | 停机演练：按规范 §8 停机 → R0 测试 PR 不被自动合并 → 恢复 → 重跑后被自动合并，结果记入规范 §6（步骤已在 P2 写入） | 进入无人值守前一次，之后每季度 | 用户演练，评审方记录 | 全链路审计 G4、1.5，设计第十七节 |
 | B27 | 独立评审试行：工具与校准集随阶段二 P7 合并；剩在 3 个 R2 PR 上试行（`bin/dispatch review <PR>`）。试行 1/3：#62（2026-09-28，OpenCode，需用户验收，4 条一般发现；首次因工具缺陷材料为空，已修复并重评），再与用户判断对照，由用户决定是否常态化 | 小；P7 合并后，随出现的 R2 PR 进行 | 评审方执行，用户决定 | 全链路审计 G5、2.4，设计 8.3 |
 | B33 | Swift 质量棘轮解析的两处已知限制（#62 独立评审发现）：协议中的计算属性声明（`var x: T { get }`）被计为函数，与规范「协议要求不算函数」的表述不一致；字符串插值内嵌字符串（`"\("x")"`）会让解析提前结束字符串、漏算同行大括号。对当前基线无影响 | 小；R3 | 评审方 | PR #62 独立评审（2026-09-28） |
+| B34 | `docs_check.py` 补两项：AGENTS.md 超过 100 行即失败；待办清单中写「进行中」的条目必须写分支名 | 小；R3 | 评审方 | 设计第五节，2026-09-29 现状复核 |
+| B35 | 派发 Pi 时改用 `--no-extensions` 再显式加载守卫：`-na` 只忽略槽位中的项目文件，用户级扩展（`~/.pi/agent/extensions/` 下 4 个）仍会加载，执行环境不完全受控 | 小；R3 | 评审方 | 2026-09-29 现状复核 |
+| B36 | 派发提示词要求执行方结束时报告「缺失的上下文或工具」，写进运行记录 `missing_context`，周报汇总，同类出现两次以上沉淀 | 小；R3 | 评审方 | 设计第五节、10.1 |
+| B37 | 独立评审结论为「不通过」时，派发的任务 PR 由执行方带评审发现修复一轮，仍不通过转用户 | 中；R3 | 评审方 | 设计 13.2 |
+| B38 | 运行记录内容检查：拒绝含命令全文、本机路径、会话正文的记录（`run_check.py`） | 小；R3 | 评审方 | 设计 10.5 的机器验收 |
+| B39 | 月度熵治理：按周报的复杂度热点生成 K3 行为不变重构任务并派发 | 小；随真实使用 | 评审方 | 设计 11.5 |
+| B40 | 本机完整事件流（git 公共目录下 `dispatch/runs/`）保留 30 天后清理 | 小；R3 | 评审方 | 设计 10.1 |
+| B41 | 用本 App 采集的执行方用量核对运行记录的 token 与费用，偏差 10% 以内即采用（可选） | 中 | 评审方 | 设计 10.1 |
 
 ## 3. 持续进行或暂缓
 

diff --git a/docs/plans/verifiable-delivery.md b/docs/plans/verifiable-delivery.md
@@ -1,6 +1,6 @@
 # 可验证交付：以本项目为标杆的全链路 harness
 
-状态：**P0–P5 完成，P6 的工具与试跑任务就绪，真实试跑待执行方执行**（2026-09-25）。基线评审见 [2026-09-25 可验证交付基线](../review/2026-09-25-harness-baseline.md)，现役规则与命令见 [可验证交付 harness](../specs/delivery-harness.md)。
+状态：**历史文档**（2026-09-29）：已由[目标态设计](https://claude.ai/code/artifact/a7646759-f838-49a8-aa1a-175b329ea1ed)取代，当前进展见 [2026-09-29 现状复核](../review/2026-09-29-harness-status.md)，未关闭事项只在[待办清单](backlog.md)。§10 决定记录与 §13 已完成事项保留作追溯。以下为原状态：**P0–P5 完成，P6 的工具与试跑任务就绪，真实试跑待执行方执行**（2026-09-25）。基线评审见 [2026-09-25 可验证交付基线](../review/2026-09-25-harness-baseline.md)，现役规则与命令见 [可验证交付 harness](../specs/delivery-harness.md)。
 
 理论来源：用户的调研报告《低人工干预下 AI Agent 持续高质量交付：理论与全链路最佳实践》（2026-09-23，Claude 文档；入库快照见 [docs/research/2026-09-23-agent-delivery-theory.md](../research/2026-09-23-agent-delivery-theory.md)，组件对照见 [harness/README.md](../../harness/README.md)）。本文只保留落到本仓库的部分；报告中面向大团队的做法按单人项目裁剪。