Créer une application de certificat d’origine.

Exécute toute cette spécification comme une tâche liée : Grill → Plan → Goal → Review. Lis d’abord le document entier et inspecte seulement ce qui est autorisé.

• Grill: questions ciblées uniquement sur conflits importants ou prérequis manquants, à résoudre avant le plan.
• Plan: plan complet sans modification de fichiers, puis ARRÊT jusqu’à mon approbation explicite.
• Goal: après approbation seulement, réalise le périmètre convenu par jalons vérifiés.
• Review: examine sans modifier chaque exigence et rapporte des constats priorisés avec preuves. Demande une autorisation pour des corrections hors périmètre approuvé. Livrer une application fonctionnelle n’annule jamais l’approbation du plan. Les instructions détaillées des quatre étapes figurent à la fin de ce même prompt.

Ce sont des styles de consigne portables, pas des modes universels. Un prompt ne change ni le mode réel ni les permissions de votre agent. Sélectionnez séparément un mode natif si votre agent en propose un.

Construis l’application de certificat d’origine (COO) décrite ci-dessous : persistance réelle, migrations, gestion des référentiels, opérations documentaires sécurisées, interface SOKit UI complète, pièces protégées, notifications localisées, certificat exemple et tests d’acceptation automatisés. Ne te limite pas à une maquette, un CRUD générique, un squelette ou un plan. Présente d’abord le plan, puis exécute-le après mon approbation. Ces exigences définissent le périmètre de l’exemple ; ne demande pas à l’utilisateur de les inventer. Pose des questions uniquement sur les conflits réels, dépendances indisponibles ou décisions bloquantes.

Modélise la structure métier avec l’exportateur et les autres parties, des références distinctes de demande et de délivrance, le transport et les marchandises, un examinateur affecté, la correspondance visible du demandeur et des notes internes à accès restreint. Les limites, numérotations, droits et cycle simplifié ci-dessous sont des règles pédagogiques délibérées, pas des exigences légales. Exclus paiements, annulation, réémission, signatures officielles, sceaux et intégrations de certification externes. Le résultat n’est jamais un certificat juridiquement valide.

Examine d’abord le dépôt et ses fichiers d’instructions. S’il ne contient que métadonnées ou documentation, découvre les structures d’application prises en charge et propose un monorepo avec l’UI, les services, contrats partagés, tests et configurations de déploiement nécessaires avant de créer des fichiers. Si une application existe, préserve sa topologie et ses conventions, trouve les composants responsables et étends-les sans créer une autre application ni remplacer la configuration racine. Si le projet est incompatible, explique pourquoi et demande une décision de migration avant toute restructuration.

Utilise SMART pour découvrir le profil de framework applicable et charger les instructions pertinentes à la révision renvoyée. Respecte les contrats SOKit et SOKit UI, les dépendances explicites du monorepo et les conventions Quarkus du projet pour injection, validation, persistance, transactions, configuration et tests. Réutilise les contrats générés et les outils épinglés ; n’invente pas d’API, ne copie pas d’anciens fichiers de build et ne change pas silencieusement les versions. Signale les instructions, accès ou dépendances manquants. Utilise des données fictives et aucun secret dans les exemples.

Dépôt vide : utilise un scaffold pris en charge pour créer un seul monorepo. Identifie les composants propriétaires de l’interface, du service COO, des référentiels, des contrats générés partagés, des tests d’intégration/de bout en bout et du déploiement local. Plusieurs capacités peuvent partager un service si le scaffold le permet ; ne crée pas un microservice par table. L’interface dépend des contrats publics, les services de leurs composants métier/persistance ; les bibliothèques partagées ne dépendent pas de l’application. Les commandes racines orchestrent les compilations et contrôles.

Application existante : étends ces propriétaires en place, en préservant gestionnaire de paquets, compilation, routes, authentification et frontières. Ne crée pas une deuxième application et ne remplace pas les fichiers racines. Projet incompatible : explique pourquoi et demande une décision de migration avant restructuration. Livre carte d’architecture, schéma/migrations, DTO et contrats générés pris en charge, écrans/opérations, traductions, fixtures, tests, exemple de variables sans secrets, démarrage local et matrice exigences/tests. Découvre la révision et le profil SMART applicables et leurs contrats SOKit/SOKit UI/Quarkus actuels ; les noms logiques de ce document ne sont pas des API inventées.

