chore: initial repository structure

Monorepo skeleton (core, 3d, studio, schema, docs, artwork), MPL 2.0 licence,
and the SEQUA Engine v2 reference document.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

.editorconfig

@@ -0,0 +1,18 @@
+root = true
+
+[*]
+charset = utf-8
+end_of_line = lf
+insert_final_newline = true
+trim_trailing_whitespace = true
+indent_style = space
+indent_size = 2
+
+[*.{cpp,hpp,h,cc,cmake}]
+indent_size = 4
+
+[CMakeLists.txt]
+indent_size = 4
+
+[*.md]
+trim_trailing_whitespace = false

.gitattributes

@@ -0,0 +1,5 @@
+* text=auto eol=lf
+*.png binary
+*.jpg binary
+*.bat text eol=crlf
+*.ps1 text eol=crlf

.gitignore

@@ -0,0 +1,32 @@
+# Build
+build/
+out/
+cmake-build-*/
+CMakeUserPresets.json
+vcpkg_installed/
+
+# Node / Studio
+node_modules/
+studio/dist/
+
+# IDE / OS
+.vs/
+.vscode/
+.idea/
+.DS_Store
+Thumbs.db
+
+# Python (outils hors produit)
+__pycache__/
+.venv/
+
+# Modèles : jamais dans le dépôt (voir docs, §10.2)
+*.onnx
+*.safetensors
+*.ckpt
+*.pt
+*.gguf
+
+# Local
+.claude/
+*.log

CONTRIBUTING.md

