first commit

docs/APPLICATION.md

@@ -0,0 +1,18 @@
+# Application blog
+
+Ce dépôt porte une seule application : le blog.
+
+Les fichiers applicatifs se trouvent directement à la racine du projet :
+- `config/modules.php`
+- `public/index.php`
+- `templates/`
+- `assets/`
+- `src/Post/`
+- `src/Site/`
+
+Le coeur technique et les modules partagés (`Kernel`, `Identity`, `Settings`, `AuditLog`, `Notifications`, `Taxonomy`, `Media`) proviennent du package Composer `netig/netslim-core` installé sous `vendor/`.
+
+En pratique :
+- ce dépôt reste propriétaire du domaine `Post` et des intégrations applicatives du blog ;
+- la page `/admin` sert de tableau de bord au back-office ;
+- `/admin/settings`, `/admin/audit-log` et `/admin/notifications` servent de démonstration vivante des modules transverses du core.

docs/ARCHITECTURE.md

@@ -0,0 +1,46 @@
+# Architecture de netslim-blog
+
+`netslim-blog` est une application qui consomme `netslim-core` et ajoute deux modules locaux :
+- `Post` pour le domaine éditorial ;
+- `Site` pour les intégrations applicatives propres au blog.
+
+## Dépendances vers le core
+
+Le projet s’appuie sur :
+- `Netig\Netslim\Kernel\...`
+- `Netig\Netslim\Identity\...`
+- `Netig\Netslim\Settings\...`
+- `Netig\Netslim\AuditLog\...`
+- `Netig\Netslim\Notifications\...`
+- `Netig\Netslim\Taxonomy\...`
+- `Netig\Netslim\Media\...`
+
+`ADMIN_HOME_PATH` pointe vers `/admin`, qui sert de tableau de bord au back-office du blog.
+
+## Frontière entre le dépôt et le core
+
+Dans ce dépôt, le code applicatif local est essentiellement :
+- `src/Post/`
+- `src/Site/`
+- `templates/`
+- `assets/`
+- `config/`
+- `public/`
+
+Le code transverse et les modules partagés vivent dans `vendor/netig/netslim-core/` après installation Composer.
+Les répertoires runtime persistants (`var/`, `database/`, `public/media/`) restent toutefois ceux du projet blog lui-même.
+
+## Démonstration des capacités du core
+
+Le module `Site` démontre concrètement :
+- `Settings` via les réglages de titre, baseline, meta description et pagination ;
+- `Authorization` via les pages d’administration réservées aux permissions d’admin ;
+- `AuditLog` via la traçabilité des actions sur les réglages, notifications et articles ;
+- `Notifications` via une page d’envoi manuel et l’historique des dispatches.
+
+Le module `Post` reste propriétaire :
+- des routes publiques et d’administration des contenus ;
+- des migrations `posts`, `post_media`, `posts_fts` ;
+- des usages concrets de `Taxonomy` et `Media`.
+
+En pratique, si une évolution relève de `Kernel`, `Identity`, `Settings`, `AuditLog`, `Notifications`, `Taxonomy` ou `Media`, elle doit être développée dans le dépôt `netslim-core`, puis intégrée ici via Composer.

docs/DEPLOYMENT.md

@@ -0,0 +1,42 @@
+# Déploiement
+
+Ce document regroupe les informations utiles pour déployer l'application avec Docker en production.
+
+## Déploiement Docker en production
+
+### Commandes minimales
+
+```bash
+cp .env.example .env
+# Définir APP_ENV=production, APP_URL, ADMIN_PASSWORD (12 caractères minimum) et la configuration SMTP
+docker compose up -d --build
+docker compose run --rm provision
+```
+
+Le provisionnement reste explicite : le runtime HTTP ne crée pas le schéma automatiquement. Il initialise aussi les réglages par défaut du blog via le module local `Site`.
+
+## Données persistées
+
+La stack Docker initialise `./data/` sur l'hôte :
+
+```text
+data/
+├── public/       # assets compilés et médias persistés
+├── database/     # base SQLite, lock de provisionnement et données runtime
+└── var/          # cache Twig/HTMLPurifier et logs
+```
+
+## Reverse proxy et Caddy
+
+Le Nginx de la stack Docker écoute sur `127.0.0.1:8888`. Pour exposer l'application publiquement, placez-le derrière un reverse proxy.
+
+Exemple Caddy :
+
+```caddy
+https://app.exemple.com {
+    header Strict-Transport-Security max-age=31536000;
+    reverse_proxy localhost:8888
+}
+```
+
+Pensez aussi à renseigner `APP_URL` avec l'URL publique, `ADMIN_HOME_PATH=/admin`, la configuration `MAIL_*` utilisée par la démonstration des notifications, et à adapter `TRUSTED_PROXIES` si l'application est servie derrière un autre proxy que le Nginx Docker fourni.

