Catalog Audit¶

Statut¶

CONTRACT / GUIDE OPÉRATEUR

Cette page décrit le rôle attendu d'un audit de catalogue. Elle ne prouve pas qu'une commande WP-CLI littérale nommée catalog-audit est enregistrée dans le Runtime courant.

Avant toute exécution, vérifier la commande réellement disponible avec :

docker compose exec platform-worker wp --allow-root --path=/var/www/html help ccx

ou avec l'aide de la sous-commande concernée.

Pourquoi cet audit existe¶

Un problème visible dans un listing, une fiche ou une navigation ne signifie pas forcément que le Frontend est fautif.

Le rôle d'un Catalog Audit est de vérifier la chaîne de lecture avant de modifier l'interface :

source / état amont
    ↓
Canonical Identity et statut de résolution
    ↓
projection persistée
    ↓
Read Service / Reader
    ↓
Adapter WordPress
    ↓
Frontend

L'objectif est donc de localiser la première couche où l'état diverge de ce qui est attendu.

Ce qu'il doit observer¶

Selon le cas, l'audit peut comparer :

l'identité canonique ;
le statut resolved / unknown / ambiguous / conflict ;
les attributs consolidés ;
les offres projetées ;
la projection produit ou catalogue ;
les données réellement lues par le Reader ;
le payload remis au Frontend.

Un statut prudent n'est pas une incohérence en soi. Par exemple, unknown, ambiguous ou conflict peut être le résultat correct d'un Resolver qui refuse une décision insuffisamment prouvée.

Ce que l'audit ne doit pas faire¶

Un Catalog Audit ne doit pas :

corriger une projection directement ;
modifier le Frontend pour masquer une anomalie amont ;
recalculer localement une Canonical Identity ;
transformer un cas ambiguous ou conflict en resolved pour améliorer un KPI ;
écrire en base ;
déclencher implicitement une reconstruction.

Si l'outil observé possède des effets techniques, il doit être reclassé et documenté comme tel.

Méthode de diagnostic¶

Pour un produit ou un groupe de produits précis :

Observer la restitution. Capturer l'identifiant, la page, le payload ou la projection concernée.
Lire la projection persistée. Vérifier que l'écart existe déjà avant le Frontend.
Lire le statut de résolution. Distinguer un défaut d'une décision volontairement prudente.
Comparer avec les données amont. Stage, données normalisées et évidences si nécessaire.
Identifier la première divergence. C'est cette couche qu'il faut diagnostiquer.
Ne muter qu'après preuve. Une correction réelle passe par le service ou le traitement propriétaire de l'écriture.

Cas fréquents¶

La projection est correcte, l'affichage est faux¶

Chercher dans :

le Reader ou Read Service ;
l'Adapter WordPress ;
le mapping du payload ;
le template ou renderer.

Ne pas toucher au Domain Core.

La projection est déjà fausse¶

Remonter vers :

le Builder ;
le Resolver ;
la normalisation ;
les évidences source ;
le Write Service qui a persisté la projection.

Ne pas corriger la ligne SQL à la main comme solution durable.

Le statut est `unknown`, `ambiguous` ou `conflict`¶

Vérifier les raisons et évidences avant de considérer le cas comme un défaut.

Un statut non résolu peut être précisément le garde-fou attendu.

Position dans le workflow d'audit¶

Un Catalog Audit complète utilement :

Real Sample Comparison
    ↓
Difference Family Audit
    ↓
Resolution Status Audit
    ↓
Catalog Audit ciblé
    ↓
Simulation éventuelle
    ↓
Validation Report

Il sert de pont entre la vérité métier/projection et ce qui est réellement restitué, sans attribuer trop vite le problème au Frontend.

Sortie attendue¶

Un audit exploitable doit au minimum préciser :

le périmètre lu ;
les identifiants concernés ;
les statuts de résolution ;
la couche où apparaît la divergence ;
les cas conformes ;
les cas réellement incohérents ;
les cas encore indéterminés ;
la prochaine investigation recommandée.

Un simple nombre global d'écarts n'est pas suffisant.

Garde-fous¶

Observer avant de modifier.
Une projection n'est pas la vérité métier, mais elle doit refléter fidèlement la décision amont.
Le Frontend ne corrige pas les erreurs du Core ou de la projection.
Un cas incertain reste explicitement incertain tant que les évidences ne permettent pas mieux.
La présence de cette page ne prouve pas l'existence d'une commande CLI du même nom.