130 lines
5 KiB
Markdown
130 lines
5 KiB
Markdown
# Audit du schéma SQLite courant — V20
|
||
|
||
> **Projet :** Labfy Investigation
|
||
> **Date de l’audit :** 2026-08-02
|
||
> **Branche auditée :** `main`
|
||
> **Version courante :** V20
|
||
> **Statut :** audit courant ; les audits V9 et V10 restent archivés dans
|
||
> `docs/database/audits/`.
|
||
|
||
## 1. Sources de vérité
|
||
|
||
La version 20 est définie par `DATABASE_SCHEMA_VERSION_CURRENT` et
|
||
`DATABASE_SCHEMA_VERSION_CURRENT_TEXT` dans `src/database/database.c`.
|
||
L’état courant est décrit par `database/schema_current.sql`; la migration
|
||
V18→V19 est `database/schema_v19.sql` et V19→V20 est
|
||
`database/schema_v20.sql`. Les fonctions publiques correspondantes
|
||
sont déclarées dans `include/database/schema.h` et implémentées dans
|
||
`src/database/schema.c`.
|
||
|
||
Une base neuve reçoit directement le schéma courant V20 dans la transaction
|
||
d’initialisation. Une base historique est migrée séquentiellement ; le passage
|
||
chaque migration installe son script et ne met à jour `metadata.schema_version`
|
||
qu’avant le `COMMIT`. Un échec entraîne un `ROLLBACK`.
|
||
|
||
## 2. Extensions d’identité V18 conservées
|
||
|
||
V18 ajoute les vocabulaires `identification_status_vocabulary` et
|
||
`person_role_vocabulary`, les évaluations humaines
|
||
`document_authenticity_assessments`, les relations factuelles
|
||
`person_evidence_factual_relations` et l’historique
|
||
`person_identification_assessments`.
|
||
|
||
`identity_field_observations` conserve séparément :
|
||
|
||
- `raw_value`, immuable après extraction ;
|
||
- `normalized_value` ;
|
||
- `corrected_value` ;
|
||
- `confirmed_value` ;
|
||
- `confirmation_state` ;
|
||
- `value_quality`.
|
||
|
||
Les triggers V18 refusent une confirmation sans action humaine ainsi que les
|
||
valeurs rejetées, en conflit, incertaines ou invalides. Les clés et triggers
|
||
vérifient aussi la cohérence preuve/OcrRun des évaluations d’authenticité et
|
||
des relations factuelles.
|
||
|
||
## 3. Extension V19
|
||
|
||
### `person_profile_fields`
|
||
|
||
Cette table porte les champs structurés d’une personne :
|
||
|
||
- `declared_name` ;
|
||
- `surname` ;
|
||
- `given_names` ;
|
||
- `birth_date` ;
|
||
- `birth_place` ;
|
||
- `nationality` ;
|
||
- `sex_as_printed` ;
|
||
- `address_as_printed`.
|
||
|
||
La clé primaire `(person_id, field_code)`, la liste fermée des codes, la valeur
|
||
non vide et la clé étrangère vers `entites` bornent les écritures.
|
||
|
||
### `person_ocr_field_projections`
|
||
|
||
Chaque ligne append-only conserve : personne, champ cible, valeur précédente,
|
||
nouvelle valeur, preuve, OcrRun, champ OCR, code OCR, qualité, statut de
|
||
révision, stratégie, date UTC et origine humaine. Les stratégies persistées
|
||
sont `fill_empty` et `replace_existing`; les qualités sont `complete` ou
|
||
`partial`; les statuts sont `accepted` ou `modified`.
|
||
|
||
L’index `idx_person_projection_person` sert la consultation chronologique.
|
||
Le trigger `projection_v19_consistency` relit le champ OCR lors de l’insertion
|
||
et refuse toute source devenue non projectable ou incohérente.
|
||
|
||
## 4. Atomicité et provenance
|
||
|
||
La V20 ajoute `document_identity_misuse_assessments`. Les trois états fermés
|
||
sont `indeterminate`, `presumed` et `confirmed`. Une justification est imposée
|
||
pour les deux derniers. Les triggers vérifient l’OcrRun, la chaîne précédente,
|
||
interdisent les branches ainsi que tout `UPDATE` ou `DELETE`. L’origine
|
||
persistée est exclusivement `human`.
|
||
|
||
`PersonCreationCoordinator` englobe dans une transaction la personne, ses
|
||
rôles, les preuves et rattachements, les observations OCR, les relations
|
||
factuelles explicites, les champs structurés et leur provenance V19. Les
|
||
copies définitives de preuves disposent d’une compensation si SQLite échoue.
|
||
Le service de projection peut rejoindre une transaction existante ou en ouvrir
|
||
une lorsqu’il est appelé seul.
|
||
|
||
Les historiques d’authenticité, de relations factuelles et de projections ne
|
||
sont ni remplacés ni supprimés silencieusement. Les originaux et les lignes
|
||
OCR sources restent inchangés par une projection.
|
||
|
||
## 5. Création, migration et réouverture vérifiées
|
||
|
||
Les tests couvrent :
|
||
|
||
- création directe d’une base V20 et présence des extensions V19/V20 ;
|
||
- migration historique jusqu’à V20 ;
|
||
- migration V17→V18 avec conservation OCR ;
|
||
- migration V18→V19 ;
|
||
- migration V19→V20 et rollback en cas d’échec ;
|
||
- réouverture SQLite ;
|
||
- cohérence preuve/OcrRun/champ ;
|
||
- source devenue obsolète ;
|
||
- échec au milieu d’une série ;
|
||
- rollback sans profil ni provenance partiels.
|
||
|
||
Commandes de validation :
|
||
|
||
```sh
|
||
make clean
|
||
make -j8
|
||
make check-source-size
|
||
DISPLAY="$DISPLAY" WAYLAND_DISPLAY="$WAYLAND_DISPLAY" make -j8 test
|
||
git diff --check
|
||
```
|
||
|
||
Les fixtures sont exclusivement synthétiques (`SPECIMEN`) et les bases sont
|
||
créées dans des répertoires temporaires.
|
||
|
||
## 6. Limites fonctionnelles hors schéma
|
||
|
||
La collecte des justifications des rôles sensibles et l’usage plus complet de
|
||
`person_identification_assessments` restent des renforcements architecturaux,
|
||
pas des exigences contractuelles explicites du ticket #109. Les états d’usage
|
||
d’identité présumé et confirmé sont désormais modélisés séparément en V20 et
|
||
ne sont pas confondus avec l’authenticité documentaire.
|