Créer un pivot financier structuré depuis les preuves et observations bancaires #110

New issue

Open

opened 2026-08-02 09:48:56 +02:00 by fy59 · 0 comments

fy59 commented 2026-08-02 09:48:56 +02:00

Owner

Copy link

Contexte

Labfy Investigation dispose déjà de plusieurs briques historiques liées aux
coordonnées bancaires :

• bank_proposal ;
• iban_analyzer ;
• rib_ocr ;
• extraction de propositions IBAN/BIC depuis les analyses EML, PDF ou OCR ;
• promotion manuelle de certaines observations vers les entités du graphe.

Ces composants ont été développés à différentes étapes du projet et peuvent
faire double emploi ou ne plus correspondre au modèle de traçabilité actuel.

Le besoin opérationnel est désormais plus large : une preuve peut contenir
plusieurs coordonnées bancaires, plusieurs titulaires déclarés et plusieurs
transactions observées. Une même coordonnée peut également apparaître dans
plusieurs preuves.

Le logiciel doit permettre de construire un pivot financier traçable sans
confondre :

• le texte brut observé ;
• une proposition extraite automatiquement ;
• une valeur corrigée par l’utilisateur ;
• un compte bancaire structuré ;
• un titulaire simplement déclaré dans une preuve ;
• une personne réellement identifiée ;
• une transaction affichée dans une capture ;
• l’auteur présumé de l’infraction.

Aucune de ces associations ne doit être déduite automatiquement.

Objectif

Créer un pivot financier structuré, centré sur les preuves, permettant :

1. d’extraire plusieurs coordonnées bancaires depuis une même preuve ;
2. de conserver les observations brutes même lorsqu’elles sont invalides,
   incomplètes ou ambiguës ;
3. de corriger et confirmer chaque proposition séparément ;
4. de créer ou réutiliser explicitement un compte bancaire dans le graphe ;
5. de rattacher un titulaire déclaré sans en faire automatiquement le
   propriétaire réel ;
6. de représenter une transaction observée avec ses comptes débiteur et
   créditeur ;
7. de retrouver toute la provenance depuis le compte, la personne, la
   transaction et la preuve ;
8. de remplacer proprement les anciens parcours bancaires redondants.

Audit préalable obligatoire

Avant toute modification, inventorier intégralement :

• include/core/bank_proposal.h
• src/core/bank_proposal.c
• include/core/iban_analyzer.h
• src/core/iban_analyzer.c
• include/core/rib_ocr.h
• src/core/rib_ocr.c
• les raccordements dans application.c ;
• le pipeline EML ;
• les observations EML ;
• les types d’entités bancaires ;
• les relations existantes ;
• les migrations SQLite ;
• les tests bancaires, OCR, EML et graphe ;
• la documentation.

Produire une matrice :

• CONSERVER ;
• REFACTORISER ;
• REMPLACER ;
• SUPPRIMER ;
• MIGRER.

Les validateurs bas niveau corrects, notamment MOD-97 et validation BIC,
peuvent être conservés.

À la fin du ticket, il ne doit pas rester deux API concurrentes accomplissant
la même fonction ni deux parcours GTK différents pour promouvoir un IBAN.

Aucune suppression ne doit intervenir avant :

• inventaire des appelants ;
• tests de non-régression ;
• stratégie de migration ;
• remplacement fonctionnel effectif.

Principes métier

Observation bancaire

Une observation bancaire correspond à ce qui est réellement visible ou
extractible dans une preuve.

Elle doit pouvoir conserver séparément :

• texte brut immuable ;
• IBAN brut ;
• IBAN corrigé ;
• IBAN normalisé ;
• BIC brut ;
• BIC corrigé et normalisé ;
• titulaire déclaré brut ;
• titulaire déclaré corrigé ;
• banque déclarée ;
• adresse bancaire déclarée ;
• type de source ;
• preuve source ;
• page ou image source ;
• OcrRun facultatif ;
• zone ou coordonnées OCR lorsqu’elles existent ;
• date de création ;
• origine automatique ou humaine ;
• notes factuelles.

Une observation invalide ne doit pas être détruite.

