# Plan V1 — Mod Minecraft Boutique PNJ

## 1. Environnement

* Minecraft 1.21.1
* NeoForge
* Easy NPC intégré dès la V1
* support prioritaire du contenu Vanilla en V1
* architecture extensible pour les mods ajoutant :

  * recettes
  * tables de craft
  * fours
  * machines
  * systèmes de transformation
  * nouvelles familles de production

Farmer’s Delight pourra servir de premier cas réel de compatibilité, mais aucune architecture centrale ne doit être spécifique à Farmer’s Delight.

---

# 2. Principe architectural général

Le cœur du mod connaît uniquement des concepts abstraits :

```text
Boutique
Session
Mode de session
Recette
Station
Famille de production
Production
Commande
Client
Réputation
Provenance
```

Il ne doit pas dépendre directement de noms de mods particuliers.

Architecture générale :

```text
                         SHOP CORE
                            │
         ┌──────────────────┼───────────────────┐
         │                  │                   │
   RecipeResolver      ShopValidator     ProductionTracker
         │                  │                   │
         └──────────────────┼───────────────────┘
                            │
                    Production Registry
                            │
          ┌─────────────────┼──────────────────┐
          │                 │                  │
       Vanilla       Farmer's Delight       Autres mods
     Integration        Integration         Integration
```

---

# 3. Dépendances

## NeoForge

Utilisé pour :

* blocs
* menus/screens
* événements
* données joueur
* configuration serveur
* recettes
* synchronisation
* persistance
* données d'ItemStack
* rendu client du mode Vérification

## Easy NPC

Easy NPC fait partie de la V1.

Il est utilisé pour :

* représentation des clients
* modèles
* skins
* apparences
* dialogues
* interactions
* navigation/pathfinding
* spawn/despawn

Toute utilisation d’Easy NPC passe par une couche d’intégration :

```text
ShopManager
    ↓
CustomerManager
    ↓
NpcAdapter
    ↓
Easy NPC
```

Le cœur économique ne dépend jamais directement d’Easy NPC.

---

# 4. Concept général

Le joueur construit une boutique physique.

Des PNJ clients :

1. apparaissent à l’entrée ;
2. suivent le chemin vers la boutique ;
3. rejoignent la file ;
4. arrivent au comptoir ;
5. passent une commande ;
6. attendent ;
7. reçoivent les objets ;
8. paient ;
9. repartent.

Le joueur doit fabriquer les produits demandés dans la boutique.

Boucle générale :

```text
Approvisionnement
       ↓
Ouverture de session
       ↓
Clients
       ↓
Commandes
       ↓
Production
       ↓
Livraison
       ↓
Émeraudes
       ↓
Réputation éventuelle
```

---

# 5. Boutique physique et session

Séparer clairement :

## Shop

La boutique persistante.

Elle définit :

```text
propriétaire
zone
marqueurs
comptoir
stockage
entrée/sortie
chemins
stations
spécialisations disponibles
```

## ShopSession

Une période d’ouverture temporaire.

Elle définit :

```text
sessionId
shopId
gameplayMode
startTime
materialSnapshot
activeProductPool
activeStationFamilies
clients
commandes
état
```

La boutique reste identique d’une session à l’autre.

---

# 6. Choix du mode à chaque ouverture

Le mode de jeu n’est pas une configuration serveur permanente.

Lorsque le joueur clique sur :

```text
OPEN SHOP
```

ouvrir une fenêtre de préparation de session.

Exemple :

```text
OUVRIR LA BOUTIQUE

Choisissez un mode :

┌────────────────────────────┐
│         STANDARD           │
│                            │
│ Réputation active          │
│ Récompenses normales       │
│ Difficulté évolutive       │
│ Gestion avancée du stock   │
└────────────────────────────┘

┌────────────────────────────┐
│           CHILL            │
│                            │
│ Aucune variation de        │
│ réputation                 │
│ Récompenses réduites       │
│ Commandes plus tranquilles │
└────────────────────────────┘
```

Le joueur choisit le mode avant que la session commence réellement.

---

# 7. ShopGameplayMode

Créer :

```text
ShopGameplayMode
```

V1 :

```text
STANDARD
CHILL
```

