4NK/cursor
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
785868b53b1d7d494a280bb1202941b5260125c3
cursor/builazoo/plan-action-cahier-des-charges.md
Nicolas Cantu 785868b53b 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>/
2026-03-03 23:29:29 +01:00

13 KiB
Raw Blame History

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 View Git Blame Copy Permalink