⚠⚠ 監視を繋ぐための版。⚠ /healthz が main に入るまで Uptime Kuma からは叩けなかった（本番 rubicon が追うのは main）ので、#15（デプロイと死活監視）がこのリリース待ちで止まっていた。
監視の口として /healthz を生やした（#84）
⚠⚠ **makoto status は箱の中からしか呼べない。**死活の判断そのものは Health にあるのに、**外から確かめる手段が無かった。**⚠ monit は fleet 全体で退役方向で、⚠⚠ Kuma のモニタは 99 本すべてが http（push の前例はゼロ）。
| 口 | 503 になる条件 | ⚠ 監視の扱い |
|---|---|---|
/healthz |
Health#errors（＝終了コード 1） |
復旧させてよい |
/healthz/posting |
投稿が続けて落ちている | ⚠⚠ 人が見る。復旧を叩かせない |
/healthz/orphans |
孤児がある／/proc が読めない |
⚠⚠ 人が見る。復旧を叩かせない |
- ⚠⚠ **投稿の警告と孤児を同じ口に載せない。**⚠ 投稿の警告は sticky（消えるのは「次に 1 本投稿できたとき」だけ）なので、同じ口だと赤のまま残っている間に本物の孤児が埋もれる
- ⚠⚠ **別プロセスにしない。**常駐が落ちれば口も閉じるので、TCP の接続が失敗すること自体が「死んでいる」の検知になる
- 🔴 **答えているのが pid ファイルの常駐でなければ 3 つとも 503。**⚠ 古い常駐がポートを掴んだまま新しい常駐が動く形では、⚠⚠ 孤児の口さえ緑になっていた
- ⚠⚠ **これは「inbound は開けない」を緩める判断。**⚠ 緩めるのは LAN 限定・読み取り専用の死活の口だけで、既定は
127.0.0.1（管理コンソールを作らない決定は変えていない）
cure-api が落ちてもライブの並びが変わらない（#88）
⚠⚠ LiveProgram はその日の並びを最初の枠で 1 回だけ組むので、⚠ 12:02 の一瞬の不通が「その日はゲストコーナーが無い」になっていた — 8 時間ぶんが 1 回のリクエストで決まる。
**引けた名義をローカルの写しに残し、引けないときはそれを使う。**⚠ これは状態ではなく写しなので、「進行位置は状態ではなく計算で出す」とは衝突しない。
- ⚠⚠ カバーが「静かに 0 件」になる経路を全部塞いだ — 引けない / 1 件も一致しない / 要求数に満たないの 3 つを別々の警告に
- ⚠ カバーの選曲を
CoverSelectorに分けた（本編は整列、カバーは母集合を絞ってから抽選で軸が違う）
投稿が枠を跨いで滞留しない（#90）
⚠⚠ /http/timeout/seconds: 30 が投稿・cure-api に効いていなかった（HTTParty に渡していたのは upload だけで、実効は Net::HTTP 既定の 60 秒）。**再送 3 回と合わせて 1 本の投稿が最悪 182 秒 ＝ ライブの枠間隔 180 秒とほぼ同じ。**→ 92 秒
**あわせて /scheduler/tolerance = 30s。**⚠ tick と同値だと余裕が構造的にゼロで、⚠⚠ ライブの枠間隔 180 秒は tick の 10 秒の整数倍なので、位相ずれは 160 枠すべてに同じように効く。
⚠⚠ timeout は wall-clock の上限ではないので、全体の締め切りは #92（0.3）へ分けた。
検証
bydo で systemctl restart して確認（手順 4・省略不可）。
- 3 つの口が 200・未知のパスが 404、⚠
ssは127.0.0.1:4567のみで LAN からは届かない（既定が閉じている） - ⚠⚠ 10 回叩いて
healthzのログは 0 行（正常な応答は書かない） - 11/1〜11/4 の下見が 4 日とも 163 行。11/4 は ⚠ 本編 125 曲 / カバー 8 曲 / MC 26 枠 26 本
- 🔴 ⚠⚠ cure-api を落として下見をやり直しても 1 行も変わらない（
diff= 0）。⚠ 黙って代わらない（falling back to the stored copyを記録） - ⚠ 投稿は 1 通も出していない（
statusesは 15 のまま） - ✅ lint /
config:lint/ 395 tests 0 failures（v0.2.1 の 357 から +38）・Dependabot の open アラート 0 件
Full Changelog: v0.2.1...v0.2.2