# Audit du niveau 3 — Modèle métier canonique et contrats API

## Types déjà trouvés dans `Omika.Core`

L'audit a couvert les dossiers existants et les dossiers créés :

- `Omika.Core/Abstractions` : abstractions techniques existantes.
- `Omika.Core/Constants` : constantes existantes.
- `Omika.Core/Interfaces` : interfaces existantes.
- `Omika.Core/Models` : modèles préexistants (à auditer pour doublons éventuels).
- `Omika.Core/Runtime` : contexte d'exécution (ex. `ApplicationRuntimeContext`),
  sélection de base demandée par la configuration (`DatabaseSchemaSelection`)
  et analyse de configuration (`DatabaseSchemaSelectionParser`).
- `Omika.Core/Compatibility` (créé) : `DatabaseSchemaVersion` (provenance /
  version réellement détectée), `DatabaseSource`, `LegacyEntityReference`,
  `SchemaCapabilities`, `CanonicalMappingResult<T>`.
- `Omika.Core/Domain` (créé) : entités métier, objets de valeur, enums,
  exceptions.
- `Omika.Core/Contracts` (créé) : DTO API.
- `Omika.Core/Mapping` (créé) : mappers entité métier → DTO.

## Types réutilisés

Aucun fichier existant n'a été déplacé. Les dossiers `Interfaces`,
`Abstractions`, `Constants` et `Runtime` ont été **réutilisés tels quels** :
la nouvelle structure `Domain/`, `Contracts/`, `Compatibility/` est ajoutée
**sans déplacer** les classes existantes.

La règle « ne crée pas un deuxième dossier concurrent » a été respectée :
les nouvelles interfaces de service ont été placées dans `Omika.Core/Interfaces`
et non dans un nouveau dossier.

## Doublons évités

- Un seul `RendezVous` canonique (pas de `Planning_RDV` / `RDV_Planning` /
  `RDV_Collaborateur` / `RDV_Contact` métier).
- Un seul `Document` (pas de duplication des classes physiques `DocumentRow`).
- Un seul `Client` (pas de duplication des tables `Client`, `ClientAdresse`,
  `ClientContact`, `ClientSite`).
- Un seul `Intervention` (pas de duplication des tables `Intervention`,
  `ActionIntervention`, `CompteRendu`).
- Les collections métier (adresses, contacts, sites) sont des propriétés de
  l'entité racine, et non des entités séparées dupliquées.
- Pas de table de liaison métier : les références sont portées par des listes
  d'identifiants ou des collections contrôlées.

## Fichiers non déplacés

- Les classes physiques Batik / Omika restent dans `Omika.Data`.
- Les classes de `Omika.Core/Models` existantes n'ont pas été déplacées par
  sécurité : un audit manuel complémentaire est nécessaire pour décider de leur
  sort (doublons éventuels avec `Domain/`).
- Les abstractions techniques de `Abstractions/`, les constantes de
  `Constants/` et le runtime de `Runtime/` restent en place.

## Ambiguïtés

1. **`Omika.Core/Models`** : contient peut-être des DTO ou modèles intermédiaires
   préexistants. Rien n'a été supprimé ; à arbitrer lors du niveau 4.
2. **Interfaces de repository** : la solution ne montre pas de convention claire
   de repository. Les services (`IClientService`, `IInterventionService`,
   `IRendezVousService`, `IDocumentService`, `IReferenceDataService`,
   `ICurrentUserService`) ont été créés dans `Interfaces/`. Les repositories
   seront définis avec l'architecture de données (Omika.Data).
3. **Identifiants publics** : chaînes. Le mobile ne doit pas voir la clé physique ;
   un helper dédié sera ajouté si nécessaire.
4. **`ReferenceValue` vs enums** : les paramètres métier restent configurables.
   Certains statuts pourraient devenir des enums stables ultérieurement.
5. **Dates** : `DateTime` partout ; `DateTimeOffset` seulement si un besoin
   multi-fuseaux est documenté.

## Éléments restant à traiter

- Mapping **physique → métier** dans `Omika.Data` (Batik et Omika) :
  conversion des rubriques préfixées et des champs zombie vers les entités
  canoniques de `Omika.Core.Domain`.
- Implémentation des services métier (`IClientService`, etc.) côté API.
- Décision sur le devenir de `Omika.Core/Models` (fusion ou suppression).
- Contrats de mise à jour des collections (remplacement complet vs diff).
- Sécurité : hachage des mots de passe, sessions, jetons (hors périmètre
  niveau 3).
- Gestion physique des documents (téléversement / téléchargement).