Authentification obligatoire, sauf à l’entrée de connexion. Résous organisation demandeuse, organisme émetteur et éligibilité du personnel depuis l’identité et les appartenances fiables. N’accepte jamais depuis les champs modifiables du demandeur les propriétaires, rôles, examinateur, état, références métier ou acteurs d’audit. Agir pour un exportateur exige un mandat vérifié côté serveur ; dans les fixtures, l’organisation demandeuse est l’exportateur.

Implémente ces droits logiques avec le système d’autorisation existant. Demandeur : créer, rechercher, lire, modifier et soumettre les dossiers d’une organisation où son appartenance demandeur est active. Examinateur : lire les dossiers qui lui sont affectés dans son organisme émetteur, puis retourner, approuver ou rejeter à l’état SUBMITTED. Superviseur : consulter la file de cet émetteur et affecter/réaffecter un examinateur éligible avec motif obligatoire ; ce rôle seul ne permet pas de décider. Agent émetteur : délivrer les dossiers APPROVED de son organisme. Administrateur de référentiels : gérer les catalogues, sans accès documentaire implicite. Les agents autorisés lisent les notes internes uniquement dans leur périmètre ; un demandeur ne les voit jamais sur son propre dossier, même avec un autre rôle.

Interdis auto-examen et auto-délivrance : le décideur n’est ni le créateur ni un membre demandeur de l’organisation propriétaire. L’émetteur est également distinct de l’approbateur. Vérifie permission ET périmètre côté serveur sur recherche, lecture, découverte d’actions, mutations, historique, correspondance, sorties et téléchargements. Un examinateur non affecté ne découvre pas les dossiers d’un autre. Applique uniformément la convention existante de refus sans divulgation. Teste URL directes et requêtes falsifiées, pas seulement les boutons masqués.

Rattache chaque organisation demandeuse à son organisme émetteur par configuration serveur fiable ; refuse la création sans routage autorisé. L’éligibilité du personnel inclut appartenance active, permission d’opération et toutes les règles de séparation des tâches. Vérifie-les à la résolution des examinateurs et émetteurs par défaut comme à l’exécution.

Utilise l’identité documentaire versionnée et expectedVersion pris en charge. L’agrégat contient documentId immuable, version, state, ownerOrganizationId/createdBy/createdAt/updatedAt fiables, issuingOrganizationId, assignedReviewerId, submittedAt, resubmissionCount initialisé à 0, approvedBy/approvedAt, requestReference/requestDate, issuanceReference/issuedAt et validFrom/validUntil. Instants en UTC, dates métier sans heure ; fuseau de l’émetteur configurable, UTC pour la démo. Réserve les champs serveur à des DTO d’opération restreints, sans affectation massive.

Instantanés exportateur et destinataire : identifier (1–64 caractères), legalName (1–200), address (1–500), référence pays, contactName facultatif (200 maximum), email facultatif valide (254 maximum), téléphone facultatif (32 maximum). Les deux parties sont obligatoires à la soumission. Parties supplémentaires : collection ordonnée, ID de ligne stable, rôle BROKER ou NOTIFY_PARTY et mêmes champs ; au plus 10, sans doublon rôle/identifiant. Distingue ces instantanés commerciaux de l’identité du demandeur. L’identité de l’émetteur vient de la configuration fiable.

Obligatoires à submit/resubmit : pays d’origine, de destination et de destination finale, mode, date prévue d’exportation, lieux de chargement, déchargement et déchargement final. Les lieux appartiennent respectivement à ces trois pays ; destination et destination finale peuvent être identiques. SEA exige vesselName, ROAD vehicleRegistration, AIR flightNumber, RAIL trainReference (100 caractères maximum chacun) ; les autres champs de mode sont facultatifs et omis de la sortie s’ils sont vides. La date d’exportation est au moins la date métier de submit/resubmit ; ne réapplique pas cette règle de date future lors de l’examen ou de la délivrance.

Crée neuf catalogues : pays ; lieux avec pays parent ; modes de transport ; emballages ; unités supplémentaires ; devises avec précision des unités mineures ; classifications de marchandises ; critères d’origine ; types de pièces. Chaque ligne : code stable (1–32), libellés EN/FR/ES/AR (1–200), indicateur actif, dates facultatives inclusives validFrom/validTo, version. Code unique par catalogue, immuable après création ; fin non antérieure au début. Une ligne référencée se désactive, sans suppression physique. Une nouvelle soumission exige des références actives et valides à cette date.

