AKTUELL: v6.8.4 · ORTSSUCHE MIT KONTEXT · 19.10.2026
================================================================
Build: 20261019-place-context-v6-8-4. Keine Live-Installation.

REPRODUZIERTE URSACHE
Die öffentlich abgerufene journey.js entsprach dem v6.8.3-Paket. Bei „Berlin“
lieferte die Transitous-Suche neben Berliner Bahnhöfen gleichnamige Halte in
Kolumbien, Spanien und Frankreich. Photon lieferte Berlin/Deutschland und
mehrere US-Orte. Die bisherige Namenssortierung stellte exakte Schreibweisen
„Berlín“/„BERLIN“ vor „Berlin Hbf“. Einheitliche Untertitel „Haltestelle /
Bahnhof“ unterschlugen die Unterscheidung nach Ort und Land. Allgemeines
Button-CSS machte die Liste zusätzlich optisch schwer.

KORREKTUR
- Gemeinsame Aufbereitung in place-results.js für Reiseplanung und Nähe-Suche.
  Treffer zeigen Art, vorhandenen Ort/PLZ und Land. Originalnamen bleiben erhalten.
- Der erste von Photon priorisierte Stadttreffer mit passendem Namen dient als
  räumlicher Bezug: nahe Bahnhöfe vor weit entfernten Namensvettern. Dies ist
  eine Sortierheuristik, keine verbindliche Erkennung der beabsichtigten Stadt.
  Keine automatische Auswahl und kein harter Länder-/Koordinatenfilter.
- Gleiche IDs innerhalb einer Ergebnisart werden dedupliziert. Unterschiedliche
  Haltestellen-IDs und entfernte gleichnamige Orte bleiben erhalten.
- stopId wird nur aus tatsächlichen STOP-Treffern bzw. älteren Stop-Datensätzen
  übernommen; generische PLACE-Treffer werden nicht als Haltestellen ausgegeben.
- Flache, zweizeilige Suchliste mit begrenzter Höhe und lesbarem Kontext.
  Mobile Navigation während offener Vorschläge ausgeblendet; keine überdeckten
  Suchtreffer. Cache-Versionen der betroffenen Dateien erneuert.
- APIs, Zeitberechnung, Kartenpositionen und gespeicherte Reisen unverändert.

PRÜFUNG
730 JavaScript-Assertions bestanden: die 703 bisherigen plus 27 neue Fälle zu
Berlin/Amsterdam, Namensvettern, Kontext, Koordinaten, IDs und Deduplizierung.
25 JavaScript-Dateien mit Syntax-/Importprüfung. 100 PHP-Assertions bestanden.
419 Browser-Assertions in fünf Viewports und zwei Themes: neue Berlin-Suche,
Stadt/Bahnhof-Reihenfolge, Länderangaben, flache Zeilen, Navigation ausgeblendet,
richtige toStopId beim Planen, Escape und die bisherigen Karten-/Fahrplanfälle.
PHP 8.2.33 WASM, Chromium 153, kontrollierte Netzwerk-/GPS-Testdaten.
Keine unbehandelten Browser-Ausnahmen. Testfixture enthält öffentliche
Ortsangaben mit synthetischen IDs, keinen persönlichen Standortverlauf.

GRENZEN
Kein echter Android-/iPhone- oder Strato-Test. Keine Garantie, dass externe
Geocoder immer die beabsichtigte Stadt zuerst liefern. Bei Mehrdeutigkeit Land
und Ort in den Vorschlägen prüfen oder genauer suchen. Frühere Berichte folgen
unverändert. Fehlende Betreiber-Echtzeitdaten bleiben eine separate Grenze.

AKTUELL: v6.8.3 · MEHR PLATZ IM HANDYFAHRPLAN · 19.10.2026
================================================================
Build: 20261019-timetable-space-v6-8-3. Vollständiges Paket, nicht installiert.

BEHOBEN
Der mobile Fahrplan hatte durch zwei Steuerzeilen, großen Kopf, Statuschips
und dauerhaft sichtbare Teilen-Aktionen zu wenig Platz für die Haltestellen.
- Höhensteuerung und Schließen in einer 44-px-Bedienzeile; doppelten
  Schließen-Knopf im mobilen Kopf entfernt. Ziehen/Pfeiltasten bleiben erhalten.
- Kopf und Status kompakter, Zähler „Halte“ kürzer. Zeitqualität und Linienfolge
  bleiben sichtbar. Die Schriftgröße der Haltestellen wurde nicht verkleinert.
- Fortschritt und ausführliche Fahrthinweise am Handy aufklappbar. Kurzer
  Hinweis auf geschätzte Positionen bzw. Planzeiten bleibt sichtbar.
  Störungsmeldungen und Weiterfahrthinweise am jeweiligen Halt bleiben direkt
  in der Liste. Desktop zeigt die ausführlichen Inhalte zunächst geöffnet.
- Teilen, Live-Teilen, Fahrzeug auf Karte und Abrufinformationen über
  „Aktionen & Daten“ erreichbar; auch im Querformat. Beim erneuten Öffnen
  des Fahrplans werden mobile Zusatzbereiche wieder eingeklappt.

VERIFIZIERT
703 bestehende JavaScript-Assertions und 100 PHP-Assertions bestanden.
311 Browser-Assertions: fünf Viewports und beide Themes; 22 synthetische Halte,
volle/scrollbare Listenfläche, letzte Haltestelle erreichbar, mindestens drei
vollständige Halte sofort sichtbar im geprüften Hochformat (einer im Querformat),
Fortschritt/Fahrthinweise aufklappbar, Teilen-Aktionen weiterhin erreichbar,
Desktop-Aktionen sichtbar. Keine unbehandelten Browserfehler.
PHP 8.2.33 WASM, Chromium 153; Daten/GPS kontrollierte Fixtures. Keine echten
Handys oder Strato-Laufzeit geprüft. Texte/Schriftvergrößerung und individuelle
Browserleisten können die sichtbare Anzahl ändern. Fehlende Betreiberprognosen
bleiben eine Datenquellengrenze. Frühere Prüfberichte folgen unverändert.

AKTUELL: v6.8.2 · KOMPAKTE HANDYKARTE · 19.10.2026
================================================================
Build: 20261019-compact-map-v6-8-2. Vollständiges Paket, nicht live installiert.
Anlass: Handyaufnahme mit überlagerten Filtern, Zoomhinweis und Vollbildknopf.

ÄNDERUNGEN
- Favoriten- und Echtzeitfilter hinter aufklappbarem „Filter“-Knopf.
  Aktive Filter sind an der Anzahl sichtbar; Einstellungen bleiben erhalten.
- Vollbild-Schließen bleibt separat und jederzeit erreichbar.
- Legende, Zoomhinweis und ausführliche Datenbasis gemeinsam aufklappbar.
  „Positionen geschätzt · Info“ bleibt auch im Vollbild sichtbar.
- Haltestellensymbole am Handy auf 24 bzw. 20 px verkleinert; ihre Position
  bleibt zentriert. Fahrzeugmarker und PLAN/PROGNOSE-Texte bleiben erhalten.
- Escape schließt zuerst ein geöffnetes Kartenmenü, danach das Vollbild.
  Beim Vollbildwechsel schließen die Menüs; Fokus kehrt passend zurück.
- Keine Änderungen an Fahrzeiten, Datenquellen, Liniennetz oder GPS-Logik.

PRÜFUNG
703 JavaScript-Assertions bestanden. 100 PHP-Assertions bestanden (PHP 8.2.33
WebAssembly). 213 Chromium-Assertions bestanden: 320/375/768/812/1280 px,
hell/grün, Hoch-/Querformat, Filterstatus, Auf-/Zuklappen, Legende und Hinweis,
Escape/Fokus und nicht überlappende Vollbild-Bedienelemente. Screenshots intern
geprüft. Netzwerkdaten und GPS simuliert, Kartenkacheln im Test ersetzt.
Reale Handy-, Server- und Fahrtdatenabnahme bleibt offen. Fehlende Echtzeitdaten
und mögliche Überlagerung von Fahrzeugmarkern an identischen Positionen
werden hierdurch nicht behoben. Frühere Berichte folgen unverändert.

AKTUELL: v6.8.1 · ABSCHLIESSENDE LOKALE PRÜFUNG · 19.10.2026
================================================================
Build: 20261019-final-review-v6-8-1. Vollständiges Paket, nicht live installiert.

BEHOBENE BEFUNDE
- live-fahrt.php: falsche Leaflet-CSS-Prüfsumme korrigiert. Die Prüfung
  erfolgt gegen die tatsächlichen Leaflet-1.9.4-Dateien (CSS und JS).
- Mobile Navigation: „Abfahrt“ gekürzt und Spalten/Innenabstand angepasst;
  alle vier Texte bei 320 px ohne Zeilenumbruch, Schriftgröße bleibt 14 px.
- Reiseplanung: ungültige Namen/Labels als Array oder Objekt werden ignoriert;
  sie verursachten vorher PHP-Warnungen. Gültige Texte bleiben erhalten.
- Cache-Versionen für geänderte mobile Dateien und Haupt-Build aktualisiert.

PRÜFERGEBNISSE: BESTANDEN
- 703 vorhandene JavaScript-Assertions einschließlich Kontrast, Merkliste,
  GPS-Lebenszyklus, Linienwechsel, Verspätungs-/Haltezeitlogik und Datenbasis.
- 100 zusätzliche PHP-Assertions in echter PHP-8.2.33-WebAssembly-Laufzeit:
  Syntax aller 31 PHP-Dateien, Rendering von 10 Seiten, sichere Vorbelegung,
  fehlerhafte Eingaben, API-Validierung, R49/R81-Durchbindung und 8 SRI-Abgleiche.
- 103 Browser-Assertions in Chromium 153: fünf Viewports (320x740, 375x812,
  768x1024, 812x375, 1280x900), jeweils hell und grün. PLAN/PROGNOSE,
  Kartenfilter, Vollbildhinweis, Standort-/Näheablauf, Navigation und Überbreite.
  Keine unbehandelten JavaScript-Ausnahmen. Screenshots intern gesichtet.
- Geprüfter Mindestkontrast der aktiven Buttonzustände: 7,86:1.

GRENZEN / OFFENE ABNAHME
Kontrollierte Testdaten und simuliertes GPS; API-Netzwerkgrenze im Test ersetzt.
Kein Test des Strato-Servers, kein echter Android-/iPhone-Test, kein Beleg für
vollständige Betreiberdaten. Fehlende Verspätungsmeldungen bleiben ungelöst;
PLAN-Markierungen sind keine gemessenen Fahrzeugpositionen. Bei identischen
Positionen können Marker/Badges überlagern; Fahrtenliste und Detailansicht nutzen.
Kein rechtliches Gutachten und keine Garantie der Fahrzeiten oder Anschlüsse.
Echte Geräte, Server-Konfiguration, Datenversorgung und praktische Fahrtvergleiche
bleiben vor einer allgemeinen Freigabe zu prüfen. Keine neue DB-/RLG-Anbindung.

NACHVOLLZIEHBARKEIT
Zusätzlicher reproduzierbarer Lauf: tests/runtime-final.cjs und
 tests/RUNTIME-QA.txt. Keine persönlichen Standortmeldungen, API-Snapshots,
Browserbilder, Testlaufzeiten oder node_modules im ausgelieferten Paket.
Ältere Berichte und Testaussagen folgen unverändert als Historie.

AKTUELL: v6.8 · DATENHERKUNFT UND UNSICHERHEIT · 19.10.2026
================================================================
Basis: vollständiges v6.7.1-Paket; öffentlich ausgelieferte app.js beim Abruf
inhaltlich mit dem Paket verglichen. Kein vollständiger neuer Server-Snapshot.
Keine Live-Installation. Build: 20261019-source-confidence-v6-8.

BEFUND UND GRENZE
Praxisabgleich einer R81-Fahrt zeigte wechselnde Abweichungen gegenüber
Planzeiten. Die dazu abgerufene Fahrt lieferte realTime=false, auch im erneuten
Abruf. Ein frischer Abruf ist keine neue Betreibermessung und bestätigt keine
Pünktlichkeit. Keine feste Zusatzverspätung eingeführt und keine persönlichen
Standortmeldungen oder Bewegungsverläufe in dieses öffentliche Paket übernommen.

UMGESETZT
- Sichtbarer Hinweis direkt oberhalb der Karte: Positionen sind Schätzungen;
  ohne Echtzeitmeldung können reale Fahrten mehrere Minuten abweichen.
- Marker mit PLAN / PROGNOSE / VORSCHAU; durch Text statt nur Farbe erkennbar.
  PLAN hat zusätzlich einen gestrichelten Rand. Tooltip erklärt Datenbasis.
- Hinweis auch im Karten-Vollbild: keine Fahrzeug-GPS-Ortung.
- Optionaler lokaler Echtzeit-Kartenfilter: nur Abschnitte mit realTime===true,
  keine Vorschau-Marker. Liniennetz, Haltestellen, Fahrtenlisten, Routen und
  Uhrzeiten unverändert. Ausschalten stellt PLAN-Marker wieder her.
- Abfahrten, Fahrplanfenster und kompakte Schiebeansichten nennen bei fehlender
  Meldung „Verspätung unbekannt“. Reiseplanung und geteilte Fahrten weisen auf
  mögliche Abweichungen hin. Gemeldete Echtzeit bleibt eine Prognose.
- Reisehilfe erklärt Datenalter, Plan/Prognose/Vorschau und Betreiberabgleich.
- Sachliche Beschreibung in Nutzungsbedingungen angepasst; Haftungsklausel
  nicht erweitert. Keine Zusicherung juristischer Rechtssicherheit.
- Entwicklungsziel transparent erwähnt: zusätzliche freigegebene Schnittstellen
  und Austausch, etwa mit RLG oder DB. Keine Zusage oder bestehende neue
  Kooperation behauptet; Wachstum garantiert keinen Datenzugang.
- Cache-Versionen betroffener direkter und transitiver JS-/CSS-Dateien erhöht.

VALIDIERUNG
703 automatisierte Assertions PASS (672 bestehende + 31 neue Prüfungen).
Neue Tests benutzen echte Marker-/Filterfunktionen: Kennzeichnung, strikte
Echtzeitprüfung, Ein-/Ausschalten, vollständige Listen und unveränderte Zeiten.
24 JS-Dateien Syntax/Imports PASS; 31 PHP-Dateien PHP-8.2-Parser PASS.
ZIP-Integrität und lokale Links geprüft. Kein echter PHP-Laufzeittest und keine
visuelle Browser-/Touch-Abnahme. Stand der letzten Geräteabnahme weiter offen.

OFFEN
- Upload und Android/iPhone: Hinweis im normalen und Karten-Vollbild prüfen,
  Filter und Favoriten gemeinsam testen, kleine Schrift/Zoom/Markerüberlappung.
- PHP-Server und echte Datenquelle testen. Betreiber-Echtzeit kann weiterhin
  fehlen oder unzutreffend sein; diese Veröffentlichung repariert keine
  fehlende Quellprognose. Keine GPS-Fahrzeugortung ergänzt.
- Rechtliche Prüfung der öffentlichen Texte bleibt separat offen. Technische
  Hinweise sind kein pauschaler Schutz vor Ansprüchen.
- Vollständige Offline-App, Hintergrundalarme und Betreiberfeeds bleiben offen.
INSTALLATION: vorhandene Konfiguration, Nutzerdaten, Cache und Live-Shares
sichern/erhalten. Nach Upload neu laden. Alle Funktionen aus v6.7.1 enthalten.
Historische Abschnitte und Testhistorie bleiben darunter unverändert erhalten.

AKTUELL: v6.7.1 · BUTTON-KONTRAST · 14.10.2026
============================================================
Basis: vollständiges v6.7-Paket. Keine Live-Installation.
Build: 20261014-button-contrast-v6-7-1.
Befund: Screenshot zeigt aktive „Abfahrten“-Navigation ohne lesbaren Text.
Allgemeine Linkfarbe der travel-help-page war spezifischer als die bisherige
aktive Dock-Regel; dadurch grüne Schrift auf grünem Hintergrund.
Korrektur: spezifische Zustandsregeln mit gepaartem action/action-text für
aktive Navigation, einfache Ansicht, Karten-/Verkehrsmittel-/Linientasten und
aktive Standortanzeige. Standortfreigabe berücksichtigt bestehende wichtige
Hintergrundregel. Kindtexte erben die aktive Schriftfarbe.
Cache-Version des mobilen Styles auf allen fünf Hauptseiten angehoben.
Keine Änderungen an GPS, Routendaten, Timings oder lokaler Speicherung.

VALIDIERUNG: 672 automatisierte Assertions PASS (480 bestehende + 192 neue).
Neue Tests lösen tatsächliche CSS-Deklarationen anhand Selektorspezifität,
Quellreihenfolge und important auf: beide Themes, 375/1024px, normal/hover,
8 aktive Bedienelemente. Minimaler geprüfter Textkontrast: 7,86:1.
Dies ist kein visueller Browser-/Touchtest; reale Handy-Abnahme bleibt offen.
24 JS-Dateien Syntax/Imports und 31 PHP-Dateien PHP-8.2-Parser PASS.
ZIP-Integrität geprüft. PHP-Laufprüfung bleibt offen.
Testhistorie: erster neuer Prüflauf FAIL (Hover überschreibt Hintergrund),
zweiter FAIL (Standortfreigabe überschreibt Textfarbe), nach Korrektur PASS.
Vorherige Testfälle und Schwellenwerte wurden nicht abgeschwächt.
Nach Upload neu laden; Seiten laden mobile-ux.css?v=20261014-v671.
Vorhandene Konfiguration/Nutzerdaten sichern und erhalten.
Historische Dokumentation bleibt darunter unverändert.

AKTUELL: v6.7 · HANDY / GPS-NAEHE / REISEBEGLEITUNG · 14.10.2026
================================================================
STATUS: lokal implementiert und logisch geprüft; keine Live-Installation.
Basis: vollständiges v6.6-Paket inklusive Haltezeitenkorrektur und UX-Roadmap.
BUILD: 20261014-mobile-assist-v6-7

