Files
equitask/PROMPT_REPRISE_V2.md

128 lines
6.1 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Prompt de reprise — EquiTask V2
> À coller tel quel en début de nouvelle session pour démarrer le développement de la V2.
---
## Contexte du projet
Tu vas m'aider à développer **EquiTask V2**, l'évolution d'une application PWA de mesure de répartition des tâches domestiques.
**L'application V1 est déjà en production** à l'adresse `https://equitask.domench.fr`. Le code source se trouve dans mon dossier de travail `equitask/` (dossier sélectionné dans Cowork).
Avant de commencer, lis les deux fichiers de référence :
1. `equitask/DOCUMENTATION.md` — documentation technique complète de la V1 (architecture, stack, BDD, API, composants, limites)
2. `equitask/PROMPT_REPRISE_V2.md` — ce fichier (contexte V2)
---
## Ce qui existe en V1 (à ne pas recoder)
- **Backend** : Express + TypeScript + SQLite (Drizzle ORM) + better-sqlite3
- Routes : `/api/foyer`, `/api/membres`, `/api/categories`, `/api/taches`, `/api/saisies`
- Stats dashboard : `GET /api/saisies/stats?debut&fin&inclure_enfants&categorie_id`
- Export CSV/JSON : `GET /api/saisies/export?format=json|csv`
- **Frontend** : React 18 + Vite + Tailwind + TanStack Query + Recharts
- Pages : Setup (wizard), SelectionProfil, Saisie (grille tâches), Dashboard (4 graphiques), Paramètres (3 onglets)
- Offline : queue IndexedDB + sync automatique au retour en ligne
- PWA : Service Worker Workbox, manifest, icônes
- **Infra** : Docker multi-stage → Coolify → https://equitask.domench.fr
- Déploiement via `deploy.py` depuis le dossier parent
- Volume SQLite persisté : `equitask-data:/data`
---
## Système de score (inchangé en V2)
```
score_final = durée_minutes × coefficient_pénibilité (15)
```
L'indicateur d'équilibre mesure l'écart en % entre les deux adultes du foyer.
Seuils : vert ≤ 10%, orange ≤ 25%, rouge > 25%.
---
## Objectifs de la V2
> **À compléter par Gaël avant de démarrer** — noter ici les fonctionnalités souhaitées.
> Exemples de pistes identifiées lors du développement de la V1 :
### Fonctionnalités prioritaires (à valider)
- [ ] **Authentification simple** — code PIN par membre ou mot de passe foyer pour éviter que n'importe qui modifie les données
- [ ] **Notifications / rappels** — push notification ou email hebdomadaire avec le récap de répartition
- [ ] **Vue récapitulatif hebdomadaire** — résumé automatique chaque dimanche soir
- [ ] **Objectifs** — définir un objectif d'équilibre cible et suivre la progression
- [ ] **Modification d'une saisie** — pouvoir éditer une saisie depuis l'historique (actuellement suppression seulement)
- [ ] **Saisie rapide** — ajouter une tâche passée sans passer par la grille (ex: "j'ai fait X hier")
- [ ] **Tri du tableau historique** — tri par colonne (date, membre, score...)
- [ ] **Tendances long terme** — graphique mensuel sur 6/12 mois
- [ ] **Badges/gamification** — récompenses pour les périodes bien équilibrées
### Améliorations techniques (à valider)
- [ ] **Migrations Drizzle** — remplacer les `CREATE TABLE IF NOT EXISTS` par un vrai système de migrations
- [ ] **Tests** — au moins les routes API critiques (saisies, stats)
- [ ] **CI/CD automatique** — déclencher le déploiement sur push Gitea (webhook → Coolify)
- [ ] **Rate limiting** — protéger l'API des abus
- [ ] **Recalcul des scores** — option pour recalculer les scores historiques si les paramètres d'une tâche changent
---
## Contraintes techniques à respecter
1. **Rester dans la même stack** : Express/Node 20, React 18, SQLite, TypeScript, Tailwind
2. **Compatibilité Docker** : le Dockerfile multi-stage doit continuer à fonctionner
- Toujours `npm install --include=dev` (pas `npm ci`, pas de lockfile)
- `NODE_ENV=production` coupe les devDependencies — le `--include=dev` est obligatoire dans les builder stages
3. **Volume SQLite** : les données sont dans `/data/equitask.db` — les migrations doivent être non-destructives
4. **Frontend `tsconfig.json`** : doit avoir `"types": ["vite/client"]` pour `import.meta.env`
5. **API** : rester rétrocompatible avec V1 (mêmes routes, mêmes structures de réponse)
6. **Design** : dark theme slate-950/slate-900, accents indigo-600, cards rounded-2xl — maintenir la cohérence visuelle
---
## Infra de déploiement
```
VPS OVH : 57.131.33.182
Coolify : http://100.94.204.91:8000
Gitea : https://git.domench.fr/gael/equitask
Branche : main
App Coolify : bunmdt8jmb2i594zuhzvdhfy
URL prod : https://equitask.domench.fr
```
Pour redéployer après modifications :
```bash
# Depuis Windows — cmd (pas PowerShell)
cd C:\Users\GALWAL~1\Documents\Claude\Projects\APPLIC~1
py -X utf8 deploy.py equitask ./equitask
```
Ou : pusher sur `main` et déclencher manuellement dans Coolify.
---
## Points de vigilance hérités de la V1
Ces bugs/pièges ont déjà été rencontrés — à ne pas reproduire :
- **`npm ci` échoue** → pas de `package-lock.json` commité, toujours utiliser `npm install`
- **`tsc: not found` pendant le build Docker** → `NODE_ENV=production` coupe les devDependencies, toujours `--include=dev`
- **TypeScript `import.meta.env` introuvable** → vérifier `"types": ["vite/client"]` dans `frontend/tsconfig.json`
- **Type `role: string` trop large** → dans les mutations TanStack Query, typer explicitement `role: 'adulte' | 'enfant'`
- **Coolify API `fqdn` read-only** → utiliser le champ `domains` dans les PATCH
- **Coolify API git_repository tronqué** → re-PATCH après création pour rétablir l'URL complète
- **`py` vs `python`** → sur ce Windows, `py` fonctionne en cmd mais pas `python3`
- **Chemin avec `ë`** → utiliser le chemin court Windows `GALWAL~1` dans cmd si nécessaire
---
## Pour démarrer la session
1. Lis `equitask/DOCUMENTATION.md` (documentation technique complète)
2. Explore le code existant si besoin : `equitask/backend/src/` et `equitask/frontend/src/`
3. Demande-moi quelles fonctionnalités V2 je veux prioriser
4. Propose un plan de développement incrémental (backend d'abord, puis frontend)
5. Travaille fichier par fichier en préservant la compatibilité avec l'existant