Definition of Done¶

Status: CURRENT / CONTRACT

Un changement est terminé lorsqu'un autre mainteneur peut comprendre sa responsabilité, vérifier son comportement, observer ses échecs et reprendre son exploitation sans dépendre de l'historique oral du projet.

1. Architecture¶

responsabilité propriétaire clairement identifiée ;
source de vérité connue ;
aucune deuxième implémentation métier active introduite ;
src/ ne dépend pas de WordPress pour fournir une responsabilité métier ;
toute responsabilité non intrinsèquement WordPress est placée ou converge vers la Platform ;
Domain Core générique ;
règles verticales confinées ;
règles marchands confinées ;
Runtime orchestre sans décider ;
Read Services read-only ;
mutations via une frontière explicite ;
Frontend/WordPress consomment des projections ou Read Services.

Un changement durable de frontière exige une mise à jour des documents normatifs ou un ADR.

2. WordPress¶

Pour tout changement dans plugins/ccx-feeds-industrial/, le reviewer doit répondre :

Cette fonctionnalité doit-elle fonctionner si WordPress disparaît ?

Si oui, la logique appartient à src/. Le plugin peut fournir un wrapper/adapter mince pendant la transition.

Une nouvelle logique de classification, identity, qualité, normalisation, scoring, projection ou règle marchand dans un fichier WordPress n'est pas Done.

3. Multi-marchands¶

Pour une évolution d'ingestion ou de synchronisation :

merchant_id/feed/run sont identifiables ;
une erreur marchand n'affecte pas indûment les autres ;
aucune logique marchande n'est dispersée dans les composants génériques ;
les volumes importants sont traités de manière bornée ;
retry/replay/idempotence sont définis lorsque nécessaires ;
le retrait du marchand n'exige pas de modifier le Domain Core.

4. Jobs et traitements de volume¶

Un job critique de volume doit autant que possible être :

borné ;
idempotent ;
retryable ;
observable ;
checkpointable ;
rejouable.

Le code ne doit pas supposer qu'un feed ou catalogue complet tient en mémoire sans justification et mesure.

5. Refresh et projections¶

Lorsqu'un changement touche une mutation d'offre/produit :

le scope impacté est explicite lorsque possible ;
un changement local ne provoque pas un full rebuild sans justification ;
l'incrémental conserve les invariants canoniques ;
le full rebuild/reconciliation reste disponible comme recovery lorsque nécessaire ;
les projections restent dérivées et reconstructibles ;
les échecs post-commit ne sont pas transformés silencieusement en succès.

6. Code¶

dépendances explicites ;
pas de fallback silencieux qui masque une erreur ou un conflit ;
états unknown, ambiguous, conflict préservés ;
diff limité au périmètre ;
aucun secret/dump/artefact local ;
legacy supprimé uniquement après preuve de non-utilisation ;
wrappers temporaires minces et identifiés TRANSITIONAL.

7. Tests¶

Les tests doivent couvrir le risque réel, pas seulement la classe modifiée.

Entrées générales du dépôt :

composer test
make lint
make check

Selon le chantier, ajouter :

tests unitaires Domain/Application ;
tests de contrats ;
tests d'architecture ;
tests d'idempotence/replay ;
tests Runtime ;
tests de projection incrémentale vs rebuild ;
tests de chargement sans WordPress ;
fixtures marchand représentatives.

8. Certification sans WordPress¶

Toute migration déclarée comme ayant sorti une responsabilité du plugin doit prouver que cette responsabilité peut être exécutée via la Platform sans bootstrap WordPress.

Une simple duplication de code dans src/ alors que le Runtime dépend encore exclusivement de l'ancien chemin n'est pas Done.

9. Runtime et exploitation¶

Lorsque le wiring, Docker ou les entrypoints changent, utiliser les contrôles pertinents disponibles dans la révision, notamment :

make guard-static
make guard-runtime
make doctor

Un changement de bootstrap/worker doit documenter :

entrypoint ;
dépendances ;
timeout ;
retry ;
logs/métriques ;
failure mode ;
rollback/recovery.

10. Données et migrations¶

Pour une mutation significative :

baseline
 -> audit read-only
 -> simulation si possible
 -> mutation explicite
 -> vérification
 -> rollback/recovery connu

La présence d'une valeur en base n'est pas une preuve de vérité métier.

11. Performance¶

baseline avant optimisation ;
dataset/volume connus ;
CPU/RAM/I/O observés lorsque pertinent ;
DB latency/requêtes critiques observées ;
traitements volumineux bornés ;
aucun N+1 introduit ;
Frontend sans reconstruction métier lourde ;
cache accompagné d'une stratégie d'invalidation ;
résultat métier avant/après identique.

Augmenter les ressources pour masquer une dette algorithmique n'est pas une certification.

12. Observabilité¶

Un flux critique doit pouvoir distinguer :

marchand ;
run ;
batch/job ;
volume parcouru/traité/modifié ;
rejets ;
reason codes ;
erreurs techniques ;
retries ;
projection lag lorsque concerné.

13. Documentation¶

La documentation est mise à jour si le changement modifie :

responsabilité/source de vérité ;
frontière ;
comportement CURRENT ;
entrypoint opérateur ;
modèle de données ;
sync/retry/replay ;
projection ;
SLO/capacité ;
migration/recovery.

Les statuts CURRENT, TARGET, TRANSITIONAL, HISTORICAL, DEPRECATED doivent rester explicites.

Les README historiques du plugin ne doivent pas se présenter comme la source documentaire officielle.

14. Documentation publiée¶

Valider selon l'environnement du dépôt :

make docs-check

ou :

./.venv-docs/bin/mkdocs build --clean

site/ reste un artefact généré.

15. Git et livraison¶

Avant fermeture :

git status --short
git log -5 --oneline --decorate

Le lot doit être propre, poussé, compréhensible et dépourvu de changements parasites.

Checklist finale¶

[ ] propriétaire et source de vérité identifiés
[ ] sens de dépendance correct
[ ] aucune nouvelle dépendance métier à WordPress
[ ] règles marchand/verticale confinées
[ ] tests adaptés au risque
[ ] retry/replay/idempotence vérifiés si nécessaire
[ ] scope de refresh/projection correct
[ ] observabilité suffisante
[ ] performance mesurée si concernée
[ ] rollback/recovery connu
[ ] documentation CURRENT/TARGET synchronisée
[ ] legacy supprimé seulement après preuve
[ ] dépôt propre et lot vérifiable