Le mode est enregistré dans :

```text
ShopSession
```

et ne modifie pas la structure permanente de la boutique.

---

# 8. Mode STANDARD

Mode principal de progression.

Caractéristiques :

```text
Réputation active
Récompenses normales
Difficulté liée à la réputation
Fréquence de clients évolutive
Quantités évolutives
Gestion du stock évolutive
File évolutive
```

Les actions influencent la réputation.

```text
SUCCESS
→ réputation +

REFUSED
→ réputation -

TIMEOUT
→ réputation --

FORCE_CLOSE
→ réputation ---
```

---

# 9. Mode CHILL

Mode de session détendu.

Caractéristiques :

```text
aucun gain de réputation
aucune perte de réputation
récompenses réduites
commandes raisonnables
pression logistique réduite
patience plus généreuse
file modérée
```

La réputation permanente du joueur existe toujours.

Elle est simplement figée pendant cette session.

Exemple :

```text
Réputation avant session : 527

Session CHILL

SUCCESS      → 527
REFUSED      → 527
TIMEOUT      → 527
FORCE_CLOSE  → 527

Fin de session : 527
```

---

# 10. Récompenses CHILL

Les récompenses sont réduites afin que le mode CHILL ne devienne pas la meilleure méthode de farm.

Utiliser un multiplicateur configurable.

Exemple de valeur initiale :

```text
chillRewardMultiplier = 0.60
```

Une commande valant normalement :

```text
10 émeraudes
```

donnerait par exemple :

```text
6 émeraudes
```

en CHILL.

La valeur exacte devra être équilibrée par playtest.

---

# 11. Règles de commandes CHILL

Le mode CHILL doit conserver le gameplay de fabrication.

Il ne doit pas supprimer :

* commandes
* spécialisations
* Recipe Resolver
* production dans la boutique
* provenance
* chemins
* file
* patience
* stock

Il réduit uniquement la pression.

Politique recommandée :

```text
Stock réel utilisé
Quantités réelles prises en compte
Commandes raisonnablement réalisables
Patience supérieure
File plus courte
Fréquence modérée
```

---

# 12. Stock en CHILL

Le mode CHILL utilise toujours la logique de stock sécurisé.

Le générateur regarde :

```text
types disponibles
+
quantités disponibles
```

afin d’éviter autant que possible les commandes impossibles.

Il n’utilise donc pas le mécanisme exigeant de snapshot par type de matière utilisé à haute réputation en STANDARD.

---

# 13. Stock en STANDARD

La politique dépend de la réputation.

## Réputation faible

Utiliser :

```text
types
+
quantités réelles
```

afin de protéger les nouveaux joueurs.

## Réputation élevée

À l’ouverture :

```text
stock
 ↓
snapshot des TYPES
 ↓
catalogue de session
```

Exemple :

```text
128 Iron
64 Coal
32 Logs
12 Diamond
```

devient :

```text
IRON
COAL
WOOD
DIAMOND
```

Les quantités ne sont ensuite plus utilisées pour limiter les commandes.

Le joueur doit gérer son réapprovisionnement.

---

# 14. Changement de mode

Impossible de changer le mode d’une session déjà ouverte.

Pour changer :

```text
Fermer la session
      ↓
Nouvelle ouverture
      ↓
Choisir un nouveau mode
```

Cela évite les exploits comme :

```text
ouvrir STANDARD
↓
profiter des paramètres
↓
passer CHILL juste avant un timeout
```

---

# 15. ShopGameplayRules

Ne pas disperser :

```text
if (mode == CHILL)
```

dans tout le projet.

Créer une abstraction :

```text
ShopGameplayRules
```

Implémentations :

```text
StandardGameplayRules
ChillGameplayRules
```

---

# 16. Responsabilités de ShopGameplayRules

Interface conceptuelle :

```text
getRewardMultiplier(...)
getReputationDelta(...)
getOrderDifficulty(...)
getOrderQuantityLimits(...)
getCustomerPatience(...)
getSpawnRate(...)
getMaxQueueSize(...)
getStockPolicy(...)
```

Les autres systèmes demandent leurs paramètres aux règles de la session.

---

# 17. Architecture du mode

