[RyodoTanaka]

変更点

PR#15 最終レビュー（および PR#17/#14 レビュー残り）の「低」指摘への追補。

1. can_diag.sh: berr-reporting 有効化時、元の restart-ms が読めなかった場合の既定値を、ハードコードされた 100 ではなく lib の CAN_RESTART_MS（conf 反映後）にフォールバックするよう変更。フォールバックした場合はその旨を診断ログに記録。判定ロジックは _diag_resolve_restart_ms() として実行ガード外に切り出し、単体試験可能にした（L-3）。
2. can_diag.sh: lock 取得後の pause 再照合（M2）で can_pause 自体が失敗した場合、黙って続行せず M1 と揃えて何も変えずに exit 1。再アサートに成功した場合は 1 行 NOTICE ログを追加（L-4）。
3. can_watchdog.sh: 起動時照合（§1d）で can_setup_iface が失敗した場合、結果を握りつぶさず reason=setup_failed_at_startup で劣化運転にするよう修正（L-4）。
4. can_watchdog.sh: _wd_snapshot の busoff= はストーム検出と同じファイルを共有しているため直近 ~60s（WD_STORM_WINDOW_S）の件数しか出ない点を明記し、起動以降の累計を表す busoff_total=（他のカウンタとは独立に増分・非プルーン）を併記するよう追加（L-5）。
5. can_watchdog.sh: lib の規則（素のまま呼んでよいのは can_read_conf/can_unpause/can_log/can_now のみ）に従い、can_unlock の素呼び出し全箇所と起動時の can_setup_iface 呼び出しを if/|| で包んだ。現状 set -e を使っていないため動作に変化はないが、将来のための予防（L-5）。

試験結果

• bash tests/run.sh: 17/17 PASSED
• shellcheck -S warning can_watchdog.sh can_diag.sh tests/test_watchdog_*.sh tests/test_diag_*.sh: 出力なし（クリーン）
• 上記 1〜4 の修正をそれぞれ個別に revert した状態で対応する新規/拡張試験が FAIL することを確認済み（5 は無変更の防御的修正のため専用試験なし）
• can_diag.sh / can_watchdog.sh / tests/test_diag_*.sh / tests/test_watchdog_*.sh のみ変更。lib・fakes・README・workflow・conf.example は未変更（別 PR 作業中のため）

Refs #9

🤖 Generated with Claude Code

[RyodoTanaka]

レビュー（Opus、読み取りと試しのみ、52f7983）

判定: マージ可。 クリティカル・高・中はありません。

確かめたこと

• 試験と CI: bash tests/run.sh は 17/17 PASSED、shellcheck -S warning（repo 直下の *.sh / *.bash と tests/）は空、CI は green、mergeStateStatus は CLEAN です。

• 毎周回の処理（hot loop）は変わっていません。 差分はすべて、まれにしか通らない経路にあります。

  • bus-off 復旧の 1 回ごとに busoff_total を読み書きします（cat 1 回と書き込み 1 回）。
  • snapshot（CRIT/NOTICE を出すときだけ）。
  • 起動時照合。
  • can_unlock || true（fork なし）。
  • PR #15 の e2 と同じ条件で、20 s の間の本体と子の CPU 合計は 0.48 s（1 コアの約 2.4 %）でした。#15 の 0.42 s と測定誤差の範囲で同じです。

• setup_failed_at_startup が誤って出ることはありません。 この判定に届くのは、PR #15 の M1 の条件をすべて通ったうえで、watchdog 自身が bind し、netdev が現れ、名前の固定（pin）にも成功した後だけです。M1 の条件は、spidev のディレクトリがあること、driver のリンクが無いこと、pause 中でないこと、劣化運転中でないこと、ロックが取れたことです。

  • 試し A: spidev が無く、偽の can1 も無い（setup を実行すれば失敗する状態）。iface_missing の WARNING だけが出て、劣化運転にはならず、bind もしません。
  • 試し B: spidev があり driver も付いているが、netdev はまだ無い（列挙が遅れている状態）。bind せず、劣化運転にもなりません。
  • bind 直後の setup 失敗を劣化運転にするのは、rebind 経路の setup_failed と同じ扱いで、§1d の「bind / pin / setup の失敗」どおりです。

• PR #15 の受け入れの再実行も退行なしです。

  • e1: 短絡の嵐で rebind しない。
  • e7: 再起動後の setup は restart-ms 0 berr-reporting off fd off と txqueuelen 10。

• can_diag の確認:

  • restart-ms を読めなかったときの代わりの値は、lib の CAN_RESTART_MS（conf を反映した値）になりました。その旨が diag のログにも残ります。
  • pause をもう一度張るのに失敗したときは、iface に触る前の時点で exit 1 になります。cleanup では _berr_ifaces が空なので復元は走らず、ロックだけを解放します。pause も、自分が書いた値のときだけ戻します（M2 の規則）。「何も変えずに終了」になっています。

• busoff_total の確認: 刈り取られない累計で、busoff=（ストームの窓の件数）とは別に持ちます。バックオフで後回しにした bus-off は数えないことも、試験で断定しています。

低（任意）

• L-1 can_diag.sh の cleanup の復元側（395 行目）は、${CAN_RESTART_MS:-100} のままです。can_read_conf の後なので :-100 に落ちることはありませんが、表記を :-0 にするか既定値なしに揃えると読み手に親切です。
• L-2 setup_failed_at_startup の否定側の試験（spidev が無い／driver が付いている場合は劣化運転にならない）は、M1 の既存の試験で間接的に担保されています。上の試し A・B を、この PR の試験に 1 件ずつ足しておくとより確実です。
• L-3 busoff_total_<if> は /var/lib（SD カード）に bus-off 1 回ごとに 1 回書きます。busoff_times と同じ頻度なので新たな負荷ではありませんが、嵐の間（10-14 は 14 s で 17 回）は書き込みが続く点だけ留意してください。