fy59/labfy-investigation

Fork 0

Importer une preuve depuis l’interface GTK #50

New issue

Closed

opened 2026-07-19 21:13:26 +02:00 by fy59 · 0 comments

fy59 commented

2026-07-19 21:13:26 +02:00

Owner

Importer une preuve depuis l’interface GTK

Objectif

Permettre à l’utilisateur de démarrer l’import d’un fichier de preuve depuis la fenêtre principale de Labfy Investigation.

Cette fonctionnalité doit relier progressivement l’interface GTK au service métier EvidenceImporter, sans bloquer la boucle principale GTK et sans introduire de dépendance directe entre les widgets et la base SQLite.

Contexte

Le cœur métier de l’import est désormais disponible et testé :

génération d’un identifiant UUID ;
génération d’un nom interne sûr ;
copie vérifiée du fichier ;
calcul et contrôle du SHA-256 ;
création du EvidenceRecord ;
insertion transactionnelle dans SQLite ;
rollback et suppression compensatoire en cas d’échec ;
prise en charge de l’annulation ;
signalement d’un éventuel fichier orphelin.

L’interface actuelle possède :

une MainWindow ;
un Workspace situé dans widgets/ ;
un TaskManager ;
un TaskPanel ;
un système générique de BackgroundTask ;
une session d’enquête active gérée par Application.

Le prochain travail consiste à exposer l’import dans l’interface, sans déplacer la logique métier dans les widgets.

Principe d’architecture

La répartition des responsabilités doit rester la suivante :

`MainWindow`

Responsable uniquement de l’affichage et des événements GTK :

afficher une action compacte « Importer une preuve » ;
activer ou désactiver cette action ;
transmettre le clic à Application par callback ;
ne pas ouvrir directement la base ;
ne pas appeler directement EvidenceImporter.

`Application`

Responsable de l’orchestration :

vérifier qu’une enquête est ouverte ;
ouvrir le sélecteur de fichier ;
récupérer le fichier choisi ;
préparer les chemins de destination ;
créer et lancer une BackgroundTask ;
appeler EvidenceImporter depuis le worker ;
mettre à jour l’état de l’interface à la fin ;
afficher les erreurs dans une boîte de dialogue GTK.

`BackgroundTask`

Responsable de l’exécution hors du thread GTK :

exécuter l’import dans un thread secondaire ;
transporter le GCancellable ;
conserver le résultat ou l’erreur ;
informer le TaskPanel.

`EvidenceImporter`

Reste responsable de toute la logique métier de l’import :

copie ;
hash ;
modèle ;
transaction ;
rollback ;
compensation.

Aucun widget ne doit reproduire cette logique.

Interface utilisateur

Action principale

Ajouter une action compacte dans la barre d’outils de MainWindow.

Caractéristiques :

icône GTK adaptée à l’import ou à l’ajout de fichier ;
infobulle : Importer une preuve;
pas de grand bouton occupant inutilement l’interface ;
action visible dans la barre d’outils principale ;
désactivée lorsqu’aucune enquête n’est ouverte ;
activée lorsqu’une session d’enquête valide est disponible.

Un libellé texte peut être conservé temporairement pendant le développement, mais la version finale doit privilégier une présentation compacte avec icône et infobulle.

Sélection du fichier

Le clic doit ouvrir un sélecteur GTK asynchrone.

Contraintes :

sélection d’un seul fichier ;
pas de sélection de dossier ;
aucune lecture lourde dans le callback GTK ;
annulation silencieuse si l’utilisateur ferme la boîte de dialogue ;
récupération d’un chemin local exploitable ;
refus clair si le fichier ne possède pas de chemin local.

Métadonnées

Dans cette première version, les valeurs minimales suivantes peuvent être utilisées :

type de preuve : document par défaut ;
date de collecte : NULL ;
source : NULL ;
description : NULL.

Une boîte de dialogue dédiée à la saisie des métadonnées sera ajoutée dans une évolution ultérieure.

Déroulement fonctionnel

Utilisateur
    → clique sur « Importer une preuve »
    → sélectionne un fichier
    → Application vérifie la session active
    → Application prépare la requête d’import
    → création d’une BackgroundTask
    → ajout de la tâche au TaskManager
    → lancement du worker
    → EvidenceImporter exécute l’import
    → résultat affiché dans le TaskPanel
    → statut principal mis à jour

