roadmap: add Phase 9 multi-interface (admin/player/bug), mark fallout-visu unification done

ROADMAP.md

@@ -150,22 +150,54 @@ Système météo calé sur la météo réelle de la Louisiane.
 
 ---
 
-## 🔮 Phase 9 — Joueurs réels (VISION LONG TERME)
+## 🔮 Phase 9 — Interfaces multiples (VISION LONG TERME)
 
-Interface pour que de vrais joueurs envoient des actions.
+Trois interfaces distinctes, même backend, accès différenciés.
 
-- API REST ou bot Discord → reçoit les actions joueur
-- Action validée par l'arbitre (Phase 6) avant d'être exécutée
+### 9a — Interface Admin (PipBoy v2, évolution de l'actuel)
+- Accès restreint (auth basique ou token)
+- Tout ce que fait le PipBoy actuel + logs bruts + contrôle fin des sessions
+- Gestion des joueurs : création de compte, reset de personnage, ban
+- Vue globale multi-sessions en temps réel
+
+### 9b — Interface Joueur
+- Flask léger ou SvelteKit (si JS est inévitable)
+- Un joueur = un personnage = une session
+- Actions possibles : se déplacer, interagir avec un PNJ (→ déclenche LLM 7b), commercer
 - Réponse PNJ via LLM 7b dans la foulée (<10s)
-- Résumé MJ 14b envoyé à la fin du tick
+- Résumé MJ 14b à la fin du tick (feed narratif)
+- Statut du personnage : HP, inventaire, position, derniers events
 - Gestion des absences : le PNJ joueur survit en mode automatique (Tier 1)
+- **Brique à préparer dès Phase 5** : API REST `POST /player/action` + `GET /player/state`
+
+### 9c — Interface Bug / Rapport
+- Formulaire simple accessible depuis l'interface joueur
+- Champ : description du bug + tick/session automatiquement attachés
+- Stocké en table `bug_reports` (PostgreSQL) avec statut open/closed
+- Visible depuis l'interface Admin
+
+### Architecture cible
+
+```
+                    ┌──────────────┐
+                    │  API centrale │  (Flask ou FastAPI)
+                    │  /admin/*     │← Admin (PipBoy évolué)
+                    │  /player/*    │← Interface Joueur
+                    │  /bug/*       │← Rapports bugs
+                    └──────┬───────┘
+                           │
+              ┌────────────┼────────────┐
+           DB Vigile    Ollama      ChromaDB
+```
+
+**Décision clé à anticiper** : séparer Admin et Joueur en deux Flask (ports différents, auth différente) ou un seul Flask avec blueprints + décorateur `@require_role`. La deuxième option est plus simple à l'échelle actuelle.
 
 ---
 
 ## Backlog technique (bugs connus / dettes)
 
-- [ ] `fallout-visu/app.py` et `dashboard/app.py` sont deux fichiers séparés à synchroniser manuellement → à unifier avec un mount symlink ou CI
-- [ ] Le container PipBoy se réinstalle à chaque restart (pip install au démarrage) → créer une image Docker dédiée
+- [x] `fallout-visu/app.py` et `dashboard/app.py` dupliqués → ✅ unifié en juin 2026 (docker-compose monte directement `dashboard/app.py`)
+- [ ] Le container PipBoy se réinstalle à chaque restart (pip install au démarrage) → créer une image Docker dédiée avec les dépendances pré-installées
 - [ ] `capacity_test.py` écrit en root depuis le container (permission denied) → monter le volume avec le bon uid
 - [ ] 8 timeouts sur 50 joueurs simultanés → augmenter timeout à 300s ou implémenter une queue avec backpressure
 - [ ] Pas de persistance de l'iptables après reboot complet du host → vérifier que `netfilter-persistent` est installé