ROADMAP-FORTSCHRITT
UX-19 bis UX-36: im Paket, Live-/Geräteabnahme offen.
UX-36 teilweise: exportierter Offline-Reiseplan vorhanden; vollständig offline
startende App samt sicherem Ressourcen-/Kartenmanagement bleibt offen.
UX-37 offen: Hintergrund-/Ausstiegserinnerungen brauchen verlässliche Tests und
gegebenenfalls Android-App-Anbindung. Kein Alarmversprechen umgesetzt.
UX-38 offen: kein freigegebener Betreiber-Positionsfeed vorhanden. Keine eigene
Trackingbox, kein neuer GPS-Fahrzeugfeed und keine Anfrage an Dritte versendet.

IMPLEMENTIERT
- Drei Einstiege: Nähe-Abfahrten, Reise planen, Merkliste; feste untere Handy-
  Navigation auf Karte, Nähe, Planung, Unterwegs und Nach-Hause-Seite.
- Einfache Ansicht mit größeren Texten/Tasten, lokal wählbar; Navigation bei
  Dialog/Vollbild/erkannter Bildschirmtastatur verborgen. Echte Geräte offen.
- Ungewöhnliche Schul-/E-Wagen-Filter aufklappbar; aktiver Zustand im Summary;
  Linienfilter zurücksetzbar. Soester Grundnetz und Live-Layer unverändert.
- Neue in-der-naehe.php: GPS nur auf Klick oder manuelle Ortswahl. Bis zu drei
  Halte im 2-km-Suchraum, Abfahrten, berechneter Fußweg und gelieferter Verlauf.
  Zeitpuffer 2/5/10 Minuten. Keine positive Einschätzung ohne Fußweg, bei alten
  Abfahrten oder GPS-Genauigkeit schlechter als 100 m. Keine Garantie.
- Neue feste Transitous-Aktionen nearby/walk: Koordinaten validiert, kurze
  Fußwege begrenzt, Rate-Limit; keine dauerhaften Antwortcaches für diese
  Standortanfragen. Kein beliebiger Ziel-URL-Proxy.
- Haltestellen ausdrücklich merken/entfernen (max.12). Letzte Halte nur nach
  freiwilliger Aktivierung (max.8) lokal speichern und separat löschen.
- Reiseplanung: GPS-Start auf Klick; ausgewählte Orte freiwillig lokal merken
  (GPS-Punkte ausgeschlossen); erhaltene Eingaben und Erneut versuchen nach
  Fehlern; letzte entfernte Reise rückgängig machen, ohne andere zu ersetzen.
- Standort/gewählte Orte per explizitem POST in die Reiseplanung übernehmen;
  keine Standortkoordinaten in der Übergabe-URL oder persistentem GPS-Handoff.
- Unterwegs: nächster Schritt LAUT ZEITPLAN, nicht bestätigter Einstieg.
  Anschlussprüfung nach aktueller Fahrtprüfung, inklusive geliefertem Fußweg,
  Reserve, Ausfall und klarer Einschränkung bei fehlendem Umsteigeweg.
- Rückfahrt; vom freiwilligen aktuellen GPS zum gespeicherten Ziel neu planen;
  Zuhause vom eigenen Standort planen; ursprüngliche Reise bleibt erhalten.
- Teilen als Text, private Start-/Zielangaben standardmäßig ausgeschlossen;
  manueller Abschluss mit Rückfahrt/Nähe-Abfahrten, rücknehmbar.
- Offline-HTML-Download des gespeicherten Plans: ohne externe Ressourcen oder
  Skripte lesbar; private Orte enthalten, keine neuen Zeiten oder Kartendaten.
- Dokumentation/Datenschutzbeschreibung/Roadmap aktualisiert; lokale
  Löschfunktion berücksichtigt neue Speicher und stadtspezifische Zuhause-
  Adressen. Offline-Downloads müssen separat gelöscht werden.

VALIDIERUNG
480 automatisierte Assertions PASS:
400 bisherige + 2 Theme-Einbindungen + 45 neue Modell-/Speicherprüfungen +
33 tatsächliche DOM-Klickabläufe mit JSDOM und kontrollierten API-/GPS-Antworten.
24 JS-Dateien Syntax und relative Imports PASS.
31 PHP-Dateien PHP-8.2-Parser PASS, keine echte PHP-Runtime-Prüfung.
Direkter Transitous-WALK-Beispielabruf erfolgreich: /api/v6/plan liefert direct
mit WALK-Legs, duration und Geometrie. Neuer PHP-Proxy noch nicht live getestet.
Browser-Layoutprüfung BLOCKIERT: Chromium-Download lieferte ungültiges/
unvollständiges Archiv. Kein visueller Browser- oder Touch-Test als PASS.
ZIP-Integrität und Dateivollständigkeit geprüft.

ABNAHME / RESTARBEIT
- Lokale Daten und Produktion vor Upload sichern; Konfiguration, Daten/cache
  und Live-Shares erhalten. Paket nicht zum Überschreiben privater Daten nutzen.
- Echte Android-/iPhone-Geräte: 320/375/768 CSS-px, 200 Prozent Schrift, beide
  Themes, Screenreader, Tastatur, Safe-Area und native Dialoge/Vollbild prüfen.
- Produktions-PHP: walk/nearby/POST-Prefill prüfen, Routingausfall, ungenaues
  oder abgelehntes GPS, Netzunterbrechung, gesperrter/voller Speicher testen.
- Vollständige Offline-App weiterhin offen, keine automatische Mitfahrerkennung,
  Ankunftserkennung, Hintergrundalarme oder sekundengenauen Buspausen versprechen.
- Vollständigen aktuellen Server-Snapshot vor weiterer Konsolidierung abgleichen.

LOKALE TESTS
Entwicklungsabhängigkeiten: npm install --include=dev (Node 22.12+).
Bestehende Tests: node tests/<Datei>.mjs; DOM-Test: node tests/ux-dom.mjs.
Tests benutzen feste Fixtures/Mocks; echte Quellen-/Geräteabnahme bleibt separat.
package.json enthält nur Entwicklungsabhängigkeiten; produktive PHP/JS-Seiten
benötigen keinen Node-Server und kein npm install auf dem Webhosting.
Historische Dokumente und PASS/FAIL-Aussagen unverändert darunter erhalten.

NUTZERFREUNDLICHKEIT / GPS / REISEBEGLEITUNG · PLANUNG 14.10.2026
====================================================================
Alle folgenden Punkte sind GEPLANT; keine Funktionsumsetzung in diesem Dokumentationsupdate.
Basis bleibt v6.6. xroadmap.html ergänzt; neue Seite nutzerfreundlichkeit.html
mit Prioritätsfilter, Voraussetzungen, Abnahmekriterien und Druckansicht.

UX-19 [P1] Klarer Einstieg auf der Startseite
  Ziel: Drei große Einstiege: Abfahrten in der Nähe, Reise planen und Gemerkte Reisen.
  Abnahme: Jede Aufgabe mit maximal zwei bewussten Schritten vom Einstieg erreichbar; ohne GPS bleibt die Haltestellensuche nutzbar.
  Voraussetzung: Bestehende Karte und Suchwege erhalten.

UX-20 [P1] Feste Handy-Navigation
  Ziel: Karte, Abfahrten, Reisen und Merkliste bleiben unten erreichbar.
  Abnahme: Safe-Area, Bildschirmtastatur und große Schrift verdecken keine Inhalte; aktiver Bereich klar erkennbar.
  Voraussetzung: Navigation darf Karten- und Dialogbedienung nicht überlagern.

UX-21 [P1] Abfahrten zuerst, Details bei Bedarf
  Ziel: An ausgewählter Haltestelle Linie, Richtung, Minuten, Verspätung und Ausfall zuerst zeigen.
  Abnahme: Gleiche Linien in Gegenrichtung bleiben unterscheidbar; Zusatzangaben können aufgeklappt werden.
  Voraussetzung: Gemeldete Zeiten und Datenalter verwenden.

UX-22 [P1] Kompakte Unterwegs-Reisekarte
  Ziel: Nächsten relevanten Einstieg oder Umstieg mit Halt und Zeit oben zeigen, gesamten Verlauf darunter.
  Abnahme: Gespeicherter Plan und aktuelle Prüfung bleiben unterscheidbar; kein automatisches Behaupten einer Mitfahrt.
  Voraussetzung: Fortschritt aus Zeit/GPS allein ist kein bestätigter Einstieg.

UX-23 [P1] Datenqualität verständlich anzeigen
  Ziel: Fahrplan, gemeldete Echtzeit, geschätzte Position und veraltete Daten knapp und erklärbar kennzeichnen.
  Abnahme: Keine Messung als Echtzeit-GPS ausgeben; alte Zeiten werden nicht durch bloßes Öffnen frisch.
  Voraussetzung: Vorhandene Herkunfts- und Altersinformationen erhalten.

UX-24 [P1] Weniger Bildschirmfülle
  Ziel: Seltene Filter und längere Erklärungen unter Weitere Optionen bündeln; aktive Filter sichtbar halten.
  Abnahme: Filter mit einer klaren Aktion zurücksetzbar; keine versehentlich versteckten Verkehrsmittel.
  Voraussetzung: Schul-/E-Wagen-Präferenz und festes Soester Grundnetz erhalten.

UX-25 [P1] Einfache Ansicht und große Bedienelemente
  Ziel: Wenige große Tasten, größere Schrift, klare Kontraste, Abstände und Symbole mit Text.
  Abnahme: 320/375/768 px, beide Themes, 200 Prozent Schrift, Tastatur und Screenreader prüfen; Bedeutung nie nur über Farbe.
  Voraussetzung: Einstellung bewusst wählen und lokal merken.

UX-26 [P1] Rückkehr ohne Orientierungsverlust
  Ziel: Auswahl, Eingaben und Scrollposition erhalten; nach App-Wechsel relevante Daten aktualisieren.
  Abnahme: Listen springen beim Nachladen nicht; Zurück bleibt erreichbar; Fehler bieten Erneut versuchen.
  Voraussetzung: Frischeprüfung und abgebrochene/veraltete Antworten beachten.

UX-27 [P1] Entfernen rückgängig machen
  Ziel: Bei gemerkten Reisen eine unmittelbar erreichbare Rückgängig-Aktion anbieten.
  Abnahme: Nur die entfernte Reise wiederherstellen; Speicherfehler sichtbar machen; andere Reisen erhalten.
  Voraussetzung: Lokale Speicherung, kein stilles Löschen oder Synchronisieren.

UX-28 [P1] In meiner Nähe als zentraler Einstieg
  Ziel: Nach freiwilliger Standortfreigabe wenige sinnvolle Haltestellen mit passenden nächsten Abfahrten zeigen.
  Abnahme: Freigabe erlaubt/abgelehnt/Timeout und ungenaues GPS verständlich behandeln; ohne GPS manuell suchen.
  Voraussetzung: Standort nur nach bewusster Auswahl; kein gespeicherter Bewegungsverlauf.

UX-29 [P1] Fußwege statt Luftlinienversprechen
  Ziel: Haltestellen mit Entfernung und berechnetem Fußweg; Fußweg zeigen, Abfahrten öffnen und Ab hier planen.
  Abnahme: Luftlinie klar kennzeichnen, wenn Routing fehlt; kein sicherer Weg über unpassierbare Barrieren suggerieren.
  Voraussetzung: Fußwegrouting samt Übermittlung des Standorts offen erklären; Barrierefreiheit nur bei belastbaren Daten.

UX-30 [P1] Schaffe ich den Bus noch?
  Ziel: Abfahrt mit berechnetem Fußweg und einstellbarem Zeitpuffer vergleichen; nächste Möglichkeit anbieten.
  Abnahme: Voraussichtlich erreichbar und Zeit wird knapp nachvollziehbar; keine Einstiegsgarantie.
  Voraussetzung: GPS-Genauigkeit, Quellalter und Routingausfälle berücksichtigen.

UX-31 [P1] Anschluss wird knapp
  Ziel: Gemeldete Ankunft, Folgeabfahrt, Umsteigeweg und Puffer vergleichen; neue Suche anbieten.
  Abnahme: Durchbindungen ohne Ausstieg erhalten; ausgefallene Halte und fehlende Zeiten verhindern falsche Zusagen.
  Voraussetzung: Zeitprüfung allein bestätigt keine Anschlussgarantie.

UX-32 [P2] Reise ab hier und gemerkte Reise fortsetzen
  Ziel: Aktuellen Standort als Start übernehmen; neues Ziel wählen oder zum gespeicherten Ziel neu suchen.
  Abnahme: Neue Suche ersetzt die ursprüngliche gemerkte Reise nicht automatisch; geplante Abfahrt klar zeigen.
  Voraussetzung: Standort nur auf Auswahl als Suchstart senden.

UX-33 [P2] Zurück nach Hause und schnelle Haltestellen
  Ziel: Vom jetzigen Ort zum lokal gespeicherten Zuhause planen; häufige und zuletzt gewählte Haltestellen anbieten.
  Abnahme: Auch ohne GPS benutzbar; Favoriten und Verlauf einzeln löschbar.
  Voraussetzung: Bestehende Nach-Hause-Funktion erweitern; sensible Orte nur lokal und bewusst speichern.

UX-34 [P2] Reise bequem teilen
  Ziel: Verbindung als Text mit Linien, Zeiten und Haltestellen teilen.
  Abnahme: Persönliche Startadressen nur nach bewusster Auswahl; gespeicherter Datenstand mitgeben.
  Voraussetzung: Bestehende Live-Fahrt-Freigabe getrennt erhalten; lokale Reise-ID ist kein öffentlicher Freigabelink.

UX-35 [P2] Gut angekommen? und Rückfahrt
  Ziel: Bewusst aufrufbare Abschlussansicht mit Rückfahrt planen und Abfahrten hier ansehen.
  Abnahme: Ankunft nicht allein aus Uhrzeit oder Nähe behaupten; jederzeit manuell erreichbar.
  Voraussetzung: Keine automatische Ausstiegs- oder Mitfahrerkennung.

UX-36 [P2] Letztbekannten Reiseplan verfügbar halten
  Ziel: Gespeicherten Verlauf bei Netzproblemen lesbar halten; vollständige Offline-Ansicht gesondert entwickeln.
  Abnahme: Offline-Start mit bereits geladenen Ressourcen prüfen; Datenstand und fehlende aktuelle Zeiten deutlich.
  Voraussetzung: Aktuell vorhandene lokale Speicherung ist noch keine vollständige Offline-App; keine unbegrenzte Kartenkachel-Speicherung.

UX-37 [P3] Standortalarme und Ausstiegserinnerungen prüfen
  Ziel: Optional vor Zielhalt oder Umstieg erinnern, wenn zuverlässig technisch möglich.
  Abnahme: Explizite Freigabe, Genauigkeit und echte Hintergrundtests; bei fehlender Zuverlässigkeit keine Zusage.
  Voraussetzung: Mobile Webseiten laufen im Hintergrund nicht verlässlich; eventuell Android-App-Anbindung erforderlich.

UX-38 [P3] Gemessene Fahrzeugpositionen anbinden
  Ziel: RLG/Betreiber nach Positionsfeed, Fahrtzuordnung, Abdeckung, Intervall und Nutzungsfreigabe fragen.
  Abnahme: Gemessene Position und Schätzung sichtbar unterscheiden; alte oder fehlende Messungen mit ehrlichem Rückfall.
  Voraussetzung: Feed-Zugang und Betreiberfreigabe offen. GPS allein ersetzt keine Ankunftsprognose; keine eigene Trackingbox ohne Kooperation.

Gemeinsame Abnahme: echte Handys, große Schrift, beide Themes, ohne GPS,
App-Wechsel, Netz-/Routingausfall und gesperrter Speicher. Keine Hintergrund-
zuverlässigkeit, Fahrzeugortung oder Offline-Fähigkeit ungeprüft zusagen.
Ältere Einträge und Testhistorien bleiben darunter unverändert erhalten.

AKTUELL: v6.6 · HALTEZEITEN / VERSPAETUNGSNACHWEIS · 14.10.2026
================================================================
BASIS: vollständiges v6.5-Paket. Öffentliche Live-Daten und Positionsmodul geprüft;
kein vollständiger frischer Server-Snapshot, keine Live-Installation.
BEFUND am 14.10.2026, Abruf 17:09:39 Europe/Berlin:
- 245 C2-Kartenabschnitte, davon 24 mit gegenüber Plan verschobener Abfahrt.
- 45 C2-Abschnitte mit identischer Abfahrt und Ankunft; sie wurden im bisherigen
  JS-Adapter durch arr<=dep verworfen. Dies konnte die Haltefolge unterbrechen.
- 218 aufeinanderfolgende C2-Abschnitte ohne Zeitlücke, 11 mit positiver Lücke;
  nur eindeutig namensgleiche Anschlussstellen gezählt.
- Vollständiger C2-Fahrtplan ebenfalls minutenweise Zeiten: z.B. Gotlandweg
  Ankunft=Abfahrt 14:59Z, Plan 14:57Z. Keine sekundengenaue Pause ableitbar.
- Bisherige Berechnung nutzt bereits gemeldete Zeiten. Verspätung nochmals zu
  addieren würde sie doppelt berechnen. Keine pauschale Verzögerung eingeführt.
KORREKTUR:
- Nullzeit-Abschnitte bleiben im Kartenadapter und der geteilten Live-Fahrt
  erhalten. Kein Teilen durch null: interpoliert werden nur positive Laufzeiten.
- Gelieferte Haltezeit zwischen Ankunft und Folgeabfahrt wird respektiert;
  Test deckt beide Grenzen und einen verspäteten Halt ab.
- Markerhinweis nennt getrennte Abfahrts-/Ankunftsabweichung zur Planzeit.
- Nicht zeitlich aufgelöste Abschnitte ausdrücklich als ungenau gekennzeichnet.
- Kartenhinweis und Reisehilfe erklären fehlende kurze Pausen.
- Quellenzeiten unverändert; keine erfundene Mindestpause, keine neue Quelle,
  kein GPS-Fahrzeugfeed und keine Änderung des festen Soester Grundnetzes.
