# API publique et API interne de netslim-core

Ce document définit la frontière de support du package `netslim-core`.

## API publique

Les applications consommatrices peuvent dépendre des éléments suivants :

- le namespace `Netig\Netslim\Kernel\Runtime\...` nécessaire au bootstrap, au runtime et à la découverte des modules ;
- les classes `*Module` exposées par les modules partagés (`IdentityModule`, `SettingsModule`, `AuditLogModule`, `NotificationsModule`, `TaxonomyModule`, `MediaModule`, `KernelModule`) ;
- les interfaces applicatives explicitement exposées par les modules (`Identity\Application\*ServiceInterface`, `Settings\Application\SettingsServiceInterface`, `AuditLog\Application\AuditLogServiceInterface`, `Notifications\Application\NotificationServiceInterface`, `Taxonomy\Application\TaxonomyServiceInterface`, `Media\Application\MediaServiceInterface`) ;
- les contrats publics sous `Netig\Netslim\*/Contracts/` ;
- les conventions documentées de `config/modules.php`, `public/index.php` et des chemins runtime résolus côté projet consommateur ;
- les layouts et partials Twig documentés sous `@Kernel/...` quand l'application choisit de les réutiliser.

## API interne

Les éléments suivants doivent être considérés comme des détails d'implémentation du package :

- tout `Infrastructure/` (repositories PDO, stockage local, wiring DI, maintenance post-migration) ;
- tout `Application/UseCase/` et les services applicatifs non documentés comme contrats ;
- les entités de domaine utilisées en interne par les modules ;
- les vérifications de démarrage propres aux modules ;
- les templates Twig non documentés comme points d'intégration.

Une application consommatrice ne devrait pas dépendre directement de ces éléments internes.

## Règle pratique

Quand un projet applicatif a besoin d'une capacité partagée, il doit préférer :

1. un contrat public existant dans `Contracts/` ;
2. à défaut, une extension documentée du runtime ou d'un module ;
3. en dernier recours, une évolution du core qui ajoute un nouveau point d'intégration public.

Éviter de se brancher directement sur des classes internes permet de garder le core petit, lisible et évolutif.