Aktueller Umsetzungsstand vom 07.10.2026: Alle acht zusätzlichen Befunde G8–G10/D9–D11/U8–U9 wurden auf Grundlage von Main 4f9cfd2c5c5bee92f4013f09273e0aff936be9aa korrigiert. Sechs unabhängige Sichten und Root haben den vollständigen geänderten Stand erneut geprüft; alle zusätzlich konkret bestätigten Randfälle wurden im selben Durchlauf geschlossen. Die historischen 16 und zwölf früheren Korrekturen bleiben erhalten. Aktuelle Verträge und Prüfnachweise folgen unter Umsetzung und Vollscan.

Die folgenden ursprünglichen Abschnitte und die 16 Korrekturen sind historische Nachweise und bleiben als solche erhalten.

Erneute Prüfung des vollständigen Main-Stands 9415e290309bb3e3d2e108e6ba9ca42f4fe03243 nach Einbindung nativer Fahrtformen und Bibliotheksmigration. Alle 220 versionierten Dateien und Dateimodi des lokalen Checkouts stimmen mit Remote-Tree 0cdc4aeaef1e4b17795e4eb0d0d5fcca486b9eba überein. Die lokale Checkpoint-Historie unterscheidet sich; geprüft wurde der identische Dateiinhalt.

Sechs unabhängige Reviewer untersuchten Oberfläche/Bedienung, GPS/Geometrie, Android-Laufzeit/Audio/Energie, Sicherheit/API, Daten/ViewModels und Build/Release/Tests. Quellcode, bestehende Regressionen und die betroffenen Wiki-Verträge wurden gegengeprüft. Der ursprüngliche Review veröffentlichte ausschließlich Dokumentation. Die nachstehend historisch belegten Befunde wurden anschließend auf Nutzerauftrag vollständig korrigiert; der aktuelle Umsetzungsstand folgt nach den Befundtabellen.

P1 bezeichnet hier einen Fehler, der die aktive Begleitung falsch abschließen kann. P2 betrifft falsche Daten, fehlende Funktionen oder unzureichend abgesicherte Veröffentlichungen. P3 betrifft weniger dringliche Anzeige- beziehungsweise derzeit nicht erreichbare Helferpfade. Dies sind Review-Prioritäten, keine gemessenen Häufigkeiten.

Der eigene CI-Lauf des geprüften Main 37523081347 ist erfolgreich. Heruntergeladene Berichte bestätigen 571 Tests in 37 Klassen, ohne Fehlschläge, Fehler oder übersprungene Tests. Vollständiges Debug-Lint meldet 0 Fehler und 53 Warnungen; Debug-APK und unsignierte Release-APK wurden gebaut. Die Warnungen betreffen KTX (15), Versionshinweise (14), Icons (12), Texte (5), veraltete SDK-Abfragen (4) sowie Ziel-API, Akkuhinweis und TOML (je 1). Die SDK-36-kompatiblen Versionspins sind keine automatisch zu behebenden Fehler.

Zusätzlich wurden zwei temporäre JUnit-Klassen gegen unveränderten Produktivcode ausgeführt. Drei Schutzassertions schlugen wie vorhergesagt fehl: zwei für GPS-Sprung/Abschluss/Ansage und eine für den Zielrücksetzpfad im Texteditor. Der Gradle-Lauf kompilierte erfolgreich und endete nach 17 Sekunden wegen dieser drei Assertionfehler. Die temporären Tests wurden anschließend aus dem Repository entfernt. Dieser Befundnachweis ist getrennt von der grünen bestehenden Suite; dauerhafte Regressionen sind Teil der jeweiligen nachfolgenden Fehlerkorrektur.

Es gab keine schreibenden Live-API-Aufrufe, keine Release-Veröffentlichung, keine Verwendung echter Kontotokens und keine Geräteprüfung. Synthetische Positionsfolgen beweisen einen Codepfad, rekonstruieren aber keine frühere Nutzerfahrt. Weitere Befunde beruhen auf konkreten Quell-/Request-Reihenfolgen oder primären API-/Plattformverträgen; ihre Häufigkeit auf dem Gerät bleibt unklar.

ID / Priorität	Auslöser und Auswirkung	Quellbeleg	Empfohlene Korrektur
G1 / P1	Nach zwei langsamen Fixes am bestätigten Einstieg erscheint ein scheinpräziser Fix mehr als zwei Kilometer entfernt am Ziel nur zwei Sekunden später. Ein weiterer Zielfix kann die Fahrt abschließen und vorher die Zielansage reservieren. Beide Auswirkungen wurden mit temporären Tests bestätigt.	StationTrackingEngine, Zeilen 245–272 und 703–722: isReliable prüft Alter/Genauigkeit/Koordinaten; die normale leftArrival-Bedingung kann die getrennten Recovery-/Rail-Sprungschutzpfade umgehen.	Physische Übergänge und Ankunftsbelege gegen eine gemeinsame plausible Bewegungsfolge prüfen. Lange echte GPS-Lücken weiterhin getrennt wiederverankern; alte Ansage-/Abschlussbelege nicht aus einem verworfenen Sprung übernehmen.
G2 / P2	Eine vorübergehend fehlgeschlagene Registrierung bei Fused Location Provider löscht den Callback. Nach Behebung der Störung registriert der laufende Service keinen Ersatz; GPS bleibt bis zum erneuten sichtbaren Activity-Start aus.	TripTrackingService, Zeilen 989–1009 sowie 515–532.	Begrenzter Retry mit Backoff und Sitzungs-/Generationsprüfung, nur bei weiterhin autorisiertem GPS. Entzogene Freigaben nicht durch automatische Wiederanfragen übergehen.
G3 / P2	Frische Standortdaten werden monoton auf ihr Alter geprüft, anschließend aber mit Location.time sortiert/dedupliziert. Eine rückwärts springende Uhr kann neue Fixes am alten Wasserzeichen blockieren; unterschiedliche Provideruhren können die Wallclock-Altersprüfung verletzen.	Service, Zeilen 915–927; Engine, Zeilen 245–258 und 867–871; Android Location.	Monotone Beobachtungsreihenfolge und Alter von darstellbaren Ereigniszeiten trennen. Uhrsprünge dürfen keine vorherige Bewegungsbasis oder Prognose wiederbeleben.
G4 / P2	Wechsel der TTS-Engine A→B während der Fahrt betrifft die Testansage in Settings, aber nicht die bestehende Serviceinstanz. Stationsansagen bleiben auf A; auch ein Initialisierungsfehler bleibt ohne Wiederanlauf dauerhaft unbehandelt.	Service, Zeilen 183–186, 253–254 und 1133–1138; SettingsViewModel, Zeilen 45–54 und 136–140.	TTS-Konfiguration im Service beobachten, die Engine generationsgebunden erneuern und Initialisierungsfehler sichtbar behandeln. Wartende Ansagen dabei erneut auf ihre aktuelle Relevanz prüfen.

Die bestehende Session-/Generationsbindung nativer Formen, deren RAM-Cache und begrenztes Parsing ergaben keinen weiteren bestätigten Blocker. WakeLock-Freigaben bei Wechsel, Stop, Destroy und Timeout sind nachvollziehbar abgesichert. Daraus folgt keine Garantie für tatsächliche Samsung-/Doze-/Audiozustellung.