VALIDIERUNG: 400 automatisierte JS-Assertions PASS (383 bestehende + 17 neue).
18 JS-Dateien Syntax PASS, 30 PHP-Dateien PHP-8.2-Parser PASS.
Kein PHP-Runtime-/Touch-End-to-End-Test. ZIP-Integrität geprüft.
OFFEN: Upload und echter Handy-/PHP-Server-Test; C2 an gleicher Haltestelle,
Fahrtkennung und Uhrzeit mit Betreiberanzeige vergleichen. Eine sekundengenaue
Übereinstimmung ist mit den geprüften minutenweisen Daten nicht erreichbar.
INSTALLATION: vollständiges Paket; vorhandene Konfiguration und Nutzerdaten
sichern/erhalten. Nach Upload Seite neu laden, Build 20261014-stop-timing-v6-6.
Historische Dokumentation bleibt unverändert darunter erhalten.

AKTUELL: v6.5 · Gemerkte Reisen / mobile Linien · 13.10.2026
================================================================
- Reise planen: Jede Verbindung kann mit „Reise merken“ lokal gespeichert werden.
- Merkliste: Unterwegs öffnen, mit Abfahrt jetzt neu planen oder entfernen.
- reise-unterwegs.php: gespeicherter Fahrplan und gelieferte Routengeometrie;
  fehlende Geometrie wird nicht durch erfundene Buslinien ersetzt.
- Optionaler GPS-Punkt samt Genauigkeitskreis; keine gespeicherte Bewegung.
  Standort wird beim Verlassen/Hintergrund beendet, erneut bewusst aktivieren.
- „Fahrzeiten prüfen“ fragt die gespeicherten Fahrtkennungen ab, zeigt getrennte
  Ergebnisse und gleicht die gespeicherte Einstiegs-/Ausstiegsfolge ab.
  Dies bestätigt keine Anschlüsse. Für neue Verbindungen neu planen.
- Speicher nur im selben Browser/Profil/Gerät, bis entfernt oder Browserdaten
  gelöscht werden. Maximal 30 Reisen; Speicherfehler werden angezeigt.
- Karten und neue Fahrzeiten benötigen Internet. Kein Offline-App-Versprechen.
- Index/Handy: Linienkopf und Filter umbrechen, große Tasten und keine intern
  höhenbegrenzte Linienliste. Sichtbares &#x20; war im Quelltext nicht vorhanden.
- Hilfe, Datenschutzbeschreibung und xroadmap.html ergänzt.
PRÜFUNG: 383 JS-Assertions PASS; 18 JS-Dateien Syntax PASS;
30 PHP-Dateien mit PHP-8.2-Parser PASS. Kein PHP-Laufzeittest.
OFFEN: Upload/Live-Abnahme; Android/iPhone, beide Themes, 320/375/768 px,
Speichern/Neuladen/Löschen, GPS erlauben/ablehnen, Hintergrund, Kartenscrollen,
Netzausfall, Speicherblockade und echte Fahrzeit-/Umleitungsfälle prüfen.
Vor Upload vorhandene Konfiguration, Cache und Live-Shares sichern/erhalten.
Das Paket wurde nicht auf der produktiven Webseite installiert.

SO-BusLivePRO · v6.4 · MOBILER SCHIEBEBEREICH
Build: 20261013-mobile-sheets-v6-4 · 13.10.2026
===========================================
STATUS: vollständig im Paket integriert und lokal logisch geprüft. Kein Deployment.
Visuelle/physische Smartphone-Abnahme und echte PHP-Laufprüfung bleiben offen.
Dieser Abschnitt hat Vorrang; frühere Reports und Testhistorien bleiben erhalten.

BEDIENUNG
- Abfahrts- und Fahrplanfenster auf Handy/Tablet bis 900 CSS-Pixel Breite als
  hochziehbarer Bereich mit drei Stufen: Kompakt / Halb / Vollständig geöffnet.
- Start in halber Höhe. Ziehen ausschließlich am 44px-Griff. Kleiner, Größer und
  Schließen als separate 44px-Schaltflächen. Griff auch antipp-/tastaturbedienbar:
  Pfeil hoch/runter, Home/End. Keine Wischbedienung auf Karte oder Listen übernommen.
- Kompakt: nächste verfügbare Abfahrt bzw. nächster gültiger Halt, Zeiten,
  Verspätung, Echtzeit-/Fahrplankennzeichnung und Datenabrufalter. Entfallene
  Abfahrten/Halte übersprungen; Sources-Fehler ausdrücklich gekennzeichnet.
- Kompakt und halb: Karte oberhalb des Bereichs bleibt bedienbar. Voll geöffnet:
  Hintergrund schirmt Karte ab. Listen scrollen unabhängig vom Griff.
- Lange Texte dürfen umbrechen; kompakte Auskunft hat eigenen Scrollbereich.
  Tablet/Querformat/Browserleisten und Tastatur werden über visualViewport/Resize
  berücksichtigt. Safe-Area und reduzierte Bewegung respektiert.
- Desktop behält die bisherigen Dialoge. Neue Bedienelemente dort ausgeblendet.
- Dialogfokus bei Öffnen/Schließen, Rückfall zur Haltestellensuche bei zerstörtem
  Auslöser; Fokusbegrenzung bei vollständig geöffnetem Modal. Halb/kompakt nichtmodal.
- Escape schützt die native Haltestellensuche und schließt den vorderen Share-/
  Fahrplandialog. Unterliegender Karten-Vollbildmodus bleibt dabei erhalten.
  Ortssuche konsumiert ihren eigenen Escape-Tastendruck.
- Periodisches Nachladen, Scrollposition, Source-Backoff, Durchbindungshinweise,
  Störungsmeldungen, Datenalter und die getrennten Kartenlayer bleiben erhalten.
- Neue bottom-sheets.js und bottom-sheets.css; Einbindung in index.php. Keine
  zusätzlichen Datenquellen, Standortfreigaben oder HTTP-Abfragen hinzugefügt.
- Kurzanleitung in reisehilfe.php, Roadmap und Textdateien ergänzt.

VALIDIERUNG
342 automatisierte JS-Assertions bestanden: 269 bisherige + 60 Schiebesteuerung/
Tastatur/Fokus/Viewport + 12 tatsächliche kompakte Auskunft + 1 Initialfehleranzeige.
Neue UI-Tests verwenden die tatsächlichen Controller-/Handlerfunktionen mit
DOM-Testdoubles: kein behaupteter Browser-/Touch-End-to-End-Test.
Getestet: drei Zustände, Grenzen/kleine Viewports, Swipe-Richtung, kurze Bewegung,
horizontale Fehlbewegung, fremde Pointer-ID, Abbruch, Klick nach Drag, Größer/Kleiner,
Tastatur, Modalstatus/Fokus, Fokus-Rückkehr, Summary-Text statt HTML, Viewportwechsel,
Escape bei nativer Suche/Share/Fullscreen, nächste Abfahrt/Verspätung/Datenalter,
Ausfall-/Fallback-/Fehlerhinweise. Bestehende Regressionen weiterhin bestanden.
15 JS-Dateien syntaxgeprüft; app.js-DOM-Referenzen und lokale Importpfade geprüft.
29 PHP-Dateien mit PHP-8.2-Syntaxparser geprüft; kein php -l / PHP-Lauftest behauptet.
Roadmap-Verweise/Statusanzahl und ZIP-Integrität geprüft.

ABNAHME NACH UPLOAD
1. Build 20261013-mobile-sheets-v6-4 kontrollieren.
2. Android/Chrome und Firefox, iPhone/Safari, Tablet: drei Stufen per Griff und Taste.
3. Kompakt/halb: Karte oberhalb ziehen/zoomen, anderen Halt/Bus antippen. Listen
   scrollen ohne Höhenwechsel. Voll geöffnet: nur Dialoginhalt bedienbar.
4. Große Schrift/200% Zoom, lange Ziele, Querformat, Browserleisten und Tastatur.
5. Offene Abfahrt/Fahrt zwei Minuten beobachten: Daten/Alter/Scrollposition/Schiebehöhe.
6. Netzfehler/Erholung, App-Rückkehr, Halte-/Fahrt-/Ortswechsel während Anfrage.
7. Escape: native Suche, Teilen, Fahrplan und Karten-Vollbild einzeln behandeln.
8. Durchbindung, Störungen, Favoriten/GPS/Teilen unverändert praktisch abnehmen.
9. Desktop: bisheriger Dialog, keine sichtbaren Griff-/Schiebeschaltflächen.

INSTALLATION
Vollständiges v6.4-Paket ersetzt v6.3 zum Upload. Neue CSS/JS-Dateien unbedingt
mit übertragen. Serverordner sichern, bestehende data/-Inhalte/Freigaben erhalten.
Details INSTALLATION-v6.txt; weiterhin offene Abnahme TODO.txt.

--- HISTORIE v6.3 UND ÄLTER ---

SO-BusLivePRO · v6.3 · FAHRPLAN-REVIEW UND ZEITANZEIGE
Build: 20261013-timetable-v6-3 · 13.10.2026
=====================================================
STATUS: lokal korrigiert und geprüft. Kein Upload/Deployment. Live-Abnahme offen.
Dieser Abschnitt hat Vorrang; frühere Prüfergebnisse und Reports bleiben erhalten.

GEFUNDENE FEHLER UND KORREKTUREN
1. buildFallbackTimetable erzeugte epoch-ms-Zahlen, renderTimetable/rideProgress
   erwarteten parsebare Datumstexte. Bei ausgefallener Trip-Abfrage konnten Uhrzeiten
   und Fortschritt deshalb fehlen. Der tatsächliche Fallback normalisiert Zeiten
   jetzt zu ISO-8601; fehlende Werte bleiben leer. Keine fiktiven Fahrzeiten.
2. Als nächster Halt wurde ein ausgefallener Halt nicht ausgeschlossen; nach Ende
   der Fahrt wurde der letzte Halt weiterhin als aktuell markiert. nextCallIndex
   überspringt Ausfälle und liefert ohne passenden zukünftigen Halt -1.
3. Ankunft und Abfahrt an Aufenthalts-/Durchbindungshalten waren nur als Zahlenpaar
   dargestellt. Nun getrennte Zeilen „An … / Ab …“. Unterschiedliche Verspätungen
   werden getrennt angezeigt, z.B. „An +3 min · Ab +1 min“. Fehlende Planzeiten
   erzeugen keine Verspätung; Frühabfahrt wird weiterhin mit Minuswert angezeigt.
4. Linienauswahl bezeichnet die R49/R81-Verknüpfung ausdrücklich als Möglichkeit
   bei einzelnen Fahrten, nicht als Zusage einer Durchbindung für jede Fahrt.

VALIDIERUNG
269 automatisierte JS-Assertions bestanden: 245 aus v6.2 + 24 neue Checks.
Neue Fälle führen insbesondere die tatsächliche buildFallbackTimetable-Funktion
mit Aufenthaltszeiten aus und prüfen parsebare Zeiten sowie Fahrtfortschritt.
Weiterhin: ausgefallene/abgeschlossene Halte, getrennte An-/Abfahrtsverspätungen,
Frühabfahrt, fehlende Zeiten und Zahlen/ISO-Timestamps. 14 JS-Dateien syntaxgeprüft.
29 PHP-Dateien per PHP-8.2-Parser syntaktisch geprüft; keine PHP-Laufabnahme.
Roadmap-Verweise/Statusanzahlen, lokale Importziele und ZIP-Integrität geprüft.

NÄCHSTE SINNVOLLE SCHRITTE
- v6.3 hochladen und aktuelle Assetrevision im Browser prüfen; data/ erhalten.
- Echte PHP-Laufprüfung und Smartphone/Firefox/Safari-Sichtprüfung am Server.
- Tatsächlich durchgebundene Fahrt sowie normale R49/R81-Fahrt als Gegenprobe.
- Störung mit entfallendem Halt/Umleitung, App-Rückkehr, Offline-/Erholungsfall.
- Geänderte Liniennummer am Kartenmarker bleibt separat live abzunehmen; die
  lokalen Logiktests beweisen keine vollständige Betreiberabdeckung.
- Weitere Erweiterungen erst nach dieser Abnahme priorisieren; schnellere
  Aktualisierung allein beseitigt keine abweichenden Quellinformationen.

INSTALLATION
Komplettpaket v6.3 ersetzt v6.2 zum Upload. Neues assets/js/timetable-time.js
mit übertragen. Hinweise INSTALLATION-v6.txt; offene Aufgaben TODO.txt.

--- HISTORIE v6.2 UND ÄLTER ---

SO-BusLivePRO · v6.2 · FAHRGASTHINWEIS BEI LINIENWECHSEL
Build: 20261013-interlining-v6-2 · Stand 13.10.2026
========================================================
STATUS: vorbereitet und lokal geprüft. Kein Deployment. PHP-Laufprüfung und
Live-Abnahme des neuen Hinweises bleiben offen. Dieser Abschnitt hat Vorrang.

BEFUND UND QUELLPRÜFUNG
- MOTIS-API v6 dokumentiert interlineWithPreviousLeg=true ausdrücklich als
  Weiterfahrt im selben Fahrzeug ohne Umstieg. joinInterlinedLegs=false erhält
  die getrennten Abschnitte und deren jeweilige Linienbezeichnungen.
- Bisherige trip.php behielt die Abschnitte, entfernte aber dieses Kennzeichen
  beim Normalisieren. interlined wurde allein aus mehreren Liniennamen abgeleitet.
  Eine Liste von Liniennummern ist kein ausdrücklicher Bleib-im-Fahrzeug-Nachweis.
- Live-Stichprobe am 13.10.2026 ca. 16:16: drei konkrete R49-/R81-Tripantworten
  aus dem aktuellen Kartenfenster hatten jeweils ein Leg und Flag false.
  Abgefragte IDs:
  20261013_16:00_de-DELFI_3428370987 (R49)
  20261013_16:00_de-DELFI_3428372232 (R81)
  20261013_16:01_de-DELFI_3428372303 (R81)
- Verbindungssuche Körbecke, Seestr. -> Lohne, Kirche ab 16:00 zeigte in drei
  Ergebnissen einen Umstieg mit WALK zwischen R49 und R81, keine Durchbindung.
  Das beweist NICHT, dass andere Fahrten nie durchgebunden sind. Abdeckung hängt
  von der konkreten Fahrt und der Quelle ab; DB kann andere Informationen haben.
- Öffentliches Prüfmuster in tests/fixtures/interlining-20261013.json erhalten.
- Schema: https://github.com/motis-project/motis/blob/master/openapi.yaml
  Kennzeichen gilt allgemein auch für andere Bus-/Bahnverbindungen, keine
  pauschale R49/R81-Regel und keine durchgeführte DB-Gleichheitsprüfung.

UMSETZUNG
- includes/interlining.php wertet nur das boolesche Kennzeichen true aus.
  Ein WALK-/unbekannter Zwischenabschnitt unterbricht die Kette. Ausfälle und
  entfallene Übergangshalte unterdrücken den Bleib-im-Fahrzeug-Hinweis.
- api/trip.php liefert bestätigte continuations mit Ausgangs-/Folgelinie und
  Wechselhalt. Kein Filtern auf bestimmte Liniennummern. interlined beruht jetzt
  auf bestätigten Übergängen, nicht auf der Anzahl unterschiedlicher Linien.
- Wechselhinweis in der Fahrplanübersicht und am Übergangshalt:
  „Dieses Fahrzeug fährt ab [Halt] als Linie [Folgelinie] weiter.
   Du kannst im Fahrzeug bleiben.“ Ohne gelieferten Halt wird kein Halt erfunden.
- Zusammengeführter Übergangshalt erhält die Abfahrt des Folgeabschnitts, während
  die Ankunft des vorigen Abschnitts erhalten bleibt. R49->R81->R49 bleibt möglich.
- Reiseplanung übernimmt denselben Hinweis aus den unveränderten rohen Legs.
  Bei fehlender transfers-Zahl zählen bestätigte Weiterfahrten nicht als Umstieg.
  Die normale Umstiegsanzeige und Fußwege bleiben erhalten.
- Neue interlining.js, gut lesbare Hinweiskarten und Assetrevision.
  Neuer Trip-Cacheprefix vermeidet Übernahme alter Antworten ohne das Kennzeichen.
- Roadmap, README, TODO, QA und Installation auf den neuen Paketstand ergänzt.

VALIDIERUNG
245 automatisierte JS-Assertions bestanden: 215 bisherige plus 30 neue Prüfungen.
Neue Fälle: R49->R81, R81->R49, andere Bahnlinien, gleiche Linie, normale Umstiege,
WALK, fehlendes/stringförmiges Flag, Ausfälle, fehlender Wechselhalt, HTML-Escaping,
mehrere Wechsel, echte negative Quellstichproben und tatsächlicher Reise-Renderer.
13 JS-Dateien syntaxgeprüft; app.js-DOM-Referenzen vollständig.
29 PHP-Dateien per PHP-8.2-Parser syntaktisch geprüft. Kein echtes php -l oder
PHP-Lauf-/End-to-End-Test behauptet. Positive Beispiele sind Testdaten; die Live-
Stichprobe enthielt KEINE bestätigte Durchbindung. Positive Live-Abnahme offen.

INSTALLATION / ABNAHME
Neues Komplettpaket ersetzt v6.1 zum Upload. Bestehende data/-Inhalte behalten.
Neue includes/interlining.php und assets/js/interlining.js unbedingt mit übertragen.
Nach Upload echte durchgebundene Fahrt prüfen: Hinweis, Wechselhalt/Abfahrtszeit,
Folgelinie und normaler Umstieg als Gegenprobe. Zusätzlich andere Bus-/Bahnverbindung.
Kein eigener GPS-/Linienwechsel-Tracker für Kartenmarker implementiert.

--- HISTORIE v6.1 UND ÄLTER ---

SO-BusLivePRO · v6.1 · ZEITRÄUME & ERWEITERTE PRÜFUNG
Build: 20261006-realtime-v6-1 · 06.10.2026
====================================================
STATUS: vorbereitet, lokal geprüft, NICHT deployed / live abgenommen.
Dieser Abschnitt hat Vorrang. v6 und ältere Abschnitte darunter sind Historie.

