fix: key users by account_id and tolerate candidate count variance

backend/app/adapters/anthropic/llm.py

@@ -50,7 +50,7 @@ class IntentOutput(BaseModel):
     familiarity: Familiarity
     is_refinement: bool
     intent_summary: str = Field(min_length=1, max_length=300, pattern=r"^[^\r\n]+$")
-    candidates: list[CandidateOutput] = Field(min_length=30, max_length=40)
+    candidates: list[CandidateOutput] = Field(min_length=10, max_length=50)
 
 
 class RerankSelectionOutput(BaseModel):
@@ -112,8 +112,6 @@ class AnthropicRecommender:
         if parsed is None:
             raise RecommenderOutputError("Intent response contained no structured output")
         validated = IntentOutput.model_validate(parsed.model_dump())
-        if len(validated.candidates) != candidate_count:
-            raise RecommenderOutputError("Intent response returned the wrong candidate count")
         return _to_intent(validated)
 
     async def stream_rerank(

backend/app/adapters/spotify/mapping.py

@@ -72,7 +72,7 @@ def parse_saved_track_page(payload: object) -> list[Track]:
 def parse_current_user(payload: object) -> CurrentUser:
     """Map a Spotify current-user response into stable identity fields."""
     root = _as_mapping(payload)
-    account_id = _required_string(root, "id") or _required_string(root, "account_id")
+    account_id = _required_string(root, "account_id") or _required_string(root, "id")
     display_name = _required_string(root, "display_name")
     if account_id is None or display_name is None:
         raise ValueError("Spotify returned an invalid current-user response")

docs/logboek.md

@@ -130,3 +130,24 @@ Waarom:
 
 - Streamen maakt de wachttijd eerlijk: de eerste kaart telt, niet de
   laatste. Een afgebroken request mag geen werk laten doorlopen.
+
+### Review-fixes en de account-quota
+
+Wat ik deed:
+
+- Twee fixes uit de live-test: gebruikers-id key op het stabiele account_id
+  veld (met id als fallback), en de intent-call accepteert nu een
+  afwijkend kandidaten-aantal in plaats van hard te falen als het model er
+  34 in plaats van 35 teruggeeft.
+- Tijdens het opnemen van demo-fixtures de dagelijkse development-quota
+  van de Spotify-app geraakt: honderden searches in enkele minuten, daarna
+  QUOTA_EXCEEDED met een Retry-After van bijna 7 uur. Het systeem
+  degradeerde zoals ontworpen: een eerlijke foutmelding, geen stille
+  fallback naar verzonnen resultaten.
+
+Waarom:
+
+- De quota is per developer-account en per dag; bulk-werk zoals fixtures
+  opnemen moet dus gebudgetteerd, en het cache-ontwerp (naam-naar-id,
+  smaakprofiel) is geen optimalisatie-garnituur maar
+  noodzakelijk om binnen de quota te blijven.