Tapez une idée de fonctionnalité · l'orchestrator sélectionne d'abord des compétences dans un catalogue local (déclencheurs + niveau de risque), puis la chaîne découpe, code, teste, fuzz, audite et publie. Même idée = même déroulé (graine fixe).
C'est le miroir simplifié de la pipeline réelle (« LanceFer V4 ») qui a produit LanceDrop : 145 tests Node + 59 JVM, veto d'audit avant chaque release, artefacts construits à chaque tag.
Le squelette pédagogique d'ARIA : intents + mémoire + trace de réflexion en clair. Aucun eval (leçon apprise après l'audit), aucun réseau, tout vit dans votre page.
Ce que les deux démos ci-dessus simulent · et où ça vit pour de vrai dans les dépôts.
Un agent ne suffit pas : il faut un chef d'orchestre qui découpe, répartit, impose des contraintes (CI verte, zéro secret versionné) et re-synchronise.
L'auditeur peut BLOQUER une release, même quand tout le reste est vert. Le gatekeeper n'outrepasse jamais un veto.
Au-delà des « ça marche » : path traversal, frames malformées, races, contraste AAA. 145 + 59 tests réels dans LanceDrop.
ARIA mémorise, apprend des règles, et explique sa réflexion · un agent doit pouvoir s'expliquer, pas juste répondre.
Avant de coder, l'orchestrator choisit dans un catalogue local : chaque compétence déclare ses déclencheurs (« quand l'utiliser ») et son niveau de risque (none · safe · critical) dit l'opération immuable.
Jamais de secret, token ou mot de passe en mémoire, même demandé · toute demande d'effacement est honorée · les actions critiques exigent une confirmation explicite dans la conversation.
Le parseur arithmétique de la démo ci-contre est exactement la leçon issue de l'audit DoS de la calculatrice ARIA (AST + whitelist).
Filigrane « données fictives », historique git propre (réécrit si besoin), licence MIT, chiffres mesurés plutôt que promis.