Validation Report — CLI¶

Status: CURRENT / CONTRACT

Rôle de cette page¶

Cette page décrit le rôle opérationnel du Validation Report dans un cycle CLI.

Le contrat conceptuel de référence reste :

Validation Reports — Read Services

Le rapport final n'est pas un résumé décoratif. C'est l'artefact qui rassemble les preuves nécessaires pour décider si une évolution peut être acceptée, refusée, différée ou limitée à un périmètre donné.

Quand produire un Validation Report¶

Le rapport intervient après les observations utiles :

Baseline
    ↓
Audits
    ↓
Simulation / Virtual Patch si nécessaire
    ↓
Remaining Audit
    ↓
Validation Report
    ↓
Décision explicite

Un rapport peut conclure à l'absence de changement. Il ne sert pas uniquement à autoriser une mutation.

Ce qu'il doit permettre de répondre¶

Un mainteneur qui ne connaît pas l'historique doit pouvoir déterminer :

Quel problème a été étudié ?
Quel périmètre et quelles versions ont été utilisés ?
Quelles preuves ont été produites ?
Quels cas restent unknown, ambiguous ou conflict ?
Qu'est-ce qui a réellement été modifié, s'il y a eu écriture ?
Quels garde-fous ont été vérifiés ?
Quels risques restent ouverts ?
Quelle décision a été prise et pourquoi ?
Comment reproduire la vérification ?

Contenu minimum attendu¶

Un rapport exploitable doit conserver au minimum :

contexte et objectif ;
date du run ou de l'analyse ;
révision Git ;
version Runtime/plugin si distincte ;
feed, verticale, run ou échantillon ciblé ;
baseline utilisée ;
commandes et paramètres significatifs ;
KPI et compteurs avant/après ;
reason codes ou familles d'écarts ;
distribution resolved / unknown / ambiguous / conflict lorsque pertinente ;
régressions recherchées ;
cas résiduels ;
effets techniques éventuels des simulations ;
écritures réellement appliquées ;
stratégie de reprise/rollback lorsque pertinente ;
résultat de la vérification post-écriture ;
décision finale et justification.

Décisions possibles¶

Le rapport doit conclure explicitement, par exemple :

validé ;
validé avec réserves ;
non validé ;
aucune mutation nécessaire ;
mutation reportée ;
audit complémentaire requis ;
rollback requis.

Éviter les conclusions floues comme « ça semble bon » ou « amélioration globale ».

KPI : ce qu'ils prouvent et ce qu'ils ne prouvent pas¶

Un KPI agrégé n'est jamais suffisant à lui seul.

Une hausse de succès peut cacher :

des conflits forcés ;
des ambiguïtés supprimées artificiellement ;
des cas inconnus convertis sans preuve ;
une régression sur une famille minoritaire mais critique.

Le rapport doit donc combiner métriques globales et exemples représentatifs.

Résultats résiduels¶

Les cas encore présents à la fin du cycle doivent être classés explicitement :

bloquants ;
acceptés ;
connus et différés ;
hors périmètre ;
nécessitant une investigation séparée.

Le fait qu'il reste des différences n'implique pas automatiquement un échec. Ce qui importe est qu'elles soient comprises et qu'une décision documentée existe.

Écriture réelle¶

Si une mutation a été appliquée, le rapport doit séparer :

Décision validée
        ↓
Write Service / action explicite
        ↓
Persistance
        ↓
Rebuild si nécessaire
        ↓
Audit post-écriture
        ↓
Résultat final

Le rapport ne doit jamais faire croire qu'une simulation a écrit réellement.

Validation d'une projection¶

Lorsque le résultat concerne une projection :

vérifier que la source amont utilisée est correcte ;
vérifier que le rebuild attendu a réellement eu lieu ;
comparer sur une projection fraîche ;
ne pas utiliser une baseline historiquement contaminée sans le signaler.

Traçabilité des commandes¶

Les commandes utilisées comme preuve doivent être reproductibles depuis l'environnement prévu.

Convention du VPS, lorsque la commande existe réellement :

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

Avant de documenter une commande comme CURRENT, vérifier son aide avec wp help ou son enregistrement via parsing de wp cli cmd-dump --format=json.

Garde-fous¶

Le Validation Report ne doit jamais :

masquer les différences résiduelles ;
présenter une intuition comme une preuve ;
confondre simulation et mutation ;
considérer un KPI global comme validation suffisante ;
omettre les cas unknown / ambiguous / conflict pertinents ;
omettre une régression connue ;
déclarer un rollback possible sans procédure vérifiable ;
déclarer une commande ou un service actif sans l'avoir vérifié.

Checklist de fin¶

Avant de conclure :

[ ] périmètre identifié ;
[ ] révisions identifiées ;
[ ] baseline reproductible ;
[ ] compteurs réconciliés ;
[ ] cas incertains visibles ;
[ ] régressions recherchées ;
[ ] écritures séparées des simulations ;
[ ] vérification post-écriture réalisée si nécessaire ;
[ ] risques résiduels documentés ;
[ ] décision explicite.