Aller au contenu

Candidate Dump — CLI

Status: CURRENT / CONTRACT

Rôle

Le Candidate Dump est une vue de diagnostic détaillée des candidats considérés lors d'une résolution.

Il sert à comprendre le raisonnement, pas à corriger les données.

Références conceptuelles :

Quand l'utiliser

Utiliser un Candidate Dump lorsqu'un audit a déjà isolé un cas ou une famille de cas et qu'il faut comprendre :

  • quels candidats existent réellement ;
  • quelles évidences sont associées à chacun ;
  • pourquoi un candidat a été retenu, rejeté ou laissé en concurrence ;
  • si l'ambiguïté vient de la génération des candidats ou du Resolver ;
  • si un conflit est légitime ou provient d'une donnée source dégradée.

Le dump n'est pas un outil de découverte globale à utiliser à l'aveugle sur tout le catalogue.

Entrées recommandées

Un dump doit être lié à un contexte reproductible :

  • identifiant source (EAN, SKU, MPN, identifiant marchand, etc.) ;
  • run ou feed si nécessaire ;
  • verticale ;
  • révision du code ;
  • échantillon ou cas issu d'un audit préalable.

Sortie attendue

Selon le moteur observé, la sortie doit rendre visibles autant que possible :

  • candidats générés ;
  • origine des candidats ;
  • évidences disponibles ;
  • scores, niveaux de confiance ou signaux ;
  • reason codes ;
  • éléments favorables/défavorables ;
  • candidat retenu lorsqu'un résultat resolved existe ;
  • raisons d'un résultat unknown, ambiguous ou conflict.

Un score élevé n'est pas une preuve de vérité métier à lui seul.

Important : dump courant vs décision historique

Un Candidate Dump rejoué aujourd'hui montre ce que la version actuelle du code et les données actuelles produisent.

Il ne prouve pas automatiquement ce qui s'est passé lors d'un ancien run.

Pour analyser historiquement une décision, il faut disposer du contexte correspondant :

  • version de code ;
  • données ou snapshot ;
  • configuration ;
  • paramètres ;
  • run concerné.

Sans cela, présenter le dump courant comme preuve historique serait incorrect.

Lecture opérationnelle

Questions utiles :

  1. Le candidat attendu existe-t-il ?
  2. Les évidences permettant de le distinguer existent-elles ?
  3. Un candidat bruité ou trop générique domine-t-il le classement ?
  4. Le problème vient-il de la donnée source, de la normalisation, de la génération de candidats ou du Resolver ?
  5. Le statut final conserve-t-il correctement l'incertitude ?

Position dans le workflow

Audit
    ↓
Cas ciblé
    ↓
Candidate Dump
    ↓
Hypothèse
    ↓
Virtual Patch éventuel
    ↓
Virtual Candidates Dump
    ↓
Validation

Vérifier la commande

La documentation de cette page ne prouve pas qu'une commande portant exactement ce nom est enregistrée dans le Runtime actuel.

Avant usage :

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

ou parser :

docker compose exec platform-worker wp --allow-root --path=/var/www/html cli cmd-dump --format=json

Garde-fous

Le Candidate Dump doit rester en observation métier. Il ne doit pas :

  • modifier les candidats persistés ;
  • appliquer une résolution ;
  • déclencher une synchronisation ;
  • reconstruire implicitement une projection ;
  • masquer unknown / ambiguous / conflict ;
  • servir seul de justification à un patch réel.

Si l'implémentation de la commande crée un artefact technique temporaire, cet effet doit être explicitement documenté et ne doit pas être confondu avec une mutation métier.

Diagnostic avant patch

Avant de modifier une règle :

  • comparer plusieurs cas de la même famille ;
  • vérifier la qualité des sources ;
  • chercher les reason codes communs ;
  • vérifier si le problème est générique ou vertical ;
  • produire une simulation ;
  • rechercher les régressions sur des cas voisins.

Voir aussi