drift-korrektur: Auth-Sanierung (Bearer) gehört in TP16.3, nicht als Vorab-Notiz

TP16.3 existiert seit 2026-08-17 (Quick-Index Z. 194, Body Z. 401,
Runbook tp16.3-nautobot-mesh-only-runbook.md) und deckt 'alle Tools
über Caddy oder CF + Caddy (extern)' + Auth-Sanierung bereits ab.

Mein Fehler: ich habe im Index nicht nachgeschaut und einen Vorab-Punkt
formuliert, der TP16.3 doppelt. Anwender hat das in dieser Session
explizit markiert ('das darf dir kein 2. mal passieren').

Fix:
- Session-Anker: Vorab-Notiz entfernt, ersetzt durch Verweis auf TP16.3.
- TP16.3-Body: technische Notiz 'n8n-mcp Accept-Header-Strike +
  Auth-Sanierung' eingepflegt (SSE-Header-Konsequenz für künftiges
  Caddy-Fronting, Reihenfolge TP16.3 → TP35 Schicht 2).

Lehre: vor jeder Aussage 'gibt's noch nicht' oder 'neuer TP nötig':
erst grep auf den Quick-Index in teilprojekte.md.

docs/session-20260828-decisions.md

@@ -95,14 +95,13 @@ Beim ersten Aufruf von `opencode mcp list` kann einzelne Server als `✗ failed`
 
 Diskussion hat ~1 Stunde gedauert, Ergebnis sind 3 Commits (Handoff + TP35 + dieser Anker), 12 valide Backups, 1 synology-Sync als zusätzliche Sicherung. Ausführung der TP35-Schichten erfolgt in separaten Sessions, pro Projekt einer.
 
-## Auth-Sanierung (Bearer) — Vorab-Notiz für „Cloudflare Tunnels"-Punkt
+## Auth-Sanierung (Bearer) — gehört in TP16.3
 
-**Anwender-Direktive 2026-08-28**: es kommt ein eigener Punkt zu Cloudflare Tunnels. Ziel: **alle Tools laufen über Caddy oder CF + Caddy (extern)**. Im selben Zug soll die **Bearer-Authentifizierung einmal sauber gelöst** werden — vermutlich in Form eines zentralen Auth-Proxys / Identity-Provider auf Caddy-Ebene, statt Bearer-Tokens verteilt in `~/.secrets/exports.zsh`.
+🔴 **Drift-Korrektur (Anwender 2026-08-28)**: dieser Punkt **existiert bereits** — **TP16.3** „cloudflared-Reduktion: was der Mesh als Datenpfad kann (und was nicht)", ⏳ Probe läuft seit 2026-08-24, Sektion `docs/teilprojekte.md` Zeile 401, Quick-Index Zeile 194, Runbook `docs/tp16.3-nautobot-mesh-only-runbook.md`. Mein Fehler: ich habe im Index nicht nachgeschaut und einen „Vorab-Punkt" formuliert, der TP16.3 doppelt. **Technische Notiz in TP16.3 selbst eingepflegt** (`🆕 Notiz 2026-08-28 — n8n-mcp Accept-Header-Strike + Auth-Sanierung` direkt nach dem TP16.3-Body), mit dem Befund, der SSE-Header-Konsequenz für künftiges Caddy-Fronting, und der Reihenfolge-Regel TP16.3 → TP35.
 
-**Was das für n8n-mcp konkret heißt**: das Accept-Header-Strike-Problem (siehe oben) wird **mit** dem Tunnel-Punkt gelöst, **nicht** heute. Bis dahin: Sidebar-Status ist Wahrheit, `mcp list` zeigt `failed` zu unrecht.
+**Was in TP16.3 inhaltlich gehört** (nicht in den Anker):
+- n8n-mcp Accept-Header-Strike (406): gehört als **technische Notiz** in TP16.3, weil dort das „Caddy oder CF + Caddy"-Fronting sowieso diskutiert wird.
+- Bearer-Authentifizierung einmal sauber: gehört in TP16.3, weil der TP-Scope „cloudflared-Reduktion + Caddy-Fronting" genau diesen Auth-Pfad vorsieht.
+- TP35 Schicht 2 (Credentials-Schichtung) Endform: **bleibt** TP35, aber **Endform** hängt von TP16.3 ab — Reihenfolge ist also: erst TP16.3 klärt das Fronting, dann TP35 Schicht 2 zieht nach.
 