WEITERFÜHRUNG
- Störungsmeldungen zeigen impactPeriod als gemeldeten Gültigkeitszeitraum an,
  mit Datum, Uhrzeit und expliziter Zeitzone Europe/Berlin. Mehrere Zeiträume
  berücksichtigt (Anzeige auf fünf begrenzt). Kommende/beendete Zeiträume kenntlich.
- Kommunikationszeitraum bleibt davon getrennt: Die Quelle entscheidet mit
  communicationPeriod, wann ein Hinweis überhaupt angezeigt werden soll.
- Fehlende oder ungültige Zeiträume erzeugen keine erfundenen Datumsangaben.
- Neue Assetrevision inklusive Version des service-alerts-Modulimports.

LIVE-CHECK DES AUSGANGSSTANDS UM 19:28 (06.10.2026)
- /api/health.php: ok=true, Build 20260917-theme-v5, Cacheverzeichnis schreibbar.
- Hauptseiten-Build ebenfalls 20260917-theme-v5.
- /xroadmap.html: HTTP 404. v6 ist zum Prüfzeitpunkt NICHT live installiert.
- Kein Deployment und keine Schreiboperation am produktiven Server durchgeführt.

VALIDIERUNG
- 215 automatisierte JS-Assertions bestanden (206 v6 + 9 Gültigkeitszeiträume).
- 12 JS-Dateien syntaxgeprüft; Roadmap-Filterfunktion, Statuszahlen/Links geprüft.
- Alle 28 PHP-Dateien mit php-parser als PHP 8.2 syntaktisch geparst, ohne Fehler.
  WICHTIG: Das ersetzt weder php -l mit echtem PHP noch den PHP-Integrationstest.
  Eine echte PHP-Laufzeit konnte in dieser Umgebung nicht bereitgestellt werden.
- ZIP-Integrität überprüft. PHP-Laufprüfung und visuelle/live Abnahme weiterhin offen.

INSTALLATION
Dieses Paket ersetzt v6 als aktuelles Uploadpaket. Anleitung INSTALLATION-v6.txt.
Bestehende data/-Inhalte und Freigaben erhalten, vorher Serverordner sichern.
Roadmap bleibt xroadmap.html im Projekt-Hauptverzeichnis. Offene Schritte: TODO.txt.

--- HISTORIE: v6 ---

SO-BusLivePRO · ECHTZEIT & STÖRUNGSHINWEISE · 20261006-realtime-v6
=================================================================
Stand: 06.10.2026. Neues Paket v6, auf REISEPLANUNG-THEMES-v5 vom 17.09.2026.
STATUS: lokal umgesetzt und logisch geprüft. Kein Upload/Deployment durchgeführt.
PHP-Laufprüfung und visuelle/live Abnahme der neuen Änderungen bleiben offen.
Dieser aktuelle Abschnitt hat Vorrang vor allen historischen Angaben darunter.

BESTÄTIGTER AUSGANGSBEFUND (06.10.2026)
- Live geladene PRO-app.js war byteidentisch zur zuletzt gefundenen v5-ZIP-Datei.
- Kartenabruf alle 20 s, Servercache bis 55 s. Offene Haltestellen hatten keine
  regelmäßige Aktualisierung. Fahrtfenster: 60-s-Intervall und 45-s-Servercache.
- C2-Kandidat: Trip 20261006_18:54_de-DELFI_3421850386, Quelle bezeichnet Ziel als
  Soest, Kesselfuhr; nicht sicher als exakt vom Nutzer beobachtete Fahrt bestätigt.
  Abruf ca. 19:03: Bahnhof 19:04 -> 19:07, Hansaplatz Abfahrt 19:15 -> 19:18;
  Stadthalle 19:18 ohne Verspätung. Später direkt aus Transitous +1 statt +3 Min.
  Das ist ein Vergleich zeitlich unterschiedlicher Quellstände, KEIN DB-Beweis.
- DB-Abfahrtssuche verweigerte diesen Browser mit Fehler 751 und Bot-Hinweis.
- Transitous dokumentiert minütliche Echtzeitfeed-Abfragen. Betriebsmessalter und
  Vollständigkeit der aktuellen lokalen Betreiberinformationen sind unbekannt.

UMSETZUNG v6
- api/bus-live.php: CACHE_SECONDS 55 -> 30. Bestehender 20-s-Clientabruf, Backoff,
  Fehler-Cooldown, Marker-Alterung und getrenntes Bus-Grundnetz bleiben erhalten.
- Offene Haltestellen und Fahrpläne: automatische Aktualisierung alle 30 s.
  Bei visibilitychange/pageshow neue Abfrage, wenn der Detailcache mindestens 20 s
  alt ist. Keine zusätzlichen Detailabrufe bei geschlossenen Fenstern/Hidden Tabs.
- Wiederholte Detailabrufe dedupliziert. Fehlerhinweise erhalten die letzten Werte,
  Scrollposition bleibt erhalten. 30-s-Requesttimeout; Fehlerwiederholung mindestens
  60 s oder Retry-After (wie bisher gedeckelt). Orts-/Fahrtwechsel verwerfen alte
  Antworten. Bestehende Quellzeiten werden nicht künstlich verändert.
- api/trip.php: Servercache 45 -> 20 s, separate v6-Dateinamen, generatedAt/cacheAge.
  Abfahrten- und Trip-HTTP-Antworten no-store. Empfang eines Caches bedeutet keinen
  neuen Quellabruf. Abrufalter in Detailfenstern sichtbar; Fallback-Alter basiert
  auf dem Kartenquellstand. Abrufalter ist ausdrücklich keine Betreibermesszeit.
- Neue data-freshness.js und service-alerts.js; neue Assetrevision gegen alte Clients.

SPERRUNGEN, VERANSTALTUNGEN UND UMLEITUNGEN
- stoptimes fragt jetzt withAlerts=true an (vorher false). Meldungen aus Place.alerts
  werden weitergereicht und im Abfahrtsfenster mit Linienbezug angezeigt.
- Trip-Antwort: Meldungen aus Legs und Halten werden übernommen; Duplikate beim
  Zusammenführen von Halten bleiben erhalten und werden in der Anzeige reduziert.
- Nur gelieferte Meldungen, als Plaintext escaped. Kommunikationszeiträume werden
  beachtet, lange Listen begrenzt. Keine automatisch besuchten Meldungs-URLs.
- Ausfallprüfung vereint event.cancelled, tripCancelled und place.cancelled per OR.
  Der frühere ??-Ausdruck konnte tripCancelled=true durch cancelled=false verdecken.
- Bestehende Stop-/Trip-Ausfallmarkierung bleibt; Hinweis erklärt mögliche Abweichung
  des Kartenverlaufs bei Umleitungen. Keine eigenen GPS-Koordinaten, fiktiven
  Umleitungslinien oder pauschalen Verspätungsaufschläge ergänzt.
- Falls der Feed einen temporären Linienweg/Zeiten liefert, nutzt die vorhandene
  Karte diesen Quellstand. Wenn nur eine Warnmeldung vorliegt, ist eine gezeichnete
  reguläre Strecke keine bestätigte reale Route. Abdeckung neuer Ersatzhalte und
  geänderter Geometrien muss anhand konkreter Störungen geprüft werden.
- Schema geprüft: https://github.com/motis-project/motis/blob/master/openapi.yaml
  /api/v6/stoptimes withAlerts; Place.alerts, Leg.alerts, Alert.communicationPeriod.
  Das ist eine Schemaprüfung, keine Live-Bestätigung aktueller Soester Sperrungen.

ROADMAP / TEXTDATEIEN
- xroadmap.html im Projekt-Hauptverzeichnis; Filter, Mobilansicht und Druckansicht.
  Link von der Hauptkarte. Status: Vorhanden in v5 / Im v6-Paket / Abnahme offen /
  Geplant. Kein erfundener Fortschrittsprozentsatz oder Veröffentlichungstermin.
- README.txt und SO-BusLive-QA.txt erhalten aktuellen Stand vor der Historie.
- TODO.txt und INSTALLATION-v6.txt neu. Historische API-Hashes, alte PHP-Abnahmen,
  12-Minuten-Haltebehauptungen und „keine eigene Reiseplanung“ gelten nicht als v6.
- robots.txt geprüft; keine Änderung für dieses Funktionsupdate erforderlich.

VALIDIERUNG v6
- 206 JS-Assertions erfolgreich: 167 bestehende + 25 Datenalter/Detailrefresh +
  14 Störungsmeldungen (inkl. Escape/Kommunikationszeitraum/Duplikate/Limits).
- Syntaxprüfung aller 12 JS-Dateien; statische app.js-DOM-Referenzen ohne fehlende
  IDs; stopDataAge ist eine ausdrücklich dynamisch erzeugte ID.
- Roadmap: Statusanzahlen, Filterfunktion und lokale Links geprüft; ZIP-Integrität.
- Keine PHP-Laufzeit vorhanden: kein php -l und kein PHP-Integrationstest behauptet.
  Kein Live-Test der neuen Alerts-/Refresh-Anzeige oder Smartphone-Sichttest.

INSTALLATION / ABNAHME / ROLLBACK
Siehe INSTALLATION-v6.txt und TODO.txt. Vorhandenen Serverordner sichern,
Programmdateien und neue Assets hochladen, bestehende data/-Inhalte behalten.
Die Reduzierung der Karten-TTL kann mehr Upstream-Abrufe erzeugen (unter Dauerlast
ungefähr bis Faktor 1,8 relativ zu 55 s); bestehenden Backoff bewusst beibehalten.
Nach Upload PHP, Datenlast und konkrete C2-Fahrt zeitgleich mit DB/Mobil info prüfen.
Zusätzlich Sperrung/Veranstaltung mit gelieferter Meldung, entfallenden Halten,
Ersatzhalt und gültigem Zeitraum testen; fehlende Meldung ist kein Entwarnungsnachweis.
Rollback: gesicherte Programmdateien zurückspielen, produktive data/ erhalten.
Keine produktive Datenbank-/Schemaänderung und keine Löschung von Freigaben.

--- HISTORIE v5 UND ÄLTER (KEINE AKTUELLE v6-ABNAHME) ---

SO-BusLive-SoestPRO · HELL/GRÜN, KONTRAST & REISEPLANUNG · 20260917-theme-v5
============================================================================
Dieses vollständige Paket baut auf SUCHLOGIK-v4 auf. Frühere Einschränkungen
zur fehlenden A-nach-B-Suche sind durch dieses Update überholt.

THEME UND LESBARKEIT
- Zentrale Theme-Initialisierung vor dem Seitenaufbau. Hell ist Standard;
  gespeichertes Grün wird auf allen acht bestehenden HTML-Seiten übernommen.
- Umschalter auch auf Unterseiten; Speicheränderungen anderer Tabs und Rückkehr
  aus dem Browsercache werden berücksichtigt. Native Formularfarben folgen mit.
- Gemeinsame deckende Flächen und kontrastreiche Text-, Hinweis-, Warnfarben.
- Vergrößerte Hinweistexte und Touch-Ziele; keine abgeschwächte Textdeckkraft
  für vergangene oder ausgefallene Halte. Umbruch in Headern, Dialogfüßen,
  Projektkarten und schmalen Formularen verbessert.
- Gemessene definierte Farbpalette: Haupt-/Nebenlesetext mindestens 8,18:1 auf
  den drei Leseflächen beider Themes; getestete Statusfarben mindestens 4,5:1.
  Dies ist KEINE vollständige WCAG-Zertifizierung oder Messung aller gerenderten
  Zustände, Fremdkarten, Fotos und dynamischen Linienfarben.

A-NACH-B-PLANUNG
- Neue reise-planen.php, direkt von Hauptkarte, Hilfe und Nach-Hause erreichbar.
- Europäische Start-/Zielsuche für Orte, Adressen und Bahnhöfe mit klarer Auswahl,
  Relevanzsortierung, Tastaturbedienung, Start/Ziel-Tausch und Abfahrtszeit.
- Bus & Bahn, nur Bahn oder nur Bus, jeweils mit Fußwegen.
- Echte Verbindungsanfragen über die mitgelieferte Referenz-API von Transitous;
  neue lokale API unter api/journey/, keine Referenzcaches übernommen.
- Aufklappbare Verbindungen mit einzelnen Abschnitten, Zeiten inklusive Datum,
  Dauer, Umstiegen, Wartezeit zwischen Abschnitten, Gleis/Steig wenn geliefert,
  Datenstatus und Ausfallhinweisen. Alle Zeiten in ausdrücklich genannter
  Gerätezeitzone, auch bei Reisen über Zeitzonengrenzen.
- Anfrageabbruch bei neuen Eingaben. Keine alten Routen als aktuelle Ergebnisse.
- Keine Ticket-/Barrierefreiheits-/Anschlussgarantie. Fahrten nur nach tatsächlicher
  Datenabdeckung. Keine Buchung, kein Tarifrechner, keine GPS-Navigation.

WEITERER BEFUND UND FIX
Die übergebene Wien-URL der Nach-Hause-Seite zeigte in Chrome tatsächlich Soest.
Dynamisches Ortsprofil nun serverseitig aufgenommen; Koordinaten und Name an
alle zugehörigen API-Anfragen weitergegeben. DE-Filter der Adresssuche entfernt.

VALIDIERUNG
- Chrome: bestehende produktive Nach-Hause-Seite aufgerufen; fest dunkler
  Hintergrund ohne data-theme und Verlust des Wien-Kontexts bestätigt.
  Bei 1363px Browserbreite kein horizontaler Überlauf in diesem Ausgangszustand.
- 167 automatisierte Assertions bestanden: bisher 102 + 65 Theme-/Kontrast-/
  Reisedarstellungsprüfungen. Alle JavaScript-Dateien syntaxgeprüft.
- Reise-Response-Struktur mit Daten aus dem bereitgestellten Referenzpaket
  abgeglichen; HTML-Escaping, Ausfälle, Umstiege und Mitternacht getestet.
- Neue PHP-Endpunkte und die fertigen Oberflächen NICHT live abgenommen.
  PHP-CLI fehlt hier; kein Deployment durchgeführt. Die Chrome-Beobachtungen
  betreffen den vorherigen Serverstand, nicht dieses lokal geänderte Paket.
- Smartphone-, Tablet-, Desktop-, Zoom-/Querformat-Abnahme nach Upload offen;
  reale Sonneneinstrahlung lässt sich aus Kontrastwerten nicht simulieren.

INSTALLATION UND ABNAHME
Vollständigen Inhalt in das tatsächlich verwendete Projektverzeichnis laden,
beispielsweise SO-BusLive-SoestPRO1 für den genannten Testlink. Bestehende data-
Verzeichnisse und Freigaben behalten. Neue api/journey-Dateien mit übertragen.
Die bestehenden öffentlichen SEO-Zieladressen wurden nicht auf PRO1 umgestellt.
1. Hell/Grün wählen, Nach Hause/Hilfe/Rechtstexte öffnen und zurückkehren.
2. Wien-URL öffnen; Ortslabel muss Wien anzeigen. Adresse in Wien suchen.
3. Reise planen: Soest Bahnhof nach Hamm Hbf, anschließend nach Wien Hbf.
4. Start/Ziel tauschen, Abfahrtszeit wechseln, Bus/Bahn filtern; Umstiege öffnen.
5. 360px/768px/Desktop sowie 200% Zoom und beide Themes prüfen.
6. Produktive Routenfehler, fehlende Daten und Ausfälle sichtbar prüfen.

--- Vorheriger Bericht ---

SO-BusLive-SoestPRO · SUCHRELEVANZ · 20260917-search-v4
====================================================
Ursachen: Fokus auf den aktuellen Ortsnamen ersetzte die Suchanfrage durch eine
leere Schnellwahl. Online-Treffer wurden unsortiert an lokale Treffer angehängt.
Scrollpositionen wurden übernommen. Halte waren nur alphabetisch sortiert.

Korrekturen:
- Ortsfeld wertet seinen sichtbaren Inhalt auch beim Fokussieren aus.
- Gemeinsame Relevanz: exakter Name, exakter Alias, Namensanfang, Aliasanfang,
  Wortanfang, Teiltreffer, Region/Zusatztext. Gleichwertige Treffer bleiben stabil.
- Lokale und Online-Ortstreffer werden gemeinsam vor dem Anzeigelimit sortiert.
- Neue Vorschläge setzen Scrollposition und alte Tastaturmarkierung zurück.
- Neue Eingabe, Schließen und Auswahl brechen überholte Ortsanfragen ab.
- Auch Haltestellensuche, Linienfilter und Nach-Hause-Adresssuche priorisieren
  genaue Treffer. Adresssuche verwirft veraltete Antworten und bricht diese bei
  Auswahl, Leeren und Schließen ab. Diakritika werden bei Relevanz normalisiert.
- Alle vorherigen Europa-, Fortschritts- und Überdeckungsänderungen enthalten.

Validierung: 102 Assertions erfolgreich (bisher 89 plus 13 gezielte Prüfungen).
Neue Tests führen auch die tatsächliche initCitySelector-Fokus-/Eingabelogik aus:
Soest vor Lippstadt, keine unpassenden Schnellwahlorte, Scrollposition oben.
Weitere Fälle: Wien/Wiener Neustadt, Vienna-Alias, RE11/RE110, Haltestellen,
Adressnummern und Zürich/ZURICH. JavaScript-Syntaxprüfung erfolgreich.
Visuelle Browserabnahme und PHP-Laufprüfung bleiben hier technisch offen.

Vollständiges Updatepaket mit REPORT.txt. Bestehende data-Verzeichnisse behalten.

--- Vorheriger Bericht ---

SO-BusLive-SoestPRO · ÜBERDECKUNGEN · 20260917-overlay-v3
=====================================================
Ursache: Leaflet-Panes und Controls (z-index bis 1000) lagen außerhalb eines
begrenzenden Karten-Stacking-Kontexts über der Kopfzeile (z-index 30).
citySuggestions mit z-index 5000 konnte den Elternkontext nicht verlassen.

