docs: GIS-Plan-Status auf WP-6 nachziehen (#433)

* docs: GIS-Plan-Status auf 2026-08-15 nachziehen (WP-0 bis WP-6 erledigt, WP-8 offen)

* docs: alten Reimport-Blocker-Status als historisch markieren

Author: haexhub

docs/plans/2026-08-04-gis-scaling-architecture.md

@@ -222,11 +222,11 @@ Jedes ist ein eigenständiges Dokument, in einer Session umsetzbar.
 | [WP-1](2026-08-04-gis-wp1-index-notfall.md) | `statement_timeout` + Invalid-Index-Wächter (Rest entfällt mit WP-0) | ~2 h | ✅ **erledigt** (PR #312) |
 | ~~[WP-2](2026-08-04-gis-wp2-drizzle-fundament.md)~~ | ~~Drizzle mit Baseline~~ — **ersetzt durch WP-0**; PostGIS-`customType` und Docker-Fallstrick dort weiterverwenden | — | — |
 | [WP-3](2026-08-04-gis-wp3-geocoding-abdeckung.md) | Geocoding-Abdeckung von 1 % anheben | 2–3 Tage | ✅ **erledigt** (PR #319) — SE-Root-Cause war ein Persistenzbug in `reprocess.ts`, nicht der Geocoder; LocationIQ-ENV auf Prod weiterhin offen (ansible-Folgeschritt) |
-| [WP-4](2026-08-04-gis-wp4-geo-features.md) | `geo_features`-Layer (EPSG:3035, zerlegt, `kind`-Mapping) | 2–3 Tage | ✅ **erledigt** (PR #318) — Aufbau-Job noch nicht gegen Prod gelaufen, `osm_local_elements` ist dort seit dem WP-0-Neuaufbau leer (Reimport steht aus) |
-| [WP-5](2026-08-04-gis-wp5-precompute-suche.md) | `auction_geo_metrics` + Suche umstellen ← **der eigentliche Fix** | 3–4 Tage | WP-4 ✅ erfüllt (Code) — Verifikation gegen echte Daten braucht den ausstehenden OSM-Reimport |
-| [WP-6](2026-08-04-gis-wp6-osm-datenausbau.md) | Lua-Filter: SE nachziehen, Routen-Relationen, Ski/Tourismus-Tags | 1–2 Tage | WP-4 ✅ erfüllt — Code liegt bereits als [ansible#87](https://github.com/haexhub/ansible/pull/87) vor (ungetestet gegen echten osm2pgsql-Lauf), **aktueller kritischer Pfad** |
-| [WP-7](2026-08-04-gis-wp7-klima-grid.md) | `climate_cells` + Open-Meteo-Adapter + Temperaturfilter | 2–3 Tage | WP-5 |
-| [WP-8](2026-08-04-gis-wp8-lagebeschreibung.md) | Lagebeschreibung und Scores für Wohnen / wirtschaftliche Nutzung | 2–3 Tage | WP-5, WP-7 |
+| [WP-4](2026-08-04-gis-wp4-geo-features.md) | `geo_features`-Layer (EPSG:3035, zerlegt, `kind`-Mapping) | 2–3 Tage | ✅ **erledigt** (PR #318) — Aufbau-Job läuft seitdem produktiv gegen echte OSM-Daten (Reimport-Bugs #321/ansible#88/ansible#91 gefixt, s. Status unten) |
+| [WP-5](2026-08-04-gis-wp5-precompute-suche.md) | `auction_geo_metrics` + Suche umstellen ← **der eigentliche Fix** | 3–4 Tage | ✅ **erledigt** (PR #323, Cron-Wiring #339) — live gegen echte Daten verifiziert, seither zwei Nachbesserungen: verwaiste Zeilen bei Geocode-Verlust (PR #422), Statement-Timeout eines Kandidaten bricht nicht mehr den ganzen Lauf ab (PR #424) |
+| [WP-6](2026-08-04-gis-wp6-osm-datenausbau.md) | Lua-Filter: SE nachziehen, Routen-Relationen, Ski/Tourismus-Tags | 1–2 Tage | ✅ **erledigt** ([ansible#87](https://github.com/haexhub/ansible/pull/87)) — Reimport lief nach zwei live gefundenen Bugs durch (PK-Kollision an Ländergrenzen → [zvg-immo#321](https://github.com/haexhub/zvg-immo/pull/321); `--flat-nodes` sprengte die Prod-Disk → `--slim --drop`, ansible#91); DE zuletzt manuell am 2026-08-07 erfolgreich reimportiert |
+| [WP-7](2026-08-04-gis-wp7-klima-grid.md) | `climate_cells` + Open-Meteo-Adapter + Temperaturfilter | 2–3 Tage | 🟡 **teilweise** — Datenfundament + Detailseiten-Klimachart erledigt (PR #340, Transaktions-Fix #428); der Such-Filter-Teil (`summerTempMax`-Slider, `auction_geo_metrics.climateCellId`-FK) ist bewusst nicht angegangen |
+| [WP-8](2026-08-04-gis-wp8-lagebeschreibung.md) | Lagebeschreibung und Scores für Wohnen / wirtschaftliche Nutzung | 2–3 Tage | ⬜ **nicht begonnen** — Eingangsdaten (`auction_geo_metrics`, `climate_cells`) liegen vor, **das ist der nächste offene Schritt der Serie** |
 
 ```
 WP-1 (Timeout+Wächter) ──> WP-3 (Geocoding)   ← erst nach WP-1, sonst Faktor 75 mehr Last
@@ -239,7 +239,9 @@ WP-0 und WP-1 sind unabhängig und können parallel laufen. WP-1 zuerst — es d
 
 Ein Reimport der OSM-Daten fällt sowohl in WP-0 (Neuaufbau) als auch in WP-6 (neue Tags) an. **Nur einmal ausführen** — WP-6 vor dem Reimport deployen, dann beide Ziele mit einem Lauf erreichen. DE dauert mehrere Stunden.
 
-> **Status 2026-08-05: das ist jetzt der aktuelle Blocker.** Der WP-0-Hard-Reset hat `osm_local_elements` mitgeleert (0 Zeilen, 96 kB statt der ursprünglichen 44,5 Mio. Zeilen/20 GB, verifiziert per `pg_stat_user_tables`) — der Reimport wurde seither nicht nachgeholt. WP-4s Aufbau-Job (PR #318) ist gemergt und lokal verifiziert, **auf Prod aber noch nicht gelaufen** — ein Lauf gegen die leere Quelle würde `geo_features` heute mit nichts befüllen. WP-5 hat noch nicht begonnen, es hängt an denselben Daten. WP-6s Code liegt bereits vor ([ansible#87](https://github.com/haexhub/ansible/pull/87), Branch `osm-import-geo-features`), aber nur syntaktisch geprüft, nicht gegen einen echten osm2pgsql-Lauf. Reihenfolge ab hier: ansible#87 gegen einen kleinen Extrakt (Bulgarien, nicht DE) testen, reviewen, mergen, deployen → DE/SE/BG-Reimport auslösen (mehrere Stunden, hohe Prod-Last, erfordert explizite Freigabe) → WP-4-Aufbau-Job auf Prod ausführen → WP-5-Precompute starten.
+> **Status 2026-08-05 (historisch, aufgelöst — siehe Status 2026-08-15 unten):** Der WP-0-Hard-Reset hat `osm_local_elements` mitgeleert (0 Zeilen, 96 kB statt der ursprünglichen 44,5 Mio. Zeilen/20 GB, verifiziert per `pg_stat_user_tables`) — der Reimport wurde seither nicht nachgeholt. WP-4s Aufbau-Job (PR #318) ist gemergt und lokal verifiziert, **auf Prod aber noch nicht gelaufen** — ein Lauf gegen die leere Quelle würde `geo_features` heute mit nichts befüllen. WP-5 hat noch nicht begonnen, es hängt an denselben Daten. WP-6s Code liegt bereits vor ([ansible#87](https://github.com/haexhub/ansible/pull/87), Branch `osm-import-geo-features`), aber nur syntaktisch geprüft, nicht gegen einen echten osm2pgsql-Lauf. Reihenfolge ab hier: ansible#87 gegen einen kleinen Extrakt (Bulgarien, nicht DE) testen, reviewen, mergen, deployen → DE/SE/BG-Reimport auslösen (mehrere Stunden, hohe Prod-Last, erfordert explizite Freigabe) → WP-4-Aufbau-Job auf Prod ausführen → WP-5-Precompute starten.
+
+> **Status 2026-08-15: Blocker aufgelöst, WP-0 bis WP-6 erledigt.** Der Reimport lief durch — auf dem Weg zwei weitere, unabhängige Live-Bugs gefunden und gefixt: eine PK-Kollision an Länder-Grenzextrakten killte den ganzen Swap eines Landes ([zvg-immo#321](https://github.com/haexhub/zvg-immo/pull/321)), und `osm2pgsql --flat-nodes` sprengte mit ~100-120GB pro Land die Prod-Disk (Fix: `--slim --drop`, [ansible#91](https://github.com/haexhub/ansible/pull/91)). WP-4/WP-5 liefen danach produktiv gegen echte Daten; zwei Nachbesserungen seither (PR #422, PR #424, siehe Tabelle oben) laufen jetzt stabil im nächtlichen Cron. WP-7 ist nur zur Hälfte erledigt: die Datengrundlage (`climate_cells`) und der Klimachart auf der Objekt-Detailseite existieren (PR #340), der Such-Filter-Teil bewusst nicht. **WP-8 wurde noch nicht begonnen** — seine Eingangsdaten (`auction_geo_metrics` aus WP-5, `climate_cells` aus WP-7) liegen vollständig vor, das ist damit der nächste offene Schritt dieser Planserie.
 
 ## Risiken