Fournis recherche paginée code/libellé, filtres actif/validité, libellés traduits avec repli documenté, écrans créer/modifier/désactiver réservés aux administrateurs. Les utilisateurs authentifiés lisent les catalogues applicables. Filtre les lieux selon le pays sélectionné. Stocke des instantanés code/libellé dans les versions pour préserver le sens historique après renommage ou désactivation. Revalide corrections et resoumissions sans invalider rétroactivement un certificat délivré.

Fixtures clairement fictives préfixées DEMO pour pays, lieux, unités, devises et classifications ; comportements SEA/ROAD/AIR/RAIL ; types INVOICE et ORIGIN_EVIDENCE ; critères pédagogiques DEMO_WHOLLY_OBTAINED et DEMO_VALUE_CONTENT. Le second exige percentageExportPrice, le premier l’interdit. N’invente pas des tarifs ou règles d’origine officiels. Les imports réels attendent une source autorisée et sa licence.

Conserve 1–100 lignes ordonnées : ID stable distinct de sequenceNumber, classification, commercialDescription (1–255), marksAndNumbers (1–255 ; valeur explicite NO MARKS si absent), packageType, packageCount entier positif, supplementaryQuantity et unité, grossWeightKg, netWeightKg, originCriterion, percentageExportPrice conditionnel, invoiceReference (1–64), invoiceDate, invoiceCurrency et invoiceValue. Tout est obligatoire à submit/resubmit sauf le pourcentage conditionnel. Séquences uniques et consécutives ; réordonner préserve les ID.

Calculs décimaux, jamais en virgule flottante binaire. Quantités/poids strictement positifs, trois décimales au plus ; poids net ≤ brut. Valeur de ligne positive, précision décimale 18, échelle de 0–3 selon la devise ; rejette la précision excessive sans arrondi silencieux. Pourcentage décimal de 0 à 100 inclus, deux décimales maximum : requis pour DEMO_VALUE_CONTENT, absent pour DEMO_WHOLLY_OBTAINED. Préserve zéro. Date de facture ≤ date métier de submit/resubmit et ≤ date d’exportation.

Totaux en lecture seule par devise : somme des valeurs allouées à chaque ligne, pas répétition du montant global de facture. Même référence/date de facture implique même devise. Affiche séparément colis et poids ; n’additionne pas les quantités d’unités différentes et ne convertis pas implicitement les devises. Les brouillons incomplets respectent déjà types, limites et cohérence numérique ; complétude et dates de soumission se contrôlent à submit/resubmit. Erreurs localisées par ligne/champ, sans perdre la saisie valide.

États persistés exacts : DRAFT, SUBMITTED, RETURNED, APPROVED, REJECTED, FINALIZED (affiché Délivré). L’examen est une activité sur SUBMITTED. Actions issues des contrats documentaires, jamais champ status modifiable. Toute mutation exige expectedVersion courant ; autorisation, validation, transition et historique partagent une transaction. Pour CREATE_DRAFT, utilise le contrat de création initiale pris en charge au lieu d’exiger une version documentaire antérieure.

CREATE_DRAFT

aucun dossier → DRAFT ; Demandeur ; parties/expédition/marchandises/pièces potentiellement incomplètes.

SAVE_DRAFT

DRAFT → DRAFT ; Demandeur propriétaire ; mêmes champs.

SUBMIT

DRAFT → SUBMITTED ; Demandeur propriétaire ; complétude, références et pièces valides ; attribue référence/date de demande et submittedAt à la première soumission. Résous l’examinateur par défaut configuré de l’émetteur parmi le personnel actif éligible ; sinon échoue clairement sans commit. Le demandeur ne choisit ni ne falsifie cet acteur.

RETURN

SUBMITTED → RETURNED ; Examinateur affecté ; motif public de 10–2000 caractères, note interne facultative jusqu’à 4000, sans modification commerciale.

SAVE_CORRECTION

RETURNED → RETURNED ; Demandeur propriétaire ; données modifiables, règles souples du brouillon.

RESUBMIT

RETURNED → SUBMITTED ; Demandeur propriétaire ; validation complète, résumé public des corrections de 10–2000 ; incrémente resubmissionCount, préserve référence/date de demande et l’examinateur s’il reste éligible, sinon résous le défaut éligible.

APPROVE

