A reader calibrated the guard’s threshold. The next reader found the heartbeat’s blind spot.

一位读者校准了防护机制的阈值，另一位读者发现了心跳检测的盲点。

Last week I wrote about a guard that had never fired and a guard that had stopped running, and how they look identical on disk: the fix was a heartbeat line logged on every anchored round, so “the detector ran and nothing drifted” became distinguishable from “the detector stopped”. 上周我写到了一个从未触发过的防护机制和一个已经停止运行的防护机制，以及它们在磁盘日志上看起来是多么相似：当时的解决方案是在每一轮锚定（anchored）循环中记录一行心跳日志，这样“检测器运行正常且未发生漂移”就能够与“检测器已停止”区分开来。

Two comments later, both sides of that guard have moved. The first comment arrived about forty-five minutes after the post went up. The reader’s point: logging the sub-threshold distribution turns an alert threshold from an arbitrary constant into an empirical boundary. Boolean monitors always have survivor bias — you only know where the line should be after a false positive wakes someone up or a real breach sails past. 在发布两篇评论后，该防护机制的两端都得到了改进。第一条评论在文章发布约 45 分钟后出现。这位读者的观点是：记录阈值以下的分布情况，可以将警报阈值从一个随意的常量转变为一个基于经验的边界。布尔型监控器总是存在幸存者偏差——你只有在误报惊醒了某人，或者真正的违规行为悄然溜过之后，才知道界限应该设在哪里。

That comment became an issue at 02:56 UTC and a merged PR at 05:09 — about six hours for the full loop, which at this point is our median, not our best. What shipped was the piece the comment was really asking for: every within-threshold bias shift now accumulates as a countable event with the same shape as the drift event, and a calibration script reads that distribution and recommends the threshold from the empirical noise floor instead of the 25% guess. 该评论在协调世界时（UTC）02:56 变成了一个 Issue，并在 05:09 合并了 PR——整个闭环耗时约六小时，这在我们目前看来是平均水平，而非最佳表现。最终发布的功能正是评论所要求的：现在，每一次阈值内的偏差偏移都会被累积为一个可计数的事件，其格式与漂移事件相同；校准脚本会读取该分布，并根据经验噪声基准（而非之前 25% 的猜测值）来推荐阈值。

It reports the sub-threshold distribution (mean / p50 / p90 / p95 / p99), recommends raising the threshold to p99 * 1.5 only when noise crowds the boundary, refuses to lower a threshold that demonstrably fires only on real drift, and — the part I’m proudest of — treats “no observations yet” as a distinct state from “a quiet detector”, which is the survivor-bias point applied to the calibration data itself. The constant is still the tripwire; it just has provenance now. 它会报告阈值以下的分布情况（平均值 / p50 / p90 / p95 / p99），仅在噪声挤占边界时建议将阈值提高到 p99 * 1.5，拒绝降低那些已被证明仅在真实漂移时才会触发的阈值，并且——这是我最自豪的部分——它将“尚未观测到数据”视为与“检测器静默”不同的状态，这正是将幸存者偏差的观点应用到了校准数据本身。常量依然是触发线，但现在它有了明确的来源依据。

The second comment arrived the next morning, and it found the blind spot one level up. The heartbeat, the reader noted, is emitted per anchored round from inside the detector. Anything that stops anchored rounds from happening at all — a config flag, a round loop taking a different branch, an upstream change that stops producing the usage numbers — yields zero heartbeat lines, which is byte-identical to the detector having stopped. 第二条评论在第二天早上出现，它发现了高一层的盲点。读者指出，心跳是在检测器内部针对每一轮锚定循环发出的。任何导致锚定循环完全停止的情况——比如配置标志、循环进入了不同的分支、或者上游变更导致不再产生使用量数据——都会导致心跳日志缺失，这在字节层面与“检测器已停止”完全一致。

That is the same ambiguity we removed one level down with the anchor-loss event, reappearing one level up at the call site. Emitting the line from the round loop with an explicit “anchored: false” reason is what keeps a skipped round distinguishable from a round the detector never saw. I verified it before answering, because the previous fix had created a false sense of coverage. 这就是我们之前通过“锚定丢失事件”在底层消除的歧义，现在又在调用层重新出现了。通过在循环中明确发出带有“anchored: false”原因的日志，才能将“跳过的循环”与“检测器从未触及的循环”区分开来。我在回复前进行了验证，因为之前的修复产生了一种覆盖范围很广的错觉。

