dofus-manager/docs/prd.md

Dofus Manager - Product Requirements Document (PRD)

Goals and Background Context

Goals

• Remplacer le tableur Excel de gestion de 60+ personnages Dofus par une application web moderne et maintenable
• Offrir une vue d'ensemble claire de tous les personnages avec filtrage multicritères et recherche instantanée
• Automatiser la gestion des données via intégration avec l'API DofusDB (quêtes, donjons, succès)
• Faciliter les mises à jour groupées (bulk update) pour réduire drastiquement le temps de maintenance
• Valider automatiquement les contraintes de compte (pas 2 personnages du même compte simultanément dans une team)
• Tracker les progressions (quêtes Dofus, donjons, recherchés, monnaies) par personnage et par team

Background Context

Theo est un joueur de Dofus gérant 60+ personnages niveau 200 répartis sur plusieurs dizaines de comptes sur plusieurs serveurs (principalement Imagiro). Actuellement, cette gestion est faite via un tableur Excel avec les personnages en colonnes horizontales, ce qui rend la visualisation impossible sans scroll excessif, les modifications fragiles (risque de casser le formatage), et la règle métier fondamentale du jeu ("pas 2 persos du même compte simultanément") gérée uniquement mentalement.

L'application remplacera ce tableur par un système web permettant la gestion CRUD des comptes, personnages, serveurs et teams, avec des filtres avancés façon e-commerce, des actions groupées, et une intégration avec DofusDB pour éliminer la saisie manuelle des données de référence (quêtes, donjons, succès).

Change Log

Date	Version	Description	Author
2026-01-17	0.1	Création initiale du PRD	John (PM)
2026-01-17	0.2	Ajout documentation API DofusDB (endpoints validés)	John (PM)

---

Requirements

Functional Requirements

• FR1: Le système doit permettre la création, lecture, modification et suppression (CRUD) des comptes avec les attributs : nom, ogrines, récompenses succès débloquées (Dofus, ressources).

• FR2: Le système doit permettre la gestion CRUD des personnages avec les attributs : pseudo, classe (17 classes Dofus), niveau, serveur associé, compte associé.

• FR3: Le système doit permettre la gestion CRUD des teams avec validation automatique de la contrainte "pas 2 personnages du même compte dans une team active".

• FR4: Le système doit offrir un filtrage multicritères des personnages par : classe, niveau, compte, team, serveur, statut de progression (quêtes, donjons, recherchés).

• FR5: Le système doit permettre la recherche textuelle sur les noms de personnages, comptes et teams.

• FR6: Le système doit permettre les mises à jour groupées (bulk update) : cocher/décocher plusieurs progressions pour une sélection de personnages ou une team entière.

• FR7: Le système doit tracker les progressions par personnage : quêtes Dofus (Turquoise, Pourpre, Émeraude, etc.), donjons par paliers avec types de succès, recherchés par région.

• FR8: Le système doit tracker les monnaies par personnage : Doplons, Almatons, Orichor, Kamas de glace, Perles des profondeurs, Alitons, Trukdivins, Pages calendrier.

• FR9: Le système doit afficher les totaux agrégés des monnaies au niveau compte et global.

• FR10: Le système doit s'intégrer avec l'API DofusDB pour importer les données de référence (liste des quêtes, donjons, succès, recherchés).

• FR11: Le système doit afficher une vue statut team avec pourcentage de complétion par objectif (ex: "Dofus Turquoise: 6/8 persos = 75%").

• FR12: Le système doit gérer les métiers par couple compte+serveur (et non par personnage) avec niveau de maîtrise.

• FR13: Le système doit permettre la gestion CRUD des serveurs (ex: Imagiro, Jahash, Draconiros) avec possibilité d'en ajouter de nouveaux.

Non-Functional Requirements

• NFR1: L'application doit être responsive et utilisable sur desktop et tablette (usage sur second écran pendant le jeu).

• NFR2: L'application doit offrir une latence de réponse < 500ms pour les opérations courantes (filtrage, CRUD).

• NFR3: L'application doit supporter 100+ personnages sans dégradation notable des performances.

• NFR4: L'application doit être auto-hébergeable sur un serveur dédié personnel via Docker.

• NFR5: L'application doit utiliser PostgreSQL comme base de données pour la persistance.

• NFR6: L'application doit être développée avec React + TanStack Start (full-stack TypeScript).

• NFR7: Les données doivent être sauvegardables et restaurables facilement (backup PostgreSQL).

• NFR8: L'application doit fonctionner en mode mono-utilisateur (pas d'authentification multi-users dans le MVP).

---

User Interface Design Goals

Overall UX Vision

L'application doit offrir une expérience efficace et dense en informations, inspirée des outils de gestion de données professionnels. L'objectif est de permettre à l'utilisateur de :