Chemins de destination

La destination physique et le chemin relatif stocké en base doivent rester distincts.

Destination physique

Pour cette première version :

<racine_enquête>/01_Preuves_Originales/Documents

Chemin relatif SQLite

01_Preuves_Originales/Documents

Le code ne doit jamais stocker un chemin absolu dans EvidenceRecord.relative_path.

Le dossier physique doit déjà exister ou être créé explicitement par le contrôleur avant le lancement de la tâche.

Données de travail de la tâche

Créer une structure privée dédiée, par exemple :

typedef struct
{
    Database *database;

    char *source_path;
    char *destination_directory;
    char *relative_directory;

    char *type_identifier;
    char *collected_at;
    char *source;
    char *description;
} EvidenceImportTaskData;

Règles de propriété :

les chaînes appartiennent à la structure ;
elles sont dupliquées avant le lancement du worker ;
la structure est détruite par worker_data_destroy ;
Database est empruntée à la session active ;
la session et la base doivent rester valides pendant toute la tâche.

Si cette dernière garantie n’est pas encore assurée par l’architecture, l’application doit empêcher la fermeture ou le remplacement de l’enquête tant qu’un import est en cours.

Worker d’import

Créer un worker compatible avec BackgroundTaskWorker.

Responsabilités :

vérifier les paramètres ;
signaler une progression initiale ;
créer EvidenceImporter ;
construire EvidenceImportRequest ;
appeler evidence_importer_import() ;
libérer EvidenceImporter ;
retourner le EvidenceRecord en résultat ;
propager les erreurs sans les masquer.

Exemple de progression :

0 %   Préparation de l’import
10 %  Validation du fichier
20 %  Copie et vérification
80 %  Enregistrement dans la base
100 % Import terminé

La progression reste approximative tant que EvidenceImporter ne fournit pas de callbacks détaillés.

Résultat de la tâche

En cas de succès :

le résultat de BackgroundTask est un EvidenceRecord * ;
result_destroy doit être evidence_record_free ;
la tâche passe à l’état terminé ;
le statut principal indique que la preuve a été importée ;
le chemin relatif ou le nom original peut être affiché ;
l’arborescence de l’enquête devra être rafraîchie.

En cas d’échec :

la tâche passe à l’état échoué ;
l’erreur complète apparaît dans le TaskPanel ;
une boîte de dialogue GTK présente un message compréhensible ;
aucun fichier ni aucune ligne SQLite incohérente ne doivent rester, sauf cas explicitement signalé comme fichier orphelin.

En cas d’annulation :

la tâche passe à l’état annulé ;
l’utilisateur n’est pas bombardé par une boîte de dialogue d’erreur ;
le statut principal peut indiquer que l’import a été annulé.

Cycle de vie de la session

Le worker utilise la base de la session active.

Il faut donc définir une règle stricte :

une enquête ne peut pas être fermée ou remplacée pendant un import actif ;

ou :

la session possède un système de références permettant au worker de la conserver jusqu’à la fin.

La première solution peut être utilisée pour cette version si elle est plus simple et clairement contrôlée dans Application.

Aucun pointeur vers Database ne doit survivre à la session qui la possède.

API `MainWindow`

Ajouter un callback dédié, par exemple :

typedef void (*MainWindowImportEvidenceCallback)(
    gpointer user_data
);

Ajouter les fonctions publiques :

void main_window_set_import_evidence_callback(
    MainWindow *main_window,
    MainWindowImportEvidenceCallback callback,
    gpointer user_data
);

void main_window_set_import_evidence_enabled(
    MainWindow *main_window,
    gboolean enabled
);

MainWindow ne devient propriétaire ni du callback ni de user_data.

Fichiers concernés

À modifier

include/views/main_window.h
src/views/main_window.c
src/core/application.c
Makefile

Potentiellement concernés

include/core/application.h
include/core/investigation_session.h
src/core/investigation_session.c
include/widgets/workspace.h
src/widgets/workspace.c

Workspace ne doit être modifié que si l’on souhaite afficher une confirmation ou un résumé de la preuve importée dans la zone centrale.

Nouveau module possible

Si l’orchestration devient trop volumineuse dans application.c :

include/core/evidence_import_task.h
src/core/evidence_import_task.c

Ce module encapsulerait :

les données du worker ;
la fonction worker ;
la destruction des données ;
la création de la BackgroundTask.

