From 2a6ad68f73bbf1e85fd2bf7237dbcf8e9c5063ca Mon Sep 17 00:00:00 2001 From: Corback Date: Tue, 16 Jun 2026 11:00:40 +0000 Subject: [PATCH] roadmap: add Phase 9 multi-interface (admin/player/bug), mark fallout-visu unification done --- ROADMAP.md | 46 +++++++++++++++++++++++++++++++++++++++------- 1 file changed, 39 insertions(+), 7 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index 7f528f4..4e8d5cf 100644 --- a/ROADMAP.md +++ b/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é