Lot 0 bis, séquence L0-4 — Moteur de règles minimal

02/10/2026. Mise en œuvre de la séquence L0-4 du plan d’alignement, d’après la note d’amendement (AM-09, AM-10, AM-11, AM-15). Écart appliqué provisoirement : EC-098.

En bref

• Un seul moteur, volontairement simple. Il évalue des conditions à des moments définis ; il ne dessine ni n’orchestre aucun processus.
• Quatre éléments. Un dictionnaire des variables lisibles ; des points d’accroche déclarés par les modules ; des lignes de décision publiées par les packs référentiels ; six issues, de « signaler » à « bloquer ».
• Toutes les lignes vraies s’appliquent. L’issue la plus forte décide.
• Chaque ligne vraie laisse un constat. Il recopie la règle, sa version, sa source et les valeurs lues.
• Une valeur manquante ne passe jamais en silence. Une variable, un paramètre ou une date de référence manquants donnent un constat « à vérifier » (PC-07).
• Aucune règle réglementaire n’est écrite à ce stade. Les tests utilisent un pack fictif (testdata/packs/referentiel-essai).

Dictionnaire et points d’accroche

Les manifestes des modules déclarent les deux.

Module	Points d’accroche	Variables (socle minimal)
noyau	document.avant_emission, certificat.changement_statut, campagne.avant_cloture, periodique.quotidien	utilisateur.roles, fournisseur.exempte, fournisseur.certificat.statut
reception	reception.avant_validation	reception.quantite_g, reception.produit
collecte	collecte.avant_validation	–
preparation	etape.avant_validation, transformation.avant_cloture	–
commercialisation	vente.avant_expedition	–

app.variable_dictionnaire reflète les manifestes, et un test d’intégration compare les deux. Les mesures des étapes s’y ajouteront avec l’arbre d’activités des packs (L1-4).

Ligne de décision

Champ	Contenu
accroche	Un point déclaré par un manifeste
contexte	Facteurs cités et valeurs acceptées (referentiel, produit…)
condition	CEL booléenne sur le dictionnaire ; les seuils passent par param('clé')
parametres	Clés citées, résolues par le moteur de paramètres
issue	signaler, exiger_note, exiger_piece, creer_non_conformite, quarantaine, bloquer
source	Obligatoire
date_effet, date_fin, date_reference	Période d’effet, comparée à la date de l’opération, de la récolte, de la création du lot ou de l’émission du certificat (AM-11)
evaluation	locale ou serveur ; une ligne « serveur » n’est pas évaluée sur le téléphone (AM-10)
mesure	Facultative : variable constatée et paramètre attendu, pour un écart chiffré (EC-098)

app.regle_decision est en ajout seul : une ligne publiée ne se modifie plus, et une correction passe par une nouvelle version du pack. biotrace_app n’y écrit pas.

Constat

app.constat (organisation, RLS, journal) :

• résultat ecart (avec l’issue) ou a_verifier (avec le motif) ;
• valeurs lues ; valeur constatée, attendue et écart si la ligne déclare une mesure ;
• lien facultatif vers la file de contrôle (EC-091).

Il ne se modifie que par son statut :

• ouvert → justifie (note exigée), leve ou clos ;
• justifie → leve ou clos ;
• clos est final.

L’API n’a le droit de modifier que les colonnes de statut ; le déclencheur tg_constat_statut_seul refuse toute autre modification, même au rôle des migrations (constat_fige, transition_interdite, auteur_requis).

Domaine

• dictionnaire : declarations, aplatir (objet → variables pointées, limité au dictionnaire), disponibleHorsLigne.
• regles :
  • evaluerPoint(accroche, contexte, lignes) : sélection par accroche, facteurs et période d’effet, évaluation par expressions.evaluerExpression, constats ;
  • issueLaPlusForte, bloqueAction ;
  • validerLigne, utilisée à la publication (PC-06 étendu) ;
  • compilerLivret : lignes en vigueur ou à venir, applicables aux référentiels de l’organisation, avec une version qui est l’empreinte SHA-256. Le format est fixé ici ; la descente sur le téléphone viendra au Lot 3.

Publication d’un pack référentiel

publierPack reconnaît type: "referentiel" (ContenuPackReferentiel, packages/schemas). Il contrôle :

• la forme ;
• chaque ligne (validerLigne, avec le dictionnaire publié, le catalogue des facteurs, où un facteur dynamique accepte toute valeur, et les accroches des manifestes) ;
• chaque jeu de paramètres.

Puis il écrit pack (type = 'referentiel'), pack_version et regle_decision dans une transaction. Republier le même contenu ne change rien ; un contenu différent sous la même version est refusé.

En CI (AM-13, étape 3), apps/api/src/packs/validation-packs.test.ts valide chaque pack de packs/ et le pack d’essai.

Évaluation au serveur

evaluerAccroche(trx, entree) (apps/api/src/regles/evaluation.ts) est le premier appelant du moteur. Les flux l’appelleront à partir du Lot 2.

1. Si le module de l’accroche est inactif, rien n’est évalué.
2. Il lit les lignes publiées des référentiels actifs de l’organisation, pack par pack, et les compile en livret.
3. Il résout chaque paramètre cité avec parametres.resoudre, à partir de la couche du pack. C’est le premier appelant de resoudre dans l’API. Un paramètre introuvable donne un constat « à vérifier ».
4. Il évalue avec evaluerPoint (lieu serveur), écrit les constats, puis rend l’issue la plus forte.

Tests

Test	Ce qu’il vérifie
VT-REGLE-001 à 012, regles.test.ts	Toutes les lignes vraies ; référentiel absent ; condition fausse ; variable, paramètre ou date manquants ; période d’effet ; ligne « serveur » reportée sur le téléphone ; ordre des issues ; refus de validerLigne ; livret
VT-DICO-001 à 004	Aplatissement limité au dictionnaire, variable absente, déclarations, disponibilité hors ligne
db/tests/l0bis-4.sql	Ligne figée, contraintes (source, issue, dates), écriture interdite à l’API, constat : statut seul, note, auteur, transitions, lien vers un contrôle, journal, RLS
apps/api/test/regles.test.ts	Publication, republication et version figée ; lignes refusées ; écart chiffré ; issue la plus forte ; « à vérifier » ; date d’effet ; module inactif ; référentiel inactif ; statut d’un constat par l’API
gardes-modules.test.ts	Dictionnaire en base égal aux manifestes
validation-packs.test.ts	Packs du dépôt valides selon leur type