Frontière WordPress

Status: NORMATIVE / CONTRACT

Décision

WordPress est le CMS, la couche SEO et l'adaptateur de présentation publique de CMonChoix.

WordPress n'est pas le moteur catalogue, n'est pas le runtime métier et n'est pas l'autorité des décisions produit.

La règle fondamentale est :

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

Le Core de la plateforme doit rester exécutable sans cycle HTTP WordPress, sans ABSPATH, sans fonctions wp_*, sans $wpdb et sans chargement du plugin.

Propriété des responsabilités

Responsabilité	Platform src/	WordPress
ingestion marchands	oui	non
téléchargement / parsing feeds	oui	non
normalisation	oui	non
classification	oui	non
identité produit / variantes	oui	non
qualité / scoring	oui	non
prix / disponibilité métier	oui	non
règles de sélection média	oui	non
catalogue / projections	oui	non
indexation recherche	oui	non
workers / jobs / queues	oui	non
synchronisation / replay	oui	non
audits et migrations métier	oui	non
health métier	oui	non
routing public	contrat éventuel	oui
canonical URLs publiques	contrat	oui
templates / HTML	non	oui
CSS / JS de présentation	non	oui
contenu éditorial	non	oui
SEO metadata / sitemap	données préparées	oui
Schema.org de présentation	données préparées	oui
navigation utilisateur	read model	oui

Test de placement

Avant d'ajouter du code au plugin ou au thème, poser la question :

Cette capacité doit-elle continuer à fonctionner si WordPress est supprimé demain ?

Si la réponse est oui, la responsabilité appartient à la Platform et doit être placée dans src/ dans la couche appropriée.

Si la réponse est non uniquement parce que la responsabilité est intrinsèquement un concept WordPress — hook, template, écran CMS, SEO WordPress, routing public — elle peut rester dans l'adapter WordPress.

Flux cible

Merchant feeds
      ↓
Adapters source
      ↓
Application / Pipeline
      ↓
Domain / Vertical knowledge
      ↓
Persistence + projections
      ↓
Read Services
      ↓
WordPress adapter
      ↓
Templates / SEO / CMS / pages publiques

WordPress consomme un résultat déjà décidé. Il ne doit pas reconstruire la vérité métier pour afficher une page.

Ce qui est interdit dans la cible

• nouvelle normalisation métier dans le plugin WordPress ;
• règle de classification dans un fichier protégé par ABSPATH ;
• heuristique marchand dans un template ou hook de présentation ;
• résolution d'identité depuis WordPress ;
• scoring catalogue dans WordPress ;
• SQL métier direct depuis les templates ;
• $wpdb comme API métier ;
• import ou rebuild critique dépendant exclusivement de WP-Cron ;
• dépendance de src/Domain ou src/Application vers WordPress ;
• dépendance de src/ vers plugins/ccx-feeds-industrial/ pour fournir une règle métier ;
• duplication d'une décision Platform dans le thème ou le plugin.

Compatibilité CURRENT

Le plugin contient encore des responsabilités historiques de pipeline, mapping, classification, identité, qualité ou orchestration. Leur présence peut être nécessaire au Runtime CURRENT pendant la migration.

Ces zones doivent être considérées TRANSITIONAL dès qu'elles portent une responsabilité qui devrait fonctionner sans WordPress.

Aucune nouvelle règle métier ne doit y être ajoutée. Les évolutions fonctionnelles doivent viser le propriétaire canonique sous src/, puis conserver si nécessaire un wrapper WordPress mince le temps de migrer les consommateurs.

$wpdb

L'accès à la base WordPress peut subsister dans un adapter d'infrastructure WordPress pendant la transition.

Il doit être caché derrière un port ou un service de persistance explicite. Les services Application et Domain ne doivent pas connaître $wpdb.

Cible :

Application port
      ↑
Infrastructure adapter WordPress / SQL
      ↑
$wpdb

et jamais :

Domain/Application -> $wpdb

Workers

Les workers métier doivent converger vers des exécutables Platform capables de tourner sans charger WordPress.

WP-CLI peut rester temporairement un adapter opérateur, mais ne doit pas être la seule manière structurelle d'exécuter ingestion, normalisation, projections ou maintenance métier.

Certification obligatoire

L'indépendance WordPress n'est pas certifiée par la documentation seule.

Une certification doit démontrer qu'un scénario représentatif peut exécuter au minimum :

fixture source
  -> ingestion
  -> normalisation
  -> classification
  -> identity
  -> quality
  -> persistence contract
  -> projection

sans WordPress chargé.

Voir Certification Platform.

Checklist de revue WordPress

Avant fusion d'un changement touchant WordPress :

• est-ce réellement de la présentation, du CMS ou du SEO ?
• la même règle pourrait-elle être utilisée par un worker, une API ou un autre frontend ?
• le résultat existe-t-il déjà dans une projection ou un Read Service ?
• le changement introduit-il ABSPATH, wp_* ou $wpdb autour d'une décision métier ?
• remplacer WordPress obligerait-il à réécrire cette fonctionnalité ?

Si une réponse révèle une propriété métier, le changement appartient à la Platform, pas à WordPress.

Critère final

WordPress doit être remplaçable comme couche publique sans réécrire le catalogue, l'identité, les feeds, les syncs, les workers, la qualité ou les projections.