TP16.1 Scharfschalten: Plan-Probe gescheitert (Token-Scope) — Blocker vollstaendig vermessen

POST /warp_connector -> 10000/403, identisch zu 2026-07-17. Neu: Gegenproben
zeigen, dass auch 4.1 blockiert ist (devices/settings GET 403) — es fehlen ZWEI
Permissions, nicht eine. MCP-Read-Gegenprobe belegt: Account kann es, Token darf
nicht -> Free-Plan-Frage bleibt offen. Am Geraet wurde nichts angefasst.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/tp16.1-warp-mesh-native-crs326.md

@@ -1,6 +1,13 @@
 # TP16.1 — Private Access via native Cloudflare Mesh (WARP Connector) auf dem CRS326 Core-Switch
 
-> **Status 2026-08-16: 🟢 GATE OFFEN, ausführungsreif.** `crs326-core` ist seit 2026-08-08 der produktive L3-Router und seit 2026-08-13 in Nautobot adoptiert (68/68 compliant) — die Bedingung „gated bis TP21 den CRS326 abdeckt" ist **erfüllt**. §3 am 2026-08-16 neu gemessen, §4.3 von Platzhalter auf **ausführungsreif** gezogen, **Governance-Ausnahme #4 erteilt** (WG-Zeilen direkt, weil ein Privkey über Golden Config strukturell nicht deploybar ist). Scharfschalten bleibt eine **eigene Session** — es fasst account-weite WARP-Einstellungen an.
+> **🔴 Status 2026-08-16 (Scharfschalt-Versuch): BLOCKIERT auf §4.0 — Token-Scope, user-gated.** Die Plan-Probe
+> wurde ausgeführt und scheiterte reproduzierbar (`10000`/403). Die Probe hat den Blocker aber **vollständig
+> vermessen**: es fehlen **zwei** Permissions, nicht eine (§4.0 *und* §4.1) — Details + Klickpfad in §4.0.
+> Alles ab §4.1 hängt daran; **am Gerät wurde nichts angefasst** (kein Backup, kein WG-Interface, keine Route).
+> Nach dem Token-Edit ist die Session ohne weiteren Vorlauf fortsetzbar. **Ob der Free-ZT-Plan Mesh überhaupt
+> erlaubt, ist weiterhin offen** — das entscheidet erst der Retry des POST.
+>
+> *Vorheriger Stand — inhaltlich unverändert gültig:* **🟢 GATE OFFEN, ausführungsreif.** `crs326-core` ist seit 2026-08-08 der produktive L3-Router und seit 2026-08-13 in Nautobot adoptiert (68/68 compliant) — die Bedingung „gated bis TP21 den CRS326 abdeckt" ist **erfüllt**. §3 am 2026-08-16 neu gemessen, §4.3 von Platzhalter auf **ausführungsreif** gezogen, **Governance-Ausnahme #4 erteilt** (WG-Zeilen direkt, weil ein Privkey über Golden Config strukturell nicht deploybar ist). Scharfschalten bleibt eine **eigene Session** — es fasst account-weite WARP-Einstellungen an.
 > *Historie: Konzept + Runbook 2026-07-16 · Recherche verifiziert + gehärtet 2026-07-17 · Ziel-Device von ap1 auf CRS326 retargeted 2026-07-22.*
 > ⚠️ **Retarget-Hinweis (2026-07-22, Stand 2026-08-16 aufgelöst):** Alles unten war ursprünglich für **ap1** geschrieben und wurde auf den **CRS326 Core-Switch** ummünzt. ~~Der CRS326 ist aktuell noch Werkszustand — Management-IP/Interface-Zuordnung TBD, §4.3 ist ein Platzhalter.~~ → **überholt:** `crs326-core` ist produktiver L3-Router mit Mgmt `10.40.99.1`, §4.3 trägt jetzt echte Werte. Grund für den Retarget: TP15-Endstand (kein RB5009, Router bleibt ap1/ap2 rein für L3/WLAN) + TP21s Modell "ganzer Kabel-Fabric via RouterOS" — der CRS326 wird ohnehin Nautobot-verwaltet, ap1 bleibt Public-Edge/WLAN-Anker.
 > Selbst-tragend: eine frische Session kann das mit diesem Doc + `docs/cf-tunnel-mapping.md` straight bauen — vorausgesetzt der CRS326-Bring-up (TP15) und die Nautobot-Adoption (TP21) stehen.
