veza/docs/AUDIT_103_CORRECTIONS.md

# Corrections par rapport à l'audit 103

**Date** : 16 février 2026  
**Référence** : `103_audit_global_features_states.md`  
**Objectif** : Documenter les écarts entre l'audit et l'état réel du backend, sans modifier le fichier d'audit lui-même.

---

## 1. Module 6 — Social & Communauté

**Audit (ligne 466)** : « Le frontend a des composants Social mais ils appellent des endpoints qui **n'existent pas** dans le backend (uniquement MSW mocks) »

**Correction** : Le backend expose des routes Social dans `veza-backend-api/internal/api/routes_social.go` :

- `GET /api/v1/social/feed` — flux social
- `GET /api/v1/social/posts/user/:user_id` — posts par utilisateur
- `GET /api/v1/social/groups` — liste des groupes
- `GET /api/v1/social/groups/:id` — détail d'un groupe
- `POST /api/v1/social/posts` — créer un post (protégé)
- `POST /api/v1/social/like` — like (protégé)
- `POST /api/v1/social/comments` — commenter (protégé)
- `POST /api/v1/social/groups` — créer un groupe (protégé)
- `POST /api/v1/social/groups/:id/join` — rejoindre un groupe (protégé)
- `DELETE /api/v1/social/groups/:id/leave` — quitter un groupe (protégé)

---

## 2. Module 9 — Gestion de Matériel (Gear)

**Audit (ligne 506)** : « Le frontend a des composants via MSW mocks (`/api/v1/inventory/gear`), mais **aucun endpoint backend n'existe** »

**Correction** : Le backend expose des routes Gear dans `veza-backend-api/internal/api/routes_gear.go` :

- `GET /api/v1/inventory/gear` — liste du matériel
- `POST /api/v1/inventory/gear` — créer un équipement (protégé)
- `GET /api/v1/inventory/gear/:id` — détail d'un équipement
- `PUT /api/v1/inventory/gear/:id` — modifier (protégé)
- `DELETE /api/v1/inventory/gear/:id` — supprimer (protégé)

---

## 3. Live Streams

**Audit (ligne 135)** : « `GET /api/v1/live/streams/*` — pas de routes live dans le backend »

**Correction** : Le backend expose des routes Live dans `veza-backend-api/internal/api/routes_live.go` :

- `GET /api/v1/live/streams` — liste des streams
- `GET /api/v1/live/streams/:id` — détail d'un stream
- `POST /api/v1/live/streams` — créer un stream (protégé)

---

## 4. Routes Notifications

**Audit** : Le rapport 103 indique un backend « limité » pour les notifications.

**Correction** : Les routes `/api/v1/notifications/*` existent dans `veza-backend-api/internal/api/routes_core.go` (lignes 344-353) :

- `GET /api/v1/notifications` — liste des notifications
- `GET /api/v1/notifications/unread-count` — nombre de non lues
- `POST /api/v1/notifications/:id/read` — marquer comme lue
- `POST /api/v1/notifications/read-all` — tout marquer comme lu
- `DELETE /api/v1/notifications/:id` — supprimer une notification
- `DELETE /api/v1/notifications` — supprimer toutes les notifications

**Phase 2.2** : Création automatique de notifications pour follow, like et comment (handlers ProfileHandler, TrackHandler, CommentHandler).

---

## 5. Job Queue (RabbitMQ)

**Audit** : Mention de job queue non connectée.

**Correction** : RabbitMQ est configuré et connecté via `config.RabbitMQEventBus` (`veza-backend-api/internal/config/config.go`). Le service démarre avec RabbitMQ si `RABBITMQ_ENABLE=true`. Le health check `/readyz` inclut RabbitMQ (mode dégradé si indisponible).

---

## 6. Stream Server — Callback HTTP

**Audit** : Référence au Stream Server.

**Correction** : Le backend expose un endpoint de callback pour le Stream Server :

- `POST /api/v1/internal/tracks/:id/stream-ready` — callback après transcoding (authentifié par `X-Internal-API-Key`)
- Également disponible en legacy : `POST /internal/tracks/:id/stream-ready`

---

## 7. Recherche unifiée

**Audit (ligne 192)** : « /search » listé comme inexistant.

**Correction** : La recherche unifiée existe dans `veza-backend-api/internal/api/routes_search.go` :

- `GET /api/v1/search` — recherche unifiée (tracks, users, playlists)

---

## 8. Tests E2E Playwright

**Prérequis** : Backend API doit être démarré sur `http://localhost:8080` pour les tests smoke/auth (login, upload, playlists).

**Configuration** :
- `PORT=5174` : évite conflit avec dev server sur 5173
- `playwright.config.ts` : webServer timeout 5 min, Vite respecte `process.env.PORT`
- `vite.config.ts` : `server.port` utilise `process.env.PORT || 5173`

**Commande** :
```bash
# Backend + Frontend requis
cd apps/web && PORT=5174 VITE_API_URL=http://localhost:8080/api/v1 npx playwright test --project=chromium
```

---

## 9. Analytics — track_plays.device

**Vérification** : La table `track_plays` possède bien la colonne `device` (modèle `TrackPlay` dans `internal/models/track_play.go`). Le handler `GetDeviceBreakdown` interroge correctement cette colonne. `GetTrafficSources` renvoie `[]` car `track_plays` n'a pas de colonne `source` — comportement documenté dans le handler.

---

## 10. Routes orphelines (backend exposé, frontend non consommateur)

Routes disponibles pour usage futur (pas de UI dédiée actuellement) :

- `POST /api/v1/tracks/initiate`, `POST /api/v1/tracks/complete`, `GET /api/v1/tracks/resume/:uploadId` — upload chunked
- `POST /api/v1/tracks/batch/delete`, `POST /api/v1/tracks/batch/update` — opérations batch
- `GET /api/v1/tracks/shared/:token` — partage par token
- `GET /api/v1/users/me/export` — export données utilisateur
- `POST /api/v1/audit/cleanup` — nettoyage audit (admin)