SUBMITTED → APPROVED ; Examinateur affecté ; validFrom/validUntil, commentaire public et note interne facultatifs ; revalide champs requis et pièces, sans la règle de date future propre à la soumission ; mémorise acteur/date.

REJECT

SUBMITTED → REJECTED ; même acteur ; motif public obligatoire de 10–2000 et note interne facultative.

REASSIGN

SUBMITTED → SUBMITTED ; Superviseur de l’émetteur ; ID d’examinateur éligible et motif interne de 10–2000 ; historique restreint avec anciens/nouveaux acteurs. Aucun droit de modifier les données commerciales.

ISSUE

APPROVED → FINALIZED ; Agent émetteur respectant la séparation des tâches ; aucune donnée commerciale modifiable ; valide instantané approuvé et validité, attribue référence/date de délivrance et fige l’instantané atomiquement. Aucun retour, modification, suppression, annulation ou réémission depuis APPROVED, REJECTED ou FINALIZED dans ce périmètre. Préserve les versions antérieures. Rejette mutations périmées/rejouées avec conflit récupérable et état courant autorisé ; ni transition, ni numéro, ni notification en double. Une seule délivrance concurrente réussit.

Référence serveur COO-REQ-{year}-{six-digit-sequence} à la première soumission réussie, unique par organisme émetteur/année. COO-ISS-{year}-{six-digit-sequence} uniquement à la délivrance, séquence distincte et même portée d’unicité. Allocation atomique en base et contraintes uniques ; jamais comptage des lignes ni numéros du client. Les trous sont acceptables. Dates selon le fuseau métier de l’émetteur ; les références ne sont ni clés primaires ni justificatifs d’accès.

Règle de démo : validFrom ≥ date métier d’approbation ; validUntil = validFrom + 89 jours, soit 90 jours calendaires inclusifs. Début par défaut : date d’approbation. La date de délivrance doit appartenir à cet intervalle ; une approbation expirée ne peut être délivrée et sa correction est hors périmètre. Ce n’est pas une règle juridique universelle.

Livre aperçu accessible et PDF exemple téléchargeable protégé depuis l’instantané délivré immuable. Mention visible EXEMPLE — CERTIFICAT NON OFFICIEL ; références/dates de demande et délivrance, validité, émetteur, exportateur, destinataire, expédition, marchandises et totaux par devise ; aucune note interne ni coordonnées privées. Avant délivrance : aperçu explicitement brouillon, sans numéro de délivrance, sans transition. Un échec de rendu après délivrance se réessaie sans nouvelle délivrance ni nouveau numéro. Réutilise le rendu pris en charge ; signale une dépendance indisponible, pas un faux bouton de téléchargement.

Sépare correspondance publique et notes internes dans les modèles enfants et projections. Chaque entrée : ID immuable, lien document/version, auteur/date fiables, texte brut et contexte d’opération. Motifs de retour/rejet et résumés de correction sont publics pour le demandeur. Notes internes réservées au personnel émetteur autorisé, exclues des DTO demandeur, historique public, recherches, notifications, journaux et sorties. Ajouts seulement, sans modification/suppression silencieuse. Ajoute les messages via les opérations spécifiées, sans inventer une messagerie distincte.

Pièce : ID de ligne stable, identité bucket authentique, type, nom/MIME/taille vérifiés, auteur/date et version. Utilise le flux bucket et le mapping pris en charge ; distingue ID local UI, ID persistant et ID fichier. Vérifie réponses et propriété côté serveur. PDF/JPEG/PNG, 10 Mio par fichier, 10 pièces maximum ; rejette fichiers vides et contenu incompatible via validation serveur, pas la seule déclaration MIME du navigateur. Intègre le scanner requis par la politique de stockage et bloque les fichiers en attente/rejetés à la soumission.

Au moins une INVOICE et une ORIGIN_EVIDENCE à submit/resubmit et approve. Seul le Demandeur propriétaire en DRAFT/RETURNED ajoute ou retire des pièces. Téléchargement soumis à l’accès parent/version, récupération autorisée temporaire, jamais URL publique. Préserve tout fichier référencé historiquement. Nettoyage des uploads temporaires non attachés après 24 heures, avec vérification de toutes les références courantes/historiques. Progression/réessai visibles et saisie conservée après échec d’upload ou d’enregistrement.