Korrekturen:
- Kartenpanel und Leaflet-Container begrenzen ihre Ebenen mittels isolation.
- Kopfzeile mit Ortssuche liegt über Karte und mobilen Tabs.
- Fahrplan-, Abfahrts-, Teilen- und Nahbereichsdialoge liegen auch über dem
  Karten-Vollbild; Standortfreigabe und Toasts entsprechend darüber.
- Schwebender Freigabe-Button wird bei geöffnetem Dialog ausgeblendet.
- Kartenwerkzeuge reservieren horizontal Platz für die Zoomtasten.
- Zoomhinweis darf umbrechen; im mobilen Karten-Vollbild unter den Werkzeugen.
- CSS-Cacheversion aktualisiert, auch für die bisher fest versionierte Teilen-CSS.

Prüfung: CSS-Ebenen und DOM-Eltern für Ortssuche, Kartensteuerung, Dialoge,
Standortfreigabe, native Haltesuche und Vollbild geprüft. Native Haltesuche
verwendet bereits die Browser-Top-Layer via showModal().
Keine Änderung an Fahrtdaten oder Ortssuche-Logik. Visuelle Browserabnahme bleibt
offen (hier technisch blockiert). Bitte besonders Handy/Hoch- und Querformat,
Ortssuche über Karte und Fahrplan im Karten-Vollbild am Server prüfen.
Vollständiges Paket; vorhandene data-Verzeichnisse beim Aktualisieren behalten.

--- Vorheriger Bericht ---

SO-BusLive-SoestPRO · EUROPA & FAHRTFORTSCHRITT · 20260917-europe-progress-v2
============================================================================
Dieser Abschnitt ersetzt frühere Statusangaben. Vollständiges Updatepaket.

ÄNDERUNGEN
- Großer Prozentbalken im Fahrplandialog und auf geteilten Fahrten: zeitlicher
  Fortschritt über die gesamte Fahrt, von 0 bis 100 %, laufend aktualisiert.
  Ein Kartenausschnitt ist ausdrücklich als solcher beschriftet. Kein GPS- oder
  Entfernungsmesswert. Echtzeit-Fahrzeiten werden berücksichtigt, wenn geliefert.
- Fehlende/ungültige Zeiten und Ausfälle erzeugen keine erfundene Prozentzahl.
  Veraltete Fahrzeiten werden nach drei Minuten als solche gekennzeichnet.
- Geöffneter Fahrplan fragt alle 60 Sekunden neue Fahrzeiten ab; Hintergrundtabs
  pausieren diese Abfrage. Die Scrollposition bleibt dabei erhalten.
- Ortssuche: Deutschland-Länderfilter und Deutschland-Koordinatengrenzen entfernt.
  Neuer Suchcache verhindert Übernahme alter leerer Treffer für Wien.
  Europäische Schnelltreffer funktionieren auch bei ausgefallener Online-Suche;
  Wien/Vienna, Prag/Prague und weitere internationale Schreibweisen unterstützt.
- Typkennzeichnungen aus dem Quellmodus: Regionalzug, Fernzug, S-Bahn, U-Bahn,
  Straßenbahn, Bus und Rufbus. Feste Bus-Beschriftungen in Dialogen, Teilen und
  Freigabeverwaltung korrigiert. Interner Z:-Präfix aus Tooltip entfernt.
- Große native Fortschrittsanzeige, flexible mobile Titelzeilen, Reisehilfe ergänzt.
- Mitgelieferter ÖPNV-Planer als Referenz ausgewertet, keine Referenzcaches kopiert.

VALIDIERUNG
89 automatisierte Assertions erfolgreich:
  node tests/position-quality.mjs (13)
  node tests/transport.mjs (37)
  node tests/requests.mjs (9)
  node tests/progress-europe.mjs (30)
Alle sechs JavaScript-Module bestehen die Syntaxprüfung.
Geprüft: Prozentgrenzen, Mitternacht/Zeitzone, geänderte Ankunft, ungültige Zeiten,
Ausfall, veraltete Daten, HTML-Escaping, Wien/Vienna und Fahrzeugbezeichnungen.
PHP-Laufprüfung, visuelle Browserabnahme und produktive Live-Abnahme sind offen:
Hier ist keine PHP-Laufzeit verfügbar; Browserprüfung war technisch blockiert.

GRENZEN
Europäische Ortsauswahl ist freigeschaltet; vollständige europaweite Fahrplandaten
oder Echtzeitinformationen können nicht garantiert werden. Quelle: Transitous.
Weiterhin kein eigener Start-Ziel-Router; Reisehilfe verlinkt Verbindungssuche.
Keine erfundenen Fahrzeug-GPS-Daten. Der Balken einer geteilten Fahrt bezieht sich
auf die gesamte Fahrt; deren Countdown kann sich auf einen gewählten Zielhalt
beziehen. Abweichungen sind deshalb möglich und entsprechend beschriftet.
Die abgebildeten zusätzlichen Routenfilter wurden nicht als funktionslose
Bedienelemente übernommen.

INSTALLATION
Dateien im bestehenden SO-BusLive-SoestPRO-Verzeichnis aktualisieren.
Bestehende data-Verzeichnisse, Freigaben und Serverkonfiguration behalten.
Vorher Sicherung anlegen. Danach Wien auswählen, Bahnfilter und einen Zugfahrplan
sowie eine geteilte Fahrt auf dem Smartphone prüfen. Kein Deployment durchgeführt.

--- Vorheriger Änderungsbericht zur Nachvollziehbarkeit ---

SO-BusLive-SoestPRO · BUS & BAHN · 20260916-bus-bahn-v1
====================================================
Status: implementiert, 59 automatisierte Assertions erfolgreich.
PHP-Laufprüfung, visuelle Browserabnahme und Live-Abnahme OFFEN.
Dieser Abschnitt hat Vorrang vor älteren Reports. Zielpfad bleibt unverändert:
https://so-portal.de/SO-BusLive-SoestPRO/

FUNKTIONSUMFANG
- Bus / Bahn / Beides als große Auswahl; Auswahl wird lokal gespeichert.
- Bahn umfasst gemeldete Regional-, Fern-, Nacht-, S-, U- und Straßenbahnmodi.
- Fahrzeugtyp wird aus dem Modus der Datenquelle bestimmt, nicht aus Liniennamen.
- Blaue eckige Bahnmarker; Busmarker bleiben separat erkennbar. Linienverläufe und
  Fahrten werden gemeinsam gefiltert. Eigenes GPS bleibt ein getrennter Layer.
- Bahnhof-/Haltestellensuche im geladenen Stadtgebiet; Treffer öffnen Abfahrten.
- Abfahrten mit Richtung, Zeiten, Verspätung, Ausfall, Gleis/Steig (soweit geliefert).
  Antippen einer Abfahrt mit tripId öffnet den vollständigen Fahrplan.
- Zugfahrpläne und geteilte Zugfahrt inklusive geschätzter Position und Countdown.
- Neue Reisehilfe in einfachen Worten unter reisehilfe.php; externer Link zu
  Transitous für eine durchgehende Start-Ziel-Verbindung mit Umstiegen.
  Kein eigener Start-Ziel-Router und keine Anschlussgarantie in diesem Paket.

DATENWEGE UND LOGIK
- includes/transport.php + assets/js/transport.js klassifizieren Quellmodi.
- api/bus-live.php übernimmt Bus-/Bahnabschnitte aus dem bestehenden map/trips-
  Abruf. Keine zusätzlichen Live-Abrufe oder künstliche Buslinien-/Geofilter.
- api/stops.php: BUS-Einschränkung entfernt, bekannte fremde Verkehrsmittel
  ausgeschlossen; unbekannte Typen bleiben neutral sichtbar. Neue Cacheversion.
- api/stop-times.php: BUS-Einschränkung entfernt, bis 40 gemeldete Abfahrten;
  interne Bahnkennungen mit Z:-Präfix verhindern Namenskonflikte (z.B. S11).
- api/trip.php übernimmt auch Bahn-Legs. joinInterlinedLegs=false bleibt erhalten;
  R49/R81-Durchbindung wird nicht auf ein einzelnes Leg gekürzt.
- live-share.php speichert den Quellmodus; alte Freigaben bleiben lesbar.
- Statische Busnetz-Referenz (api/network.php) unverändert; Bahnlinien kommen aus
  den geladenen Fahrtabschnitten. Kein vollständiges dauerhaftes Schienennetz.
- Aktiver Verkehrsmittelfilter wird auf Karte, Linien, Fahrten, Halte und Abfahrten
  angewandt. Schul-/E-Wagenfilter gilt nicht für Bahnfahrten; neuer Standard aus,
  bestehende gespeicherte Wahl bleibt erhalten.
- Antworten eines inzwischen verlassenen Ortes werden verworfen. Danach wird der
  aktuelle Ort angefragt; Fehler-/Retry-Status wird beim Ortswechsel zurückgesetzt.
- Nahbereichsempfehlungen lassen als ausgefallen gemeldete Abfahrten aus.

MOBILE / SENIOREN
- Helles Design standardmäßig, ausdrücklich gespeichertes grünes Theme bleibt.
- Große 54px Hauptschaltflächen mit Text; häufige Aktionen vor Zusatzfunktionen.
- Zusatzfunktionen aufklappbar, Haltesuche im nativen Dialog (Escape/Focus-Trap).
- Größere Fahrplan-/Abfahrtsschrift, Gleise, ausreichende Touch-Ziele, sichtbarer
  Tastaturfokus, reduzierte Animation bei entsprechender Systemeinstellung.
- Browserzoom bleibt erlaubt. Keine geänderten Architektur-/Datenschutzfreigaben.

VALIDIERUNG
node tests/position-quality.mjs: 13 Assertions erfolgreich.
node tests/transport.mjs: 37 Assertions erfolgreich (echte Parser-/Filterfunktionen,
Typen, RE/ICE-Bezeichnungen, S11-Kollision, Schulfilter, Marker, TTL).
node tests/requests.mjs: 9 Assertions erfolgreich (verspätete Ortsantworten verwerfen,
Ladesperren freigeben, neue Abfrage einplanen).
Alle fünf JavaScript-Module syntaktisch geprüft, lokale Imports und neue DOM-IDs
kontrolliert. ZIP-Integrität geprüft. Kein Testverkehr an echte Freigabeempfänger.
Browser-Prüfung versucht: Cloud-Browser blockiert lokale Vorschau-URLs; keine
visuelle Bestätigung behauptet. PHP-CLI fehlt; kein php -l oder PHP-Integrationstest.
API-Schemaabruf nicht verfügbar; Erweiterung verwendet bestehende Antwortfelder,
bekannte Verkehrsmodi und generische RAIL-Erkennung. Betreiberabdeckung offen.
Referenz: https://transitous.org/api/ (Datenquelle und offizielle Dokumentation).

GRENZEN / RISIKEN
Fahrzeugpositionen bleiben Schätzungen entlang der Route, keine GPS-Ortung.
Ein Datenabruf bestätigt nicht die Aktualität einer Betreibermessung. Bahnfahrten
erscheinen nur, wenn Quelle, Stadtfenster und Zeiten sie liefern. Kein Marker ist
kein Ausfallnachweis. Einzelne Details wie Gleise können fehlen. Die erweiterte
Haltestellenmenge und Abfahrtsantwort können größer sein; Abrufintervalle und
serverseitiger Cooldown bleiben begrenzt.
Bei >3 Minuten ohne frischen Abruf werden Fahrzeugschätzungen weiter ausgeblendet.
Bus-Grundnetz bleibt unabhängig vom Live-Fenster und im Bus-/Beides-Modus wählbar.

LIVE-ABNAHME NACH UPLOAD
1. PHP-Dateien auf dem Zielserver prüfen (PHP 8.1+ wie bisher), Konsole auf Fehler.
2. Handy 360/390px, Tablet und PC: hell/grün, Textzoom, Dialog schließen, Scrollen.
3. Bus / Bahn / Beides: nur passende Marker/Linien/Halte; Bus-Grundnetz bleibt.
4. Soest Bahnhof suchen, Bahnfahrt mit Quelle vergleichen, RE/RB/ICE-Name vollständig,
   Gleis, Verspätung, Fahrplan und Richtung prüfen. Fehlende Gleise nicht erfinden.
5. Bus S11 und ggf. Bahn S11 getrennt; R49/R81-Durchbindung und C2-Richtungen prüfen.
6. Bahn teilen: Empfängeransicht, Countdown, optional eigenes GPS, Linkende prüfen.
7. Schnell Ort wechseln: keine Rückkehr alter Ortsdaten. Datenausfall >3min testen.
8. Haltestellensuche ohne Treffer, Quellenfehler und Bahnfilter ohne Zugdaten prüfen.

UPLOAD / ROLLBACK
Serverordner vorher sichern. Inhalt des Projektordners über bestehende Dateien
kopieren. Alle neuen Dateien mitnehmen (transport.js, transport.php, reisehilfe.php,
reisehilfe.css). Bestehende data/live-shares/ nicht löschen. Danach hart neu laden.
Rollback: vorheriges Komplettpaket zurückspielen; bestehende Freigabedaten erhalten.

--- HISTORIE ---

SO-BusLive-SoestPRO · 20260916-position-quality-v1
=================================================
Status: lokal logisch geprüft; PHP-/Browser-/Live-Abnahme noch offen.
Dieser Abschnitt hat Vorrang vor historischen Aussagen zur GPS-/Positionsqualität.

Befund und Ursachen
- Kartenmarker sind zeitbasierte Interpolation entlang der Route, keine Bus-GPS-Daten.
- Cache-Antworten übernahmen die alte Serveruhr und versetzten die Animation zurück.
- Kontinuitätssegmente konnten durch neue Cache-Dateizeiten unbegrenzt weiterleben.
- Ältere Fahrtabschnitte konnten neben aktualisierten Abschnitten derselben Fahrt bleiben.
- Geteilte Karte bewegte Marker nur beim Abruf, hielt veraltete Marker bis 12 Minuten.
- Formulierungen wie "bestätigte Halteposition" waren nicht durch Messdaten gedeckt.

Änderungen
api/bus-live.php: aktuelle Antwortuhr auch bei Cache, HTTP no-store bei unverändertem
serverseitigem Abrufcache/Backoff. Pro Abschnitt eigenes fetchedAt (Abrufzeit, KEINE
Messzeit). Kontinuität höchstens 180 Sekunden ab ursprünglichem Abruf; neue Abschnitte
einer Fahrt verdrängen alte. Keine zusätzliche Linien-/Geofilterung.
assets/js/position-quality.js: gemeinsame Auswahl aktiver Abschnitte vor Vorschauen,
zeitlich begrenzte Schätzung, Echtzeitzeiten/Fahrplan getrennt. Terminalnachlauf 60 s.
app.js: Qualitätsanzeige, Datenalter im Tooltip, keine zusätzliche 12-Minuten-Haltefiktion.
Geteilte Fahrt: gleiche Auswahl/Alterung, Animation pro Sekunde, Marker nach Ablauf
entfernen; Ausfall unterdrückt Marker/Countdown, beendete Freigabe entfernt Busmarker.
Countdown verwendet serverkorrigierte Uhr. Ausfallhinweis wird bei Erholung entfernt.
Layout: gut lesbare Qualitätszeile, aufklappbare Erklärung statt horizontal versteckter
Hinweise. Status der geteilten Fahrt unter der Karte statt über den Fahrzeugen.
Neue Assetrevision; beide Seiten laden das neue gemeinsame JS-Modul.

Grenzen
Kein neuer GPS-Datenfeed. Gleichmäßige Bewegung zwischen Halten bleibt eine Schätzung.
Ein frischer Abruf beweist nicht, dass der Betreiber gerade eine neue Messung geliefert
hat. fetchedAt wird ausdrücklich nur als Datenabruf bezeichnet. Kein künstliches
Beschleunigen/Bremsen, weil solche Annahmen die reale Genauigkeit nicht belegen.
Fahrten-/Liniennetz, GPS des Nutzers und Fahrzeugmarker bleiben getrennte Systeme.

Validierung
- 13 automatisierte Assertions: aktuelle Fahrt, überlappende Abschnitte, Vorschau,
  Haltezeit, Terminalablauf, ungültige/alte/zukünftige Zeitstempel, Qualitätsbezeichnung.
- JavaScript-Syntaxprüfung der geänderten Module erfolgreich.
- Änderungsumfang/Backend-Cachepfade im Quelltext geprüft.
- PHP-CLI und Chromium fehlen in der Umgebung. PHP-Lint und visuelle Browserabnahme
  konnten daher nicht ausgeführt werden. Keine Behauptung einer Live-Bestätigung.

Abnahme nach Upload
1. index.php auf Firefox/Chrome und Handy (390 px), helles/grünes Theme prüfen.
2. Qualitätszeile und aufklappbare Quelle; Karte, Haltestellen, GPS und Linienfilter.
3. Mehrere Cache-Abrufe: Uhr darf nicht zum alten Abrufzeitpunkt zurückspringen.
4. Nach erfolgreichem Abruf Verbindung >3 Minuten unterbrechen: Marker verschwinden,
   Liniennetz bleibt. Nach Wiederverbindung neue Marker prüfen.
5. Geteilte Fahrt: sekündliche Schätzung, Datenalter, Countdown, GPS separat;
   Link beenden, Ausfall testen; schmale Ansicht ohne verdeckte Karte prüfen.
6. R49/R81-Durchbindung und C2-Richtungsgruppen wie zuvor prüfen.
Risiko: Bei längerem Datenausfall werden bewusst weniger Busmarker angezeigt.
Rollback: vorheriges vollständiges Paket wiederherstellen. Vorher Serverdateien und
bestehende data/-Inhalte sichern; keine Freigabedaten löschen.

SO-BusLive-SoestPRO · AKTUELLER REPORT / REGRESSIONSSCHUTZ
============================================================
Stand: 30.08.2026 · Build 20260830-pro-metro503-readability-v5
Live-Ziel: https://so-portal.de/SO-BusLive-SoestPRO/