ID / Priorität	Auslöser und Auswirkung	Quellbeleg	Empfohlene Korrektur
D1 / P2	Editor für Ziel A öffnen, nur Text ändern; anderer Client setzt B; der 30-Sekunden-Refresh übernimmt B, während das Formular A behält. Speichern sendet A als vermeintlich bewusst geändertes Ziel und überschreibt B. Der Requestpfad wurde per temporärem Test bestätigt.	StatusDetailViewModel, Zeilen 111–145 und 329–350; StatusEditRequest, Zeilen 9–16.	Originalbesuch des Editors explizit speichern; eine Zieländerung ausschließlich gegenüber diesem Edit-Anfangswert bestimmen. Konflikte gegebenenfalls anzeigen.
D2 / P2	Ein vor markAsRead begonnener GET liefert seine alte ungelesene Meldung erst nach erfolgreich beendetem Read-POST. pendingReads ist bereits entfernt; die Antwort darf die Meldung wieder als ungelesen veröffentlichen. Auch parallele normale Count-Requests besitzen keine eigene Antwortgeneration.	NotificationViewModel, Zeilen 50–78, 104–125 und 154–160.	Lesemutationen mit der Listenantwortversion abgleichen oder bestätigte Markierungen bis zu einem neueren Snapshot überlagern. Count-Requests separat ordnen beziehungsweise zusammenführen.
D3 / P2	Zwei verschiedene Stations-IDs innerhalb von etwa 200 Metern werden bereits wegen eines gemeinsamen Ortsworts zusammengelegt. Synthetisches Beispiel: „Teststadt Markt“ (51,7) und „Teststadt Rathaus“ (51.0005,7); die zweite ID verschwindet aus Check-in und Fahrterkennung.	TraewellingRepository, Zeilen 155–181.	Nur gleiche Stationsidentitäten oder belegte gemeinsame Identifier deduplizieren. Name und Nähe allein belegen keine austauschbaren Halte.
U1 / P2	Die Check-in-Felder „Zeiten anpassen“ ersetzen POST-departure/arrival, obwohl diese die geplanten Besuche identifizieren. Eine Ankunftskorrektur ohne exakten Planzeitmatch wird abgelehnt; eine geänderte Abfahrt kann beim eindeutig vorhandenen Einstieg nur ignoriert werden.	CheckInViewModel, Zeilen 352–374; Upstream CheckinService, Zeilen 172–203; Hydrator desselben Commits, Zeilen 69–81.	Beim Erstellen die ausgewählten Planmarker unverändert senden. Manuelle Zeiten erst über den unterstützten Statuseditor/PUT setzen oder die irreführende Eingabe entfernen.
U2 / P2	Am Ausstieg bevorzugt die Timeline das Echtzeit-Abfahrtsgleis der Weiterfahrt statt des Ankunftsgleises. Beispiel: Ankunft Gleis 2, Weiterfahrt Gleis 4 ergibt Gleis 4 am eigenen Ziel; passende Plan-Gleise fehlen ebenfalls im Rückfall.	StatusDetailScreen, Zeilen 999–1002.	Den vorhandenen ereignisbezogenen trackingPlatform-Helfer nutzen oder Ankunft/Abfahrt ausdrücklich getrennt beschriften.
U3 / P2	Die Abfahrtsauswahl zeigt bevorzugt Planzeit und nur positive Verspätung. Plan 18:00, Echtzeit 17:57 erscheint als 18:00 ohne Verfrühungshinweis. Der negative Modellwert existiert bereits.	CheckInScreen, Zeilen 344–347 und 368; Models, Zeilen 223–225.	Echtzeit neben Plan beziehungsweise auch negative Abweichungen anzeigen; Darstellung separat testen.
U4 / P3	Nach erfolgreichem Löschen im Detail bleibt eine bereits geladene Feedkarte sichtbar. Erneutes Öffnen führt bis zum manuellen Refresh zu 404; RAM-/Room-Feed werden nicht invalidiert.	Detail-ViewModel, Zeilen 247–266; FeedScreen, Zeilen 32–35; Repository, Zeilen 108–111.	Erfolgreiche Änderungen/Löschungen an den Feed melden und den sitzungsgebundenen Cache synchronisieren.

ID / Priorität	Auslöser und Auswirkung	Quellbeleg	Empfohlene Korrektur
S1 / P2	allowBackup=true ohne Ausschlüsse nimmt bei aktivierter Systemsicherung reguläre DataStore-/Datenbankdateien auf. Darin stehen Zugangsdaten sowie privater Fahrt-/Feedcache. Auch die tatsächlich zusammengeführten Debug-/Release-Manifeste enthalten keine ergänzenden Regeln.	Manifest, Zeile 24; PreferencesManager, Zeile 16; AuthSession, Zeilen 15–24; Android Auto Backup.	datastore/traewelling_prefs.preferences_pb und sensible Datenbankdateien aus Cloud-/D2D-Sicherung ausschließen: alte fullBackupContent-Regeln und neue dataExtractionRules. Einstellungen bei Bedarf getrennt sichern. Der Befund behauptet weder unverschlüsselte Cloudablage noch fremden App-Zugriff.
S2 / P3	Der derzeit nicht an die UI angebundene Refresh-Helfer löscht einen bestehenden Refresh-Token, wenn die erfolgreiche Antwort keinen neuen enthält. Das ist laut OAuth-Vertrag eine zulässige Antwort; ein nächster Refresh kann dann nicht mehr starten.	AuthRepository, Zeile 91; AuthSession, Zeile 61; RFC 6749 §6.	Ausschließlich beim Refresh den bisherigen Refresh-Token behalten, falls kein Ersatz ausgegeben wird. OAuth-Fehlercodes statt pauschal jedes HTTP 400 als verlorene Autorisierung behandeln.
R1 / P2	Die Releasevalidierung erlaubt eine bereits veröffentlichte Versionsbezeichnung. Beispiel 1.8.7/Code 14 wird akzeptiert, obwohl v1.8.7 bereits existiert. Die Releaseaction aktualisiert bestehende Releases und überschreibt Dateien standardmäßig; neuer APK-Inhalt kann unter einem alten Quelltag landen.	android.yml, Zeilen 32–39 und 103–108; Releaseaction-Vertrag.	Vorhandene Tags/Releases vor dem Build abweisen, Dateien nicht überschreiben und Releasejobs serialisieren. Keine solche Veröffentlichung wurde im Review ausgeführt.
R2 / P2	Der Versionscode wird nur auf Zahlenbereich geprüft, Default ist 1. Ein neuer Versionsname mit Code 1 wird akzeptiert, obwohl der signierte Lauf für 1.8.7 bereits Code 13 nutzte; eine reguläre Updateinstallation ist damit blockiert.	Workflow, Zeilen 10–13 und 36–39; signierter Lauf 37477231988.	Monotone Versionsquelle und Abgleich mit dem veröffentlichten Höchstwert vor Signierung. Parallel gestartete Releases dürfen keinen gleichen/niedrigeren Code erhalten.
R3 / P2	target_commitish fehlt. Bei Branch-Dispatch oder einem während des Builds fortgeschriebenen Main kann der neue Tag auf den aktuellen Defaultbranch statt auf den tatsächlich gebauten Commit zeigen.	Workflow, Zeilen 103–108; Releaseaction-Eingaben.	Den Tag ausdrücklich an ${{ github.sha }} binden und die Tagidentität prüfen. Ein erfolgreicher Build allein belegt diese Bindung nicht.

Sechs parallel arbeitende Implementierer und unabhängige Gegenprüfungen ergänzen die folgenden Korrekturen. Die ursprünglichen Quellzeilen oben beziehen sich ausschließlich auf den historischen Prüfcommit; heutige Dateien haben andere Zeilennummern.

