你的真实目标不是 issue、不是 DailyRecord、也不是 richer board，而是非常窄的一条链路： 在信息获取群里发一条链接，然后自动写进 公众号信息采集台账。 这条链路现在已经重新拿到真实 E2E 证据，最新探针写入了 A85:I85。
不做大模型总结，不发群回复，只抽几个核心字段，失败时可排查。
plain link 已重新进入 logs，并成功追加到公众号信息采集台账。
把信息获取群从 true 改回 false，主链路恢复。
OpenClaw 仍会静默调度到 dev-triage，只是最终 replies=0。
| 目标项 | 在信息获取群发一条 plain link，自动写入公众号信息采集台账。 | 已实现 | 最新真实探针 om_x100...8fd6 写入 A85:I85。 |
|---|---|---|---|
| 目标项 | 不要再把链接写成全局主账本语义，不要残留错误投影。 | 已实现 | 当前固定为 projection=link_library，9 列写入。 |
| 目标项 | 成功时不要再在群里冒出莫名其妙的回复。 | 已实现 | 最新 restored 探针最终 queuedFinal=false, replies=0。 |
| 目标项 | 完全不要调度模型，只跑 hook。 | 未完全实现 | 仍会静默 dispatch 到 dev-triage，只是没回群。 |
| 目标项 | 失败时能快速知道卡在哪。 | 部分实现 | 底层日志已可排查，但用户侧失败提示仍不够强，且成功默认静默。 |
她会先把链路拆成可观测阶段，而不是一开始就争论“是不是 fixed”。 这次真正有用的证据就是三段：飞书 UI 发送成功、OpenClaw 收到消息、sheet_auto 写入成功。 之前之所以体感混乱，是因为缺少用户侧 ACK，很多不同问题都被体感成“没反应”。
他会强调先恢复 last-known-good，再做结构优化。A84 那次其实已经证明主链路绿了， 但在这条基线还没冻结时继续追“不要调度模型”，把主链路再次带进了风险区， 最终才出现 requireMention=true 把 plain link 一起切断的回撤。
他会把这件事看成多个控制面的耦合问题：Feishu 激活规则、OpenClaw routing、 passive hook、sheet writer 是四层，任何一层都能让体感相似，但根因完全不同。 所以这次最重要的不是继续猜，而是明确哪一层已经绿、哪一层还没绿。
最新真实 E2E 已经证明：信息获取群中的 plain link 会重新进入 OpenClaw，并最终追加到 公众号信息采集台账。下面这张图只画现在真正发生的链路，而不是理想图。
这部分是今天最绕、也最耽误时间的地方。两个方案都真实跑过，所以现在可以明确地说清楚： 不是没试，而是这两个试法一个只改变了去哪个 agent，一个直接把收件也关掉了。
把信息获取群的 requireMention 从 true 恢复为 false， plain link 才重新进入 messages.jsonl。
被动 hook 的写表逻辑继续固定在 link_library， 并强制带 --append-data-only，避免标题行再被当作数据行重复写入。
inbound dedup 已经恢复到下游处理前执行，避免同一条入站消息把后面的写表、副作用和排障都带乱。
真实探针 green。om_x100b54485dc698b8c3eefc3adfbee95 写入 A84:I84，但仍发生 silent dispatch。
错误优化。把 requireMention 设为 true 之后，plain link 在 gateway.log、messages.jsonl、feishu-sheet-auto.jsonl 都不再出现。
热修复。恢复 requireMention=false，Feishu channel 热重载成功。
真实发送。恢复后探针 E2E LINK fix-20260316-restored 进入信息获取群，messageId 为 om_x100b544839898484c33a0e0e3ab8fd6。
写表成功。同一探针写入 a2176e!A85:I85，writtenRows=1，updatedCells=9。
残留差距。gateway 记录 dispatch complete (queuedFinal=false, replies=0)，说明可见回复已收口，但 silent dispatch 仍在。