Repository Cleanup Phase 1¶
Status: HISTORICAL SNAPSHOT / BASELINE DE NETTOYAGE
Cette page conserve un ancien état de référence utilisé pour préparer le nettoyage du repository.
Elle reste utile pour comprendre quelles conventions et quels risques avaient été identifiés pendant cette phase, mais elle ne doit pas être lue comme une description exhaustive de l’état CURRENT.
Ce qui reste valable comme principe¶
Les garde-fous suivants restent pertinents :
- ne jamais supprimer un fichier PHP sans preuve d’inutilisation ;
- ne jamais déplacer une classe critique sans tests ou caractérisation ;
- garder les changements atomiques et réversibles ;
- vérifier les chargements directs, bootstraps et bind mounts avant suppression ;
- ne pas considérer une copie historique comme canonique sans preuve Runtime.
Namespace Platform¶
Le namespace Platform observé comme canonique dans la documentation actuelle reste :
CMonChoix\Platform\
avec le code Platform sous :
src/
Les anciens namespaces ou prototypes ne doivent pas être promus comme CURRENT uniquement parce qu’ils apparaissent dans un snapshot de migration.
Limite de cette page¶
Les listes de fichiers, états de composants et décisions de « Phase 1 » décrites historiquement étaient valables dans le contexte de cette phase.
Avant de réutiliser une décision :
vérifier le fichier actuel
→ vérifier Composer / bootstrap
→ vérifier les consommateurs
→ vérifier les tests
→ vérifier les Contracts et frontières
→ prendre une nouvelle décision
Nettoyage CURRENT¶
Pour un nettoyage actuel, appliquer plutôt la méthode suivante :
- identifier la responsabilité ;
- vérifier qui la charge ou l’appelle ;
- distinguer CURRENT, COMPATIBILITY et HISTORICAL ;
- caractériser le comportement ;
- migrer les consommateurs si nécessaire ;
- vérifier le dépôt et le Runtime ;
- supprimer seulement lorsque la preuve est suffisante.
Attention aux fichiers « apparemment inutiles »¶
Un fichier peut être absent d’un chemin d’exécution normal tout en restant utilisé par :
- un test direct ;
- un outil CLI ;
- un bootstrap ciblé ;
- un bind mount ;
- une procédure de reprise ;
- une compatibilité temporaire.
Le grep seul n’est donc pas une preuve suffisante pour les composants critiques.
Conservation historique¶
Cette page est conservée pour expliquer les premières décisions de nettoyage et la transition vers le namespace Platform actuel.
Elle ne doit pas être continuellement réécrite pour refléter chaque évolution ultérieure : les pages CURRENT de l’architecture, du Runtime et de la gouvernance sont les références à utiliser pour l’état réel.