Étapes de réalisation

Étape 1 — Action GTK

ajouter l’action compacte dans MainWindow ;
ajouter le callback public ;
ajouter la fonction d’activation/désactivation ;
vérifier que le clic remonte jusqu’à Application.

Aucun import réel à cette étape.

Étape 2 — Sélecteur de fichier

ouvrir un sélecteur GTK asynchrone ;
récupérer le fichier sélectionné ;
gérer proprement l’annulation ;
afficher temporairement le chemin choisi dans la barre de statut.

Aucune copie à cette étape.

Étape 3 — Préparation de la tâche

construire les chemins ;
préparer EvidenceImportTaskData ;
créer la BackgroundTask ;
l’ajouter au TaskManager.

Étape 4 — Import réel

appeler EvidenceImporter dans le worker ;
propager résultat, erreur et annulation ;
mettre à jour l’interface à la fin.

Étape 5 — Rafraîchissement

rafraîchir l’arborescence de l’enquête ;
sélectionner ou afficher la preuve importée si pertinent ;
mettre à jour le statut principal.

Tests attendus

Tests unitaires ou d’intégration

Vérifier au minimum :

le bouton est désactivé sans enquête ;
le bouton est activé avec une enquête ouverte ;
le callback de MainWindow est bien appelé ;
l’annulation du sélecteur ne crée aucune tâche ;
un fichier sélectionné crée exactement une tâche ;
la tâche réussie retourne un EvidenceRecord ;
une erreur d’import apparaît dans la tâche ;
l’annulation de la tâche est transmise à EvidenceImporter ;
la destruction des données de tâche ne provoque aucune fuite ;
la fermeture de l’application annule ou attend correctement les imports actifs.

Vérification manuelle GTK

démarrer l’application sans enquête ;
vérifier que l’action d’import est désactivée ;
ouvrir une enquête ;
vérifier que l’action devient active ;
cliquer sur l’action ;
annuler le sélecteur ;
vérifier qu’aucune tâche n’est créée ;
recommencer et choisir un fichier ;
vérifier l’apparition de la tâche ;
attendre la fin ;
vérifier la copie dans le dossier de preuves ;
vérifier la ligne SQLite ;
vérifier l’absence de blocage de l’interface ;
tester le bouton d’annulation du TaskPanel.

Critères d’acceptation

Le ticket est terminé lorsque :

une action compacte d’import existe dans MainWindow ;
elle est désactivée sans enquête active ;
elle est activée avec une enquête active ;
le sélecteur de fichier est asynchrone ;
le thread GTK n’exécute aucune copie ni aucun calcul de hash ;
l’import est exécuté par une BackgroundTask ;
la tâche est suivie par TaskManager et visible dans TaskPanel ;
l’annulation est transmise par GCancellable ;
le résultat est un EvidenceRecord valide ;
la copie et la ligne SQLite existent après succès ;
aucune incohérence fichier/base n’est introduite après échec ;
les erreurs sont lisibles dans l’interface ;
l’application ne peut pas invalider la session pendant l’import ;
make, make test et git diff --check réussissent ;
Valgrind ne signale aucune erreur ni fuite sur les nouveaux tests.

Hors périmètre

Ne font pas partie de ce ticket :

import de plusieurs fichiers en une seule opération ;
glisser-déposer ;
import d’un dossier complet ;
catégorisation automatique avancée ;
extraction de métadonnées EXIF ;
OCR ;
analyse antivirus ;
aperçu du document ;
modification d’une preuve déjà importée ;
suppression d’une preuve ;
formulaire complet de métadonnées ;
corrélation automatique avec les entités OSINT.

Règles de sécurité et de qualité

ne jamais construire une commande shell avec le chemin sélectionné ;
ne jamais effectuer de copie ou de hash dans le thread GTK ;
ne jamais stocker un chemin absolu dans SQLite ;
ne jamais supprimer le fichier source ;
ne jamais masquer le chemin d’un fichier orphelin ;
ne jamais fermer la base pendant qu’un worker l’utilise ;
respecter les conventions C17, snake_case et les préfixes de module ;
ne pas committer tant que l’import réel et ses tests ne sont pas validés.

