这个决定的背景
6 月底我把多 Agent 架构（T3R）的计划写完了：Planner 管任务真相，Coder 管局部实现，Reviewer 管证据和涟漪，协议先行，typed-event 驱动。文档很完整，拆分的理由也很充分——单 Agent 上下文有限，任务一长就开始互相污染。
然后我按下暂停键。
不是计划有问题，而是我意识到一个顺序问题：**多 Agent 的正确性建立在单 Agent 的正确性之上。**一个会"假完成"的单体，拆成三个就是三个会假完成的单体，还多了一个互相掩盖的机会。先让单体做到证据门不撒谎，再谈分工。这个决策记成了 Strong Single v1.0。
决策的输入：五个真实缺口
这个决策不是拍脑袋。对照 Anthropic 的工程建议、Claude Code 的 hooks/checkpointing 文档、DeepSeek 的文档，把当时"已经稳定"的协议层重新审查了一遍，发现五个 runtime 闭环缺口：
- HookSystem warn 丢弃——
runBefore只有blocked才返回，warn-only 的输出被静默丢弃。钩子说"小心"，系统听不见。 - writeGuard 的"未读覆盖"只 warn 不 block——安全漏洞。文件没读过就写，只是警告，不是拦截。
- Completion 路径分散——没有统一的 CompletionOrchestrator，"完成"判定散落在
loop.ts的多个位置。每个位置都有自己的判定逻辑，就没人能保证它们一致。 - PatchTransaction 只有 Phase 1——无状态机、无 apply-to-temp、无回滚。一次失败的编辑可以留下半截文件而没有任何记录。
- FIM 无安全约束——无 prefix/suffix/expectedOldContent 校验；E2E Replay 只有 30 cases，无 CI 集成，无 SWE-style benchmark。
这五条有一个共同点：它们都在"结果已发生之后"才可见。钩子警告被丢、覆盖没拦住、完成乱判——这些不修，单体就是一把漏勺。拿漏勺去拆多 Agent，只会漏得更多。
收敛的范围
v1.0 收敛到六个方向，每个方向有明确的完成证据：
1. Runtime 边界统一
bootstrap 走一条共享链路，CLI/TUI 入口全部从 runtime assembly 出发。事件边界（event-bus / controller / control-plane）统一，slash 解析共享，未知命令传给 agent，不安全本地命令在运行期被拦。事件分类学收敛成有限 9 类（lifecycle/model/tool/gate/verification/evidence/workflow/error/internal），每类有 canonical 事件表，未知类型可发现。
2. 文件状态（FreshnessGate）
文件工具全部走 contract preflight + 审批快照事务边界。fresh/partial/truncated/deleted/unread 五类目标全部 fail-close，管理写记录 agent 基线，回滚有专用 recovery policy。细节在 Harness 2.0 文章里展开，这是收敛的最大受益者——以前"读文件-改文件"是自由行为，现在是受管事务。
3. 钩子系统
HookSystem 2.0 累积警告、链式替换、fail-closed。默认工厂保持 strict，运行时 bootstrap 显式选 warn——enforcement 交给 FreshnessGate，hook 不抢戏。第一条缺口的解法不是"让 warn 生效"，而是"warn 只负责观察，拦截由更硬的机制负责"。
4. 证据与完成
CompletionOrchestrator 做最终轮真实性检查，EvidenceLedger 管证据状态。验证器身份固定（固定白名单，不能随便换验证器），提交历史指纹权威，命令级文件覆盖补齐"谁写了我"的最后一块。回滚感知失效保证撤销即证据失效。
5. 补丁事务与回滚
PatchTransaction 管审批基线、新文件缺失、非文件目标、符号链接父目录、部分冲突回滚、提交证据快照。rollback_transaction 是专用 recovery 策略。
6. 可重复验证
70 个确定性回放场景（CI core gate）、H12 脚本化 E2E 12/12、mini benchmark 持久基线（pass@1 100%，false done rate 0%）。回放不是 demo——是每次提交都要过的门禁。
明确不做的事
v1.0 的"Not In Scope"写得很直白：
- 多 Agent / T3R 拆分：先稳定单 Agent 运行时
- SkillForge / 插件市场：等 ToolPolicy、Evidence、Replay、沙箱 hard-gated 之后
- 新增 ToolContractRegistry：不要加，未来消费者用现有 ToolDef 目录的不可变投影
- 替换 TUI：复用现有 surface
这些"不做"和"做"一样重要。收敛的本质是给未来的改动划边界——边界内可以乱改，边界外暂时不许动。
Gate Control Plane：门禁如何变成体系
收敛的副产品是一套门禁体系（9 个 PR）：typecheck / core / test / build / replay / benchmark 各自独立、各自有基线。验收口径定死三件套——代码、测试、运行时接线——同时在场才算 Done。306→318 项全绿。
这条线的意义不在数量。门禁的可信度来自"能拦住什么"：replay gate 拦住行为回归，benchmark gate 拦住完成门退化（pass@1 掉下去或 false done 率升上来都直接红）。基线持久化在仓库里，每一次提交都能和基线比较。
现在的坐标
v1.0 的 PR 映射表里，Done 占了绝大多数，Partial 集中在 ToolPolicy 权限 UX、Provider 成本追踪、TUI 审批 UX 三个尾巴上——都不是拦路项。
下一步在 Graph Runtime（typed execution graph）和 LR2（execd 执行协议）上。多 Agent 并没有被放弃，只是被正确地排在了后面：先把单体做成不会撒谎的系统，再让它学会和人合作。
验收口径一句话：代码、测试、运行时接线三者同时在场才算 Done。 这是 Strong Single 留给后来所有计划线的遗产。