Prime Radiant : modeleur visuel de L-systems pour generation de scenarios de test¶
Resume¶
Prime Radiant est un modeleur visuel de grammaires formelles (L-systems) ecrit en Rust + Tauri v2 + Svelte 5. Il genere des sequences de test complexes, probabilistes et deterministes a partir de modeles composables. Code source : https://gitlab.com/Akanoa/prime-radiant — MIT, 7 commits (28 mars 2026). Reference d'inspiration : Might of Merchants — jeu medieval qui utilise les L-systems pour la generation procedurale de mondes (villes, economies, dynasties).
Architecture en 4 couches¶
| Couche | Concept | Fonctionnement |
|---|---|---|
| Tokens | Alphabet atomique | Constantes (GET, PUT, DEL) et variables typees (string avec pattern/longueur, int/float avec min/max/pas, bool, enum) |
| Statements | Expressions | Sequences ordonnees de tokens. Ex: PUT key value = 1 constante + 2 variables. Construction drag-and-drop |
| Scenarios | Graphes de transitions | Graphes ponderes diriges reliant des statements. Statements initiaux avec poids. Regles de propagation par variable : propagate (reutilise valeur) ou renew (regenere) |
| Sagas | Compositions | Graphes ponderes de scenarios. Pool de variables partage entre scenarios. Compteurs d'etapes configurables par scenario |
Dependances strictes sans cycles : Tokens ← Statements ← Scenarios ← Sagas.
Details techniques cles¶
- PRNG seme ChaCha8 — sortie deterministe et reproductible. Meme seed = memes scenarios, meme machine, meme resultat.
- Propagation de variables — chaque transition decide si une variable reutilise sa valeur precedente ou en genere une nouvelle. Ca permet de modeliser des sessions (meme
user_idpropage) avec des donnees variables (nouveaudocument_ida chaque etape). - Topologie etoile (blueprint canvas) — editeur visuel pour definir les probabilites de transition entre statements.
- Sauvegarde
.prgram— format de fichier propre au projet.
Stack technique¶
Cargo.toml (workspace root)
├── prime-radiant-core/ # Lib Rust (modeles, validation, serialisation) — zero dep UI
└── prime-radiant-app/ # Tauri v2
├── src/ # Backend Rust (IPC, etat, undo/redo)
└── frontend/ # SPA Svelte 5
Multi-plateforme : Linux (.deb, .AppImage), Windows (.msi), macOS (.dmg).
Analyse critique¶
Ce qui est solide : - La separation core Rust (lib pure) / app Tauri est propre. Le core peut etre reutilise sans l'UI — en CLI, en pipeline CI, en serveur. - ChaCha8 pour le PRNG est un bon choix : deterministe, rapide, cryptographiquement inspire (pas necessaire ici, mais garantit une distribution uniforme sans biais). - La propagation de variables entre transitions est le vrai differenciateur vs QuickCheck/Hypothesis. Ca permet de modeliser des sessions stateful : un user_id persiste a travers une saga entiere, simulant un vrai parcours utilisateur. - Le drag-and-drop visuel abaisse le cout d'entree pour definir les grammaires — c'est souvent le frein du property-based testing. - Rust + Tauri + Svelte : stack moderne, performante, legere. Pas d'Electron.
Ce qui est a nuancer : - 7 commits, 28 mars 2026 — c'est tres jeune. Le projet est fonctionnel mais pas encore battle-tested. - Le format .prgram est proprietaire. Pas d'export vers des formats standards (JSON schema, Protocol Buffers, etc.) pour l'instant. - L'interface visuelle est un avantage pour l'exploration, mais pour l'integration CI/CD il faudra un mode CLI headless. Le core Rust le permet en theorie.
Pertinence ProbatioVault — generation adversariale de contre-exemples¶
Lien direct avec la reflexion sur la verification formelle (cf. fiche David Silver / AlphaProof) :
Le pipeline ProbatioVault-formal a un probleme identifie : le risque de tautologie. Les proprietes extraites du code (extract-facts.py) peuvent re-decrire le code au lieu de le confronter aux normes. Le solveur dit "vrai" parce que le modele dit la meme chose que le code.
La solution evoquee : une phase de generation adversariale de contre-exemples — produire des scenarios ou le code DEVRAIT echouer, puis verifier que le modele formel les detecte.
Prime Radiant est exactement l'outil pour cette phase :
| Etape pipeline formal | Aujourd'hui | Avec Prime Radiant |
|---|---|---|
| Extraction de faits | extract-facts.py (AST + normes) | Inchange |
| Proprietes | Invariants TLA+/Alloy/Prolog | Inchange |
| Validation | Solveur verifie les proprietes | Solveur verifie + Prime Radiant genere des contre-exemples |
| Detection tautologie | Manuelle (revue humaine) | Automatique : si le modele ne detecte pas les violations generees, les proprietes sont trop faibles |
Exemple concret pour la norme NF Z42-013 (archivage electronique) :
- Tokens : constantes
{DEPOT, CONSULTATION, DESTRUCTION, EXPIRATION}, variables{user_id: string, doc_id: uuid, retention_days: int[1..3650]} - Statements :
DEPOT user_id doc_id(nominal),DESTRUCTION doc_id(sans bordereau — violation),CONSULTATION doc_id(apres expiration — violation) - Scenarios : graphe ou apres
DEPOT, la transition versDESTRUCTIONsans bordereau a un poids de 0.1 (cas limite surpondere) - Propagation :
doc_idpropage entre DEPOT et CONSULTATION (meme document),user_idpropage dans toute la saga (meme session) - Generer 10 000 sagas avec une seed fixe
- Verifier que le modele TLA+ detecte toutes les violations (destruction sans bordereau, consultation apres expiration, etc.)
- Si le modele ne detecte pas certaines violations → les proprietes sont tautologiques
Le seed ChaCha8 garantit la reproductibilite : si une saga echoue au model checking, on peut la rejouer pour debugger le modele formel.
C'est du model checking adversarial assiste par grammaire — plus rigoureux que la generation de contre-exemples par LLM (qui peut produire des cas triviaux ou invalides syntaxiquement), et plus cible que du fuzzing pur (qui ne connait pas la semantique metier).
Prochaines etapes : - Tester le core Rust en mode lib (sans UI) pour l'integrer dans le pipeline verify-norm.sh - Definir les grammaires pour les 10 normes ProbatioVault (iso-14641, nf-z42-013, pv-anchor, etc.) - Discuter avec @Akanoa de la possibilite d'un export CLI / JSON pour l'integration CI