执行交接与共享结论，各有归属
worktree 文件和 diff 承接实现，原生 handoff 承接进度、约束和下一步；Busabase 调查记录承接其他任务需要引用的主张、来源与接受状态。三者互相链接，不把整段工作上下文复制进知识库，也不让修复进度冒充原因已证实。
执行上下文
工作文件、指令和临时观测留在当前任务的执行环境。
证据引用
为具体主张保留来源、观测时间和适用范围，便于复核。
团队正式记录
以当前正式记录为入口，将审定值和未决问题交给下一任务。
WebSocket 掉线：两个原因，分别核证
在虚构调查中，A 怀疑代理空闲超时，B 怀疑事件循环阻塞。主 Agent 汇总意见不等于两个诊断都成立。分别记录主张和来源，再设计能区分二者的检查。代码修复仍走 Git diff 和 PR，知识结论另行接受。
虚构示例，用于说明记录结构，不是真实客户结果或实测。
提案记录示例
| 字段 | 示例值 | 证据／决定 |
|---|---|---|
| claim.A | proxy idle timeout | hypothesis |
| claim.B | event-loop stall | hypothesis |
| evidence | logs from matching time window needed | missing |
| accepted_record | empty until discriminating check | not accepted |
- 01A：代理超时，待验证
- 02B：事件循环阻塞，待验证
- 03区分性检查，尚未执行
- 04审定结论，审核前留空
把相反诊断交接成可执行的验证计划
WebSocket 示例中，分别保留掉线时点、代理配置和事件循环观测，再指派能区分两种假设的下一项检查。只有一个环境复现时，结论就限定在该环境。修复 PR 作为实现依据链接进来，PR 合并本身不能证明全部原因判断。
下一位 Agent 应读到什么
建议记录字段
case_id、provider、source_agent、claim、evidence、open_question、accepted_record、head
在 daemon 主机和各底层 CLI 中分别核对安装与授权；手机或浏览器客户端不是安装主机。Claude Code 切换到 Codex，不代表工具和账号自动相同。独立意见是证据输入，不是多数票审批机制。
来源＋观测时间
链接具体文件、行号、commit 或 URL，记录实际检查时间。
适用范围＋接受状态
写清适用环境或交付对象，缺少依据的字段保持未决。
责任人＋下一项检查
指定谁维护结论，以及出现什么证据时需要重新核验。
从发现到正式记录
- 01读取已有记录，核对 Space、Base 和 head。
- 02只提议有证据的字段，保留来源和未决问题。
- 03需要先审后写时使用 changeRequest；write 是更广授权，不是强制人审门槛。
- 04经授权审核合并后回读正式记录；下一任务带上版本和未决问题。
切换 provider 时，明确交接什么
接收 Agent 先读取正式结论、适用范围、证据与剩余问题，再继续任务。在 daemon 主机和选定 CLI 核实访问权限。不同 provider 的工具可能不同；无法读取证据时，把验证步骤明确交给能执行的任务，不能仅凭上一份 handoff 宣告核验完成。
常见问题
多个 provider 意见一致就算审核通过吗？
不算。分别保留主张和来源，审核能区分原因的检查及其结果，再接受有证据的结论。意见一致可以影响核查顺序，不能替代核查。
会替代原生记忆吗？
不会。原生指令与会话记忆继续服务执行；需要跨任务共享的审定事实及来源保存在这里，使用时读取最新版本。
多人同时更新怎么办？
提案前读取当前 head；版本变化时比较中间改动，修订提案，不用旧证据覆盖新结论。