• Kit KX/factory/kit/
• Configurateur KX/factory/kit/configurator/
• Variantes KX/factory/kit/variants/
• Chaîne en 9 étapes/factory/chain/
• Avant-poste OX/factory/outpost/
• Kit GX (pixel art)/factory/grid/
• Référentiel IA/factory/referential/
• Visionneuse 3D V1en bas de cette page

Blueprint Factory : handoff pour agent IA

À lire en premier. Ce document résume tout le contexte du projet Blueprint Factory (Kage Games) pour un agent qui arrive sur le projet. Point d'entrée public : https://kg.g.caute.re/factory/. Cette page contient ce document en entier, rendu en HTML statique : aucun JavaScript n'est nécessaire pour le lire. Versions alternatives : handoff.md (ce texte en Markdown brut), llms.txt (index court) et context.json (inventaire lisible par machine).

• État figé au : 10 novembre 2026, vers 23 h (heure de Paris), au commit 2700872. Le handoff a été ajouté en 8b7432b, puis rendu dans l'accueil.
• Langue du projet : français, pour l'UI, les docs, les commits et les échanges avec le propriétaire.
• Convention de ce document : chaque fait vient du dépôt, des docs ou de l'historique des demandes. Ce qui n'est pas vérifié est marqué [à confirmer].

Sommaire

1. En bref
2. Règles dures, à ne jamais enfreindre
3. But et vision
4. Index des livrables en ligne
5. Chronologie (commits)
6. Glossaire
7. Architecture du dépôt
8. Principes de conception transverses
9. V1 : bâtiments de colonie (spec → SVG → 3D)
10. Kit KX : cargo spatial modulaire
11. Configurateur et galerie de variantes KX
12. Chaîne factory en 9 étapes
13. Kit OX : avant-poste minier sur astéroïde
14. Kit GX : grille voxel pour pixel art
15. Référentiel IA
16. Formats de fichiers et schémas
17. Commandes : build, lint, tests, export
18. Palette : jamais de vert
19. Budgets triangles et poids web
20. Données gameplay
21. Problèmes connus
22. Journal des décisions
23. Questions ouvertes et prochaines étapes
24. Conventions de travail pour un agent
25. Contexte : Deep City
26. Données publiques lisibles par machine
27. Ce qui n'a pas pu être confirmé

1. En bref

• Quoi : une « usine à assets » pour jeux. On part d'une spec JSON paramétrique, on en tire des plans techniques SVG cotés (plusieurs vues), puis de la 3D Blender en trois versions (filaire, plein, texturé). Le tout est exporté en GLB (avec Draco pour le web) et vérifié jusqu'à l'import dans Godot 4.7.2.
• Pourquoi : les assets 3D générés directement, ceux du kit colonie, étaient « imprécis ». Le plan sert de référence à la 3D, et ce sont les mêmes sommets qui produisent le SVG et le maillage. Les cotes du plan sont donc celles du GLB par construction.
• Kits livrés :
  • KX : cargo spatial, avec 14 composants, 5 modules, 3 coques à slots vides et 4 assemblages.
  • OX : avant-poste minier sur astéroïde, dérivé de KX. Il a 12 composants propres plus 10 hérités de KX, 7 bâtiments, 3 parcelles et 3 assemblages.
  • GX : KX quantifié sur une grille voxel pour le pixel art, avec 15 composants, 5 modules, 3 coques et 4 assemblages.
• Outils web : une visionneuse 3D par kit, un configurateur KX (glisser-déposer, validation en direct), une galerie de variantes générées par seed, et une page qui illustre la chaîne de production en 9 étapes sur l'assemblage AX-02.
• Qualité : un lint par kit (KX 119/119, OX 150/150, GX 107/107), un QA de chaîne, des tests Playwright headless pour chaque page et un contrôle d'import Godot.
• Règle visuelle absolue : aucun vert, nulle part : art, UI, SVG et matériaux. Les lints le vérifient.
• Déploiement : par overlays tar.gz (préfixe launcher/), qui ne font qu'ajouter ou remplacer des fichiers. Ils sont appliqués par un opérateur d'infrastructure, jamais par l'agent de développement.
• Phase : exploratoire. Le propriétaire explore le principe « factory / composant ». Les pistes OX et GX sont des explorations, pas des choix figés.

2. Règles dures, à ne jamais enfreindre

1. Pas de vert dans les chartes graphiques, les UI, les SVG ou les matériaux. Est interdite toute teinte entre 70° et 170° avec une saturation ≥ 0,25 et une valeur ≥ 0,15. Voir §18.
2. Aucun secret dans le chat, les logs, git ou les pages publiques : clés, jetons, mots de passe, adresses internes.
3. Ne jamais déployer soi-même. On prépare un overlay, on le documente (taille, sha256, liste des fichiers) et un opérateur le fusionne.
4. Overlays uniquement : des fichiers ajoutés ou remplacés un par un.
   • Ne jamais lancer le build-site.sh complet du lanceur : il échoue, car des builds de POC ne sont plus présents.
   • Ne jamais remplacer le Caddyfile.
   • Ne jamais livrer un factory/ entier qui écraserait les sous-pages (voir §21 sur add-factory.sh).
