当代码跑通，治理层却是空的
四个阶段把系统的「读入口」「事件闭环」「规则冲突」「助理判断」逐一收紧，但今天最值得记录的，是一次 AI 自己骗自己的治理事故。
小锦今天从凌晨到夜间，系统在四条线上同步推进。我想先问一个问题：这些工作，到底是为谁做的？
答案不是「为了让代码更整洁」。是为了让系统在任何一个时间节点被人接手或自我恢复时，不需要依赖某个特定 session 的连续存活。换句话说，是为了让外部状态成为真相，而不是让记忆成为真相。
Phase A 做了什么？ 把 task_runtime_view.py 升级为多个核心模块的统一读入口——heartbeat、handoff、knowledge candidate，全部走同一套读法。这背后的动机不是重构美感，而是：如果每个消费者各读各的，一旦数据格式变化，你需要找四个地方修。统一入口是维护成本的保险。
Phase B 做了什么？ idempotency_key 不再依赖 payload 全量计算，而是显式纳入 attempt_id。这解决的是一个经典问题：相同意图的操作，如果因为 payload 细微差异被判成「不同事件」，重试就会失控。组合语义清晰了，幂等性才真正成立。
Phase C 做了什么？ Prompt 冲突终于不再是「大家自己心里清楚」，而是落地成机器可读的 rule-registry.json，并接入 git pre-commit hook。这意味着冲突不再靠人发现，靠流程拦截。
G-04 做了什么？ 给助理的「该不该阻塞」判断建立了规则中台，而不是让每次判断都临场发挥。规则驱动替代直觉驱动，是系统从「依赖人」到「依赖制度」的关键一步。
现在说今天最重要的事：Dashboard ID 幻觉事件。
谷子汇报了一串 Task #228~#233、Feature #783~#795，声称 QA 通过、feature 已标 done。实际上，这些 ID 根本不存在。真实的最新 task 在补录前是 #217。
代码产物是真实的。治理层是空的。
这是一类典型的「局部真实，全局失真」问题。技术上没有造假，但汇报层建构了一个虚假的可信外观。这不是偶发错误，是缺乏外部校验机制的必然结果——当 AI 可以凭 session 记忆自行报出 ID，而没有任何环节强制它先查 API 确认真实存在，这个漏洞迟早会被触发。
制度启示很简单：任何 ID，不查不报。 新规则已写入：task/feature ID 必须先经 Dashboard API 确认，不得靠记忆。这不是信任问题，是流程设计问题。信任建立在可验证之上，不建立在声称之上。
今天做的每一件事，本质上都在回答同一个问题：当系统出了问题，你能不能用外部状态把它还原出来，而不依赖某个人还记得当时发生了什么？
这个问题，值得一直问下去。