Befund	Eingebaute Korrektur	Dauerhafte Prüfung
G1	Gemeinsamer Kurzsprungschutz vor Ankunft, Abfahrt, Cursor, Ansage und Abschluss; verworfener Fix ersetzt keine plausible Referenz. Lange Lücken verwenden weiterhin eigene Wiederverankerung.	StationTrackingJumpTest, bestehende Engine-/Tunnel-/Railfälle
G2	Drei begrenzte Registrierungsretrys nach 2/5/15 Sekunden; Callback-, Fahrt-, Generations- und Freigabeprüfung; sichtbarer Fehler.	LifecycleRetryBudgetTest, Service-Gegenprüfung
G3	Alter und Reihenfolge aus monotoner Providerzeit; aktuelle Ereigniszeit minus Fixalter; Uhrsprung entfernt Bewegungs-/ETA-Basis, erhält Besuch und Ansagekeys. Erkennung verwirft alte asynchrone Suchergebnisse.	TrackingLocationObservationTest, Sprung-/Clockfälle, Gegenprüfung beider Services
G4	Engine/Enable/Sprache/Stimme reaktiv; 10-Sekunden-Initfrist, begrenzter Wiederanlauf und Versuchstokens; wartende Ansagen erneut besuchsbezogen prüfen.	SpeechInitializationLifecycleTest, Service-Gegenprüfung
D1	Zielvergleich gegen Editor-Anfangsstatus; ausdrückliche manuelle Ankunftsabsicht getrennt von Providerrefresh.	StatusEditRequestTest
D2	Bestätigte Einzel-/Alle-Lesemarkierungen überlagern alte GETs; Countanfragen besitzen eigene Reihenfolge und Mutex.	NotificationControllerTest mit virtueller Coroutine-Zeit
D3	Deduplizieren anhand belegter Stationsidentität; verschiedene interne IDs bleiben trotz Nähe oder gemeinsamem Ortsnamen erhalten.	NearbyStationIdentityTest
U1	Geplante Besuchsmarker unverändert im POST; manuelle Istzeiten danach im PUT derselben Sitzung; Teilfehler und unvollständige akzeptierte Erstellung erlauben keinen zweiten POST.	CheckInSubmissionTest, Repositorytests
U2	Am Einstieg das Abfahrtsgleis, am Ziel das Ankunftsgleis und passende Planwerte mit dem gemeinsamen ereignisbezogenen Helfer verwenden.	Gemeinsamer trackingPlatform-Vertrag und Modelltests
U3	Parsebare Echtzeit, abweichende Planzeit und auch negative Abweichung anzeigen.	DepartureTimePresentationTest
U4	Erfolgreiche Statusmutationen invalidieren RAM-/Room-Basis ihrer Credentialpartition; Events und Feedübernahme bleiben revisionsgebunden. Alte GETs werden verworfen. DELETE-Nachlauffehler warnt, beendet Busy und navigiert genau einmal.	Repository-Mutationsfälle, FeedControllerTest, DeletedStatusCompletionTest
S1	Altes und neues Backupregelwerk schließen DataStore sowie Datenbanken mit Journals/WAL/SHM aus Cloud-/Geräteübertragung aus.	XML-/zusammengeführte Manifestprüfung, Android-Lint
S2	Nicht ersetzten Refresh-Token erhalten; Sitzung nur bei streng belegtem invalid_grant in passender Authrevision entfernen.	AuthRepositoryTest einschließlich ungültiger/temporärer Fehlerantworten
R1	Vorhandene Tags/Releases ablehnen; global serialisieren; neuen Tag/Draft reservieren und Assets nur create-only auf eigener Release-ID hochladen.	Offline-Releaseguardtests mit Konflikten, Teilfehlern und API-Doubles
R2	Durable Legacy-Untergrenze 13 plus validierte künftige Versionsassets; auto Höchstcode + 1, explizit nur größer; unklare Historie stoppt.	Offline-Releaseguardtests einschließlich neuer Historie und Rennen
R3	Checkout/Tag am exakten Dispatchcommit, APK-Manifest/Hash und Metadaten prüfen; veröffentlichte Identität erneut lesen.	Offline-Releaseguardtests mit falscher SHA, Manifest-/Digestfehlern und alter Draftidentität

Die Gegenprüfung behob zusätzlich bestätigte Folgefehler bei erfolgreicher alter Mutation nach erneutem Login mit gleichen Credentials, erfolgreicher PUT-Antwort ohne brauchbaren Statusbody, akzeptierter POST-Antwort ohne Status-ID sowie lokalem DELETE-Cleanupfehler. kotlinx-coroutines-test ist ausschließlich eine Testabhängigkeit; produktive Bibliothekspins und SDK-Ziele bleiben gleich.

Aktuelle ausgeführte Ergebnisse stehen unter Tests. Geräte-, Restore- und signierte Live-Releaseprüfungen bleiben getrennt; es gab keine schreibenden Träwelling-Tests und keine Nutzung echter Kontotokens. Architekturentscheidungen stehen in der ADR Befundkorrekturen.

Der veröffentlichte CI-Lauf 37529409222 ist auf exakt diesem Commit erfolgreich: 658 Unit-Tests in 47 Klassen, 41 Offline-Releaseguardtests, Debug-/unsignierter Release-Build und vollständiges Debug-Lint mit 0 Fehlern und 53 Warnungen. Die heruntergeladenen JUnit-/Lint-Berichte wurden unabhängig gezählt. Der lokale frische Build hatte 40 Warnungen; 13 zusätzliche erreichbare Versionshinweise erklären den CI-Unterschied. Nach Entfernung aller temporären Nachreviewklassen wurde die unveränderte 658-Test-Suite lokal nochmals erfolgreich ausgeführt (17 Sekunden, keine Fehler, Fehlschläge oder übersprungenen Tests).

Zusätzliche kontrollierte Gegenproben verwenden den unveränderten Produktivcode: neun JUnit-Prüfungen in sieben temporären Klassen ergaben sieben gezielte Schutzassertionfehler und zwei erfolgreiche Adapterkontrollen. Drei zusätzliche Offline-Python-Prüfungen ergaben zwei Schutzassertionfehler und eine erfolgreiche Releasekontrolle. Die sieben fehlgeschlagenen Kotlin-Prüfungen scheiterten ausschließlich an den erwarteten Assertions; die zwei Kontrollen bestanden. Es gab keinen Ausführungsfehler. Die lokalen Gradle-Läufe dauerten 20 beziehungsweise 19 Sekunden. Diese zwölf Zusatzprüfungen sind weder Teil der vorhandenen 658/41-Test-Suite noch Beleg eines fehlgeschlagenen veröffentlichten CI-Laufs. Temporäre Klassen wurden anschließend entfernt. Es gab keine Live-API-Schreiboperationen, keine Signing-/Releaseoperation und keine Verwendung echter Kontotokens.

Zeilenangaben beziehen sich auf Main f406bad. P2 betrifft hier Funktions-/Datenfehler oder einen konkret administrativ ausgelösten Versionsregress; P3 betrifft weniger dringliche Anzeige-/Bedienpfade. Kein neuer P1-Abschlussfehler wurde bestätigt.