5. Ne jamais toucher au DNS, à l'edge (proxy), au VPN ni aux ACL réseau.
6. Ne pas câbler jobs.json (file de jobs d'un autre outil, hors périmètre).
7. Unreal Engine est exclu (décision du propriétaire : « oublie Unreal Engine »). Le moteur cible des exports est Godot 4.7.2.
8. Les étapes Steamworks restent entre les mains du propriétaire. N'en engage aucune.
9. Documenter la chaîne : chaque étape doit avoir un script, un artefact et une trace (README, planche, capture).
10. Vérifier chaque affirmation avant de la reporter : un lint, un test ou un curl doit le confirmer. Une page en ligne n'est « en ligne » qu'une fois qu'elle a répondu 200.

3. But et vision

• Demande d'origine (9 nov. 2026) : les assets 3D du kit colonie étaient imprécis. Plutôt que générer directement une image ou un mesh, il fallait d'abord produire des plans 2D SVG multi-vues (dessus, face, profil, iso) qui servent de référence à la 3D. La 3D est ensuite déclinée en filaire, plein et texturé. Consigne : « Tente une V1 et on ajustera. »
• Vision qui s'en est dégagée : un système de familles d'objets cohérentes par construction. Une charte mesurée (grille, rivets, biseaux, bordé, interface d'accroche, palette) est imposée à des composants paramétriques. Ces composants forment des modules, les modules se posent dans des slots vides de coques ou de parcelles, et les assemblages ne sont que des données. Un lint garantit la ressemblance.
• Pistes explorées ensuite à la demande du propriétaire :
  • la même méthode pour les bâtiments d'un avant-poste minier sur astéroïde (OX) ;
  • une géométrie volontairement sur grille pour un rendu pixel art ultérieur (GX) ;
  • des idées de décomposition et d'étapes pour la factory, dont sont sortis le configurateur, la galerie de variantes et la chaîne en 9 étapes.
• Utilisateurs visés : les jeux du studio, Godot en priorité (export .tscn avec collisions et ancres), et des agents IA, puisque les specs sont lisibles, diffables et éditables par une IA.
• Contrainte d'hébergement : les pages tournent sur un petit serveur (2 vCPU, sans GPU) et dans le navigateur du visiteur. D'où la compression Draco, les textures JPEG, le filaire calculé côté client et l'occlusion des SVG.

4. Index des livrables en ligne

Base : https://kg.g.caute.re. Le lanceur général du studio est à la racine /.

Factory

Liens profonds utiles :

• Accueil : /factory/#<id>/<mode>, par exemple #command_hq/tex. Les ids sont habitat_s, command_hq et landing_pad ; les modes wire, solid et tex.
• Kit KX : /factory/kit/#<niveau>/<id>/<mode>. Les niveaux sont components, modules, hulls et assemblies. Exemple : #assemblies/asm_mixte/tex.
• Kit OX : /factory/outpost/#<niveau>/<id>/<mode>. Les niveaux sont components, buildings, plots et assemblies.
• Kit GX : /factory/grid/#<niveau>/<id> ou #methods.
• Configurateur : état complet dans le hash, par exemple #h=l&f=S1-bio,S2-cry,S4a-liq,S4b-liq-r&sn=L7KX-204&w=1&st=orange.
  • h est la coque (s, m ou l) et f la liste des slots sous la forme slot-module[-r] ;
  • sn est l'immatriculation, w l'usure de 0 à 3 et st la bande de flotte.
• Galerie : ?base=1&n=20 ; ?sheet&mode=tex donne la planche statique.

Contexte jeu (Deep City)

Ces pages servent de contexte seulement : elles ne font pas partie de la factory. Voir §25.

5. Chronologie (commits)

Dépôt git blueprint-factory (local, sans remote). Les heures sont celles de Paris.

Publication :

• Toutes ces étapes ont été mises en ligne par overlays successifs le 10/11 : kit, référentiel, configurateur, chaîne, avant-poste, grille, nav, puis le correctif Draco.
• L'opérateur a vérifié chaque sha256 et testé chaque page publique (HTTP 200).

6. Glossaire

7. Architecture du dépôt

blueprint-factory/
├── README.md                 # vue d'ensemble V1 + kit KX + régénération de ces pages
├── build.sh                  # V1 (3 bâtiments) : SVG → Blender → bake → viewer/assets → Godot
├── build-kit.sh              # Kit KX : SVG + mesh + lint + Blender + bake + GLB web Draco + assets
├── build-outpost.sh          # Kit OX (même structure, FAST=1 = sans Blender)
├── build-grid.sh             # Kit GX : voxels + sprites A + Blender (B, B′) + quantification + lint
├── specs/
│   ├── habitat_s.json, command_hq.json, landing_pad.json   # V1
│   ├── kit/   style-kit.json · stats.json · modules/ · hulls/ · assemblies/
│   ├── outpost/ style-outpost.json · buildings/ · plots/ · assemblies/
│   ├── grid/  grid-kit.json · modules/ · hulls/ · assemblies/
│   └── briefs/ax02-mixte.brief.txt
├── src/
│   ├── geom.py spec.py project.py blueprint.py factory.py sheets.py   # V1 (pur Python)
│   ├── blender_bridge.py bake_textures.py kit_web_glb.py               # Blender (partagés KX/OX)
│   ├── viewer_assets.py godot_check.gd                                # V1
│   ├── kit_core.py kit_parts.py kit_modules.py kit_hulls.py kit_sheet.py kit_project.py
│   │   kit_build.py kit_viewer_assets.py kit_config_data.py            # KX
│   ├── ox_core.py ox_parts.py ox_buildings.py ox_plots.py ox_sheet.py
│   │   ox_build.py ox_viewer_assets.py                                 # OX
│   ├── grid/  gx_core gx_parts gx_hulls gx_build gx_raster gx_blender gx_quantize gx_finalize
│   ├── chain/ brief_to_spec chain_blender chain_gameplay chain_tscn chain_qa chain_sheet chain_site
│   └── handoff/build_context.py     # génère viewer/context.json + viewer/index.html (rendu de handoff.md)
│       handoff/home.template.html  # gabarit de l'accueil (préambule IA, nav, visionneuse)
├── tools/   kit_lint.py ox_lint.py grid_lint.py kit_cinematic_renders.py
│            test-viewer.mjs test-kit.mjs test-kit-config.mjs test-kit-nav.mjs
│            test-chain.mjs test-outpost.mjs test-grid.mjs test-factory-home.mjs check-factory-text.py
├── viewer/  # = ce qui est publié sous /factory/
│   ├── index.html viewer.js viewer.css handoff.md llms.txt context.json
│   ├── vendor/three/ (r170, vendorisé, dont le décodeur Draco)
│   ├── assets/ (models, plans, kit, grid, referential, buildings.json)
│   ├── kit/ (index, kit.js, kx3d.js, kxrules.js, kgltf.js, configurator/, variants/)
│   ├── chain/  outpost/  grid/  referential/
├── docs/    planches, captures, README par kit (kit/, outpost/, grid/, chain/), handoff/
└── build/   sorties (une partie est suivie : manifestes, lint, modèles ; mesh/logs/web ignorés)

Outils externes : Blender 5.2 (variable BLENDER, binaire local), xvfb-run, Python 3 avec cairosvg, Pillow et numpy, Godot 4.7.2 (optionnel, pour le contrôle d'import), Node et Playwright avec Chrome et SwiftShader pour les tests.

8. Principes de conception transverses

1. La spec est la source de vérité.
   • Le SVG est une sortie inspectable, écrasée à chaque build : il ne faut pas l'éditer.
   • src/geom.py (pur Python) construit les maillages. Le SVG est une projection orthogonale de ces mêmes sommets, et Blender fait from_pydata avec eux aussi.
2. Triple vérification des cotes :
   • bbox de chaque pièce dans Blender contre le manifeste (tolérance 0,1 mm) ;
   • bbox du GLB réimporté (1 mm) ;
   • import Godot (tailles et triangles).
   • Le build échoue si une pièce passe sous le sol.
3. Dessin technique :
   • projection du 3e dièdre : dessus au-dessus de la face, profil droit à droite, même échelle, lignes de rappel ;
   • calques Inkscape et attribut data-part sur chaque pièce ;
   • échelle automatique de 1:20 à 1:200, silhouette humaine de 1,80 m, cartouche avec le sha256 de la spec.
4. Repère : mètres, Z en haut, origine au sol au centre du socle, façade vers −Y (V1). L'export glTF est en Y-up. Dans three.js, un point du kit devient position (x, z, −y), avec rotation.y = rotZ.
5. Ressemblance par construction : tous les objets d'un kit sont bâtis avec les mêmes sous-composants et les mêmes métriques, et un lint le vérifie. Les détails A et B du coin KX sont identiques d'un module à l'autre.
6. Les coques et parcelles ont des slots vides. Elles ne dessinent jamais de module ni de bâtiment, seulement les interfaces. Le lint vérifie qu'aucune pièce de module n'apparaît dans un blueprint de coque.
7. Un assemblage, ce sont des données, pas un nouveau blueprint : {slot, module, rot} (et links pour OX). Le build compose le maillage, et la visionneuse compose la même chose dans le navigateur à partir des GLB de la coque et des modules.
8. Héritage sans copie :
   • OX étend KX ("extends": "specs/kit/style-kit.json") : le code lit les valeurs héritées dans la source unique (src/kit_core.py, objet S).
   • GX dérive ses métriques de KX (g = U/2) et le lint vérifie le lien.
9. Déterminisme : le brief → spec suit des règles fixes, sans IA. Les variantes passent par generate(seed) (mulberry32) et l'usure par une seed. Mêmes entrées, mêmes sorties.
10. Sobriété web : Draco plus textures JPEG, filaire calculé dans le navigateur, faces cachées retirées des SVG, un seul décodeur Draco partagé.

9. V1 : bâtiments de colonie (spec → SVG → 3D)

• Écarts mesurés : ≤ 0,05 mm par pièce et ≤ 0,0002 mm sur le GLB réimporté. Godot 4.7.2 a importé les 6 GLB sur 6, avec 1 MeshInstance3D chacun.
• Textures cuites (<id>_tex.glb) : UV smart project, atlas de 2048 px, bake de la couleur, des normales et de l'émission, un seul matériau PBR.
• Primitives de spec : box, prism (+ chamfer/taper), cylinder/frustum, tube, dome, avec at, rot, repeat et polar. Composants : door, window, hublot, ladder, railing.
• Calques et matériaux :
  • layer vaut structure, openings, equipment ou markings ;
  • mat vaut panel, anthracite, accent, emissive, glass, metal, pad ou paint.
• Limites V1 :
  • le SVG est une sortie seulement ;
  • pas de booléens : les ouvertures sont en saillie, pas percées ;
  • pas de coupes en V1, alors que les kits suivants en ont ;
  • pas de LOD ni de collisions.

10. Kit KX : cargo spatial modulaire

Source : specs/kit/style-kit.json (version 1.0). Doc détaillée : docs/kit/README.md. Page : /factory/kit/.

10.1 Métriques imposées

• Grille : U = 0,25 m, u = U/5 = 0,05 m. Toute cote structurelle est un multiple de u, et c'est vérifié.
• Slots : C1 = 3,00 × 2,00 × 2,00 ; C2 = 6,25 = 2 × C1 + une nervure de 0,25. Le jeu est de 0,05 par face, donc l'enveloppe d'un module C1 fait 2,90 × 1,90 × 1,90.
• Interface KX-4 :
  • 8 coins KXC (cubes de 0,20, biseau XS, couleur iface #f2b705) ;
  • 4 verrous KXL au plancher du slot, à l'aplomb des coins (retrait de 0,10) ;
  • 4 bras KXB en tête : la mâchoire tombe sur les coins hauts ;
  • 1 ombilicale UMB au centre (mâle sous le module, femelle sur la coque, entraxe des brides de 100 mm). Un C2 en a 2, à ±1,625.
• Rivets : micro Ø0,03 au pas 0,15, marge ≥ 0,05 (modules et composants) ; macro Ø0,06 au pas 0,30 (coques). Les rangées sont centrées : n = floor((L − 2·edge)/pitch) + 1.
• Biseaux à 45° : XXS 0,01 · XS 0,025 · S 0,05 · M 0,10 · L 0,20 · XL 0,40. La taille vaut environ 1/10 de la plus petite section, arrondie à la taille inférieure.
• Bordé : plaques de 0,50 sur les modules et de 1,00 sur les coques, joints de 0,01. Les joints SVG et ceux de la texture cuite ont le même pas.
• Cadre : lisse de 0,10 (biseau XS), nervures de 0,10 × 0,20 au pas de 0,50.
• Marquage : bande code denrée de 0,15 de haut à z = 1,45, hachures de 0,10, ID de 0,20.
• Traits (en mm sur la feuille) : contour 0,35 · détail 0,20 · joint 0,10 · caché 0,13 · slot 0,30 (orange, pointillé) · coupe hachurée à 45°.
• Typographie : IBM Plex Sans Condensed et IBM Plex Mono.

10.2 Contenu

Composants (14) : src/kit_parts.py

Modules (5) : specs/kit/modules/*.json → src/kit_modules.py

Tous les modules partagent le même châssis : 8 KXC, 12 lisses BVL rivetées, un plancher, une UMB mâle dessous, une bande code et un ID. Seul le corps change.

Coques (3), toutes à slots vides : specs/kit/hulls/*.json → src/kit_hulls.py

La planche d'une coque montre le dessus, l'élévation et le profil, la coupe A-A (quille, poste, propulsion) et la coupe B-B à travers un slot.

Assemblages (4) : specs/kit/assemblies/*.json

Repère des assemblages : +x vers l'avant, +z vers le haut. y < 0 est tribord, y > 0 bâbord. S1 = avant tribord, S2 = avant bâbord, et ainsi de suite.

10.3 Lint KX (tools/kit_lint.py, 119 contrôles)

Résultat vérifié le 10/11 au soir : KIT_LINT OK 119/119. Le lint écrit dans build/kit/lint.json, un fichier suivi par git (voir §21).

10.4 Rendus

Dix rendus sont décrits dans docs/kit/renders/README.md : des originaux Blender Cycles en 1920×1080 et des passes cinématiques IA en 1280×720.

• La version Blender est conservée quand la version IA dévie trop : vue éclatée, coques à slots vides, pylônes ajoutés par l'IA.
• Une planche contact est fournie.

11. Configurateur et galerie de variantes KX

11.1 Configurateur (/factory/kit/configurator/)

• Interaction :
  • choisir une coque ;
  • déposer des modules par glisser-déposer, sur le plan 2D ou directement sur la 3D (raycast, surbrillance orange si le dépôt est accepté, rouge sinon) ;
  • ou cliquer sur un module pour l'armer, puis sur un slot ;
  • R tourne le module de 180°, Suppr le retire.
• Règles (viewer/kit/kxrules.js, partagé avec la galerie) :
  • taille : un C1 va dans un slot C1 ou un demi-slot a/b de C2 ; un C2 prend un slot C2 entier ;
  • orientation : rotZ ∈ {0, 180} ;
  • interface KX-4 : même calcul que le lint, à 1 mm près ;
  • slot vide : autorisé, mais signalé ;
  • budgets : charge utile et énergie du bus ombilical (specs/kit/stats.json).
• Résumé affiché : masse, coût, jauges de charge et d'énergie, capacité par denrée. Les 4 assemblages AX sont proposés en presets.
• Export / import au format AX : id, code, name, hull, description, fill[{slot, module, sub?, rot?}], plus livery et seed optionnels. Exemple : docs/kit/variants/cfg_exemple.json.
• Habillage, sans toucher à la géométrie :
  • immatriculation <lettre coque><3 alnum>-<3 chiffres> (alphabet sans I, O ni Q) ;
  • bande de flotte orange, jaune, cyan, rouge ou blanc ;
  • usure de 0 à 3 (neuf, service, usé, épave) : encrassement vers rock #4a3f36 et écaillage déterministe.
• Données : python3 src/kit_config_data.py génère viewer/assets/kit/config.json (stats, presets, ancres d'habillage, half_c2 = 1,625).

11.2 Galerie de variantes (/factory/kit/variants/)

generate(seed) est déterministe (mulberry32) et procède ainsi :

1. Tirage d'une coque pondérée (S 3, M 4, L 3).
2. Tirage d'une mission : Citernier, Vraquier, Frigorifique, Mixte ou Bétailler. Elle pondère les denrées.
3. Remplissage des slots :
   • chaque slot reste vide avec p = 0,12 ;
   • un C2 reçoit un BIO avec p = 0,8 en Bétailler et 0,15 sinon, et 2 × C1 dans les autres cas.
4. Rotation de 180° avec p = 0,4.
5. Habillage.
6. Correction des budgets : le module fautif est remplacé par une denrée plus légère, ou le slot est vidé.

Le résultat :

• 20 vignettes par défaut ;
• un clic ouvre la variante dans le configurateur, avec le même état ;
• planche statique : docs/kit/variants/kx-variants-sheet.png ; specs des seeds 1 à 20 : docs/kit/variants/variants-seeds-1-20.json.

Mémoire : la galerie rend 20 vignettes 3D. Depuis 2700872, viewer/kit/kgltf.js fournit un chargeur GLB partagé (un seul DRACOLoader, 1 worker wasm, cache, file d'attente). Il libère le renderer et le décodeur à la navigation. Un échec de chargement affiche l'erreur au lieu d'un « Chargement… » qui reste bloqué.

12. Chaîne factory en 9 étapes

Page : /factory/chain/, sur AX-02 « Cargo moyen mixte ». Les 9 étapes sont toutes réelles depuis 8c6bb9c. Doc : docs/chain/README.md. Planche : docs/chain/chain-9-steps.png.

Fin de chaîne :

• python3 src/chain/chain_sheet.py && python3 src/chain/chain_site.py produit la planche et la page ;
• node tools/test-chain.mjs <url>/factory/chain/ teste la page.

Les artefacts de chaque étape sont publics sous /factory/chain/artifacts/ : brief, spec, style-kit.json, hull_m.json, .tscn, fiche gameplay, rapport QA, cartes cuites…

Format du brief (extrait réel) :

code       : AX-02
nom        : Cargo moyen mixte
rôle       : cargo
gabarit    : moyen
slots      : 6 × C1
cargaison  : 2 cryo, 1 sec, 1 liquide, 2 minerai
placement  : avant → arrière, tribord puis bâbord
retourner  : liquide, minerai @ bâbord
ton        : lisible de loin, châssis KX commun, interface jaune visible, usure modérée
usure_seed : 4471

13. Kit OX : avant-poste minier sur astéroïde

Source : specs/outpost/style-outpost.json (version 0.1, extends KX). Doc : docs/outpost/README.md. Page : /factory/outpost/.

13.1 Héritage KX, sans copie

OX reprend de KX la grille U/u, les rivets, les biseaux, le bordé, le cadre, les marquages, les traits, la typo et la palette. Il hérite aussi de 10 composants KX : RVT, BVL, RIB, KXC, UMB, VNT, RNG, BCN, PIP et DOR.

• Les scripts Blender sont les mêmes, sans modification : blender_bridge.py, bake_textures.py, kit_web_glb.py.
• Le cadre des planches vient de kit_sheet.py.

13.2 Métriques propres à OX

• Maille de lotissement : Λ = 6,00 (24U), soit une emprise F1 de 4,00 plus un couloir de 2,00. Chaque centre de slot est un nœud de maille.
• Emprises : F1 = 4,00 × 4,00 ; F2 = 10,00 × 4,00. Le jeu est de 1U par face, donc l'enveloppe F1 fait 3,50 × 3,50. Un slot F2 accepte 1 × F2, ou 2 × F1 sur les sous-slots a (+3,00) et b (−3,00).
• Socle OX-4 :
  • des ancrages ANC (retrait de 0,10) qui reçoivent des vérins LEG (2U), placés sous les KXC jaunes ;
  • un plancher à +0,70 ;
  • une UMB au centre, avec un jeu UMB ↔ borne HUB vérifié entre 50 et 100 mm (74 mm mesurés).
• Ports PRT : axe à +1,75 (7U), collier de 1U qui affleure l'emprise, bride jaune de Ø1,80 à 16 boulons.
• Tubes TUB : Ø1,50, longueur n × 0,50. Entre deux voisins, un tube fait 2,00, avec un tréteau SUP au milieu.
• Terrain : terrasse à +1,20, origine de slot à +1,30, régolithe en cellules de 1,00 avec cratères et blocs.
• Familles : VIE #2f7fd0 · EXT #e0573a · TRT #c8962e · NRJ #8fd3ff · COM #b06ad8. Ce sont les teintes de denrée KX : aucune nouvelle couleur, aucun vert.

13.3 Contenu

• Composants OX (12) :

  Code	Rôle	Code	Rôle
  ANC	ancrage régolithe	SUP	tréteau
  LEG	vérin	MMS	blindage Whipple
  HUB	borne de service	RAD	radiateur
  SPD	semelle de slot	SOL	panneau solaire
  PRT	port de liaison	ANT	antenne
  TUB	tube de liaison	SAS	sas d'accès

• Bâtiments (7) :

  Code	Bâtiment	Classe	Famille	Ports	Triangles
  OX-HAB	Habitat pressurisé	F1	VIE	E W N	9 166
  OX-DRL	Foreuse	F1	EXT	W	8 686
  OX-REF	Raffinerie	F2	TRT	E W Sa Sb	16 316
  OX-SIL	Silo à minerai	F1	TRT	–	8 846
  OX-PWR	Centrale solaire	F1	NRJ	–	7 014
  OX-COM	Relais de communication	F1	COM	–	9 346
  OX-HGR	Hangar à engins	F2	VIE	E Sa Na	16 692

• Parcelles :
  • PX-S, Prospection : 3 × F1 (14 070 tris) ;
  • PX-M, Exploitation : 4 × F1 + 1 × F2 (23 820) ;
  • PX-L, Base : 5 × F1 + 3 × F2 (40 234).
• Assemblages :
  • OA-01, Avant-poste de prospection : PX-S, 3 bâtiments, 1 tube (40 476 tris) ;
  • OA-02, Exploitation minière : PX-M, 5 bâtiments, 3 tubes (80 140) ;
  • OA-03, Base minière complète : PX-L, les 7 types en 9 bâtiments (le slot S7 est un F2 garni de 2 × F1), 6 tubes (143 872, voir §19).

Un assemblage contient fill ({slot, sub, building, rot}) et links ([slotA, portA, slotB, portB]). Le build route chaque tube entre les brides. Il produit l'assemblage complet, plus un lnk_* qui ne contient que les tubes et les tréteaux.

13.4 Lint OX (tools/ox_lint.py, 150 contrôles)

Il vérifie :

• les classes de slot ;
• les vérins sur les ancrages et l'alignement UMB ↔ HUB ;
• l'emprise dans la terrasse ;
• les tubes : face à face, coaxiaux, de longueur n × 0,50, posés dans un couloir ;
• les ports libres, listés comme obturés ;
• l'absence de bâtiment sur une parcelle ;
• l'absence de vert.

Vérifié le 10/11 au soir : OX_LINT OK 150/150.

14. Kit GX : grille voxel pour pixel art

Source : specs/grid/grid-kit.json (version 0.1). Doc : docs/grid/README.md. Page : /factory/grid/.

14.1 Charte

• 1 voxel = g = U/2 = 0,125 m (G8 : 8 vox/m). G4 (1 vox = U) en est un LOD dérivé par sous-échantillonnage 2×2×2, jamais modélisé.
• Slots : C1 = 24 × 16 × 16 vox (= 3 × 2 × 2 m, comme KX) ; C2 = 50 (2 × C1 + 2). Le jeu est de 1 vox, et le module se pose sur z = 1. Enveloppes : C1 = 22 × 14 × 14, C2 = 48 × 14 × 14.
• Interface GX-4 :
  • 8 coins de 2 × 2 × 2 en jaune #f2b705, avec un trou de 1 px ;
  • 4 verrous de 2 × 2 dans la couche 0 ;
  • des mâchoires en z = 15 ;
  • une ombilicale de 4 × 4.
• Détails au pixel :
  • rivet = 1 pixel : un drapeau de surface, pas un voxel ;
  • chanfrein en marches de 1 voxel à 45° : 0 marche sous 6 vox, 1 sous 16, 2 sous 32, 3 au-delà ;
  • joints tous les 4 vox (modules) ou 8 vox (coques) ;
  • bande code en z = 11.
• Palette indexée de 53 couleurs, sans vert :
  • 0 = transparent ;
  • 4 couleurs fixes : encre #14161c, ombre #262a33, slot #ff9a3c et slot caché #8a5426 ;
  • 16 matériaux × 3 tons (hi, mid, lo).
  • Exports : gx_palette.gpl, .hex et .png.
• Éclairage fixe en repère écran : dessus = hi, face gauche = mid, face droite = lo. Un contour de 1 px en encre entoure la silhouette, et une rupture de profondeur de plus de 2 vox donne 1 px d'ombre.
• Projection : iso 2:1 entière, P = [[−2,2,0],[1,1,−2]]. La vue 3/4 de dessus utilise P = [[−2,0,0],[0,2,−2]].

14.2 Contenu

• Composants (15) : CRN, LCK, ARM, UMB, RVT, BVL, PNL, RIB, VNT, BCN, PIP, DOR, WIN, HAZ, IFP (codes GX-*).
• Modules (5) : GX-LIQ, GX-BOX, GX-ORE et GX-CRY en C1 (22 × 14 × 14), GX-BIO en C2 (48 × 14 × 14).
• Coques (3), à slots vides : GH-S (107 × 20 × 42 vox), GH-M (147 × 38 × 45) et GH-L (257 × 20 × 44).
• Assemblages (4) : GA-01 à GA-04, les mêmes que AX-01 à AX-04, composés dans le navigateur.

14.3 Méthodes comparées et verdict

Verdict, qui sert de décision :

• la géométrie naît sur la grille, et le rendu est un raster entier voxel par voxel en Python (méthode A) ;
• Blender en ortho (B) n'est gardé que pour les 8 directions ou une caméra libre, et demande des retouches ;
• G4 sert pour les vues lointaines et les icônes ;
• C est un outil de cadrage ;
• on ne part pas d'un modèle KX lisse.

14.4 Lint et limites

• Lint GX (tools/grid_lint.py, 107 contrôles) :
  • lien avec KX ;
  • palette : 64 couleurs au plus, pas de vert, bases issues de KX ;
  • chanfreins, rivets, modules, coques et assemblages : 0 collision, alignement coins ↔ verrous ↔ mâchoires ;
  • sprites indexés dans la palette exacte.
  • Vérifié le 10/11 : 107/107.
• Limites :
  • les sprites G8 des coques sont grands (jusqu'à 560 × 370 px pour GH-L) ;
  • l'éclairage est fixe à l'écran ;
  • les 8 directions de la méthode B ne sont pas retouchées ;
  • la carte de normales contient des teintes cyan-vert. C'est une donnée technique, exclue du contrôle « sans vert » de la palette art.

15. Référentiel IA

Page : /factory/referential/, une grille 3 × 2.

• Principe : pour chacun des 3 bâtiments V1, une image est générée par un modèle d'image à partir du plan technique, et une autre à partir de la prévisualisation 3D texturée.
• But : juger à quel point le modèle d'image respecte le référentiel (proportions, pièces nommées, matériaux).
• Fichiers : sources dans viewer/assets/referential/sources/, rendus dans viewer/assets/referential/.
• Constat : les rendus Blender restent la référence quand l'IA dévie (voir aussi les rendus KX, §10.4).

16. Formats de fichiers et schémas

Toutes les specs sont du JSON UTF-8. Les clés _doc et _rule sont des commentaires lus par les humains et les agents.

16.1 Spec bâtiment V1 (specs/<id>.json)

{ "id": "habitat_s", "name": "Module habitat S", "code": "HAB-S", "tiles": [2, 2], "description": "…",
  "parts": [ { "id": "hull", "label": "Coque pressurisée Ø2.80", "layer": "structure", "mat": "panel",
               "prims": [ { "type": "cylinder", "r": 1.40, "h": 2.60, "at": [0, 0.30, 0.45] } ] } ],
  "dims": [ … ], "levels": [ … ], "decals": [ … ] }

• Les primitives acceptent repeat et polar ({n, r, start, center, skip}).
• Une entrée de dims donne view, parts, axis et side.
• Le code de référence est src/spec.py.

16.2 Charte KX (specs/kit/style-kit.json)

Clés de premier niveau :

• grid {U, u} ;
• slots {C1, C2, clearance, rib_gap} ;
• interface {name: "KX-4", casting, twistlock_inset, umbilical, plate_t} ;
• rivet {micro, macro} ;
• bevel {angle_deg, sizes, ratio} ;
• plates, frame, markings ;
• palette {…, codes{LIQ,BOX,ORE,CRYO,BIO}} ;
• strokes, type, scale_classes ;
• budget.triangles {component, module, hull, assembly} ;
• gameplay {units, cargo{<denrée>: {density}}, modules{<id>: {usable, tare_t, cost_cr}}, hulls{<id>: {dry_t, cost_cr}}}.

16.3 Module KX (specs/kit/modules/<id>.json)

{"id": "mod_liq", "code": "KX-LIQ", "name": "Module citerne", "cls": "C1", "body": "tank", "cargo": "LIQ",
 "goods": "Liquides : eau, carburant, solvants", "description": "…"}

• cls vaut C1 ou C2.
• body vaut tank, box, hopper, cryo ou vivarium.

16.4 Coque KX (specs/kit/hulls/<id>.json)

{"id": "hull_m", "code": "HX-M", "name": "Coque cargo moyen", "description": "…",
 "rows": [["C1", "C1"], ["C1", "C1"], ["C1", "C1"]], "fore_len": 5.0, "aft_len": 3.4, "keel_h": 1.60, "engines": 3, "skid_h": 1.00}

rows liste les rangs de l'avant vers l'arrière. Chaque rang contient une ou deux colonnes (tribord puis bâbord). Les slots sont numérotés S1, S2… dans cet ordre.

16.5 Assemblage KX (specs/kit/assemblies/<id>.json), qui est aussi le format d'export du configurateur

{"id": "asm_mixte", "code": "AX-02", "name": "Cargo moyen mixte", "hull": "hull_m", "description": "…",
 "fill": [{"slot": "S1", "module": "mod_cryo"}, {"slot": "S4", "module": "mod_liq", "rot": 180}]}

• sub vaut a ou b pour un C1 posé dans un C2.
• rot vaut 0 ou 180 (0 par défaut).
• L'export du configurateur ajoute livery et seed, qui sont optionnels.

16.6 Stats gameplay KX (specs/kit/stats.json)

• modules.<id> : {tare_t, load_t, cap, unit, power_kw, label}.
• hulls.<id> : {dry_t, payload_t, power_kw, crew}.
• livery : bandes de flotte, couleur d'encrassement, niveaux d'usure et format d'immatriculation.
• generator : {hull_weights, p_empty, p_rot180, p_bio, missions}.
• _rules : définitions de la masse, de la charge utile, de l'énergie et des slots.

16.7 Charte OX (specs/outpost/style-outpost.json)

• Héritage : extends, inherits[].
• Métriques : lattice {pitch, corridor}, footprints {F1, F2, clearance}, socle {name: "OX-4", anchor_inset, pile, leg_h, deck_z, hub_top, umb_gap, …}, port {z, tube_d, flange_d, collar, bolts, segment}.
• Environnement et équipements : terrain, shield, radiator, solar.
• Couleurs : families{VIE,EXT,TRT,NRJ,COM}, palette_add.

16.8 Bâtiment, parcelle et assemblage OX

{"id": "bld_hab", "code": "OX-HAB", "name": "Habitat pressurisé", "cls": "F1", "body": "habitat", "family": "VIE", "ports": ["E", "W", "N"], "role": "…", "description": "…"}
{"id": "plot_m", "code": "PX-M", "name": "Parcelle d'exploitation", "seed": 23, "craters": 5, "rocks": 30,
 "slots": [{"id": "S1", "cls": "F1", "node": [0, 0]}, {"id": "S4", "cls": "F2", "node": [0, 1]}]}
{"id": "oa_exploitation", "code": "OA-02", "plot": "plot_m",
 "fill": [{"slot": "S1", "building": "bld_drl", "rot": 180}], "links": [["S1", "W", "S2", "W"], ["S2", "N", "S4", "Sa"]]}

16.9 Charte et objets GX

• Charte (specs/grid/grid-kit.json) : grid {g, per_U, lod}, slots (en voxels), interface, rivet, bevel {steps}, plates, frame, markings, render {tones, light, outline, iso.P, oblique.P, aa:false}, palette {fixed, materials[16], ramp}.
• Objets : specs/grid/modules/gmod_*.json, hulls/ghull_*.json (rows, fore, aft, keel_h, skid_h en voxels) et assemblies/gasm_*.json (même fill que KX).
• Sorties :
  • viewer/assets/grid/grid.json : catalogue, palette, lint ;
  • vox/<id>.json : grille dense en base64, ordre x, y, z ;
  • sprites/<id>/g8_d0..3.png, g4_d*.png, g8_oblique.png, plus les normales et la profondeur ;
  • sprites_b/<id>/b_d0..7.png ;
  • sheets/<id>.png et .json (atlas).

16.10 Sorties de build communes

17. Commandes : build, lint, tests, export

À lancer depuis la racine du dépôt blueprint-factory/. BLENDER vaut par défaut le binaire Blender 5.2 local.

# V1
./build.sh                         # 3 bâtiments : SVG, Blender, bake, assets visionneuse, Godot (≈ 2 min 25)
./build.sh specs/habitat_s.json    # un seul bâtiment
python3 src/factory.py specs/*.json   # SVG + manifestes seuls (< 1 s)

# Kits
./build-kit.sh       ; FAST=1 ./build-kit.sh       # KX (FAST = sans Blender)
./build-outpost.sh   ; FAST=1 ./build-outpost.sh   # OX
./build-grid.sh      ; FAST=1 ./build-grid.sh      # GX (≈ 25–50 s complet)
python3 src/kit_config_data.py                     # stats, presets, ancres → viewer/assets/kit/config.json

# Lints (rapides, sans Blender)
python3 tools/kit_lint.py    # → build/kit/lint.json      (attendu : KIT_LINT OK 119/119)
python3 tools/ox_lint.py     # → build/outpost/lint.json  (attendu : OX_LINT OK 150/150)
python3 tools/grid_lint.py   # → build/grid/lint.json     (attendu : [gx-lint] 107/107)
python3 src/chain/chain_qa.py   # QA de la chaîne AX-02 (attendu : CHAIN_QA OK)

# Ce handoff
python3 src/handoff/build_context.py   # régénère viewer/context.json et viewer/index.html (handoff.md rendu en HTML)
python3 src/handoff/build_context.py --check   # échoue si context.json ou index.html n'est pas à jour
PYTHONPATH=/tmp/pylib python3 tools/check-factory-text.py <url-factory>   # lecture « comme un LLM » via html2text : 27/27 sections

17.1 Tests navigateur (Playwright headless, Chrome et SwiftShader)

On sert viewer/ (ou un site qui contient factory/) en HTTP local, puis on lance :

python3 -m http.server 8782 -d viewer &
node tools/test-viewer.mjs      http://127.0.0.1:8782/ docs        # accueil V1 : rotation, modes, captures
node tools/test-kit.mjs         http://127.0.0.1:8782/ docs/kit    # 4 niveaux KX, modes, coupe, éclaté
node tools/test-kit-config.mjs  http://127.0.0.1:8782/ docs/kit    # configurateur + galerie (28 contrôles)
node tools/test-kit-nav.mjs     http://127.0.0.1:8782/             # stress mémoire galerie → configurateur
node tools/test-outpost.mjs     http://127.0.0.1:8782/ docs/outpost
node tools/test-grid.mjs        http://127.0.0.1:8782/ docs/grid
node tools/test-chain.mjs       http://127.0.0.1:8782/chain/       # 10 images, liens d'artefacts en 200
node tools/test-factory-home.mjs http://127.0.0.1:8782/            # accueil v2 : source statique (27 h2), sans JS, ancres, liens, fichiers

• Les tests échouent sur toute erreur ou tout avertissement console, toute requête en échec et toute réponse HTTP ≥ 400.
• Ils utilisent playwright-core (chemin pnpm local) et /usr/bin/google-chrome avec --use-angle=swiftshader.

17.2 Export Blender, GLB et Draco

1. Contrôle et export : src/blender_bridge.py (Blender headless sous xvfb-run) vérifie chaque pièce contre le manifeste, puis exporte <id>.glb, .fbx, _wire.glb (glTF LINES) et les rendus filaire, plein et texturé.
2. Textures : src/bake_textures.py cuit les textures PBR (atlas de 512 pour les composants, 1024 pour les modules et bâtiments, 2048 pour les coques et parcelles) dans <id>_tex.glb.
3. Web : src/kit_web_glb.py produit les GLB web avec compression Draco, et des textures JPEG pour les _tex (option --jpeg).
4. Visionneuses : elles décodent avec le DRACOLoader de three r170 vendorisé, via le chargeur partagé viewer/kit/kgltf.js.
5. Godot : src/godot_check.gd (V1) et build/chain/godot/check.gd (chaîne) contrôlent l'import dans Godot 4.7.2 headless.

18. Palette : jamais de vert

• Règle : pas de vert, ni dans l'art, ni dans l'UI, ni dans les SVG, ni dans les matériaux. Est interdite toute couleur de teinte 70° à 170° dont la saturation est ≥ 0,25 et la valeur ≥ 0,15 (HSV).
• Contrôle : kit_lint, ox_lint et grid_lint scannent les SVG, le CSS et le JS des visionneuses, les chartes, stats.json et les matériaux Blender. chain_qa compte les pixels verts des rendus (0 sur 198 400).
• Palette de base KX :

• Codes denrée : LIQ #2f7fd0 · BOX #e0573a · ORE #c8962e · CRYO #8fd3ff · BIO #b06ad8.
• Bandes de flotte : orange #ffad5c, jaune #f2b705, cyan #62d6ff, rouge #ff6f61 et blanc #eef7ff.
• Seule exception tolérée : les cartes de normales techniques (encodage standard), jamais affichées comme art.
• Éclairage des rendus 3D : neutre ou froid (soleil blanc froid, fill bleuté). C'était déjà l'un des correctifs de la V1 par rapport au kit colonie.

19. Budgets triangles et poids web

• Plafonds (style-kit.json → budget.triangles) : composant ≤ 2 500 · module ≤ 20 000 · coque ≤ 45 000 · assemblage ≤ 100 000. Ils sont vérifiés par src/chain/chain_qa.py sur les 26 objets KX. AX-04, avec 96 928 tris, est le plus proche du plafond ; AX-02 (76 614) en est à 77 %.
• Fourchettes KX constatées :
  • composants : 28 à 2 076 ;
  • modules : 5 164 à 16 880 ;
  • coques : 16 924 à 41 076 ;
  • assemblages : 33 554 à 96 928.
• OX n'a pas de budget déclaré. OA-03 compte 143 872 tris, ce qui dépasserait le plafond d'assemblage KX s'il s'appliquait (voir §21).
• Poids web KX :
  • 44 GLB web (Draco + JPEG), environ 6,2 Mo en tout ;
  • la coque texturée la plus lourde fait environ 1,1 Mo, un module plein 30 à 77 Kio, un composant 1 à 14 Kio.
• Filaire : calculé dans le navigateur (EdgesGeometry à 20°, même règle que les arêtes vives du SVG). Aucun GLB filaire n'est en ligne.
• SVG : le retrait des faces totalement cachées fait passer les planches KX de 34 à 12 Mo.

20. Données gameplay

Définitions :

• Configurateur (stats.json) : masse = coque à vide + Σ(tare + charge pleine). La charge utile Σ(tare + charge) doit rester ≤ payload_t, et l'énergie Σ power_kw ≤ power_kw de la coque.
• Chaîne (style-kit.json → gameplay) : volume utile = enveloppe × usable, et charge = volume utile × densité.
  • Densités en t/m³ : LIQ 1,00 · BOX 0,60 · ORE 2,33 · CRYO 0,69 · BIO 0,32.
  • Les densités ont été choisies pour retrouver les charges du configurateur, avec un écart maximal de 0,37 % contrôlé en QA.

Modules :

Coques :

Fiche AX-02 (chaîne, étape 9) : capacité 43,1 m³ · charge 51,0 t · masse 102,5 t · coût 18 200 cr.

Assemblages selon la règle du configurateur (recalculés depuis stats.json pour ce document) :

AX-02 pèse 102,6 t selon le configurateur et 102,5 t selon la chaîne : l'écart vient des deux modes de calcul (forfait d'un côté, volume × densité de l'autre). Il est voulu et contrôlé.

Les budgets sont de vraies contraintes de jeu : 6 × ORE sur HX-M (102,6 t de charge) est refusé, tout comme 2 × CRY sur HX-S (12 kW).

21. Problèmes connus

22. Journal des décisions

23. Questions ouvertes et prochaines étapes

Questions ouvertes (à trancher avec le propriétaire) :

1. Quel jeu consomme les kits ? Deep City (2D vue de dessus), un colony builder, un jeu spatial ? [non décidé]
2. Faut-il retenir la 3D ou le pixel art ? GX reste une exploration, et le verdict A ne porte que sur la méthode de rendu.
3. Quel budget de triangles pour OX (OA-03 à 143 872) ?
4. Faut-il une édition inverse (SVG annoté → patch de spec) ou un éditeur web de spec avec aperçu SVG en direct ?
5. Faut-il étendre la chaîne en 9 étapes à tous les AX, aux OA, et à GX ?
6. Comment l'agent entrant accède-t-il au dépôt (remote) ?

Prochaines étapes suggérées, triées du moins cher au plus cher :

1. Corriger le badge LINT du kit (régénérer kit.json, overlay d'un fichier).
2. Rendre l'usure lisible en vue d'ensemble.
3. Rendre add-factory.sh additif, sans rm -rf ni Caddyfile, ou le marquer « dev seulement ».
4. Versionner les URL des JS des visionneuses pour éviter les problèmes de cache.
5. Ajouter un budget OX et le contrôler dans ox_lint.
6. Généraliser l'export Godot .tscn (collisions, ancres Marker3D) aux 4 AX et 3 OA.
7. GX : retoucher les 8 directions B, étendre GX à OX (bâtiments voxel), viser des sprites plus petits en G4.
8. Ajouter des booléens (ouvertures percées), des LOD, et des UV mieux dépliées que le smart project.
9. Migrer le reste du kit colonie (23 bâtiments poc-blender) spec par spec.

24. Conventions de travail pour un agent

• Langue : tout en français (UI, docs, commits), sur un ton direct et technique.
• Commits :
  • préfixe du périmètre, puis un résumé dense avec les chiffres vérifiés (lint, tests, compteurs) ;
  • corps du message : la cause et le correctif.
  • Exemples réels :
    • « Kit KX : configurateur (…) ; stats.json, lint 119/119, test 28/28 » ;
    • « Kit KX/OX : libérer Draco et le contexte WebGL avant de quitter la page ».
  • Un jalon par commit. Ne pas committer de secrets ni de chemins de clés.
• Avant de modifier une page publiée : repartir du fichier en ligne, qui peut différer du dépôt (voir §21 n°10).
• Livraison par overlay :
  1. Construire une archive launcher-factory-<sujet>-overlay.tar.gz dont tous les chemins commencent par launcher/site/… (par exemple launcher/site/factory/kit/index.html).
  2. N'y mettre que des fichiers ajoutés ou remplacés : pas de suppression, pas de dossier entier qui écraserait un voisin, pas de Caddyfile, pas de games.json sans accord.
  3. Indiquer la taille en octets, le sha256 et la liste exacte des fichiers.
  4. Un opérateur vérifie le sha256, sauvegarde les fichiers remplacés, extrait l'archive en se limitant à site/factory et teste les URL publiques.
  5. Après la fusion, revérifier soi-même chaque URL (HTTP 200, type MIME) si le réseau le permet.
• Vérifier chaque affirmation :
  • lancer le lint du kit touché, le test Playwright de la page touchée et chain_qa si les chiffres gameplay ou les budgets bougent ;
  • un chiffre cité doit sortir d'un fichier ou d'une commande.
• Documenter chaque étape : README du kit, planche ou capture dans docs/, et mise à jour de ce handoff : éditer viewer/handoff.md, puis lancer python3 src/handoff/build_context.py, qui réécrit context.json et index.html.
• Nommage :
  • ids en minuscules : mod_*, hull_*, asm_*, cmp_*, bld_*, plot_*, oa_*, oxc_*, gmod_*, ghull_*, gasm_*, gx_* ;
  • codes en majuscules : KX-LIQ, HX-M, AX-02, OX-HAB, PX-M, OA-02, GX-LIQ, GH-M, GA-02.
• Parallélisme : plusieurs agents ont déjà travaillé en même temps dans ce dépôt. Ne touchez pas aux fichiers partagés (factory/index.html, kit.json) sans les relire juste avant, et fusionnez à la main.

25. Contexte : Deep City

Ce projet est distinct de la factory et n'est donné ici que comme contexte. Deep City est un hybride action-RPG en vue de dessus et jeu de gestion : un donjon (ennemis, coffres, loot) et une ville (étal de marché, vente). La version de référence est en Godot 4.7.2 (GL Compatibility, export web sans threads), avec du pixel art procédural sans vert.

• Des portages du MVP existent en Love2D, Raylib, Phaser et Canvas TypeScript.
• Tests du jeu : playtests headless Godot (DC_TEST, DC_TEST=floors, DC_TEST=v3) et captures (DC_SHOTS).
• Lien avec la factory : aucune intégration n'est faite à ce jour. Les kits visent l'export Godot (.tscn), et le pixel art GX pourrait servir un jeu 2D comme Deep City [hypothèse, non décidé].

26. Données publiques lisibles par machine

Tout ceci est servi sous https://kg.g.caute.re/factory/ et peut remplacer l'accès au dépôt pour se faire une idée :

27. Ce qui n'a pas pu être confirmé

• Le contenu exact de la liste d'« idées de décomposition et d'étapes » donnée au propriétaire le 10/11 n'est pas reproduit ici. On sait seulement que le configurateur, la galerie et la chaîne en 9 étapes en sont issus.
• Avant de rédiger, l'accueil en ligne a été relu en HTTPS : il est identique à la base utilisée. Toutes les URL publiques citées ici ont répondu 200 le 10/11 au soir, sauf handoff.md, llms.txt et context.json, qui attendaient leur overlay. Le contenu des autres sous-pages n'a pas été comparé octet par octet avec le dépôt. Les tests locaux tournent sur une reconstitution, c'est-à-dire les overlays appliqués dans l'ordre.
• Le correctif du badge (§21 n°1) n'a pas été appliqué ni testé. Seule la cause a été vérifiée dans le code.
• Le défaut d'usure peu visible à distance (§21 n°2) a été constaté pendant les travaux, mais n'a pas été mesuré.