Modèles EN/FR/ES/AR ; destinataires résolus côté serveur, liens authentifiés. Submit/resubmit → examinateur affecté. Return/reject → compte du demandeur ayant soumis. Approve → agent émetteur éligible configuré et demandeur informé Approuvé, en attente de délivrance. Issue → demandeur, exemple disponible. Reassign → nouvel examinateur. Une configuration de personnel requise manquante bloque l’opération avant commit ; aucune adresse arbitraire dans les entrées.

Insère une outbox durable dans la transaction documentaire. Le worker ne délivre que les entrées validées, vers un récepteur local en développement. Clé événement unique : document, version validée, type, destinataire. Réessaie les échecs temporaires après 1, 5 et 30 minutes, puis marque en échec pour inspection et relance explicite. Livraison au moins une fois, déduplication si disponible, aucune promesse exactement une fois. L’échec de livraison n’annule pas l’opération validée ; rollback ne produit aucune notification livrable.

Audite chaque opération réussie : document/version, ancien/nouvel état, acteur authentifié, date et métadonnées sûres. Sépare affectation/notes restreintes de la chronologie demandeur. Journalise refus et échecs sans fichiers, secrets ni notes privées. Vérifie l’autorisation pour chaque version historique et chaque sortie.

Utilise les composants et le langage visuel SOKit UI de l’application. Espace demandeur : Créer une demande ; tableau paginé référence, exportateur, destination, état, dernière modification, référence de délivrance ; filtres texte/référence, état, dates ; tri récent par défaut. États vide, chargement, erreur et réessai utiles. Sur téléphone, cartes lisibles conservant actions et statut.

Espace émetteur : Mes demandes affectées ; file d’affectation uniquement pour superviseurs ; Approuvées à délivrer pour agents émetteurs éligibles. Colonnes demande, demandeur/exportateur, date de soumission, état, examinateur ; filtres état/date/examinateur selon droits. Liens vers le vrai document autorisé. Ne rends pas tous les espaces à tous les rôles avec de simples boutons désactivés.

En-tête documentaire : état, références, version, dernière modification et actions autorisées par le serveur. Rail de sections sur bureau, sélecteur mobile : Parties, Expédition, Marchandises, Pièces, Correspondance, Historique ; Notes internes seulement si autorisé. Totaux et résumé de validation accessibles. Parties : blocs exportateur/destinataire et répétiteur facultatif. Expédition : sélecteurs pays/lieux dépendants et champs par mode. Marchandises : tableau récapitulatif et éditeur de ligne accessible ajout/modification/retrait/réordre, décimales et totaux par devise. Pièces : type/taille/progression et actions autorisées.

Enregistrer le brouillon et Soumettre sont distincts. Dossier retourné : motif, corrections modifiables et résumé obligatoire avant Resoumettre. Dialogues Retourner/Rejeter : motif public obligatoire séparé de la note interne facultative. Approbation : résumé métier en lecture seule, validité, confirmation explicite. Délivrance : données approuvées, validité et confirmation ; bloque doubles clics en cours sans remplacer la concurrence serveur. Délivré/Rejeté en lecture seule. Avertis avant perte de modifications. Conflit de version : conserve la tentative, explique, propose rechargement/réconciliation sans écrasement automatique.

Traduis complètement EN/FR/ES/AR : libellés, validation, états, interface de correspondance, notifications. Préserve le texte métier saisi. Notifications dans la langue préférée du destinataire ; dates/nombres selon langue UI. Arabe RTL avec identifiants LTR isolés et actions ordonnées correctement. Sortie exemple dans la langue choisie, codes/valeurs historiques préservés.

Vérifie 360, 768 et 1440 px : une colonne sur mobile, regroupements pertinents sur bureau, aucun débordement ni élément collant couvrant saisie/actions. Clavier, focus visible, libellés descriptifs, annonce des erreurs, focus sur résumé et retour du focus après dialogue. Statut non fondé sur la seule couleur. Distingue erreurs de permission, réseau, upload et validation sans perdre la saisie.

Applique les contrats SMART actuels pour opérations/groupes de validation, DTO générés, sécurité par dossier, références, bucket et notifications. Quarkus selon profil : CDI, persistance, propriété des transactions, configuration, validation et tests ; pas de dérive de versions, dépendances non gérées, entités en entrée publique ou API inventées. Migrations avec contraintes/index, pagination bornée et chargements intentionnels sans N+1. Secrets hors dépôt, données personnelles hors journaux, protections authentification/CSRF/origines adaptées au projet.