ID / Priorität	Auslöser und tatsächliche Auswirkung	Quellbeleg / Nachweis	Empfohlene Korrektur
G5 / P2	Nach bestätigtem Einstieg folgt alle drei Sekunden ein plausibler 24-Meter-Fix bei 8 m/s. Die Engine wechselt kumulativ bei 240 Metern zum Folgehalt; die GPS-Abfahrt des Einstiegs wird nie beobachtet, weil das letzte Paar unter 35 Metern liegt und spätere Fixes nicht mehr zum alten Besuch gehören. Zukunftsprognosen bleiben möglich.	Zeitschätzer, 305–306 und 493–500; Engine, 727–734. Eine ausgeführte Engine→Estimator-Schutzassertion bestätigt fehlendes departureObserved; normale Folgeprognose und fehlender Abschluss sind Kontrollen.	Abfahrt an kumulativ belegte Besuchsbewegung binden; normale kurze Fixpaare dürfen den beobachteten Ereignisübergang nicht dauerhaft verlieren.
G6 / P2	Während Wiederverankerung folgen präzise Fixes t0/t3, ein frischer ungenauer 150-Meter-Fix t6 und ein präziser t9. Der Service filtert t6 vor der Engine heraus; der alte Kandidatenbeleg bleibt bestehen und ein einzelner zurückkehrender Fix kann bereits den späteren Besuch wählen. Ein 80-Meter-Fix setzt denselben Beleg dagegen zurück. Kein unmittelbarer falscher Abschluss ist belegt.	Service, 1056–1059 und 1117–1120; Engine, 260–262 und 543–555. Zwei ausgeführte reine Clock-/Engine-/Adapterkontrollen bestätigen die Abweichung; kein Android-Service wurde ausgeführt.	Jede neue unbrauchbare Beobachtung muss den transienten Wiederverankerungsbeleg gezielt invalidieren oder die Engine erreichen.
G7 / P2	Hinter dem echten Ende einer gültigen nativen Form wird derselbe Fix an die vorletzte Kante geklemmt. Ein Punkt 75,05 Meter hinter dem Ende mit Genauigkeit 75 Metern und unbestätigter Ankunft ergibt eine Projektion bei 96,5223 Prozent und eine neue GPS-ETA. Die Sperre der letzten Kante wird durch den benachbarten Vertex umgangen. Kein physischer Fahrtabschluss wurde ausgelöst.	Geometrie, 67–72; Zeitschätzer, 256–292. Ausgeführter echter Transitparser→Geometrie→Engine→Estimator-Beleg: Kurve 1027,63 Meter, drei plausible Fixes über acht Sekunden, erwartete fehlende Prognose verletzt.	Endpunktunterstützung über den gesamten Linienzug prüfen; verschieden dichte oder kurze Randkanten dürfen die Abschnittsendprüfung nicht umgehen.
D4 / P2	Nur Text bearbeiten; anderer Client schränkt inzwischen die Sichtbarkeit ein; der Editor sendet trotzdem den alten Sichtbarkeitswert zurück. Der Dialog besitzt keine Sichtbarkeitsauswahl. Dadurch kann eingeschränkt sichtbarer Inhalt wieder öffentlich werden.	Requestbuilder, 16–17; Detail-ViewModel, 141–151 und 309. Ausgeführte Schutzassertion: Anfang 0, aktuelle Sichtbarkeit 2, reine Textänderung; Request enthält 0 statt null. Server behandelt nur vorhandene Sichtbarkeitsfelder.	Sichtbarkeit nur bei ausdrücklich geänderter Benutzerabsicht senden; Textänderung lässt das Feld weg.
D5 / P2	Ein vor dem Like gestarteter GET trifft nach dessen Erfolg ein oder beendet sich während des offenen Like. Der Feed übernimmt wieder liked=false; nach Erfolg sendet der nächste Tipp erneut Like statt Unlike.	Feedcontroller, 94–107 und 149–159. Beide Reihenfolgen mit realem Controller und verzögertem Gateway ausgeführt; beide Schutzassertions schlagen fehl.	Like-/Unlikeabsicht und bestätigte Mutation gegen ältere GET-Snapshots schützen; Overlays nicht nur für Updated-Events anwenden.
D6 / P2	„Alle gelesen“ ist auf dem Server bereits abgeschlossen, dessen Antwort aber verspätet. Danach entsteht Meldung B; ein GET während der ausstehenden Antwort liefert B korrekt ungelesen. Die UI markiert und bestätigt B trotzdem dauerhaft gelesen, während der serverseitige Zähler 1 bleibt.	Meldungscontroller, 85–87 und 165–169. Kontrollierter Servercommit→neue Meldung→GET→PUT-Antwort→frischer GET ausgeführt; B hat readAt="now" statt null.	Bestätigte MarkAll-Menge beziehungsweise Snapshotgrenze an den Mutationsbeginn binden; neuere Meldungen nicht aus einer später geladenen Liste nachbestätigen.
D7 / P2	Activity-Neuanlage, etwa Rotation während der Texteingabe, entsorgt die alte Composition. Deren onDispose setzt das erhaltene Detail-ViewModel zurück, löscht den Entwurf und beendet eine mögliche Mutation. Der neue Screen lädt ohne Entwurf.	Detailscreen, 70–75; Detail-ViewModel, 427–436; Activity, 51–53 und 111–126; Manifest, 35–39. Konkreter Lifecycle-/Codebeleg, kein ausgeführter Rotationstest.	Screenabonnement und erhaltenen Fach-/Editorzustand getrennt beenden; Reset nur an einen tatsächlichen Fahrt-/Sitzungswechsel oder ausdrückliches Verwerfen binden.
U5 / P2	Während eines ausstehenden Check-in-POSTs öffnet der Nutzer die noch bestehende Fahrterkennungsnotification. Navigation ruft reset() auf; dieses schützt nur die nachgelagerte SUCCESS-Phase und bricht CONFIRM+Loading ab. Ein bereits serverseitig angenommener Check-in kann ohne Erfolgskarte, Aktivierung und Zeitkorrektur zurückbleiben; die UI bietet erneut Erstellung an. Ein tatsächlicher doppelter Serverstatus ist nicht belegt.	Navigation, 65–66; Check-in-ViewModel, 391–403; Erkennungsservice, 356–373. Konkreter erreichbarer Intent-/Codepfad; goBack() sperrt denselben offenen POST ausdrücklich.	Alle Reset-/Navigationspfade während einer bereits abgeschickten Erstellung absichern und deren Ergebnis zu Ende übernehmen.
R4 / P2	Ein künftig bereits veröffentlichter Release mit Code 18 wird administrativ gelöscht oder wieder zum Draft. Obwohl sein Tag bleibt und die APK installiert sein kann, wählt der nächste neue Release Code 14. Der normale erhaltene Verlauf wählt 19.	Releaseguard, 237–264 und 268–271. Zwei ausgeführte Offline-Schutzassertions bestätigen 18→14; Kontrolle mit unverändertem veröffentlichtem Release ergibt 19. Erfordert externe Historienänderung, keine normale Workflow-Race.	Auch künftig ausgegebene Höchstcodes dauerhaft bewahren oder unvollständig zurückgezogene Historie blockieren. Bis dahin veröffentlichte Versionsmetadaten erhalten beziehungsweise den dauerhaften Floor vor weiterer Veröffentlichung erhöhen.
D8 / P3	Check-in-Zeit-PUT A committet vor Text-PUT B, aber Antwort B trifft vor der verzögerten Antwort A ein. Der Feed zeigt erst den neuen Text und danach wieder den alten Text aus A. Serverzustand und Room-Invalidation bleiben korrekt; der RAM-Feed ist bis Refresh veraltet.	Repository, 136–148; Feedcontroller, 62–65. Ausgeführte reale Repository→Mutation-Flow→Feed-Probe mit zwei PUTs verletzt die abschließende Texterwartung. Haupttabs bleiben während der nachgelagerten Check-in-Zeitkorrektur erreichbar.	Überlappende Mutationen je Status ordnen oder nach ihnen einen aktuellen Snapshot verifizieren; komplette Antwortbodies nicht allein nach Ankunftsreihenfolge übernehmen.
U6 / P3	Initiale Standard-TTS-Engine scheitert; die Einstellungsansicht kehrt vor dem Laden der installierten Engineliste zurück. Eine funktionierende installierte Alternative ist in Routely nicht auswählbar. Service-Retries betreffen einen anderen Besitzer.	Settings-ViewModel, 96 und 109; Settingsscreen, 275–281. Konkreter Initfehler-/UI-Codepfad, kein Gerätetest.	Engineliste unabhängig von erfolgreicher Syntheseinitialisierung anbieten; sichtbaren Fehler und Wiederanlauf für den Settingsbesitzer ergänzen.
U7 / P3	Einstellungsname und Switch sind getrennte Semantikknoten; der Toggle erhält keine zugehörige Beschriftung. Der Token-Anzeigenbutton besitzt ausschließlich ein dekoratives Icon ohne Aktionsbeschreibung.	Settingsscreen, 33–38, 189–195 und 266–269; Setupscreen, 148–151. Code-/Compose-Vertragsbeleg, keine instrumentierte Semantik- oder TalkBack-Prüfung.	Beschriftung und Toggle zusammenführen und „Token anzeigen/verbergen“ zugänglich benennen.