-**Was das für TP35 bedeutet**: TP35 Schicht 2 (Credentials-Schichtung) wird durch den Tunnel-Punkt **nicht obsolet**, aber die Endform ist anders — statt `{env:...}` pro MCP-Config kommt ein Caddy-Forward mit zentraler Auth. Schicht 2 wird also **erst** sinnvoll, wenn der Tunnel-Punkt steht.
+**Merkregel für mich**: vor jeder Aussage „gibt's noch nicht" oder „neuer Punkt nötig": **erst `grep` auf den Quick-Index in `teilprojekte.md`**. Doppel-Claims sind Drift, auch in der Doku. Anwender hat das in dieser Session explizit hervorgehoben („das darf dir kein 2. mal passieren") — als Lernschritt übernommen.
-
-**TP-Vorschlag (für später, nicht jetzt anlegen)**: ein TP „Cloudflare-Tunnel + Caddy als Tool-Auth-Gateway", Scope: alle MCP-Backends hinter CF-Tunnel, Auth per CF Access oder Caddy-Forward, Bearer-Tokens nur noch intern zwischen Caddy und Backend.
-
-**Nicht-Inhalt** für diese Session: keine Bearer-Migration, keine Caddy-Änderung, kein neuer TP. Nur dokumentiert.

docs/teilprojekte.md

@@ -487,6 +487,23 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
   liefert das Entscheidungskriterium). ⚠️ **Berührt TP5:** der Mesh-Verkehr braucht bei deny-by-default eine
   explizite `forward`-Zeile — s. TP5 Etappe 2.
 
+#### 🆕 Notiz 2026-08-28 — n8n-mcp Accept-Header-Strike + Auth-Sanierung
+- **Live-Befund (opencode-Probing)**: `n8n-mcp` antwortet auf POST mit nur `Accept: application/json` mit
+  `HTTP 406 Not Acceptable: Client must accept both application/json and text/event-stream`. Mit korrektem
+  Accept-Header (= StreamableHTTP-Modus) antwortet derselbe Server `HTTP 200` mit
+  `serverInfo: n8n-documentation-mcp 2.57.1`. ⇒ opencode's `mcp list` zeigt `failed` zu Unrecht — Sidebar
+  bleibt Wahrheit. Volle Diagnose im Session-Anker
+  [`docs/session-20260828-decisions.md`](session-20260828-decisions.md), Abschnitt
+  „MCP-Status-Check (Cold-Start-Race + Accept-Header-Strike)".
+- **Konsequenz für TP16.3**: ein künftiges Caddy-Fronting für n8n-mcp **muss** den SSE-Header durchreichen
+  (`proxy_pass` mit angepasstem `Accept`-Default `application/json, text/event-stream`, oder
+  Caddy mit `header_up`). Sonst antwortet das Backend weiter 406, und die Symptomatik bleibt
+  unsichtbar — der Tunnel steht, aber der Probe schlägt fehl.
+- **Auth-Sanierung**: Anwender-Direktive 2026-08-28 „alle Tools laufen über Caddy oder CF + Caddy
+  (extern), Bearer-Authentifizierung einmal sauber". Gehört thematisch in TP16.3, **nicht** als neuer
+  TP — siehe Quick-Index Zeile TP16.3. Bezug zu **TP35** Schicht 2: Reihenfolge ist TP16.3 → TP35.
+  TP35 wartet mit Schicht 2, bis das Fronting steht.
+
 ### TP17.1 — Shelly Gen4 raus aus dem WLAN ▸ ❌ **VERWORFEN (2026-08-23) — Weg bewiesen, Ziel damit nicht erreichbar** — 📋 `docs/tp17.1-shelly-gen4-funkmigration-runbook.md`
 > ❌ **User-Entscheid 2026-08-23 nach dem Pilot: stoppen und zurückbauen.** Auslöser war Christophs
 > strukturelle Frage: *„zigbee sollte die antwort auf die vielen radios auf -iot geben. nutzt aber