Exemple : un IBAN incomplet ou comportant un caractère douteux reste une
observation exploitable avec un statut invalid, ambiguous ou
unverifiable.

Validation technique

Prévoir des états distincts :

• valid
• invalid
• ambiguous
• unverifiable

La validation technique ne constitue ni une confirmation du titulaire, ni une
preuve d’utilisation du compte, ni une preuve d’identité.

Décision humaine

Prévoir des états de traitement distincts :

• proposed
• confirmed
• rejected

Le passage à confirmed exige une action explicite.

Le rejet ne supprime pas l’observation brute.

Compte bancaire structuré

Un compte bancaire structuré ne peut être créé qu’à partir :

• d’un IBAN corrigé et techniquement valide ;
• ou d’une saisie manuelle explicitement confirmée.

Le compte doit être intégré au système d’entités canonique du graphe, avec une
extension métier dédiée plutôt qu’un second système d’entités parallèle.

Prévoir au minimum :

• entity_id canonique ;
• IBAN normalisé ;
• pays ;
• données BBAN dérivées lorsque pertinentes ;
• BIC facultatif ;
• établissement déclaré facultatif ;
• statut actif/inconnu/clos si le vocabulaire existe réellement ;
• première et dernière observation ;
• notes factuelles.

L’IBAN normalisé doit être unique dans une enquête pour les comptes confirmés.

Lorsqu’il existe déjà, l’interface propose sa réutilisation sans l’imposer.

Titulaire déclaré

Le nom voisin d’un IBAN dans une capture ou un document constitue un
titulaire déclaré, pas une identité vérifiée.

L’utilisateur doit pouvoir :

• ne créer aucun titulaire ;
• sélectionner une personne existante ;
• créer une nouvelle personne prudente ;
• enregistrer une relation factuelle de titulaire déclaré.

Le logiciel ne doit jamais fusionner deux personnes parce que leurs noms sont
identiques.

Le logiciel ne doit jamais attribuer automatiquement le compte à
Auteur présumé.

Transactions financières observées

Permettre de représenter une transaction observée dans une preuve, notamment
un virement affiché par une application bancaire.

Champs attendus, selon disponibilité :

• type de transaction ;
• date et heure observées ;
• montant ;
• devise ;
• statut affiché ;
• référence bancaire ;
• type de référence, notamment UETR lorsqu’indiqué ;
• compte débiteur ;
• compte créditeur ;
• payeur déclaré ;
• bénéficiaire déclaré ;
• établissement ou application source ;
• preuve source ;
• observation bancaire source ;
• notes factuelles ;
• origine humaine.

Une transaction affichée comme « envoyée », « exécutée » ou « reçue » doit
être enregistrée comme statut observé dans la preuve, sans transformer
l’affichage en certification bancaire indépendante.

Utiliser le système d’événements ou de chronologie canonique lorsqu’il est
compatible. Ne pas créer un second moteur de chronologie.

Extraction depuis les preuves

Prendre en charge au minimum :

• texte manuel ;
• texte EML ;
• corps et pièces jointes EML ;
• PDF texte ;
• résultat OCR d’image ;
• résultat OCR d’une page PDF ;
• capture contenant plusieurs blocs bancaires ;
• IBAN séparé sur plusieurs lignes ;
• espaces, tirets et ponctuation ;
• BIC de 8 ou 11 caractères ;
• plusieurs IBAN associés au même nom déclaré ;
• plusieurs titulaires déclarés dans une même preuve.

Une preuve doit pouvoir produire zéro, une ou plusieurs propositions.

Ne jamais limiter le résultat au premier IBAN trouvé.

L’association automatique par proximité entre un IBAN, un BIC et un nom
constitue uniquement une proposition modifiable.

Chaque bloc proposé doit pouvoir être séparé, fusionné ou corrigé par
l’utilisateur avant confirmation.

Interface GTK

Ajouter depuis la fiche de preuve une action claire :

Analyser les données bancaires

L’interface doit proposer :

