initial commit
This commit is contained in:
922
docs/prd.md
Normal file
922
docs/prd.md
Normal file
@@ -0,0 +1,922 @@
|
||||
# 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
|
||||
|
||||
```bash
|
||||
# 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 ?
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user