# Genesis V5 · Bibliothèque de jeux

Créé et maintenu par Genesis V5 / Genesis Wave. Genesis développe ; Coach Prompt fournit le contrat de travail et les critères. Genesis V1 reste le lanceur d’installation.

## Livraison et périmètre

Cinq fichiers initiaux, sans dépendance externe : `index.html` (interface, CSS et JS), `games.json` (catalogue et modèle), `versions.json` (historique), `_headers.txt` (en-têtes à renommer par le préparateur) et ce guide. Destination source demandée : `/home/codex/Bureau/Genesis-Refonte/site-jeux-genesis-v5`. Ces contenus sont fournis pour écriture dans le nouveau dossier de mission ; aucune écriture, inspection de sources ou exécution n’a été réalisée dans cette réponse.

Le catalogue comporte onze titres : trois existants dont les mises à jour restent à préparer, huit créations planifiées. Les versions 0.2.0, 1.0.0 et 1.0.0 et les comptes de contrôles 26, 19 et 21 proviennent exclusivement du besoin fourni. Les manifestes ne sont pas joints. Les résultats, plateformes et commandes des titres existants restent inconnus. SILEX 002 est une évolution de `silex-glass-isles-001`, jamais un douzième jeu. Les versions 0.0.0 identifient des concepts non livrés.

Les intentions de mécaniques, progression, tactiques et commandes des huit créations sont explicitement prévues, non implémentées. Les illustrations SVG sont des compositions originales générées localement par le site, jamais des captures des jeux. Aucune durée n’a été mesurée. Aucun paquet jouable n’est inclus : tous les chemins valent `null`.

## Lancement local

Le chargement des JSON nécessite HTTP ; ouvrir directement le HTML en `file://` ne suffit généralement pas. Si Python 3 est déjà installé, lancer depuis le dossier du site :

```text
python3 -m http.server 8080
```

Ouvrir ensuite `http://localhost:8080`. Cette commande est une instruction manuelle, non exécutée ici. Aucun téléchargement ou installation n’est nécessaire au site.

## Contrat des données

`games.json` utilise `schemaVersion: 1`. Chaque entrée contient son identité stable, sa version, son statut, un chemin nullable, sa production, ses intentions ou faits de jeu, ses commandes, son visuel, sa monnaie et ses preuves. Le modèle `gameTemplate`, hors du tableau `games`, sert aux prochains titres : tous les champs propres au titre doivent être renseignés avant ajout. Un identifiant et un slug doivent être uniques. Le catalogue peut ensuite dépasser onze titres.

Statuts acceptés : `Planifié`, `En développement`, `Disponible`. Le statut ne constitue pas une preuve. Ne passer à `Disponible` qu’après intégration et recette du véritable paquet. La page refuse les chemins autres que `games/<slug>/index.html`, sans traversée, URL externe, paramètres ni fragment ; elle vérifie une réponse HTML locale avant de proposer Jouer. Ce contrôle réseau ne remplace pas la vérification physique du fichier par le préparateur : un hébergeur avec repli HTML pourrait répondre à une URL inexistante.

Les filtres restent dans la page pendant l’ouverture et la fermeture d’une fiche ; ils ne sont pas persistés après rechargement. Les dialogues natifs offrent fermeture par Échap, confinement du focus et retour au déclencheur. Les liens vers les jeux utilisent le même onglet. Les erreurs JSON disposent d’un message utile et d’un bouton de nouvelle tentative.

`durationMinutes: null` signifie non mesurée ; ne renseigner une valeur qu’avec une mesure. `receipt.passed` et `receipt.failed` restent `null` si les résultats ne sont pas vérifiés. Documenter la source et conserver les preuves réelles avant toute affirmation de recette.

## Monnaies

Conversion inter-jeux : prévue pour une version ultérieure, actuellement désactivée.

NXR est envisagé · test local uniquement, fictif et sans valeur financière. Les noms et contrats locaux non confirmés restent « à définir » / « statut à confirmer ». Points internes, jetons de test et actifs transférables sont distincts ; cette livraison ne propose aucun actif réellement transférable. Aucun wallet, taux, prix, solde, achat, retrait ou transaction.

