@mostajs/rules-trigger-editor

Auteur : Dr Hamid MADANI [email protected] · Licence : AGPL-3.0-or-later

Éditeur + moteur de configuration ECA (Événement → Condition → Action) générique et réutilisable, façon Drupal Rules + Trigger + Workflow : un administrateur configure « quand ceci, si cela, alors fais cela » sans toucher au code. Compose les moteurs @mostajs/{rules, trigger, statemachine, workflow, graph-editor} (par injection) ; n'apporte que les registres déclaratifs, les data-selectors, la persistance de config, le demi-workflow (états / transitions / historique / planifiées) et l'éditeur hybride (graphe + formulaires). Autosuffisant (sans @mostajs/socle).

Statut : 0.0.1 (scaffold) — types + registres + selectors + schémas rte_* + RuleStore (CRUD/validate/export). Runtime (compileRule), éditeur ./client et export UPPERCASE : jalons suivants. Livrables DEVRULES #1–#3 dans docs/. API dense : llms.txt.

Concepts

• Registres déclaratifs : l'app hôte déclare son catalogue d'events / conditions / actions.
• Règle : ON event(s) → IF (arbre AND/OR/NOT) → DO (actions ordonnées, +loop).
• Data-selector : un paramètre vaut un littéral ({mode:"input"}) ou un chemin dans le contexte ({mode:"select", path:"order:customer:email"}).
• Demi-workflow (optionnel) : états + transitions config + historique exécuté + transitions planifiées.

Usage (serveur)

import {
  defineEvent, defineCondition, defineAction, RuleStore, RTE_SCHEMAS,
} from "@mostajs/rules-trigger-editor";

// 1) L'app déclare SON catalogue (runtime)
defineEvent({ key: "order.assigned", label: "Commande assignée", variables: { order: { type: "entity:order", label: "Commande" } } });
defineCondition({ key: "order.state.is", label: "L'état de la commande est…", params: { state: { type: "text", label: "État" } } });
defineAction({ key: "notify_user", label: "Notifier l'utilisateur", params: { message: { type: "text", label: "Message" } } });

// 2) Persistance (dialecte ORM injecté ; ajouter RTE_SCHEMAS au registre de schémas de l'app)
const store = new RuleStore(dialect);

// 3) Définir et valider une règle
const rule = {
  name: "auto_notify", label: "Notifier à l'assignation", active: true, weight: 0,
  on: [{ event: "order.assigned" }],
  if: { type: "and", children: [ { type: "condition", name: "order.state.is", params: { state: { mode: "input", value: "nouvelle" } } } ] },
  do: [ { type: "action", name: "notify_user", params: { message: { mode: "select", path: "order:number" } } } ],
};
const check = store.validateRule(rule);     // { ok, errors[] } — refuse events/conditions/actions inconnus
if (check.ok) await store.saveRule(rule);

// 4) Export / import portable
const json = await store.exportJson();
await store.importJson(json);

Vérification / exemple

examples/traffic-lights/ — gestion des feux d'un croisement pilotée 100 % par des règles ECA, avec le graphe des phases édité via @mostajs/graph-editor (DEVRULES §12). Headless : node examples/traffic-lights/sim.mjs (cycle + 4 assertions, invariant « jamais deux axes au vert »). Navigateur : bash examples/traffic-lights/sync-vendor.sh puis servir le dossier.

examples/rule-builder/ — éditeur ./client en action : <RuleEditor> (formulaires ON/IF/DO) + <StatesGraph> (graphe @mostajs/graph-editor) + aperçu config UPPERCASE en direct.

Architecture (composition — règle d'or)

Conditions → @mostajs/rules · Exécution + scheduler → @mostajs/trigger · États → @mostajs/ statemachine + @mostajs/workflow · UI graphe → @mostajs/graph-editor · Persistance → @mostajs/orm (DI) · Trace → @mostajs/audit. Aucune de ces capacités n'est réimplémentée.

Peers (tous optionnels sauf @mostajs/orm) : voir package.json. Tables NEUVES rte_* (pas d'ALTER).