配置管理执行，记录保存判断
workspace manifest 和插件设置决定启动环境，仓库文件描述被调查的代码，共享故障记录则保存团队已接受的判断。配置版本和知识版本分别记录，更新插件配置不应悄悄改变旧结论的含义。
执行上下文
工作文件、指令和临时观测留在当前任务的执行环境。
证据引用
为具体主张保留来源、观测时间和适用范围，便于复核。
团队正式记录
以当前正式记录为入口，将审定值和未决问题交给下一任务。
两个 worktree，对同一故障得出不同解释
虚构故障调查中，两个 Agent 基于不同提交提出相反原因。主张必须带上 commit、环境和观测时间。审核人先核对证据是否描述同一次部署，再接受共享结论。新启动的任务读取已接受版本，不复制旧诊断当事实。
虚构示例，用于说明记录结构，不是真实客户结果或实测。
提案记录示例
| 字段 | 示例值 | 证据／决定 |
|---|---|---|
| source.A | commit A / staging | scope A |
| source.B | commit B / production | scope B |
| review_check | compare deployed commit and observation time | required |
| accepted_head | no shared cause before environment match | not accepted |
- 01worktree A：提交与主张
- 02worktree B：另一提交与主张
- 03审核：先对齐部署和时间
- 04正式 head：有范围的结论
先核部署，再比较结论
每个 worktree 都记录 commit、部署目标、观测时间和证据。两份观测来自不同发布版本时，应拆开适用范围，而不是对诊断投票。审核人可以接受其中一个版本的解释，要求另一个版本补测；各自修复仍链接到对应 PR。
下一位 Agent 应读到什么
建议记录字段
incident_id、repo、commit、environment、observed_at、source、claim、next_check
插件变化面向新启动的 Agent，不自动改变运行中的会话。Agentastic 的 MCP 仅适用于文档支持的 provider，不能承诺所有 CLI 一样兼容。工作区 manifest 认可和凭据存储管理的是执行配置，Busabase 记录审核管理的是知识接受。
来源＋观测时间
链接具体文件、行号、commit 或 URL，记录实际检查时间。
适用范围＋接受状态
写清适用环境或交付对象，缺少依据的字段保持未决。
责任人＋下一项检查
指定谁维护结论，以及出现什么证据时需要重新核验。
从发现到正式记录
- 01读取已有记录，核对 Space、Base 和 head。
- 02只提议有证据的字段，保留来源和未决问题。
- 03需要先审后写时使用 changeRequest；write 是更广授权，不是强制人审门槛。
- 04经授权审核合并后回读正式记录；下一任务带上版本和未决问题。
新启动任务，重读当前决定
启动时先确认实际 provider 与 MCP 配置，再读当前故障记录。commit 或环境变化时，先核适用性再复用诊断。需要修改已接受原因时，保留旧值，并明确哪份新证据支持更新，让下一任务能追溯结论为何变化。
常见问题
认可工作区插件，就等于认可调查结论吗？
不等于。插件认可管理执行配置；诊断还需要准确代码版本、环境、证据和独立接受决定。更改插件默认值，也不能证明运行中的任务已经获得新工具。
会替代原生记忆吗？
不会。原生指令与会话记忆继续服务执行；需要跨任务共享的审定事实及来源保存在这里，使用时读取最新版本。
多人同时更新怎么办？
提案前读取当前 head；版本变化时比较中间改动，修订提案，不用旧证据覆盖新结论。