@@ -0,0 +1,7 @@
+# Contribuer à SEQUA
+
+Le projet est porté par ses auteurs et n'accepte pas encore de contributions externes.
+
+La politique de contributions (certificat d'origine DCO ou accord de contributeurs) sera fixée avant d'en accepter. Voir `docs/SEQUA_Engine_resume_complet_v2.md`, §10.2 et §17.
+
+Conventions provisoires : branche `main` protégée, commits conventionnels (`feat:`, `fix:`, `docs:`, `chore:`), en-têtes SPDX `MPL-2.0` dans les fichiers source.

LICENSE

@@ -0,0 +1,373 @@
+Mozilla Public License Version 2.0
+==================================
+
+1. Definitions
+--------------
+
+1.1. "Contributor"
+    means each individual or legal entity that creates, contributes to
+    the creation of, or owns Covered Software.
+
+1.2. "Contributor Version"
+    means the combination of the Contributions of others (if any) used
+    by a Contributor and that particular Contributor's Contribution.
+
+1.3. "Contribution"
+    means Covered Software of a particular Contributor.
+
+1.4. "Covered Software"
+    means Source Code Form to which the initial Contributor has attached
+    the notice in Exhibit A, the Executable Form of such Source Code
+    Form, and Modifications of such Source Code Form, in each case
+    including portions thereof.
+
+1.5. "Incompatible With Secondary Licenses"
+    means
+
+    (a) that the initial Contributor has attached the notice described
+        in Exhibit B to the Covered Software; or
+
+    (b) that the Covered Software was made available under the terms of
+        version 1.1 or earlier of the License, but not also under the
+        terms of a Secondary License.
+
+1.6. "Executable Form"
+    means any form of the work other than Source Code Form.
+
+1.7. "Larger Work"
+    means a work that combines Covered Software with other material, in
+    a separate file or files, that is not Covered Software.
+
+1.8. "License"
+    means this document.
+
+1.9. "Licensable"
+    means having the right to grant, to the maximum extent possible,
+    whether at the time of the initial grant or subsequently, any and
+    all of the rights conveyed by this License.
+
+1.10. "Modifications"
+    means any of the following:
+
+    (a) any file in Source Code Form that results from an addition to,
+        deletion from, or modification of the contents of Covered
+        Software; or
+
+    (b) any new file in Source Code Form that contains any Covered
+        Software.
+
+1.11. "Patent Claims" of a Contributor
+    means any patent claim(s), including without limitation, method,
+    process, and apparatus claims, in any patent Licensable by such
+    Contributor that would be infringed, but for the grant of the
+    License, by the making, using, selling, offering for sale, having
+    made, import, or transfer of either its Contributions or its
+    Contributor Version.
+
+1.12. "Secondary License"
+    means either the GNU General Public License, Version 2.0, the GNU
+    Lesser General Public License, Version 2.1, the GNU Affero General
+    Public License, Version 3.0, or any later versions of those
+    licenses.
+
+1.13. "Source Code Form"
+    means the form of the work preferred for making modifications.
+
+1.14. "You" (or "Your")
+    means an individual or a legal entity exercising rights under this
+    License. For legal entities, "You" includes any entity that
+    controls, is controlled by, or is under common control with You. For
+    purposes of this definition, "control" means (a) the power, direct
+    or indirect, to cause the direction or management of such entity,
+    whether by contract or otherwise, or (b) ownership of more than
+    fifty percent (50%) of the outstanding shares or beneficial
+    ownership of such entity.
+
+2. License Grants and Conditions
+--------------------------------
+
+2.1. Grants
+
+Each Contributor hereby grants You a world-wide, royalty-free,
+non-exclusive license:
+
+(a) under intellectual property rights (other than patent or trademark)
+    Licensable by such Contributor to use, reproduce, make available,
+    modify, display, perform, distribute, and otherwise exploit its
+    Contributions, either on an unmodified basis, with Modifications, or
+    as part of a Larger Work; and
+
+(b) under Patent Claims of such Contributor to make, use, sell, offer
+    for sale, have made, import, and otherwise transfer either its
+    Contributions or its Contributor Version.
+
+2.2. Effective Date
+
+The licenses granted in Section 2.1 with respect to any Contribution
+become effective for each Contribution on the date the Contributor first
+distributes such Contribution.
+
+2.3. Limitations on Grant Scope
+
+The licenses granted in this Section 2 are the only rights granted under
+this License. No additional rights or licenses will be implied from the
+distribution or licensing of Covered Software under this License.
+Notwithstanding Section 2.1(b) above, no patent license is granted by a
+Contributor:
+
+(a) for any code that a Contributor has removed from Covered Software;
+    or
+
+(b) for infringements caused by: (i) Your and any other third party's
+    modifications of Covered Software, or (ii) the combination of its
+    Contributions with other software (except as part of its Contributor
+    Version); or
+
+(c) under Patent Claims infringed by Covered Software in the absence of
+    its Contributions.
+
+This License does not grant any rights in the trademarks, service marks,
+or logos of any Contributor (except as may be necessary to comply with
+the notice requirements in Section 3.4).
+
+2.4. Subsequent Licenses
+
+No Contributor makes additional grants as a result of Your choice to
+distribute the Covered Software under a subsequent version of this
+License (see Section 10.2) or under the terms of a Secondary License (if
+permitted under the terms of Section 3.3).
+
+2.5. Representation
+
+Each Contributor represents that the Contributor believes its
+Contributions are its original creation(s) or it has sufficient rights
+to grant the rights to its Contributions conveyed by this License.
+
+2.6. Fair Use
+
+This License is not intended to limit any rights You have under
+applicable copyright doctrines of fair use, fair dealing, or other
+equivalents.
+
+2.7. Conditions
+
+Sections 3.1, 3.2, 3.3, and 3.4 are conditions of the licenses granted
+in Section 2.1.
+
+3. Responsibilities
+-------------------
+
+3.1. Distribution of Source Form
+
+All distribution of Covered Software in Source Code Form, including any
+Modifications that You create or to which You contribute, must be under
+the terms of this License. You must inform recipients that the Source
+Code Form of the Covered Software is governed by the terms of this
+License, and how they can obtain a copy of this License. You may not
+attempt to alter or restrict the recipients' rights in the Source Code
+Form.
+
+3.2. Distribution of Executable Form
+
+If You distribute Covered Software in Executable Form then:
+
+(a) such Covered Software must also be made available in Source Code
+    Form, as described in Section 3.1, and You must inform recipients of
+    the Executable Form how they can obtain a copy of such Source Code
+    Form by reasonable means in a timely manner, at a charge no more
+    than the cost of distribution to the recipient; and
+
+(b) You may distribute such Executable Form under the terms of this
+    License, or sublicense it under different terms, provided that the
+    license for the Executable Form does not attempt to limit or alter
+    the recipients' rights in the Source Code Form under this License.
+
+3.3. Distribution of a Larger Work
+
+You may create and distribute a Larger Work under terms of Your choice,
+provided that You also comply with the requirements of this License for
+the Covered Software. If the Larger Work is a combination of Covered
+Software with a work governed by one or more Secondary Licenses, and the
+Covered Software is not Incompatible With Secondary Licenses, this
+License permits You to additionally distribute such Covered Software
+under the terms of such Secondary License(s), so that the recipient of
+the Larger Work may, at their option, further distribute the Covered
+Software under the terms of either this License or such Secondary
+License(s).
+
+3.4. Notices
+
+You may not remove or alter the substance of any license notices
+(including copyright notices, patent notices, disclaimers of warranty,
+or limitations of liability) contained within the Source Code Form of
+the Covered Software, except that You may alter any license notices to
+the extent required to remedy known factual inaccuracies.
+
+3.5. Application of Additional Terms
+
+You may choose to offer, and to charge a fee for, warranty, support,
+indemnity or liability obligations to one or more recipients of Covered
+Software. However, You may do so only on Your own behalf, and not on
+behalf of any Contributor. You must make it absolutely clear that any
+such warranty, support, indemnity, or liability obligation is offered by
+You alone, and You hereby agree to indemnify every Contributor for any
+liability incurred by such Contributor as a result of warranty, support,
+indemnity or liability terms You offer. You may include additional
+disclaimers of warranty and limitations of liability specific to any
+jurisdiction.
+
+4. Inability to Comply Due to Statute or Regulation
+---------------------------------------------------
+
+If it is impossible for You to comply with any of the terms of this
+License with respect to some or all of the Covered Software due to
+statute, judicial order, or regulation then You must: (a) comply with
+the terms of this License to the maximum extent possible; and (b)
+describe the limitations and the code they affect. Such description must
+be placed in a text file included with all distributions of the Covered
+Software under this License. Except to the extent prohibited by statute
+or regulation, such description must be sufficiently detailed for a
+recipient of ordinary skill to be able to understand it.
+
+5. Termination
+--------------
+
+5.1. The rights granted under this License will terminate automatically
+if You fail to comply with any of its terms. However, if You become
+compliant, then the rights granted under this License from a particular
+Contributor are reinstated (a) provisionally, unless and until such
+Contributor explicitly and finally terminates Your grants, and (b) on an
+ongoing basis, if such Contributor fails to notify You of the
+non-compliance by some reasonable means prior to 60 days after You have
+come back into compliance. Moreover, Your grants from a particular
+Contributor are reinstated on an ongoing basis if such Contributor
+notifies You of the non-compliance by some reasonable means, this is the
+first time You have received notice of non-compliance with this License
+from such Contributor, and You become compliant prior to 30 days after
+Your receipt of the notice.
+
+5.2. If You initiate litigation against any entity by asserting a patent
+infringement claim (excluding declaratory judgment actions,
+counter-claims, and cross-claims) alleging that a Contributor Version
+directly or indirectly infringes any patent, then the rights granted to
+You by any and all Contributors for the Covered Software under Section
+2.1 of this License shall terminate.
+
+5.3. In the event of termination under Sections 5.1 or 5.2 above, all
+end user license agreements (excluding distributors and resellers) which
+have been validly granted by You or Your distributors under this License
+prior to termination shall survive termination.
+
+************************************************************************
+*                                                                      *
+*  6. Disclaimer of Warranty                                           *
+*  -------------------------                                           *
+*                                                                      *
+*  Covered Software is provided under this License on an "as is"       *
+*  basis, without warranty of any kind, either expressed, implied, or  *
+*  statutory, including, without limitation, warranties that the       *
+*  Covered Software is free of defects, merchantable, fit for a        *
+*  particular purpose or non-infringing. The entire risk as to the     *
+*  quality and performance of the Covered Software is with You.        *
+*  Should any Covered Software prove defective in any respect, You     *
+*  (not any Contributor) assume the cost of any necessary servicing,   *
+*  repair, or correction. This disclaimer of warranty constitutes an   *
+*  essential part of this License. No use of any Covered Software is   *
+*  authorized under this License except under this disclaimer.         *
+*                                                                      *
+************************************************************************
+
+************************************************************************
+*                                                                      *
+*  7. Limitation of Liability                                          *
+*  --------------------------                                          *
+*                                                                      *
+*  Under no circumstances and under no legal theory, whether tort      *
+*  (including negligence), contract, or otherwise, shall any           *
+*  Contributor, or anyone who distributes Covered Software as          *
+*  permitted above, be liable to You for any direct, indirect,         *
+*  special, incidental, or consequential damages of any character      *
+*  including, without limitation, damages for lost profits, loss of    *
+*  goodwill, work stoppage, computer failure or malfunction, or any    *
+*  and all other commercial damages or losses, even if such party      *
+*  shall have been informed of the possibility of such damages. This   *
+*  limitation of liability shall not apply to liability for death or   *
+*  personal injury resulting from such party's negligence to the       *
+*  extent applicable law prohibits such limitation. Some               *
+*  jurisdictions do not allow the exclusion or limitation of           *
+*  incidental or consequential damages, so this exclusion and          *
+*  limitation may not apply to You.                                    *
+*                                                                      *
+************************************************************************
+
+8. Litigation
+-------------
+
+Any litigation relating to this License may be brought only in the
+courts of a jurisdiction where the defendant maintains its principal
+place of business and such litigation shall be governed by laws of that
+jurisdiction, without reference to its conflict-of-law provisions.
+Nothing in this Section shall prevent a party's ability to bring
+cross-claims or counter-claims.
+
+9. Miscellaneous
+----------------
+
+This License represents the complete agreement concerning the subject
+matter hereof. If any provision of this License is held to be
+unenforceable, such provision shall be reformed only to the extent
+necessary to make it enforceable. Any law or regulation which provides
+that the language of a contract shall be construed against the drafter
+shall not be used to construe this License against a Contributor.
+
+10. Versions of the License
+---------------------------
+
+10.1. New Versions
+
+Mozilla Foundation is the license steward. Except as provided in Section
+10.3, no one other than the license steward has the right to modify or
+publish new versions of this License. Each version will be given a
+distinguishing version number.
+
+10.2. Effect of New Versions
+
+You may distribute the Covered Software under the terms of the version
+of the License under which You originally received the Covered Software,
+or under the terms of any subsequent version published by the license
+steward.
+
+10.3. Modified Versions
+
+If you create software not governed by this License, and you want to
+create a new license for such software, you may create and use a
+modified version of this License if you rename the license and remove
+any references to the name of the license steward (except to note that
+such modified license differs from this License).
+
+10.4. Distributing Source Code Form that is Incompatible With Secondary
+Licenses
+
+If You choose to distribute Source Code Form that is Incompatible With
+Secondary Licenses under the terms of this version of the License, the
+notice described in Exhibit B of this License must be attached.
+
+Exhibit A - Source Code Form License Notice
+-------------------------------------------
+
+  This Source Code Form is subject to the terms of the Mozilla Public
+  License, v. 2.0. If a copy of the MPL was not distributed with this
+  file, You can obtain one at https://mozilla.org/MPL/2.0/.
+
+If it is not possible or desirable to put the notice in a particular
+file, then You may include the notice in a location (such as a LICENSE
+file in a relevant directory) where a recipient would be likely to look
+for such a notice.
+
+You may add additional accurate notices of copyright ownership.
+
+Exhibit B - "Incompatible With Secondary Licenses" Notice
+---------------------------------------------------------
+
+  This Source Code Form is "Incompatible With Secondary Licenses", as
+  defined by the Mozilla Public License, v. 2.0.

README.md

@@ -0,0 +1,30 @@
+# SEQUA Engine
+
+![SEQUA](artwork/SEQUA_GraphicIdentity.v1.png "SEQUA Engine")
+
+**SEQUA** : *Simulate Environments, Quantify Uncertainty, Adapt.*
+
+Environnement de création et d'exécution de mondes virtuels, piloté par l'intention de l'auteur, au-dessus d'un noyau déterministe et rejouable. Les moteurs 3D et les modèles IA sont des composants interchangeables.
+
+Documentation de référence : [docs/SEQUA_Engine_resume_complet_v2.md](docs/SEQUA_Engine_resume_complet_v2.md)
+
+## Organisation du dépôt (monorepo)
+
+| Dossier | Rôle | Langage |
+|---|---|---|
+| [studio/](studio) | SEQUA Studio : application web de création | TypeScript |
+| [core/](core) | SEQUA Core : projet, simulation déterministe, rejeu, intentions, orchestrateur, confiance | C++20 |
+| [3d/](3d) | SEQUA 3D : interface vers les moteurs 3D (adaptateurs, capacités, synchronisation) | C++20 |
+| [schema/](schema) | Contrat de données et protocole Studio↔Core | Protobuf / FlatBuffers |
+| [docs/](docs) | Documentation et décisions d'architecture (`docs/adr/`) | Markdown |
+| [artwork/](artwork) | Identité graphique et sources visuelles | PNG |
+
+Les adaptateurs de moteurs (Godot, Unreal) vivent dans des dépôts séparés.
+
+## État
+
+Phase 0 : fondations. Rien n'est encore exécutable.
+
+## Licence
+
+[MPL 2.0](LICENSE). © Ange-Marie MAURIN - A2M Systèmes (https://a2msystemes.org)

docs/SEQUA_Engine_resume_complet_v2.md

@@ -0,0 +1,556 @@
+# SEQUA Engine
+
+![SEQUA](../artwork/SEQUA_GraphicIdentity.v1.png "SEQUA Engine")
+
+**SEQUA** signifie **Simulate Environments, Quantify Uncertainty, Adapt**.
+
+Cette phrase exprime la philosophie du projet : simuler des environnements, quantifier l'incertitude liée à leur représentation et aux traitements nécessaires, puis adapter les méthodes de calcul et de rendu au contexte.
+
+*Version 2 : refonte autour de SEQUA Studio, de la création guidée par l'intention et de l'indépendance vis-à-vis des moteurs d'exécution.*
+
+---
+
+## 1. Synthèse
+
+**SEQUA Engine** est un environnement de création et d'exécution de mondes virtuels dont le premier domaine d'application est le jeu vidéo. Il repose sur un changement de paradigme :
+
+> **Ce que l'utilisateur recherche n'est plus la maîtrise technique, mais l'expression d'une volonté artistique, la finesse du gameplay et l'innovation des modes de jeu.**
+
+SEQUA est composé de quatre couches :
+
+1. **SEQUA Studio** : l'outil de création, cœur et visage du produit. Il est puissant, novateur, et pensé pour des personnes, pas pour des paramètres.
+2. **SEQUA Core** : la source de vérité. Il possède le format de projet, la simulation déterministe, l'enregistrement et le rejeu, la couche d'intention, l'orchestrateur de rendu et la mesure de l'incertitude. Il ne connaît aucun moteur 3D.
+3. **SEQUA 3D** : la couche d'interface 3D, propriété de SEQUA. Elle définit le contrat de données, la synchronisation de la scène, la négociation des capacités et les adaptateurs vers les moteurs. C'est par elle, et par elle seule, que SEQUA parle à un moteur 3D.
+4. **Moteurs 3D** : les vrais moteurs d'exécution qui affichent et font tourner le monde (Godot en premier, Unreal ensuite, puis un moteur maison). Ils sont interchangeables et ne contiennent aucune logique du produit.
+
+**SEQUA n'est pas un plugin d'un autre moteur.** Les moteurs existants sont des composants que SEQUA pilote, pas des hôtes dont il dépend. Le projet, la scène de référence, les règles et les intentions appartiennent à SEQUA.
+
+**Principe directeur : la simulation détermine ce qui existe et ce qui se passe ; l'intention de l'auteur détermine ce que le monde doit faire ressentir ; les systèmes neuronaux et génératifs déterminent comment il apparaît.**
+
+Le projet ne cherche pas à réinventer la roue, mais à lui ajouter des pneus modernes : les bibliothèques existantes sont utilisées partout où elles sont mûres, derrière des contrats stables permettant de les remplacer plus tard.
+
+## 2. Manifeste
+
+### Principes
+
+1. **L'humain garde l'autorité.** L'IA propose, l'auteur choisit, épingle et retouche. Aucune génération ne remplace une décision de création.
+2. **L'intention est un objet de première classe.** Une ambiance, un rythme, une émotion visée sont stockés, versionnés, et pilotent le rendu, le gameplay et les budgets.
+3. **La simulation est déterministe et rejouable.** C'est ce qui permet de comparer, de revenir en arrière et de tester des variantes à l'identique.
+4. **L'apparence est séparée de la vérité du monde.** Collisions, règles et persistance ne dépendent jamais d'un modèle génératif.
+5. **L'incertitude est mesurée, pas ignorée.** Chaque sortie neuronale ou générative porte une confiance, utilisée pour décider, composer et informer l'auteur.
+6. **Le non-déterminisme est visible et maîtrisable.** Graines, modes figés, provenance de chaque élément généré.
+7. **Les moteurs d'exécution sont interchangeables.** Si changer de moteur 3D oblige à toucher au projet, l'architecture a échoué.
+8. **Le rendu IA est optionnel.** Le moteur reste utilisable en 3D classique sur du matériel modeste.
+9. **Divulgation progressive.** L'artiste travaille au niveau de l'intention ; l'expert peut toujours descendre à la couche technique.
+10. **Open source.** SEQUA est publié sous MPL 2.0 tant que le projet est porté par ses auteurs. Les dépendances du cœur sont permissives ; tout composant propriétaire n'entre que comme plugin facultatif (voir §10.2).
+11. **Multiplateforme par conception.** Windows, Linux et macOS sont compilés et testés dès le premier jour ; les fonctions les plus lourdes (IA, génération) peuvent arriver plateforme par plateforme, mais l'architecture ne suppose jamais une seule plateforme.
+
+### Test d'identité
+
+Avant d'ajouter une fonctionnalité, on pose la question :
+
+> *Est-ce seulement la version IA de quelque chose qui existe déjà dans un moteur classique ?*
+
+Si oui, elle est reportée ou abandonnée. « Générer une texture depuis une description » existe partout. « Rejouer à l'identique une session avec une règle modifiée » ou « peindre une ambiance sur une région avec carte de confiance » sont rares. Ce test sert à resserrer le périmètre sans perdre l'essence du projet.
+
+## 3. Architecture générale
+
+```text
+                        SEQUA STUDIO
+   (intentions, ressenti, modes de jeu, comparaison, direction)
+                              |
+                       commandes / état
+                              v
+                         SEQUA CORE
+   +----------------------------------------------------------+
+   |  Projet et scène de référence   |  Couche d'intention     |
+   |  Simulation déterministe        |  Enregistrement / rejeu |
+   |  Orchestrateur de rendu         |  Confiance et budgets   |
+   +----------------------------------------------------------+
+                              |
+                              v
+                          SEQUA 3D
+   +----------------------------------------------------------+
+   |  Contrat de données (NeuralFrameContext, état du monde,  |
+   |  commandes, mesures)  |  Synchronisation de la scène     |
+   |  Négociation des capacités  |  Adaptateurs               |
+   +----------------------------------------------------------+
+                              |
+        +---------------------+---------------------+
+        v                     v                     v
+   +-----------+        +-----------+        +----------------+
+   | Moteur 3D |        | Moteur 3D |        | Moteur 3D      |
+   | Godot     |        | Unreal    |        | Maison (futur) |
+   +-----------+        +-----------+        +----------------+
+                              |
+                    rendu : 3D / neuronal / génératif
+                              v
+                  compositeur temporel -> affichage
+                    (et mesures renvoyées à Studio)
+```
+
+### Responsabilités
+
+| Partie | Responsabilité |
+|---|---|
+| SEQUA Studio | Création, direction artistique, ressenti, modes de jeu, comparaison, débogage temporel, collaboration |
+| SEQUA Core | Format de projet, scène de référence, simulation déterministe, enregistrement et rejeu, intentions, orchestrateur, confiance |
+| SEQUA 3D | Contrat de données, synchronisation de la scène vers le moteur, négociation des capacités, adaptateurs, traduction des commandes et des mesures |
+| Moteurs 3D | Exécution du rendu et de l'affichage, production des tampons demandés, remontée des mesures |
+| Rendus (3D, neuronal, génératif) | Produire l'apparence selon les consignes de l'orchestrateur |
+
+## 4. SEQUA Studio
+
+Studio est le produit que l'utilisateur voit et juge. Il vise à rapprocher la création de jeu vidéo d'un travail d'auteur : on dirige un monde, on ne règle pas des paramètres.
+
+### 4.1 Couche d'intention
+
+Chaque région, moment ou objet peut porter une intention : ambiance (« refuge », « tension montante »), références visuelles, palette, rythme, contraintes de conservation.
+
+- Studio traduit l'intention en paramètres concrets (éclairage, matériaux, génération, budgets de calcul).
+- Un mode « couche technique » reste accessible : on voit et on peut modifier ce que l'intention a produit.
+- Pour que l'intention ne soit pas une promesse magique, elle repose sur un **vocabulaire restreint**, relié à des paramètres mesurables et validé par des tests (voir §12).
+
+### 4.2 Laboratoire de ressenti (game feel)
+
+Saut, caméra, arrêt sur impact, tolérance de saisie, inertie : on les règle en jouant, avec des courbes manipulables directement. Grâce à la simulation déterministe, une session enregistrée peut être rejouée à l'identique avec d'autres réglages, côte à côte.
+
+### 4.3 Atelier des modes de jeu
+
+- Les règles s'écrivent sous forme de **règles composables et lisibles** (cartes de règles, machines à états visuelles), compréhensibles par des non-programmeurs.
+- **Voyage dans le temps** : revenir en arrière, brancher une version alternative d'une règle, comparer les deux sur les mêmes actions du joueur.
+- **Tests de jeu par agents** (étape ultérieure) : des joueurs simulés testent un mode et rapportent stratégies dominantes, impasses et courbe de difficulté. Ils complètent les joueurs humains sans les remplacer.
+
+### 4.4 Vue de réalisateur
+
+Une frise des moments de l'expérience, avec une courbe de tension. Elle couvre les séquences de gameplay, pas seulement les cinématiques.
+
+### 4.5 Rendu : contrôle et lisibilité
+
+- **Peindre le mode de rendu** : sur une région ou un objet, on choisit 3D, neuronal ou génératif, avec transition douce.
+- **Surimpression de confiance** : voir où le rendu IA s'écarte de la vérité structurelle.
+- **Contraintes visibles** : préserver silhouette, collisions, identité ; les violations s'affichent là où elles se produisent.
+- **Travailler par budget** : on fixe un budget (millisecondes, Go de VRAM) et un profil de GPU cible, et Studio montre comment l'orchestrateur le répartit, y compris pour un matériel qu'on ne possède pas.
+- **Verrouiller et versionner l'apparence** : ce qui plaît est épinglé et la régénération n'y touche plus ; chaque changement se compare, s'accepte ou se refuse.
+- **Débogueur temporel** : remonter la timeline image par image, voir lesquelles étaient générées, rejetées car périmées, ou remplacées par la 3D.
+- **Comparaison de rendus** : classique, amélioré, génératif, côte à côte avec la même caméra.
+
+### 4.6 L'IA comme collaboratrice
+
+- Elle propose plusieurs variantes ; l'auteur choisit, épingle et retouche.
+- Tout élément généré garde sa provenance (l'intention qui l'a produit, la graine, le modèle) et reste modifiable de façon non destructive.
+- Pas de simple zone de texte « génère-moi un niveau » : les contrôles déterministes restent la base, la génération est une aide.
+
+### 4.7 Collaboration
+
+Commentaires, revues, branches de direction créative et comparaison d'intentions d'une version à l'autre, pour que programmeurs, artistes, game designers et directeurs de création travaillent sur le même projet sans passer par des outils techniques.
+
+### 4.8 Technologie de l'interface : Studio web, conteneur remplaçable
+
+Studio est une **application web écrite en TypeScript**, indépendante de tout moteur. Elle ne communique avec le Core que par un **protocole** (WebSocket plus schéma partagé, voir §5.6). Comme elle ne dépend d'aucun conteneur particulier, le conteneur est un détail remplaçable.
+
+**Conteneurs possibles**
+
+| Conteneur | Licence | Usage |
+|---|---|---|
+| Navigateur de l'utilisateur | aucune | Le Core C++ sert Studio localement. Solution de la phase 1 : rien à embarquer |
+| Webview du système (bibliothèque `webview/webview`, MIT) | permissive | Application de bureau légère ; moteurs web différents selon la plateforme |
+| CEF (Chromium Embedded Framework) | BSD | Comportement identique partout, mais lourd à distribuer |
+| Interface native C++ (Dear ImGui, RmlUi) | MIT | Outils de débogage et modes dégradés |
+
+Qt et les composants à licence restrictive sont exclus du cœur (voir §10.2).
+
+**Séparation de l'état et de l'affichage.** L'interface est une vue d'un modèle sérialisable (modes de rendu, contraintes, budgets, verrous, intentions). Elle n'a jamais de logique de produit propre.
+
+**Disposition du poste de travail.** Le jeu s'exécute dans sa propre fenêtre, qui peut occuper un second écran en plein écran, tandis que Studio, dans une webview ou un navigateur, occupe le premier. Cette disposition est le mode de travail de référence : elle donne au jeu toute sa résolution et sa fluidité, sans passer par un flux vidéo vers une page web.
+
+**Intégration de la vue dans l'interface (étape ultérieure).** Pour afficher la vue du moteur dans Studio lui-même, les pistes sont un flux vidéo local vers la page, ou une composition native de la webview et de la vue du moteur. Sous Linux, superposer une fenêtre native à une page web est délicat avec Wayland (à vérifier). Cette intégration est donc un objectif de la phase 3, pas un prérequis.
+
+**Composants dessinés par le GPU.** Frise de réalisateur, courbes de ressenti, graphes de règles et surimpressions sont des composants maison (WebGPU ou WebGL2, avec repli si WebGPU est indisponible). Les panneaux courants (inspecteurs, formulaires, docking) reposent sur des bibliothèques web existantes avec un système de design propre à SEQUA. Un moteur d'interface complet maison n'est pas prévu.
+
+## 5. SEQUA Core
+
+### 5.1 Projet et scène de référence
+
+Le projet est une **description de données** appartenant à SEQUA, sans logique propre à un moteur. Il contient objets, règles, intentions, contraintes, budgets, références visuelles et historique. Les moteurs 3D reçoivent cette description via SEQUA 3D et l'exécutent ; ils ne sont jamais modifiés directement.
+
+Les assets s'appuient sur des formats ouverts (glTF, USD) avec des extensions SEQUA pour les intentions et contraintes.
+
+### 5.2 Représentation du monde en quatre niveaux
+
+| Niveau | Contenu | Garantie |
+|---|---|---|
+| L0 Structurel | Volumes, topologie, collisions, dimensions, logique | Déterministe et toujours disponible |
+| L1 Géométrique | Meshes, textures, matériaux, lumières | Rendu traditionnel |
+| L2 Neuronal | Détails reconstruits, apparence enrichie, représentations neuronales | Guidé par les données de scène |
+| L3 Génératif | Apparence et éléments générés à la demande | Contraint par la structure du monde |
+
+Chaque objet possède une identité persistante, un transform, des collisions, un état logique, des propriétés sémantiques, des règles d'interaction et une représentation visuelle interchangeable. Exemple : un arbre a une collision et une position déterministes, mais son apparence peut être un mesh, un asset neuronal ou une génération conditionnée.
+
+### 5.3 Simulation déterministe, enregistrement et rejeu
+
+- Fréquence de simulation fixe, indépendante de l'affichage.
+- Toutes les entrées du joueur sont enregistrées avec leur horodatage de simulation.
+- Une session se rejoue à l'identique, avec d'autres règles, d'autres réglages de ressenti ou un autre moteur 3D.
+- Les modèles neuronaux et génératifs sont exclus de la boucle de simulation : ils n'influencent jamais l'état du monde.
+- L'apparence étant purement locale, des joueurs différents peuvent avoir des rendus différents sans désynchronisation de la simulation (avantage pour le jeu en réseau).
+
+### 5.4 Orchestrateur de rendu adaptatif
+
+C'est le composant qui réalise le « Adapt » de SEQUA.
+
+Fonctions :
+
+- détecter les capacités réelles du GPU, mesurer la VRAM et la charge ;
+- établir un budget de calcul et sélectionner le pipeline ;
+- répartir les tâches entre CPU et GPU ;
+- surveiller les temps d'inférence, réduire la qualité IA ou revenir à la 3D classique en cas de surcharge ;
+- **s'appuyer sur la confiance** (§5.5) pour décider où dégrader.
+
+Modes de rendu :
+
+1. **Classic** : rendu 3D conventionnel.
+2. **Neural Enhancement** : 3D plus amélioration neuronale.
+3. **Hybrid Generative** : génération visuelle localisée.
+4. **Generative World** : apparence d'une partie du monde générée à partir d'une description structurelle et temporelle.
+
+**Rendu adaptatif spatial** : les modes coexistent dans une image et se choisissent par objet, matériau, région ou couche. Exemple : personnage et arme en 3D classique, ennemis en 3D plus reconstruction, forêt générée, brouillard neuronal, interface en 2D.
+
+Difficulté connue : une région générée ne fournit ni profondeur, ni identifiants, ni éclairage cohérent avec le reste. Il faut gérer l'occlusion (un personnage 3D devant un arbre généré), les ombres portées et les raccords entre régions. C'est le point le plus risqué de l'orchestrateur et il fait partie du prototype.
+
+### 5.5 Quantifier l'incertitude
+
+C'est le « Quantify Uncertainty » du nom, mis en œuvre concrètement :
+
+- Chaque sortie neuronale ou générative est accompagnée d'une **carte de confiance** par pixel ou par région.
+- La confiance est calculée par **vérification en boucle fermée** : un estimateur de profondeur et de segmentation est exécuté sur l'image produite puis comparé à la vérité L0 (profondeur réelle, identifiants d'objets).
+- Elle sert à trois décisions : l'orchestrateur dégrade ou bascule en 3D là où elle est basse ; le compositeur fond les régions selon elle ; Studio l'affiche à l'auteur.
+- Elle répond à un risque de gameplay, pas seulement visuel : un arbre généré sans collision ou un mur dessiné là où il n'y en a pas trompent le joueur.
+
+### 5.6 Contrat de données
+
+Le contrat est l'interface qui compte : il survit au remplacement des bibliothèques parce qu'il ne reprend aucun concept d'un moteur particulier.
+
+**Du Core vers le rendu** (`NeuralFrameContext`) : couleur, profondeur, normales, vecteurs de mouvement, albedo, identifiants d'objets, masque sémantique, caméra, éclairage, état temporel, paramètres artistiques et intentions, index de frame.
+
+**Du rendu vers le Core et Studio** : image produite, carte de confiance, temps de calcul, VRAM utilisée, version de l'état du monde utilisée.
+
+Règles :
+
+- Le contrat se définit à partir de prototypes, pas dans l'abstrait ; on prévoit de le réviser plusieurs fois pendant la phase 1.
+- Les données restent résidentes sur le GPU autant que possible. Le passage de textures entre l'API graphique (Vulkan, DirectX) et le moteur d'inférence (CUDA, TensorRT) sans copie CPU est le point où les abstractions fuient le plus ; il est testé en tout premier.
+
+### 5.7 Synchronisation temporelle
+
+Chaque résultat généré est associé à un horodatage, une caméra, une version de l'état du monde, les transformations des objets et l'historique temporel utilisé. Les résultats périmés sont rejetés ou limités à un rôle d'enrichissement. La simulation et les interactions critiques n'attendent jamais le modèle génératif.
+
+Techniques envisagées : génération par petits blocs, contexte glissant, attention causale, KV cache, reprojection, compensation de mouvement, correction par le renderer 3D.
+
+## 6. Moteur neuronal et génératif
+
+Trois sous-systèmes, utilisables via des plugins interchangeables.
+
+### Neural Reconstruction Engine
+
+Amélioration de résolution, reconstruction de détails, débruitage, reconstruction temporelle. Ce terrain est déjà occupé par les solutions des fabricants (DLSS, FSR, XeSS). Il reste utile comme base technique et comme mode de repli, mais **n'est pas le différenciateur** du projet.
+
+### Neural Appearance Engine
+
+Enrichissement de matériaux, détails de surface, végétation, atmosphère, éclairage neuronal, transformation d'apparence **avec contraintes de conservation** (silhouette, identité, collisions, palette). C'est ici que se joue la valeur : une apparence guidée par la sémantique et l'intention, et non un simple gain de résolution. C'est le premier module IA à développer en profondeur.
+
+### Generative Video Engine
+
+Génération à partir d'une vidéo de référence, conditionnement par la caméra et les données de scène, mémoire temporelle, génération de frames ou de petits blocs, prise en compte des événements du monde.
+
+Deux voies : une voie neuronale rapide pour le gameplay (image par image, guidée par la 3D) et une voie de génération par blocs pour les environnements et transitions complexes. Un débit vidéo élevé n'implique pas une faible latence interactive : débit, latence du premier bloc et latence input-to-photon se mesurent séparément.
+
+## 7. SEQUA 3D et moteurs 3D
+
+On distingue deux choses :
+
+- **SEQUA 3D** est l'interface : du code propriété de SEQUA, qui ne dépend d'aucun moteur. Elle définit ce que SEQUA demande à un moteur 3D et ce qu'il doit renvoyer.
+- Les **moteurs 3D** (Godot, Unreal, un futur moteur maison) sont les vrais moteurs d'exécution. Ce sont des implémentations de SEQUA 3D, rien de plus.
+
+Pour éviter toute confusion, le mot « backend » est réservé au calcul GPU (`IComputeBackend`).
+
+### 7.0 Ce que contient SEQUA 3D
+
+- **Le contrat de données** (voir §5.6).
+- **La synchronisation de la scène** : le projet SEQUA est poussé vers le moteur à sens unique ; le moteur n'est jamais modifié directement.
+- **La négociation des capacités** : chaque moteur déclare ce qu'il sait produire (identifiants d'objets, vecteurs de mouvement, albedo, profondeur, normales…). L'orchestrateur et Studio s'adaptent à cette déclaration au lieu de supposer que tout existe.
+- **L'interface d'adaptateur** (`I3DEngineAdapter`) que chaque moteur implémente.
+- **La traduction des mesures** (temps de calcul, VRAM, confiance) vers un format commun.
+
+### 7.0.1 Précautions
+
+- **Interface étroite.** SEQUA 3D ne doit exposer aucun concept propre à un moteur (nœuds Godot, acteurs Unreal) et ne doit pas viser le plus petit dénominateur commun : ce qu'un moteur ne sait pas faire est signalé par la négociation des capacités, pas supprimé de l'interface.
+- **Un petit agent côté moteur reste inévitable.** Pour lire les tampons de rendu ou recevoir les commandes, il faut du code qui s'exécute dans le moteur (extension native Godot, module Unreal). Cet agent est interne, minimal, sans logique de produit, et n'est pas ce que l'utilisateur voit. C'est la seule partie qui ressemble à un plugin.
+- **Le Core ne connaît pas le moteur.** Sa simulation, ses intentions et son orchestrateur ne dépendent que du contrat, ce qui garde la porte ouverte à d'autres usages que la 3D (simulation, visualisation).
+
+### 7.1 Ordre prévu
+
+1. **Godot** (phase 1) : licence permissive, code modifiable, bon candidat pour les premiers essais. Le moteur y est utilisé comme moteur d'exécution, pas comme éditeur.
+2. **Unreal** (phase 2) : sert de **test d'isolation**. Critère de réussite : *la même couche SEQUA tourne sur Godot et sur Unreal avec seulement un adaptateur d'hôte à écrire.* Si l'adaptateur Unreal oblige à modifier le Core ou Studio, le contrat de données est mal conçu.
+3. **Moteur maison** (long terme) : les parties du moteur que SEQUA juge utile de maîtriser (rendu, simulation, outils) sont progressivement intégrées dans SEQUA.
+
+### 7.2 Responsabilité de l'adaptateur
+
+Chaque adaptateur produit les tampons du contrat qu'il déclare savoir produire, quels que soient les moyens de son moteur. Exemple à vérifier dans la version utilisée : Unreal dispose d'un G-buffer et d'un stencil exploitable pour les identifiants d'objets ; Godot en rendu Forward+ n'a pas de G-buffer classique, donc l'albedo et les identifiants d'objets demanderont des passes supplémentaires.
+
+### 7.3 Risques propres à cette architecture
+
+- **Double scène** : une version dans SEQUA, une dans le moteur, qui divergent. Parade : le projet SEQUA est la seule source de vérité, synchronisée à sens unique vers le moteur par SEQUA 3D.
+- **Pipeline d'assets** : importation depuis glTF/USD et export vers chaque moteur 3D à maintenir.
+- **Viewport** : latence et intégration de la vue en direct dans Studio (voir §4.8).
+
+## 8. Gestes signature
+
+Chaque pilier du projet est défini par une interaction qui n'existe pas, ou pas ainsi, dans un moteur classique. Ces gestes sont implémentés dès le départ, même grossièrement.
+
+| Pilier | Geste signature |
+|---|---|
+| Intention | On peint une ambiance sur une région (« refuge vers menace ») ; éclairage, apparence et rendu y répondent |
+| Ressenti et modes | On enregistre une session, puis on la rejoue à l'identique avec une règle ou un réglage différent, côte à côte |
+| Incertitude | La carte de confiance s'affiche en surimpression ; l'orchestrateur bascule sur la 3D là où elle est basse |
+| Adaptation | On choisit un profil de GPU cible et on voit le budget se réallouer entre les modes de rendu |
+| Isolation | On change de moteur d'exécution (Godot vers Unreal) sans toucher au projet (phase 2) |
+
+## 9. Prototype fondateur : le squelette
+
+Au lieu d'une coupe verticale étroite, la première version relie tous les piliers par un **chemin minimal de bout en bout** : Studio produit un projet, le Core simule de façon déterministe et enregistre, SEQUA 3D transmet au moteur 3D qui rend, et les mesures (confiance, budget) reviennent dans Studio. Chaque maillon est fin, mais le chemin est complet.
+
+### Scène de démonstration
+
+Une petite scène de forêt à la première personne avec un micro-mode de jeu, rendue en trois sorties synchronisées (3D classique, 3D améliorée par IA, génératif) avec la même caméra, les mêmes collisions et le même état du monde.
+
+### Scénario de démonstration
+
+Une personne non technique :
+
+1. peint une ambiance sur une région dans Studio ;
+2. voit le rendu changer sur Godot, avec la carte de confiance en surimpression ;
+3. règle le ressenti d'un mouvement et d'une règle, rejoue sa session, compare les deux versions ;
+4. change de profil de GPU et observe la réallocation du budget.
+
+La phase 2 y ajoute : même projet, moteur 3D Unreal.
+
+### Pilier à approfondir en premier
+
+Le **rendu avec confiance** (Neural Appearance et carte de confiance), car c'est le plus risqué techniquement. Les autres piliers existent sous une forme minimale mais réelle.
+
+### Réel et simulé
+
+Pour tenir plusieurs piliers avec des moyens limités, certaines parties seront simulées au début (par exemple l'intention pilotera d'abord un petit nombre de paramètres fixes, et les agents de test viendront plus tard). **Tout ce qui est simulé est marqué comme tel**, pour ne pas confondre prototype et validation.
+
+### Critères de réussite
+
+- L'environnement devient visuellement plus riche **sans perte de correspondance** entre géométrie, collisions, objets et état physique.
+- Un rejeu déterministe est identique bit à bit côté simulation.
+- La carte de confiance détecte effectivement les écarts avec la vérité L0 (arbre généré sans collision, objet déplacé).
+
+### Critères d'arrêt (à fixer avant de commencer)
+
+À définir par des seuils chiffrés, par exemple : cohérence temporelle mesurée trop faible, consommation de VRAM excédant le profil visé, dérive géométrique au-dessus d'un seuil. Si un seuil est franchi, on change d'approche plutôt que de poursuivre.
+
+## 10. Stratégie : réutiliser avant de construire
+
+| Domaine | Brique de départ | Remplaçable par |
+|---|---|---|
+| Moteur 3D (derrière SEQUA 3D) | Godot, puis Unreal | Moteur maison |
+| Physique | Jolt | — |
+| ECS | EnTT | Solution propriétaire |
+| Inférence | ONNX Runtime, TensorRT | Backends spécialisés |
+| Entraînement | PyTorch | — |
+| Génération | ComfyUI, diffusers, pipelines temps réel type StreamDiffusion | Plugins `IVideoGenerationPlugin` |
+| Amélioration de résolution | SDK des fabricants (DLSS, FSR, XeSS), éventuellement via une couche d'unification | Modèle propre |
+| Shaders | Slang | — |
+| Assets | glTF, USD | Formats propriétaires |
+| Profilage | Tracy et outils GPU natifs | — |
+| Interface Studio | Application web TypeScript, conteneur remplaçable (§4.8) | Autres conteneurs |
+| Protocole et contrat | Protobuf ou FlatBuffers (types générés en C++ et TypeScript) | — |
+| Build | CMake (C++), Vite (TypeScript) | — |
+
+Pour le prototype : un seul chemin technique (Vulkan, Slang, GPU NVIDIA). Les autres APIs et fabricants s'ajoutent une fois la thèse prouvée, via `IComputeBackend`.
+
+**Le moteur comme générateur de données d'entraînement** : le moteur produit gratuitement des paires parfaites (tampons de rendu et image de référence), ce qui permet d'entraîner des modèles légers propres au projet. Référence à vérifier : *Enhancing Photorealism Enhancement* (Intel, 2021), qui utilisait les tampons de rendu d'un jeu pour guider l'amélioration d'image.
+
+### 10.1 Langages
+
+Pour limiter la charge cognitive, SEQUA utilise **deux langages de produit** :
+
+| Rôle | Langage |
+|---|---|
+| Tout le natif : Core, SEQUA 3D, agents côté moteur 3D, colle GPU et inférence | C++20/23 |
+| Studio | TypeScript |
+| Shaders (domaine étroit) | Slang |
+| Entraînement et expérimentation des modèles (hors produit) | Python |
+
+Justification du C++ : Jolt, EnTT, Slang, ONNX Runtime et CUDA y sont natifs ; l'extension Godot (GDExtension) et le module Unreal y sont écrits ; aucune frontière de langage côté natif, ce qui simplifie notamment le partage de textures GPU entre rendu et inférence.
+
+Contreparties assumées et compensations : pas de garantie mémoire du compilateur, donc C++ moderne sans pointeurs propriétaires bruts, analyseurs statiques (clang-tidy), sanitizers (ASan, UBSan) en intégration continue, avertissements stricts.
+
+**Règles de déterminisme en C++** (simulation et rejeu) :
+
+- désactiver `-ffast-math` et les fusions multiplication-addition (`-ffp-contract=off`) ;
+- aucune dépendance à `std::unordered_map` ou à un ordre d'itération non défini dans la simulation ;
+- bibliothèque mathématique déterministe, indépendante de la plateforme ;
+- résultats indépendants de l'ordonnancement des threads ;
+- générateur aléatoire propre à SEQUA, avec graine explicite ;
+- mode de déterminisme multiplateforme de Jolt à activer (à vérifier dans la version retenue).
+
+Python reste hors de la boucle d'exécution : en phase 1, ComfyUI ou diffusers tournent comme processus séparé ; les modèles sont ensuite exportés vers le runtime.
+
+### 10.2 Licences et dépendances
+
+**Licence de SEQUA : MPL 2.0.** Toute modification des fichiers de SEQUA reste ouverte, et les jeux créés avec SEQUA restent libres de choisir leur licence. Les versions déjà publiées restent sous cette licence. Pour garder de la souplesse sur les versions futures, la politique de contributions (certificat d'origine DCO ou accord de contributeurs) se choisit tôt, avant d'accepter des contributions externes. Un avis juridique est conseillé le moment venu.
+
+**Politique de dépendances**
+
+- Le cœur n'utilise que des dépendances permissives (MIT, BSD, Apache 2.0, zlib) ; la compatibilité de chaque version retenue est à confirmer.
+- Tout composant propriétaire n'entre que comme **plugin facultatif** : Unreal (licence propriétaire, adaptateur seul ouvert), CUDA, TensorRT et DLSS (NVIDIA uniquement, derrière `IComputeBackend`).
+- **Poids des modèles** : ils ne sont pas embarqués dans le dépôt. Par défaut, seuls des modèles sous Apache 2.0 ou MIT sont proposés ; les autres sont téléchargés par l'utilisateur, avec sa propre acceptation de licence.
+- Qt, Ultralight, Sciter et tout composant à licence restrictive sont exclus du cœur. WebView2 est exclu car propriétaire et limité à Windows.
+
+### 10.3 Multiplateforme
+
+Le multiplateforme s'entend comme une **architecture et une intégration continue** : le projet compile et passe ses tests sur Windows, Linux et macOS à chaque modification. Les fonctions IA lourdes arrivent plateforme par plateforme et fabricant par fabricant, via des plugins. macOS est la plateforme la plus délicate pour le calcul GPU (Metal plutôt que Vulkan natif) et sera traité en conséquence.
+
+### API et plugins prévus
+
+`IRendererPlugin`, `INeuralRendererPlugin`, `IVideoGenerationPlugin`, `IWorldGeneratorPlugin`, `IComputeBackendPlugin`, `I3DEngineAdapter`.
+
+Le remplacement d'un modèle ou d'un moteur ne doit pas nécessiter de réécrire le jeu.
+
+## 11. Compatibilité matérielle
+
+Le moteur doit fonctionner sans génération IA.
+
+| Profil | VRAM indicative | Fonctionnalités |
+|---|---|---|
+| Entry | 6 à 8 Go | 3D classique, reconstruction légère |
+| Mainstream | 8 à 12 Go | Amélioration neuronale compacte |
+| Advanced | 12 à 16 Go | Rendu neuronal plus avancé |
+| High-end | 16 à 24 Go | Rendu hybride, génération limitée |
+| Enthusiast | 24 à 32 Go et plus | Modèles génératifs plus lourds |
+
+Ces profils ne sont pas des garanties : les besoins réels (modèles, caches, activations, résolutions) seront mesurés.
+
+Fonctions nécessaires : chargement à la demande, quantification adaptée, streaming des modèles, gestion de VRAM, déchargement des modèles inutilisés, repli en 3D, tests sur plusieurs fabricants.
+
+## 12. Génération du monde et persistance
+
+Le World Generation System produit des environnements sous contraintes :
+
+1. topologie ;
+2. placement des objets ;
+3. collisions et chemins ;
+4. propriétés sémantiques et physiques ;
+5. génération visuelle ;
+6. enrichissement neuronal ;
+7. mise à jour selon les événements.
+
+Chaque région possède un identifiant, une graine, un état physique et logique, une description sémantique, une intention, des références visuelles et un historique. Les modifications du joueur survivent à la régénération : une maison détruite ne réapparaît pas intacte. Les éléments épinglés par l'auteur ne sont jamais écrasés.
+
+### Vocabulaire d'intentions
+
+Pour éviter une interface qui promet de la magie, le vocabulaire initial est volontairement court (quelques ambiances, quelques rythmes), chacun relié à des paramètres mesurables et vérifié par des tests (perception, comparaison de variantes, retours d'utilisateurs). Il s'étend ensuite selon les résultats.
+
+## 13. Feuille de route indicative
+
+L'ordre compte plus que les durées, qui dépendent de l'équipe (à décider, voir §16) et sont à fixer après le premier prototype.
+
+| Phase | Contenu | Résultat |
+|---|---|---|
+| 0. Fondations | Contrat de données, passage GPU rendu vers inférence, format de projet minimal | Données qui circulent de bout en bout |
+| 1. Squelette sur Godot | Les gestes signature (intention, rejeu, confiance, budget) sous forme minimale, scène de forêt | Démonstration complète du concept |
+| 2. Isolation | Adaptateur Unreal, même projet | Preuve que le Core est indépendant du moteur |
+| 3. Approfondissement | Neural Appearance, composition spatiale, atelier de modes, tests par agents | Studio crédible pour de vrais projets |
+| 4. Monde génératif | Generative Video Engine, World Generation System | Monde semi-génératif persistant |
+| 5. Maîtrise du moteur | Intégration progressive de composants maison dans SEQUA | Moteur d'exécution propre |
+
+## 14. Objectifs de performance initiaux
+
+| Indicateur | Objectif |
+|---|---|
+| Simulation | 60 à 120 Hz |
+| Affichage | 60 FPS |
+| Latence commandes (voie neuronale rapide) | moins de 50 ms visée |
+| Latence commandes (voie génération par blocs) | objectif séparé, à mesurer ; non interactif au sens strict |
+| Résolution minimale | 1080p |
+| Résolution cible | 1440p |
+| Résolution avancée | 4K |
+| Changement de pipeline | sans interruption du gameplay |
+| Fonctionnement sans IA | obligatoire |
+
+Métriques suivies séparément : latence input-to-photon, latence du premier bloc généré, débit vidéo, stabilité temporelle, fréquence de simulation, **exactitude du rejeu** et **précision de la carte de confiance**. Ces objectifs sont des hypothèses à valider par prototype.
+
+## 15. Décisions à préserver
+
+1. SEQUA n'est pas un plugin d'un autre moteur ; il possède le projet, la scène de référence et le contrat de données.
+2. Studio est le cœur du produit, centré sur l'intention artistique et la finesse de gameplay.
+3. La simulation reste déterministe et rejouable.
+4. L'humain garde l'autorité ; l'IA propose.
+5. L'incertitude est quantifiée et utilisée.
+6. Les moteurs 3D et les modèles IA sont interchangeables ; SEQUA 3D est la seule porte entre SEQUA et un moteur.
+7. Le rendu génératif est optionnel ; le runtime de base ne dépend pas du cloud.
+8. La représentation logique du monde est indépendante de son apparence.
+9. Le rendu est adaptatif et spatial.
+10. Les bibliothèques existantes sont réutilisées derrière des contrats stables.
+11. Chaque fonctionnalité passe le test d'identité.
+12. La compatibilité multi-fabricant est une exigence d'architecture, activée après la preuve de concept.
+13. Les parties simulées d'un prototype sont toujours marquées comme telles.
+14. SEQUA est open source sous MPL 2.0 ; le cœur n'a que des dépendances permissives.
+15. Le projet est multiplateforme par conception, avec intégration continue sur Windows, Linux et macOS.
+16. Studio est une application web dont le conteneur est remplaçable ; il ne parle au Core que par protocole.
+17. Deux langages de produit seulement : C++ et TypeScript.
+
+## 16. Principaux risques
+
+| Risque | Réponse |
+|---|---|
+| Périmètre trop large pour l'équipe | Squelette minimal de bout en bout, un pilier approfondi à la fois, test d'identité |
+| Éditeur très coûteux à construire | Importer les scènes existantes (glTF, USD) et concentrer l'effort sur les couches nouvelles |
+| Intention artistique trop floue | Vocabulaire restreint relié à des paramètres mesurables et validé par des tests |
+| Double scène entre SEQUA et le moteur | Projet SEQUA unique source de vérité, synchronisation à sens unique |
+| Fuite des abstractions (échange GPU entre rendu et inférence) | Testé en premier ; contrat de données issu de prototypes |
+| Composition spatiale difficile (occlusion, ombres, raccords) | Inclus dans le prototype ; confiance utilisée au raccord |
+| Latence générative excessive | Deux voies, simulation indépendante, repli 3D |
+| Incohérence temporelle | État versionné, historique, validation des frames |
+| Contenu généré trompeur pour le gameplay | Vérification en boucle fermée contre L0, carte de confiance |
+| Consommation de VRAM | Modèles compacts, quantification, chargement à la demande |
+| Dépendance à un modèle ou à un moteur | Plugins, adaptateurs et interfaces stables |
+| Différences entre GPU | Abstraction de calcul et backends spécifiques après la preuve de concept |
+| Contrôle artistique et reproductibilité | Graines fixes, mode figé, provenance de chaque élément généré |
+| Licences et données d'entraînement | Politique de licences des modèles (§10.2), provenance des données, étiquetage du contenu généré |
+| Sûreté mémoire du C++ | Analyseurs statiques, sanitizers en intégration continue, C++ moderne |
+| Déterminisme perdu par un compilateur ou une plateforme | Règles de §10.1, tests de rejeu comparés entre plateformes en intégration continue |
+| Webviews de plateformes différentes (comportements divergents) | Conteneur remplaçable, repli de rendu, CEF si l'homogénéité devient indispensable |
+| Contributions externes et licence | MPL 2.0 ; choisir tôt entre DCO et accord de contributeurs |
+
+## 17. Décisions ouvertes
+
+- Équipe, compétences, budget et calendrier.
+- Plateforme et fabricant de référence pour les premiers prototypes (la cible reste multiplateforme).
+- Conteneur de Studio pour la distribution de bureau (webview du système ou CEF) et méthode d'intégration de la vue du moteur (flux ou composition native).
+- Format de schéma du contrat (Protobuf ou FlatBuffers).
+- Moteur d'inférence open source pour le multi-fabricant (ONNX Runtime, ncnn…).
+- Physique : Jolt par FFI ou autre, selon un test de déterminisme.
+- Premier GPU de référence et modèle neuronal de départ.
+- Scène de benchmark et seuils des critères d'arrêt.
+- Objectifs de latence réalistes par voie de rendu.
+- Premier vocabulaire d'intentions et méthode de validation.
+- Politique de contributions (DCO ou accord de contributeurs) et politique de distribution des poids de modèles.
+
+*Décisions prises : licence MPL 2.0 ; deux langages de produit (C++ et TypeScript) ; Studio web avec conteneur remplaçable ; multiplateforme par conception.*
+
+## Conclusion
+
+SEQUA Engine est une plateforme de création où l'auteur dirige un monde par l'intention, le ressenti et les règles, au-dessus d'un noyau déterministe et rejouable, avec un rendu adaptatif et mesuré par sa propre incertitude. Les moteurs d'exécution et les modèles IA sont des composants interchangeables, pas les fondations du projet.
+
+Le premier jalon n'est pas de générer un monde entier. C'est de démontrer, par un squelette complet de bout en bout, qu'une personne peut peindre une ambiance, voir le monde y répondre sans perdre sa cohérence, rejouer et comparer des variantes de gameplay à l'identique, et changer de moteur d'exécution sans toucher à son projet. C'est cette preuve qui justifiera ensuite l'investissement dans la génération vidéo, la génération de monde et un moteur propre.
+
+---
+
+## Note de validation
+
+Les chiffres de performance, noms de projets, dates et références de recherche mentionnés sont à vérifier à partir de leurs publications et dépôts officiels avant toute décision technique ou budgétaire. Les budgets par frame, profils GPU, comportements des moteurs (Godot, Unreal) et choix de bibliothèques sont des hypothèses de conception, pas des résultats mesurés.