@@ -107,7 +114,41 @@ MCP ist read-only, s. §11 der Mapping-Doc). Erfolgt der Create → Mesh ist im
 Plan-/Auth-Fehler → **Stopp, Fallback = LXC-auf-pve-WARP-Connector** (alter Plan, ebenfalls dokumentiert).
 Token danach: `GET /accounts/…/warp_connector/{tunnel_id}/token` → das ist das `eyJhIjoi…In0=`-Register-Token.
 
-**⚠️ Token-Permission-Gotcha (2026-07-17, real erlebt):** `POST /warp_connector` schlug mit `code 10000
+**🔴 STAND 2026-08-16: Plan-Probe erneut ausgeführt — identisch gescheitert, Blocker jetzt vollständig vermessen.**
+`POST /accounts/…/warp_connector {"name":"bf-core-mesh"}` → `{"success":false,"errors":[{"code":10000,
+"message":"Authentication error"}]}`, HTTP **403**. Der Token (`455e4f8e…`) ist `active`. Gegenproben mit
+**demselben** Token, um Scope von Plan-Gate zu trennen:
+
+| Endpoint | Methode | Ergebnis | Bedeutet |
+|---|---|---|---|
+| `warp_connector` | GET | **200** (`[]`) | Endpoint existiert für den Account, Feature nicht wegge-403-t |
+| `warp_connector` | POST | **403** `10000` | ⛔ §4.0 — Permission `Cloudflare One Connector: WARP` fehlt |
+| `cfd_tunnel` | GET | 200 | `Cloudflare Tunnel`-Scope vorhanden (TP16-Strang unberührt) |
+| `teamnet/routes` | GET | 200 | §4.4-Pfad grundsätzlich da (PATCH-Edit 2026-07-17 bewiesen) |
+| `devices/settings` | GET | **403** `9109` | ⛔ **NEU: §4.1 ist ebenfalls blockiert** — `Zero Trust`-Scope fehlt |
+| `user/tokens/{id}` · `tokens/permission_groups` | GET | 403 `9109` | Token kann sich selbst nicht introspizieren → Scope-Liste nur im Dashboard |
+
+⚠️ **Der wichtigste neue Befund: das Runbook nannte bisher NUR die eine fehlende Permission (§4.0).** Die Probe
+zeigt, dass auch **§4.1 komplett scheitern würde** — `devices/settings` ist für den Token schon lesend dicht.
+Ohne diesen Nachtrag hätte die Scharfschalt-Session den Token **zweimal** nachziehen müssen. Beides in **einem**
+Edit erledigen.
+
+**Gegenprobe, dass es NICHT das Free-Plan-Gate ist:** derselbe `devices/settings`-GET liefert über den
+`cloudflare`-**MCP** (OAuth, read-only, volle Account-Sicht) sauber `200` mit
+`{gateway_proxy_enabled:true, gateway_udp_proxy_enabled:true, use_zt_virtual_ip:false}`. Der Account *kann* das
+also — nur der Token darf nicht. ➡️ **Die Free-Plan-Frage aus §4.0 bleibt damit weiterhin unentschieden**: sie
+beantwortet sich erst beim Retry des `POST` mit korrekt gescoptem Token. Erst ein dann *immer noch* fehlschlagender
+POST wäre das Plan-Gate und würde den LXC-Fallback (§6) auslösen.
+
+**➡️ Was zu tun ist (Dashboard, nur der User — Token-Bearbeitung ist keine Agent-Aktion):**
+`dash.cloudflare.com` → My Profile → API Tokens → Token `455e4f8e…` → Edit → **Account**-Permissions ergänzen:
+1. **„Cloudflare One Connector: WARP" → Edit** (§4.0: `POST /warp_connector` + `/token`)
+2. **„Zero Trust" → Edit** (§4.1: `devices/settings` PATCH, `devices/policy` POST, Split-Tunnel PUT)
+3. **„Cloudflare One Networks" → Edit** (§4.4 Routes/vnets — GET geht heute, Edit war 2026-07-17 ok; sicherheitshalber mitnehmen)
+
+Danach neuen Wert nach `mcp/cloudflare/.env` **und** `~/.secrets/credentials.env` (beide tragen `CF_API_TOKEN`).
+
+**⚠️ Token-Permission-Gotcha (2026-07-17, real erlebt — Ursachenanalyse, weiterhin gültig):** `POST /warp_connector` schlug mit `code 10000
 "Authentication error"` (HTTP 403) fehl, obwohl der `CF_API_TOKEN` gültig ist und `teamnet/routes` PATCHen kann.
 Ursache: Cloudflare hat beim WARP-Connector→Mesh-Rebranding (2026-04-14) eine **eigene, separate Permission-Group**
 eingeführt — `Cloudflare One Connector: WARP` (Read/Edit) — „Grants write access to Cloudflare Mesh nodes". Das ist