Repair¶

Status: TARGET

À quoi sert un Repair Write Service ?¶

Un Repair Write Service applique une correction ciblée sur des données déjà présentes lorsque l'anomalie a été démontrée par un audit et que la correction a été validée séparément.

Il ne découvre pas le problème et ne décide pas de la bonne règle métier. Il exécute une décision déjà établie.

Audit
  ↓
Simulation / Virtual Patch
  ↓
Validation explicite
  ↓
Repair Write Service
  ↓
Contrôles après écriture

État documentaire¶

Cette page décrit la cible d'architecture de la famille Repair.

Elle ne signifie pas qu'un service générique de réparation est actuellement actif dans le Runtime. Toute opération concrète doit être vérifiée dans le code, la CLI et les Write Services réellement présents avant exécution.

Entrées attendues¶

Une réparation doit recevoir un périmètre explicite et suffisamment borné, par exemple :

identifiants métier ;
run ou batch ;
verticale ;
feed ;
famille de cas issue d'un audit ;
paramètres de correction déjà validés ;
référence vers le rapport ayant autorisé l'opération.

Une réparation ne doit jamais sélectionner implicitement « tout ce qui semble faux ».

Ce qu'elle peut produire¶

Selon le cas, un Repair Write Service peut :

corriger une valeur persistée ;
réappliquer une règle validée sur une population historique ;
reconstruire une projection dérivée ;
remettre un enregistrement dans un état cohérent avec les invariants actuels.

Le résultat doit exposer au minimum les compteurs examined, changed, unchanged, skipped et failed, ou un modèle équivalent réconciliable.

Ce qu'elle ne doit jamais faire¶

Une réparation ne doit jamais :

inventer une règle métier ;
masquer un conflict pour améliorer un KPI ;
convertir une absence de preuve en resolved ;
modifier un périmètre différent de celui validé ;
être déclenchée par un Read Service ;
être présentée comme un audit ou un dry-run lorsqu'elle écrit réellement ;
contourner un Write Service spécialisé déjà existant.

Sécurité opérationnelle¶

Avant une réparation réelle, vérifier :

le périmètre exact ;
la sauvegarde ou la stratégie de retour arrière ;
le résultat du dry-run lorsqu'il existe ;
les KPI avant intervention ;
les invariants concernés ;
la commande et le service réellement appelés.

Après écriture, relancer l'audit qui a motivé la correction. Une baisse du nombre d'erreurs techniques ne suffit pas : les statuts unknown, ambiguous et conflict doivent rester visibles lorsqu'ils sont légitimes.

Diagnostic¶

Si une réparation produit plus de lignes modifiées que prévu, arrêter l'opération suivante et vérifier d'abord :

le filtre utilisé ;
la population de départ ;
l'idempotence ;
les exclusions ;
les dépendances de projection ;
les compteurs avant/après.

Ne pas élargir le périmètre pour « finir le nettoyage » sans nouvel audit.

Tests attendus¶

Une implémentation concrète doit tester :

absence d'écriture hors périmètre ;
idempotence ;
compteurs réconciliables ;
comportement sur données déjà conformes ;
erreurs partielles explicites ;
conservation des invariants métier ;
mode dry-run réellement non destructif lorsqu'il est annoncé.

Invariants¶

La réparation est explicitement destructive ou mutative : elle n'est jamais cachée dans un outil read-only.
Elle applique une décision validée ; elle ne la fabrique pas.
Son périmètre est connu avant exécution.
Elle est traçable et mesurable.
Elle est rejouable sans duplication d'effets lorsque le contrat le permet.
Elle est suivie d'un nouvel audit de vérification.