Une ADR (Architecture Decision Record) consigne une décision structurante : son contexte, les options envisagées, le choix fait et ses conséquences. Elle garde le pourquoi que le code ne montre pas.

Règles

Une décision par fiche, numérotée dans l'ordre (NNNN-titre-court.md), écrite à partir de 0000-modele.md.
Une ADR acceptée n'est pas réécrite : si l'on change d'avis, une nouvelle ADR la remplace et l'ancienne passe au statut « Remplacée par ADR NNNN ».
Seules les décisions difficiles à défaire en méritent une (format, licence, dépendance majeure, architecture).

Index

N°	Décision	Statut
0001	Licence MPL 2.0 et politique de dépendances	Acceptée
0002	Deux langages de produit : C++ et TypeScript	Acceptée
0003	Studio web, conteneur remplaçable	Acceptée
0004	Multiplateforme par conception, vérification locale	Acceptée, modifiée par 0010
0005	Serveur WebSocket du Core (IXWebSocket, nlohmann/json)	Acceptée
0006	Studio host et cycle de vie du Core	Acceptée
0007	Adaptateur Godot dans le dépôt, Godot hébergé par LibGodot depuis un fork	Acceptée
0008	Processus de rendu séparé du Core, moteur et inférence en bibliothèques chargées	Acceptée
0009	Processus de rendu lancé par le Core, protocole Core ↔ rendu, adaptateurs en bibliothèques chargées	Acceptée
0010	Arborescence des binaires (développement et installation), build unifié	Acceptée
0011	Entrées du joueur captées par l'adaptateur, traduction en actions dans l'adaptateur	Acceptée

Décisions ouvertes (docs, §17)

Format du schéma du contrat (Protobuf ou FlatBuffers), conteneur de bureau de Studio, moteur d'inférence multi-fabricant, physique (Jolt), premier GPU et modèle de référence, seuils des critères d'arrêt, objectifs de latence, premier vocabulaire d'intentions, politique de contributions (DCO ou accord de contributeurs).