• aperçu de la preuve ;
• liste de toutes les propositions ;
• texte brut visible ;
• IBAN corrigé et normalisé ;
• résultat de validation ;
• BIC ;
• titulaire déclaré ;
• provenance et zone source ;
• sélection indépendante de chaque proposition ;
• création ou réutilisation d’un compte ;
• création facultative d’une relation de titulaire déclaré ;
• création facultative d’une transaction observée ;
• résumé final avant écriture ;
• annulation sans écriture.

Aucune case de création d’entité, relation, personne ou transaction ne doit
être cochée par défaut.

Les opérations longues doivent être asynchrones, annulables et protégées
contre :

• fermeture de la fenêtre ;
• changement d’InvestigationSession ;
• résultat tardif ;
• preuve modifiée ;
• divergence SHA-256.

Consultation

Depuis la fiche d’une preuve, afficher :

• observations bancaires ;
• propositions rejetées ou confirmées ;
• comptes créés ou réutilisés ;
• titulaires déclarés ;
• transactions associées.

Depuis la fiche d’un compte, afficher :

• toutes les preuves où il apparaît ;
• toutes les observations ;
• toutes les variantes brutes ;
• tous les titulaires déclarés ;
• toutes les transactions ;
• dates de première et dernière observation.

Depuis la fiche d’une personne, afficher uniquement les liens factuels
explicitement créés.

Depuis une transaction, permettre de remonter aux comptes, participants
déclarés et preuves.

Provenance et intégrité

Pour chaque donnée confirmée, conserver :

• preuve source ;
• empreinte SHA-256 contrôlée ;
• observation brute ;
• correction humaine ;
• méthode d’extraction ;
• OcrRun facultatif ;
• page et zone source ;
• date UTC ;
• utilisateur ou origine human ;
• compte créé ou réutilisé ;
• relation créée ;
• transaction créée.

Les valeurs brutes doivent être append-only.

Les corrections et confirmations ne doivent jamais écraser la valeur brute.

Aucun fichier original ne doit être modifié.

Transactions SQLite

La confirmation finale doit être atomique pour :

• observations retenues ;
• comptes créés ;
• comptes réutilisés ;
• personnes éventuellement créées ;
• relations factuelles ;
• transactions ;
• événements de chronologie ;
• provenance.

En cas d’échec :

• rollback complet ;
• aucune entité orpheline ;
• aucune relation orpheline ;
• aucune transaction partielle ;
• aucune observation faussement confirmée ;
• aucune copie temporaire présentée comme définitive.

Migration

Le schéma courant étant V20, créer une migration V21 si le modèle nécessite de
nouvelles tables.

Vérifier :

• database/schema_v21.sql ;
• database/schema_current.sql autonome ;
• version courante déclarée ;
• migration V20→V21 ;
• création directe V21 ;
• rollback de migration ;
• reprise après échec ;
• deuxième ouverture ;
• clés étrangères ;
• index ;
• contraintes CHECK ;
• triggers append-only.

Les observations bancaires historiques ne doivent pas être supprimées.

Lorsqu’une migration automatique vers le nouveau modèle est sûre, la réaliser.

Lorsqu’elle est ambiguë, conserver les données historiques lisibles avec une
origine legacy, sans créer automatiquement un compte ou une relation.

Suppression de l’ancien socle

Après mise en place du nouveau parcours :

• supprimer les API bancaires devenues réellement redondantes ;
• supprimer les raccordements GTK obsolètes ;
• adapter le pipeline EML au nouveau modèle ;
• conserver les validateurs bas niveau utiles ;
• mettre à jour les tests ;
• vérifier l’absence de références mortes ;
• ne laisser aucun ancien bouton ou parcours parallèle.

La suppression porte sur le code obsolète, jamais sur les preuves ou
observations historiques.

Automatismes interdits

Ne jamais créer automatiquement :

• une personne ;
• un titulaire réel ;
• une relation de propriété ;
• une relation vers l’auteur présumé ;
• une transaction ;
• un rôle accusatoire ;
• une conclusion de fraude ;
• une conclusion de blanchiment ;
• une conclusion de mule bancaire ;
• une fusion de comptes ou de personnes.

Les propositions automatiques doivent rester clairement identifiées comme
propositions.

Tests obligatoires

Utiliser exclusivement des fixtures SPECIMEN synthétiques.