```text
ShopSession
     │
     ├── ShopGameplayMode
     │
     └── ShopGameplayRules
             │
        ┌────┴─────┐
        │          │
   Standard      Chill
    Rules        Rules
```

Cela permettra éventuellement d’ajouter d’autres modes plus tard sans modifier tout le mod.

---

# 18. Comptoir

Le comptoir est le contrôleur principal.

Il possède :

```text
5 slots de livraison
```

Il affiche :

* état boutique
* mode de session
* commande active
* réputation
* récompense
* patience
* file
* catalogue
* spécialisations
* mode Vérification

Boutons :

```text
OPEN SHOP
CLOSE ARRIVALS
FORCE CLOSE
REFUSE ORDER
VERIFY SHOP
```

---

# 19. Écran de préparation de session

Le bouton OPEN SHOP ne doit plus immédiatement démarrer la boutique.

Flux :

```text
OPEN SHOP
    ↓
Validation boutique
    ↓
Écran préparation
    ↓
Choix STANDARD / CHILL
    ↓
Résumé session
    ↓
CONFIRM OPEN
```

---

# 20. Résumé avant ouverture

L’écran peut afficher :

```text
MODE
STANDARD

ZONE
✓ Valide

SPÉCIALITÉS
3 / 3

CATALOGUE
127 produits potentiels

STOCK
Mode : Snapshot haute réputation

RÉCOMPENSES
×1.00

RÉPUTATION
Active

[ CONFIRMER L'OUVERTURE ]
```

Pour CHILL :

```text
MODE
CHILL

STOCK
Mode : Quantités réelles

RÉCOMPENSES
×0.60

RÉPUTATION
Figée
```

---

# 21. Validation des objets au comptoir

Consommer uniquement les quantités nécessaires.

Commande :

```text
24 Stone
8 Torch
```

Inventaire :

```text
64 Stone
5 Torch
3 Torch
1 Diamond
```

Résultat :

```text
40 Stone
1 Diamond
```

Le système :

* fusionne plusieurs stacks logiquement ;
* consomme exactement les quantités demandées ;
* ignore les objets sans rapport ;
* vérifie la provenance.

Validation entièrement serveur.

---

# 22. Stockage de matières premières

Bloc spécifique.

Il accepte seulement les matières configurées.

Exemples :

```text
#minecraft:logs
minecraft:iron_ingot
minecraft:gold_ingot
minecraft:diamond
minecraft:redstone
```

Doit supporter :

* IDs Vanilla
* IDs moddées
* tags

D’autres joueurs peuvent approvisionner la boutique.

---

# 23. Zone de boutique

Deux marqueurs définissent les coins opposés d’un cuboïde.

Calcul :

```text
minX/maxX
minY/maxY
minZ/maxZ
```

Taille maximale configurable.

Exemple :

```text
32 × 32 × 16
```

---

# 24. ShopValidator

Créer :

```text
ShopValidator
```

Fonction conceptuelle :

```text
ShopValidationResult scan(Shop shop)
```

Résultat :

```text
zoneValid
zoneDimensions

counterInside
storageInside

entryValid
exitValid

incomingPathValid
outgoingPathValid

queuePositions

detectedStations
detectedStationFamilies

unsupportedStations

errors
warnings
```

---

# 25. Mode Vérification

Accessible depuis le comptoir.

Afficher :

* volume boutique
* marqueurs
* comptoir
* stockage
* stations
* familles
* chemins
* waypoints
* file
* entrée/sortie
* erreurs
* avertissements

Aucun vrai bloc n’est placé.

---

# 26. Rapport de vérification

Exemple :

```text
ZONE
21 × 14 × 8

✓ Zone valide
✓ Comptoir valide
✓ Stockage valide


STATIONS

CRAFTING
  Crafting Table ×2

FORGE
  Furnace ×3
  Blast Furnace ×1

STONEWORKING
  Stonecutter ×1


SPÉCIALISATIONS

3 / 3


CHEMINS

✓ Entrée → Comptoir
✓ Comptoir → Sortie
✓ 4 positions de file


WARNINGS

⚠ Machine inconnue :
othermod:custom_machine
```

---

# 27. Spécialisations

Limiter le nombre de familles de production et non le nombre de blocs.

