运作与验证

过程也是展品 VERIFIED

普通仓库提交的是代码；这个仓库还提交了运行记录：目标账本（.omx/ultragoal/goals.json）、事件账本（ledger.jsonl）、验证对照图（docs/g002–g013）、迭代日志（progress.txt）、机器生成的知识库（AGENTS.md）、自动化边界政策（docs/anti-slop-triage.md）。它们不是给人看的摆设，而是协调系统真实运行的副产品。

一个完整的运作循环

目标账本：每个"目标"都带证据

.omx/ultragoal/goals.json 记录了 G001–G013 十三个目标。每个目标对象的结构是：id / title / objective / status / attempt / createdAt / startedAt / completedAt / evidence。关键在 evidence 字段——它不是"做完了"三个字，而是一段可回放的记录：

• 团队状态：phase=team-verify，任务 5/5 完成；
• 分工明细：worker-2 产出 issue/parity 汇总、worker-3 产出 board 渲染、worker-4 记录验证证据、worker-1 完成初始产物；
• 合并轨迹：leader 对齐提交 45b43b5；
• 验证命令：一串 python3 脚本 + cargo check 全部通过。

旁边还有追加式事件账本 ledger.jsonl（每条一行，带时间戳）和 get-goal-*.json / quality-gate-*.json 快照。这就是"可审计"的含义：谁、在何时、做了什么、凭什么算完成——全部可回放。

worker 团队：怎么分工

从 goals.json 的 evidence 里能拼出团队模型：一个 leader + 多个 worker。worker 并行产出各自工件（代码、文档、验证证据），leader 负责把它们整合、跑最终验证、对齐提交。"leader-owned"状态（如 goals.json 与 ledger.jsonl 本身）有明确的权限边界——worker 不许改账本，只有 leader 能写。这避免了"谁都能记一笔"导致的审计混乱。

验证链：从承诺到证据

• verification-map：每条主线（安全 g002、启动 g003、事件 g004、分支恢复 g005、任务/策略 g006、插件/MCP g007、Windows/发布 g009、会话卫生 g010、生态运维 g011、终局 g012……）都配一份"验证对照图"，把承诺与证据一一对应。
• 质量门命令：每个 gate 跑一整套：git diff --check、cargo fmt --all -- --check、cargo test -p <crate>、clippy、python3 -m py_compile、cargo check --workspace——全部 PASSED 才收尾。
• CI：.github/workflows/rust-ci.yml 只对 rust/、docs/ 等路径变更触发；clippy 在 CI 里比文档声明的门略弱——这种"已知缺口"被如实记录在验证 map 里。
• mock parity harness：12 个脚本化场景（streaming、read/write、权限批准/拒绝、bash、插件、多工具轮转、自动压缩、token 报告），用确定性 mock 服务跑 CLI 子进程做行为对账。
• doctor 先行：claw doctor 验证 API key、模型访问、工具配置，是"第一道体检"。

失败与恢复：策略引擎 + 恢复配方

自主系统必然会失败，所以恢复是被显式设计的：

• 恢复配方（recovery recipes）：recovery_recipes.rs 定义 7 种失败场景（构建失败、测试失败、超时、陈旧分支……）对应可执行的恢复步骤序列，并带"尝试账本"（ledger）防止无限重试；
• 策略引擎（policy engine）：policy_engine.rs 用规则（条件 And/Or/GreenAt/StaleBranch，动作 MergeToDev/RecoverOnce/Escalate）把"何时恢复、何时升级给人"写成可评估的策略；
• 陈旧分支检测：stale_branch.rs 判断分支 Fresh/Stale/Diverged，并按策略 AutoRebase/AutoMergeForward/WarnOnly/Block 处理。

一句话：它不假设 agent 不会失败，而是假设会失败，并把"失败 → 恢复 → 升级"也自动化。

自动化的边界：谁拥有"最后一道门"

最反直觉的政策在 docs/anti-slop-triage.md：自动化 lane 不得 merge 或 close 社区的 PR / issue。它们可以留账本记录、补文档模板、给出处理建议，但最终合入决定必须由人类维护者做。

政策还给出了分类清单：actionable-bug / actionable-docs / actionable-feature / duplicate / spam-or-promotion / generated-slop-or-hallucinated / unsafe-or-security-sensitive / not-reproducible-yet / externally-blocked——每个分类都有"用什么证据、做什么安全动作"。PR 评审必须回答五个问题（是否合入候选、证据是什么、跑了哪些检查、解决哪个问题、若不合入最小无害下一步）。原因很直白：防止"AI 自己维护自己的展品"变成闭环——没有人类把关，错的东西会被高速复制。

延伸学习资源（选读，不计入 40 分钟）

验证与恢复是"agent 工程"里最反直觉的部分——下面资源帮你把直觉补上：

• 📄 文章 · Karpathy：从 Vibe Coding 到 Agentic Engineering（中文解读）——"vibe coding 提高下限，agent 工程保证质量"的完整论述，是 06 页讨论的背景材料。
  cloud.tencent.com.cn/developer/article/2710146
• 📄 原则 · 12-Factor Agents——把"12-factor app"思想搬到生产级 LLM agent：可观测、可测试、可回滚等原则，与本章的"验证文化"直接呼应。
  github.com/humanlayer/12-factor-agents
• 📄 文章 · Anthropic: Building Effective Agents——重点看 evaluator-optimizer 与 reflection 两种模式：它们正是"评审 → 恢复 → 再验证"循环的抽象（与 03 页资源同源，视角不同）。
  anthropic.com/research/building-effective-agents
• 📄 对照 · 本仓库的验证实物——想亲自读账本，直接看 .omx/ultragoal/goals.json 与 docs/g002–g013 verification-map（仓库内路径）。