offene fragen - shedowe19/routely GitHub Wiki

Offene Fragen

Zweck

Sammlung von offenen Punkten, Unsicherheiten und Annahmen im Projekt.

Offene Punkte

  • G8–G10/D9–D11/U8–U9 des weiteren Main-Nachreviews 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 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 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, Feed und Tests beschreiben die bestätigten Quellkorrekturen und deren Prüfgrenzen.

  • TODO: Den defensiven Foreground-Service-Timeout 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-Systemupdates müssen mit nicht exportiertem Receiver weiter funktionieren, fremde benutzerdefinierte Updates ausbleiben.

  • TODO: Die verschärften SEV-Fristen und Richtungen 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, Zeitprognose, Timeline, 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 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 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 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 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 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 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 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 anbinden, Sichtbarkeitsauswahl beim Check-in und Bearbeiten anbieten sowie Meldungsnavigation 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 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.

  • TODO: Nach dem Nutzerbericht zu 1.7.0 den Übergang Maubisstraße → Rathaus mit dem korrigierten GPS-Stationsalarm 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 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 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 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 halten eine bereits belegte Prognose nur bei passenden frischen Folgefixes bis zum ursprünglichen Ablauf; die Stationsansage 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 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 mit realen API-Änderungen, deaktivierten Benachrichtigungen und konkurrierenden TTS-Ansagen prüfen. Ohne Providerwerte gibt es keine Änderungserklärung.

  • TODO: Reisefortschritt 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 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