Exemple :

```text
6 Furnaces
3 Blast Furnaces
2 Smithing Tables
```

peuvent appartenir à :

```text
FORGE
```

et compter pour une seule spécialité.

---

# 28. StationFamily

Concept générique extensible.

Exemples :

```text
CRAFTING
FORGE
COOKING
STONEWORKING
SMITHING
```

Mods futurs :

```text
MECHANICAL_PROCESSING
PRESSING
MILLING
WOODWORKING
ADVANCED_COOKING
```

---

# 29. Limite de spécialisation

Configuration serveur :

```text
station_type_limit_enabled = true
max_station_types_per_shop = 3
```

La limite appartient à la boutique, pas au mode CHILL/STANDARD.

Une session CHILL ne permet donc pas de contourner les spécialisations.

---

# 30. Framework de compatibilité mods

La V1 doit disposer d’un framework interne permettant d’enregistrer :

```text
RecipeProvider
StationProvider
ProductionHandler
StationFamilyProvider
```

Les systèmes centraux utilisent ces interfaces.

---

# 31. Règle de compatibilité fondamentale

Le cœur ne doit pas contenir de logique :

```text
if Farmer's Delight
if Create
if Mekanism
...
```

Préférer :

```text
Registry
   ↓
Providers
   ↓
Handlers
```

---

# 32. Niveaux de compatibilité

## Niveau 1 — Automatique

Nouvelles recettes utilisant un RecipeType déjà supporté.

Aucun code spécifique.

## Niveau 2 — Déclaratif

Nouvelle station simple.

Déclaration possible :

```text
block = modid:custom_table
family = CRAFTING
recipe_type = modid:crafting
```

## Niveau 3 — Adapter léger

Comportement particulier.

Créer un :

```text
ProductionHandler
```

## Niveau 4 — Intégration complète

Pour :

* machines multibloc
* fluides
* énergie
* automation complexe
* production continue
* chaînes mécaniques

---

# 33. RecipeProvider

Responsable de fournir une représentation commune des recettes.

Doit exposer conceptuellement :

```text
inputs
outputs
recipeType
requiredStationFamily
conditions
```

---

# 34. StationProvider

Responsable de déterminer :

```text
Est-ce une station ?
Quelle famille ?
Quels RecipeTypes ?
Quel ProductionHandler ?
```

---

# 35. ProductionHandler

Responsable de la production réelle.

Concept :

```text
canHandle(...)
detectProduction(...)
getProducedStacks(...)
getProductionContext(...)
```

---

# 36. Recettes et stations séparées

Un mod peut :

* ajouter des recettes sans station ;
* ajouter une station sans nouveau RecipeType ;
* réutiliser une station existante ;
* créer les deux.

Le framework doit traiter chaque cas séparément.

---

# 37. Farmer’s Delight

Farmer’s Delight est un test du framework, pas une exception architecturale.

Une intégration future pourra déclarer :

```text
Cooking Pot
Cutting Board
RecipeTypes associés
ProductionHandlers
StationFamilies
```

Les addons qui ajoutent simplement des recettes aux mêmes mécanismes doivent être reconnus autant que possible sans intégration supplémentaire.

---

# 38. Vanilla comme intégration

Même les mécaniques Vanilla doivent utiliser le framework.

Support V1 :

* crafting inventaire 2×2
* crafting table
* furnace
* blast furnace
* smoker
* stonecutter
* smithing table
* éventuellement campfire

Ainsi :

```text
Vanilla = première intégration
```

et non :

```text
Vanilla = logique codée directement dans le core
```

---

# 39. Recipe Resolver

Créer :

```text
RecipeResolver
```

Pipeline :

```text
Matières
   ↓
RecipeProviders
   ↓
Graphe de recettes
   ↓
Intermédiaires
   ↓
Produits réalisables
   ↓
Stations nécessaires
   ↓
Familles disponibles
   ↓
Blacklist
   ↓
Règles de session
   ↓
Pool de commandes
```

---

# 40. ShopGameplayRules et RecipeResolver

Le RecipeResolver détermine ce qui est théoriquement fabriquable.

Les règles de session déterminent ensuite comment utiliser cette information.

Exemple :

