P0
- Aucun secret servi au navigateur : /assets/config.local.js est généré par le
serveur AVANT les montages statiques (il l'emporte sur le fichier local) et
ne contient plus YOUTUBE_API_KEY(S) ; le fichier local n'est plus copié dans
l'image Docker ni embarqué dans dist (angular ignore config.local.js) ;
youtube-api.service n'appelle plus googleapis directement (fetchYouTube =
/api/yt -> /proxy/api/yt), gardes « pas de clé => écran vide », rotation et
carte de bans côté client supprimées ; readiness YouTube via /healthz
(youtube.keys.count) ; messages d'erreur orientés configuration serveur.
- CORS : origines pilotées par API_ALLOWED_ORIGINS (CSV), méthode PATCH
ajoutée (requis par /user/preferences), header X-API-Key accepté.
- Clés d'API longue durée : table api_keys (empreinte SHA-256 + préfixe
affichable), routes GET/POST /api/keys et DELETE /api/keys/:id, jeton
ntk_… affiché une seule fois, last_used_at à chaque usage ; X-API-Key
accepté par authMiddleware ET authMiddlewareCookieAware.
P1
- X-Request-Id renvoyé sur chaque réponse + journal JSON structuré en prod
(ts, reqId, method, route, status, ms).
- GET /metrics : exposition Prometheus sans dépendance (http_requests_total
par route/code, somme+nombre de durées, uptime/mémoire ; METRICS_TOKEN
verrouille l'accès si défini).
- Rate-limit sur /api/details (DETAILS_RATE_LIMIT, 60/min, réponse JSON) —
/transcript avait déjà le sien.
- Version unique package.json : menu du compte, info.version de l'OpenAPI
(+ schéma apiKeyAuth et chemins /keys / /metrics documentés).
Tests : api_coverage +7 cas « production-ready » (sentinel de fuite de clé,
X-Request-Id, /metrics, CORS PATCH, contrat/version, cycle complet des clés
d'API), suggest, transcript, flags, filters, kind — verts. Build OK.
Vérifs instance locale : config servie sans secret, /api/yt 200 avec la clé
serveur, /metrics alimenté, menu 1.0.59 et 40 cartes rendues sans clé côté
client.
Nouvelle liste dans la section Vous de la barre latérale, avec un bouton
horloge a cote du coeur sur toutes les cartes (accueil, themes, provider-
themes, recherche).
- db : les 4 fonctions de listes (like/unlike/isLiked/list) prennent un
paramètre `tag` — la table `tags` sert déjà de mot-clés génériques, donc
zéro migration.
- api : les 4 routes likes sont générées par registerVideoTagRoutes(prefix,
tagName) ; /api/user/watch-later = même fabrique, même enrichissement
yt-dlp, même middleware cookie-aware. Entrée OpenAPI ajoutée.
- front : LikesService prend un VideoTag, like-button un @Input() list
(icône horloge, ambre quand enregistré, libellés a11y dédiés) — un seul
composant pour les deux boutons, pas de copie.
- cartes de recherche : la grille partagée n'avait AUCUN bouton ; cœur +
horloge ajoutés, masqués sur les lives et cartes chaîne (coin bas-gauche
déjà occupé par le compteur de spectateurs / pas des vidéos).
- route /library/watch-later = LikedComponent via data.list (titre, icône,
placeholder et état vide pilotés par la route), clés nav.watchLater FR/EN.
Tests : npm run test:api 41/41 (nouveau test watch-later : ajout, statut,
indépendance vis-à-vis des likes, liste, retrait, 400, 401) + 21 autres
suites vertes. Build OK, instance locale 4200 rebuildée. Sondage Playwright
desktop+mobile : 12/14 (2 faux positifs du sondage : accordéon replié sur
une route hors /library, 3×401 console pendant la phase déconnectée).
bruno