docs/DEVELOPMENT.md

@@ -0,0 +1,79 @@
+# Développement
+
+Ce document sert de guide quotidien : lancer le projet, savoir où placer une modification et vérifier le résultat avant push.
+
+Pour une première découverte du dépôt, commence plutôt par [ONBOARDING.md](ONBOARDING.md).
+
+## Démarrage local
+
+Prérequis : PHP 8.4+, Composer, Node.js 18+, `pdo`, `pdo_sqlite`, `fileinfo`, `gd`, `json`, `mbstring`, `session`, `dom`, `simplexml`.
+
+```bash
+composer install
+composer frontend:install
+composer frontend:build
+cp .env.example .env
+composer provision
+composer start
+```
+
+Pour recompiler le SCSS en continu :
+
+```bash
+npm run watch
+```
+
+## Où placer une modification ?
+
+### Backend local au projet
+
+- `src/Post/` : domaine éditorial du blog
+- `src/Site/` : intégrations applicatives du blog (dashboard, réglages, audit, notifications de démonstration)
+
+### Code transverse provenant du core
+
+`Kernel`, `Identity`, `Settings`, `AuditLog`, `Notifications`, `Taxonomy` et `Media` proviennent de `netslim-core` et ne vivent pas dans `src/` de ce dépôt.
+
+Règle pratique :
+- si la modification concerne seulement `Post`, `Site` ou les assets/templates du blog, elle a sa place ici ;
+- si elle concerne les modules du core, elle doit être portée dans `netslim-core`, puis intégrée via Composer.
+
+### Frontend
+
+- templates de domaine : `src/<Domaine>/UI/Templates/`
+- partials applicatifs transverses : `templates/Kernel/partials/`
+- scripts d’écran : `assets/js/`
+
+## Points d’attention fonctionnels
+
+Le blog démontre les modules transverses du core :
+- `Settings` pilote le titre, la baseline, la meta description, l’introduction et la pagination ;
+- `AuditLog` trace les modifications de réglages, les notifications envoyées et les opérations CRUD sur les articles ;
+- `Notifications` envoie un email de démonstration depuis `/admin/notifications` ;
+- `Authorization` réserve les pages d’administration transverses aux administrateurs.
+
+## Vérifications avant push
+
+```bash
+composer test
+composer stan
+composer cs:check
+```
+
+Et si le frontend a changé :
+
+```bash
+composer frontend:build
+```
+
+Raccourci utile pour les vérifications backend :
+
+```bash
+composer qa
+```
+
+Pour la couverture :
+
+```bash
+composer test:coverage
+```

docs/FRONTEND.md