```text
RecipeResolver :
"Diamond Sword est fabriquable"

STANDARD haute réputation :
"Le type DIAMOND était présent au démarrage,
donc commande possible."

CHILL :
"Il faut également que les quantités disponibles
permettent raisonnablement cette commande."
```

---

# 41. Graphe de recettes

Gérer :

* dépendances récursives
* cycles
* recettes alternatives
* outputs multiples
* quantités
* intermédiaires
* station nécessaire

Exemple :

```text
Log → Planks → Sticks
               +
              Iron
               ↓
          Iron Sword
```

---

# 42. Production Tracker

Créer :

```text
ShopProductionTracker
```

Responsabilités :

```text
identifier boutique
identifier session
identifier station
identifier producteur
marquer output
valider provenance
```

---

# 43. Provenance

Produit manufacturé :

```text
ShopProductionData
```

Exemple :

```text
shopId
sessionId
crafterUUID
productionHandlerId
stationFamilyId
craftedForShop
```

---

# 44. Matières premières externes

Autoriser :

```text
ami apporte Diamond
→ valide
```

---

# 45. Produits finis externes

Refuser comme produits de commande :

```text
ami apporte Diamond Sword
→ provenance invalide
```

Mais :

```text
ami apporte Diamond
↓
épée craftée dans la boutique
↓
provenance valide
```

---

# 46. Session et provenance

La provenance dépend également du :

```text
sessionId
```

Un objet produit lors d’une ancienne session ne doit pas automatiquement satisfaire une commande d’une nouvelle session.

Cela s’applique à STANDARD et CHILL.

---

# 47. Modes et anti-cheese

Le mode CHILL ne doit jamais désactiver :

```text
provenance
zone
spécialisation
validation de production
```

Sinon il pourrait servir à fabriquer facilement un stock d’objets valides pour STANDARD.

Les données de session empêchent ce problème.

---

# 48. Machines différées

Pour les machines comme les fours :

```text
ShopProductionContext
```

Exemple :

```text
shopId
sessionId
stationPosition
handlerId
startTime
```

---

# 49. États de boutique

## CLOSED

Pas de session active.

## OPEN

Nouveaux clients autorisés.

## ARRIVALS_CLOSED

Nouveaux clients bloqués.

Clients existants conservés.

## FORCE_CLOSED

Clients non servis expulsés.

En STANDARD :

```text
réputation -
```

En CHILL :

```text
réputation inchangée
```

---

# 50. Clients

Créer :

```text
ShopCustomer
```

Exemple :

```text
customerId
shopId
sessionId
currentOrder
state
queuePosition
patience
appearanceProfile
npcReference
```

États :

```text
SPAWNING
WALKING_TO_QUEUE
WAITING_IN_QUEUE
WALKING_TO_COUNTER
ORDER_ACTIVE
SERVED
REFUSED
TIMEOUT
LEAVING
DESPAWNED
```

---

# 51. Easy NPC

Créer :

```text
integration/easynpc/
```

Exemples :

```text
EasyNpcAdapter
EasyNpcCustomerFactory
EasyNpcDialogueController
EasyNpcNavigationController
EasyNpcAppearanceController
```

---

# 52. Apparence des clients

Créer :

```text
CustomerAppearanceProfile
```

Pouvant contenir :

```text
model
skin
displayName
visual settings
```

Utiliser les modèles et possibilités disponibles dans Easy NPC.

Ne pas limiter arbitrairement aux Villagers/Illagers.

---

# 53. Entrée / sortie

Bloc dédié servant au :

```text
spawn
retour
despawn
```

V1 : un même point peut être utilisé pour entrée et sortie.

---

# 54. Chemins

Deux couleurs de tapis.

Exemple :

```text
Bleu :
entrée → comptoir

Rouge :
comptoir → sortie
```

Créer :

```text
ShopPathManager
```

---

# 55. Navigation

Séparation :

```text
ShopPathManager
       ↓
Waypoint
       ↓
NpcNavigationAdapter
       ↓
Easy NPC
```

Le ShopPathManager décide où aller.

Easy NPC gère le déplacement physique.

---

# 56. File d’attente

Positions dérivées du chemin entrant.