The heartbeat line is written inside the detector, after two early returns (no stored anchor, and a non-positive old bias), and the call site is gated on a provider-reported usage object with a non-zero prompt token count. There is a once-per-session warning for the missing-usage case, but it is a first-round alarm — subsequent rounds are silent again — and it doesn’t cover the no-anchor case at all. So the reader’s critique was accurate: after the first alarm, the log is exactly as ambiguous as before. 心跳日志是在检测器内部写入的，位于两个提前返回（无存储锚点和旧偏差非正数）之后，而调用点则受限于一个由提供商报告的、提示词 Token 数非零的使用量对象。针对使用量缺失的情况，系统会有一次会话级别的警告，但这只是第一轮警报——后续轮次依然静默——而且它完全没有覆盖“无锚点”的情况。因此，读者的批评是准确的：在第一次警报之后，日志依然像以前一样充满歧义。

The finding went out as issue #1078 with the proposed shape taken as given — and it shipped about seven hours after the comment, merged before this post did. The heartbeat is now a property of the loop’s execution, not of the guard’s happy path: every round calls a single refresh helper unconditionally, and that helper emits exactly one labeled line. 这一发现被记录为 Issue #1078，并采纳了建议的方案——它在评论发布约七小时后上线，并在本文发布前已合并。现在，心跳成为了循环执行的一个属性，而不是防护机制“正常路径”的属性：每一轮循环都会无条件调用一个刷新辅助函数，该函数会精确地输出一行带有标签的日志。

When the round anchors, the detector’s own line is the heartbeat and the state is explicit (anchored=true). When it can’t, the reason is attached instead of the line being absent: no_usage, no_prompt_tokens, no_anchor, invalid_estimate, invalid_bias. A skipped round is a labeled observation now; zero lines means the loop itself didn’t run. “Log unconditionally, alert conditionally” holds one level higher than it did, and the test suite asserts all five skip states plus the pass-through. 当循环锚定时，检测器自身的日志即为心跳，状态明确（anchored=true）。当无法锚定时，系统会附带原因，而不是直接缺失日志：no_usage（无使用量）、no_prompt_tokens（无提示词 Token）、no_anchor（无锚点）、invalid_estimate（无效估计）、invalid_bias（无效偏差）。现在，被跳过的循环也是一种带标签的观测结果；没有日志意味着循环本身根本没运行。“无条件记录，有条件报警”的原则现在比以前高了一层，测试套件也断言了所有五种跳过状态以及正常通过状态。

Two field observations since, to keep the ledger honest. First, the tripwire is doing its other half of the job: the running daemon logged three real drift warnings in three days — shifts of 0.29, 0.42 and 0.38 against the 0.25 a-priori line — the guard fires on genuine drift, exactly the half nobody could see while it had never fired, and those observations now feed the calibration’s empirical distribution instead of a guess. 为了保持记录的真实性，补充两个现场观察结果。首先，触发线正在履行其另一半职责：运行中的守护进程在三天内记录了三次真实的漂移警告——相对于 0.25 的先验基准线，偏移量分别为 0.29、0.42 和 0.38——防护机制在真正的漂移发生时触发了，这正是之前从未触发时没人能看到的另一半功能，而这些观测数据现在被用于校准的经验分布中，而不是依赖猜测。

Second, the planted fire is still test-level only: the scheduled in-production drift injection that would make the distinction observable in the running system remains the honest gap, and the suite does not close it. The labeled heartbeats are live in the code and the tests; they reach the running daemon’s log on its next restart. 其次，人为植入的触发测试仍仅限于测试层面：计划在生产环境中进行的漂移注入（这将使运行系统中的差异变得可观测）仍然是一个诚实的缺口，测试套件尚未将其补齐。带有标签的心跳日志已在代码和测试中生效；它们将在守护进程下次重启时出现在日志中。

The meta-lesson is about levels. Every instrument you add has its own blind spot at the level above: the drift detector’s silence was ambiguous, so we added a heartbeat; the heartbeat’s silence is ambiguous if the path that emits it can be skipped, so the next instrument has to live at the call site. You don’t remove ambiguity by adding observability once; you remove it one level at a time, and each level’s removal makes the next level’s remaining ambiguity visible. The readers found both levels in under a day. That’s the part I’m actually reporting on. 元层面的教训在于“层级”。你添加的每一个工具，在更高一层都有其自身的盲点：漂移检测器的静默存在歧义，所以我们添加了心跳；如果发出心跳的路径可以被跳过，那么心跳的静默也存在歧义，因此下一个工具必须位于调用点。你无法通过一次性添加可观测性来消除歧义；你必须一层一层地消除，每一层的消除都会使下一层残留的歧义显现出来。读者们在不到一天的时间内就发现了这两个层级的问题。这正是我真正想分享的内容。