• Trouver rapidement l'information cherchée (quel perso n'a pas fait X ?)
• Effectuer des modifications en masse sans friction
• Avoir une vue d'ensemble claire malgré le volume de données (60+ personnages)

Le design privilégie la fonctionnalité sur l'esthétique : interface sobre, contrastes clairs, densité d'information élevée, navigation rapide.

Key Interaction Paradigms

• Filtres sidebar façon e-commerce — Panel latéral avec facettes cliquables (classe, serveur, team, compte, statut)
• Multi-select façon Gmail — Checkboxes pour sélection multiple + barre d'actions groupées
• Tables interactives — Tri, resize colonnes, pagination, colonnes masquables
• Actions au survol — Boutons edit/delete apparaissent au hover pour réduire le bruit visuel
• Drill-down progressif — Liste → Fiche détaillée → Sous-sections (progressions, monnaies)
• Feedback immédiat — Toasts pour confirmations, indicateurs de chargement, états vides informatifs

Core Screens and Views

1. Dashboard — Vue d'accueil avec KPIs (total persos, teams, progression globale)
2. Liste Personnages — Vue principale avec filtres, recherche, tableau paginé
3. Fiche Personnage — Détails complets : infos, progressions, monnaies, teams
4. Liste Comptes — Gestion des comptes avec leurs personnages associés
5. Fiche Compte — Détails compte : ogrines, métiers (par serveur), récompenses
6. Liste Teams — Toutes les teams avec statut de complétion
7. Fiche Team — Membres, validation contraintes, % progression par objectif
8. Gestion Serveurs — CRUD des serveurs disponibles
9. Données de référence — Gestion des quêtes/donjons/recherchés (sync DofusDB)

Accessibility

Niveau cible : Aucun (pas de conformité WCAG requise)

Application à usage personnel. Bonnes pratiques de base respectées : contrastes suffisants, navigation clavier, labels sur formulaires.

Branding

Aucun branding spécifique. Design system sobre et moderne (shadcn/ui ou similaire), palette neutre, pas de thématique Dofus (éviter copyright), focus sur lisibilité.

Target Device and Platforms

Web Responsive (Desktop-first)

• Priorité 1 : Desktop — Usage principal sur grand écran pendant les sessions de jeu
• Priorité 2 : Tablette — Consultation occasionnelle
• Priorité 3 : Mobile — Consultation basique acceptable

---

Technical Assumptions

Repository Structure: Monorepo

Projet organisé en monorepo :

/
├── src/
│   ├── routes/          # Pages et API routes (TanStack Start)
│   ├── components/      # Composants React réutilisables
│   ├── lib/             # Utilitaires, clients API, helpers
│   └── server/          # Server functions, services
├── prisma/              # Schéma et migrations Prisma
├── docker/              # Configuration Docker
└── docs/                # Documentation projet

Service Architecture: Monolith Full-Stack

Architecture monolithique avec TanStack Start :

• Frontend : React avec TanStack Router (file-based routing)
• Backend : Server functions intégrées à TanStack Start
• Base de données : PostgreSQL avec Prisma ORM

Testing Requirements: Unit + Integration

Type	Scope	Outils
Unit	Logique métier, validations, helpers	Vitest
Integration	API routes, queries DB	Vitest + testcontainers
E2E	Non prioritaire MVP	(Playwright en V2)

Additional Technical Assumptions and Requests

Stack technique :

• Framework : TanStack Start (React full-stack)
• ORM : Prisma (type-safe, migrations robustes, écosystème mature)
• UI Components : shadcn/ui (composants copiés, personnalisables)
• Tables : TanStack Table (tri, filtres, pagination)
• Database : PostgreSQL 16+
• Container : Docker + Docker Compose

Infrastructure :

• Reverse proxy : Traefik (existant sur le serveur)
• CI/CD : GitLab personnel (pipelines de build et déploiement)
• Hébergement : Serveur dédié personnel

Intégration externe :

• DofusDB API : Client HTTP pour récupérer les données de référence
• Sync manuelle ou cron pour mise à jour des données de jeu

Conventions de code :

• TypeScript strict mode
• ESLint + Prettier
• Conventional commits (feat:, fix:, chore:, etc.)

Déploiement :

• Docker Compose (app + postgres)
• Pipeline GitLab CI pour build et push des images
• Labels Traefik pour routing automatique

---

DofusDB API Reference

Documentation de l'API externe utilisée pour l'Epic 6.

Base URL

https://api.dofusdb.fr/

Caractéristiques techniques

• Framework: FeathersJS (REST API)
• Pagination: $limit, $skip (défaut: limit=10)
• Filtrage: Style MongoDB ($regex, $in, $gt, etc.)
• Multilingue: name.fr, name.en, name.de, name.es, name.pt
• Authentification: Aucune (API publique)