```text
COMPTOIR
   ↑
Client 1
   ↑
Client 2
   ↑
Client 3
   ↑
Entrée
```

La capacité effective peut dépendre de :

```text
capacité physique
+
ShopGameplayRules
```

---

# 57. Patience

STANDARD :

la patience évolue éventuellement avec la progression/difficulté.

CHILL :

patience généralement plus généreuse.

Dans les deux modes :

la patience principale commence lorsque la commande devient active.

---

# 58. Résultats de commande

```text
SUCCESS
REFUSED
TIMEOUT
FORCE_CLOSE
```

Ils sont identiques dans les deux modes.

Ce sont leurs conséquences qui changent.

---

# 59. Politique STANDARD

Exemple :

```text
SUCCESS
→ récompense normale
→ réputation +

REFUSED
→ aucune récompense
→ petite réputation -

TIMEOUT
→ aucune récompense
→ réputation -

FORCE_CLOSE
→ aucune récompense
→ forte réputation -
```

---

# 60. Politique CHILL

```text
SUCCESS
→ récompense réduite
→ réputation 0

REFUSED
→ aucune récompense
→ réputation 0

TIMEOUT
→ aucune récompense
→ réputation 0

FORCE_CLOSE
→ aucune récompense
→ réputation 0
```

Les clients repartent normalement.

Le gameplay reste cohérent sans conséquence persistante.

---

# 61. Réputation

Liée au propriétaire.

Échelle proposée :

```text
0 → 1000
```

En STANDARD, elle influence :

* difficulté
* fréquence
* quantité
* valeur
* file
* comportement stock

En CHILL :

elle ne change pas et n’est pas utilisée comme principal moteur de difficulté.

---

# 62. Rang

Exemple possible :

```text
0–99       Inconnu
100–249    Petit commerçant
250–449    Marchand
450–699    Commerçant réputé
700–899    Marchand renommé
900–1000   Fournisseur royal
```

Les seuils restent configurables.

---

# 63. Monnaie

Utiliser :

```text
minecraft:emerald
```

Récompense calculée selon :

* objet
* quantité
* complexité
* chaîne de production
* éventuellement réputation
* multiplicateur du mode

---

# 64. Blacklist produits

Configuration serveur.

Support Vanilla et moddé.

```text
product_blacklist
```

---

# 65. Whitelist matières

Support :

* IDs
* tags
* objets moddées

Exemple :

```text
#minecraft:logs
minecraft:iron_ingot
farmersdelight:tomato
some_mod:raw_material
```

---

# 66. Configuration serveur

Les valeurs d’équilibrage restent configurables.

Exemples :

```text
max_shop_size

material_whitelist
product_blacklist

max_reputation

standard_reputation_rewards
standard_reputation_penalties

standard_spawn_rate
standard_queue_limits

chill_reward_multiplier
chill_spawn_rate
chill_queue_limit
chill_patience_multiplier

order_quantity_limits

station_type_limit_enabled
max_station_types_per_shop

enabled_station_families
enabled_production_handlers

inspection_mode_enabled
```

La configuration serveur définit les règles générales.

Mais **le joueur choisit STANDARD ou CHILL à chaque ouverture**.

---

# 67. Compatibilité et modes

Les compatibilités de production doivent être complètement indépendantes du mode.

Exemple :

```text
Farmer's Delight Cooking Pot
```

peut être utilisé en :

```text
STANDARD
ou
CHILL
```

sans handler spécifique au mode.

Le handler décrit la production.

`ShopGameplayRules` décrit les règles de session.

---

# 68. Performances

Ne pas scanner la zone à chaque tick.

Scanner :

* lors de VERIFY
* lors de OPEN SHOP
* lorsque la structure devient invalide
* éventuellement après changement pertinent

Mettre en cache :

```text
ShopValidationResult
```

---

# 69. Cache des recettes

Mettre en cache le graphe en fonction notamment de :

```text
RecipeProviders
stations disponibles
familles
whitelist
blacklist
```

Puis appliquer les règles de session par-dessus.

Cela évite de reconstruire tout le graphe simplement parce que le joueur passe de STANDARD à CHILL.

---

# 70. Persistance

Persistant :

```text
Shop
owner
zone
markers
counter
storage
paths
reputation
configuration structurelle
```