WICHTIGER AKTUELLER STATUS
--------------------------
Dieser Abschnitt hat Vorrang vor älteren historischen Hash-/Schutzangaben weiter unten.
Der Nutzer meldete auf der Live-Seite reproduzierbare HTTP-503-Fehler bei frei gesuchten
Großstädten, insbesondere Hamburg, Berlin und München. Die Konsole zeigte weiterhin den
alten Asset-Stand `20260830-pro-city-mobile-fullscreen-gps180-v1`; damit war der vorherige
Client-Backoff live noch nicht aktiv. Zusätzlich lieferte api/network.php bei Metropolen 503.

FEHLERBILD
-----------
- XHR api/bus-live.php?...radiusKm=9 -> HTTP 503.
- XHR api/network.php?...radiusKm=9 -> HTTP 503.
- app.js meldete daraufhin wiederholt `[SO-BusLive] Datenfehler Error: HTTP 503`.
- Betroffen gemeldet: Hamburg, Berlin, München.
- `No Listener: tabs:outgoing.message.ready` stammt nicht aus dem SO-BusLive-Codepfad
  und wird als Browser-/Extension-Nebenmeldung behandelt.

URSACHE
-------
1. Freie Großstadtprofile konnten vom alten Client noch mit radiusKm=9 angefragt werden.
   Der Server begrenzte das zwar bereits teilweise, erzeugte aber weiterhin relativ große
   Transitous/MOTIS-map/trips-Abfragen.
2. api/network.php startete für dieselbe freie Stadt zusätzlich eine zweite map/trips-Abfrage
   für Liniengeometrien. Das verdoppelte unnötig die Last, obwohl die Live-Segmente bereits
   Polylinien enthalten.
3. Der alte Client war live noch im Browsercache/auf dem Server sichtbar und behandelte
   HTTP 503 als Exception.
4. Transitous ist ein Community-/Best-Effort-Dienst; ressourcenintensive oder viele Abfragen
   können temporär begrenzt werden. Deshalb muss die App mit Degraded-/Cache-Zuständen
   korrekt weiterarbeiten und darf den Upstream nicht im 20-Sekunden-Takt erneut belasten.

V4-ÄNDERUNGEN
--------------
A) api/bus-live.php – BEWUSST GEÄNDERT
- Erwartbare Upstream-Ausfälle werden an den Browser als HTTP 200 + `degraded:true`
  geliefert, nicht mehr als HTTP 503. Das schützt sogar noch einen alten gps180-v1-Client.
- Retry-Cooldown: 120 Sekunden serverseitig.
- vorhandener letzter guter Live-Cache kann bis 15 Minuten als klar markierter stale-Stand
  weiter angezeigt werden.
- freie Geo-/Metropolenprofile werden progressiv klein abgefragt:
  1. bis 4,0 km Kernradius / 30 Minuten Zukunft
  2. bis 2,5 km Kernradius / 15 Minuten Zukunft
- maximal zwei Upstream-Versuche pro Cooldown-Zyklus.
- kein serverseitiger Linien-Whitelist-/Grundnetzfilter für Live-Fahrzeuge.

B) api/network.php – BEWUSST GEÄNDERT
- Für freie `geo-*`-Orte (Berlin/Hamburg/München usw.) wird KEINE zusätzliche
  Transitous-map/trips-Netzabfrage mehr gestartet.
- Der Endpunkt liefert HTTP 200 mit `dynamicLiveFallback:true`; Linienpolylinien kommen
  dort aus den ohnehin geladenen Live-Segmenten.
- Für feste Stadtprofile bleibt die additive Netzreferenz erhalten, mit 180 Sekunden
  Fehler-Cooldown und bis zu 7 Tage altem stale-Netzcache.
- Fehler-Cooldown-Datei wird nicht mehr bei jedem Cooldown-Lesezugriff neu angefasst.

C) api/stops.php – RESILIENCE ERGÄNZT
- Haltestellenquelle erhält 300 Sekunden Cooldown.
- letzter gültiger Haltestellenstand kann bis 7 Tage als stale-Cache dienen.
- erwartbare Upstream-Ausfälle werden ebenfalls nicht mehr als HTTP 503 an den Browser
  propagiert.
- dynamische Großstadt-Haltestellen-BBox ist kompakter (max. ca. 6 km).

D) includes/city-profiles.php
- ein alter Client darf weiterhin `radiusKm=9` senden; der Server clamp't freie Orte
  jetzt zwingend auf 2,5–4,0 km Live-Radius.
- dadurch ist die Lastbegrenzung SERVERSEITIG und nicht von einem frischen JS-Cache abhängig.

E) assets/js/app.js
- Buildkennung wird in der Konsole ausgegeben.
- parallele doppelte Live-/Netz-/Stop-Abfragen werden verhindert.
- 503/429 bzw. `degraded:true` führen zu Backoff statt Stack-Flood.
- neue freie Orte senden maximal radiusKm=4.
- leere dynamische Netzreferenz wird für 30 Minuten als geladen betrachtet, damit der
  lokale network.php-Fallback nicht alle 20 Sekunden erneut abgefragt wird.

F) index.php / config.php
- Asset-Revision: `20260830-pro-metro503-readability-v5`.
- HTML erhält no-store/no-cache, damit ein neuer Revisionsstand schneller sichtbar wird.
- Trotzdem bleibt die Backend-Kompatibilität entscheidend: Selbst wenn kurz noch v1 geladen
  wird, sollen die betroffenen APIs keinen 503 mehr an diesen Client durchreichen.

AKTUELLE DATEI-HASHES
----------------------
- api/bus-live.php   23c6799e3facf2156683ca8e3d3574d55fdc9396b312a54d4c5f3ca821ec2128
- api/network.php    350341e43ff0196a50652f8779b2bb9b5d9268351f386cf7678bb037a593fcd4
- api/stops.php      8462dc61de901f2c4058ba1c58215914005846f09ad006c74ebf0ef328d33c74
- api/stop-times.php 008148a398927e49ce8a6a07ae53731c2d91adcd93d5bf73180cb39f82f76257
  `stop-times.php` ist gegenüber dem gelieferten PRO-Ausgangsstand weiterhin unverändert.

REGRESSIONSSCHUTZ
------------------
- Live-Fahrzeugmarker niemals durch festes Soester Grundnetz oder serverseitige Linien-Whitelist
  abschneiden. Nur Nutzer-Linien-/Favoritenfilter dürfen Marker ausblenden.
- Schul-/E-Wagen-Filter bleibt ausschließlich Listenfilter.
- Live-Marker, Linien-/Routennetz und eigener GPS-Punkt bleiben getrennte Layer.
- Pausen-/Letzte-Position-Haltefunktion bleibt clientseitig bestehen.
- 180-Tage-GPS-Präferenz speichert nur den Zustimmungsstatus, niemals Koordinaten/Verlauf.
- Ortssuche, Karten-Vollbild, Favoritenfilter und Mobile-Scroll dürfen durch 503-Fixes nicht
  zurückgebaut werden.

LOKALE ABNAHME V4
------------------
[OK] PHP-Syntax bus-live.php / network.php / stops.php.
[OK] JavaScript-Syntax app.js.
[OK] Dynamisches München mit vom alten Client gesendetem radiusKm=9 wird serverseitig auf
     radiusKm=4 begrenzt.
[OK] Simulierter Cooldown bus-live.php -> HTTP 200 + degraded:true + Retry-After:120.
[OK] Dynamisches München network.php -> HTTP 200 + dynamicLiveFallback:true, ohne Upstream-Aufruf.
[OK] Simulierter Cooldown network.php (feste Stadt) -> HTTP 200 + degraded:true.
[OK] Simulierter Cooldown stops.php -> HTTP 200 + degraded:true.
[OK] stop-times.php bleibt bytegenau zum gelieferten PRO-Ausgangsstand.

NOCH LIVE ZU PRÜFEN NACH UPLOAD
--------------------------------
[ ] Seitenquelltext / Konsole zeigt Build `20260830-pro-metro503-readability-v5`.
[ ] Hamburg: bus-live.php und network.php liefern im Browser KEIN HTTP 503 mehr.
[ ] Berlin: dito.
[ ] München: dito.
[ ] Bei erreichbarer Transitous-Quelle erscheinen Live-Fahrzeuge im kompakten Innenstadtfenster.
[ ] Bei nicht erreichbarer Quelle erscheint ein verständlicher Retry-/Degraded-Hinweis statt
    einer Fehlerflut.
[ ] Soest/Unna weiterhin Live-Marker, Netz, Haltestellen, GPS und Favoriten prüfen.

TESTGRENZE
-----------
Die Ausführungsumgebung konnte api.transitous.org selbst nicht per DNS erreichen. Deshalb ist
die V4-Abnahme lokal gegen simulierte Upstream-Ausfälle und die Serverantworten erfolgt. Es wird
nicht behauptet, dass Transitous für jede Metropole im Testzeitpunkt erfolgreiche Live-Daten
geliefert hat. Ziel dieses Hotfixes ist zusätzlich, einen realen Upstream-Ausfall sauber und
lastschonend zu behandeln.


HISTORISCHER PROJEKTREPORT / FRÜHERE REGELN
============================================
SO-BusLive Soest · REPORT / REGRESSIONSSCHUTZ
================================================
Stand: 29.08.2026
Live-Referenz: https://so-portal.de/SO-BusLive-Soest/
Anleitung: https://so-portal.de/SO-BusLive-Soest/entdecken.php#anleitung

ZWECK DIESER DATEI
------------------
Diese Datei ist vor JEDEM zukünftigen Build, Hotfix oder Server-Upload zu lesen.
Sie schützt die bereits funktionierende Bus-/Routenlogik vor erneuten Regressionen.
Änderungen an den unten als geschützt markierten Grundregeln dürfen nur nach einem
expliziten Auftrag erfolgen und müssen anschließend gegen die Abnahme-Checkliste
geprüft werden.

GESCHÜTZTE AUSGANGSBASIS
------------------------
Vom Nutzer gelieferter funktionierender Referenzstand:
SHA-256 des Original-ZIPs:
4f5bdb3d9afc3cceb74d08aa145c395423eb13180b7bbf1924d291738c467739

Kritische Originaldateien, die in diesem Build BYTEGENAU aus der Referenz übernommen sind:
- api/bus-live.php
  SHA-256: 8a90ebd5d5bf045c871a3c5acb3163e3177d0f62c4fcf1ce01d3438fb9bef161
- api/stop-times.php
  SHA-256: 25799fb7ae6c2004ee5a4269b24453ca3bddb92fa7443d233c0ac7dd96b0657e

Diese beiden Dateien dürfen nicht vorsorglich umgebaut, mit einer Linien-Whitelist
versehen oder geografisch vorgefiltert werden. Wenn eine Änderung dort wirklich nötig
ist, muss sie ausdrücklich beauftragt, begründet und separat getestet werden.

VERBINDLICHE ARCHITEKTUR
------------------------
1. LINIENNETZ != KURZES LIVE-FENSTER
   Das Soester Grundnetz bleibt in der Linienauswahl sichtbar, auch wenn aktuell
   kein Bus der Linie im ca. dreistündigen Live-Fenster vorhanden ist.
   Live-Daten bestimmen nur, welche konkreten Fahrten/Busse gerade aktiv sind.

2. LIVE-API NICHT KAPUTTFILTERN
   api/bus-live.php liefert weiterhin die bewährten Transitous/MOTIS-Busdaten aus
   dem bestehenden großen Datenfenster. Keine serverseitige Linien-Whitelist.
   Kein "Soest-Ankerfilter" in dieser Live-API.

3. SOEST-ANZEIGE IM CLIENT
   Die Oberfläche zeigt das fest bekannte Soester Grundnetz plus zusätzliche Linien,
   die in den aktuellen Live-Daten tatsächlich einen eindeutigen Soest-Bezug besitzen.
   Dadurch werden zufällige Fremdlinien aus dem großen Datenfenster (z. B. 32/661 aus
   anderen Orten) nicht als "Busnetz Soest" präsentiert, ohne die Original-Live-API
   zu beschneiden.

4. ADDITIVE NETZROUTEN
   api/network.php ist ausschließlich eine additive Referenz für Linienverläufe,
   damit Routen auch abends sichtbar bleiben, wenn gerade kein Fahrzeug der Linie
   im kurzen Live-Fenster fährt. Ein Fehler dieses Endpunkts darf die Hauptseite
   nicht lahmlegen; der Client fällt auf die bewährten Live-Polylinien zurück.
   Die Linienliste dieses additiven Endpunkts darf niemals die Live-Fahrzeuge filtern.

5. BUSPOSITIONEN != NETZFILTER
   Live-Busmarker werden ausschließlich aus den von api/bus-live.php gelieferten
   aktuellen Fahrtsegmenten aufgebaut. Das feste Soester Grundnetz und die dynamische
   Linienliste dürfen diese Marker NICHT vorfiltern. Nur ein vom Nutzer ausdrücklich
   gewählter Linien- oder Favoritenfilter darf die sichtbaren Busmarker einschränken.
   Regression vom 29.08.2026: activeRows() verwendete lineVisible(); lineVisible()
   erlaubte nur Grundnetz/dynamisch erkannte Linien. Dadurch konnten vorhandene
   Live-Fahrzeuge auf der Karte verschwinden. Schutzregel: activeRows() verwendet
   ausschließlich lineSelected(); die Netzprüfung bleibt auf Routen/Linienliste begrenzt.

   Technischer Hinweis: Die Markerposition wird im bewährten Client aus dem aktuellen
   MOTIS-Fahrtsegment, dessen Polyline und Abfahrts-/Ankunftszeit interpoliert. Sie ist
   daher nur so live/genau wie die von Transitous/MOTIS gelieferten Daten und stellt
   nicht automatisch eine direkte GPS/AVL-Koordinate des Fahrzeuges dar. Wenn die
   Quelle keine aktuell aktive Fahrt liefert, darf der Client zur Orientierung bald
   startende Fahrten als klar gekennzeichnete Vorschau-Marker zeigen. Diese Marker
   muessen optisch/textlich von echten aktiven Fahrzeugpositionen unterscheidbar bleiben.

6. EIGENER GPS-STANDORT IST EIN EIGENER LAYER
   Der pulsierende Nutzerstandort liegt ausschließlich auf userLayer und darf weder
   durch renderRoutes(), renderMarkers(), Linienfilter noch durch Bus-Refresh gelöscht
   werden. Eine gespeicherte 180-Tage-Präferenz muss beim erneuten Seitenaufruf sowie
   nach Tab-/App-Rückkehr den Standort-Watch wieder aufnehmen, soweit Browser/OS dies
   zulässt. Safari/iOS darf nicht daran scheitern, dass navigator.permissions.query
   für Geolocation fehlt oder anders implementiert ist. In diesem Fall wird direkt
   navigator.geolocation.watchPosition() verwendet; Browser/OS behält trotzdem die
   alleinige Kontrolle über die eigentliche Standortberechtigung.

AKTUELLES SOESTER GRUNDNETZ
---------------------------
Quelle für das dauerhafte Grundnetz ist der aktuelle RLG-Liniennetzplan Soest 2026
(gültig ab 25.05.2026) plus die aktuelle Expresslinie X51 Warstein <-> Soest.

StadtBus:
- C1
- C2
- C3
- C4
- C5
- C7
- C8

Regionallinien / Express:
- R36
- R47
- R49
- R51
- R54
- R81
- X51

Weitere im RLG-Liniennetz Soest ausgewiesene Linien:
- 532
- 569
- 583
- 644
- T35
- T37
- T39
- M4
- S11

WICHTIG: Ergänzungs-, Schul-, Taxi-/Kleinbus- oder zeitweise verkehrende Linien
(z. B. 528, 530, 531, 552, 630, 633, 634, 635, 647 usw.) dürfen NICHT pauschal
geblockt werden. Wenn Transitous/MOTIS sie aktuell mit eindeutigem Soest-Bezug
liefert, dürfen/sollen sie dynamisch zusätzlich erscheinen. So bleibt das System
zukünftigen Fahrplanänderungen gegenüber robust.

C2 / EHEMALIGE C6
-----------------
- C6 wird im aktuellen Soester Grundnetz nicht als eigenständige Linie geführt.
- Seit der Netzänderung zum 25.05.2026 ist der frühere Hermannstraße-Ast Teil der C2.
- C2 besitzt mehrere Ziele/Äste und muss nach dem tatsächlich gelieferten Headsign /
  Fahrziel getrennt dargestellt werden (z. B. Gotlandweg, Hermannstraße,
  Goldarbeiterweg / weitere aktuelle Ziele laut Fahrplandaten).

RICHTUNGEN SIND PFLICHT
-----------------------
Buslinien fahren in der Regel in beide Richtungen. Die UI darf eine Linie niemals
so darstellen, als gäbe es grundsätzlich nur eine Richtung. Aktuelle Fahrten werden
nach tatsächlichem Ziel/Headsign gruppiert. Wenn im Live-Zeitfenster nur eine Richtung
vorhanden ist, bedeutet dies nur: in diesem Fenster wurde gerade nur diese Richtung
geliefert. Es darf daraus keine dauerhafte Einrichtungs-Logik entstehen.

R49 <-> R81 DURCHBINDUNG
------------------------
- R49 und R81 können am Bahnhof als zusammenhängender Fahrzeugumlauf / Linienwechsel
  weitergeführt werden.
- Im Fahrplan soll deshalb eine gelieferte Linienfolge R49 -> R81 bzw. R81 -> R49
  sichtbar werden.
- api/trip.php verwendet ABSICHTLICH joinInterlinedLegs=false.
  Hintergrund: MOTIS liefert stay-seated-Durchbindungen dann als getrennte Legs mit
  ihren jeweiligen Liniennummern. joinInterlinedLegs=true würde diese Informationen
  zu einem Leg zusammenziehen und den sichtbaren Linienwechsel verschlechtern.
- Diese Einstellung nicht ohne Prüfung der aktuellen MOTIS-Dokumentation ändern.

FAVORITEN
---------
- Linien können mit Stern als Favorit gespeichert werden.
- Speicherung ausschließlich lokal im Browser (localStorage), ohne Benutzerkonto.
- Favoriten dürfen die Grund-/Live-Daten nicht verändern, sondern nur die Ansicht.

