報告のobserved_atを記録より前にしない。経路を確かめるreporting verifyを足す（ADR 0195、0.76.0）

[quolu]

修正: 故障や解決の直後の送信が、受け口に断られていた

0.74.0・0.75.0 は、報告の observed_at を署名の時刻（秒）と同じ値へ切り捨てて作っていた。BugHubは、記録の last_seen や解決の resolved_at が observed_at より後の報告を 422 invalid_report で断る。記録と同じ1秒の中で送ると、切り捨てた observed_at は記録より前になる。自動送信は記録の直後に走るので、ほとんどの場合これに当たる。

実際に起きたこと（rabbit、2026-10-03）:

• 解決を 12:22:47.921 UTC に打ち、自動送信が 12:22:48.007 に rejected。
• 76秒後に手で送ると delivered。
• 最初の到達確認（11:51）が通ったのは、記録が 11:51:28.999 で、送信が次の秒へまたいだため。

断られた報告は、同じ中身の送り直しの制限で最大1時間遅れて届く。記録は失われない。

直し: observed_at を、送る時刻と、載せる記録の時刻のうち最も後の時刻にする。秒へ切り捨てない。受け口の検査は契約どおりで、変えない。

追加: lattice runtime-errors reporting verify --json

記録を載せない空の報告を1通送り、合鍵・署名・受け口までの経路・受領の署名を確かめる。

• 送る条件は report と同じ。送信を有効にしていない端末と、合鍵の無い端末は、networkへ触れない。
• storeの記録、受領の印、送る時機の記録には触れない。
• 受け口は受領を記録するだけで、issueも通知も動かさない（BugHubの持ち主に確認済み）。
• 受領まで確かめられた時だけ verified・exit 0。

Windowsの端末から届くことを、起きていない故障の記録を作らずに確かめるために要る。合鍵を入れ替えた時にも使える。

確かめたこと

• BugHubと同じ規則（記録の時刻が observed_at より後なら422）で検査する受け口を試験に置き、記録や解決と同じ1秒の中で送った報告が受領されることを確かめた。
• 端末の時計が戻った時は、observed_at が記録の時刻になる。
• reporting verify の前後で、storeの診断と送信の状態が変わらない。
• 手元の npm run ci 全体が成功（root 1963件中 0失敗）。

🤖 Generated with Claude Code