Aller au contenu

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_id propage) avec des donnees variables (nouveau document_id a 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) :

  1. Tokens : constantes {DEPOT, CONSULTATION, DESTRUCTION, EXPIRATION}, variables {user_id: string, doc_id: uuid, retention_days: int[1..3650]}
  2. Statements : DEPOT user_id doc_id (nominal), DESTRUCTION doc_id (sans bordereau — violation), CONSULTATION doc_id (apres expiration — violation)
  3. Scenarios : graphe ou apres DEPOT, la transition vers DESTRUCTION sans bordereau a un poids de 0.1 (cas limite surpondere)
  4. Propagation : doc_id propage entre DEPOT et CONSULTATION (meme document), user_id propage dans toute la saga (meme session)
  5. Generer 10 000 sagas avec une seed fixe
  6. Verifier que le modele TLA+ detecte toutes les violations (destruction sans bordereau, consultation apres expiration, etc.)
  7. 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