v0.2.1
⚠ 監視を繋ぐ前に、監視される側を直すためのパッチ。
⚠⚠ **どちらも 0.2.0 のリリース前レビューで赤にし、「監視がまだ 1 本も繋がっていない」を理由に非ブロック化して繰り越したもの。**⚠ 本番 rubicon が 2026-08-15 に稼働を始め、次が監視の接続（pooza/chubo2#98 → #15）なので、その前に入れる。
#78 — makoto status が「投稿が実際に出たか」を見ていなかった
⚠⚠ jobs は起動時に決まる登録の本数なので、160 枠すべてが失敗しても jobs: 5 のまま exit 0 だった。
枠の結末を 3 つに分けて、失敗の側だけを数える。
| 枠の結末 | 記録 |
|---|---|
| 投稿できた | failures を 0 に戻す |
| ⚠ 本文が無い | 何も記録しない（中立） |
⚠ source が落ちた／投稿が失敗した |
failures を 1 つ進める |
- 🔴 **「本文が無い」を中立に置くのが肝。**⚠ 失敗に数えると原稿がまだ無いだけの日（8/15〜10/31 の 2 か月半）が延々と警告になり、⚠⚠ 成功に数えると「設定を消すと枠の中で例外が上がる」形（#77）が中立に紛れる
- ⚠⚠ 異常（1）ではなく警告（2）。投稿が落ちる原因（トークンの失効・設定の欠落・
sourceの不具合・Mastodon 側の障害）はどれも再起動で直らないので、1 にすると検知 → 再起動 → また失敗のループになる - ⚠
makoto statusにposting:の行が増えた
#79 — 不正なバイト列を含む例外でログ経路自体が落ちていた
⚠ **PostingJob → Scheduler の両方の rescue を貫通して stderr へ抜け、bin/makoto_daemon.rb が /dev/null に落とすので 1 行も残らなかった。**⚠⚠ 常駐は生き続け、makoto status は健全のまま。
**呼び出し側 6 箇所ではなく、Makoto::Logger#create_message（出口 1 つ）で受けた。**⚠ 6 箇所を直す形は 7 箇所目が生えた瞬間に、しかも静かに破れる。
⚠⚠ レビューで出た 3 件（すべて実在した）
- 同じ枠の失敗を二重に数えていた — ⚠ 成功は冪等キーで畳まれるのに失敗だけ畳まれず、落ちた枠 1 つで閾値を 2 つ消費。「投稿の側で冪等にしたものは、観測の側でも冪等にする」
- 🔴 痕跡の書き込みが不可分でなかった — ⚠
File.writeは切り詰めてから書くので、読んだ側が壊れた JSON を掴みstale?が true。⚠⚠makoto statusが 1 を返して monit が正常な常駐を再起動する形で、#78 自身が窓を広げていた（1 時間に 1 回 → ライブ当日 160 回）。実測で 2,000 回中 625 回が nil - 🔴 秘密がマスクを迂回して漏れる経路を、#79 の修正自身が作っていた — ⚠⚠ 修正前は syslog で落ちて「ログごと消えて」いたものが、scrub で出力できるようになった結果、秘密がそのまま書かれる。「ログが消える」を「秘密が漏れる」に変えていた
検証
- ✅ ステージング検証（手順 4・省略不可） —
bydoで検知そのものを動かした。3 枠落としてcode=2、同じ枠は二重に数えず、1 本出ればcode=0 - ✅ ⚠ #79 のログが実際に
/var/log/makoto2.logに残り、同じ行のtoken: SECRETはログ全体で 0 件 - ✅ 11/1〜11/4 の 4 日ぶんの下見が 0.2.0 と同一（11/3 は前日増量 8/8、11/4 は 160/160）
- ✅ lint / config:lint / 357 tests 0 failures（0.2.0 の 314 から +43）
- ⚠ 投稿は 1 通も出していない
Full Changelog: v0.2.0...v0.2.1