# 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).