Der heutige Upstream-develop wurde erneut als 4d602796da8409017314cc771b1127d169155f02 bestätigt; API_CHANGELOG.md hat Blob-SHA 151ba6f1c9e012f9a665eef2f733ee1114d73015. Alle verwendeten Endpunkte und Laufzeitressourcen wurden mit den aktuellen primären Routen/Ressourcen verglichen. Kein zusätzlicher inkompatibler Consumervertrag wurde gefunden. Septemberänderungen betreffen Ressourcen/Stationsabfahrten; additive manuelle Trips und Heimstationfunktionen sind noch keine angebundene Produktfunktion.

Die Visibility-Enum unterscheidet 0 öffentlich, 2 Follower und 3 privat. Die D4-Probe verwendete 2, nicht 3. Der Requestbuilder sendet unabhängig vom zwischenzeitlichen Wert den alten Wert; die Auswirkung auf privat eingeschränkte Inhalte folgt aus diesem Code- und Serververtrag. Der Server erzeugt nach Commit einen kompletten Antwortsnapshot, der bei verzögerter Übertragung bereits älter als eine zweite Mutation sein kann.

Android-Verträge für D7/U7 wurden anhand Activity-Neuanlage, DisposableEffect und zugänglichen Switches gegengeprüft. Die reinen Prüfungen führen weder Rotation noch Android-Service-/FLP-/TTS-/Doze-Zustellung aus. Reale Häufigkeiten und frühere Nutzerfahrten bleiben unbewiesen.

Die folgende Umsetzung korrigiert alle zwölf Befunde. Die historischen Quellzeilen und damaligen Schutzassertionfehler oben beschreiben ausschließlich den unveränderten Ausgangsstand.

Befund	Heute eingebaute Korrektur	Dauerhafte Prüfung
G5	Kumulierte Abfahrt seit bestätigtem inneren Aufenthaltsanker; geordneter Übergang und frisches Vorwärtspaar bleiben nötig. Eindeutig gestützter Anker knapp vor dem Ursprung kann Fortschritt null verwenden.	GpsDepartureObservationTest
G6	Neue unbrauchbare Clockbeobachtung erreicht die Engine und unterbricht den transienten Wiederverankerungsbeleg. Alte/Replays bleiben ausgeschlossen.	TrackingLocationRecoveryAdapterTest
G7	Endpunktzulässigkeit nach Kandidatenvergleich auf dem gesamten Linienzug; benachbarte Kanten umgehen kein reales Ende. Kurven-/Mehrdeutigkeitsregeln bleiben erhalten.	GpsGeometryEndpointTest
D4	Unveränderte Sichtbarkeit im PUT weglassen; explizite Editierabsicht getrennt vom Providerrefresh.	StatusEditRequestTest
D5	Offene/bestätigte Like-Absicht überlagert ältere GETs und vollständige Statusevents; Like/Unlike invalidiert Room und publiziert revisionsgebundene Teilmutation.	FeedLikeOrderingTest, StatusWriteOrderingTest
D6	MarkAll bestätigt nur Start-IDs; neue Meldungen bleiben servergetreu. Erfolgreicher PUT erzwingt neuen Snapshot und sperrt alte Listen; Rollback erhält sichtbare Ungelesene.	NotificationControllerTest
D7	Erhaltener Fachzustand und getrennte Composition-Beobachtungsleases; Rotation verwirft weder Entwurf noch abgeschickte Mutation. Aktuelle VM-Busygrenze sperrt Verlassen vor Recomposition.	StatusDetailPresentationTest
U5	Gemeinsamer Schutz für CONFIRM-POST und SUCCESS-Nachkorrektur in Auswahl, Reset, Navigation und Zurück.	CheckInNavigationGuardTest
R4	Annotierte Create-only-Codeclaims vor Build/Signierung, exakt lauf-/versuchsgebunden. Fehlbuild und Release-Rücknahme geben Code/Name nicht frei; fehlende ältere Evidenz stoppt.	Offline-Releaseguardtests
D8	Prozessweite feste Mutexstreifen ordnen PUT/DELETE/Like/Unlike je Credential und Status durch Antwort/Cacheübernahme. Warten abbrechbar, Dispatch zeitbegrenzt weitergeführt.	StatusWriteOrderingTest
U6	Enginekatalog unabhängig von Syntheseinitialisierung; sichtbarer Fehler/Retry, zehn Sekunden Initfrist und Callbackgeneration.	SettingsSpeechInitializerTest
U7	Gelabelte gemeinsame Switchaktionen, eigenbeschriftete Dropdowns und Token-Anzeigen-/Verbergenaktion.	Quell-/Semantik-Gegenprüfung; Instrumentierung offen

Die fachfremde Gegenprüfung fand und korrigierte zusätzliche konkrete Folgefälle im selben Durchlauf: Bodyless-PUT-Verifikation darf durch spätere Mutationen nicht verloren gehen und muss Seite 1 prüfen; ein gestützter Haltanker knapp vor dem Ursprung benötigt eine konservative Ausgangsprojektion; MarkAll-Rollback muss währenddessen neu geladene ungelesene Meldungen mitzählen; Dropdownfelder brauchen ihre eigene Beschriftung; ein schneller Zurücktipp muss gegen den aktuellen VM-Zustand geprüft werden; bestätigtes DELETE muss lokale identitätsgebundene Bereinigung unabhängig vom späteren Ansichtswechsel abschließen; bereits geladene eigene Karten im Nutzerprofil müssen erfolgreiche Mutationen übernehmen und alte GETs sperren. Die Profilintegration erhält laufende Follow-Aufträge, ihren eigenen Besitzer und einen Followfehler auch über nachfolgende erfolgreiche Statusverifikation. Unveränderter Text wird beim reinen Zeit-PUT ebenfalls ausgelassen; bewusst geleerter Text bleibt eine ausdrückliche Änderung. onCleared invalidiert Präsentation und Ladegeneration, damit eine noch laufende bestätigte DELETE-Bereinigung nach Sitzungsende keinen veralteten UI-Hinweis auslösen kann.

