Initial: desk + ncantu placeholder + per-project cursor configs
**Motivations:** - Centraliser les fichiers Cursor (rules, skills, agents, commands, hooks) par user et par projet **Root causes:** - N/A **Correctifs:** - N/A **Evolutions:** - desk: rules, skills-cursor, agents, commands, hooks, argv/hooks/mcp.json - ncantu: README placeholder - 4NK_node, algo, builazoo, ia_local, lecoffre_ng, lecoffre_ng_pprod, lecoffre_ng_test: .cursor contents **Pages affectées:** - cursor/desk/, cursor/ncantu/, cursor/<project>/
This commit is contained in:
160
builazoo/plan-action-cahier-des-charges.md
Normal file
160
builazoo/plan-action-cahier-des-charges.md
Normal file
@@ -0,0 +1,160 @@
|
||||
# Plan Cursor – Action cahier des charges
|
||||
|
||||
Exécution dans l’ordre : BLOC 1 → 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9 → 10 → 11.
|
||||
Référence : `docs/plan-action-cahier-des-charges.md` et `docs/cahier des charges.md`.
|
||||
|
||||
---
|
||||
|
||||
## BLOC 1 – Grille au lancement + 3 couples reproducteurs (§1, §10)
|
||||
|
||||
**FILES:** `web/js/state.js` | `web/js/config.js` | `web/js/placement.js` | `web/js/grid-utils.js` | `web/js/main-bootstrap.js` | `web/js/loot-tables.js`
|
||||
|
||||
**STEPS:**
|
||||
1. Définir en config (ou dans `state.js`) le **layout de grille zoo au premier lancement** : positions fixes pour 1 Recherche, 1 Billeterie, 1 Nurserie, 1 Accueil, 1 Nourriture, 1 Camion, 1 zone Agrandissement zoo, et 24 cases vides avec 3 couleurs/biomes.
|
||||
2. Adapter `buildDefaultCells()` pour générer cette grille (au lieu de seulement school 1_1 + nursery 2_1). Inclure research, billeterie, food, reception, plotUpgrade (agrandissement zoo), et 24 cases avec biome réparti sur 3 couleurs.
|
||||
3. Au premier démarrage (nouveau zoo ou `defaultState()`), **placer 3 couples reproducteurs** : choisir des animaux basiques selon biome de départ (ex. depuis loot-tables), placer sur des cases vides de la grille (ou en pendingBabies/reception si pas assez de place). Définir quels animalIds = « basiques » par biome.
|
||||
4. Documenter le **layout carte du monde au lancement** (§11) : compteurs (bébés, animaux, labos, zoos, villes), cases Accueil/Nourriture/Camion, 24 cases 3 couleurs. Implémenter si l’UI actuelle en dévie.
|
||||
5. Créer ou mettre à jour une fiche `docs/features/grille-lancement.md` (objectif, impacts, modifications, déploiement, analyse).
|
||||
|
||||
**DONE_WHEN:** Nouveau zoo démarre avec grille complète (recherche, billeterie, nurserie, accueil, nourriture, camion, 24 cases 3 couleurs) et 3 couples reproducteurs placés ; doc à jour.
|
||||
|
||||
---
|
||||
|
||||
## BLOC 2 – Ventes : validation différée 10 min + sablier (§13)
|
||||
|
||||
**FILES:** `server/migrations/` | `server/db.js` | `server/routes/sales.js` | `web/js/api-client.js` | `web/js/ui.js` | `web/js/types.js` | `docs/features/ventes-encheres-phase10.md`
|
||||
|
||||
**STEPS:**
|
||||
1. **Migration BDD** : ajouter sur `sale_listings` un champ `validated_at TIMESTAMPTZ` (NULL = pas encore validé définitivement). Conserver `sold_at` = date d’acceptation par le vendeur. Statut intermédiaire : `sold_pending` ou utiliser `validated_at IS NULL AND sold_at IS NOT NULL`.
|
||||
2. **Logique serveur** : à l’accept, ne pas transférer les pièces immédiatement ; enregistrer `sold_at = now()`, `validated_at = now() + 10 minutes`. Créer un traitement (cron ou à la lecture) qui pour les lignes `sold_at IS NOT NULL AND validated_at IS NOT NULL AND validated_at <= now()` effectue le transfert de pièces (buyer -= amount, seller += amount) et marque la vente comme validée (ex. `validated_at` déjà renseigné ou champ `status = 'validated'`). L’acheteur ne peut appeler `deliver` qu’après validation.
|
||||
3. **API** : exposer `validated_at` et/ou temps restant pour chaque vente (asSeller, asBuyerUndelivered). Le client calcule « en attente de validation » si `sold_at` présent et `validated_at` dans le futur.
|
||||
4. **Client** : afficher un **sablier** (ou compte à rebours) pour les ventes vendues mais pas encore validées ; désactiver « Récupérer » jusqu’à `validated_at <= now`. Après validation, comportement actuel (Récupérer disponible).
|
||||
5. Mettre à jour `docs/features/ventes-encheres-phase10.md` (validation différée, sablier, migration).
|
||||
|
||||
**DONE_WHEN:** Acceptation met la vente en attente 10 min ; transfert de pièces et possibilité de récupérer uniquement après 10 min ; sablier visible côté client.
|
||||
|
||||
---
|
||||
|
||||
## BLOC 3 – Mode automatique : 50 profils et UI hiérarchique (§5)
|
||||
|
||||
**FILES:** `web/js/types.js` | `web/js/auto-mode-profiles.js` (new) | `web/js/bot-zoo.js` | `web/js/game-loop.js` | `web/js/ui.js` | `web/js/texts-fr.js`
|
||||
|
||||
**STEPS:**
|
||||
1. Créer **web/js/auto-mode-profiles.js** : modèle des 50 profils (id, famille, spécialisation, libellé, paramètres : seuil dépense, fréquence, types d’animaux préférés, etc., priorité et risques en clés i18n). Familles : Conservateurs (1–10), Éleveurs (11–20), Commerçants (21–30), Expansionnistes (31–40), Scientifiques (41–50).
|
||||
2. **types.js** : étendre le state pour stocker le profil choisi (ex. `autoModeProfileId: string` ou `autoModeFamily` + `autoModeSpecialisation`) ; garder rétrocompat avec `autoModeProfile` pour migration.
|
||||
3. **bot-zoo.js** / **game-loop.js** : adapter la logique mode auto pour utiliser les paramètres du profil sélectionné (seuils, fréquences, priorités) au lieu des 3 profils fast/slow/balanced uniquement. Mapper les 50 profils vers les paramètres numériques utilisés par `playerAutoDoOneUpgrade` et les décisions bot.
|
||||
4. **ui.js** : ajouter une **interface de sélection hiérarchique** : étape 1 = choix de la Famille (5 boutons ou cartes), étape 2 = choix de la Spécialisation dans la famille (liste des 10 profils), affichage des priorités et risques pour le profil sélectionné. Remplacer ou compléter le simple toggle mode auto par l’ouverture de cette interface (ex. au clic sur le bouton mode auto quand inactif).
|
||||
5. **texts-fr.js** : ajouter les libellés des 5 familles, des 50 spécialisations, et les textes priorités/risques par profil.
|
||||
|
||||
**DONE_WHEN:** 50 profils définis et sélectionnables via Famille → Spécialisation ; mode auto utilise le profil choisi ; libellés centralisés.
|
||||
|
||||
---
|
||||
|
||||
## BLOC 4 – Visitor.MaxSecondsWithoutVisit + disparition animaux (§2)
|
||||
|
||||
**FILES:** `web/js/config.js` | `web/js/game-loop.js` | `web/js/income.js` ou module visiteurs | `web/js/state.js`
|
||||
|
||||
**STEPS:**
|
||||
1. **config.js** : ajouter `Visitor.MaxSecondsWithoutVisit` (ex. 300 pour 5 min).
|
||||
2. Dans la boucle de jeu (ou module qui gère les visites), pour chaque animal : si `now - lastVisitedAt > MaxSecondsWithoutVisit`, retirer l’animal de la grille et incrémenter `deathCountRecent` (ou appliquer la règle de mort « pas visité » déjà existante si présente).
|
||||
3. S’assurer que `lastVisitedAt` est mis à jour quand un visiteur « visite » l’animal (vérifier income.js / visitor logic).
|
||||
|
||||
**DONE_WHEN:** Un animal non visité pendant la durée configurée est retiré et compte comme mort ; config lisible.
|
||||
|
||||
---
|
||||
|
||||
## BLOC 5 – Interface : barre non reconstruite, erreur masquée (§4)
|
||||
|
||||
**FILES:** `web/js/ui.js`
|
||||
|
||||
**STEPS:**
|
||||
1. **Barre** : identifier les parties dynamiques (indicateurs : pièces, parcelle, case, compétences, visiteurs, œufs, météo ; icônes musique, quêtes, prestige, restart, mode auto, vue zoo/monde). Ne pas recréer tout le DOM de la barre à chaque `setState()` ; ne mettre à jour que les nœuds dont le contenu change (ex. `statusBarCoins.valueEl.textContent`, etc.). Si le rendu actuel recrée tout le contenu à chaque appel, refactorer pour garder des références aux éléments et les mettre à jour dans une fonction dédiée (ex. `updateStatus()` déjà partiellement en place).
|
||||
2. **Onglets** : vérifier qu’il n’y a pas de titres « Carte du zoo » / « Carte du monde » affichés comme onglets ; garder uniquement le sélecteur icônes (🦒 / 🗺️). Supprimer ou masquer les titres d’onglets s’ils existent.
|
||||
3. **Erreur** : s’assurer que le message d’erreur est `hidden` ou `display: none` quand `errorMsg.current` est vide, et qu’il ne réserve pas d’espace (éviter un bloc vide visible).
|
||||
|
||||
**DONE_WHEN:** Barre mise à jour par mise à jour ciblée des indicateurs ; pas de titres d’onglets ; message d’erreur invisible et sans emprise quand vide.
|
||||
|
||||
---
|
||||
|
||||
## BLOC 6 – Villes : formule attraction + cases (§3, §11)
|
||||
|
||||
**FILES:** `web/js/config.js` | `web/js/income.js` ou module attractivité | `web/js/ui.js` | `docs/features/villes-phase11.md`
|
||||
|
||||
**STEPS:**
|
||||
1. Vérifier / implémenter la **formule d’attraction** : proximité zoo–ville + valeur des animaux. Config ou state pour le plafond « max visiteurs vers zoos » par ville (ex. sur chaque ville dans `GameConfig.WorldMap.Cities` : `maxVisitorsToZoos`).
|
||||
2. **Carte du monde** : afficher pour chaque ville 1 case nom et 1 case « nombre max visiteurs vers zoos » (lecture depuis config ou state). Voir `docs/features/villes-phase11.md`.
|
||||
3. Utiliser ce plafond dans le calcul des visiteurs alloués aux zoos (répartition ou limite depuis les villes).
|
||||
|
||||
**DONE_WHEN:** Villes affichent nom et max visiteurs ; formule d’attraction et plafond pris en compte dans le flux visiteurs.
|
||||
|
||||
---
|
||||
|
||||
## BLOC 7 – Stagnation (§3)
|
||||
|
||||
**FILES:** `web/js/config.js` | `web/js/income.js` | `web/js/state.js` | `web/js/game-loop.js`
|
||||
|
||||
**STEPS:**
|
||||
1. Définir en config : délai sans action d’évolution (ex. en secondes), plancher du multiplicateur (ex. 0.1 pour 10 %).
|
||||
2. Suivre la **dernière action d’évolution** par zoo (ou par joueur) : timestamp de dernière action (upgrade, achat, vente, placement, etc.). Stocker dans le state (ex. `lastEvolutionAt` déjà présent ; vérifier qu’il est mis à jour sur toutes les actions pertinentes).
|
||||
3. Dans le calcul du nombre de visiteurs (ou du multiplicateur de revenus visiteurs), appliquer un **multiplicateur dégressif** : si `now - lastEvolutionAt > seuil`, réduire le multiplicateur jusqu’au plancher (interpolation linéaire ou par paliers).
|
||||
|
||||
**DONE_WHEN:** Zoos sans évolution depuis le délai configuré subissent une baisse du multiplicateur visiteurs jusqu’au plancher.
|
||||
|
||||
---
|
||||
|
||||
## BLOC 8 – Incidents visiteurs + invités de luxe (§2)
|
||||
|
||||
**FILES:** `web/js/config.js` | `web/js/income.js` | `web/js/game-loop.js` | `web/js/ui.js` | `web/js/types.js` | `web/js/texts-fr.js`
|
||||
|
||||
**STEPS:**
|
||||
1. **Incidents** : modéliser les types (soif, poubelle pleine, banc requis, animal trop loin, envie de photo). Associer à un visiteur (ex. `visitorArrivals[].incident?: string`, `incidentAt?: number`). Config : fréquence en phase d’attente (camion en route, enchère en cours, éclosion longue).
|
||||
2. **Affichage** : bulle d’icône au-dessus du visiteur concerné ; au clic sur la bulle ou action correctrice (poser banc, etc.), marquer résolu et appliquer gain attractivité + pièces ; si ignoré, perte attractivité et départ prématuré.
|
||||
3. **Invités de luxe** : config `Visitor.LuxuryShare` (ex. 0.08). Pour une part des visiteurs, flag `isLuxury` ; dans le calcul des revenus (entrée + boutique), appliquer un multiplicateur (ex. 1.5 ou 2) pour ces visiteurs.
|
||||
|
||||
**DONE_WHEN:** Incidents apparaissent, affichage bulle, résolution/ignorance avec impact ; 8 % des visiteurs paient plus (entrée + boutique).
|
||||
|
||||
---
|
||||
|
||||
## BLOC 9 – Animaux : feedbacks visuels + causes de mort (§12)
|
||||
|
||||
**FILES:** `web/js/loot-tables.js` | `web/js/game-loop.js` | `web/js/income.js` | `web/js/ui.js` | `web/js/config.js` | `web/js/types.js`
|
||||
|
||||
**STEPS:**
|
||||
1. **Feedbacks visuels** : à partir des données déjà calculées (température, nourriture, lastVisitedAt, etc.), dériver des états (froid, chaud, faim, maladie, heureux). Rendu : teinte CSS ou classe sur la case/sprite (bleuâtre/givre, rougeâtre/vapeur, icône faim, couché/ternes, cœurs/couleurs vives). Pas de jauges.
|
||||
2. **Morts** : auditer le code (game-loop, trade, etc.) et comparer à la liste §12 (seuls, pas visités, nourriture, tué autre zoo, recherche trop basse, bébé non vendu à temps, bébé mature non placé à temps, animal accueil non placé à temps, vente échouée, température/milieu en écart). Implémenter les causes manquantes (délais, température, milieu).
|
||||
3. Documenter dans `docs/features/` ou `docs/fixKnowledge/` les causes de mort et les règles associées.
|
||||
|
||||
**DONE_WHEN:** États visuels animaux affichés ; toutes les causes de mort du §12 branchées ou documentées comme différées.
|
||||
|
||||
---
|
||||
|
||||
## BLOC 10 – Saisons (§12)
|
||||
|
||||
**FILES:** `web/js/config.js` | `web/js/state.js` | `web/js/game-loop.js` | `web/js/income.js` | `web/js/reproduction.js` | `web/js/ui.js` | `web/js/texts-fr.js`
|
||||
|
||||
**STEPS:**
|
||||
1. Introduire une **saison** (Printemps, Été, Automne, Hiver) : dérivée du temps de jeu (ex. cycle sur N jours) ou de la date réelle. Stocker dans le state (ex. `season: string`).
|
||||
2. Faire évoluer **météo** et **température** selon la saison (config : plages par saison). Adapter les formules de **reproduction** et **survie** (bonus/malus par type d’animal et saison).
|
||||
3. Affichage : indiquer la saison dans la barre ou sur la carte (texte ou icône).
|
||||
|
||||
**DONE_WHEN:** Les 4 saisons alternent ; météo/température et bonus/malus reproduction/survie dépendent de la saison ; affichage à jour.
|
||||
|
||||
---
|
||||
|
||||
## BLOC 11 – Billeterie : flux complet (§7, §10)
|
||||
|
||||
**FILES:** `web/js/income.js` | `web/js/config.js` | `web/js/state.js` | `docs/features/`
|
||||
|
||||
**STEPS:**
|
||||
1. Clarifier le **design** : arrivée des visiteurs depuis les villes → billeterie (cap 20 × niveau), durée max 1 journée par visiteur, départ par la billeterie, retour selon attractivité. Documenter dans `docs/features/billeterie-flux.md`.
|
||||
2. Implémenter le flux dans le module visiteurs / income : génération des arrivées (selon attractivité et plafond villes), entrée via billeterie (cap), suivi du temps passé dans le zoo, départ avant fin de journée, réinjection vers les zoos selon attractivité.
|
||||
|
||||
**DONE_WHEN:** Flux arrivée → billeterie → séjour max 1 jour → départ → retour selon attractivité documenté et codé.
|
||||
|
||||
---
|
||||
|
||||
## Références transverses
|
||||
|
||||
- **Compatibilité** : `normalizeLoadedCells` / loadState (animal inconnu → c0_r0, œuf → Color_1) : à conserver.
|
||||
- **Sécurité** : pas de confiance client, limitation fréquence, traçabilité (API/serveur).
|
||||
- **BDD** : aligné avec `docs/bdd-comptes.md` pour schéma et flux 401/404/200.
|
||||
Reference in New Issue
Block a user