@@ -0,0 +1,139 @@
+# Frontend
+
+Ce document sert de référence pour Twig, SCSS et JavaScript côté navigateur. Pour découvrir le projet, commencer plutôt par [ONBOARDING.md](ONBOARDING.md). Pour le travail quotidien, voir aussi [DEVELOPMENT.md](DEVELOPMENT.md).
+
+## Vue d'ensemble
+
+Le frontend repose sur :
+
+- Twig pour le rendu HTML ;
+- Sass pour les styles ;
+- un peu de JavaScript côté navigateur ;
+- Trumbowyg pour l'édition riche côté admin.
+
+L'objectif reste simple : pas de couche frontend applicative lourde, mais des scripts dédiés dès qu'un écran dépasse le petit snippet inline.
+
+## Où trouver quoi ?
+
+- templates de page : `src/<Domaine>/UI/Templates/`
+- partials de domaine : `src/<Domaine>/UI/Templates/partials/`
+- partials partagés : `templates/Kernel/partials/` (avec un fallback interne dans `vendor/netig/netslim-core/src/Kernel/Http/UI/Templates/partials/`)
+- SCSS global : `assets/scss/`
+- scripts frontend dédiés (sources) : `assets/js/`
+- scripts générés servis par l'application : `public/assets/js/`
+
+## Lire un template Twig
+
+Les constructions les plus courantes sont :
+
+- `{% extends %}` : hériter d'un layout ;
+- `{% block %}` : remplir une zone du layout ;
+- `{% include %}` : réutiliser un partial ;
+- `{{ ... }}` : afficher une valeur ;
+- `{% if %}` / `{% for %}` : logique de présentation simple.
+
+Principe : garder la logique métier hors de Twig. Un template décide **quoi afficher**, pas **comment fonctionne le métier**.
+
+## Organisation SCSS
+
+Le dossier `assets/scss/` est organisé en couches :
+
+- `core/` : tokens, variables, mixins
+- `base/` : styles HTML globaux
+- `components/` : blocs BEM réutilisables
+- `layout/` : charpente globale de la page
+- `modules/` : styles propres à un domaine ou à un écran
+- `utilities/` : helpers ponctuels de layout (`u-*`)
+
+Ordre d'import : `core -> base -> components -> layout -> modules -> utilities`.
+
+## Règles de placement
+
+- bloc réutilisable sur plusieurs vues : `components/`
+- structure globale de la page : `layout/`
+- style propre à un écran ou à un domaine : `modules/`
+- helper ponctuel de mise en page : `utilities/`
+
+En cas d'hésitation entre `components/` et `modules/`, commencer dans `modules/` puis extraire à la deuxième vraie réutilisation.
+
+## Convention BEM
+
+- bloc : `.card`
+- élément : `.card__title`
+- modificateur : `.card--featured`
+
+Règles :
+
+- un fichier SCSS reste centré sur un ou plusieurs blocs cohérents ;
+- éviter les sélecteurs descendants hors `base/` et zones de contenu riche ;
+- préférer un modificateur BEM à une nouvelle classe parallèle ;
+- les utilitaires commencent par `u-`.
+
+## Contenu riche et Trumbowyg
+
+Le contenu HTML issu de l'éditeur est rendu dans `.rich-text` côté public. L'éditeur Trumbowyg est stylé pour rester cohérent avec le reste du projet : même typographie, mêmes états de focus, mêmes espacements généraux.
+
+### Workflow média actuel
+
+Le workflow média de l'éditeur est désormais le suivant :
+
+- l'éditeur ouvre une **modale de médiathèque** ;
+- la modale charge `/admin/media/picker` dans un contexte allégé ;
+- la sélection ou le téléversement d'une image insère un `<img>` avec `data-media-id` ;
+- le backend conserve ensuite ce `data-media-id` à la sanitisation pour synchroniser `post_media`.
+
+Le point important est le suivant : l'insertion d'une image ne repose pas sur une simple URL copiée, mais sur un HTML structuré permettant de garder le lien métier avec la médiathèque.
+
+## Quand créer un partial Twig ?
+
+Créer un partial si :
+
+- un fragment est répété dans plusieurs pages ;
+- le template principal devient difficile à lire ;
+- un composant partagé a besoin d'un markup stable (flashs, pagination, badges, empty states, actions admin).
+
+## Quand sortir du JavaScript dans un fichier dédié ?
+
+Le projet évite une couche JavaScript applicative dédiée tant que le besoin reste limité.
+
+Règles :
+
+- réserver le JavaScript aux comportements réellement nécessaires ;
+- garder les snippets inline pour les comportements très courts et strictement locaux ;
+- extraire vers `assets/js/` dès qu'un écran devient riche, qu'il faut gérer plusieurs interactions ou qu'un comportement doit rester lisible ;
+- ne charger une librairie tierce dans un template que lorsqu'un écran en a réellement besoin.
+
+Exemples actuels sortis des templates :
+
+- `assets/js/post-editor-media-picker.js` pour le picker média de l'éditeur ;
+- `assets/js/media-admin.js` pour les actions de la médiathèque (copie, insertion, téléversement AJAX).
+
+Après modification de ces fichiers, exécuter `composer frontend:build` pour les recopier dans `public/assets/js/`.
+
+## Checklist avant d'ajouter un style ou un comportement
+
+Avant d'ajouter du frontend, vérifier :
+
+1. est-ce un token ? → `core/`
+2. est-ce un style global HTML ? → `base/`
+3. est-ce un bloc réutilisable ? → `components/`
+4. est-ce structurel à la page ? → `layout/`
+5. est-ce propre à un domaine ? → `modules/`
+6. est-ce un ajustement ponctuel de layout ? → `utilities/`
+7. est-ce un comportement minuscule et local, ou faut-il déjà un fichier JS dédié ?
+
+## Vérifications manuelles utiles
+
+Après une modification du picker média, de l'éditeur ou de la médiathèque :
+
+1. ouvrir l'édition d'un post ;
+2. ouvrir la modale **Médiathèque** ;
+3. sélectionner ou téléverser une image ;
+4. vérifier l'insertion dans l'éditeur ;
+5. enregistrer le post puis vérifier l'usage du média dans `/admin/media`.
+
+Après une modification Twig ou SCSS plus générale :
+
+1. vérifier le rendu desktop et mobile ;
+2. vérifier les états de focus et les actions principales ;
+3. relire les partials partagés qui utilisent le même composant.

