4ea13afe60
Beobachtung 30.05.2026 02:51-02:53: zwei verkettete Antipatterns beim Spotify-Test. 1. ARIA bekam 403 vom /pause-Endpoint, vermutete 'der 204-Bug ist zurueck' und patchte den Skill — zweimal hintereinander. Der 204-Fix war aber laengst im Code (haette sie durch skill_get in 5s gesehen). Symptome != Diagnose. 2. Bei den 403s antwortete sie 'war schon pausiert, daher der 403' und 'schon aktiv, daher der 403'. Beides war geraten basierend auf is_playing-Check, nicht aus den Daten gelesen. 403 'Restriction violated' kann viele Ursachen haben (NO_ACTIVE_DEVICE, ALREADY_PAUSED, PREMIUM_REQUIRED, MARKET_RESTRICTED, ...) — die wahre steht als error.reason im JSON-Body. Sie hat das verschluckt und plausibel-aber-geraten geantwortet. Eine Regel deckt beide Patterns ab, generisch fuer alle Skills: - Vor jedem skill_update: erst skill_get lesen, dann beurteilen - Bei HTTP-Errors: Body / error.reason zitieren, nicht raten - Wenn der Skill die wahre Ursache verschluckt: skill_update mit besserer Error-Extraktion (NACH skill_get, nicht davor) Wirkt fuer alle aktuellen + zukuenftigen API-Skills. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>