"NACH HAUSE"
-------------
- Eigene Seite: nach-hause.php
- Adresssuche mit Vorschlägen (typeahead/T9-ähnlich), damit nicht alles ausgeschrieben
  werden muss.
- Zeigt geeignete Haltestellen in Zielnähe.
- Zuhause-Adresse wird nur gespeichert, wenn der Nutzer dies ausdrücklich auswählt.
- Keine automatische Server-Datenbank für private Zuhause-Adressen.

FAHRT TEILEN / TOKEN
--------------------
- Bei einer konkreten ausgewählten Busfahrt gibt es "Fahrt teilen".
- Der erzeugte URL-Token enthält nur:
  * Token-Version
  * Fahrt-ID
  * Linie
  * Fahrziel/Headsign
  * Erstellungszeit
- Der Token enthält KEINE GPS-Koordinaten, KEINE Zuhause-Adresse und KEINE Favoriten.
- Beim Öffnen wird die konkrete Fahrt fokussiert bzw. ihr Fahrplan geladen.

GPS / 180-TAGE-PRÄFERENZ
------------------------
- Standort ist freiwillig.
- Bei Einwilligung kann im Browser bis zu 180 Tage gespeichert werden, DASS der Nutzer
  die Standortfunktion verwenden möchte.
- Es werden dafür keine Standortkoordinaten als Bewegungsverlauf gespeichert.
- Die eigentliche Standortberechtigung bleibt immer unter Kontrolle von Browser/OS.
- Standortdarstellung: pulsierender Punkt auf einem eigenen Leaflet-userLayer.
- Eine gültige 180-Tage-Präferenz soll den Standort-Watch beim Seitenstart wieder
  aufnehmen, sofern Browser/OS die Berechtigung gewährt oder erneut abfragt.
- Safari/iPhone/iPad: fehlende oder eingeschränkte Permissions API darf den Start von
  navigator.geolocation.watchPosition() nicht stillschweigend verhindern.
- Nach pagehide/pageshow bzw. Rückkehr aus einem Hintergrund-Tab muss ein beendeter
  Watch bei gültiger Präferenz erneut gestartet werden.
- Buspositionen und eigener GPS-Punkt sind getrennte Layer/Funktionen.

WETTER
------
- Hauptseite zeigt aktuelles Wetter.
- Ohne Standortfreigabe: Wetter für Soest.
- Bei freiwillig aktivem GPS: Wetter kann auf den aktuellen Standort umschalten.
- Browserseitige Wetterabfrage über Open-Meteo.
- Wetteranzeige verlinkt zu https://jarvis-und-der-erdling.de/wetter/
- Standortdaten dürfen für die Wetteranzeige nicht als Bewegungsprofil gespeichert werden.

MOBILE / APPLE
--------------
- Android/Chrome und iPhone/iPad/Safari sind gleichberechtigte Zielplattformen.
- Safe Areas, Touch-Ziele, Scrollen, iOS-Eingabezoom, Visual Viewport und mobile
  Bottom-Sheets beachten.
- Kein toter Vollbild-Button auf Browsern, die die verwendete Fullscreen-API nicht
  zuverlässig anbieten.
- Hauptfunktionen müssen ohne Tastatur erreichbar sein.

ANLEITUNG / ABGEDECKTE LINIEN
-----------------------------
entdecken.php#anleitung dokumentiert:
- Karte / Linien / Fahrten
- beide Fahrtrichtungen / Ziel-Gruppierung
- GPS und 180-Tage-Präferenz
- Favoriten
- Nach Hause
- Fahrt teilen per Token
- Wetter
- aktuelles Soester Grundnetz sowie dynamische Ergänzungen

VERBOTENE REGRESSIONEN
----------------------
Folgende bereits verursachten Fehler dürfen NICHT wieder eingeführt werden:
- Feste serverseitige Linien-Whitelist in api/bus-live.php.
- Geografischer Soest-Ankerfilter, der die Original-Live-Daten abschneidet.
- Linienauswahl ausschließlich aus dem kurzen aktuellen Live-Fenster erzeugen.
- Dadurch nur R51 oder andere einzelne Linie anzeigen und C-Linien verschwinden lassen.
- Zufällige Fremdlinien wie 32/661 als dominantes "Busnetz Soest" darstellen.
- Die beiden geschützten Original-APIs ohne Auftrag umbauen.
- R49/R81 als grundsätzlich voneinander unabhängige Fahrten darstellen, wenn MOTIS
  eine stay-seated-Durchbindung liefert.
- Alle Fahrten einer Linie in nur eine Richtung zusammenwerfen.
- ZIP ohne obersten Ordner SO-BusLive-Soest/ erzeugen.
- Funktionierende Karten-/Routenlogik für ein Nebenfeature austauschen.
- Live-Busmarker durch Grundnetz-/Soest-Linienfilter aus activeRows() entfernen.
- userLayer beim Rendern/Refresh von Buslinien oder Routen leeren.
- Eine gültige 180-Tage-Standortpräferenz auf Safari/iOS wegen fehlender Permissions API
  stillschweigend ignorieren.

PFLICHT-ABNAHME VOR JEDEM ZIP
------------------------------
[ ] ZIP enthält als obersten Ordner SO-BusLive-Soest/
[ ] api/bus-live.php stimmt mit Schutz-Hash überein, sofern keine explizite Änderung beauftragt wurde
[ ] api/stop-times.php stimmt mit Schutz-Hash überein, sofern keine explizite Änderung beauftragt wurde
[ ] PHP-Syntax für alle PHP-Dateien fehlerfrei
[ ] JavaScript-Syntax für alle JS-Dateien fehlerfrei
[ ] manifest.webmanifest gültiges JSON
[ ] Keine fehlenden DOM-IDs für app.js / home.js
[ ] C1, C2, C3, C4, C5, C7, C8 im Grundnetz vorhanden
[ ] C6 nicht künstlich als aktuelle eigene Grundlinie eingeführt
[ ] R36, R47, R49, R51, R54, R81, X51 vorhanden
[ ] 532, 569, 583, 644, T35, T37, T39, M4, S11 vorhanden
[ ] Fremdlinien 32/661 nicht Teil des festen Grundnetzes
[ ] Dynamische echte Soest-Zusatzlinien werden nicht pauschal geblockt
[ ] Fahrten nach Richtung/Headsign getrennt
[ ] R49 <-> R81 und joinInterlinedLegs=false geprüft
[ ] Routen-Referenz ist additive Fallback-Schicht und darf Live nicht blockieren
[ ] Live-Busmarker werden aus Original-Live-Segmenten erzeugt und NICHT durch Grundnetzfilter abgeschnitten
[ ] Bei aktivem Linienfilter werden nur die bewusst gewählten Busmarker ausgeblendet
[ ] Eigener GPS-Punkt liegt auf userLayer und bleibt bei Bus-/Routen-Refresh erhalten
[ ] 180-Tage-Präferenz startet GPS auf Chromium sowie Safari/iOS bestmöglich wieder
[ ] pageshow/visibilitychange nehmen einen gemerkten, beendeten GPS-Watch wieder auf
[ ] Favoriten funktionieren nur als lokale Ansicht
[ ] Fahrt-Token enthält keine GPS-/Zuhause-Daten
[ ] Wetter ohne GPS = Soest; mit freiwilligem GPS = aktueller Standort möglich
[ ] 180-Tage-Präferenz speichert nur Einwilligungs-/Wunschstatus, keine Koordinaten
[ ] entdecken.php beschreibt Funktionen und Linien
[ ] Mobile/iOS-relevante CSS-/Viewport-Regeln vorhanden
[ ] QA-Bericht aktualisiert

REFERENZEN
----------
- Projekt: https://so-portal.de/SO-BusLive-Soest/
- Anleitung: https://so-portal.de/SO-BusLive-Soest/entdecken.php#anleitung
- RLG Liniennetzpläne: https://www.rlg-online.de/fahrt-planen/verbindungen/liniennetzplaene/
- RLG Liniennetz Soest 2026: https://www.rlg-online.de/fileadmin/startseite_rlg/fahrgast/fahrt_planen/liniennetzplan/slnp_soest_2026.pdf
- X51 Warstein - Soest: https://www.rlg-online.de/fahrt-planen/aktuelles/x51-warstein-soest/
- WeatherCore: https://jarvis-und-der-erdling.de/wetter/


MULTI-CITY-STAND 30.08.2026
---------------------------
- SO-BusLive ist jetzt nicht mehr hart auf Soest festgelegt. Die Hauptkarte hat
  eine Stadtwahl; Direktlinks wie ?city=unna laden direkt das passende Stadtprofil.
- Vorbereitete Stadtprofile: Soest, Unna, Dortmund, Hamm, Lippstadt, Werl,
  Arnsberg, Warstein, Menden, Iserlohn.
- Pro Stadt werden Live-Segmente, Netzrouten, Haltestellen, Adresssuche, Wetter-
  Default, Favoriten und Nach-Hause-Speicher getrennt behandelt.
- Soest nutzt weiter das gepflegte feste Grundnetz. Andere Staedte bauen die
  Linienliste aus den aktuell gelieferten Transitous/MOTIS-Live- und Netzdaten.
- Verifikation lokal: Unna lieferte 1601 Live-Segmente, 700 Routenreferenzen,
  948 Haltestellen und erfolgreiche Adresssuche fuer "Massener Hellweg".

PRO-LIVE-REQUEST-NACHTRAG 30.08.2026
------------------------------------
- Auf https://so-portal.de/SO-BusLive-SoestPRO/?city=unna war der Live-Endpunkt
  api/bus-live.php?city=unna mit HTTP 503 nicht nutzbar, waehrend Netzwerk,
  Haltestellen und Stadtprofile funktionierten.
- Transitous/MOTIS lieferte fuer die breite Unna-Live-Anfrage zeitweise
  HTTP 422 "too many trips".
- Fix: optionale liveBbox je Stadt plus automatische Fallback-Versuche im
  Live-Endpunkt. Unna fragt Live-Busse jetzt enger ab, damit Busmarker wieder
  erzeugt werden koennen.

PRO SCHUL-/E-WAGEN-LISTENFILTER 30.08.2026
------------------------------------------
- Neue lokale UI-Praeferenz: "Schul-/E-Wagen ausblenden" auch in der PRO-/Multi-City-Version.
- Standard bleibt OFF: Alle Fahrten werden angezeigt. Der Zustand wird im Browser via
  localStorage (so_buslive_hide_school_extra_v1) gespeichert. Da Standard- und PRO-Seite
  auf derselben Domain laufen, kann die persoenliche Praeferenz konsistent uebernommen werden.
- Filter wirkt nur auf Fahrten-/Abfahrtslisten: Aktuelle Fahrten, Haltestellen-Abfahrten
  und "Busse in der Naehe". Live-Busmarker, userLayer, Netzrouten und Stadtprofile bleiben
  bewusst unangetastet.
- Multi-City-sicher: Kein pauschaler S-Praefix-Filter. S-Linien koennen regulaere Linien sein;
  in Soest muss insbesondere S11 erhalten bleiben.
- Erkennung: eindeutige Schul-/Extra-Flags, E/E-Wagen-Kennungen sowie klare Begriffe wie
  Schulbus, Schuelerverkehr, Einsatzwagen, Verstaerkerfahrt und Zusatzfahrt.
- Keine Zeitfenster-Heuristik (z. B. morgens = Schulbus).
- PRO-spezifische Unna-Live-BBox/Fallback-Logik und Server-APIs wurden fuer dieses Feature
  nicht veraendert.



SO-BUSLIVE-SOESTPRO UPGRADE 30.08.2026 – ORTSSUCHE / MOBILE / VOLLBILD / GPS180
================================================================================
Zielpfad: https://so-portal.de/SO-BusLive-SoestPRO/
Ausgangspaket: SO-BusLive-SoestPRO-SCHUL-EWAGEN-FILTER-20260830(1).zip
Status: BUILD/STATIC QA BESTANDEN – Live-Upload noch durch Nutzer erforderlich.

1. ORTSSUCHE / DEUTSCHLANDWEITER LIVE-AUSSCHNITT
-------------------------------------------------
Fehlerbild / Wunsch:
- Starres Stadt-Dropdown ist fuer Fahrten z. B. nach Berlin zu unflexibel.
- Ort soll per Tippen schnell gefunden werden; Vorschlaege muessen mobile/touch-tauglich sein.

Ursache:
- Bisher konnten nur fest hinterlegte Stadtprofile ausgewaehlt werden.
- Serverprofile kannten keine validierte dynamische Geo-BBox fuer frei gewaehlte Orte.

Aenderung:
- index.php: citySelect durch citySearch + ARIA-Combobox + Vorschlagsliste ersetzt.
- assets/js/app.js: Offline-Schnelltreffer (wichtige deutsche Staedte), 180-ms Debounce,
  Tastatursteuerung Pfeil hoch/runter/Enter/Escape, Touch-Auswahl per pointerdown,
  gespeichertes dynamisches Stadtprofil und URL-Parameter lat/lon/name/region.
- api/city-search.php NEU: serverseitiger Photon/OpenStreetMap-Proxy fuer deutsche Orte,
  Cache 7 Tage, Eingabevalidierung, Deutschland-Bounds, max. 10 Ergebnisse.
- includes/city-profiles.php: dynamische geo-* Profile mit validierter kompakter BBox.
  Live-Radius standardmaessig 9 km, Haltestellen etwas weiter. Keine riesige Berlin-Gesamt-BBox.

Regression-Schutz:
- Feste Profile Soest/Unna/... bleiben unveraendert nutzbar.
- Soester Grundnetz bleibt separates Referenznetz; dynamische Orte erhalten coreLines=[]
  und bauen ihre Linien aus echten MOTIS/Transitous-Daten auf.
- Kein geografischer Soest-Ankerfilter in activeRows().

2. MOBILE-FIRST: KARTE + SCROLL
-------------------------------
Fehlerbild / Wunsch:
- Grosse Karte war auf Mobile teilweise nicht erreichbar, weil body/app-shell auf 100dvh
  und overflow:hidden festgesetzt waren.

Aenderung:
- assets/css/pro-upgrades.css NEU, zuletzt geladen.
- Bis 900 px: normaler Dokument-Scroll statt gesperrter App-Huelle.
- Kartenansicht Portrait: clamp(520px,72svh,760px).
- Landscape: mindestens 320 px bzw. ca. 78svh.
- Linien-/Fahrtenansichten duerfen im Dokument wachsen; keine erzwungene kleine Innen-Scrollbox.
- assets/js/app.js: Mobile-Tab kann zum gewaehlten Panel scrollen und Leaflet danach invalidieren.

3. KARTEN-VOLLBILD + WEBSEITEN-VOLLBILD
----------------------------------------
Aenderung:
- Karte: eigener CSS-Vollbildmodus, funktioniert auch ohne Browser-Fullscreen-API.
- Auf Karte: "⛶ Karte"; im Vollbild grosses "×" oben rechts; Escape schliesst am Desktop.
- Nur im Karten-Vollbild wird Seiten-Scroll absichtlich pausiert.
- Kopfzeile: getrennte Option "⛶ Webseite" nutzt Browser-Fullscreen, sofern unterstuetzt.
  Webseiten-Vollbild selbst sperrt den normalen Dokument-Scroll NICHT.

4. NUR FAVORITEN AUF DER KARTE
------------------------------
- Neue lokale Kartenpraeferenz pro Stadt: so_buslive_map_favorite_only_v1.<city>.
- Filter wirkt ausschliesslich auf Kartenrouten und Busmarker.
- Fahrtenlisten, Haltestellen-Abfahrten und Rohdaten werden nicht gefiltert.
- Ohne gespeicherte Favoriten wird der Kartenfilter deaktiviert statt eine leere Karte zu erzeugen.

5. SCHUL-/E-WAGEN STANDARDMAESSIG AUS LISTEN
--------------------------------------------
- Neuer Standard fuer Nutzer ohne vorhandene Praeferenz: hideSchoolExtra=true.
- Button zeigt im Normalzustand die Aktion "Schul-/E-Wagen anzeigen".
- Bereits gespeicherte Wahl bleibt erhalten.
- S11, C2, R51 und "E-Bus" bleiben Gegenbeispiele und werden nicht pauschal ausgeblendet.
- WICHTIG: Live-Busmarker, Routennetz und GPS-Layer bleiben vom Schulfilter unberuehrt.

6. PAUSE / LETZTE BESTAETIGTE HALTEPOSITION
-------------------------------------------
- Nur echte gestoppte Live-Marker werden als letzte Halteposition gepuffert.
- Wenn der Datensatz waehrend Pause/Wende kurz verschwindet, bleibt die letzte Position bis
  zu 12 Minuten als "PAUSE" sichtbar.
- Bewegte Busse und Vorschau-Marker werden NICHT eingefroren.
- Position wird im Puffer nicht kuenstlich fortgeschrieben.

7. GPS / 180-TAGE-STANDORTPRAEFERENZ
------------------------------------
Befund:
- Die 180-Tage-Funktion war im PRO-Ausgangspaket bereits vorhanden und wurde beibehalten.

Aktueller Vertrag:
- Dialog bietet "180 Tage merken & GPS anzeigen" sowie "Nur dieses Mal".
- LocalStorage-Key: soBusLive.locationPreference.v1.
- Gespeichert werden enabled + expiresAt; keine Koordinaten, kein Bewegungsverlauf.
- watchPosition verarbeitet den aktuellen Standort nur in der laufenden Browseransicht.
- pageshow/visibilitychange koennen einen gemerkten Watch nach Rueckkehr wieder aufnehmen.
- Safari/iOS ohne Permissions API darf nicht stillschweigend vom Resume ausgeschlossen werden.
- WICHTIG: Die Browser-/OS-Geolocation-Berechtigung kann eine Webseite nicht fuer 180 Tage
  erzwingen. Die App merkt 180 Tage den Wunsch; Browser/OS entscheidet weiterhin ueber Prompt,
  granted oder denied. In datenschutz.php kann die interne 180-Tage-Merkung geloescht werden.

