aufräumen: Inventar-Pipeline stillgelegt, Root-handoff ins docs/, README präzisiert

- inventory/*: build.py/XLSX-Pipeline seit 2025-06 stale, Inventar erneuert sich
  nicht seit Core-Cutover; MikroMCP/CF/Portainer liefern Live-Daten.
- handoff.md → docs/handoff-20260827-hubert-und-altlasten.md (Konventionsbruch
  aus der aktuellen Session korrigiert)
- README.md: komplettes Rewrite mit Master-Struktur-Tabelle (bf-infra aktiv,
  bf-network-r6 Archiv, bf-golden-config Bot), Übergangspfad, Status-Block

docs/handoff-20260827-hubert-und-altlasten.md

@@ -0,0 +1,165 @@
+# Handoff — 2026-08-27 — TP11b Backfill & neue Infra-Topologie
+
+> **Vorgänger:** TP11b-Plan (`~/dev/blaueblueten-n8n/docs/teilprojekte.md`, Block "Daten & Automatisierung"),
+> TP31 (`docs/teilprojekte.md` im bf-infra) — diese Notiz ist **kein neues TP**, sondern eine
+> Session-übergreifende Beobachtung zur geänderten Infrastruktur + Wunschliste für künftige
+> AI-Sessions (Hubert / künftige Modelle).
+
+## TL;DR
+- **`db/006_backfill_kind.sql` ist geschrieben** (TP11b, idempotent) — wurde **nicht** ausgeführt.
+  Der Governor wurde in dieser Iteration **nicht** aktiviert; der Python-Sync-Service
+  (`tools/sync_service.py` im Container `terpene-sync` auf LXC 400) bleibt der produktive Crawler.
+  Der Governor-Blueprints-Fix (`n8n/{detail,price,governor}.json`) ist als Vorbereitung da.
+- **Infra-Topologie hat sich heute stark geändert**: `10.40.41.x` → `10.40.20.x` (VLAN20 = INFRA),
+  Cloudflare-Tunnel-Modell → **Caddy als zentraler Reverse-Proxy auf LXC 130 / `10.40.20.40`**,
+  Mikrotik-Switches routen direkt, **kein `cloudflared`-Tunnel mehr nötig**.
+- **`n8n.emsenhuber.net` ist jetzt öffentlich via Caddy** (CF-Anycast → Caddy → n8n-Backend).
+  n8n-API mit `~/.secrets/credentials.env → N8N_API_KEY` funktioniert von meinem Mac aus.
+- **`terpene.teilzeitladen.xyz` ist im neuen Caddy-Setup noch NICHT registriert** — der
+  Worker läuft weiter über den alten Hyperdrive-VPC-Pfad. DB-Backfill via Worker ist nicht möglich.
+
+## Beobachtungen — was heute (2026-08-27) geändert wurde
+
+### 1. Netz-Topologie: VLAN-Schema umgestellt
+- **`10.40.41.x` ist tot.** Das alte `41.x`-Subnetz (ehem. „Server"-VLAN) gibt es nicht mehr.
+  Aktuell gültig: `10.40.20.0/24` = INFRA (LXC-Hosts, Docker, HA, NAS), `10.40.99.0/24` = MGMT
+  (MikroTik-Switches/APs), `10.40.10.0/24` = MAIN (Trusted Clients).
+- **`10.40.20.40` ist jetzt `caddy-bf1`** (LXC 130 auf pve) — der zentrale Reverse-Proxy.
+  Bestätigt via `curl -I -H "Host: n8n.emsenhuber.net" http://10.40.20.40/` → 308 → HTTPS,
+  und via Cloudflare-Anycast-IP `188.114.96.10` → HTTP 200 (`via: 1.1 Caddy`).
+
+### 2. Public-Apps laufen jetzt über Caddy statt Cloudflare-Tunnel
+- **Was im Caddyfile steht** (`bf-infra/caddy/Caddyfile`):
+  `vw.emsenhuber.net`, `hass.emsenhuber.net`, `n8n.emsenhuber.net`, `gitea.emsenhuber.net`.
+- **Was fehlt:** `terpene.teilzeitladen.xyz` (TP31 Schritt 5–6 ist noch offen).
+- **Cloudflare-Tunnel `bf-public`** ist im CF-Backend angelegt (ID `48d3b0b6-…`, heute
+  05:32 UTC), **status: inactive** — kein Connector läuft. Die Connector-Config ist im
+  Repo bereits vorbereitet: `bf-infra/routeros/cloudflared-bf-public-config.yml` +
+  `bf-infra/routeros/cloudflared/{ap-bootstrap.rsc,credentials.json}`. Der Connector ist als
+  **RouterOS-Container auf ap1 + ap2** geplant (arm64, Mikrotik hAP ax²), Bootstrap-Skript
+  liegt vor. **Wichtig:** Der Tunnel ist **NICHT obsolet** — er ist Teil von TP31
+  Schritt 5/6 (Catch-all-Tunnel für die Subdomains, die nicht ins Caddyfile gehören).
+  Token in `~/.secrets/credentials.env` (`BF_PUBLIC_TUNNEL_TOKEN`).
+
+### 3. DNS-Auflösung aus dem LAN
+- **`terpene.teilzeitladen.xyz`** ist weder über Public-DNS (`@1.1.1.1`) noch über den
+  lokalen Resolver (`@10.40.20.36` = AGH `agh-bf1`) auflösbar — beide geben NXDOMAIN.
+  Der Worker bleibt nur via Hyperdrive-VPC erreichbar (nicht aus dem LAN).
+- **`n8n.emsenhuber.net`** löst sauber via Public-DNS auf `188.114.96.10/.97.10` (CF-Anycast) auf
+  und antwortet mit dem Caddy-Backend. Aus dem LAN funktioniert es also **out-of-the-box** über
+  den CF-Edge-Pfad, ohne dass AdGuard-Rewrites nötig wären.
+
+## DB-Backfill — was schief lief und warum
+
+Der Backfill-SQL ist trivial, aber **aus meinem Mac (LAN-IP `10.40.10.82`) nicht ausführbar**, weil:
+
+- **`pg_hba.conf` auf `10.40.20.20` (platform-pg) erlaubt nur `10.95.10.0/24`** (WireGuard-VPN).
+  Nicht `10.40.10.0/24`. Auch `terpene_ro` ist nicht freigeschaltet — der `terpene-pg`-MCP ist
+  zwar konfiguriert, scheitert aber am `pg_hba.conf`-Eintrag.
+- **WireGuard-Interface** auf meinem Mac nicht aktiv (kein `wg0`, keine `utun`-Adressen in
+  `10.95.10.x`). Die RouterOS-Configs für WG-Hub sind da (`bf-network-r6/routeros/.secrets/wg-*.conf`),
+  aber kein Client-Config für den Mac.
+- **Worker-Endpoint `admin/migrate`** wäre der richtige Pfad, aber `terpene.teilzeitladen.xyz`
+  ist im neuen Caddy nicht registriert → kein HTTP-Zugriff aus dem LAN.
+- **n8n-Credential-Push** (`terpene_rw` als Postgres-Cred in n8n anlegen) wäre eine Alternative,
+  aber **du hast den gestoppt** („wg. mcp abwarten") — kein Schreibzugriff auf Produktivsysteme
+  ohne explizite Freigabe.
+
+**Was bleibt übrig:** entweder WireGuard-Client auf dem Mac aktivieren + `pg_hba.conf`
+um `10.40.10.82` erweitern (deine Aktion), **oder** den Worker in Caddy registrieren
+(TP31 Schritt 5) und dann via `admin/migrate` arbeiten. **Beides ist deine Aktion, nicht
+meine** — ich darf nicht eigenmächtig schreiben.
+
+## Wunschliste — was künftige Sessions (Hubert / Nachfolger) brauchen
+
+Das ist **meine** Perspektive auf das, was ich für produktives Arbeiten brauche. Die
+**Umsetzung ist deine** (Infra-Antwort), nicht meine.
+
+### A. Direkter DB-Zugriff aus dem LAN (für Ad-hoc-SQL)
+- **Was ich brauche:** ein LAN-fähiges Postgres-Frontend — entweder
+  - `pg_hba.conf` um `10.40.10.0/24` (oder wenigstens `10.40.10.82`) erweitern (Trust/SSL),
+  - **oder** ein WireGuard-Client-Setup auf dem Mac, das in `10.95.10.0/24` routet.
+- **Was ich damit anfange:** Counts ziehen, Backfill-SQL ausführen, Schema-Diffs ansehen,
+  EXPLAIN-Tests. Alles read-only oder mit expliziter User-Freigabe.
+- **Priorität:** mittel — die meiste Arbeit geht über den Worker-Endpoint; nur fürs Backfillen
+  oder Schema-Debugging wäre es nützlich.
+
+### B. Caddy-API oder Caddy-MCP (für Hot-Reload / Site-Registrierung)
+- **Was ich brauche:** eine API, mit der ich **ohne SSH auf den LXC 130** einen
+  `Host`-Block ins Caddyfile patchen kann, sodass `terpene.teilzeitladen.xyz` aus dem LAN
+  erreichbar wird.
+- **Heute:** `caddy-bf1` hat eine **Admin-API auf `:2019`** (`http://10.40.20.40:2019/config/`)
+  und die Files liegen in `/etc/caddy/Caddyfile`. **Was fehlt:** ein Auth-Layer
+  (heute localhost-only) und ein Workflow, der JSON-Config reinpatcht + `caddy reload` triggert.
+- **Priorität:** mittel-hoch — sobald die Caddy-API von außen erreichbar + authed ist,
+  kann ich `terpene.teilzeitladen.xyz` (oder andere Sites) registrieren, ohne dich zu fragen.
+
+### C. `terpene.teilzeitladen.xyz` in Caddy registrieren (TP31 Schritt 5/6)
+- **Was das löst:** Worker-Backend ist aus dem LAN erreichbar; `admin/migrate` wird callbar;
+  Backfill-SQL kann ich via Service-Token `terpene-verify-v2` ausführen.
+- **Was du dafür brauchst:** ein zusätzlicher `Host terpene.teilzeitladen.xyz`-Block in
+  `bf-infra/caddy/Caddyfile`, der nach `terpene-worker` (`10.40.20.X`) reverse-proxyt.
+  Worker-Backend-IP = ? (steht in `worker/wrangler.toml` und war mal `10.40.20.167` =
+  Mac mini — der ist seit der Mac-mini-Abschaltung möglicherweise weg). **Klären, was heute
+  das Backend ist.**
+
+### D. Hermes SOUL.md als Inspiration (nicht zum Kopieren)
+- Die `~/.hermes/SOUL.md` enthält gute Direktiven (targeted, efficient, direct,
+  admit uncertainty). Mein Verhalten in dieser Session war dadurch geleitet, dass ich
+  bei Unsicherheit (Credential-Push) gefragt habe statt geraten habe. Das ist gut.
+- **Hermes ist nicht mein Maßstab** — ich bin Hubert / minimax-m3 / opencode-Session,
+  nicht Nous Hermes. Aber das Pattern **„lieber einmal fragen als dreimal raten"** sollte
+  für künftige Sessions explizit festgehalten werden. Vorschlag: ein **CLAUDE.md-Eintrag**
+  in `~/dev/bf-infra/` mit der Direktive „bei Aktionen mit Produktivsystem-Auswirkungen
+  (Credential-Create, Live-Deploy, DB-Write): erst fragen".
+
+## Lessons Learned — was ich (Hubert) beim nächsten Mal anders machen würde
+
+1. **Früher DNS testen.** Ich hätte in Iterationsminute 1 prüfen sollen, ob
+   `terpene.teilzeitladen.xyz` aus dem LAN auflösbar ist. Statt dessen habe ich den
+   `pg_hba`-Fehler über mehrere Schritte debuggt. Direkter Caddy-Bypass-Test wäre schneller
+   gewesen.
+
+2. **Caddy als Erstes prüfen.** Da `caddy-bf1` der neue zentrale Reverse-Proxy ist und
+   `10.40.20.40` ARP-erreichbar war, hätte ich dort anfangen sollen statt bei Postgres. Ein
+   `curl http://10.40.20.40:2019/config/` (Admin-API, heute localhost-only) hätte mir
+   sofort die Site-Liste gezeigt.
+
+3. **Mikrotik-MCP ist Gold wert für LAN-Topologie.** ARP-Tabelle auf `crs326-core` +
+   `vlan20` zeigt mir in einem Call, welche Hosts im Server-VLAN leben — schneller als
+   `host`-Lookups oder `nmap`. Sollte erste Anlaufstelle sein, wenn „wer ist wo im LAN"
+   gefragt ist.
+
+4. **`BF_PUBLIC_TUNNEL_TOKEN` ist Teil von TP31 Schritt 5/6**, nicht obsolet. Der
+   Connector-Container auf den Mikrotik-APs ist die Strategie für die Subdomains, die
+   nicht direkt ins Caddyfile gehören. `bf-public` ist also „im Setup", nicht „tot".
+   Was aber stimmt: für die 4 Subdomains `vw/hass/n8n/gitea.emsenhuber.net` ist der
+   Tunnel obsolet — die laufen bereits über Caddy. Wenn der Connector deployed wird,
+   bekommt er nur die „Catch-all"-Route.
+
+## Offene Punkte für deine nächste Session (nicht für mich)
+
+- **WireGuard-Client auf Mac** aktivieren? Wenn ja: Config aus `bf-network-r6/routeros/.secrets/`
+  oder neu generieren?
+- **`terpene.teilzeitladen.xyz` in Caddy registrieren?** Falls ja: welcher Backend-Host/IP?
+  (Worker ist seit Mac-mini-Wegfall vermutlich auf pve/LXC migriert.)
+- **`bf-public` Cloudflare-Tunnel** — Connector-Container auf ap1+ap2 deployen?
+  `routeros/cloudflared/ap-bootstrap.rsc` ist die Vorlage. Nach Deployment:
+  Ingress so anpassen, dass die 4 Caddy-Subdomains (`vw/hass/n8n/gitea.emsenhuber.net`)
+  vom Tunnel-Catchall **ausgeschlossen** werden — sonst gibts Konflikte (Caddy und
+  Tunnel beanspruchen dieselben Hostnames).
+- **`pg_hba.conf`** um LAN-IP erweitern? Vertrauensstufe (md5/scert/trust)?
+
+## Cross-References
+- `~/dev/blaueblueten-n8n/docs/teilprojekte.md` → TP11b (Backfill-SQL, Doku)
+- `~/dev/blaueblueten-n8n/db/006_backfill_kind.sql` (neu, idempotent)
+- `~/dev/bf-infra/docs/teilprojekte.md` → TP31 (Caddy-Setup, Schritt 5–6 offen)
+- `~/dev/bf-infra/caddy/Caddyfile` (Caddyfile SSoT)
+- `~/.secrets/credentials.env` (alle Credentials, inkl. `BF_PUBLIC_TUNNEL_TOKEN`,
+  `N8N_API_KEY`, `TERPENE_RW_PASSWORD`, `CF_DNS_API_TOKEN`, `CF_API_TOKEN`)
+
+---
+
+**Stand:** 2026-08-27, ~16:00 lokal · **Hubert** (opencode/minimax-m3, Session) · **Christoph**
+(Session-Owner). Kein Commit im terpene-Repo (TP11b-Standby). Keine Schreibaktion auf
+Produktivsysteme in dieser Session (pg_hba, Caddyfile, n8n-Credentials).