持续运行的 Agent 系统要把三个问题回答清楚：将要合入的代码经过了哪些检查，一条完成声明从何处进入账本，重启以后怎样识别已经计过的输入。
这个系列来自九月底到十月初的 Harness 工程进展。第一篇沿一次“全绿”盲区复盘合并关口；第二篇追踪事件表示、准入与消费的契约；第三篇从两个崩溃窗口推导计数状态的保存顺序。
各篇以重述的机制、短伪代码和合成例子展开，配有原创机制图。可以按阅读路线连续读，也可以直接进入对应工程问题。
从问题登记册到合并关口：一次“全绿”漏洞的工程复盘 ↗
把修复经验变成可执行约束，还需要证明约束实际运行在将要合入的代码上。一次通过数足够却漏掉守卫的反例，推动了逐目标审计、合并后树验证和关口负对照。
完成事实的入口：类型化事件与共享写入边界 ↗
当完成声明藏在通用事件包装中，写入许可与消费含义可能错位。Harness 的一次修正把禁止包装的规则放进两条写路共用的校验边界，并以逻辑读视图保留合法历史事件，再用 AST 守卫约束生产者与消费者的演化。
游标最后推进：从两次故障推导信号重放 ↗
一批信号可以重读，却不能重复加到累计值里。沿着丢信号与重复计数两个故障窗口，推导游标、计数和字节水位的写入顺序。
从检查结果的身份、完成事件的语义，到计数重放的水位，这三篇围绕同一个工程要求：让系统决定有可核对的依据。