Christophs Kontext explodiert am Sessionende. Handoff bündelt:
- CF-Token-Audit-Befund: CF_DNS_API_TOKEN ungültig (Code 1000 'Invalid API Token'),
Christophs Verdacht 'falscher Token extrahiert' bestätigt.
- Globale MCP-Migration FQDN → IP für gitea-mcp + n8n-mcp; cloudflare bleibt
extern (User-Direktive explizit). WARP-Pfad statt Bearer-Header wenn der
Connector intern ohne Token lebt.
- terpene W5: n8n-mcp in blaueblueten-n8n/.mcp.json (User-Zustimmung).
- Domain-Korrektur: 420.teilzeitladen.xyz ist die echte terpene-Domain
(NICHT terpene.teilzeitladen.xyz) — User-Direktive, gilt für alle.
- W1/W6 bleiben User-blocked, W7 wartet auf TP31-Schritt 5/6.
Dringend beim Nachfolger: CF-Token-Validität zuerst klären, dann erst
MCP-Migration. STATUS.md im terpene-Repo ist auf die falsche Domain
korrigieren.
Container shelly-mcp läuft seit dem mcp<2-Pin-Fix auf DS923 (10.40.20.180,
macvlan vlan20). Eintrag in der projekt-spezifischen Config analog zu pve-mcp:
type=remote, kein Bearer (Container nimmt keine Auth entgegen, lebt im
BF-LAN hinter deny-by-default — s. TP5).
Abnahme: mcp list 11/11, shelly-mcp connected, /health antwortet
200 mit psk_configured:true.
Container crashte beim ersten Deploy mit 'No module named mcp.server.fastmcp':
PyPI hat mcp 2.x als aktuellste Version, FastMCP wurde dort zu MCPServer
umbenannt. Repo-Code (server.py) nutzt noch v1-API.
Fix: requirements.txt 'mcp[cli]>=1.0,<2' — hält den Server auf v1-kompatibel.
Deploy-Ergebnis:
- Container shelly-mcp auf DS923, IP 10.40.20.180 (macvlan vlan20)
- Health /health: 200, psk_configured:true, iot_ssid=dirtyvader-iot
- StreamableHTTP /mcp: serverInfo 'shelly-mcp 1.29.1'
- Live-Sweep 10.40.30.180-250: 23 Shellys erreichbar
TP30 Posten #3 (Shelly-Gerätepasswort) hochgestuft: SHELLY_DEVICE_PW ist im
Zuge dieses Deploys erneut in ein Sitzungstranskript geraten (sed-Pattern
'SHELLY_DEVICE_PW=.*' hat den Wert nicht maskiert, weil der Replacement-
String zu wenig greedy war — neuer Lessons-Block-Eintrag). Reihenfolge:
erst Werkzeug-Härtung (Stream-Filter statt cat+sed), dann Posten #3
rotieren. CLAUDE.md hat den Lessons-Eintrag, TP30 Posten #3 hat die
Hochstufungs-Begründung.
Portainer-Server (pve LXC 400): 2.40.0 → 2.42.0 via Image-Swap mit Volume-Erhalt.
Pre-Upgrade-Snapshot: docker commit :2.40.0-preupgrade-20260828 (Rollback 7 d
verfügbar) + Settings/Stacks/Endpoints-JSON-Dump (40 KB, 31 Stacks, 4 Endpoints).
Instance-ID + API-Token nach Bump identisch — kein Re-Auth, kein Settings-Verlust.
portainer-mcp: offizielles PyPI-Paket mcp-portainer~=2.42.0 (193 Tools), nur
in bf-infra/opencode.jsonc, via uvx-stdio. Tool-Gate: get_guidance() einmal pro
Session zwingend vor erstem Read. Andere Projekte unberührt.
Korrekturen ggü. Handoff 2026-08-28 README:
- mcp-portainer PyPI bis 2.42.6, Docker-Hub portainer/portainer-ce nur bis 2.42.0
(unterschiedliche Versionierungspfade).
- mcp/portainer/README.md ist auf 2.42.6 formuliert und sollte nachgezogen werden.
Bestand: mcp/INVENTORY.md portainer-mcp ⛔→🟢 + Header MCP-WARP-Direktive ergänzt.
.mcp.json (war getrackt aus Commit 3426366) entfernt: opencode nutzt opencode.jsonc,
nicht .mcp.json — Claude-Code-Konvention hier irrelevant.
Befund 2026-08-28 nach Skill-Verifikation in opencode:
- Der 'Nächster Schritt (2026-08-26)'-Absatz war zwei Tage veraltet
(drei Sessions waren parallel offen)
- Manuelle Doku mit Live-Daten verliert gegen die Realitaet, sobald
die Datei lang wird (1940 Zeilen, drei Stellen pro Edit)
Reaktion:
1. 'Nächster Schritt' umgeschrieben: drei Folge-Sessions A/B/C aus
dem gestrigen Handoff, klar als 'parallel' markiert. A ist erledigt
(TP35 Schicht 6), B+C offen.
2. TP36 als Folge-TP neu angelegt: SSoT via Nautobot fuer
teilprojekte-Live-Daten + Datei-Aufteilung (Index / Snapshot /
Archiv). Eigene Session, nicht heute.
3. CLAUDE.md: zwei Lessons-Eintraege:
a) opencode-TUI: fuehrendes Leerzeichen vor /command manchmal
noetig (Beobachtung, kein Skill-Bug)
b) Manuell gepflegte Doku verliert gegen Realitaet, Merkregel:
drei Stellen pro Edit mitlesen (Quick-Index, TP-Abschnitt,
Ist-Stand); strukturelle Antwort = TP36
Lessons-Block hat jetzt 7 Eintaege (Stand 2026-08-28).
- CLAUDE.md: zwei Lessons-Eintraege (opencode-Default-Pfad kopieren,
nicht symlinken; Kommentar in Code != Verhalten)
- teilprojekte.md: TP35 Quick-Index auf 'Schicht 6 erledigt, Rest offen',
Schicht-6-Befund im TP-Block, Ist-Stand auf 2026-08-28 mit MCP-Bestand-
Korrektur
- handoff-20260828-session-a-projektstatus.md: Session-A-Bericht mit
Drift, Befund, Entscheid, Lehren fuer Session B
Skill selbst liegt in ~/.config/opencode/skills/projektstatus/SKILL.md
(cp aus ~/.claude/skills/projektstatus/, byte-identisch) - opencode
scannt diesen Default-Pfad, kein skills.paths-Eintrag in der JSONC
noetig.
cloudflared-Konfigurationsmaterialien fuer TP16.3 (BFF-public-Tunnel
auf dem Edge statt cloudflared-QUIC-Workaround). Enthaelt:
- ap-bootstrap.rsc: RouterOS-Script fuer ap1/ap2 (veth, srcnat,
container-mounts, env-Vars). Token kommt aus ~/.secrets, wird per
SFTP auf den Router kopiert — kein Klartext im Script.
- cloudflared-bf-public-config.yml: tunnel-UUID + credentials-Pfad
(KEIN Secret). Ingress wird CF-Dashboard-gemanagt (config_src=cloudflare).
- .gitignore: credentials.json mit dem Tunnel-Secretbase64
(PrivateKey des Tunnels, niemals committen).
Status: vorbereitet, nicht ausgefuehrt. credentials.json bleibt lokal.
Vorbereitetes Runbook für TP31.5 (cloudflared-Container auf hAPs statt
TUN-Device-Workaround, da WARP-Connector auf ROS nicht möglich). Inhalt:
- Image-Build (RouterOS 7.x container, 70 MB Budget je AP)
- Pro AP: veth, interface-list-Mitgliedschaft, container-env
- CNAME-Flip von CF-Tunnel auf ap1/ap2 (DNS-Propagation, Rollback)
- Voraussetzungen: WAN-Healthcheck, Tunnel-Secret aus credentials.json
(siehe routeros/cloudflared/.gitignore im Folge-Commit)
Status: vorbereitet, nicht ausgeführt. Stand 2026-08-27.
Vorbereitung für Session B (Deploy auf DS923). Datei-Set reicht für
Image-Build ohne weitere Quellen aus dem Repo:
- Dockerfile: python:3.12-slim, mountbares /config ohne .env-COPY
- requirements.txt: mcp[cli]>=1.0, starlette>=0.36 (StreamableHTTP)
- BUILD.md: rsync → docker build → Portainer-Container-Deploy
- .gitignore: .env (Schema-Vorlage lokal) + __pycache__ ausklammern
Die Live-Instanz .env und der Container selbst werden in Session B
gebaut, nicht hier. Kein Secret in Git.
Eine Seite, die eine frische Session in 30 Sekunden auf Stand bringt:
TL;DR, Lese-Reihenfolge (Handoff → Anker → TP35), sofort-tun-Liste,
Übergabe-Mechanik, Mid-Action-Checkpoint, Commit-Hinweis-Regel, Was-offen.
Löst das 'Bahnhof'-Problem, das Christoph beim Session-Neustart
beobachtet hat.
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.
n8n-mcp-Accept-Header-Strike wird mit dem noch kommenden CF-Tunnel-Punkt
gelöst, nicht heute. Bearer-Authentifizierung soll einmal sauber per
Caddy/CF-Access zentralisiert werden — TP35-Schicht-2 Endform hängt davon.
Inhalt: nur Doku, keine Migration, kein neuer TP, keine Config-Änderung.
Diagnose: n8n-mcp verlangt 'Accept: application/json, text/event-stream'
(StreamableHTTP-Modus). opencode mcp list schickt nur 'application/json',
kriegt 406, wertet als failed. Echter Tool-Aufruf nutzt richtigen Header,
deshalb Sidebar grün. Bearer-Token + Server sind gesund (200 OK mit
richtigem Accept-Header, serverInfo: n8n-documentation-mcp 2.57.1).
Konsequenz: 'failed' in mcp list ist nicht 'kaputt' sondern 'Probing-Header
zu strikt'. Sidebar-Status bleibt Wahrheit.
- Neue Handoff-Datei für den konkreten nächsten Schritt (im Gegensatz zur
Inventur-Handoff, die den Master-Plan zeigt).
- Dokumentiert: cannaleo/terpene-pg entfernt, n8n-mcp repariert,
shelly-mcp-Tote entdeckt, CLAUDE.md-Erweiterung.
- Liste der offenen Aktionen für die nächste Session: bf-network-r6
archivieren, terpene-Caddyfile-Block, STATUS.md Z.47 korrigieren,
n8n-mcp auch in ~/.claude.json, gitea-mcp-Init-Problem.
- shelly-mcp läuft auf keinem Host (kein Mac-Prozess, kein Container auf
NAS/pve). INVENTORY-Handoff hatte den Stand nicht aktualisiert.
Config jetzt enabled=false, neuer Punkt im Ist-Stand-Block.
- 3 neue Lessons-for-Sessions-Regeln: MCP-Änderungen aktiv melden,
Host vor Edit verifizieren, tote MCPs ins Projekt-Repo.
- 'Was du sofort wissen musst' um shelly-mcp-Tote ergänzt.
Die Datei war bereits im Working Tree, aber ohne klaren Zweck -- jetzt
umbenannt auf .snapshot.yaml und mit Marker-Kommentar versehen, der sagt:
- das ist KEINE Transaktions-Akte (kein .json)
- das ist auch KEIN Vor-Zustand zum heutigen nas.emsenhuber.net-Edit
- das ist die AGH-Komplett-Config mit bereits angewandtem Standortsuffix
(*.bf.emsenhuber.net), die beim Bau des AGH-Paars (110/111) in der
naechsten Session als Soll-Zustand gilt.
upstream_dns ist auf /bf.emsenhuber.net/ bedingt (Suffix-Form), 26 von
30 Rewrites haben .bf.-Suffix, 4 Public (vw/hass/n8n/gitea) bleiben ohne
Suffix.
Baut auf handoff-20260825 auf (AdGuard-Paar + Split-Horizon) und ergaenzt
den Auftrag um den heute eingefuehrten Standortsuffix-Sweep: alle BF-Hosts
in AGH heissen kuenftig <host>.bf.emsenhuber.net statt ohne Suffix.
nas.emsenhuber.net ist seit 1d569fa weg (Commit direkt vorher).
`nas.emsenhuber.net` war nur als AGH-Rewrite auf 10.40.20.10 vorhanden,
zeigte aber nirgends hin: kein CF-CNAME, kein Caddyfile-Eintrag (der
hatte von Anfang an ds-bf.emsenhuber.net fuer Synology DSM).
Mit dem TP23-Stufe-2-Cutover wandert die DNS-Aufloesung in ein
AdGuard-Paar und der Rewrite-Satz wird neu aufgebaut. Die Regel
ist ab jetzt: Hosts, die es an mehreren Standorten gibt, heissen
immer `<host>.<site>.emsenhuber.net` — kein gemeinsamer Name
ohne Suffix.
Andere namensgleiche Hosts (macmini/mfc/tv/docker/platform-pg/
core/ap1/ap2/branch) bleiben vorerst ohne Suffix in AGH und werden
einzeln in der TP23-Stufe-2-Session bewertet.
- adguard/AdGuardHome.yaml: AGH-Wizard-Setup (27 Rewrites ohne .bf, DoH zum CF-Gateway, conditional emsenhuber.net).
- nautobot/mikrotik_routeros.j2: DHCP dns-server=10.40.20.36,.37, domain=emsenhuber.net.
- docs/transaktionen/TP23-agh-firewall.commands.rsc: TP5-E2 LAN->AGH dns auf .16/.17 ersetzt durch .36/.37.
- docs/transaktionen/TP23-agh-dhcp-cutover.commands.rsc: DHCP-Cutover (dns-server + domain in einem Deploy).
Compliance 104/104, 0 Drifts. Core bleibt als Rückfallebene unangetastet.
[KEIN go fuer den Rest: Persistenz (CLAUDE.md/memory), Host.Naming (.host.emsenhuber.net),
add-dns-entries-Suffix, conditional-Upstream, lease-time-Transaktion, TP31-defer — alles im Plan,
Wartet auf separates go des Users.]
User-Entscheid. minarca, node-red, hms-mqtt-publisher und openproject
zerstoert, 28 PBS-Snapshots geloescht, 0 Fehler. Gegenprobe direkt am
Datastore: keine Spur von ct/103|109|115|201 mehr.
Ergebnis: auf pve laeuft jetzt jeder existierende Gast -- 11 LXC + 2 VMs,
kein einziger stopped. Der Datastore enthaelt nur noch aktuelle Gaeste.
Merkregel mitgeschrieben: die Snapshot-Liste VOR dem pct destroy
einsammeln. pvesm list --vmid liefert danach 0, obwohl die Backups noch
liegen -- der Filter braucht die Gast-Config. Genau deshalb lief der
104er-Loeschversuch vorhin ins Leere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
User-Entscheid: auch die Grafana-Backups loeschen. Gegenprobe direkt am
Datastore (ct/104 = 0), nicht ueber 'pvesm list --vmid' -- dessen Filter
ist nach dem destroy nicht mehr aussagekraeftig.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Christoph hat 10.40.41.10/32 (alte VLAN1-NAS) entfernt und den Stand als
stable bestaetigt - kein pending offen. Vertraut wird jetzt nur noch, was
tatsaechlich proxyt: 10.40.20.40 (Caddy) plus die drei cloudflared-Origins,
die mit Schritt 6 wegfallen. Abnahme: hass/vw/gitea/n8n je 200 ueber Caddy.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ursache war nicht der fehlende Eintrag, sondern der falsche Ort: HA hat die
http-Konfiguration nach .storage/http migriert ("yaml_migration_done": true,
created_at 2026-08-05). Der YAML-Block wird seither kommentarlos ignoriert -
auch ein absichtlich ungueltiger Schluessel darin erzeugt keinen Fehler.
Die Logzeile fuehrt aktiv in die Irre: "untrusted proxy 10.40.20.40" faellt
laut Quelltext nur bei aktivem use_x_forwarded_for - beide Werte kamen aber
aus .storage, wo .20.10/.126/.167 (die cloudflared-Origins) standen und
Caddy fehlte.
Fix ueber den vorgesehenen Weg: http/config/configure (setzt pending, startet
HA neu) und binnen 5 Minuten http/config/promote. stable enthaelt jetzt
10.40.20.40/32, pending ist leer, hass/vw/gitea/n8n liefern 200 ueber Caddy.
Der wirkungslose Block in configuration.yaml ist durch einen Hinweis ersetzt.
Offen und bewusst vertagt: 10.40.41.10/32 (tote VLAN1-NAS) steht weiter in
der Trusted-Liste.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SoT: CF und Caddy werden NICHT synchron gehalten - die Doppelpflege faellt
mit Schritt 5/6 weg. Heute stehen 19 Ingress-Regeln und 16 Caddy-Sites
nebeneinander und stimmen fachlich ueberein; im Zielbild haelt CF nur noch
eine Catch-all auf 10.40.20.40. Danach: Caddyfile = Name->Origin,
CF = welcher Name ist oeffentlich (4), AGH = Name->IP intern.
Nebeneffekt: die 12 internen Namen brauchen keinen oeffentlichen DNS mehr.
caddy/cf-sync.py (read-only, Exit 1 bei Drift) findet im ersten Lauf sieben
Abweichungen, alle auf CF-Seite: grafana noch im Ingress, nautobot und
gateway-dw als CNAME ohne Ingress (Quelle der 302), drei *.bf-CNAMEs auf den
zerstoerten NPM, dazu die Wildcard-Access-App, die alles maskiert.
Uebergabe korrigiert nach User-Einwand und Gegenmessung:
- Rewrites sind veraltet, nicht wertlos - Hosts leben auf VLAN20 weiter,
also Ziele umbiegen statt Namen loeschen.
- Die Redundanz existiert doch, reziprok ueber die Standorte: FM antwortet
auf 10.101.0.16/.17 (DS415+) - und beide liefern fuer nas.bf die tote
VLAN1-Adresse. Ein Rewrite-Satz nur im neuen BF-Paar erzeugt
standortabhaengig verschiedene Antworten.
- Vorratsregel auf .16 wird gestrichen statt erweitert (User-Entscheid).
- Cave: emsenhuber.net ist die Domain, bf.lan nur der DHCP-Suffix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die erste Fassung entstand vor der Caddy-Abnahme. Live erhoben, dagegen:
- adguard_bf1 (.20.16) ist ein Archiv, keine Vorlage: 24 Rewrites, davon 8
ins tote VLAN1, 9 auf den heute zerstoerten nginx-proxy-manager (LXC 128)
und 2 FritzBox-Reste. Uebernommen werden Upstreams/Filter, die Rewrites
entstehen neu aus caddy/Caddyfile.
- .20.17 ist nicht "bf2", sondern adguard_fm2 (FM-Standort) und antwortet
fuer gitea mit 10.40.41.123. BF hat heute EINEN AGH.
- Die TP5-Vorratsregeln erlauben LAN->DNS hart auf .20.16. Nach dem
DHCP-Flip wird DNS ein forward-Fluss ueber VLAN-Grenzen; ohne erweiterte
Regeln verlieren IOT/MEDIA/UNTRUSTED/GUEST/MGMT die Aufloesung, waehrend
VLAN20 weiterlaeuft und den Fehler tarnt.
Dazu neu: lease-time=1d macht Flip und Rollback traege (erst zur
Erneuerung wirksam), expliziter Rollback-Abschnitt, .36/.37 als frei
geprueft, und der Core bleibt bewusst Rueckfallebene.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Schritt 3 ist durch: Token liegt, deploy.sh gelaufen, Dienst active+enabled.
Abnahme ueber den Host-Header von einem zweiten Host (pve): 11x 200,
nautobot 302, Antwortzeiten 0,02-0,11 s.
Zwei Funde, die man sonst falsch ablegt:
- pve-mcp 400 / ha-mcp 403 / gitea-mcp 404 sind KEINE Proxy-Fehler - die
Gegenprobe direkt am Origin liefert dieselben Codes. Es sind die Antworten
der MCP-Server auf ein nacktes GET /.
- hass bleibt 400, aber die Logzeile sagt "untrusted proxy 10.40.20.40" und
nicht "not set-up for reverse proxies": use_x_forwarded_for greift also,
nur die Liste zieht nicht. Zwei volle Neustarts, Config-Check valid.
Naechster Schritt notiert; die atime taugt unter relatime nicht als Beweis.
Ist-Stand-Block mitgezogen (Projektregel).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Split-Horizon-Entscheid (AdGuard statt Core) macht aus 'ein paar
Eintraegen' eine Verschiebung der DNS-Aufloesung des ganzen Standorts in
einen Container -- heute liefert der DHCP in allen sieben VLANs den Core.
Das gehoert nicht ans Ende einer langen Sitzung (Lehre aus TP28).
Handoff enthaelt: Ausgangslage (Caddy produktiv, 16 Sites/17 Zertifikate),
den Auftrag in fuenf Schritten inkl. der IP-Kollision .30 (Nautobot) und
der Vorgabe, AGH als Paar 110/111 zu bauen statt als DNS-SPOF, sowie die
Staffelung VLAN fuer VLAN mit VLAN30 zuletzt.
Vier Fallen mitgegeben, alle in dieser Session bezahlt: Statuscode vom
oeffentlichen FQDN beweist nichts (grafana), pvesm free scheitert an
geschuetzten Snapshots stillschweigend, Startreihenfolge haengt nicht an
der VMID, und Core-Config braucht Golden Config.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Caddy in LXC 130 ist produktiv: 17 von 17 Zertifikaten per DNS-01 von
Let's Encrypt, Dienst active+enabled, Proxy gegen Host-Header verifiziert
(nautobot 302, gitea 200, pve 200, portainer 200). deploy.sh laeuft
End-to-End; Token per Fingerprint gegengeprueft -- eigenes Zone:DNS:Edit,
nicht das account-weite.
🔴 Fund beim Durchtesten: grafana war seit Langem tot und Cloudflare
Access hat es maskiert. LXC 104 stopped, konfigurativ noch auf VLAN1
(10.40.41.109), waehrend die Ingress-Zeile auf 10.40.20.109 zeigte -- eine
Adresse die es fuer Grafana nie gab. Der FQDN lieferte trotzdem 302, weil
das der Access-Login war. Exakt die Falle aus TP16.3 Paragraph 8, diesmal
in freier Wildbahn: ein toter Dienst sieht hinter Access monatelang
gesund aus.
=> Caddy-Zeile raus (16 Sites), LXC 104 zerstoert, aus dem Backup-Job.
Die 14 PBS-Snapshots bleiben bewusst stehen -- einzige Kopie etwaiger
Dashboards.
hass liefert 400: bekannter trusted_proxies-Punkt aus TP16, gehoert vor
die CNAME-Umstellung.
Split-Horizon entschieden (User): in AdGuard zusammen mit TP23 Stufe 2.
Dokumentiert, was das bedeutet -- heute liefert der DHCP in allen sieben
VLANs den Core als DNS; AGH bekommt niemand. Der Schritt verschiebt die
Aufloesung des ganzen Hauses in einen Container, deshalb als Paar
110/111 bauen. Die geloeschten Altlasten hiessen nicht zufaellig
adguard-bf1/-bf2.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nach der Relay-Reparatur lag weiter nichts an. tcpdump auf der VLAN40-Leitung:
jedes SSDP-Paket des MacBooks kam von Chrome (ST dial-multiscreen,
USER-AGENT Chromium), kein einziges von Sonos. Ursache war das
macOS-Local-Network-Gate - es stand auf "an" und griff nicht. Schalter
aus/ein + App-Neustart hat es gerichtet (User-bestaetigt).
Damit faellt auch die tragende Zahl des Vormittags-Handoffs: die "291 Suchen
der App in 12 Minuten" waren Chrome plus eigene Proben.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
