Registre des composants¶

Status: CURRENT / GOVERNANCE

Ce document aide un repreneur à localiser les grandes responsabilités de CMonChoix Platform sans transformer une liste statique en vérité absolue sur l’état du Runtime.

Le registre indique où commencer à chercher. Il ne remplace jamais :

le code chargé dans la révision courante ;
les Contracts ;
les pages d’architecture dédiées ;
les tests et audits reproductibles ;
l’état réellement observé sur le Runtime.

Une mention ancienne comme « certifié », « stable » ou « en découpage » ne doit donc pas être réutilisée sans nouvelle preuve.

Comment lire le registre¶

Pour chaque composant, distinguer quatre questions :

Responsabilité — que fait cette brique ?
Frontière — que ne doit-elle pas faire ?
Point d’entrée — où vérifier son implémentation actuelle ?
Preuve — quels tests, audits ou observations confirment son comportement dans la révision examinée ?

Le registre ne certifie pas à lui seul qu’un fichier est chargé, qu’un service est actif ou qu’une fonctionnalité est utilisée en production.

Composants structurants¶

Composant	Responsabilité	Où vérifier en priorité	Frontière principale
Domain Core	Porter les concepts et règles métier génériques	`src/`, `docs/domain-core/`	ne dépend d’aucune verticale, d’aucun Adapter ou Frontend
Contracts	Définir les interfaces et formes stables entre couches	`src/Contracts/`, `docs/contracts/`	ne contient pas l’implémentation infrastructure
Vertical Modules	Porter la connaissance propre aux familles produit	bootstrap/registry vertical courant + `docs/vertical-modules/`	aucune règle verticale dans le Domain Core
Resolver	Décider à partir de preuves et produire `resolved`, `unknown`, `ambiguous` ou `conflict`	contrat Resolver et implémentations chargées	ne persiste pas lui-même les résultats
Projection Builders	Construire des représentations dérivées pour la lecture	`src/Projection/`, Contracts Projection, docs projections	ne deviennent jamais source de vérité métier
Read Services	Exposer observation, audit et lecture applicative	`src/ReadService/` et adaptateurs associés	strictement read-only côté métier
Write Services	Appliquer une mutation explicitement décidée	services d’écriture et orchestrateurs associés	ne doivent pas décider implicitement de la vérité métier
Runtime	Orchestrer les contextes d’exécution	bootstraps Runtime et docs Runtime	orchestre ; ne déplace pas les règles métier dans l’orchestration
Pipeline / ingestion	Importer, normaliser et préparer les données sources	plugin industriel, pipeline et docs pipeline	les règles marchands restent confinées ; ne gouverne pas le Frontend
Adapters WordPress	Relier WordPress, HTTP, CLI, admin et cron à l’application	`plugins/ccx-feeds-industrial/includes/`	les globals WordPress restent confinés à l’Adapter
Frontend public	Rendre les projections et contrats publics	thème actif + `plugins/ccx-feeds-industrial/includes/frontend/`	ne recalcule pas la logique métier et n’écrit pas pendant une requête publique
Navigation publique	Déclarer et exposer l’architecture de navigation	`includes/application/navigation-architecture.php`	la visibilité Runtime ne se déduit pas du simple fait qu’une feuille est déclarée
Feed Runtime	Déterminer les feeds réellement activables/exécutables	`CCX_ACTIVE_FEEDS`, `ccx_feed_runtime_active_feeds()`	`ccx_feeds_registry()` contient aussi des feeds PREPARED ; PREPARED ≠ ACTIVE
Base de données	Persister sources, états, identités, projections et états techniques	migrations/schema/services de persistence	la présence d’une valeur en base ne lui donne pas autorité métier
Infrastructure / Docker	Fournir services, mounts, volumes et réseau	`docker-compose.yml`, `.env.example`, scripts ops	vérifier le Runtime réel avant de déduire un chemin ou un mount
Exploitation	Diagnostiquer, sauvegarder et tester la reprise	`Makefile`, `scripts/`, `docs/operations/`	observer et vérifier avant toute mutation
Documentation	Transmettre architecture, opérations, décisions et historique	`docs/`, `mkdocs.yml`	`site/` est un artefact généré, pas une source à éditer

Frontend WordPress : repères actuels¶

La couche Frontend a connu plusieurs phases d’extraction. Pour éviter de traiter un ancien snapshot comme une cartographie actuelle :

partir de plugins/ccx-feeds-industrial/includes/bootstrap/frontend.php et des bootstraps associés ;
vérifier les fichiers réellement inclus dans la révision ;
vérifier les tests de caractérisation pertinents ;
distinguer le thème wordpress/wp-content/themes/ccx/ de la couche catalogue fournie par le plugin industriel ;
ne pas supposer qu’un ancien fichier monolithique ou une ancienne extraction reste le point d’entrée CURRENT.

Les anciennes entrées du registre qui citaient par exemple product-models.php, des assets particuliers ou un statut 🟢/🟡 doivent être lues comme historique de découpage, pas comme certification permanente.

Preuves attendues avant de déclarer un composant CURRENT¶

Une assertion CURRENT doit idéalement pouvoir être reliée à plusieurs éléments :

fichier ou classe présente dans la révision ;
bootstrap ou wiring qui la charge réellement ;
test de contrat ou de caractérisation ;
audit reproductible ;
observation Runtime lorsque l’état dépend du déploiement ;
documentation cohérente avec ces preuves.

Une simple occurrence dans le dépôt ne suffit pas toujours. Un fichier peut être legacy, fallback, compatibilité ou non chargé.

Ajouter ou modifier un composant¶

Documenter au minimum :

Nom
Responsabilité
Statut : CURRENT / TARGET / CONTRACT / HISTORICAL / DEPRECATED
Explication simple
Point(s) d’entrée
Entrées
Sorties
Dépendances autorisées
Dépendances interdites
Lecture / écriture
Tests et audits
Documentation canonique
Risques / rollback
Preuves du statut annoncé

Quand mettre à jour ce registre¶

Mettre à jour cette page lorsqu’une évolution :

crée une responsabilité durable ;
supprime ou déprécie une brique ;
déplace une frontière entre Core, Application, Adapter, Runtime ou Frontend ;
change la source d’autorité d’un comportement ;
modifie le point d’entrée canonique d’un composant.

Ne pas mettre à jour un statut sur impression générale. Citer les preuves dans la PR, le commit, l’ADR ou le rapport de validation concerné.

Diagnostic lorsqu’un composant semble « absent »¶

Avant de recréer ou recopier une brique supposée manquante :

chercher son contrat et son rôle dans les docs ;
vérifier les namespaces et le Composer autoload ;
vérifier les bootstraps réellement chargés ;
vérifier les wrappers de compatibilité ;
vérifier le contexte Runtime concerné ;
seulement ensuite conclure qu’une implémentation manque réellement.

Cette méthode évite de réintroduire une copie historique ou de contourner l’architecture canonique.