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:
2026-03-03 23:29:29 +01:00
commit 785868b53b
114 changed files with 6455 additions and 0 deletions

View File

@@ -0,0 +1,208 @@
# Plan Cursor Rappel des grandes règles (174-324)
Exécution dans lordre : Phase 0 → 1 → 3 → 4 → 2 → 5 → 6 → 7 → 8 → 9 → 10 → 11 → 12 → 13.
Référence détaillée : `docs/plan-implementation-rappel-grandes-regles.md`.
---
## PHASE 0 Modèle de données et configuration
**FILES:** `web/js/types.js` | `web/js/config.js` | `web/js/state.js` | `web/js/loot-tables.js`
**STEPS:**
1. **types.js** Ajouter/étendre :
- `biome?: string` et `temperature?: number` sur les cases (ou sur la grille par case).
- Nouveaux kinds de cell : `research`, `billeterie`, `food`, `reception`, `biomeChangeColor`, `biomeChangeTemp`. Garder `souvenirShop` (alias boutique), `nursery`, camion reste zone/state.
- Types pour bébé/vente : `PendingBaby`, `ReceptionAnimal`, `SaleListing` (babyId/animalId, zooId, price, endAt, reproductionScoreAtSale?).
- Animal multi-case : sur `AnimalCell` ajouter `originKey?: string`, `cellsWide?: number`, `cellsHigh?: number` (optionnel, défaut 1).
- GameState : `researchPoints?: number`, `pendingBabies?: PendingBaby[]`, `receptionAnimals?: ReceptionAnimal[]`, `saleListings?: SaleListing[]`, `deathCountRecent?: number`, `birthCount?: number`, `feedingRate?: number`.
2. **config.js** Ajouter blocs (tous MaxLevel: 7 sauf si indiqué) :
- `Research: { MaxLevel: 7, ZoosPerUnit: 10, BaseUpgradeCost, UpgradeGrowth, PointsPerTickPerLevel }`
- `Billeterie: { MaxLevel: 7, VisitorsPerUnit: 20, BaseUpgradeCost, UpgradeGrowth }`
- `Food: { MaxLevel: 7, AnimalsPerUnit: 5, BaseUpgradeCost, UpgradeGrowth }`
- `Reception: { MaxLevel: 7, AnimalsPerUnit: 1, BaseUpgradeCost, UpgradeGrowth, AcclimatationSecondsBase }`
- `BiomeChangeColor: { MaxLevel: 7, BaseUpgradeCost, UpgradeGrowth }`
- `BiomeChangeTemp: { MaxLevel: 7, BaseUpgradeCost, UpgradeGrowth }`
- Mettre `Nursery.MaxLevel = 7`, `SouvenirShop.MaxLevel = 7`, `Truck.MaxLevel = 7`.
3. **state.js** Dans `defaultState()` : `researchPoints: 0`, `pendingBabies: []`, `receptionAnimals: []`, `saleListings: []`, `deathCountRecent: 0`, `birthCount: 0`. Prévoir cellules initiales pour recherche, billeterie, nourriture, accueil (voir phase 12 pour positions exactes).
4. **loot-tables.js** Pour chaque animal : `cellsWide: 1`, `cellsHigh: 1` (extensible en 2x2 plus tard), `idealTemperature?: number`, `temperatureTolerance?: number`, `reproductionScoreByBiome?: Record<string,number>`, `survivalScoreByBiome?: Record<string,number>`.
**DONE_WHEN:** Types compilent, config lue, defaultState contient les nouveaux champs, loot-tables exporte les champs animaux. Pas de régression sur le jeu actuel (ancien state reste valide).
---
## PHASE 1 Cartes : couleurs et températures
**FILES:** `web/js/biome-rules.js` | `web/js/grid-utils.js` | `web/css/main.css` | `web/js/ui.js`
**STEPS:**
1. Étendre biomes : eau douce, eau salée, montagne, prairie, forêt (au moins 5). Attribuer à chaque case un `biome` et un `temperature` (dérivés de la position ou stockés).
2. Exporter `getDisplayBiome(x, y, grid)` et `getDisplayTemperature(x, y, grid)` avec interpolation des voisins.
3. Rendu CSS : classes ou variables par biome et par plage de température ; dégradés entre cases.
4. Grille zoo et monde utilisent ces fonctions pour le fond des cases.
**DONE_WHEN:** Les cases affichent une couleur/milieu et une température avec transition douce.
---
## PHASE 3 Bâtiments zoo (7 niveaux)
**FILES:** `web/js/config.js` | `web/js/state.js` | `web/js/economy.js` | `web/js/placement.js` | `web/js/zoo.js` | `web/js/ui.js`
**STEPS:**
1. Coûts dupgrade pour research, billeterie, food, reception, biomeChangeColor, biomeChangeTemp (formules exponentielle comme Plot).
2. Placement : construction sur case vide pour research, billeterie, food, reception, biomeChangeColor, biomeChangeTemp. Upgrade sur clic comme aujourdhui pour nursery/souvenirShop.
3. Recherche : tick produit researchPoints (formule par niveau des cells research). Agrandissement carte consomme researchPoints (phase 9).
4. Billeterie / Boutique : capacités (visiteurs/unité) utilisées en phase 8.
5. UI : icônes et libellés pour chaque type de bâtiment ; affichage niveau et flèche upgrade si possible.
**DONE_WHEN:** Tous les bâtiments sont constructibles et upgradeables à 7 niveaux ; recherche produit des points.
---
## PHASE 4 Bébés et flux (remplacement œufs)
**FILES:** `web/js/state.js` | `web/js/zoo.js` | `web/js/placement.js` | `web/js/hatching.js` | `web/js/conveyor.js` | `web/js/ui.js` | `web/js/world-map.js`
**STEPS:**
1. Remplacer `pendingEggTokens` / œufs par `pendingBabies` (bébé en croissance en nurserie) et offres = bébés ou animaux adultes.
2. Nurserie : slot avec bébé en croissance ; durée selon niveau nurserie ; à la fin état « bébé mature » déplaçable (case zoo → animal, ou camion → vente).
3. Accueil : animal acheté/reçu va en `receptionAnimals` ; durée acclimatation ; à la fin « animal prêt » déplaçable (case zoo ou camion).
4. Conveyor/offres : générer offres de bébés et danimaux (pas dœufs). Achat envoie en nurserie (bébé) ou en accueil (animal).
5. UI : afficher bébé mature / animal prêt ; glisser vers case vide ou camion.
**DONE_WHEN:** Plus dœufs ; achat bébé/animal → nurserie/accueil → mature/prêt → placement ou vente.
---
## PHASE 2 Animaux multi-cases
**FILES:** `web/js/loot-tables.js` | `web/js/placement.js` | `web/js/grid-utils.js` | `web/js/ui.js` | `web/js/state.js`
**STEPS:**
1. Définir `cellsWide`, `cellsHigh` dans loot-tables (par défaut 1).
2. Placement : vérifier que toutes les cases (originKey + largeur/hauteur) sont vides et dans les limites.
3. Stockage : une entrée par case avec référence à lorigine (originKey) ou une entité avec originKey + dimensions.
4. Suppression / déplacement : libérer ou déplacer tout le bloc.
5. UI : dessiner lanimal sur plusieurs cases ; drag déplace le bloc.
**DONE_WHEN:** Au moins un type danimal 2x2 (ou 1x2) placeable et déplaçable.
---
## PHASE 5 Nourriture, consommation, morts
**FILES:** `web/js/config.js` | `web/js/state.js` | `web/js/food.js` (new) | `web/js/game-loop.js` | `web/js/animal-visits.js` | `web/js/loot-tables.js`
**STEPS:**
1. Module `food.js` : par tick, calculer consommation totale ; capacité nourriture = sum(food buildings × AnimalsPerUnit) ; répartir ; animaux non nourris reçoivent un déficit ou timer.
2. Mort si pas nourri au-delà dun seuil ; retirer de la grille ; incrémenter deathCountRecent.
3. Implémenter toutes les autres causes de mort (seul, pas visité, 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). Appeler une fonction `checkDeathCauses(state, nowUnix)` dans la game loop.
4. loot-tables : température idéale et tolérances par animal.
**DONE_WHEN:** Les animaux non nourris meurent ; les autres causes de mort sont branchées (même si certaines règles sont simplifiées au début).
---
## PHASE 6 Reproduction
**FILES:** `web/js/loot-tables.js` | `web/js/reproduction.js` (new) | `web/js/state.js` | `web/js/game-loop.js`
**STEPS:**
1. Détecter paires danimaux même type, origine « autre zoo » pour au moins un, en proximité (adjacent ou distance N).
2. Timer par paire ou par animal ; à léchéance créer un bébé → nurserie si place, sinon en vente. Utiliser score de reproduction du zoo et adéquation température/milieu pour réduire le délai.
3. Exposer score de reproduction par milieu et survie par milieu depuis loot-tables.
**DONE_WHEN:** Une paire admissible peut produire un bébé après un délai ; le bébé va en nurserie ou en vente.
---
## PHASE 7 Score de reproduction du zoo
**FILES:** `web/js/state.js` | `web/js/food.js` | `web/js/reproduction.js` | `web/js/trade.js` | `web/js/world-map.js`
**STEPS:**
1. birthCount incrémenté à chaque naissance ; feedingRate = ratio nourris/total (ou fenêtre glissante).
2. Formule score agrégé = f(birthCount, feedingRate, …). Exposer dans state et sur la carte du monde (case sous le nom du zoo).
3. À la vente, attacher `reproductionScoreAtSale` à lentité vendue (pour phase 6 côté acheteur).
**DONE_WHEN:** Score de reproduction affiché ; vendu porte le score du zoo vendeur.
---
## PHASE 8 Attractivité et visiteurs
**FILES:** `web/js/income.js` | `web/js/visitor-attraction.js` | `web/js/config.js` | `web/js/state.js` | `web/js/ui.js` | `web/js/world-map.js`
**STEPS:**
1. Entrée visiteurs uniquement via billeterie ; cap = Billeterie.VisitorsPerUnit × niveau total billeterie.
2. Durée max 1 journée par visiteur ; sortie par billeterie. Temps passé prolongé par boutiques et diversité animaux.
3. Formule attractivité : valeur cumulée, nombre despèces, rareté, taux remplissage ; pénalités morts ; bonus naissances.
4. Affichage score dattractivité sous le nom du zoo sur la carte du monde.
**DONE_WHEN:** Visiteurs plafonnés par billeterie ; attractivité calculée et affichée.
---
## PHASE 9 Carte du monde (recherche + compteurs)
**FILES:** `web/js/state.js` | `web/js/economy.js` | `web/js/world-map.js` | `web/js/ui.js` | `web/js/config.js`
**STEPS:**
1. Agrandissement carte payé en researchPoints (pas en pièces). Coût par palier en unités de recherche. Bouton grisé si pas assez.
2. Compteurs : bébés à vendre, animaux à vendre, laboratoires, zoos, villes (affichage sur la carte ou barre).
3. Case zoo : nom, score attractivité, score reproduction, case de vente (phase 10).
**DONE_WHEN:** Agrandissement carte consomme researchPoints ; compteurs affichés.
---
## PHASE 10 Ventes et enchères
**FILES:** `web/js/state.js` | `web/js/trade.js` | `web/js/world-map.js` | `web/js/ui.js` | `server/routes/zoos.js` ou `server/routes/trades.js` | `server/db.js`
**STEPS:**
1. Cases de vente sous chaque zoo sur la carte du monde ; afficher bébé ou animal à vendre + dernier montant enchère.
2. Depuis le zoo : glisser bébé mature ou animal sur le camion → création dune entrée saleListings (zoo du joueur).
3. API enchères : créer/consulter offres, enchérir, valider/refuser vente par le vendeur. Si délai dépassé sans vente validée pour un bébé → mort du bébé.
4. Vente validée : acheteur reçoit bébé (nurserie) ou animal (accueil) ; reproductionScoreAtSale attaché.
**DONE_WHEN:** Mise en vente depuis le zoo ; enchères joueurs/bots ; validation vendeur ; bébé invendu meurt.
---
## PHASE 11 Villes
**FILES:** `web/js/config.js` | `web/js/world-map.js` | `web/js/income.js` | `web/js/ui.js`
**STEPS:**
1. Chaque ville : 1 case nom, 1 case « nombre max visiteurs vers zoos ». Config ou state.
2. Répartir ou limiter les visiteurs vers les zoos selon ce plafond et lattractivité.
**DONE_WHEN:** Villes affichent le max visiteurs ; la règle limite ou répartit les visiteurs.
---
## PHASE 12 UI et grilles au lancement
**FILES:** `web/js/state.js` | `web/js/ui.js` | `web/js/world-map.js` | `web/css/main.css`
**STEPS:**
1. Grille zoo au lancement : 1 agrandissement, 1 recherche, 1 billeterie, 1 nurserie, 1 accueil, 1 nourriture, 1 camion, 24 cases 3 couleurs. Positions fixes dans defaultState().
2. Grille monde au lancement : 1 agrandissement carte (recherche), compteurs, 1 accueil, 1 nourriture, 1 camion, 24 cases 3 couleurs.
3. Transitions douces visibles (phase 1). Actions : achat sur case vide (tous les types), déplacement bébé mature / animal prêt. Accessibilité ARIA/clavier/contraste.
**DONE_WHEN:** Les deux grilles de lancement sont conformes au cahier ; toutes les actions sont accessibles.
---
## PHASE 13 Migration et compatibilité
**FILES:** `web/js/state.js` | `server/routes/zoos.js`
**STEPS:**
1. specVersion ou version dans game_state (ex. 1 = ancien œufs/école, 2 = rappel grandes règles).
2. Au load : si version 1, soit migration (œufs → bébés, école → research niv 1, etc.), soit message « sauvegarde incompatible ».
3. API accepte game_state étendu (JSONB) sans casser les anciens champs.
**DONE_WHEN:** Anciennes sauvegardes migrées ou refusées proprement ; nouvelles sauvegardes complètes.