Couvrir au minimum :

• trois IBAN dans une même image synthétique ;
• deux IBAN associés au même titulaire déclaré ;
• un troisième IBAN associé à un autre titulaire ;
• IBAN français sur plusieurs lignes ;
• IBAN techniquement invalide conservé comme observation ;
• correction humaine transformant une proposition ambiguë en IBAN valide ;
• BIC 8 caractères ;
• BIC 11 caractères ;
• absence de BIC ;
• absence de titulaire ;
• même IBAN observé dans plusieurs preuves ;
• suggestion de réutilisation du compte existant ;
• refus de fusion automatique ;
• mêmes noms avec personnes différentes ;
• transaction débitée d’un compte et créditée sur un autre ;
• référence UETR synthétique ;
• statut affiché distinct d’une certification externe ;
• rejet d’une proposition sans suppression du brut ;
• preuve dont le SHA-256 a changé ;
• OcrRun étranger à la preuve ;
• annulation ;
• fermeture pendant analyse ;
• changement de session ;
• rollback à chaque étape critique ;
• réouverture SQLite ;
• migration V20→V21 ;
• création directe V21 ;
• absence de tout automatisme interdit.

Les tests GTK finaux doivent être exécutés sous Wayland/Sway réel avec :

G_DEBUG=fatal-criticals
timeout 30s

Aucun test GTK final ne doit être SKIP.

Exécuter également une matrice ASan/UBSan ciblée avec les binaires sous /tmp.
Ne pas revendiquer LeakSanitizer lorsqu’il est désactivé.

Contraintes d’architecture

• C17 ;
• aucun SQL dans les widgets GTK ;
• modèles indépendants de GTK et SQLite ;
• services métier indépendants de GTK ;
• DAO canoniques ;
• aucune commande shell construite dynamiquement ;
• make -j8 pour les compilations parallélisables ;
• aucun nouveau fichier .c supérieur à 2 000 lignes ;
• ne pas augmenter les plafonds historiques ;
• ne pas ajouter de logique supplémentaire à application.c ;
• extraire les responsabilités dans des modules spécialisés.

Sécurité des données de développement

Codex et les agents locaux travaillent uniquement avec :

• le dépôt source ;
• des fixtures synthétiques ;
• des bases SQLite temporaires ;
• des fichiers sous /tmp.

Ils ne doivent jamais consulter :

• Enquete.sqlite réel ;
• une copie de l’enquête réelle ;
• le dossier enquête test ;
• les captures réelles ;
• les IBAN réels ;
• les identités réelles ;
• les EML réels ;
• les PDF ou vidéos réels.

La validation sur la copie de l’enquête réelle sera effectuée manuellement par
le propriétaire du projet après validation des tests synthétiques.

Documentation

Mettre à jour au minimum :

• README.md
• CHANGELOG.md
• docs/ARCHITECTURE.md
• docs/DEVELOPMENT.md
• docs/ROADMAP.md
• docs/database/DATABASE_ARCHITECTURE.md
• docs/database/SCHEMA_AUDIT_CURRENT.md

Documenter :

• la distinction observation/proposition/compte/relation/transaction ;
• les données invalides conservées ;
• la confirmation humaine ;
• la provenance ;
• la migration V21 ;
• le retrait de l’ancien parcours bancaire ;
• les limites et automatismes interdits.

Critères d’acceptation

Le ticket est terminé lorsque :

• une preuve peut produire plusieurs observations bancaires ;
• un IBAN invalide ou ambigu reste conservé sans être promu ;
• chaque proposition est corrigée et confirmée indépendamment ;
• un compte existant peut être réutilisé explicitement ;
• un titulaire déclaré reste distinct d’un propriétaire vérifié ;
• une transaction observée peut relier comptes débiteur et créditeur ;
• toute donnée structurée remonte à sa preuve et à sa valeur brute ;
• aucune association avec l’auteur présumé n’est automatique ;
• l’ancien code redondant a été supprimé ou justifié ;
• migration et création directe passent ;
• rollback et réouverture passent ;
• tous les tests non GTK et GTK passent ;
• ASan/UBSan ciblé passe ;
• make check-source-size passe ;
• la documentation correspond au code ;
• la validation manuelle finale est demandée avant commit et push.

