Présentation de la migration¶

Status: CURRENT / GOVERNANCE / TARGET ALIGNMENT

Décision de migration¶

La migration prioritaire de CMonChoix est une migration de responsabilités depuis les zones historiques du plugin WordPress vers la Platform indépendante sous src/.

Elle ne consiste pas à déplacer des dossiers en masse ni à réécrire le système d'un coup.

La cible est :

plugins/ccx-feeds-industrial/
    WordPress bootstrap
    hooks
    controllers / admin / presentation adapters
    wrappers de compatibilité temporaires
             │
             ▼
            src/
    Domain
    Application
    Contracts
    Infrastructure
    Projection
    ReadService
    Runtime
    autres composants Platform

Règle fondamentale¶

WordPress -> src/ : autorisé
src/ -> WordPress : interdit

Toute capacité qui doit fonctionner sans WordPress appartient à la Platform.

Le fait qu'une capacité soit aujourd'hui appelée depuis WP-CLI, un hook ou un fichier du plugin ne signifie pas qu'elle appartient architecturalement à WordPress.

CURRENT¶

Le dépôt contient encore des responsabilités historiques importantes sous plugins/ccx-feeds-industrial/, notamment dans des zones telles que :

includes/application/
includes/mapping/
includes/verticals/
includes/identity/
includes/quality/
includes/pipeline/
includes/runtime/
includes/catalog/

Ces noms de dossiers ne suffisent pas à déterminer la responsabilité réelle de chaque fichier. Ils doivent être audités composant par composant.

Le code historique reste une source de connaissance et peut rester nécessaire au Runtime CURRENT. Il n'est pas pour autant l'autorité de la cible.

TARGET¶

Doivent converger vers src/ les responsabilités telles que :

ingestion indépendante du CMS ;
parsing et normalisation ;
classification ;
règles de verticales ;
identité produit et variante ;
qualité et scoring ;
logique prix/disponibilité ;
catalogue ;
projections ;
orchestration métier ;
jobs/workers ;
synchronisation et replay ;
audits et migrations métier ;
contrats de persistance ;
search projections.

Peuvent rester spécifiques à WordPress :

bootstrap WordPress ;
hooks ;
routing public ;
templates ;
SEO et sitemaps ;
CMS éditorial ;
contrôleurs admin WordPress ;
WP-CLI comme adapter temporaire/opérateur ;
adaptation de données Platform vers le rendu WordPress.

Priorité de migration¶

L'ordre recommandé est basé sur le risque architectural, pas sur la taille des fichiers.

P0 — décisions métier enfermées dans WordPress¶

Migrer en priorité tout fichier qui combine une dépendance WordPress (ABSPATH, hooks, $wpdb, etc.) avec une décision telle que :

classification ;
identity ;
qualité ;
normalisation canonique ;
heuristique marchand ;
choix de verticale ;
état final d'une offre.

P1 — use cases et orchestration métier¶

Extraire les cas d'usage aujourd'hui présentés comme application dans le plugin et conserver uniquement les contrôleurs/adapters WordPress nécessaires.

P1 — persistance¶

Isoler $wpdb et SQL concret derrière des ports définis par la Platform.

P1 — workers¶

Faire converger les traitements background vers des exécutables Platform capables de fonctionner sans WordPress.

P2 — compatibilité et nettoyage¶

Supprimer wrappers, shims, anciens dossiers documentaires et duplications uniquement après preuve de non-utilisation.

Unité de migration¶

L'unité de travail est une responsabilité ou un contrat suffisamment petit pour être :

compris ;
caractérisé ;
testé ;
déplacé ;
comparé ;
rollbacké.

Un dossier entier n'est pas une unité de migration par défaut.

Séquence industrielle¶

1. Identifier le comportement CURRENT
2. Identifier les consommateurs
3. Caractériser avec des tests
4. Définir le propriétaire TARGET
5. Créer/certifier le contrat Platform
6. Extraire la logique pure vers src/
7. Créer l'adapter Infrastructure si nécessaire
8. Transformer l'ancien point d'entrée en wrapper mince
9. Migrer les consommateurs
10. Comparer ancien/nouveau comportement
11. Certifier Runtime et architecture
12. Supprimer le chemin historique lorsqu'il n'est plus utilisé

Règles des wrappers¶

Un wrapper de compatibilité est acceptable s'il :

reste mince ;
ne contient aucune nouvelle logique métier ;
délègue dans le sens WordPress -> Platform ;
possède des consommateurs identifiés ;
est enregistré comme TRANSITIONAL ;
possède des critères de suppression.

Un wrapper qui recommence à prendre des décisions est une nouvelle dette.

Migration des règles marchands¶

Une particularité marchande ne doit pas être déplacée telle quelle dans le Domain Core.

La cible est :

source merchant
  ↓
adapter / source mapping / merchant policy explicite
  ↓
canonical observation
  ↓
common pipeline

Une règle spécifique devient générique uniquement si son caractère transversal est démontré.

Migration du Runtime¶

Le Runtime cible orchestre des services Platform neutres.

WP-CLI et les hooks peuvent rester des adapters pendant la transition, mais ingestion, classification, identity, projection et jobs ne doivent pas dépendre structurellement du bootstrap WordPress.

Migration de la persistance¶

Cible :

Application
   ↓ port
Infrastructure repository/writer
   ↓
MariaDB / SQL / $wpdb temporaire

Interdit :

Domain/Application -> $wpdb

Certification sans WordPress¶

La migration ne sera pas considérée achevée sur le Core tant qu'un test représentatif ne pourra pas exécuter sans WordPress :

fixture
 -> ingestion
 -> normalization
 -> classification
 -> identity
 -> quality
 -> projection

La certification doit échouer si le scénario nécessite ABSPATH, une fonction WordPress ou le chargement du plugin.

CURRENT / TARGET / TRANSITIONAL / HISTORICAL¶

Chaque documentation de migration doit préciser son statut.

Une page historique dans le plugin ne doit jamais se présenter comme la racine documentaire officielle de la Platform.

La source documentaire officielle reste docs/, et la cible code indépendante reste src/.

Quand supprimer l'ancien composant¶

Un ancien composant peut être retiré lorsque :

tous les consommateurs actifs sont identifiés/migrés ;
son comportement utile est couvert dans la Platform ;
les tests de caractérisation et nouveaux tests passent ;
aucun bootstrap/require direct ne dépend encore de lui ;
la certification Runtime pertinente passe ;
la documentation ne le présente plus comme CURRENT ;
le rollback ou mécanisme de recovery est compris.

Critère de réussite¶

La migration est réussie lorsque supprimer WordPress ne supprime plus le moteur catalogue.

Le plugin devient progressivement un adapter de présentation/intégration et non un second Core concurrent.