Les champs `ecosystem.provider`, `ecosystem.testnet`, `ecosystem.adapters` et `currency.adapter` réservent une structure de configuration ; ils sont inactifs et aucun moteur d’échange n’est implémenté. Une future intégration exigera son propre développement et sa recette. Le site charge seulement ses JSON et, si renseignés, les paquets ou archives du même site.

## Préparation de release et Cloudflare Pages

Domaine cible : `jeux.lesbonplan.org`. Le projet Cloudflare Pages `genesis-wave` sert la bibliothèque ; la validation DNS/TLS du domaine reste à confirmer. Google OAuth reste reporté après finalisation ; le site actuel n’a pas de compte.

Le préparateur doit créer `dist/`, y copier les cinq fichiers statiques en renommant `_headers.txt` en `_headers`, et copier uniquement les vrais paquets dans `dist/games/<slug>/index.html` avec leurs ressources. Ne pas renseigner un chemin sans fichier présent. Aucune compilation, npm, CDN, VPS, base de données ou ressource payante n’est requise. Pour Pages, utiliser `dist` comme répertoire de sortie sans commande de compilation.

Avant toute release suivante, conserver une copie statique complète du site précédent dans `versions/<version>/`, avec ses JSON, ses ressources et ses jeux nécessaires. Ne pas créer d’archives récursives contenant les archives elles-mêmes. Ajouter une entrée à `versions.json` et préserver les précédentes ; renseigner `archivePath` uniquement après copie. Les chemins d’archives autorisés sont `versions/<version>/index.html` ; les liens ne sont proposés qu’après réponse HTML locale. Ne renseigner `publishedAt` et le statut publié qu’après confirmation Cloudflare. Aucune archive antérieure n’existe dans cette livraison.

Les en-têtes interdisent caméra, microphone, géolocalisation et paiement ; ils limitent les ressources et connexions au même site. Scripts/styles inline sont autorisés pour le HTML autonome ; la compilation WebAssembly locale est autorisée pour de futurs jeux. WebGL ne nécessite pas de source distante. Les futurs paquets doivent être vérifiés sous cette CSP, notamment les workers et les éventuels besoins d’isolation. Les JSON et l’entrée HTML demandent une revalidation ; les autres fichiers ont un cache court.

## Vérifications à réaliser et preuves

Aucun contrôle n’a été exécuté. Les listes de réussites et d’échecs dans `versions.json` sont vides : cela ne signifie pas que les tests passent. Les critères restent à vérifier en environnement réel.

1. Analyser les deux JSON et valider HTML, CSS et JavaScript ; vérifier les onze identifiants, l’absence de doublon SILEX et les valeurs inconnues.
2. Servir en HTTP ; vérifier recherche accentuée, combinaison genre/état/tri, réinitialisation, état vide et fiche de chaque titre.
3. Parcourir au clavier : lien d’évitement, contrôles, cartes, dialogues, Échap, retour du focus et conservation des filtres.
4. Vérifier à 390 px sans débordement horizontal, puis tablette/bureau, zoom et préférence de réduction des animations.
5. Simuler JSON absent ou invalide et vérifier message et nouvelle tentative. Contrôler console et réseau : aucune exception ou ressource tierce.
6. Vérifier physiquement chaque paquet et archive avant activation ; tester un chemin absent sous la configuration de l’hébergeur.
7. Vérifier les en-têtes après déploiement, le domaine et l’état réel de publication.
8. Recetter les jeux séparément ; conserver commandes, dates, environnement et résultats dans les preuves puis reporter uniquement les réussites/échecs réellement observés dans l’historique.

Le préparateur calculera les empreintes SHA-256 des fichiers effectivement écrits et les joindra au dossier de release, hors de ces cinq fichiers initiaux. Aucune empreinte n’est inventée ici. Le contrat des fichiers et les contrôles ci-dessus constituent le cahier de recette observable ; cette livraison prépare la porte d’entrée du catalogue, sans livrer ni valider les onze jeux.