catalog-audit¶

catalog-audit est la page opérateur pour les audits centrés sur les résultats visibles au niveau catalogue, projections et cohérence de restitution.

Cette page reste volontairement pratique. Elle ne redéfinit ni le Domain Core ni le frontend.

Rôle pratique¶

Un catalog-audit sert à vérifier que les données lues côté catalogue restent cohérentes avec les identités, projections et règles attendues.

On l'utilise en général pour :

repérer des incohérences visibles dans les listings ;
vérifier qu'une projection reste stable après une évolution read-only ;
croiser un problème front apparent avec sa cause métier probable ;
confirmer qu'un écart vient d'une projection, d'une identité ou d'un bruit source.

Quand l'utiliser¶

Utiliser catalog-audit quand :

un problème remonte depuis une vue catalogue ;
une verticale semble correcte en Core mais incohérente en restitution ;
on veut vérifier un lot de projections sans toucher au frontend ;
on prépare un diagnostic entre lecture métier et affichage.

Ce que ce type d'audit regarde¶

En pratique, il peut s'appuyer sur :

les projections existantes ;
les identités canoniques ;
les attributs utiles à l'affichage ;
les statuts de résolution ;
les écarts détectés entre sources, identité et restitution.

Ce que ce type d'audit ne fait pas¶

catalog-audit ne doit jamais :

modifier le frontend ;
corriger une projection en direct ;
patcher le pipeline ;
contourner les services de lecture officiels ;
écrire en base.

Lecture recommandée¶

Quand un écart catalogue apparaît, il faut d'abord répondre à cette séquence :

l'identité canonique est-elle correcte ?
la projection est-elle correcte ?
le statut de résolution a-t-il forcé une restitution prudente ?
l'écart vient-il d'un bruit source ou d'une règle métier ?

Position dans le workflow¶

Le catalog-audit complète souvent :

un real-sample-comparison
un difference-family-audit
un validation-report

Il est utile quand on veut faire le lien entre logique read-only et rendu catalogue, sans toucher au frontend.