# Importer une preuve depuis l’interface GTK ## Objectif Permettre à l’utilisateur de démarrer l’import d’un fichier de preuve depuis la fenêtre principale de Labfy Investigation. Cette fonctionnalité doit relier progressivement l’interface GTK au service métier `EvidenceImporter`, sans bloquer la boucle principale GTK et sans introduire de dépendance directe entre les widgets et la base SQLite. --- ## Contexte Le cœur métier de l’import est désormais disponible et testé : - génération d’un identifiant UUID ; - génération d’un nom interne sûr ; - copie vérifiée du fichier ; - calcul et contrôle du SHA-256 ; - création du `EvidenceRecord` ; - insertion transactionnelle dans SQLite ; - rollback et suppression compensatoire en cas d’échec ; - prise en charge de l’annulation ; - signalement d’un éventuel fichier orphelin. L’interface actuelle possède : - une `MainWindow` ; - un `Workspace` situé dans `widgets/` ; - un `TaskManager` ; - un `TaskPanel` ; - un système générique de `BackgroundTask` ; - une session d’enquête active gérée par `Application`. Le prochain travail consiste à exposer l’import dans l’interface, sans déplacer la logique métier dans les widgets. --- ## Principe d’architecture La répartition des responsabilités doit rester la suivante : ### `MainWindow` Responsable uniquement de l’affichage et des événements GTK : - afficher une action compacte « Importer une preuve » ; - activer ou désactiver cette action ; - transmettre le clic à `Application` par callback ; - ne pas ouvrir directement la base ; - ne pas appeler directement `EvidenceImporter`. ### `Application` Responsable de l’orchestration : - vérifier qu’une enquête est ouverte ; - ouvrir le sélecteur de fichier ; - récupérer le fichier choisi ; - préparer les chemins de destination ; - créer et lancer une `BackgroundTask` ; - appeler `EvidenceImporter` depuis le worker ; - mettre à jour l’état de l’interface à la fin ; - afficher les erreurs dans une boîte de dialogue GTK. ### `BackgroundTask` Responsable de l’exécution hors du thread GTK : - exécuter l’import dans un thread secondaire ; - transporter le `GCancellable` ; - conserver le résultat ou l’erreur ; - informer le `TaskPanel`. ### `EvidenceImporter` Reste responsable de toute la logique métier de l’import : - copie ; - hash ; - modèle ; - transaction ; - rollback ; - compensation. Aucun widget ne doit reproduire cette logique. --- ## Interface utilisateur ### Action principale Ajouter une action compacte dans la barre d’outils de `MainWindow`. Caractéristiques : - icône GTK adaptée à l’import ou à l’ajout de fichier ; - infobulle : `Importer une preuve`; - pas de grand bouton occupant inutilement l’interface ; - action visible dans la barre d’outils principale ; - désactivée lorsqu’aucune enquête n’est ouverte ; - activée lorsqu’une session d’enquête valide est disponible. Un libellé texte peut être conservé temporairement pendant le développement, mais la version finale doit privilégier une présentation compacte avec icône et infobulle. ### Sélection du fichier Le clic doit ouvrir un sélecteur GTK asynchrone. Contraintes : - sélection d’un seul fichier ; - pas de sélection de dossier ; - aucune lecture lourde dans le callback GTK ; - annulation silencieuse si l’utilisateur ferme la boîte de dialogue ; - récupération d’un chemin local exploitable ; - refus clair si le fichier ne possède pas de chemin local. ### Métadonnées Dans cette première version, les valeurs minimales suivantes peuvent être utilisées : - type de preuve : `document` par défaut ; - date de collecte : `NULL` ; - source : `NULL` ; - description : `NULL`. Une boîte de dialogue dédiée à la saisie des métadonnées sera ajoutée dans une évolution ultérieure. --- ## Déroulement fonctionnel ```text Utilisateur → clique sur « Importer une preuve » → sélectionne un fichier → Application vérifie la session active → Application prépare la requête d’import → création d’une BackgroundTask → ajout de la tâche au TaskManager → lancement du worker → EvidenceImporter exécute l’import → résultat affiché dans le TaskPanel → statut principal mis à jour ``` --- ## Chemins de destination La destination physique et le chemin relatif stocké en base doivent rester distincts. ### Destination physique Pour cette première version : ```text <racine_enquête>/01_Preuves_Originales/Documents ``` ### Chemin relatif SQLite ```text 01_Preuves_Originales/Documents ``` Le code ne doit jamais stocker un chemin absolu dans `EvidenceRecord.relative_path`. Le dossier physique doit déjà exister ou être créé explicitement par le contrôleur avant le lancement de la tâche. --- ## Données de travail de la tâche Créer une structure privée dédiée, par exemple : ```c typedef struct { Database *database; char *source_path; char *destination_directory; char *relative_directory; char *type_identifier; char *collected_at; char *source; char *description; } EvidenceImportTaskData; ``` Règles de propriété : - les chaînes appartiennent à la structure ; - elles sont dupliquées avant le lancement du worker ; - la structure est détruite par `worker_data_destroy` ; - `Database` est empruntée à la session active ; - la session et la base doivent rester valides pendant toute la tâche. Si cette dernière garantie n’est pas encore assurée par l’architecture, l’application doit empêcher la fermeture ou le remplacement de l’enquête tant qu’un import est en cours. --- ## Worker d’import Créer un worker compatible avec `BackgroundTaskWorker`. Responsabilités : 1. vérifier les paramètres ; 2. signaler une progression initiale ; 3. créer `EvidenceImporter` ; 4. construire `EvidenceImportRequest` ; 5. appeler `evidence_importer_import()` ; 6. libérer `EvidenceImporter` ; 7. retourner le `EvidenceRecord` en résultat ; 8. propager les erreurs sans les masquer. Exemple de progression : ```text 0 % Préparation de l’import 10 % Validation du fichier 20 % Copie et vérification 80 % Enregistrement dans la base 100 % Import terminé ``` La progression reste approximative tant que `EvidenceImporter` ne fournit pas de callbacks détaillés. --- ## Résultat de la tâche En cas de succès : - le résultat de `BackgroundTask` est un `EvidenceRecord *` ; - `result_destroy` doit être `evidence_record_free` ; - la tâche passe à l’état terminé ; - le statut principal indique que la preuve a été importée ; - le chemin relatif ou le nom original peut être affiché ; - l’arborescence de l’enquête devra être rafraîchie. En cas d’échec : - la tâche passe à l’état échoué ; - l’erreur complète apparaît dans le `TaskPanel` ; - une boîte de dialogue GTK présente un message compréhensible ; - aucun fichier ni aucune ligne SQLite incohérente ne doivent rester, sauf cas explicitement signalé comme fichier orphelin. En cas d’annulation : - la tâche passe à l’état annulé ; - l’utilisateur n’est pas bombardé par une boîte de dialogue d’erreur ; - le statut principal peut indiquer que l’import a été annulé. --- ## Cycle de vie de la session Le worker utilise la base de la session active. Il faut donc définir une règle stricte : - une enquête ne peut pas être fermée ou remplacée pendant un import actif ; ou : - la session possède un système de références permettant au worker de la conserver jusqu’à la fin. La première solution peut être utilisée pour cette version si elle est plus simple et clairement contrôlée dans `Application`. Aucun pointeur vers `Database` ne doit survivre à la session qui la possède. --- ## API `MainWindow` Ajouter un callback dédié, par exemple : ```c typedef void (*MainWindowImportEvidenceCallback)( gpointer user_data ); ``` Ajouter les fonctions publiques : ```c void main_window_set_import_evidence_callback( MainWindow *main_window, MainWindowImportEvidenceCallback callback, gpointer user_data ); void main_window_set_import_evidence_enabled( MainWindow *main_window, gboolean enabled ); ``` `MainWindow` ne devient propriétaire ni du callback ni de `user_data`. --- ## Fichiers concernés ### À modifier ```text include/views/main_window.h src/views/main_window.c src/core/application.c Makefile ``` ### Potentiellement concernés ```text include/core/application.h include/core/investigation_session.h src/core/investigation_session.c include/widgets/workspace.h src/widgets/workspace.c ``` `Workspace` ne doit être modifié que si l’on souhaite afficher une confirmation ou un résumé de la preuve importée dans la zone centrale. ### Nouveau module possible Si l’orchestration devient trop volumineuse dans `application.c` : ```text include/core/evidence_import_task.h src/core/evidence_import_task.c ``` Ce module encapsulerait : - les données du worker ; - la fonction worker ; - la destruction des données ; - la création de la `BackgroundTask`. --- ## Étapes de réalisation ### Étape 1 — Action GTK - ajouter l’action compacte dans `MainWindow` ; - ajouter le callback public ; - ajouter la fonction d’activation/désactivation ; - vérifier que le clic remonte jusqu’à `Application`. Aucun import réel à cette étape. ### Étape 2 — Sélecteur de fichier - ouvrir un sélecteur GTK asynchrone ; - récupérer le fichier sélectionné ; - gérer proprement l’annulation ; - afficher temporairement le chemin choisi dans la barre de statut. Aucune copie à cette étape. ### Étape 3 — Préparation de la tâche - construire les chemins ; - préparer `EvidenceImportTaskData` ; - créer la `BackgroundTask` ; - l’ajouter au `TaskManager`. ### Étape 4 — Import réel - appeler `EvidenceImporter` dans le worker ; - propager résultat, erreur et annulation ; - mettre à jour l’interface à la fin. ### Étape 5 — Rafraîchissement - rafraîchir l’arborescence de l’enquête ; - sélectionner ou afficher la preuve importée si pertinent ; - mettre à jour le statut principal. --- ## Tests attendus ### Tests unitaires ou d’intégration Vérifier au minimum : - le bouton est désactivé sans enquête ; - le bouton est activé avec une enquête ouverte ; - le callback de `MainWindow` est bien appelé ; - l’annulation du sélecteur ne crée aucune tâche ; - un fichier sélectionné crée exactement une tâche ; - la tâche réussie retourne un `EvidenceRecord` ; - une erreur d’import apparaît dans la tâche ; - l’annulation de la tâche est transmise à `EvidenceImporter` ; - la destruction des données de tâche ne provoque aucune fuite ; - la fermeture de l’application annule ou attend correctement les imports actifs. ### Vérification manuelle GTK 1. démarrer l’application sans enquête ; 2. vérifier que l’action d’import est désactivée ; 3. ouvrir une enquête ; 4. vérifier que l’action devient active ; 5. cliquer sur l’action ; 6. annuler le sélecteur ; 7. vérifier qu’aucune tâche n’est créée ; 8. recommencer et choisir un fichier ; 9. vérifier l’apparition de la tâche ; 10. attendre la fin ; 11. vérifier la copie dans le dossier de preuves ; 12. vérifier la ligne SQLite ; 13. vérifier l’absence de blocage de l’interface ; 14. tester le bouton d’annulation du `TaskPanel`. --- ## Critères d’acceptation Le ticket est terminé lorsque : - une action compacte d’import existe dans `MainWindow` ; - elle est désactivée sans enquête active ; - elle est activée avec une enquête active ; - le sélecteur de fichier est asynchrone ; - le thread GTK n’exécute aucune copie ni aucun calcul de hash ; - l’import est exécuté par une `BackgroundTask` ; - la tâche est suivie par `TaskManager` et visible dans `TaskPanel` ; - l’annulation est transmise par `GCancellable` ; - le résultat est un `EvidenceRecord` valide ; - la copie et la ligne SQLite existent après succès ; - aucune incohérence fichier/base n’est introduite après échec ; - les erreurs sont lisibles dans l’interface ; - l’application ne peut pas invalider la session pendant l’import ; - `make`, `make test` et `git diff --check` réussissent ; - Valgrind ne signale aucune erreur ni fuite sur les nouveaux tests. --- ## Hors périmètre Ne font pas partie de ce ticket : - import de plusieurs fichiers en une seule opération ; - glisser-déposer ; - import d’un dossier complet ; - catégorisation automatique avancée ; - extraction de métadonnées EXIF ; - OCR ; - analyse antivirus ; - aperçu du document ; - modification d’une preuve déjà importée ; - suppression d’une preuve ; - formulaire complet de métadonnées ; - corrélation automatique avec les entités OSINT. --- ## Règles de sécurité et de qualité - ne jamais construire une commande shell avec le chemin sélectionné ; - ne jamais effectuer de copie ou de hash dans le thread GTK ; - ne jamais stocker un chemin absolu dans SQLite ; - ne jamais supprimer le fichier source ; - ne jamais masquer le chemin d’un fichier orphelin ; - ne jamais fermer la base pendant qu’un worker l’utilise ; - respecter les conventions C17, `snake_case` et les préfixes de module ; - ne pas committer tant que l’import réel et ses tests ne sont pas validés.

fy59 closed this issue

2026-07-20 07:16:23 +02:00

No labels

No milestone

No project

No assignees

1 participant

Notifications

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#50

No description provided.