Endpoints disponibles

Endpoint	Total	Champs clés
/dungeons	187	id, name, optimalPlayerLevel, monsters[], subarea
/quests	1978	id, name, categoryId, levelMin, levelMax, steps[], rewards[]
/achievements	2788	id, name, description, level, points, categoryId, rewards[]
/monsters	5093	id, name, level, isBoss, stats, drops[], subareas[]
/items	—	id, name, typeId (23 = Dofus trophées)
/quest-categories	43+	id, name (régions, types de quêtes)
/achievement-categories	129	id, name, parentId

Mapping pour le PRD

Besoin PRD	Endpoint DofusDB	Query
Donjons	/dungeons	?$limit=200
Recherchés	/quests	?categoryId=6
Items Dofus	/items	?typeId=23&name.fr[$regex]=Dofus
Succès donjons	/achievements	?categoryId=3

Dofus identifiés

ID Item	Nom
739	Dofus Turquoise
694	Dofus Pourpre
737	Dofus Émeraude
7043	Dofus des Glaces
18043	Dofus Abyssal
8698	Dofus Nébuleux
7112	Dofus Tacheté
6980	Dofus Vulbis
7754	Dofus Ocre
7114	Dofus Ébène
7115	Dofus Ivoire

Exemples de requêtes

# Tous les donjons
curl "https://api.dofusdb.fr/dungeons?$limit=200"

# Quêtes de recherchés (Avis de recherche)
curl "https://api.dofusdb.fr/quests?categoryId=6"

# Items Dofus
curl "https://api.dofusdb.fr/items?typeId=23&name.fr[\$regex]=Dofus"

# Monstres boss
curl "https://api.dofusdb.fr/monsters?isBoss=true&$limit=50"

Notes d'implémentation

• Les quêtes Dofus ne sont pas directement liées aux items Dofus dans l'API → nécessite un mapping manuel
• Les recherchés sont sous categoryId=6 dans /quests
• Les noms sont multilingues : utiliser name.fr pour le français
• Pagination recommandée pour les gros volumes (achievements, monsters)

---

Epic List

#	Epic	Objectif
1	Foundation & Core Entities	Établir le projet, le schéma DB, et le CRUD de base pour Serveurs, Comptes et Personnages
2	Teams & Constraints	Implémenter la gestion des Teams avec validation de la contrainte compte
3	Filtering & Search	Ajouter les filtres multicritères et la recherche textuelle sur la liste des personnages
4	Progression Tracking	Tracker les progressions (quêtes Dofus, donjons, recherchés) par personnage
5	Currencies & Aggregations	Gérer les monnaies par personnage et afficher les totaux agrégés
6	DofusDB Integration	Intégrer l'API DofusDB pour les données de référence

---

Epic 1: Foundation & Core Entities

Goal: Établir les fondations du projet (setup, Docker, Prisma, CI/CD) et implémenter le CRUD complet pour les entités de base : Serveurs, Comptes et Personnages. À la fin de cet epic, l'utilisateur peut créer, consulter, modifier et supprimer des serveurs, comptes et personnages.

Story 1.1: Project Setup & Infrastructure

As a developer, I want a fully configured TanStack Start project with Docker and GitLab CI, so that I can start development with a working local environment and deployment pipeline.

Acceptance Criteria:

1. TanStack Start project initialized with TypeScript strict mode
2. Docker Compose configuration with app service and PostgreSQL 16
3. Prisma configured and connected to PostgreSQL
4. shadcn/ui installed with base components (Button, Input, Card, Table)
5. ESLint + Prettier configured with recommended rules
6. GitLab CI pipeline: build, lint, test stages
7. Dockerfile multi-stage pour production build
8. README avec instructions de setup local
9. Application démarre et affiche une page d'accueil "Dofus Manager"

Story 1.2: Database Schema - Core Entities

As a developer, I want a Prisma schema with Server, Account, and Character models, so that the data structure is defined and migrations are ready.

Acceptance Criteria:

1. Model Server: id, name, createdAt, updatedAt
2. Model Account: id, name, ogrines (integer), createdAt, updatedAt
3. Model Character: id, name, class (enum 17 classes), level (1-200), serverId (FK), accountId (FK), createdAt, updatedAt
4. Enum CharacterClass avec les 17 classes Dofus
5. Relations définies : Character → Server (N:1), Character → Account (N:1)
6. Migration initiale générée et appliquée
7. Seed script avec données de test (2 serveurs, 3 comptes, 10 personnages)

Story 1.3: Server CRUD

As a user, I want to manage servers (create, view, edit, delete), so that I can add the Dofus servers I play on.

Acceptance Criteria:

1. Page /servers affiche la liste des serveurs en tableau
2. Bouton "Ajouter" ouvre un formulaire modal de création
3. Formulaire avec champ nom (requis, unique)
4. Actions Edit/Delete sur chaque ligne (icônes au hover)
5. Confirmation avant suppression
6. Toast de confirmation après chaque action
7. Validation : nom non vide, unicité vérifiée côté serveur
8. Serveurs triés par nom alphabétique

Story 1.4: Account CRUD

As a user, I want to manage my Dofus accounts (create, view, edit, delete), so that I can organize my characters by account.

Acceptance Criteria:

1. Page /accounts affiche la liste des comptes en tableau (nom, ogrines, nb personnages)
2. Bouton "Ajouter" ouvre un formulaire modal de création
3. Formulaire avec champs : nom (requis), ogrines (optionnel, défaut 0)
4. Actions Edit/Delete sur chaque ligne
5. Clic sur un compte navigue vers /accounts/:id (fiche détail)
6. Page détail affiche infos compte + liste des personnages associés
7. Suppression compte impossible si personnages associés (message d'erreur)
8. Toast de confirmation après chaque action

Story 1.5: Character CRUD

As a user, I want to manage my characters (create, view, edit, delete), so that I can track all my Dofus characters.

Acceptance Criteria:

1. Page /characters affiche la liste des personnages en tableau (nom, classe, niveau, serveur, compte)
2. Bouton "Ajouter" ouvre un formulaire modal de création
3. Formulaire avec champs : nom (requis), classe (select), niveau (1-200), serveur (select), compte (select)
4. Actions Edit/Delete sur chaque ligne
5. Clic sur un personnage navigue vers /characters/:id (fiche détail)
6. Page détail affiche toutes les infos du personnage
7. Icônes de classe affichées (optionnel: images ou emojis)
8. Tableau paginé (20 items par page)
9. Toast de confirmation après chaque action

Story 1.6: Navigation & Layout

As a user, I want a consistent navigation layout, so that I can easily move between sections of the app.

Acceptance Criteria:

1. Sidebar de navigation avec liens : Dashboard, Personnages, Comptes, Serveurs
2. Layout responsive : sidebar collapse sur mobile
3. Breadcrumb sur les pages de détail
4. Page active mise en évidence dans la sidebar
5. Header avec titre de l'application
6. Dark mode toggle (état persisté en localStorage)

---

Epic 2: Teams & Constraints

Goal: Implémenter la gestion complète des Teams avec la règle métier fondamentale : impossible d'avoir 2 personnages du même compte dans une team active. L'utilisateur peut créer des teams, y ajouter des personnages, et voir le statut de complétion.

Story 2.1: Team Database Schema

As a developer, I want a Prisma schema for Teams with many-to-many relation to Characters, so that teams can be created and managed.

Acceptance Criteria:

1. Model Team: id, name, type (enum: MAIN, SUCCESS, PL, CUSTOM), isActive (boolean), createdAt, updatedAt
2. Relation many-to-many Team ↔ Character via table de jonction TeamMember
3. Model TeamMember: teamId, characterId, joinedAt
4. Enum TeamType avec les types identifiés (Main, Succès, PL, Custom)
5. Migration générée et appliquée
6. Seed script mis à jour avec 2-3 teams de test

Story 2.2: Team CRUD - Basic

As a user, I want to create, view, edit and delete teams, so that I can organize my characters into groups.

Acceptance Criteria:

1. Page /teams affiche la liste des teams en tableau (nom, type, nb membres, statut actif)
2. Bouton "Ajouter" ouvre un formulaire modal de création
3. Formulaire avec champs : nom (requis), type (select), isActive (checkbox)
4. Actions Edit/Delete sur chaque ligne
5. Clic sur une team navigue vers /teams/:id (fiche détail)
6. Suppression team supprime aussi les TeamMember associés
7. Badge visuel pour teams actives vs inactives
8. Toast de confirmation après chaque action

Story 2.3: Team Member Management

As a user, I want to add and remove characters from a team, so that I can compose my teams.

Acceptance Criteria:

1. Page /teams/:id affiche la liste des membres actuels
2. Bouton "Ajouter membre" ouvre un sélecteur de personnages
3. Sélecteur filtrable par nom, classe, compte, serveur
4. Multi-select possible pour ajouter plusieurs personnages à la fois
5. Bouton "Retirer" sur chaque membre pour le supprimer de la team
6. Affichage du compte de chaque personnage dans la liste des membres
7. Ordre des membres modifiable (drag & drop optionnel, sinon ordre d'ajout)

Story 2.4: Account Constraint Validation

As a user, I want the system to prevent adding two characters from the same account to an active team, so that I respect the game's simultaneous play restriction.

Acceptance Criteria:

1. Lors de l'ajout d'un membre, vérification que son compte n'est pas déjà dans la team
2. Si conflit détecté : message d'erreur clair indiquant le personnage en conflit
3. Validation côté serveur (impossible de contourner)
4. Validation côté client pour feedback immédiat
5. La contrainte ne s'applique qu'aux teams actives (isActive = true)
6. Teams inactives peuvent avoir plusieurs persos du même compte (pour planification)
7. Lors du passage d'une team inactive → active : vérification des conflits

Story 2.5: Team Status Overview

As a user, I want to see a summary of each team's composition, so that I can quickly assess my teams.

Acceptance Criteria:

1. Sur /teams, colonnes : nom, type, membres (count), statut, classes représentées
2. Sur /teams/:id, section récapitulative : nb membres, comptes utilisés, classes
3. Indicateur visuel si team incomplète (< 8 membres pour type MAIN)
4. Liste des comptes utilisés dans la team (pour éviter conflits lors de multi-boxing)
5. Affichage des classes sous forme d'icônes compactes

---

Epic 3: Filtering & Search

Goal: Ajouter un système de filtrage multicritères et de recherche textuelle sur la liste des personnages. L'utilisateur peut rapidement trouver les personnages qui correspondent à ses critères (classe, serveur, compte, team, etc.).

Story 3.1: Filter Sidebar Component

As a user, I want a sidebar with filter options on the characters list, so that I can narrow down the displayed characters.

Acceptance Criteria:

1. Sidebar à gauche de la liste des personnages
2. Section "Classe" : checkboxes pour chaque classe (17 classes)
3. Section "Serveur" : checkboxes pour chaque serveur existant
4. Section "Compte" : checkboxes pour chaque compte existant
5. Section "Team" : checkboxes pour chaque team existante
6. Section "Niveau" : slider ou inputs min/max (1-200)
7. Bouton "Réinitialiser les filtres"
8. Sidebar collapsible sur mobile (bouton toggle)
9. Compteur de résultats mis à jour en temps réel

Story 3.2: Filter Logic Implementation

As a developer, I want server-side filtering with URL state, so that filters are shareable and persist on refresh.

Acceptance Criteria:

1. Filtres stockés dans les query params de l'URL (ex: ?class=CRA,IOP&server=1)
2. API endpoint accepte les paramètres de filtre
3. Requête Prisma optimisée avec WHERE dynamique
4. Filtres combinés en AND (classe ET serveur ET compte...)
5. Au sein d'un même filtre, valeurs combinées en OR (Cra OU Iop)
6. État des filtres synchronisé avec l'URL au changement
7. Chargement initial lit les filtres depuis l'URL
8. Debounce sur les changements pour éviter trop de requêtes

Story 3.3: Text Search

As a user, I want to search characters by name, so that I can quickly find a specific character.

Acceptance Criteria:

1. Champ de recherche au-dessus du tableau
2. Recherche sur le nom du personnage (insensible à la casse)
3. Recherche également sur le nom du compte
4. Résultats filtrés en temps réel (debounce 300ms)
5. Recherche combinable avec les filtres sidebar
6. Icône "clear" pour vider la recherche
7. Placeholder : "Rechercher un personnage..."
8. Recherche stockée dans l'URL (?q=...)

Story 3.4: Column Sorting

As a user, I want to sort the characters table by clicking column headers, so that I can organize the data as needed.

Acceptance Criteria:

1. Colonnes triables : nom, classe, niveau, serveur, compte
2. Clic sur header = tri ascendant, second clic = descendant, troisième = reset
3. Indicateur visuel de la colonne triée (flèche up/down)
4. Tri côté serveur pour performance
5. Tri par défaut : niveau descendant (200 en premier)
6. Tri stocké dans l'URL (?sort=level&order=desc)
7. Un seul tri actif à la fois

Story 3.5: Saved Filter Presets

As a user, I want to save and reuse filter combinations, so that I don't have to reconfigure common filters.

Acceptance Criteria:

1. Bouton "Sauvegarder ce filtre" quand filtres actifs
2. Modal pour nommer le preset
3. Liste des presets sauvegardés dans la sidebar (section "Mes filtres")
4. Clic sur preset applique tous ses filtres
5. Bouton supprimer sur chaque preset
6. Presets stockés en base de données (model FilterPreset)
7. Limite de 10 presets maximum
8. Presets spécifiques à l'utilisateur (pour futur multi-user)

---

Epic 4: Progression Tracking

Goal: Implémenter le tracking des progressions par personnage : quêtes Dofus, donjons par paliers, et recherchés par région. L'utilisateur peut marquer les progressions comme complétées et voir les statistiques par team.

Story 4.1: Progression Database Schema

As a developer, I want a flexible schema for tracking character progressions, so that different types of progressions can be managed uniformly.

Acceptance Criteria:

1. Model ProgressionType: id, category (enum: DOFUS_QUEST, DUNGEON, WANTED), name, region (nullable), levelRange (nullable), createdAt
2. Model CharacterProgression: characterId, progressionTypeId, completed (boolean), completedAt (nullable)
3. Enum ProgressionCategory: DOFUS_QUEST, DUNGEON, WANTED
4. Index composite sur (characterId, progressionTypeId) pour performance
5. Migration générée et appliquée
6. Seed script avec données de progression types :
   • 10 quêtes Dofus (Turquoise, Pourpre, Émeraude, Glaces, Abyssal, Nébuleux, Domakuro, Dorigami, Tacheté, Vulbis)
   • Donjons par paliers (1-50, 51-100, 101-150, 151-190, 191-200)
   • Recherchés par région (Astrub, Amakna, Frigost I/II/III, etc.)

Story 4.2: Character Progression View

As a user, I want to see and edit a character's progressions on their detail page, so that I can track what each character has completed.

Acceptance Criteria:

1. Section "Progressions" sur la page /characters/:id
2. Onglets par catégorie : Quêtes Dofus | Donjons | Recherchés
3. Liste des items avec checkbox pour marquer fait/pas fait
4. Date de complétion affichée si complété
5. Clic sur checkbox toggle l'état et sauvegarde immédiatement
6. Compteur de progression par catégorie (ex: "7/10 Dofus")
7. Filtres : Tous | Faits | Non faits
8. Items triés par nom ou par ordre logique (niveau pour donjons)

Story 4.3: Bulk Progression Update

As a user, I want to update progressions for multiple characters at once, so that I can quickly mark a dungeon done for my whole team.

Acceptance Criteria:

1. Page /progressions/bulk accessible depuis le menu
2. Sélecteur de personnages (multi-select avec filtres)
3. Sélection possible par team entière (bouton "Sélectionner team X")
4. Sélecteur de progression type à mettre à jour
5. Action : "Marquer comme fait" ou "Marquer comme non fait"
6. Confirmation avant exécution avec récapitulatif (X personnages, progression Y)
7. Toast de succès avec nombre de mises à jour effectuées
8. Retour à la page précédente après action

Story 4.4: Team Progression Status

As a user, I want to see the progression status of my team for a specific objective, so that I can see who still needs to complete it.

Acceptance Criteria:

1. Sur /teams/:id, nouvelle section "Statut des progressions"
2. Sélecteur de progression type (ex: "Dofus Turquoise")
3. Tableau : membres de la team avec statut (fait/pas fait) pour cette progression
4. Pourcentage global affiché (ex: "6/8 = 75%")
5. Indicateur visuel clair (vert = fait, rouge = pas fait)
6. Bouton "Marquer fait pour tous" pour bulk update depuis cette vue
7. Filtrable par catégorie de progression

Story 4.5: Progression Filters in Character List

As a user, I want to filter characters by progression status, so that I can find who hasn't completed a specific objective.

Acceptance Criteria:

1. Nouvelle section dans la sidebar des filtres : "Progression"
2. Sélecteur de progression type
3. Options : "A fait" / "N'a pas fait"
4. Combinable avec les autres filtres existants
5. Exemple d'usage : "Montrer tous les Cra qui n'ont pas fait le Dofus Turquoise"
6. Compteur de résultats mis à jour
7. Filtre stocké dans l'URL

---

Epic 5: Currencies & Aggregations

Goal: Implémenter le tracking des monnaies par personnage (Doplons, Orichor, etc.) et afficher les totaux agrégés au niveau compte et global. L'utilisateur peut rapidement voir combien de chaque monnaie il possède au total.

Story 5.1: Currency Database Schema

As a developer, I want a schema for tracking currencies per character, so that currency amounts can be stored and aggregated.

Acceptance Criteria:

1. Model CurrencyType: id, name, icon (nullable), createdAt
2. Model CharacterCurrency: characterId, currencyTypeId, amount (integer), updatedAt
3. Contrainte unique sur (characterId, currencyTypeId)
4. Migration générée et appliquée
5. Seed script avec les 8 monnaies identifiées :
   • Doplons, Almatons, Orichor, Kamas de glace
   • Perles des profondeurs, Alitons, Trukdivins, Pages calendrier
6. Index sur characterId pour requêtes d'agrégation

Story 5.2: Character Currency View

As a user, I want to see and edit a character's currencies on their detail page, so that I can track each character's wealth.

Acceptance Criteria:

1. Section "Monnaies" sur la page /characters/:id
2. Liste des monnaies avec champ input numérique pour chaque
3. Modification inline avec sauvegarde au blur ou sur Enter
4. Indicateur de sauvegarde (loading spinner pendant save)
5. Validation : montant >= 0, entier uniquement
6. Affichage de l'icône/nom de chaque monnaie
7. Dernière mise à jour affichée par monnaie

Story 5.3: Bulk Currency Update

As a user, I want to update a currency for multiple characters at once, so that I can quickly update after a group activity.

Acceptance Criteria:

1. Page /currencies/bulk accessible depuis le menu
2. Sélecteur de personnages (multi-select avec filtres, sélection par team)
3. Sélecteur de monnaie à mettre à jour
4. Mode d'opération : "Définir à" (valeur absolue) ou "Ajouter/Soustraire" (delta)
5. Champ pour la valeur
6. Confirmation avant exécution
7. Toast de succès avec récapitulatif
8. Historique des bulk updates (optionnel, pour audit)

Story 5.4: Account Currency Totals

As a user, I want to see the total currencies for each account, so that I can see my wealth per account.

Acceptance Criteria:

1. Sur /accounts/:id, section "Total des monnaies"
2. Tableau avec chaque monnaie et le total pour ce compte
3. Total = somme des monnaies de tous les personnages du compte
4. Mise à jour automatique quand les données changent
5. Affichage compact (icône + montant)
6. Zéro affiché si aucun personnage n'a cette monnaie

Story 5.5: Global Currency Dashboard

As a user, I want to see my total currencies across all characters, so that I have a global view of my in-game wealth.

Acceptance Criteria:

1. Widget sur le Dashboard (page d'accueil) : "Mes monnaies"
2. Liste de toutes les monnaies avec total global
3. Total global = somme sur tous les personnages
4. Possibilité de cliquer pour voir le détail par compte
5. Drill-down : compte → personnages avec leurs montants
6. Données mises en cache pour performance (invalidation au changement)

Story 5.6: Currency Management (Admin)

As a user, I want to add or remove currency types, so that I can adapt to game updates adding new currencies.

Acceptance Criteria:

1. Page /settings/currencies pour gérer les types de monnaies
2. Liste des monnaies existantes
3. Formulaire d'ajout : nom, icône (optionnel)
4. Suppression possible si aucun personnage n'a cette monnaie
5. Avertissement si suppression avec données existantes
6. Ordre d'affichage modifiable (drag & drop ou champ order)

---

Epic 6: DofusDB Integration

Goal: Intégrer l'API DofusDB pour importer automatiquement les données de référence du jeu (quêtes, donjons, succès, recherchés). L'utilisateur n'a plus besoin de saisir manuellement ces informations.

Story 6.1: DofusDB API Client

As a developer, I want a typed HTTP client for the DofusDB API, so that I can fetch game reference data reliably.

Acceptance Criteria:

1. Module lib/dofusdb.ts avec client HTTP typé
2. Types TypeScript pour les réponses API (quêtes, donjons, succès, etc.)
3. Gestion des erreurs API (timeout, rate limit, 404)
4. Configuration via variables d'environnement (API URL, éventuels tokens)
5. Retry automatique en cas d'échec temporaire (max 3 retries)
6. Logging des appels API pour debug
7. Tests unitaires avec mocks des réponses API

Story 6.2: Dungeon Data Import

As a user, I want to import the list of dungeons from DofusDB, so that I don't have to add them manually.

Acceptance Criteria:

1. Endpoint ou script pour importer les donjons depuis DofusDB
2. Mapping des données DofusDB vers le model ProgressionType (category: DUNGEON)
3. Import des métadonnées : nom, niveau requis, zone/région
4. Gestion des doublons : mise à jour si existant, création sinon
5. Rapport d'import : X créés, Y mis à jour, Z erreurs
6. Bouton "Importer donjons" dans /settings/data
7. Indicateur de dernière synchronisation

Story 6.3: Quest Data Import

As a user, I want to import Dofus quest chains from DofusDB, so that I can track my progress on main quests.

Acceptance Criteria:

1. Import des quêtes Dofus (les 10 quêtes principales identifiées)
2. Mapping vers ProgressionType (category: DOFUS_QUEST)
3. Import des métadonnées : nom, Dofus associé
4. Option de filtrer quelles quêtes importer (sélection manuelle ou toutes)
5. Gestion des doublons
6. Bouton "Importer quêtes" dans /settings/data
7. Rapport d'import

Story 6.4: Wanted Posters Import

As a user, I want to import wanted poster data from DofusDB, so that I can track bounties by region.

Acceptance Criteria:

1. Import des recherchés par région depuis DofusDB
2. Mapping vers ProgressionType (category: WANTED)
3. Métadonnées : nom, région associée
4. Regroupement par région (Astrub, Amakna, Frigost I/II/III, etc.)
5. Gestion des doublons
6. Bouton "Importer recherchés" dans /settings/data
7. Rapport d'import

Story 6.5: Sync Settings & Automation

As a user, I want to configure automatic synchronization with DofusDB, so that my reference data stays up to date.

Acceptance Criteria:

1. Page /settings/data avec configuration de sync
2. Option sync manuelle (boutons par type de données)
3. Option sync automatique périodique (daily, weekly, disabled)
4. Cron job ou scheduled task pour sync auto
5. Notification (toast ou log) après sync automatique
6. Historique des syncs (date, type, résultat)
7. Option de réinitialiser toutes les données de référence

Story 6.6: Data Conflict Resolution

As a developer, I want a strategy for handling conflicts between local and API data, so that user modifications aren't lost during sync.

Acceptance Criteria:

1. Les ProgressionType importés ont un flag source: API | MANUAL
2. Sync API ne modifie que les entrées source: API
3. Entrées source: MANUAL préservées lors du sync
4. Option de forcer l'écrasement (avec confirmation)
5. Détection des entrées supprimées de l'API (soft delete ou warning)
6. Log des conflits détectés pour review

---

Checklist Results Report

Executive Summary

Metric	Value
Overall PRD Completeness	95%
MVP Scope Appropriateness	Just Right
Readiness for Architecture	Ready
DofusDB API	✅ Validée et documentée

Category Analysis

Category	Status	Notes
1. Problem Definition & Context	PASS	Problème clairement articulé, utilisateur cible défini
2. MVP Scope Definition	PASS	6 epics bien délimités, scope MVP réaliste
3. User Experience Requirements	PASS	Flows documentés, paradigmes d'interaction définis
4. Functional Requirements	PASS	13 FR + 8 NFR, tous testables
5. Non-Functional Requirements	PARTIAL	Performance OK, sécurité minimale (mono-user)
6. Epic & Story Structure	PASS	6 epics séquentiels, 27 stories avec AC détaillés
7. Technical Guidance	PASS	Stack définie, architecture monolith documentée
8. Cross-Functional Requirements	PASS	Intégration DofusDB, schéma DB complet
9. Clarity & Communication	PASS	Document structuré, terminologie cohérente

Issues Identified

Priority	Issue	Status
HIGH	API DofusDB non validée	✅ Résolu — Documentation ajoutée
MEDIUM	Métriques de succès non formalisées	À définir post-MVP
MEDIUM	Stratégie backup non détaillée	À documenter dans architecture
LOW	Seed data à compléter	À préciser lors de l'implémentation

Final Decision

✅ READY FOR ARCHITECT — Le PRD est complet et prêt pour la phase d'architecture.

---

Next Steps

UX Expert Prompt

Je travaille sur Dofus Manager, une application web de gestion de personnages pour le MMORPG Dofus.

Contexte : L'application remplace un tableur Excel pour gérer 60+ personnages sur plusieurs comptes. Les fonctionnalités clés sont :
- CRUD pour Serveurs, Comptes, Personnages, Teams
- Filtrage multicritères et recherche
- Tracking des progressions (quêtes, donjons, recherchés)
- Gestion des monnaies avec agrégations
- Validation de contrainte : pas 2 persos du même compte dans une team active

Design goals :
- Desktop-first, responsive tablette
- Dense en informations, inspiré outils pro
- Filtres sidebar façon e-commerce
- Multi-select et bulk actions façon Gmail
- shadcn/ui comme design system

Peux-tu créer les wireframes ou maquettes pour les écrans principaux :
1. Liste des personnages avec filtres
2. Fiche personnage (infos + progressions + monnaies)
3. Gestion des teams avec validation contrainte

Le PRD complet est disponible dans docs/prd.md

Architect Prompt

Je travaille sur Dofus Manager, une application web full-stack pour gérer des personnages de MMORPG.

Stack technique validée :
- Framework : TanStack Start (React full-stack, TypeScript)
- ORM : Prisma avec PostgreSQL 16
- UI : shadcn/ui + TanStack Table
- Infra : Docker, Traefik, GitLab CI

Contexte métier :
- 60+ personnages, dizaines de comptes, plusieurs serveurs
- Teams avec contrainte : pas 2 persos du même compte simultanément
- Progressions (quêtes, donjons, recherchés) et monnaies à tracker
- Intégration API DofusDB pour données de référence

Besoins architecture :
1. Schéma Prisma complet pour les entités (Server, Account, Character, Team, ProgressionType, CurrencyType, etc.)
2. Structure du projet TanStack Start
3. Patterns pour server functions et data fetching
4. Stratégie de cache pour agrégations
5. Configuration Docker + GitLab CI

Le PRD complet avec les 6 epics et 27 stories est disponible dans docs/prd.md.
Peux-tu initier le mode architecture et proposer une conception technique ?