diff --git a/AGENTS.md b/AGENTS.md index 1047ba2..d79d98b 100644 --- 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 index fe9f315..d99c029 100644 --- 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 index 23669a1..9f96664 100644 --- 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 `）。试行 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 index 6123ffe..5dc38c8 100644 --- 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)）。本文只保留落到本仓库的部分；报告中面向大团队的做法按单人项目裁剪。 diff --git a/docs/review/2026-09-29-harness-status.md b/docs/review/2026-09-29-harness-status.md new file mode 100644 index 0000000..a5b8ef2 --- /dev/null +++ b/docs/review/2026-09-29-harness-status.md @@ -0,0 +1,111 @@ +# harness 现状复核与下一阶段（2026-09-29） + +审查基线：main `b2e4fa8`（PR #64 合并后）。标尺：[调研报告](../research/2026-09-23-agent-delivery-theory.md)的八条原则（3.2）、五级成熟度（16.2）与落地检查清单（17.2）；[目标态设计](https://claude.ai/code/artifact/a7646759-f838-49a8-aa1a-175b329ea1ed)第四至第十五节的设计项与第十六节路线；[2026-09-27 全链路审计](2026-09-27-harness-audit.md)的差距编号。各能力的证据以 [delivery-harness 规范](../specs/delivery-harness.md) §6 为准，本文不重复「已通过」的结论。 + +## 结论 + +- **目标态设计的阶段一（P1–P3）与阶段二（P4–P8）全部落地**（PR #49–#64），审计的 G1–G13、C1–C3 均已处理；C4（执行方同时具备不可信输入、敏感访问、改变状态三项）只部分缓解，C5（发版后观察）未做。 +- **成熟度：M1 完整，M2 的机制基本建齐，但 M2 的准入数据还没有。** 报告要求进入 M2 前有 20–50 个真实任务组成的评测集、目标类别 pass^k 达标、逃逸在预算内、能一键回滚；目前真实派发只有 1 个任务（T005），评测集为 0，误差预算的统计从 #50 起算，样本很少，发版回退未演练。 +- **下一阶段是设计中的阶段三「放权」**：以真实使用为主线，用派发真实任务产生数据，同时补齐评测集、实测降级与停机、首次发版演练；数据达标后按类别做放权决定。本次复核另发现 8 处与设计的出入，登记为待办 B34–B41（见文末）。 + +## 一、对照报告的八条原则 + +| 原则 | 落点 | 判断 | +|---|---|---| +| 1 先有判定器，再放权 | `bin/verify` 与 CI 同口径；任务书准入（`taskbook.py`）；验收挂规格编号；R0 与业务任务书、补测试自动合并，其余人审 | ✅ | +| 2 确定性优先 | 风险判级、合并路由、派发的九个步骤、运行记录复核、周报都是脚本；Agent 只在实现、修复与评审三处工作 | ✅ | +| 3 生成与验证分离 | 执行方在槽位里实现，判定在执行方进程之外与 CI 中重跑；独立评审由非设计方、只读、只看材料 | ✅ 结构已有；独立评审试行 1/3 | +| 4 结构防护胜过提示词 | 三层守卫；执行方对判定器、合同、运行记录、议题只读；守卫从 origin/main 加载；执行方与评审方无 GitHub 凭据；评审方只读锁定 | ✅；残余见 C4 | +| 5 小批量、可回滚 | 一个任务一个 PR；400 行阈值；严格必过检查；revert 回滚 | ✅ 代码；发版回退未演练 | +| 6 状态外置、上下文从简 | 任务书、运行记录、待办、周报议题；AGENTS.md 51 行 | ✅ | +| 7 自治按类别 × 风险，数据驱动 | `autonomy.toml` 的类别自治等级、误差预算自动停该类、K3 三抽一 | ⚠️ 机制在，数据刚开始积累 | +| 8 失败沉淀为 harness 改进 | 缺陷编号、回放强制、周报突增、每周错误分析流程；本轮 #62 评审暴露的工具缺陷已修复并加测试 | ⚠️ 首次每周错误分析未做 | + +## 二、对照报告的落地检查清单（17.2） + +| 类别 | 条目 | 状态 | 说明 | +|---|---|---|---| +| 规格与上下文 | 可执行验收与非目标 | ✅ | 任务书合同与准入 | +| | 按可验证性 × 风险分诊，模糊先澄清 | ✅ | 类别 × 风险；执行方写澄清升级包 | +| | AGENTS.md 约 100 行只做地图 | ⚠️ | 51 行；设计要求的「超过 100 行即失败」未加进 `docs_check.py`（B34） | +| | 一条命令构建测试 | ✅ | `bin/verify` | +| 执行 | 隔离环境，文件系统与网络受限 | ⚠️ | 固定槽位 worktree 是工作隔离，不是安全隔离；网络与文件系统未受限（B31） | +| | 凭证不进沙箱 | ⚠️ | 执行方与评审方环境里没有 GitHub 令牌、gh 与 git 凭据；同一 macOS 用户仍能读用户文件（B10、B31）；Pi 仍加载用户级扩展（B35） | +| | 时长、token、重试、CI 轮次预算 | ⚠️ | 时长、重试、CI 轮次由派发执行、CI 复核；token 只记录不设限（按决定 8） | +| | 长任务进度文件与逐步提交 | ✅ | 任务在一次运行内完成，逐步提交；运行记录 | +| 验证 | 测试、CI、lint 对实现只读 | ✅ | 守卫；已有测试按 base 版本重跑 | +| | 最终验收在 Agent 之外重跑 | ✅ | 派发本地判定 + CI | +| | 独立上下文 AI 评审并经人工校准 | ⚠️ | 工具与校准集已有；校准数据是 Pi 版本、评审提示词改动之前的，与现用 OpenCode 不同；试行 1/3 | +| | 变异或性质测试 | ✅ | 6 组变异只升不降；性质测试；41 个回放 | +| | 改测试、CI、依赖、公共 API 自动升级 | ✅ | 风险路由 R2/R3 | +| 发布与运行 | PR 小而短命，主干常绿 | ✅ | 严格模式、400 行 | +| | 按风险分级发布、自动回滚或特性开关 | ❌ | 桌面 App 尚未正式发版；B2、B19 | +| | 开发与生产隔离，备份恢复演练 | — | 本机 App，无生产服务；数据在 `~/.local/state`，恢复步骤随 B19 一并写 | +| | 每次运行完整轨迹，记录模型、提示词、工具版本 | ✅ | 运行记录入库，完整事件流留本机；本机轨迹保留期未实现（B40） | +| | 紧急停机与误差预算降级 | ⚠️ | 已建；停机未演练（B23），降级未被真实事件触发 | +| | 换模型或改提示词前先跑回归评测 | ❌ | 执行方评测集未建（P9）；评审方有校准集 | +| 改进与人 | 每周错误分析，事故转回归用例 | ⚠️ | 周报每周自动生成；错误分析流程已写，第一次未做；事故转回放已强制 | +| | 教训优先沉淀为自动检查 | ✅ | 本轮新增的检查都有测试 | +| | 定期熵治理任务，监控复杂度趋势 | ⚠️ | Python 与 Swift 棘轮、文档检查已有；按热点生成清理任务的月度节奏未开始（B39） | +| | 人审按风险路由，升级包含证据与选项 | ✅ | 合并路由；派发的升级包 | +| | 度量升级精度与处理时长 | ⚠️ | 周报已有该项，尚无样本 | +| | 技能保持安排 | ⚠️ | 设计为每月读 2 条执行方轨迹、季度停机演练，未排期 | + +## 三、对照成熟度（16.2） + +| 级别 | 本项目 | +|---|---| +| M1 受监督执行 | ✅ 沙箱（工作隔离）中完成任务、统一 verify 入口、AGENTS.md；R2 以上人审 | +| M2 门禁自治 | 机制基本建齐：分层门禁、防篡改、独立评审（试行）、低风险类别自动合并加抽样审计、有界重试与升级。**准入条件未满足**：评测集 0 个（要求 20–50）、pass^k 无数据、逃逸预算样本少、回滚未演练 | +| M3 闭环自治 | 未开始：后台维护 Agent、渐进发布与自动回滚、停机演练、安全红队测试（本项目以注入回放在后台配置下全拦代替）、执行方单独系统用户（B31） | + +设计的 90 天目标是 M2（K1、K2 以数据站稳 L4，K3 按规则完成一次升级或明确不升），不进入 L5。 + +## 四、对照目标态设计各节 + +| 节 | 设计项 | 状态 | +|---|---|---| +| 四 需求与规格 | 任务书头部与准入、按类别审、执行方只读合同、验收挂编号、计划并入任务书、历史任务补头部 | ✅ P1；另按用户决定，设计方自行实现的工作也写任务书（方案 B） | +| 五 上下文与知识 | 文档断链检查；AGENTS.md ≤ 100 行检查；待办「进行中」须有分支名；执行方回报缺失的上下文或工具 | ⚠️ 断链与陈旧状态已有（P8）；后三项未做（B34、B36） | +| 六 规划与派发 | 派发九步、认领、槽位、提示词入库、`dispatch review` | ✅ P4、P7；评测模式 `--eval --repeat` 未做（P9） | +| 七 执行环境 | 固定槽位、无凭据、时长与卡死与打转与 CI 预算、停机 | ✅ P4；守卫从 main 加载（用户确认的方案 B）；用户级扩展仍加载（B35） | +| 八 验证与门禁 | 回放强制、R1 加强判定、Swift 棘轮、独立评审与校准、有界重试 | ✅ P2、P3、P7、P8；评审否决后「执行方修复一轮」未接入派发（B37）；留出判定随评测集（P9） | +| 九 集成与发布 | 合并路由（风险、类别、预算、规模、运行记录）、严格模式、类别标签、抽审 | ✅ P2、P5；首次发版与重发上一版未演练（B2、B19） | +| 十 运行与观察 | 运行记录、停机、周报突增告警、发版后观察 | ⚠️ 运行记录、停机步骤、突增已有；运行记录的违禁内容检查未做（B38）；发版后观察未做；用本 App 采集执行方用量核对运行记录（可选）未做（B41） | +| 十一 反馈与改进 | 周报、试跑记录汇总、评测集与 pass^k、逃逸转评测任务、月度清理、季度重审 | ⚠️ 周报与汇总已有（P6）；评测集与逃逸转评测任务（P9）、月度清理（B39）、季度重审未开始 | +| 十二 安全 | 三者取二、密钥扫描、最小权限、破坏性动作硬拦截、凭据隔离 | ⚠️ 密钥扫描与严格模式已开；凭据隔离暂缓（B31，须跨平台） | +| 十三 人的角色与升级 | 升级触发器、升级包、escalation 标签与精度、注意力预算、技能保持 | ⚠️ 触发器与升级包、标签已有；「独立评审否决转执行方修复」（B37）与技能保持安排未做 | +| 十四 度量与误差预算 | 14.1 指标、北极星、误差预算、周报 | ✅ 周报含全部指标；多项「样本不足」 | +| 十五 自治等级 | 类别、`autonomy.toml`、升级人定、降级自动、抽审 | ✅ 机制；放权决策点未到 | + +## 五、下一阶段：阶段三「放权」（数据驱动，约 4–6 周） + +按依赖排序。每项只写做什么与完成标准，细节在对应待办或任务书中。 + +| 顺序 | 项 | 完成标准 | 负责 | +|---|---|---|---| +| 1 | **开始真实使用**：选 2–3 个高可验证、低风险的类别（K2 补测试、K4 有复现的缺陷修复，其次 K5 小功能），每周派发若干真实任务，一次一两个 | 每个任务都有运行记录、合并路由判定与（R2 以上）独立评审；周报开始有样本 | 设计方写任务书与派发，用户按类别审 | +| 2 | **本机后台评审常驻**：`bin/dispatch review --watch`；完成独立评审试行 2/3、3/3，由用户决定是否常态化（B27） | 3 个 R2 以上 PR 有评审结论并与用户判断对照 | 用户开常驻，设计方汇总 | +| 3 | **第一次每周错误分析**（2026-10-05 周报后） | `docs/review/weekly/2026-W41.md` 入库，沉淀项进待办 | 非本周主要设计方的评审方 | +| 4 | **停机演练**（B23） | 规范 §6 记录演练结果；无人值守派发之前必须完成 | 用户 | +| 5 | **P9 评测集**：≥ 20 个真实任务（历史缺陷修复与补测试），base_sha 与留出判定，`bin/dispatch --eval --repeat 3` | 每个任务在 base_sha 上判定失败、在原始修复上判定通过；pass^3 按类别进周报 | 设计方 | +| 6 | **P10 实测误差预算降级**：登记一个测试用逃逸，确认该类下一个 PR 转用户，关闭议题后仍计数 | 规范 §6 记录实测 | 设计方执行，用户确认 | +| 7 | **首次发版演练**（B2、B19）：自用先行、发布审批实测、重发上一版的书面步骤、14 天观察 | 发版记录与观察记录入库 | 用户定版本号并审批 | +| 8 | **放权决策点**：K2 维持 L4（有数据）；K3 是否升级（满 10 个抽审）；独立评审是否常态化 | 每项决定附周报证据 | 用户 | + +并行的小修（R3，按主题合成少量 PR）：B34–B41。 + +阶段三之后（进入 M3 或长时间无人值守之前）：执行方凭据与系统隔离（B31、B10，须跨 Windows、Linux、macOS 评估）；护栏指标连续 4 周达标；注入类回放在后台配置下全部被拦。 + +## 六、本次复核新登记的待办 + +| 编号 | 事项 | 来源 | +|---|---|---| +| B34 | `docs_check.py` 补两项：AGENTS.md 超过 100 行即失败；待办清单中写「进行中」的条目必须写分支名 | 设计第五节 | +| B35 | 派发 Pi 时改用 `--no-extensions` 再显式加载守卫：现在 `-na` 只忽略槽位中的项目文件，用户级扩展（`~/.pi/agent/extensions/` 下 4 个）仍会加载，执行环境不完全受控 | 本次复核 | +| B36 | 派发提示词要求执行方结束时报告「缺失的上下文或工具」，写进运行记录 `missing_context`，周报汇总，同类出现两次以上沉淀 | 设计第五节、10.1 | +| B37 | 独立评审结论为「不通过」时，派发的任务 PR 由执行方带评审发现修复一轮，仍不通过转用户 | 设计 13.2 | +| B38 | 运行记录内容检查：拒绝含命令全文、本机路径、会话正文的记录（`run_check.py`） | 设计 10.5 的机器验收 | +| B39 | 月度熵治理：按周报的复杂度热点生成 K3 行为不变重构任务并派发 | 设计 11.5 | +| B40 | 本机完整事件流（git 公共目录下 `dispatch/runs/`）保留 30 天后清理 | 设计 10.1 | +| B41 | 用本 App 采集的执行方用量核对运行记录的 token 与费用，偏差 10% 以内即采用（可选） | 设计 10.1 | diff --git a/docs/specs/delivery-harness.md b/docs/specs/delivery-harness.md index 3efb26e..397c54d 100644 --- a/docs/specs/delivery-harness.md +++ b/docs/specs/delivery-harness.md @@ -1,6 +1,6 @@ # 可验证交付 harness -状态：现役（2026-09-25 起）。方案与阶段见 [可验证交付方案](../plans/verifiable-delivery.md)，基线见 [2026-09-25 基线评审](../review/2026-09-25-harness-baseline.md)。 +状态：现役（2026-09-25 起）。目标态与分阶段路线见[目标态设计](https://claude.ai/code/artifact/a7646759-f838-49a8-aa1a-175b329ea1ed)，当前进展与下一阶段见 [2026-09-29 现状复核](../review/2026-09-29-harness-status.md)；基线见 [2026-09-25 基线评审](../review/2026-09-25-harness-baseline.md)。早期的[可验证交付方案](../plans/verifiable-delivery.md)为历史文档，只保留 §10 决定记录与 §13 已完成事项。 harness 只依赖 Python 标准库，放在仓库顶层 `harness/`，不进发布包（构建只拷 `scripts/` 与 `bin/session-manager`）。改动 `harness/`、`.githooks/`、`.github/`、`.claude/`、`.opencode/`、`.pi/`、`.zcode/` 属于 R3，必须由用户批准。 diff --git a/harness/README.md b/harness/README.md index da9cf67..91c11ad 100644 --- a/harness/README.md +++ b/harness/README.md @@ -16,7 +16,8 @@ - 调研报告《低人工干预下 AI Agent 持续高质量交付：理论与全链路最佳实践》（2026-09-23）：入库快照 [docs/research/2026-09-23-agent-delivery-theory.md](../docs/research/2026-09-23-agent-delivery-theory.md)，编辑源为 [Claude 文档](https://claude.ai/code/artifact/487213ef-a1a8-44fd-9399-2e37f91c8b0c)。先读它的「核心结论」和「3.2 八条设计原则」。 - 开工时的落地计划：[2026-09-25 落地交接说明](../docs/plans/2026-09-25-harness-rollout-handoff.md)（原为报告最后一节：基线、失败分类、可验证性地图、P0–P6 路线），历史文档。 -- 目标态设计：[Agent-Notification 可验证交付 Harness 目标态设计](https://claude.ai/code/artifact/a7646759-f838-49a8-aa1a-175b329ea1ed)（2026-09-27，第十七节为 2026-09-28 的决定；第十六节为分阶段实施路线，阶段一 P1 合同、P2 合并路由、P3 回放强制与守卫小修已落地）。 +- 目标态设计：[Agent-Notification 可验证交付 Harness 目标态设计](https://claude.ai/code/artifact/a7646759-f838-49a8-aa1a-175b329ea1ed)（2026-09-27，第十七节为 2026-09-28 的决定，第十六节为分阶段实施路线）。 +- **现状（2026-09-29）**：阶段一（P1–P3）与阶段二（P4–P8）全部落地；成熟度为 M1 完整、M2 的机制基本建齐但准入数据未满足；下一阶段是阶段三「放权」，以真实使用积累数据。对照报告与设计的逐项复核见 [2026-09-29 现状复核](../docs/review/2026-09-29-harness-status.md)。 - 落到本仓库的方案与决定：[可验证交付方案](../docs/plans/verifiable-delivery.md)（§1 目标、§2「可验证」的操作定义、§10 决定记录）。 - 本项目自己的失败样本：v0.8.0 交付中的 R1–R19 与 X1–X6，分类见 [2026-09-25 基线评审](../docs/review/2026-09-25-harness-baseline.md)。每条护栏都对应其中至少一种失败。