fix: corrections SW cache, nginx proxy, sw.js no-cache — 2026-05-01 05:48

This commit is contained in:
Claude Deploy
2026-05-01 05:48:38 +00:00
parent e3f3bb0ea5
commit 50758fe232
4 changed files with 721 additions and 18 deletions
+127
View File
@@ -0,0 +1,127 @@
# 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