Validation finale

Exécuter :

make clean
make -j8
make check-source-size
DISPLAY="$DISPLAY" WAYLAND_DISPLAY="$WAYLAND_DISPLAY" make -j8 test
git diff --check

Ne créer aucun commit et ne pousser aucune modification avant validation
manuelle.

## Contexte Labfy Investigation dispose déjà de plusieurs briques historiques liées aux coordonnées bancaires : - `bank_proposal` ; - `iban_analyzer` ; - `rib_ocr` ; - extraction de propositions IBAN/BIC depuis les analyses EML, PDF ou OCR ; - promotion manuelle de certaines observations vers les entités du graphe. Ces composants ont été développés à différentes étapes du projet et peuvent faire double emploi ou ne plus correspondre au modèle de traçabilité actuel. Le besoin opérationnel est désormais plus large : une preuve peut contenir plusieurs coordonnées bancaires, plusieurs titulaires déclarés et plusieurs transactions observées. Une même coordonnée peut également apparaître dans plusieurs preuves. Le logiciel doit permettre de construire un pivot financier traçable sans confondre : - le texte brut observé ; - une proposition extraite automatiquement ; - une valeur corrigée par l’utilisateur ; - un compte bancaire structuré ; - un titulaire simplement déclaré dans une preuve ; - une personne réellement identifiée ; - une transaction affichée dans une capture ; - l’auteur présumé de l’infraction. Aucune de ces associations ne doit être déduite automatiquement. ## Objectif Créer un pivot financier structuré, centré sur les preuves, permettant : 1. d’extraire plusieurs coordonnées bancaires depuis une même preuve ; 2. de conserver les observations brutes même lorsqu’elles sont invalides, incomplètes ou ambiguës ; 3. de corriger et confirmer chaque proposition séparément ; 4. de créer ou réutiliser explicitement un compte bancaire dans le graphe ; 5. de rattacher un titulaire déclaré sans en faire automatiquement le propriétaire réel ; 6. de représenter une transaction observée avec ses comptes débiteur et créditeur ; 7. de retrouver toute la provenance depuis le compte, la personne, la transaction et la preuve ; 8. de remplacer proprement les anciens parcours bancaires redondants. ## Audit préalable obligatoire Avant toute modification, inventorier intégralement : - `include/core/bank_proposal.h` - `src/core/bank_proposal.c` - `include/core/iban_analyzer.h` - `src/core/iban_analyzer.c` - `include/core/rib_ocr.h` - `src/core/rib_ocr.c` - les raccordements dans `application.c` ; - le pipeline EML ; - les observations EML ; - les types d’entités bancaires ; - les relations existantes ; - les migrations SQLite ; - les tests bancaires, OCR, EML et graphe ; - la documentation. Produire une matrice : - CONSERVER ; - REFACTORISER ; - REMPLACER ; - SUPPRIMER ; - MIGRER. Les validateurs bas niveau corrects, notamment MOD-97 et validation BIC, peuvent être conservés. À la fin du ticket, il ne doit pas rester deux API concurrentes accomplissant la même fonction ni deux parcours GTK différents pour promouvoir un IBAN. Aucune suppression ne doit intervenir avant : - inventaire des appelants ; - tests de non-régression ; - stratégie de migration ; - remplacement fonctionnel effectif. ## Principes métier ### Observation bancaire Une observation bancaire correspond à ce qui est réellement visible ou extractible dans une preuve. Elle doit pouvoir conserver séparément : - texte brut immuable ; - IBAN brut ; - IBAN corrigé ; - IBAN normalisé ; - BIC brut ; - BIC corrigé et normalisé ; - titulaire déclaré brut ; - titulaire déclaré corrigé ; - banque déclarée ; - adresse bancaire déclarée ; - type de source ; - preuve source ; - page ou image source ; - OcrRun facultatif ; - zone ou coordonnées OCR lorsqu’elles existent ; - date de création ; - origine automatique ou humaine ; - notes factuelles. Une observation invalide ne doit pas être détruite. Exemple : un IBAN incomplet ou comportant un caractère douteux reste une observation exploitable avec un statut `invalid`, `ambiguous` ou `unverifiable`. ### Validation technique Prévoir des états distincts : - `valid` - `invalid` - `ambiguous` - `unverifiable` La validation technique ne constitue ni une confirmation du titulaire, ni une preuve d’utilisation du compte, ni une preuve d’identité. ### Décision humaine Prévoir des états de traitement distincts : - `proposed` - `confirmed` - `rejected` Le passage à `confirmed` exige une action explicite. Le rejet ne supprime pas l’observation brute. ### Compte bancaire structuré Un compte bancaire structuré ne peut être créé qu’à partir : - d’un IBAN corrigé et techniquement valide ; - ou d’une saisie manuelle explicitement confirmée. Le compte doit être intégré au système d’entités canonique du graphe, avec une extension métier dédiée plutôt qu’un second système d’entités parallèle. Prévoir au minimum : - `entity_id` canonique ; - IBAN normalisé ; - pays ; - données BBAN dérivées lorsque pertinentes ; - BIC facultatif ; - établissement déclaré facultatif ; - statut actif/inconnu/clos si le vocabulaire existe réellement ; - première et dernière observation ; - notes factuelles. L’IBAN normalisé doit être unique dans une enquête pour les comptes confirmés. Lorsqu’il existe déjà, l’interface propose sa réutilisation sans l’imposer. ### Titulaire déclaré Le nom voisin d’un IBAN dans une capture ou un document constitue un **titulaire déclaré**, pas une identité vérifiée. L’utilisateur doit pouvoir : - ne créer aucun titulaire ; - sélectionner une personne existante ; - créer une nouvelle personne prudente ; - enregistrer une relation factuelle de titulaire déclaré. Le logiciel ne doit jamais fusionner deux personnes parce que leurs noms sont identiques. Le logiciel ne doit jamais attribuer automatiquement le compte à `Auteur présumé`. ### Transactions financières observées Permettre de représenter une transaction observée dans une preuve, notamment un virement affiché par une application bancaire. Champs attendus, selon disponibilité : - type de transaction ; - date et heure observées ; - montant ; - devise ; - statut affiché ; - référence bancaire ; - type de référence, notamment UETR lorsqu’indiqué ; - compte débiteur ; - compte créditeur ; - payeur déclaré ; - bénéficiaire déclaré ; - établissement ou application source ; - preuve source ; - observation bancaire source ; - notes factuelles ; - origine humaine. Une transaction affichée comme « envoyée », « exécutée » ou « reçue » doit être enregistrée comme **statut observé dans la preuve**, sans transformer l’affichage en certification bancaire indépendante. Utiliser le système d’événements ou de chronologie canonique lorsqu’il est compatible. Ne pas créer un second moteur de chronologie. ## Extraction depuis les preuves Prendre en charge au minimum : - texte manuel ; - texte EML ; - corps et pièces jointes EML ; - PDF texte ; - résultat OCR d’image ; - résultat OCR d’une page PDF ; - capture contenant plusieurs blocs bancaires ; - IBAN séparé sur plusieurs lignes ; - espaces, tirets et ponctuation ; - BIC de 8 ou 11 caractères ; - plusieurs IBAN associés au même nom déclaré ; - plusieurs titulaires déclarés dans une même preuve. Une preuve doit pouvoir produire zéro, une ou plusieurs propositions. Ne jamais limiter le résultat au premier IBAN trouvé. L’association automatique par proximité entre un IBAN, un BIC et un nom constitue uniquement une proposition modifiable. Chaque bloc proposé doit pouvoir être séparé, fusionné ou corrigé par l’utilisateur avant confirmation. ## Interface GTK Ajouter depuis la fiche de preuve une action claire : `Analyser les données bancaires` L’interface doit proposer : - aperçu de la preuve ; - liste de toutes les propositions ; - texte brut visible ; - IBAN corrigé et normalisé ; - résultat de validation ; - BIC ; - titulaire déclaré ; - provenance et zone source ; - sélection indépendante de chaque proposition ; - création ou réutilisation d’un compte ; - création facultative d’une relation de titulaire déclaré ; - création facultative d’une transaction observée ; - résumé final avant écriture ; - annulation sans écriture. Aucune case de création d’entité, relation, personne ou transaction ne doit être cochée par défaut. Les opérations longues doivent être asynchrones, annulables et protégées contre : - fermeture de la fenêtre ; - changement d’InvestigationSession ; - résultat tardif ; - preuve modifiée ; - divergence SHA-256. ## Consultation Depuis la fiche d’une preuve, afficher : - observations bancaires ; - propositions rejetées ou confirmées ; - comptes créés ou réutilisés ; - titulaires déclarés ; - transactions associées. Depuis la fiche d’un compte, afficher : - toutes les preuves où il apparaît ; - toutes les observations ; - toutes les variantes brutes ; - tous les titulaires déclarés ; - toutes les transactions ; - dates de première et dernière observation. Depuis la fiche d’une personne, afficher uniquement les liens factuels explicitement créés. Depuis une transaction, permettre de remonter aux comptes, participants déclarés et preuves. ## Provenance et intégrité Pour chaque donnée confirmée, conserver : - preuve source ; - empreinte SHA-256 contrôlée ; - observation brute ; - correction humaine ; - méthode d’extraction ; - OcrRun facultatif ; - page et zone source ; - date UTC ; - utilisateur ou origine `human` ; - compte créé ou réutilisé ; - relation créée ; - transaction créée. Les valeurs brutes doivent être append-only. Les corrections et confirmations ne doivent jamais écraser la valeur brute. Aucun fichier original ne doit être modifié. ## Transactions SQLite La confirmation finale doit être atomique pour : - observations retenues ; - comptes créés ; - comptes réutilisés ; - personnes éventuellement créées ; - relations factuelles ; - transactions ; - événements de chronologie ; - provenance. En cas d’échec : - rollback complet ; - aucune entité orpheline ; - aucune relation orpheline ; - aucune transaction partielle ; - aucune observation faussement confirmée ; - aucune copie temporaire présentée comme définitive. ## Migration Le schéma courant étant V20, créer une migration V21 si le modèle nécessite de nouvelles tables. Vérifier : - `database/schema_v21.sql` ; - `database/schema_current.sql` autonome ; - version courante déclarée ; - migration V20→V21 ; - création directe V21 ; - rollback de migration ; - reprise après échec ; - deuxième ouverture ; - clés étrangères ; - index ; - contraintes CHECK ; - triggers append-only. Les observations bancaires historiques ne doivent pas être supprimées. Lorsqu’une migration automatique vers le nouveau modèle est sûre, la réaliser. Lorsqu’elle est ambiguë, conserver les données historiques lisibles avec une origine `legacy`, sans créer automatiquement un compte ou une relation. ## Suppression de l’ancien socle Après mise en place du nouveau parcours : - supprimer les API bancaires devenues réellement redondantes ; - supprimer les raccordements GTK obsolètes ; - adapter le pipeline EML au nouveau modèle ; - conserver les validateurs bas niveau utiles ; - mettre à jour les tests ; - vérifier l’absence de références mortes ; - ne laisser aucun ancien bouton ou parcours parallèle. La suppression porte sur le code obsolète, jamais sur les preuves ou observations historiques. ## Automatismes interdits Ne jamais créer automatiquement : - une personne ; - un titulaire réel ; - une relation de propriété ; - une relation vers l’auteur présumé ; - une transaction ; - un rôle accusatoire ; - une conclusion de fraude ; - une conclusion de blanchiment ; - une conclusion de mule bancaire ; - une fusion de comptes ou de personnes. Les propositions automatiques doivent rester clairement identifiées comme propositions. ## Tests obligatoires Utiliser exclusivement des fixtures `SPECIMEN` synthétiques. Couvrir au minimum : - trois IBAN dans une même image synthétique ; - deux IBAN associés au même titulaire déclaré ; - un troisième IBAN associé à un autre titulaire ; - IBAN français sur plusieurs lignes ; - IBAN techniquement invalide conservé comme observation ; - correction humaine transformant une proposition ambiguë en IBAN valide ; - BIC 8 caractères ; - BIC 11 caractères ; - absence de BIC ; - absence de titulaire ; - même IBAN observé dans plusieurs preuves ; - suggestion de réutilisation du compte existant ; - refus de fusion automatique ; - mêmes noms avec personnes différentes ; - transaction débitée d’un compte et créditée sur un autre ; - référence UETR synthétique ; - statut affiché distinct d’une certification externe ; - rejet d’une proposition sans suppression du brut ; - preuve dont le SHA-256 a changé ; - OcrRun étranger à la preuve ; - annulation ; - fermeture pendant analyse ; - changement de session ; - rollback à chaque étape critique ; - réouverture SQLite ; - migration V20→V21 ; - création directe V21 ; - absence de tout automatisme interdit. Les tests GTK finaux doivent être exécutés sous Wayland/Sway réel avec : G_DEBUG=fatal-criticals timeout 30s Aucun test GTK final ne doit être SKIP. Exécuter également une matrice ASan/UBSan ciblée avec les binaires sous `/tmp`. Ne pas revendiquer LeakSanitizer lorsqu’il est désactivé. ## Contraintes d’architecture - C17 ; - aucun SQL dans les widgets GTK ; - modèles indépendants de GTK et SQLite ; - services métier indépendants de GTK ; - DAO canoniques ; - aucune commande shell construite dynamiquement ; - `make -j8` pour les compilations parallélisables ; - aucun nouveau fichier `.c` supérieur à 2 000 lignes ; - ne pas augmenter les plafonds historiques ; - ne pas ajouter de logique supplémentaire à `application.c` ; - extraire les responsabilités dans des modules spécialisés. ## Sécurité des données de développement Codex et les agents locaux travaillent uniquement avec : - le dépôt source ; - des fixtures synthétiques ; - des bases SQLite temporaires ; - des fichiers sous `/tmp`. Ils ne doivent jamais consulter : - `Enquete.sqlite` réel ; - une copie de l’enquête réelle ; - le dossier `enquête test` ; - les captures réelles ; - les IBAN réels ; - les identités réelles ; - les EML réels ; - les PDF ou vidéos réels. La validation sur la copie de l’enquête réelle sera effectuée manuellement par le propriétaire du projet après validation des tests synthétiques. ## Documentation Mettre à jour au minimum : - `README.md` - `CHANGELOG.md` - `docs/ARCHITECTURE.md` - `docs/DEVELOPMENT.md` - `docs/ROADMAP.md` - `docs/database/DATABASE_ARCHITECTURE.md` - `docs/database/SCHEMA_AUDIT_CURRENT.md` Documenter : - la distinction observation/proposition/compte/relation/transaction ; - les données invalides conservées ; - la confirmation humaine ; - la provenance ; - la migration V21 ; - le retrait de l’ancien parcours bancaire ; - les limites et automatismes interdits. ## Critères d’acceptation Le ticket est terminé lorsque : - une preuve peut produire plusieurs observations bancaires ; - un IBAN invalide ou ambigu reste conservé sans être promu ; - chaque proposition est corrigée et confirmée indépendamment ; - un compte existant peut être réutilisé explicitement ; - un titulaire déclaré reste distinct d’un propriétaire vérifié ; - une transaction observée peut relier comptes débiteur et créditeur ; - toute donnée structurée remonte à sa preuve et à sa valeur brute ; - aucune association avec l’auteur présumé n’est automatique ; - l’ancien code redondant a été supprimé ou justifié ; - migration et création directe passent ; - rollback et réouverture passent ; - tous les tests non GTK et GTK passent ; - ASan/UBSan ciblé passe ; - `make check-source-size` passe ; - la documentation correspond au code ; - la validation manuelle finale est demandée avant commit et push. ## Validation finale Exécuter : make clean make -j8 make check-source-size DISPLAY="$DISPLAY" WAYLAND_DISPLAY="$WAYLAND_DISPLAY" make -j8 test git diff --check Ne créer aucun commit et ne pousser aucune modification avant validation manuelle.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

No results found.

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: fy59/labfy-investigation#110

No description provided.