8. KONTRAST / LESBARKEIT / SCROLLBALKEN
---------------------------------------
- Bekanntes gruenes Theme bleibt Standard auf der eigenstaendigen BusLive-PRO-Seite.
- Neuer Schalter "Hell" aktiviert optional einen hellen Outdoor-/Seniorenkontrast und speichert
  so_buslive_theme_v1. Im hellen Modus zeigt der Button "Gruen" zum Zurueckwechseln.
- Lesbarkeitsboden fuer Status, Hinweise und mobile Ortssuche angehoben.
- Scrollbars sichtbar, breiter und neon-gruen; im hellen Theme ebenfalls neon-gruen.
- prefers-contrast:more wird zusaetzlich respektiert.

9. DATEIEN
----------
NEU:
- api/city-search.php
- assets/css/pro-upgrades.css

GEAENDERT:
- index.php
- assets/js/app.js
- includes/city-profiles.php
- config.php
- datenschutz.php
- impressum.php
- nutzungsbedingungen.php
- entdecken.php
- sitemap.xml
- robots.txt
- README.txt
- REPORT.txt
- SO-BusLive-QA.txt

GESCHUETZT / BYTEGENAU UNVERAENDERT:
- api/bus-live.php
  SHA-256 67b7ead13fe5a5e17284b1eb51441e08241bb34ae665584be6f6903861e2e5be
- api/stop-times.php
  SHA-256 008148a398927e49ce8a6a07ae53731c2d91adcd93d5bf73180cb39f82f76257

10. REGRESSION-RISIKEN
----------------------
- Freie Grossstadt-Suche kann sehr viele Transitous-Fahrten treffen. Deshalb kompakte dynamische
  Live-BBox beibehalten; Radius nicht unkontrolliert vergroessern.
- city-search.php ist von Photon-Erreichbarkeit abhaengig. Offline-Schnelltreffer im Browser sind
  deshalb verpflichtender Fallback.
- includes/city-profiles.php wird von Live-/Netz-/Stops-APIs geteilt. Feste Profil-BBoxes duerfen
  bei spaeteren Arbeiten nicht versehentlich durch dynamische Parameter ueberschrieben werden.
- Karten-Vollbild und Modal-Overlays verwenden beide hohe Z-Indizes. Modaltests nach kuenftigen
  Z-Index-Aenderungen wiederholen.
- iOS blendet Scrollbars systemseitig teilweise aus; Touch-Scroll muss unabhaengig davon funktionieren.

11. QA / TESTERGEBNISSE
-----------------------
BESTANDEN:
- PHP-Lint: 19 PHP-Dateien, 0 Syntaxfehler.
- JS-Syntax: assets/js/app.js und assets/js/home.js fehlerfrei (node --check).
- DOM-Verknuepfung app.js -> index.php: 58 referenzierte IDs, 0 fehlend.
- Dynamisches Berlin-Profil: lat 52.5200 / lon 13.4050 erzeugt valide Live-/Stops-/Address-BBox.
- Keine verbliebene citySelect-Referenz.
- Geschuetzte Live-API-Hashes entsprechen dem Ausgangspaket.
- Ordnername des Release-Pakets: SO-BusLive-SoestPRO/.

EINSCHRAENKUNG DER AUTOMATISCHEN BROWSER-ABNAHME:
- Lokale Chromium-Navigation auf 127.0.0.1 wird in dieser Ausfuehrungsumgebung durch
  ERR_BLOCKED_BY_ADMINISTRATOR blockiert. Deshalb kein vollstaendiger automatisierter Klicktest
  der echten Leaflet-Interaktion in dieser Umgebung. Statische/Syntax-/DOM-/Profiltests bestanden.

LIVE-TEST NACH UPLOAD – PFLICHT:
[ ] Soest laden: Grundnetz + Marker wie vorher.
[ ] Unna laden: Busmarker-Fallback weiterhin funktionsfaehig.
[ ] Ort "Ber" tippen -> Berlin auswaehlen -> Karte zentriert Berlin und lädt dynamische Daten.
[ ] Offline/Fehler von city-search.php simulieren -> lokale Schnelltreffer bleiben sichtbar.
[ ] Mobile 390px: Seite bis Karte/Listen scrollen; Karte deutlich >500px hoch.
[ ] Karte -> Vollbild -> × -> normale Seite wieder scrollbar.
[ ] Webseiten-Vollbild -> Ab-/Aufscrollen weiterhin moeglich.
[ ] Linie favorisieren -> "Nur Favoriten" Karte -> nur favorisierte Kartenlayer/Marker.
[ ] Schul-/E-Wagen sind bei Erstnutzer in Listen aus; "anzeigen" funktioniert.
[ ] S11/C2/R51/E-Bus bleiben sichtbar.
[ ] Haltender Bus verschwindet kurz aus Feed -> PAUSE-Marker bleibt, bewegter Bus nicht.
[ ] GPS: "180 Tage merken & GPS anzeigen" -> Standortpunkt; Reload -> bestmoegliches Resume.
[ ] GPS intern loeschen in Datenschutz -> erneuter Klick zeigt Einwilligungsdialog.
[ ] Hell-Theme -> Texte/Buttons/Kartenlegende lesbar; Gruen -> altes Theme wiederhergestellt.


======================================================================
2026-08-30 · LIVE-DATEN 503 RESILIENCE HOTFIX
======================================================================
STATUS: BEHOBEN / LIVE-NACHPRUEFUNG ERFORDERLICH

FEHLERBILD
- Browserkonsole meldete wiederholt:
  [SO-BusLive] Datenfehler Error: HTTP 503
  loadData ... app.js
- Wiederholung etwa im normalen 20-Sekunden-Refresh.
- Separate Meldung "No Listener: tabs:outgoing.message.ready" ist kein
  SO-BusLive-Codepfad und wird Browser/Extension-Interna zugeordnet.

KONKRETE URSACHE
- api/bus-live.php gibt HTTP 503 aus, wenn Transitous/MOTIS map/trips
  temporär keinen erfolgreichen Datensatz liefert und kein verwendbarer
  Cache existiert.
- Die bisherige Serverlogik konnte pro Refresh mehrere serielle map/trips-
  Versuche starten. Bei einer Upstream-Störung erzeugte der 20-Sekunden-
  Client-Refresh dadurch zusätzliche Last und viele identische Konsolenfehler.
- Freie Großstadtprofile (z. B. Berlin) waren mit 9 km Live-Radius relativ
  groß für einen ressourcenintensiven map/trips-Aufruf.

GEAENDERTE LOGIK / DATEIEN
1) api/bus-live.php
   - map/trips-Versuche auf maximal 2-3 gezielte Abfragen reduziert.
   - cURL/HTTP-Timeout verkürzt.
   - 45-Sekunden-Fehler-Cooldown pro Stadt eingeführt.
   - letzter guter Stand darf bei Upstream-Ausfall bis max. 15 Minuten als
     klar markierter STALE-Stand weitergegeben werden.
   - Retry-After wird bei 503 gesendet.
   - nach zwei 503-Antworten kein weiteres Request-Stakkato.

2) includes/city-profiles.php
   - Soest erhält einen kompakten liveBbox-Erstversuch; breite bbox bleibt
     als kurzer Fallback bestehen.
   - freie Orte starten standardmäßig mit 7 km statt 9 km Live-Radius.

3) assets/js/app.js
   - 503/429 werden als erwartbare temporäre Live-Quellenstörung behandelt.
   - exponentieller Retry: 30 s -> 60 s -> 120 s -> 240 s -> max. 300 s.
   - Retry-After des Servers wird respektiert.
   - Console-Stack-Flood entfernt; knappe Warnung höchstens periodisch.
   - Karte, Liniennetz und Haltestellen bleiben bei Live-503 nutzbar.
   - bei stale Serverantwort sichtbarer Hinweis "letzter gültiger Stand".

REGRESSION-SCHUTZ
- Schul-/E-Wagen-Filter bleibt ausschließlich Listenfilter.
- Live-Marker werden nicht über Soester Grundnetz/Whitelist abgeschnitten.
- GPS-Layer, Liniennetz und Fahrzeugmarker bleiben getrennte Logiken.
- Pausen-/Last-Position-Haltefunktion bleibt unverändert.
- Ortssuche bleibt erhalten.

LIVE-TESTSCHRITTE
1. https://so-portal.de/SO-BusLive-SoestPRO/ öffnen.
2. Network: api/bus-live.php?city=soest prüfen.
3. Bei 200: Live-Fahrten/Marker und Source-Pill prüfen.
4. Bei 503: UI muss Warnstatus zeigen, darf aber nicht alle 20 s einen
   neuen Stacktrace erzeugen; Retry-Abstand muss wachsen.
5. Liniennetz/Stops müssen auch während 503 weiter bedienbar bleiben.
6. Ort Berlin wählen und kontrollieren, dass der kompakte Ortsausschnitt
   ohne Request-Stakkato geladen wird.
7. Nach Erholung der Quelle muss der nächste erfolgreiche 200-Request den
   Backoff vollständig zurücksetzen.


============================================================
30.08.2026 – HALTESTELLEN-LIVE READABILITY / DUPLIKATE / METROPOLEN-PARITÄT
============================================================
FEHLERBILD
- Im hellen Theme waren Haltestellen-Abfahrtskarten teilweise weiterhin dunkel, während Ziel-/Detailtexte bereits dunkle Light-Theme-Farben geerbt hatten. Ergebnis: sehr schlechter Kontrast (dunkel auf dunkel), besonders problematisch auf Mobilgeräten und bei Sonneneinstrahlung.
- Transitous kann Fahrplan- und Echtzeitdarstellung derselben Fahrt als getrennte Zeilen liefern; dadurch wirkten einzelne Abfahrten doppelt.

URSACHE
- CSS-Kaskade: Dialog/Kopf wurden im hellen Theme aufgehellt, die fest codierte dunkle Hintergrundfarbe von .stop-departure blieb jedoch in einzelnen Integrationspfaden aktiv.
- Die Abfahrtsliste renderte alle gelieferten Stoptime-Zeilen ohne Zusammenführung gleicher tripId bzw. gleicher Linie/Richtung/Planminute.

ÄNDERUNGEN
- Eigener letzter Kontrast-Layer für Haltestellen-Live: klare helle Karten im Light-Theme, klar lesbare dunkle Karten im grünen Theme.
- Mobile Typografie/Touch: Ziel >=16 px, Detail >=13 px, Abfahrtszeit 18 px, X-Schaltfläche 48x48 px.
- Fahrplan/Echtzeit-Doppelmeldungen werden konservativ zusammengeführt; Echtzeit hat Vorrang.
- Verspätung wird kompakt als z.B. "Echtzeit · Plan 13:55 · +3 Min · Steig 2" dargestellt.
- Keine Änderung am Schul-/E-Wagen-Grundsatz: Listenfilter bleibt von Live-Markern getrennt.

REGRESSION-RISIKEN / TESTS
- Prüfen: Haltestelle mit Echtzeit + Fahrplan, eine echte zweite Fahrt derselben Linie wenige Minuten später darf nicht verschwinden.
- Prüfen: Hell/Grün umschalten bei geöffnetem Haltestellendialog.
- Prüfen: lange Ziele umbrechen auf 320–430 px Breite, Uhrzeit bleibt sichtbar.
- Prüfen: Scrollen der Abfahrtsliste und Schließen über X.


================================================================================
30.08.2026 · LIVE-FAHRT TEILEN + KARTEN-EMPFÄNGER + CA.-COUNTDOWN
================================================================================
STATUS: IMPLEMENTIERT · SERVER-/BROWSER-SMOKE-CHECK ERFORDERLICH NACH UPLOAD

ANFORDERUNG
- Eine konkret ausgewählte Busfahrt soll als zeitlich begrenzte Live-Kartenansicht teilbar sein.
- Empfänger sehen Busposition, Richtung, nächsten Halt, geteiltes Ziel und einen ungefähren Countdown bis zum Ziel.
- Teilen per WhatsApp, Telegram, nativer Handy-Freigabe oder Link-Kopie.
- Optional darf die sendende Person zusätzlich ihren eigenen GPS-Punkt teilen.

DATENSCHUTZ-/SICHERHEITSENTSCHEIDUNGEN
- Standard ist NUR BUS; eigener GPS-Punkt ist pro Freigabe ausdrücklich opt-in.
- Öffentlicher Link enthält einen kryptographisch zufälligen Token, keine Koordinaten.
- Separater Verwaltungsschlüssel zum Aktualisieren/Beenden; er wird nicht an Empfänger übertragen.
- Max. Freigabedauer 4 Stunden; Receiver-Seite noindex/noarchive.
- GPS-Punkt wird beim Beenden gelöscht; GPS-Updates funktionieren nur bei geöffneter Senderseite.
- data/live-shares ist per .htaccess gegen direkten Webzugriff geschützt.

DATEIEN/LOGIK
- NEU: api/live-share.php (create/get/update/end, Token-/Edit-Key-Trennung, Ablauf).
- NEU: live-fahrt.php (Empfänger-Kartenansicht).
- NEU: assets/js/live-ride-share-page.js (Busposition, Trip-Haltestellen, Countdown, optionaler GPS-Punkt).
- NEU: assets/css/live-ride-share.css (Mobile First, hoher Kontrast, große Karte).
- GEÄNDERT: Live-Bus-JavaScript: „Fahrt live teilen“, Ziel-/Dauerwahl, WhatsApp/Telegram, optionales GPS, Beenden.
- GEÄNDERT: Fahrplan-Overlay: zusätzlicher Button „● Fahrt live teilen“.
- GEÄNDERT: Datenschutz um Live-Fahrtfreigabe ergänzt.

COUNTDOWN
- Ziel ist vom Sender aus den verbleibenden Haltestellen wählbar; Standard ist der letzte verbleibende Halt.
- Countdown nutzt aktuelle Trip-Zeit (Echtzeit wenn geliefert), sonst gespeicherte Zielzeit.
- Anzeige bewusst als „ca.“; bei fehlenden/gestörten Daten keine falsche sekundengenaue Behauptung.

BUSPOSITION
- Empfänger pollt vorhandene serverseitig gecachte Live-API; keine neue direkte Transitous-Abfrage aus dem Browser.
- Bei kurzen Datenlücken bleibt die letzte Busposition bis zu 12 Minuten als letzter Stand erhalten.
- Eigener GPS-Punkt ist ein separater Marker und wird nie mit der Busposition vermischt.

REGRESSION-SCHUTZ
- Schul-/E-Wagen-Listenfilter bleibt getrennt von Live-Markern.
- Favoritenfilter und GPS-Layer bleiben getrennt.
- 503-/Metropolen-Resilience der Live-APIs wird nicht zurückgebaut.
- Bestehendes statisches „Fahrt teilen“ bleibt zusätzlich erhalten.

LIVE-TEST NACH UPLOAD
1. Fahrt öffnen -> „Fahrt live teilen“.
2. Ziel wählen, 1/2/4 h wählen, zunächst ohne GPS erstellen.
3. WhatsApp-/Telegram-Link in zweitem Gerät öffnen.
4. Busmarker, nächster Halt, Ziel und ca.-Countdown prüfen.
5. Datenquelle kurz ausfallen lassen / wechseln: letzter Busstand darf nicht sofort verschwinden.
6. Neue Freigabe MIT GPS explizit aktivieren; zweiten blauen Standortmarker prüfen.
7. Freigabe beenden: Empfängerseite muss zeitnah „beendet“ zeigen.
8. Ablauf prüfen; keine Reaktivierung ohne neue Freigabe.


30.08.2026 – LIVE-FAHRT KARTEN-/MARKER-FIX V2
STATUS: BEHOBEN / LIVE-NACHPRÜFUNG NACH UPLOAD

FEHLERBILD
- Empfängerkarte in live-fahrt.php zeigte versetzte/groß skalierte OSM-Kacheln.
- Bus-/GPS-Marker waren trotz geladener Positionsdaten nicht sichtbar.

URSACHE
- Beide Live-Fahrt-Seiten enthielten einen fehlerhaften SRI/SHA-256-Wert für Leaflet 1.9.4 CSS:
  FALSCH:  sha256-p4NxAoJBhIINfQ3ynKtu40zWmMZK1xPnsrTxGbdJ6I4=
  RICHTIG: sha256-p4NxAoJBhIINfQ3ynKtu40zMZK1xPnsrTxGbdJ6I4=
- Browser mit SRI-Prüfung verwarfen dadurch das komplette Leaflet-Stylesheet.
- Ohne Leaflet-Struktur-CSS werden Tiles und Marker nicht absolut in den Leaflet-Panes positioniert.

ÄNDERUNGEN
- SRI-Wert in live-fahrt.php korrigiert.
- leaflet-core-fallback.css lokal als strukturelles Sicherheitsnetz eingebunden.
- Fallback erzwingt korrekte Pane/Tile/Marker-Geometrie auch bei CDN-CSS-Ausfall.
- live-ride-share.css mit zusätzlichem Marker-/Map-Sicherheitslayer ergänzt.
- live-ride-share-page.js invalidiert Leaflet nach Load, Resize und Orientationchange erneut.
- Asset-Revision auf 20260830-live-share-mapfix-v2 erhöht, um alten Browsercache zu umgehen.

REGRESSION-SCHUTZ
- Live-Share-Token/API, Countdown, Busdaten, GPS-Freigabe und Ablaufzeiten unverändert.
- bus-live.php/network.php/stops.php/stop-times.php für diesen Fix nicht geändert.
- Marker bleiben getrennt: Busposition aus ÖPNV-Live-Daten; optionaler Mitfahrer-GPS-Punkt separat.

LIVE-TEST NACH UPLOAD
1. Bestehenden Live-Link auf Android/iPhone/Desktop öffnen.
2. Prüfen: OSM-Kacheln lückenlos, keine vergrößerten Einzelkacheln.
3. Busmarker sichtbar und auf der Route.
4. Optionaler GPS-Marker sichtbar, falls Freigabe aktiv.
5. Hoch-/Querformat wechseln; Karte bleibt korrekt dimensioniert.
6. Countdown und nächste Haltestelle laufen unabhängig weiter.