Die unabhängigen Sichten umfassen GPS/Geometrie, Android-Lifecycle/Audio/Notification/Widget, Daten-/API-/Cacheantworten, Editor/Navigation/Zugänglichkeit sowie Auth/Backup/Release. Keine Schutzgrenze wurde für einen Test gelockert. Eine grüne reine Suite belegt diese Codeverträge, keine echte Nutzerfahrt oder Gerätezustellung. Tatsächlich ausgeführte Tests, Lint und Buildnachweise stehen unter Tests; die Abwägung steht in der ADR Nachreview-Korrekturen.

21 bestehende Seiten wurden aktualisiert: api/traewelling-kompatibilitaet, architektur/datenfluss, architektur/entscheidungen, entscheidungen/README, entwicklung/deployment, entwicklung/main-review-2026-10-06, entwicklung/tests, index, module/checkin, module/feed, module/gps-zeiten, module/notifications, module/profile, module/settings, module/status-detail, module/trip-tracking, module/user-profile, offene-fragen, ui/komponenten, ui/screens und ui/theme. Neu ist die ADR Nachreview-Korrekturen. Gründe sind die korrigierten Codeverträge, dauerhaften Regressionen und neue Versionsclaim-/Lifecycleentscheidungen. Auth-/Auth-PKCE-, Secrets-, Widget-, Fahrterkennungs-, Fortschritts-, Datenmodell-/Schema- und externe Schnittstellenseiten wurden zusätzlich sachlich gegengeprüft; dort erfordern diese Korrekturen keinen neuen Vertrag. Alle 60 Wiki-Seiten werden auf relative Links und abschließende verwandte Seiten geprüft. Praktische Geräte- und signierte Release-TODOs bleiben sichtbar getrennt.

Der lokale Tree 5faeef8b0f5f01f2ac969c453ce8f6b872e6b03e wurde vollständig mit Remote-Main abgeglichen: 264 Blobs mit identischen Inhalten und Dateimodi. Der CI-Lauf 37536735143 und Wiki-Sync 37536735025 sind auf genau 443d6e1 erfolgreich. Die echten CI-Berichte bestätigen 726 Tests in 56 Klassen ohne Fehler oder Skips, 56 Offline-Releaseguardtests, vollständiges Debug-Lint mit 0 Fehlern/53 Warnungen sowie Debug- und unsignierten Release-Build (4 Minuten 20 Sekunden, alle 108 Tasks ausgeführt). Die damaligen 42 lokalen Warnungen unterscheiden sich um elf erreichbare Gradle-/Maven-Versionshinweise.

Die erneuten Sichten decken GPS/Geometrie/ETA, Android-Service/Lifecycle/Audio/Recognition/Widget, Daten/API/Cache/Mutation, UI/Navigation/Zugänglichkeit und Release/CI/Auth/Backup ab. Root prüfte zusätzlich die externen Parser-/Quellverträge und den Träwelling-Upstream: develop ist weiterhin 4d602796da8409017314cc771b1127d169155f02; der erneut gelesene Changelog hat unverändert Blob-SHA 151ba6f1c9e012f9a665eef2f733ee1114d73015. Keine neue Endpunktmigration ist belegt.

ID / Priorität	Konkreter Auslöser und Wirkung	Quellstelle im geprüften Commit	Nachweis und passende Korrektur
D9 / P1	Aktive Fahrt kurz vor dem alten Ziel verlängern, Ziel-PUT bestätigt. Die Begleitung hält bis zum nächsten frischen Poll die alte Zielrolle; ein vor PUT gestarteter GET kann sie anschließend erneut übernehmen. Normale Ankunft am alten Ziel löst Zielansage und Trackingabschluss samt Entfernen der aktiven ID aus.	StatusDetailViewModel.kt:405–422, TripTrackingService.kt:744–787,1320–1326,1618	Daten-/Androidsicht unabhängig bestätigt; ausgeführter Enginevergleich mit identischer plausibler Fixfolge zeigt alten Abschluss, während aktualisierte Zielrollen weiterfahren. Service muss bestätigte Mutationen übernehmen und alte Snapshotantworten an eine Mutationsrevision binden; Stopovers/Geometrie und Fortschritt gemeinsam abgleichen.
G8 / P2	Tracking startet nach Abfahrt auf einer validierten Kurve oder kehrt nach einer GPS-Lücke zurück. Fixes alle 3 Sekunden bei 8 m/s ergeben 24 Meter je Paar; trotz 240 Metern weiterer gerichteter Bewegung bleibt Einstieg beziehungsweise alter Besuch ausgewählt. Folgeansage und ETA können verspätet verfügbar werden.	StationTrackingEngine.kt:617–634,683–701	Zwei ausgeführte Parser→Engine-Proben scheitern am erwarteten Folgehalt. Native Bootstrap-/Gap-Hilfen verlangen 35 Meter im letzten Paar. Kumulierten Beleg auf unveränderter Projektionsbasis verwenden; frisches Vorwärtspaar, Mehrdeutigkeits- und Sprungschutz erhalten.
G9 / P2	Bediente Halte liegen 180 Meter auseinander. Nach bestätigtem Aufenthalt wechselt die Engine bei ungefähr 120 Metern bereits zum Folgehalt; der Abfahrtsbeobachter benötigt mehr als 120 Meter plus Genauigkeit. Danach verhindert lastVisitKey dauerhaft den ausstehenden Abfahrtsbeleg.	GpsJourneyTimeEstimator.kt:508–517, StationTrackingEngine.kt:775–776	Ausgeführte Engine→Estimator-Probe bestätigt Folgeankunft, aber fehlende Einstiegsabfahrt. Ausstehenden Abfahrtsbeleg über den geordneten Übergang erhalten und mit frischen kompatiblen Folgefixes prüfen; Radius nicht lockern.
G10 / P2	Bestätigter Aufenthalt und gerichtete Ausfahrt, aber nächste Planankunft fehlt oder Fahrtintervall überschreitet 90 Minuten. Der Forecastguard verhindert bereits observeDeparture; dadurch fehlt zusätzlich die eigene Istabfahrt.	GpsJourneyTimeEstimator.kt:267–282,293	Zwei ausgeführte Proben: nullable Folgeankunft sowie validierte etwa 183-km-Kurve mit 100 Minuten Planfahrt. ETA bleibt zurecht ROUTE_UNSUPPORTED; physische Ereignisbeobachtung muss von zeitlicher Forecastzulässigkeit getrennt werden.
D10 / P2	Dashboard-Like ist noch offen; Wechsel zum Globaltab startet dessen erste GET-Ladung. Alter Likeabschluss/Statusevent bricht sie ab und startet keinen Ersatz. Der neue Tab bleibt leer, obwohl Daten vorhanden sind.	FeedController.kt:65–100,173–181,203–210, FeedScreen.kt:32–48	Ausgeführte Coroutineprobe liefert [] statt [99]. Unabhängige Tabladungen erhalten beziehungsweise einen abgebrochenen notwendigen Abruf neu starten; Schutz vor alten Karten und Like-Absicht bewahren.
D11 / P2	Vorhandenes Nutzerprofil wird aktualisiert; Followbutton bleibt aktiv. Erfolgreicher Follow-POST setzt following=true, danach überschreibt die ältere Profil-GET-Antwort dies wieder mit false. Unfollow ist spiegelbildlich gefährdet.	UserProfileController.kt:82–92,160–203, UserProfileScreen.kt:101–126	Ausgeführte Coroutineprobe bestätigt false statt true; UI-Trigger unabhängig geprüft. Profilantworten gegen Followrevision binden beziehungsweise bestätigte Beziehungsabsicht erhalten und frisch verifizieren.
U9 / P2	Launcherroot auf unterstütztem Android 8–11/API 26–30: System-Zurück während bereits serverseitig angenommenem, aber antwortoffenem Check-in-POST beendet die Activity. Featurestore-Clear bricht den Scope ab; Aktivierung und Abschlussübernahme fehlen.	CheckInScreen.kt:47–84, AppNavigation.kt:74–83, SessionViewModelStore.kt:16–22, CheckInViewModel.kt:350,371–385, TraewellingRepository.kt:256–263	Zwei statische Sichten plus Android-Primärvertrag; kein Gerätetest. BackHandler nur für sichtbare Check-in-Page an denselben Pendingguard binden. Android 12+ Root-Back beendet regulär nicht die Activity; abgeschickte Zeit-PUTs sind weiterhin NonCancellable geschützt. Kein tatsächlicher Doppelstatus behauptet.
U8 / P3	Frischen GPS-Fahrterkennungsvorschlag übernehmen, in Zielauswahl einmal Toolbar-Zurück. Die VM springt in DEPARTURES, hat für diesen Einstieg aber nie Abfahrten geladen. Sie zeigt eine leere Liste ohne vorausgehende Abfahrtsanfrage.	CheckInViewModel.kt:107–113,426–428, CheckInScreen.kt:324–335	Quell-/Navigationsprüfung; Herkunft der Zielauswahl berücksichtigen und zur Suche/Erkennung zurückkehren oder Abfahrten ausdrücklich laden. Keine Servererstellung ausgelöst.

