# Architecture de netslim-core

`netslim-core` fournit un noyau technique et des modules réutilisables pour plusieurs applications.

## Contenu du package

- `src/Kernel/` : bootstrap, runtime, container DI, routing, migrations, Twig, checks de démarrage.
- `src/Identity/` : identité, authentification, comptes, autorisation et reset de mot de passe.
- `src/Settings/` : paramètres applicatifs clé / valeur typés.
- `src/AuditLog/` : journalisation des actions transverses.
- `src/Notifications/` : envoi et suivi des emails transactionnels.
- `src/Taxonomy/` : taxonomie réutilisable et contrats publics associés.
- `src/Media/` : médiathèque partagée et contrats publics associés.

## Principes

- un seul runtime applicatif par projet consommateur ;
- les projets consommateurs possèdent leurs templates, assets, points d’entrée HTTP et leurs modules métier propres ;
- tous les chemins runtime persistants (logs, cache, base SQLite, médias) sont résolus depuis le projet consommateur ;
- les dépendances inter-modules passent par des contrats publics minimaux ;
- le noyau ne connaît pas le métier applicatif des projets consommateurs ;
- les exigences d'environnement métier (par exemple le provisionnement admin d'`Identity`) restent portées par les modules concernés, pas par le bootstrap du noyau.

## Surface publique et frontière package / application

Le package expose comme points d'intégration :
- `Netig\Netslim\Kernel\Runtime\...` pour le bootstrap et le runtime ;
- les interfaces applicatives publiques des modules partagés ;
- les contrats publics sous `*/Contracts/` ;
- les classes `*Module`.

Les implémentations `Infrastructure/`, les repositories PDO, les détails de wiring et les templates internes doivent être considérés comme des détails d'implémentation. Voir aussi `docs/PUBLIC_API.md`.

## Responsabilités d'une application consommatrice

Une application qui consomme `netslim-core` doit fournir :
- un manifeste de modules (`config/modules.php`) ;
- un point d'entrée HTTP ;
- les templates réellement applicatifs ;
- les assets attendus par les layouts et écrans qu'elle utilise.

Contrats implicites actuels côté UI :
- `@Kernel/layout.twig` attend `/assets/css/main.css` ;
- l'écran admin de `Media` attend `/assets/js/media-admin.js` côté projet consommateur ;
- `Identity` ne suppose pas la présence d'un module éditorial : la destination back-office se règle via `ADMIN_HOME_PATH` (défaut : `/admin`).

Contraintes d'environnement côté modules :
- `Identity` requiert `ADMIN_*` uniquement si le projet exécute le provisionnement initial du compte administrateur ;
- `Notifications` requiert les variables `MAIL_*` seulement si l'application active l'envoi réel d'emails transactionnels.

> Quand `netslim-core` est installé via Composer, les chemins runtime détectent automatiquement la racine du projet consommateur pour les scripts CLI et les suites de tests qui n'appellent pas explicitement `Bootstrap::create()`.