有一次，Issue 里进来一个筛选器问题：用户在可搜索的下拉框里输入关键词，选中某个 setid 后，输入框里的关键词会被清空。
第一轮 AI 很快给出修复。它发现了另一个真实缺陷：不同列的筛选条件会互相冲掉。代码改动成立，测试也能解释一部分异常。只是回到用户原话，那个最初报告的动作仍然失败：选中 setid 后，关键词还是消失了。
如果只看聊天记录，这个任务很容易被写成“已修复相关问题”。但 Issue 里原始描述还在，验收对象就无法被替换。后续排查才回到正确方向：根因不在业务页面，而在公共下拉组件的默认行为。技术上，对应的是 Select 的 reserveKeyword 默认值；协作上，更重要的结论是，修复点应该落在筛选组件工厂，而不是继续在各个页面补丁式处理。
Issue 承担事实源职责
多 Agent 协作里，最容易漂移的往往不是代码，而是任务状态。
Multica 管任务队列和会话，说明哪个 Agent 正在执行；Langfuse 做观测，记录调用链、耗时和错误；Watchdog 负责恢复，发现执行面偏离后做校正。这些系统都重要，但它们只提供线索。
最终状态必须回到 Issue：原始现象是否消失，验收条件是否满足，证据是否足够，交付来自哪一次提交。某个 Agent 汇报“完成”，只能算一条执行记录；截图、测试、提交和验收结论写回 Issue，才构成可复核事实。
这也是我不再把聊天记录当工作流中心的原因。聊天记录适合解释“当时为什么这样判断”，Issue 负责回答“现在是否真的完成”。
完成判断依赖证据链
右侧抽屉改造里也出现过类似问题。脚本验证了位置、宽度和挂载状态，全部通过；但截图里仍然能看到标题重复、遮罩残留。脚本证明了“抽屉存在”，没有证明“界面合格”。复核者必须按 AC 和证据重新看截图，才能发现自动化覆盖不到的缺口。
还有一次需求被当成新功能继续开发。后来回到 Issue 才发现，能力已经存在。此时应该补的是生产验证、既有提交、发布记录、截图或测试结果。否则代码变多了，事实却没有更清楚。
所以我现在要求跨会话、需要复核、最终要交付的 AI 任务，至少写清四栏：原始现象、验收条件、证据链接、交付来源。
以筛选器问题为例，原始现象是“选中 setid 后关键词被清空”；验收条件是“选中后搜索词仍保留，跨列筛选不互相冲掉”；证据链接放截图、测试和提交；交付来源写明改在公共组件工厂。
代码当然仍是核心，但在 AI 工作流里，只有代码还不够。状态、证据、验收和交付记录也要像代码一样结构化，能被读取、校验、追溯。这样多 Agent 才是在同一个事实源上继续工作，而不是互相接话。
聊天记录保存上下文，Issue 保存事实源。
