# Format de lecture d’une solution — Bluffy r3

Le lecteur de l’Atelier d’étude accepte un JSON UTF-8 de 3 Mo maximum, avec 169 classes de mains NLHE. Ce n’est pas un solveur, ni un import natif GTO Wizard/Pio/GTO+. Un adaptateur doit convertir un export licitement disponible sans modifier ses chiffres. Le fichier reste en mémoire sur cette page et disparaît au rechargement. Seule la préférence visuelle de l’atelier est conservée.

**La validation est structurelle : elle ne prouve pas l’authenticité, la convergence ou la correction stratégique du fichier.** Elle ne valide pas non plus la légalité détaillée de l’historique. L’import n’active aucune notation automatique et ne remplace pas les grilles manuelles existantes.

## Objet racine

| Champ | Valeur / obligation |
|---|---|
| `schemaVersion` | `1` |
| `dataType` | `solver-export` ou `synthetic` (tests uniquement) |
| `source.name` | Logiciel/source déclarée |
| `source.version` | Version réelle de la source |
| `source.date` | Date du calcul/export |
| `source.reference` | Identifiant de calcul ou référence permettant de le retrouver |
| `source.rights` | Droits d’usage / licence déclarés |
| `source.convergence` | Précision, exploitabilité/résidu et unité déclarés par la source ; pas de valeur inventée |
| `evTolerance` | Tolérance non négative, dans la même unité que les EV ; fournie par la source |
| `context` | Hypothèses décrites ci-dessous |
| `hands` | Exactement 169 objets, une fois chaque classe, notation canonique `AA`, `AKs`, `AKo`, etc. |

## Contexte

- `variant`: `NLHE`.
- `format`: `cash`, `tournament-chipEV` ou `tournament-ICM`.
- `players`: tous les joueurs, chaque objet avec `position` unique et `stackBB` initial positif. De 2 à 10 joueurs.
- `heroPosition`: une des positions déclarées.
- `smallBlindBB`: montant de petite blinde rapporté à une BB ; `anteBB`: montant selon `anteRule`.
- `anteRule`: par joueur / BB ante / aucune, avec convention détaillée.
- `rakeRule`: pourcentage, cap, devise, no-flop-no-drop, et conditions, ou aucun.
- `history`: liste ordonnée des actions ; chaque objet contient `position`, `action`, `totalBB` (contribution totale à cette rue, pas incrément). `[]` si aucune action avant ce nœud.
- `node`: description exacte de la décision. Ce lecteur de 169 classes est destiné au préflop ; il ne décrit pas les combos spécifiques et blockers d’un nœud postflop.
- `actions`: liste de clés uniques, avec les sizings explicites dans les clés ou dans `abstraction`. Au moins deux actions.
- `abstraction`: arbre étudié, sizings disponibles et exclus, autorisation des limps/calls/relances, précision des cartes, éventuelles restrictions.
- `evUnit`: par exemple `BB` ou `EUR`. Les valeurs doivent avoir une unité homogène.
- `evOrigin`: origine précise, par exemple « tapis au début de la main, blindes comprises » ou « décision actuelle, fold = 0 ».
- `payouts`: en ICM, une valeur par joueur restant, de la première à la dernière place, y compris les zéros. Le lecteur se limite aux modèles dont tous les joueurs restants sont décrits.
- `bounties`: `null`. Les exports PKO ne sont pas supportés par ce lecteur.

## Une ligne de main

Chaque objet contient :

- `hand`: classe canonique ;
- `reachWeight`: poids d’arrivée au nœud entre 0 et 1. À zéro, le lecteur n’affiche pas de verdict ;
- `frequencies`: une propriété numérique par action, entre 0 et 1, somme 1 (tolérance technique 0,000001) ;
- `ev`: une valeur finie par action, dans l’unité et l’origine déclarées. Aucune EV manquante ne doit être reconstruite arbitrairement.

Les fréquences sont conservées, y compris les stratégies mixtes. Le lecteur calcule uniquement la différence entre l’EV maximale fournie et chaque EV fournie. Il ne recalcule pas le jeu.

Pour un nœud inaccessible, `reachWeight = 0`. Des valeurs techniques finies peuvent servir dans ces lignes pour compléter le fichier, mais elles ne sont jamais affichées comme une décision. Si l’export ne contient pas les EV des actions accessibles, ce format ne doit pas être utilisé en inventant des zéros : il faut compléter l’export à la source.

## Avant de considérer une range comme une référence professionnelle

1. Conserver le fichier natif, sa provenance, sa licence et son empreinte.
2. Vérifier les structures de jeu, les tapis, les mises, les antes et le rake.
3. Comparer les fréquences et les EV du JSON au logiciel source sur chaque classe et action, sans arrondir une stratégie mixte à une action unique.
4. Vérifier la convergence et l’origine des EV.
5. Vérifier les combos et les poids d’arrivée au nœud ; ne pas confondre fréquence globale et fréquence conditionnelle.
6. Faire relire les spots limites et les simplifications par un coach compétent sur le format.
7. Versionner et retester chaque changement de modèle.

La page n’effectue pas ces validations externes à votre place. Aucune source de ranges professionnelles n’a été fournie avec le projet au moment de cette livraison.