2.1 KiB
2.1 KiB
Maintenance du dépôt
Ce document rassemble les règles simples à garder pour faire évoluer le projet sans le dégrader.
Ce qui doit rester stable
Backend
- architecture modulaire par domaines ;
- séparation
Application / Domain / Infrastructure / UI; - services applicatifs découplés du framework HTTP ;
- tests d'architecture présents ;
- relation explicite
Post ↔ Mediaviapost_media; - démonstration vivante des modules
Settings,AuditLogetNotificationsvia le module localSite; - recherche full-text FTS5 protégée contre les entrées purement ponctuées.
Frontend
- templates colocalisés par domaine ;
- partials transverses dans
templates/Kernel/; - SCSS centralisé dans
assets/et organisé par couches ; - scripts d'écran riches externalisés dans
assets/js/puis copiés danspublic/assets/js/au build ; - médiathèque admin et picker de l'éditeur alignés sur le même workflow métier (
data-media-id).
Pour les détails de déploiement Docker, du provisionnement et d'un reverse proxy comme Caddy, voir DEPLOYMENT.md.
Règles de conduite
- respecter
docs/ARCHITECTURE.md,docs/DEVELOPMENT.mdetdocs/FRONTEND.md; - éviter d'ajouter du transverse local alors que l'évolution relève de
netslim-core; - préférer une amélioration locale à une nouvelle couche générique prématurée ;
- garder les tests et la documentation à jour quand une frontière change ;
- valider les parcours critiques manuellement avant une livraison importante ;
- préserver le découplage actuel entre
PostetMedia:Postgarde ses VOs internes, l'adaptateur seul parle le contrat du domaineMedia; - garder
Sitecomme module d'intégration applicative du blog, sans y déplacer de responsabilités qui appartiennent au core.
Dépôt prêt à évoluer quand
- PHPUnit est vert ;
- PHPStan est vert ;
- une vérification manuelle des parcours critiques a été effectuée si nécessaire ;
- les assets frontend ont été reconstruits si besoin ;
- aucun fichier temporaire n'est présent ;
- la documentation reflète l'état réel du projet.