docs/MAINTENANCE.md

@@ -0,0 +1,44 @@
+# 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 ↔ Media` via `post_media` ;
+- démonstration vivante des modules `Settings`, `AuditLog` et `Notifications` via le module local `Site` ;
+- 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 dans `public/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](DEPLOYMENT.md).
+
+## Règles de conduite
+
+1. respecter `docs/ARCHITECTURE.md`, `docs/DEVELOPMENT.md` et `docs/FRONTEND.md` ;
+2. éviter d'ajouter du transverse local alors que l'évolution relève de `netslim-core` ;
+3. préférer une amélioration locale à une nouvelle couche générique prématurée ;
+4. garder les tests et la documentation à jour quand une frontière change ;
+5. valider les parcours critiques manuellement avant une livraison importante ;
+6. préserver le découplage actuel entre `Post` et `Media` : `Post` garde ses VOs internes, l'adaptateur seul parle le contrat du domaine `Media` ;
+7. garder `Site` comme 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.

docs/ONBOARDING.md

@@ -0,0 +1,78 @@
+# Onboarding
+
+Ce document sert de rampe d'accès au projet. Il n'essaie pas de tout expliquer : il te donne le bon ordre de lecture, les fichiers à ouvrir en premier et une première modification simple à réaliser sans te perdre.
+
+## L'idée du projet en une minute
+
+`netslim-blog` est une application blog concrète construite sur `netslim-core`.
+
+Les idées à retenir sont simples :
+
+- le code local est organisé par **domaines fonctionnels**, avec ici surtout `Post` et `Site` ;
+- les modules partagés (`Kernel`, `Identity`, `Settings`, `AuditLog`, `Notifications`, `Taxonomy`, `Media`) viennent de `netslim-core` ;
+- chaque domaine suit la même structure : `Application`, `Domain`, `Infrastructure`, `UI` ;
+- l'application sert de cas réel pour faire vivre le socle partagé dans un projet éditorial.
+
+## Ce qu'il faut comprendre la première heure
+
+Si tu dois vite te repérer, concentre-toi sur ces deux flux :
+
+- la **médiathèque** (`Media`) avec son picker intégré à l'éditeur ;
+- la relation explicite `Post ↔ Media` via `data-media-id` et `post_media` ;
+- le tableau de bord `/admin` et les pages `/admin/settings`, `/admin/audit-log`, `/admin/notifications`, qui montrent comment le blog intègre les modules transverses du core.
+
+Ils donnent une bonne vision de l'état actuel du projet : modularité, ports inter-domaines, UI admin et coordination frontend/backend.
+
+## Ordre de lecture conseillé
+
+1. [../README.md](../README.md) pour la vue d'ensemble et le démarrage rapide
+2. [ARCHITECTURE.md](ARCHITECTURE.md) pour comprendre la structure du dépôt
+3. `public/index.php`, `bootstrap.php`, puis `vendor/netig/netslim-core/src/Kernel/Runtime/Bootstrap.php`, `vendor/netig/netslim-core/src/Kernel/Runtime/RuntimePaths.php`, `vendor/netig/netslim-core/src/Kernel/Runtime/DI/container.php`, `vendor/netig/netslim-core/src/Kernel/Runtime/Http/`, `vendor/netig/netslim-core/src/Kernel/Runtime/Routing/Routes.php`
+4. `src/Site/` puis `src/Post/` pour suivre les modules locaux
+5. `vendor/netig/netslim-core/src/Settings/`, `AuditLog/`, `Notifications/` et `Media/` pour comprendre les briques transverses démontrées par le blog
+6. [FRONTEND.md](FRONTEND.md) si tu touches à Twig, SCSS ou à l'éditeur
+7. [DEVELOPMENT.md](DEVELOPMENT.md) pour le workflow quotidien
+
+## Comment lire un domaine
+
+Parcourir un domaine dans cet ordre :
+
+1. `UI/Http/Routes.php`
+2. `UI/Http/*Controller.php`
+3. `Application/`
+4. `Domain/`
+5. `Infrastructure/`
+
+Ce parcours part d'une route ou d'un écran réel, puis remonte vers les cas d'usage et les implémentations.
+
+## Première modification conseillée
+
+Choisir une évolution **petite mais verticale** dans un domaine existant. Par exemple :
+
+- ajuster un message ou un champ dans `/admin/settings` ;
+- modifier un partial Twig partagé ;
+- faire une petite évolution dans `Post` ou `Site` ;
+- ajuster un style ou un comportement lié à la médiathèque.
+
+Éviter comme première tâche :
+
+- un nouveau domaine complet ;
+- une modification transverse dans `netslim-core` sans avoir d'abord compris son impact ;
+- un changement d'architecture ;
+- une abstraction générique "pour préparer plus tard".
+
+## Ce qu'il faut garder en tête
+
+- un service applicatif sert de façade ; les workflows sensibles vivent dans des use cases dédiés ;
+- un contrôleur traduit HTTP vers l'application ;
+- `Infrastructure/` contient les implémentations concrètes ;
+- le code transverse vient du package `netslim-core` ;
+- le frontend reste simple, mais les écrans riches ont leurs scripts dédiés dans `assets/js/`, puis copiés dans `public/assets/js/` au build.
+
+## Après la première lecture
+
+Quand tu te sens à l'aise :
+
+- passe à [DEVELOPMENT.md](DEVELOPMENT.md) pour le travail quotidien ;
+- garde [ARCHITECTURE.md](ARCHITECTURE.md) comme document de référence avant une évolution structurelle ;
+- ouvre [FRONTEND.md](FRONTEND.md) avant de toucher à l'éditeur, à la modale de médiathèque ou aux assets.

docs/README.md

@@ -0,0 +1,37 @@
+# Documentation
+
+> Cette application nécessite une version récente de `netig/netslim-core` exposant les modules `Settings`, `AuditLog`, `Notifications` et l'authorization fine d'`Identity`. En cas d'erreur sur `SettingsModule` ou `SettingsReaderInterface`, mets d'abord à jour le dépôt du core puis relance `composer update netig/netslim-core`.
+
+Ce dossier rassemble les documents utiles pour travailler sur `netslim-blog`.
+
+## Par où commencer ?
+
+- **Je découvre le projet** → [../README.md](../README.md)
+- **Je dois comprendre vite comment il est organisé** → [ONBOARDING.md](ONBOARDING.md)
+- **Je veux comprendre l'application livrée** → [APPLICATION.md](APPLICATION.md)
+- **Je veux comprendre le rôle du core et du code local** → [ARCHITECTURE.md](ARCHITECTURE.md)
+- **Je travaille au quotidien sur le dépôt** → [DEVELOPMENT.md](DEVELOPMENT.md)
+- **Je touche à Twig, SCSS ou JavaScript d’écran** → [FRONTEND.md](FRONTEND.md)
+- **Je prépare un déploiement Docker** → [DEPLOYMENT.md](DEPLOYMENT.md)
+- **Je veux connaître les garde-fous de long terme** → [MAINTENANCE.md](MAINTENANCE.md)
+- **Je contribue au dépôt** → [../CONTRIBUTING.md](../CONTRIBUTING.md)
+
+## Si tu ne lis que trois documents
+
+1. [../README.md](../README.md)
+2. [ONBOARDING.md](ONBOARDING.md)
+3. [ARCHITECTURE.md](ARCHITECTURE.md)
+
+## Rôle de chaque document
+
+| Document | Rôle |
+|---|---|
+| [../README.md](../README.md) | Vue d'ensemble, démarrage rapide, modules activés |
+| [ONBOARDING.md](ONBOARDING.md) | Parcours de découverte du dépôt |
+| [ARCHITECTURE.md](ARCHITECTURE.md) | Frontière entre le blog et `netslim-core` |
+| [APPLICATION.md](APPLICATION.md) | Vue d'ensemble de l'application blog livrée |
+| [DEVELOPMENT.md](DEVELOPMENT.md) | Guide de travail quotidien et checklist avant push |
+| [FRONTEND.md](FRONTEND.md) | Référence Twig, SCSS, JavaScript d'écran |
+| [DEPLOYMENT.md](DEPLOYMENT.md) | Déploiement Docker et répertoires persistants |
+| [MAINTENANCE.md](MAINTENANCE.md) | Garde-fous pour faire évoluer le dépôt sans le dégrader |
+| [../CONTRIBUTING.md](../CONTRIBUTING.md) | Règles de contribution |