Session :

```text
sessionId
gameplayMode
state
snapshot
activeProductPool
customers
orders
```

---

# 71. Redémarrage serveur

Décider une stratégie robuste.

Deux possibilités futures :

```text
reprendre session
```

ou :

```text
fermer proprement session au redémarrage
```

Mais dans tous les cas, le mode de session doit être persisté si la session est restaurée.

---

# 72. Multijoueur

V1 :

* d’autres joueurs peuvent approvisionner en matières premières ;
* les produits finis externes restent invalides.

Prévoir futur :

```text
OWNER
ASSISTANT
OUTSIDER
```

---

# 73. Structure de code indicative

```text
shop/
├── core/
│   ├── ShopManager
│   ├── Shop
│   ├── ShopSession
│   ├── ShopState
│   └── ShopGameplayMode
│
├── gameplay/
│   ├── ShopGameplayRules
│   ├── StandardGameplayRules
│   └── ChillGameplayRules
│
├── validation/
│   ├── ShopValidator
│   └── ShopValidationResult
│
├── recipe/
│   ├── RecipeResolver
│   ├── RecipeProvider
│   └── RecipeGraph
│
├── production/
│   ├── ShopProductionTracker
│   ├── ProductionHandler
│   ├── ProductionContext
│   └── ShopProductionData
│
├── station/
│   ├── ShopStationRegistry
│   ├── StationProvider
│   ├── StationDefinition
│   └── StationFamily
│
├── customer/
│   ├── CustomerManager
│   ├── ShopCustomer
│   └── CustomerAppearanceProfile
│
├── path/
│   ├── ShopPathManager
│   └── QueueManager
│
├── integration/
│   └── easynpc/
│
└── compat/
    ├── vanilla/
    ├── farmersdelight/
    ├── create/
    └── ...
```

---

# 74. Ordre de développement

## Phase 1 — Setup

* NeoForge
* Easy NPC
* registries
* config
* données joueur

## Phase 2 — Core boutique

* Shop
* comptoir
* stockage
* markers
* zone
* ShopSession

## Phase 3 — Gameplay Modes

Créer très tôt :

```text
ShopGameplayMode
ShopGameplayRules
StandardGameplayRules
ChillGameplayRules
```

Ainsi les systèmes suivants ne coderont jamais directement les règles STANDARD.

## Phase 4 — Compatibility Framework

Créer :

```text
RecipeProvider
StationProvider
ProductionHandler
StationFamily
ShopStationRegistry
```

## Phase 5 — Vanilla Integration

Implémenter Vanilla via le framework.

## Phase 6 — ShopValidator / Inspection

* scan zone
* stations
* familles
* overlay
* chemins
* erreurs

## Phase 7 — Spécialisations

* limites
* validation
* configuration

## Phase 8 — Recipe Resolver

* graphe
* providers
* capacités boutique
* blacklist
* politiques de stock

## Phase 9 — Écran d’ouverture

Créer :

```text
OPEN SHOP
↓
validation
↓
sélection STANDARD / CHILL
↓
preview
↓
création ShopSession
```

## Phase 10 — Orders

* génération
* quantités
* validation
* récompenses
* règles STANDARD/CHILL

## Phase 11 — Production Tracking

* provenance
* handlers
* sessions
* stations Vanilla

## Phase 12 — Easy NPC

* spawn
* apparences
* dialogues
* navigation
* despawn

## Phase 13 — Paths / Queue

* tapis
* waypoints
* file

## Phase 14 — Réputation

* progression STANDARD
* rangs
* seuils
* stock haute réputation
* neutralisation complète en CHILL

## Phase 15 — GUI finale

* dashboard
* commandes
* mode courant
* diagnostic
* réputation
* catalogue

## Phase 16 — Première compatibilité moddée

Farmer’s Delight est un bon candidat.

Le test doit vérifier que :

```text
nouvelles recettes
nouvelles stations
nouveaux handlers
```

peuvent être ajoutés sans modifier le cœur.

## Phase 17 — Robustesse

Tester STANDARD et CHILL séparément ainsi que les transitions entre sessions.

---

# 75. Tests spécifiques des modes

Tester :

