# Offene Fragen

## Zweck

Sammlung von offenen Punkten, Unsicherheiten und Annahmen im Projekt.

## Offene Punkte

- G8–G10/D9–D11/U8–U9 des [weiteren Main-Nachreviews](./entwicklung/main-review-2026-10-06.md#weiterer-nachreview-von-main-443d6e1) sind vollständig korrigiert und erneut aus sechs unabhängigen Sichten plus Root geprüft. Die dabei konkret bestätigten Lade-, Zurück-, Revision-/Like-/Persistenz- und Detailabruf-Ränder sind ebenfalls geschlossen. Es bleiben die getrennten praktischen Nachweise unten, keine dieser acht offenen Codekorrekturen.
- Die zwölf zusätzlichen Befunde G5–G7, D4–D8, U5–U7 und R4 des [Nachreviews](./entwicklung/main-review-2026-10-06.md) sind korrigiert. Dauerhafte Regressionen und eine erneute unabhängige Gegenprüfung ergänzen die historischen 16 Korrekturen. Geräte-, TalkBack-, Restore- und signierte Releaseprüfungen bleiben eigene praktische Nachweise.
- Die historischen 16 Befunde des ursprünglichen [Main-Reviews](./entwicklung/main-review-2026-10-06.md) sind im Code korrigiert und mit dauerhaften Regressionen ergänzt. TODO: FLP-/TTS-Wiederanlauf, Uhrsprünge, Backup-/Geräteübertragung und der erste neue signierte Release bleiben praktische Systemprüfungen. Die optionalen Ausbauideen des Reviews sind getrennte spätere Aufgaben.
- TODO: Die Session-/Consumer-Korrekturen des Main-Audits vom 06.10.2026 auf dem Gerät prüfen: Login während verspäteter Antwort, Logout und erneuter Login mit gleichem Token, Server-/Kontowechsel, Rotation, Feed-/Profil-/Suchwechsel, schnell wechselnde Check-in-Auswahl, doppelte Bestätigung und gleichzeitig aktualisierte Lesemarkierungen. Der kontogetrennte Room-Cache darf bei Authfehler oder Abbruch keine alte private Seite anzeigen; eine gültige leere Seite muss ihren Cache ersetzen. OAuth-Browser-Login bleibt unabhängig davon unangebunden. [Auth](./module/auth.md), [Feed](./module/feed.md) und [Tests](./entwicklung/tests.md) beschreiben die bestätigten Quellkorrekturen und deren Prüfgrenzen.
- TODO: Den defensiven [Foreground-Service-Timeout](./module/trip-tracking.md) auf einem Android-15+-Testgerät mit ausdrücklich aktivierter Kompatibilitätsgrenze prüfen: synchrones Entfernen von Jobs, GPS, Audiofokus und WakeLock, zurückgesetzte Anzeigen sowie erhaltener Fahrtcache für sichtbaren Wiederanlauf. Das derzeitige Target 34 unterliegt regulär noch nicht dem ab Target 35 geltenden `dataSync`-Budget; ein tatsächlicher Budgetabsturz des Nutzerbuilds ist nicht bewiesen. [Widget](./module/widget.md)-Systemupdates müssen mit nicht exportiertem Receiver weiter funktionieren, fremde benutzerdefinierte Updates ausbleiben.
- TODO: Die verschärften [SEV-Fristen und Richtungen](./module/sev-haltestellen.md) bei Ablauf einer Sonderrichtung, zusätzlichen `ab`-/`bis`-Hinweisen und mehrdeutigen Fahrtgrenzen vor Ort prüfen. Fehlender Beleg darf keinen späteren Gegenrichtungspunkt auswählen oder öffentliche Anfragen außerhalb des eigenen eindeutigen Check-ins auslösen. Die heuristische HTML-/Richtungszuordnung ersetzt keine linienbezogene Maßnahmendatenbank.
- TODO: Den Tunnelbericht Essen Hbf → Bismarckplatz → Savignystraße mit mehreren Halten ohne GPS und Signalrückkehr am späteren Halt auf dem Gerät prüfen: [Besuchswiederverankerung](./module/trip-tracking.md), [Zeitprognose](./module/gps-zeiten.md), [Timeline](./module/status-detail.md), alte wartende Ansagen und Zielabschluss müssen dieselbe neue Basis verwenden. Im alten Code konnten ein geschützter etablierter Cursor und die nur auf einen Folgehalt begrenzte Lückenerkennung eine erneute Zuordnung verhindern. Die konkrete Fix-/Audiofolge des Nutzerberichts ist nicht aufgezeichnet. Geeignete native Formen können inzwischen die gerade Bahn-/Tramprojektion ersetzen, belegen aber keinen aktuellen amtlichen Fahrtweg. Mehrdeutige spätere Halte, Rundfahrten, stationäres Wiederfinden, Signalflattern und restaurierter Fahrtcache benötigen eigene Geräteprüfung.

- TODO: Die [native Bahn-/Tram-Geometrie](./entscheidungen/2026-10-06-native-streckenverlaeufe.md) auf Kurven, parallelen Gleisen, Rundfahrten, Umleitungen und langen Abschnitten prüfen: eindeutige Besuchsbindung, frische Quellenanzeige unabhängig von GPS-ETA, Form-/Sessionwechsel, harter Ablauf ohne Netz und konservativer Geraden-/API-Rückfall. Träwelling mischt Teilformen und Stationssehnen ohne Herkunft je Abschnitt; eine geometrisch akzeptierte Form ist keine amtliche Gleisgarantie. Quellenqualität sowie Laufzeit, Speicher- und Netzwerkverbrauch auf weiteren Servern bleiben offen. Gerätefixes werden für den nativen Abruf nicht übertragen.
- TODO: Die [Bibliotheksmigration](./entwicklung/build.md) zusätzlich auf dem Gerät prüfen: Coil-3-Profilbilder und HTTP-Cacheverhalten, Material-3-Pull-to-refresh, TTS-Einstellungen, Ortsabfrage und Compose-Layouts. Die Pins bleiben bei SDK 36 und Kotlin 2.3; für künftig höhere API-/AGP-/Kotlin-Versionen müssen AAR-Metadaten und R8-Anforderungen neu geprüft werden. Automatisierter Buildnachweis ersetzt diese Geräteprüfung nicht.

- TODO: Die automatische [SEV-Ergänzung](./module/sev-haltestellen.md) der RE1-Busfahrt Essen → Mülheim → Duisburg vor Ort prüfen: physischer Einstieg, Richtungsbeleg aus der vollständigen API-Fahrt, Maßnahmenende, GPS-Ausfall und Wiederanlauf mit Cache. Die App lädt öffentliche bahnhof.de-Kartendaten ohne RIS::Stations-Zugang und übernimmt ausschließlich eindeutige aktuelle Punkte in die lokale GPS-Projektion. Unklar: Tatsächliche API-Koordinaten dieser Fahrt und die Ankunftsposition des in Duisburg endenden Busses sind aus dem Screenshot nicht erkennbar. Ohne Richtung bleibt die Position unbestätigt; die zusätzliche Pkw-Straßenprojektion ersetzt keinen fehlenden Ersatzhaltbeleg.
- TODO: Dauerhafte Nutzungsbedingungen, Änderungen der öffentlichen HTML-Struktur, weitere Bahnhofs-Slugs und Richtungsformulierungen sowie Netzwerk-/Akkuverbrauch der [SEV-Quelle](./module/sev-haltestellen.md) prüfen. Die Bus-RE/RB-Erkennung deckt nicht sämtliche Ersatzverkehre ab. Zeitweilige Verlegungen und Sonderfristen müssen neu geprüft werden; `properties.version` ist kein Gültigkeitsintervall. Der Entwicklungs-Beispielabruf bleibt eine Momentaufnahme, kein laufender Aktualisierungsdienst.
- TODO: Den RE1-Busbericht zur Rückfahrt Duisburg → Mülheim → Essen vom 06.10.2026 mit Fix-/Audioverlauf und der neuen [Straßenprojektion](./module/gps-zeiten.md) nachprüfen. Die spätere Aufnahme zeigt `OUTSIDE_CORRIDOR` als damaligen Ablehnungszustand, keinen vollständigen Verlauf, tatsächlichen Busweg oder bestätigte GPS-Abfahrt. Beobachtete Ereignisse müssen auch ohne Zukunftsprognose sichtbar bleiben. Pkw-Routenkandidaten sind keine offiziell bestätigte SEV-Busführung und garantieren keine ETA. Kreuzungen, parallele Straßen, Baustellenumwege, falsche Geometrie und fehlende SEV-Endpunkte beziehungsweise Bewegung dürfen keine unbelegte Abschnittsprognose erzeugen. Netzausfall und Neustart können nur bei verfügbarer gültiger RAM-Geometrie und frischem Beleg weiter prognostiziert werden. Bestätigter Zwischenhalt-Aufenthalt bleibt eine getrennte Planversatzbasis; ohne geeignete lokale Zeit gilt der API-/Plan-Rückfall. Stationsengine, Genauigkeit und 30-Sekunden-Gültigkeit bleiben unverändert.
- TODO: Die [GPS-Prognose auf gemeinsamem SEV-Restweg](./entscheidungen/2026-10-07-sev-gemeinsamer-restweg.md) bei Start/Neustart nach zusammenlaufenden Anfahrtswegen, GPS-Ausfall, parallelen Straßen und Umleitung vor Ort prüfen. Die begrenzte Kandidatenstreuung und automatisierte öffentliche Fixture belegen keine reale ETA-Genauigkeit. Mehrdeutige Schleifen bleiben auch bei früher gebundenem Weg gesperrt.
- TODO: Eignung und Belastung des öffentlichen [FOSSGIS-OSRM-Dienstes](./api/externe-schnittstellen.md) bei wachsender Installation bewerten. Der anonyme Abruf öffentlicher SEV-Endpunktpaare ist auf höchstens den aktuellen Ankunfts- und Folgeabschnitt, am Einstieg die ersten zwei geeigneten Abschnitte, einen Request-Start pro Sekunde je Prozess und begrenzten RAM-Cache beschränkt; dies ersetzt keine anbieterweite Kapazitätsplanung. Attribution und Kartenkorrektur-Link prüfen. Für exakt bekannte Buswege wäre eine verlässliche Quelle der konkreten Maßnahme nötig.
- TODO: Bestehende UI-Lücken abschließen: [OAuth-Anmeldung und Token-Erneuerung](./module/auth-pkce.md) anbinden, Sichtbarkeitsauswahl beim [Check-in](./module/checkin.md) und [Bearbeiten](./module/status-detail.md) anbieten sowie [Meldungsnavigation](./module/notifications.md) ergänzen. Profilkarten deaktivieren ihre nicht angebundene Herz-Aktion inzwischen ausdrücklich; Like/Unlike bleibt im Feed verfügbar. Diese Punkte sind Bestandsgrenzen, keine beschlossene Feature-Roadmap.
- TODO: Bei Bedarf die am 05.10.2026 erfolgreiche [Live-GET-Prüfung](./entwicklung/tests.md) als wiederholbare Integrationstests einrichten. Falls echte API-Tokens nötig sind, müssen diese lokal und nicht versioniert bereitgestellt werden.
- TODO: Neue Träwelling-Changelog-Einträge regelmäßig mit dem tatsächlich eingesetzten Routen- und Ressourcenvertrag abgleichen. Der gepinnte Prüfstand ist Upstream `develop`-Commit `4d602796da8409017314cc771b1127d169155f02`. Der erste erneute Abruf am 06.10. lieferte keinen sicheren SHA; ein späterer Commitvergleich bestätigte `develop` als identisch. Die getrennten Nachweise stehen unter [API-Kompatibilität](./api/traewelling-kompatibilitaet.md).
- TODO: Nach dem Nutzerbericht zu `1.7.0` den Übergang Maubisstraße → Rathaus mit dem korrigierten [GPS-Stationsalarm](./module/trip-tracking.md) erneut auf einer echten Fahrt prüfen. Unklar: Die genaue Ursache der fehlenden Rathaus-Ansage ist ohne Standort-/Audioverlauf nicht bewiesen. Weitere Prüfungen umfassen Tunnel, nahe Halte, Vorbeifahrt und Rundfahrten; Luftlinie ist keine genaue Ankunftsprognose.
- TODO: Auf Android-Geräten präzise/grobe/entzogene Freigabe, ausgeschaltete Ortung, Display-aus-Betrieb, `START_STICKY`, Wiederanlauf mit Cache und Audiofokus prüfen. Hier steht kein physisches Testgerät zur Verfügung; der Fahrplan-Rückfall beendet die Fahrt bewusst nicht automatisch.
- TODO: Nach dem Nutzerbericht vom 06.10.2026 ausbleibende Ansagen bei ausgeschaltetem Display mit der [Display-aus-/Doze-Matrix](./entwicklung/tests.md) auf Samsung S26 Ultra prüfen: mindestens 30 Minuten, erzwungenes Doze auf einem Testgerät, gewährte/abgelehnte Akku-Ausnahme, Energiesparmodus und Herstellerbeschränkungen. Standort-, API-, Service- und Audioverlauf getrennt erfassen; die konkrete Ursache des Berichts ist bislang nicht bewiesen. Nach Beenden, Logout und Service-Zerstörung darf kein CPU-WakeLock zurückbleiben. Android-Ausnahme und WakeLock ersetzen keinen Geräte-/Akkuverbrauchsnachweis und können Nutzer-Force-Stop nicht aufheben.
- TODO: Die [Status-Timeline](./module/status-detail.md) mit großer Schrift und mehrzeiligen Zeiten visuell prüfen: genau eine Besuchsmarkierung, durchgehende Linie, konsistente Haltepunkte und keine Fortschrittsübernahme aus einer anderen Fahrt.
- TODO: Den S28-Nutzerbericht vom 06.10.2026 zu häufigem Wechsel zwischen `GPS-Schätzung` und `API-Echtzeit` sowie einer erst nach der Abfahrt gesprochenen Einstiegsansage erneut auf einer Fahrt prüfen. Die spätere Bildschirmaufnahme zeigt Quellenwechsel bei eingeschaltetem Display, aber keine Standort- oder Audiodaten. Die [UI-Uhrkorrektur](./module/status-detail.md) muss frische Fixes zwischen sekündlichen UI-Ticks sofort anhand der aktuellen Zeit prüfen; tatsächlich zukünftige und abgelaufene Daten bleiben ungültig. Die [GPS-Zeiten](./module/gps-zeiten.md) halten eine bereits belegte Prognose nur bei passenden frischen Folgefixes bis zum ursprünglichen Ablauf; die [Stationsansage](./module/trip-tracking.md) muss bei bestätigtem Warten vor der gültigen Abfahrt erfolgen und nach beginnender Abfahrt ausbleiben. Eine lange Änderungsansage unmittelbar vor Abfahrt muss den Einstiegsversuch nur innerhalb des weiter gültigen Wartefensters verzögern; nach Losfahren darf kein alter Hinweis nachgereicht werden. Prognosegüte bei Verfrühung, Verspätung, längerem Halt, Tunnel, Kurven und Wiederkehr des Signals bleibt offen. Header, Halte, Widget und Samsung-Sperrbildschirm müssen dieselbe geeignete Zeitquelle verwenden. Die konservative räumliche Interpolation ist kein Nachweis der tatsächlichen Prognosegüte.

- TODO: Die [Fahrterkennung](./module/ride-recognition.md) auf realen Fahrten einschließlich paralleler Linien, Kurven, GPS-Lücken, Logout und aktiver Fahrt prüfen. Android-Freigaben, tatsächliche Erkennungsgüte sowie Akku-/API-Verbrauch sind keine Ergebnisse der reinen Engine-Tests.
- TODO: [Änderungshinweise](./module/trip-changes.md) mit realen API-Änderungen, deaktivierten Benachrichtigungen und konkurrierenden TTS-Ansagen prüfen. Ohne Providerwerte gibt es keine Änderungserklärung.
- TODO: [Reisefortschritt](./module/trip-progress.md) auf Android API 35, 36 und 36.1 sowie Samsung prüfen: System-/OEM-Promotion, große Schrift, Wegwischen, kalte/warme Navigation und ausgeschaltete Sperrbildschirmdetails. Live Updates bleiben vom System und Nutzer abhängig.

## Live-Datenprüfung vom 10.10.2026

Die [anonyme DBF-/IRIS-Ergänzung vom 10.10.2026](./api/live-datenquellen.md) liefert zusätzliche Bahnwerte ohne Registrierung. Abrufalter, Quellenkennzeichnung und Soll-/Ist-Gleisvergleich sind umgesetzt. Offen bleiben:

- TODO: Auf echten Fahrten Gleiswechsel, Verspätungen und Haltausfälle mit Träwelling vergleichen; ein erfolgreicher öffentlicher Tafelabruf belegt keine Vollständigkeit oder garantierte höhere Aktualität.
- TODO: DBF-Dienstlast bei mehreren Installationen prüfen. Der Client begrenzt Request-Starts je Prozess auf zehn/min und einen je Bahnhof/min; keine flottenweite Quote ist nachgewiesen.
- Unklar: Alter der zugrunde liegenden Providerprognosen. Die Anzeige belegt den Clientabruf, keine Änderung bei DB beziehungsweise Transitous. Version 3 erlaubt keinen belastbaren Import separater Teilausfälle beziehungsweise deren Rücknahme.

## Verwandte Seiten

- [Live-Datenquellen](./api/live-datenquellen.md)

- [Index](./Home.md)
- [Tests](./entwicklung/tests.md)
- [TripTracking](./module/trip-tracking.md)
- [GPS-Zeiten](./module/gps-zeiten.md)
- [SEV-Ersatzhaltestellen](./module/sev-haltestellen.md)
- [StatusDetail](./module/status-detail.md)
- [Secrets und Sicherheit](./konfiguration/secrets-und-sicherheit.md)
- [Fahrterkennung](./module/ride-recognition.md)
- [Fahrtänderungen](./module/trip-changes.md)
- [Reisefortschritt](./module/trip-progress.md)