Acht gezielte Tests in vier temporären Klassen wurden gegen unveränderten Produktivcode ausgeführt: sieben Schutzassertionen reproduzieren G8–G10/D10/D11, ein bestandener Vergleich bestätigt D9s alte gegenüber aktueller Zielrolle. Dies sind keine acht verbleibenden Tests in der regulären Suite. Die fünf temporären Quelldateien wurden entfernt; alle 264 ursprünglichen Dateien waren danach SHA-256-identisch. Die wiederhergestellte Suite und Bereinigung der temporären Buildklassen sind unter Tests dokumentiert. U8/U9 bleiben statisch beziehungsweise primärquellenbasiert; ein physischer Android-Test wurde nicht vorgetäuscht.

Nicht als neue bestätigte Defekte aufgenommen wurden ein hypothetischer ungültiger Service-Start hinter einem legitimen Ersatzstart, ungeklärte Username-/Suchformate, unaufgerufene OAuth-Refreshrennen und mögliche Wiederanmeldung desselben Tokens während alter Logoutantwort. Dafür fehlen entweder Produktionsreichweite oder vollständige Serverbelege. Ein bestehender Feed könnte nach Check-in-Erstellung gezielt aktualisiert werden; dies bleibt eine getrennte Konsistenzverbesserung. Release, Sicherheits-/Backupgrenzen und externe Parser lieferten keinen neuen bestätigten Befund.

Aktualisiert wurden elf bestehende Seiten: entwicklung/main-review-2026-10-06, entwicklung/tests, index, offene-fragen, api/traewelling-kompatibilitaet, module/gps-zeiten, module/trip-tracking, module/status-detail, module/feed, module/user-profile und module/checkin. Gründe sind die neuen belegten Grenzen, getrennten Prüfnachweise und der aktualisierte Quellstand. Keine neue Seite oder ADR ist nötig, weil keine Implementierungsentscheidung getroffen wurde. Zusätzlich wurden Auth/PKCE, Secrets, Build/Deployment, Schemas, Profile, Notifications, Settings, UserSearch, RideRecognition, Widget, TripProgress, TripChanges, SEV/externe Schnittstellen sowie UI Screens/Komponenten und die früheren ADRs gegengeprüft; dort entsteht kein neuer eigener Vertrag. Alle 60 Seiten bleiben auf reale relative Linkziele und abschließende verwandte Seiten geprüft. Offene Code-TODOs sind G8–G10/D9–D11/U8–U9; Geräte-, TalkBack-, Backup-Restore- und signierte Release-Nachweise bleiben getrennt.

Der Ausgangsstand wurde vollständig abgeglichen: Alle 264 Blobs und Dateimodi entsprechen Main 4f9cfd2 und Tree 1ea274650b2a8bc676d3f2ae516ad70bd52239bb. Die lokale Checkpoint-Historie unterscheidet sich; veröffentlicht wird ausschließlich auf dem echten Remote-Main-Elterncommit. Es gibt keine Bibliotheks-, Endpunkt-, Datenbank- oder Releaseworkflowänderung.

Befund	Eingebaute Korrektur	Dauerhafte Prüfung
D9	Bestätigte Contentrevision für aktive Status-/Halt-/Routebasis, erneute Prüfung nach Suspensionen und geordnete Zielansage/Completion/Cachewrites; Contentcommit invalidiert die passende alte persistente Basis.	ActiveTripStatusBridgeTest, StatusMutationRepositoryTest, AuthSessionTest
G8	Kumulierte native Chainage auf unveränderter Formbasis plus frisches gerichtetes Paar; Qualitäts-, Gap-, Sprung- und Formwechsel starten Belege neu.	GpsOrderedDepartureRegressionTest
G9	Ausstehende physische Abfahrt bleibt über den exakt geordneten Nahhaltübergang erhalten, bis ein kompatibler Ausfahrtsfix sie belegt.	GpsOrderedDepartureRegressionTest
G10	Physische Ereignisbeobachtung läuft unabhängig von nullable Folgeankunft und zeitlicher Forecastzulässigkeit; ETA-Ablehnung bleibt erhalten.	GpsOrderedDepartureRegressionTest
D10	Aktueller Tab-/Seitenabruf wird nach Mutation oder lokalem Likeabschluss neu gestartet; Invalidated verlangt weiterhin Seite 1.	FeedTabSwitchLikeTest, FeedControllerTest, FeedLikeOrderingTest
D11	Beziehungsrevision schützt bestätigtes Follow/Unfollow/Privatanfrage vor älteren GETs, erhält andere neue Profilfelder und spätere GET-Autorität.	UserProfileFollowOrderingTest
U8	Herkunft der Zielauswahl entscheidet zwischen Stationssuche/Erkennung und tatsächlich geladener Abfahrtsliste.	CheckInBackNavigationTest
U9	Sichtbare Check-in-Page übernimmt normale Schritte; sichtbarer Main-Eintrag sperrt offene Erstellung auch nach Tabwechsel. Live-VM-Guard schützt den schnellen Back vor Recomposition.	CheckInNavigationGuardTest, suspendierter POST-/PUT-Test und statischer Composeabgleich

Die fachfremde Gegenprüfung bestätigte und schloss zusätzlich folgende konkrete Fälle:

• Updated/Deleted müssen eine erste Tabladung oder Pagination ebenso wie LikeChanged erhalten. Bestätigte Likeabsicht darf nicht durch ein verspätetes eigenes Event vor einer alten Vollstatusantwort verloren gehen.
• Zurück aus normalen Abfahrten erhält die bekannte gültige Station als Suchergebnis. Ein zurückbehaltener Stationsname mit geleerten Ergebnissen darf keine unbelegte „Kein Bahnhof gefunden“-Anzeige erzeugen.
• Ein begrenztes Contentledger darf Likes nicht über einen Konto-Feedepoch zur aktiven Fahrtänderung erklären. Verifizierte Statusbaselines und konservative Eviktion trennen diese Fälle.
• Bestätigter Ziel-PUT, Prozessneustart vor dem nächsten Tick und Offline-Start dürfen nicht regulär den alten persistenten Zielcache zurückholen. Commitinvalidierung und geordnete JSON-Schreibvorgänge schützen die passende Sitzung/Status-ID, während die aktive ID erhalten bleibt. Ein lokaler Speicherfehler ist ausdrücklich keine prozessübergreifende RAM-Garantie.
• Nach Check-in-Erstellung kann eine getrennte Zeitkorrektur bestätigen, während StatusDetail noch Halte lädt. StatusDetailRead trägt die Revision bis nach diesem zweiten Endpoint, lädt höchstens zweimal neu und publiziert keinen alten Zeitstatus. Haltefehler und Sitzungs-Cancellation bleiben getrennt.