Crée Demo Chamber, Demo Export Ltd demandeur/exportateur, Demo Import Ltd destinataire et une autre organisation demandeuse sans lien. Identités séparées demandeur, examinateur affecté, autre examinateur, superviseur, agent émetteur, administrateur via fixtures d’authentification locale prises en charge, jamais identifiants de production. Expédition valide à deux lignes, neuf catalogues et pièces inoffensives ; horloge de test contrôlée.

Automatise : brouillon incomplet → enregistrement → parties/transport/deux lignes/pièces complétés → soumission avec une référence → retour avec motif public et note privée → demandeur ne voit que le motif → correction/enregistrement/resoumission, même référence, compteur 1 → approbation pour 90 jours → délivrance unique par agent distinct → PDF filigrané depuis l’instantané figé. À chaque étape vérifie état/version/acteur/historique/actions/outbox. Couvre aussi le rejet terminal.

Tests négatifs : chaque combinaison rôle/état ; propriétaire/examinateur falsifiés ; accès inter-organisations aux lectures/recherches/historique/fichiers ; examinateur non affecté, auto-examen, même approbateur/émetteur ; fuite de notes ; références inactives ; lieux incohérents ; champs par mode/pièces absents ; dates/précision/poids invalides ; devises multiples ; identité/réordre de lignes ; upload trop gros/falsifié ; échecs upload/enregistrement et nettoyage. Teste deux soumissions/délivrances concurrentes, modifications périmées, validité expirée, unicité, sortie immuable, rollback sans notification, réessai/déduplication, réessai de rendu sans réémission et accès direct non autorisé.

Exécute compilations, types, lint, tests backend/intégration/UI, quatre langues et trois largeurs. Livre matrice exigences/tests avec résultats réels, fichiers/composants modifiés, démarrage local, migrations/fixtures et configuration opérationnelle. Indique précisément les contrôles non exécutés et pourquoi. Un jalon est terminé quand le comportement observable fonctionne ; des mocks, scaffolds ou un plan ne sont pas une application complète.

Questionne mon cahier des charges avant l’implémentation. Identifie exigences manquantes, contradictions et hypothèses risquées. Pose une question ciblée à la fois, explique son importance et propose des alternatives utiles avec une recommandation. Couvre acteurs et propriété, champs, sources des références, transitions, validation, reprise après erreur, notifications, UI et critères d’acceptation. Sépare décisions confirmées et hypothèses. N’écris pas de code et ne décide pas silencieusement des règles métier. Termine par un journal concis des décisions et blocages restants.

Inspecte le dépôt et produis un plan complet pour le périmètre convenu sans modifier les fichiers. Cartographie modèle, références, composants responsables, interfaces, matrice états/opérations/droits, validation par opération, migrations, fichiers protégés et effets après commit. Inclus routes UI, accessibilité, comportement EN/FR/ES/AR, erreurs et tests d’acceptation. Découpe en jalons examinables et identifie les vrais points d’entrée de build et contrôle. Résous les ambiguïtés importantes avec moi avant de finaliser ; ne commence pas l’implémentation.

Implémente uniquement l’objectif et les jalons convenus avec moi. Sans périmètre ou plan approuvé, demande-le d’abord. Avance par étapes examinables : fondations et références, cycle documentaire et accès, UI, pièces jointes et notifications, puis vérification complète. Exécute les contrôles pertinents après chaque changement significatif, analyse les échecs et donne les preuves. Préserve les travaux sans rapport. Aucun déploiement, migration destructive, message externe ou fonctionnalité hors périmètre sans autorisation. Arrête-toi sur les blocages exigeant décision ou accès et explique-les ; ne prétends pas avoir exécuté un contrôle. Termine par fichiers, résultats réels et reste à faire.

Examine l’implémentation selon le cahier des charges, le plan et les instructions SMART actuelles. Ne modifie aucun fichier. Priorise exactitude, droits sur dossiers/recherches/historique/fichiers, transitions, validation, transactions, échecs de notifications, dépendances, configuration, tests, accessibilité et quatre langues. Pour chaque constat, donne fichier/emplacement, déclencheur concret, impact et correction recommandée. Distingue défauts, améliorations facultatives et preuves manquantes. Sans constat exploitable, dis-le et précise les limites de vérification ; n’invente pas de problème.