```text
ouvrir STANDARD
fermer
ouvrir CHILL

ouvrir CHILL
fermer
ouvrir STANDARD
```

Vérifier qu’aucun état ne fuit d’une session vers l’autre.

---

# 76. Tests réputation

Cas :

```text
Rep = 500
↓
ouvrir CHILL
↓
10 succès
3 refus
2 timeouts
↓
fermer
```

Résultat obligatoire :

```text
Rep = 500
```

Puis :

```text
ouvrir STANDARD
```

La progression reprend normalement à 500.

---

# 77. Tests provenance entre modes

Exemple :

```text
Session CHILL A
→ fabrication Iron Sword
→ session terminée

Session STANDARD B
→ ancienne Iron Sword utilisée
```

Elle ne doit pas être valide simplement parce qu’elle a été produite dans la même boutique.

Le `sessionId` doit empêcher ce contournement.

---

# 78. Tests ouverture de session

Avant création de la session :

```text
validation structurelle
validation stations
validation spécialisation
validation chemins
```

Puis seulement :

```text
choix mode
création sessionId
snapshot/catalogue
spawn clients
```

---

# 79. Critère de réussite de la séparation Shop / Session

Le joueur doit pouvoir :

```text
construire UNE boutique
```

puis jouer :

```text
Session 1 : STANDARD
Session 2 : STANDARD
Session 3 : CHILL
Session 4 : STANDARD
```

sans :

* reconstruire
* déplacer les stations
* refaire les chemins
* recréer le stockage
* changer une configuration serveur

---

# 80. Critère de réussite du framework moddé

Ajouter une nouvelle station doit idéalement demander seulement :

```text
StationProvider
RecipeProvider
ProductionHandler
StationFamily
```

et ne nécessiter aucune modification de :

```text
ShopManager
ShopValidator
OrderGenerator
ShopGameplayRules
```

---

# 81. Critère de réussite du mode CHILL

CHILL ne doit pas être :

```text
"STANDARD mais sans réputation"
```

Il doit réellement être une expérience moins stressante.

Donc :

```text
récompenses plus faibles
commandes plus sûres
stock réel
patience supérieure
fréquence raisonnable
file raisonnable
```

tout en conservant :

```text
production
spécialisation
logistique
clients
commandes
provenance
```

---

# 82. Philosophie globale

La boutique définit :

```text
CE QUE JE PEUX PRODUIRE
```

La session définit :

```text
COMMENT JE VEUX JOUER AUJOURD'HUI
```

STANDARD signifie :

```text
progression
risque
récompense
gestion
réputation
```

CHILL signifie :

```text
production
ambiance
clients
organisation
sans pression persistante
```

Les deux utilisent exactement la même boutique.

---

# 83. Résumé architectural final

```text
SHOP
│
├── Structure physique
├── Stations
├── Stockage
├── Paths
└── Spécialisations
       │
       ▼
   OPEN SHOP
       │
       ▼
Choix du GameplayMode
       │
   ┌───┴────┐
   │        │
STANDARD   CHILL
   │        │
   └───┬────┘
       │
       ▼
   ShopSession
       │
       ├── RecipeResolver
       ├── OrderGenerator
       ├── Customers
       ├── ProductionTracker
       └── Rewards
```

---

# 84. Principe final à transmettre à Codex

Le mod doit distinguer strictement :

```text
SHOP
= infrastructure persistante

SESSION
= une ouverture de boutique

GAMEPLAY MODE
= règles appliquées à cette session
```

Le joueur choisit `STANDARD` ou `CHILL` à chaque création de `ShopSession`.

Ce choix :

* ne modifie pas la boutique ;
* ne nécessite aucune reconfiguration ;
* ne peut pas être changé pendant une session ;
* n’affecte pas la compatibilité des stations ;
* n’affecte pas les règles de provenance ;
* modifie les récompenses, la réputation et certains paramètres de difficulté.

Le système doit utiliser une abstraction `ShopGameplayRules` plutôt que des conditions dispersées dans le code.

Enfin, le cœur reste conçu comme un framework générique de boutique et de production moddée :

```text
Recipes
Stations
Production
Gameplay Rules
Shop
NPC
```

restent des systèmes séparés et extensibles.