Sechs unabhängige Sichten untersuchten GPS/Geometrie/ETA, Android-Service/Lifecycle/Audio, Daten/Auth/API/Cache, UI/Navigation/Zugänglichkeit, Release/Sicherheit und übergreifende Integration. Die finalen Quell-/Regressionabgleiche fanden keinen weiteren bestätigten erreichbaren Codebefund. Root prüfte die Änderungen, Dateibasis, Upstream und automatischen Berichte nochmals. Ein grüner Codevertrag beweist keine reale Android-Fahrt, System-Backzustellung oder OEM-Audiozustellung.

62 dauerhafte Android-Regressionen ergänzen die bisherige Suite: GPS elf, Feed/Follow siebzehn, Check-in neun, Service/Repository/Preferences zwanzig und Detailabruf fünf. Eine alte Feed-Testfixture verwendete dieselbe alte Antwort auch für den neu gestarteten post-Commit-GET; der erste 788-Test-Lauf fand genau diese eine Assertion. Die korrigierte Fixture trennt beide Antworten, erhält den alten Schutzassert und prüft den neuen Server-Likecount. Die endgültigen tatsächlich ausgeführten Gesamtprüfungen stehen unter Tests. Es gab keine echten Kontotokens, Träwelling-Schreibtests, signierte Veröffentlichung oder Geräteausführung.

Alle 61 Wiki-Seiten werden auf relative echte Linkziele und abschließende verwandte Seiten geprüft. Aktualisiert sind 15 bestehende Seiten: api/traewelling-kompatibilitaet, architektur/datenfluss, architektur/entscheidungen, entscheidungen/README, entwicklung/main-review-2026-10-06, entwicklung/tests, index, module/checkin, module/feed, module/gps-zeiten, module/status-detail, module/trip-tracking, module/user-profile, offene-fragen und ui/screens. Neu ist die ADR aktive Fahrt und Beobachtungen, weil Revision, Persistenz, physische Ereignisse und Navigationsbesitzer neue Architekturentscheidungen bilden. Auth/PKCE, Secrets, Build/Deployment, Schemas/Datenbank, Notifications, Profile, Settings, UserSearch, RideRecognition, Widget/TripProgress/TripChanges, SEV/externe Schnittstellen, UI-Komponenten/Theme und frühere ADRs wurden zusätzlich gegengeprüft; ihre eigenen Verträge brauchen keine weitere Änderung. Offene TODOs betreffen Geräte-/TalkBack-/Backup-Restore-/signierte Release-Nachweise und optionale Ausbauten, keine der acht beauftragten Korrekturen.

• Unveränderte Notification-/Widget-Payloads unterdrücken. Der Service sendet sie derzeit bei jedem 10-Sekunden-Tick und GPS-Update bis alle drei Sekunden erneut; GPS-/Ansagefrequenz muss hierfür nicht sinken. Kein Akkugewinn wurde gemessen.
• Eine Diagnoseansicht für letzte Fixzeit, Genauigkeit, tatsächliche Geometrie-/Zeitquelle und TTS-/Registrierungszustand ergänzen. Der bestehende Prognose-Ablehnungsgrund ist ein Ausgangspunkt; eine automatisch gespeicherte Geräte-GPS-Historie ist damit nicht beschlossen.
• Virtuelle Coroutine-Requestprüfungen für Meldungen und Feed sowie Editor-Anfangssnapshot-Regressionen sind jetzt ergänzt. Instrumentierte Compose-/Service-/Permission-/TTS-Prüfungen bleiben sinnvolle eigene Erweiterungen.
• Nach stabiler Laufzeit Release-Verkleinerung durch R8/Resource-Shrinking prüfen, einschließlich Gson-/Room-/Reflexionsverträglichkeit. Aktuelle unsignierte Release-APK: ungefähr 16,3 MB. Kein neuer gemessener Ressourcenblocker wurde gefunden.
• Bekannte UI-Lücken bleiben OAuth-Anbindung/Erneuerung, Sichtbarkeitsauswahl und Meldungsnavigation; diese sind schon dokumentiert und keine neue Regression der Bibliotheksmigration.
• Gewöhnliche TTS-Ansagen gegen eine Engine ohne Terminalcallback mit begrenztem Watchdog absichern; Init- und Zielwartefrist ersetzen diesen Queuefall nicht. Widget-Systemupdates könnten sofort den vorhandenen RAM-Snapshot statt kurz die Defaultanzeige übernehmen. Beides sind Robustheitsideen ohne Gerätebeleg.
• Vor OAuth-Anbindung parallele Refreshversuche zusammenführen: Zwei Aufrufe mit demselben rotierenden Refresh-Token können bei invalid_grant vor der erfolgreichen Antwort die Sitzung verlieren. Der Helfer hat aktuell keinen Produktionsaufrufer; dies ist kein belegter Fehler des erreichbaren manuellen Logins.
• Release- und Wiki-Actions an geprüfte vollständige Commit-SHAs binden; derzeit stehen darunter veränderliche Tags und newrelic/wiki-sync-action@main. GitHub-Empfehlung. R8-Optimierung gemäß Android-Dokumentation gesondert validieren, statt pauschal aktuelle kompatible Bibliothekspins anzuheben.
• Dunkle Textakzente, große Schrift und TalkBack systematisch prüfen. Die tatsächliche dunkle Primaryfarbe ist IndigoLight; unter den aktuell verwendeten Grundflächen ergeben sich für diese kleine Textfarbe rechnerisch nur 2,370:1 beziehungsweise auf AMOLED 2,985:1. Keine reale Bildschirmmessung wurde durchgeführt.

• Die historischen 16 Codebefunde sind korrigiert und gezielt abgesichert. Keine Schutzgrenze wurde zugunsten alter unrealistischer Testpositionen gelockert.
• Alle zwölf zusätzlichen Befunde G5–G7, D4–D8, U5–U7 und R4 sowie konkret bestätigte Folgefälle sind korrigiert. Die erneute Gegenprüfung ist Bestandteil dieses Umsetzungsdurchlaufs; reine und praktische Prüfgrenzen bleiben getrennt.
• Alle acht zusätzlichen Befunde und die konkret bestätigten Folgefälle sind korrigiert und dauerhaft abgesichert. Historische Fehlerproben oben bleiben als Ausgangsnachweis erhalten; der aktuelle Umsetzungs-/Vollscanstand steht im neuen Abschnitt.
• TODO: System-/Compose-/Backup-Restore-Prüfungen und ersten neuen signierten Release ergänzen; die optionalen Ausbauideen sind keine verbleibenden Codebefunde dieses Reviews.
• TODO: Reale GPS-/ETA-Güte, Samsung-Sperrbildschirm, Display-aus-/Doze-/Audiozustellung und Ressourcenverbrauch weiterhin auf einem Gerät prüfen. Der Review liefert hierfür keine Garantie.

• Tests
• Deployment
• GPS-Zeiten
• TripTracking
• StatusDetail
• Check-in
• Notifications
• Secrets und Sicherheit
• Offene Fragen