Aller au contenu

Commandes CLI

Cette page classe les commandes et workflows opérateur de CMonChoix par intention et par niveau de risque.

Elle complète overview.md et reference.md sans dupliquer toute l’architecture CLI.

Exécution canonique

Depuis la racine du dépôt :

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

La présence d’une commande doit être vérifiée avec wp help ou par parsing du JSON retourné par wp cli cmd-dump --format=json. Un simple grep dans la sortie brute n’est pas une preuve fiable.

Classification opérationnelle

Lecture et audit

Ces commandes observent l’état courant sans modifier les données métier.

Exemples de workflows documentés :

Une commande d’audit doit exposer des compteurs, les critères utilisés et le périmètre réellement lu.

Simulation

Les simulations évaluent une hypothèse sans persistance métier.

Une simulation doit distinguer clairement :

  • les lignes examinées ;
  • les cas éligibles ;
  • les changements proposés ;
  • les cas ignorés ou ambigus ;
  • les raisons de chaque décision.

Dumps et revue manuelle

Ces commandes produisent des sorties détaillées pour inspection humaine.

Les dumps ne doivent pas devenir une seconde source de vérité. Ils restent des artefacts d’analyse dérivés de l’état courant.

Écritures et reconstructions

Les commandes qui lancent une synchronisation, reprennent un run, reconstruisent une projection ou appliquent une correction sont des opérations d’écriture.

Elles doivent annoncer explicitement :

  • la table ou projection ciblée ;
  • le run ou le périmètre ;
  • le caractère reprenable ou non ;
  • les garde-fous ;
  • les compteurs de résultat ;
  • le code de retour final.

Les reconstructions de projections doivent passer par les services ou orchestrateurs dédiés, jamais par une duplication de logique dans l’adapter CLI.

Opérations sensibles

Les commandes de taxonomy V2, rollback, cleanup, migration, schéma ou maintenance peuvent créer des tables temporaires, installer un schéma ou écrire dans les offres.

Elles ne doivent jamais être présentées comme read-only uniquement parce que leur nom contient audit ou dry-run. La documentation doit décrire les effets techniques réellement observés.

Media Quality

Media Quality fonctionne par défaut en mode audit-first et non destructif.

Le workflow attendu est :

projection fraîche
    ↓
audit Media Quality
    ↓
analyse des évidences et métriques
    ↓
validation explicite d’une politique de mutation
    ↓
écriture éventuelle à confiance suffisante

Une commande Media Quality ne doit pas effacer image_norm par défaut. Les métriques doivent au minimum distinguer les lignes scannées, vérifiées, compatibles, incompatibles, ambiguës, inconnues et les remplacements réellement appliqués.

Validation de fin d’opération

Toute commande importante doit permettre de répondre à quatre questions :

  1. Qu’est-ce qui a été lu ?
  2. Qu’est-ce qui a été décidé ?
  3. Qu’est-ce qui a été écrit ?
  4. Comment vérifier le résultat ?

Le rapport final doit rester exploitable par un humain et par l’automatisation.

Invariants

  • L’adapter CLI reste mince : parsing, validation, délégation et formatage.
  • La logique métier vit dans les services applicatifs ou le Domain Core.
  • Une commande de lecture n’écrit pas silencieusement.
  • Une commande d’écriture annonce son périmètre et ses effets.
  • Les projections sont reconstruisibles et ne deviennent pas une vérité métier autonome.
  • Un résultat ambigu ne déclenche pas une mutation destructive.
  • Les erreurs produisent un code de retour non nul et un message actionnable.

Documentation associée