Research: Catégorisation des dossiers à la racine de l'archive

1. Où stocker la liste des catégories déjà utilisées (pour la suggestion, FR-004/Edge Case)

Decision: Réutiliser la base de contexte centralisée SQLite déjà définie par specs/003-config-contexte-travail (même fichier, mêmes conventions PRAGMA user_version/application_id), avec une nouvelle table categories (nom, premiere_utilisation). Elle est alimentée automatiquement à chaque création d'un dossier ou dossier parent sous une catégorie (jamais pour les répertoires d'année, qui n'ont pas besoin d'être mis en cache).

Rationale: Les répertoires d'année sont dérivés directement de la date EXIF, sans aucune ambiguïté d'orthographe possible — rien à mettre en cache. Les catégories, en revanche, sont des noms libres saisis par l'utilisateur (FR-004) : sans liste des catégories déjà utilisées, Régine ne pourrait pas proposer de suggestion au moment de la saisie (Edge Case "Mariage" vs "mariage"), et devrait soit interroger le NAS en direct (lenteur, dépendance réseau au moment même de l'import), soit laisser l'utilisateur créer des doublons par erreur. Réutiliser la base de contexte centralisée déjà actée par specs/003-config-contexte-travail (plutôt que d'en créer une nouvelle) suit le même raisonnement déjà retenu pour les boîtiers : éviter un aller-retour réseau, cohérence avec le Principe VI (une seule bibliothèque centrale, pas de mécanisme de persistance dupliqué pour un besoin très proche).

Alternatives considered:

Lister en direct les répertoires présents à la racine de l'archive NAS à chaque saisie — rejeté : nécessite un accès réseau à un moment où le NAS peut ne pas être monté (cf. specs/003-config-contexte-travail User Story 2), et serait plus lent qu'une lecture locale pour une simple suggestion de saisie.
Une base séparée dédiée aux catégories — rejeté : même argument que pour les boîtiers (specs/003 research.md § 2), pas de justification à dupliquer le mécanisme de persistance pour un second besoin de nature identique (cache de suggestion local, alimenté à l'écriture).

2. Suggestion de catégorie proche (orthographe/casse)

Decision: Utiliser difflib.get_close_matches (bibliothèque standard Python) pour comparer la saisie de l'utilisateur aux catégories déjà connues (table categories) et proposer les correspondances proches avant de créer un nouveau répertoire de catégorie.

Rationale: Besoin simple (comparaison de chaînes approximative sur un nombre de catégories attendu faible à modéré), entièrement couvert par la bibliothèque standard — cohérent avec la préférence du projet pour des dépendances minimales déjà actée en specs/003-config-contexte-travail/research.md.

Alternatives considered:

Bibliothèque tierce de correspondance floue (rapidfuzz, fuzzywuzzy) — rejeté : complexité et dépendance non justifiées pour un volume de catégories qui reste faible (dizaines, pas milliers).
Comparaison stricte (sensible à la casse et à l'orthographe) sans suggestion — rejeté : ne répond pas à l'Edge Case explicitement identifié dans la spec (risque de créer deux répertoires équivalents par erreur).

3. Emplacement du code de résolution de chemin

Decision: Nouveau module regine_core/dossier/root.py, exposant une fonction determine_root(date, categorie=None) -> RootLocation qui retourne un objet structuré (type de racine, nom du répertoire, chemin archive et chemin local en miroir), consommée par le futur code d'import (specs/001-import-photos) et par regine_core/config/categories.py pour la mise à jour du cache.

Rationale: Le placement racine (année/catégorie) est une règle de structure de dossier, pas une règle propre à l'import de carte mémoire — il relève naturellement du module dossier déjà identifié dans l'architecture du projet (docs/interface-cli-gui-architecture.md), qui n'avait encore aucun code avant ce plan. Le retour d'un objet structuré (plutôt qu'une simple chaîne de caractères) respecte le Principe VI : aucune façade n'a à reconstruire ou parser un chemin, elle reçoit directement de quoi afficher le résumé requis par FR-010.

Alternatives considered:

Intégrer cette logique directement dans le futur module import plutôt que dans dossier — rejeté : le placement racine est réutilisé ailleurs qu'à l'import (ex. affichage, recherche de dossiers candidats déjà prévue par specs/001-import-photos FR-008), la séparation par responsabilité reste plus cohérente avec le découpage de modules déjà documenté.

Résumé

Tous les points du Technical Context sont résolus par les décisions ci-dessus. Aucune dépendance tierce nouvelle introduite ; une seule extension de schéma (table categories) sur une base déjà actée.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


# Research: Catégorisation des dossiers à la racine de l'archive

## 1. Où stocker la liste des catégories déjà utilisées (pour la suggestion, FR-004/Edge Case)

**Decision**: Réutiliser la base de contexte centralisée SQLite déjà définie par `specs/003-config-contexte-travail` (même fichier, mêmes conventions `PRAGMA user_version`/`application_id`), avec une nouvelle table `categories` (`nom`, `premiere_utilisation`). Elle est alimentée automatiquement à chaque création d'un dossier ou dossier parent sous une catégorie (jamais pour les répertoires d'année, qui n'ont pas besoin d'être mis en cache).

**Rationale**: Les répertoires d'année sont dérivés directement de la date EXIF, sans aucune ambiguïté d'orthographe possible — rien à mettre en cache. Les catégories, en revanche, sont des noms libres saisis par l'utilisateur (FR-004) : sans liste des catégories déjà utilisées, Régine ne pourrait pas proposer de suggestion au moment de la saisie (Edge Case "Mariage" vs "mariage"), et devrait soit interroger le NAS en direct (lenteur, dépendance réseau au moment même de l'import), soit laisser l'utilisateur créer des doublons par erreur. Réutiliser la base de contexte centralisée déjà actée par `specs/003-config-contexte-travail` (plutôt que d'en créer une nouvelle) suit le même raisonnement déjà retenu pour les boîtiers : éviter un aller-retour réseau, cohérence avec le Principe VI (une seule bibliothèque centrale, pas de mécanisme de persistance dupliqué pour un besoin très proche).

**Alternatives considered**:
- Lister en direct les répertoires présents à la racine de l'archive NAS à chaque saisie — rejeté : nécessite un accès réseau à un moment où le NAS peut ne pas être monté (cf. `specs/003-config-contexte-travail` User Story 2), et serait plus lent qu'une lecture locale pour une simple suggestion de saisie.
- Une base séparée dédiée aux catégories — rejeté : même argument que pour les boîtiers (specs/003 research.md § 2), pas de justification à dupliquer le mécanisme de persistance pour un second besoin de nature identique (cache de suggestion local, alimenté à l'écriture).

## 2. Suggestion de catégorie proche (orthographe/casse)

**Decision**: Utiliser `difflib.get_close_matches` (bibliothèque standard Python) pour comparer la saisie de l'utilisateur aux catégories déjà connues (table `categories`) et proposer les correspondances proches avant de créer un nouveau répertoire de catégorie.

**Rationale**: Besoin simple (comparaison de chaînes approximative sur un nombre de catégories attendu faible à modéré), entièrement couvert par la bibliothèque standard — cohérent avec la préférence du projet pour des dépendances minimales déjà actée en `specs/003-config-contexte-travail/research.md`.

**Alternatives considered**:
- Bibliothèque tierce de correspondance floue (`rapidfuzz`, `fuzzywuzzy`) — rejeté : complexité et dépendance non justifiées pour un volume de catégories qui reste faible (dizaines, pas milliers).
- Comparaison stricte (sensible à la casse et à l'orthographe) sans suggestion — rejeté : ne répond pas à l'Edge Case explicitement identifié dans la spec (risque de créer deux répertoires équivalents par erreur).

## 3. Emplacement du code de résolution de chemin

**Decision**: Nouveau module `regine_core/dossier/root.py`, exposant une fonction `determine_root(date, categorie=None) -> RootLocation` qui retourne un objet structuré (type de racine, nom du répertoire, chemin archive et chemin local en miroir), consommée par le futur code d'import (`specs/001-import-photos`) et par `regine_core/config/categories.py` pour la mise à jour du cache.

**Rationale**: Le placement racine (année/catégorie) est une règle de structure de dossier, pas une règle propre à l'import de carte mémoire — il relève naturellement du module `dossier` déjà identifié dans l'architecture du projet (`docs/interface-cli-gui-architecture.md`), qui n'avait encore aucun code avant ce plan. Le retour d'un objet structuré (plutôt qu'une simple chaîne de caractères) respecte le Principe VI : aucune façade n'a à reconstruire ou parser un chemin, elle reçoit directement de quoi afficher le résumé requis par FR-010.

**Alternatives considered**:
- Intégrer cette logique directement dans le futur module `import` plutôt que dans `dossier` — rejeté : le placement racine est réutilisé ailleurs qu'à l'import (ex. affichage, recherche de dossiers candidats déjà prévue par `specs/001-import-photos` FR-008), la séparation par responsabilité reste plus cohérente avec le découpage de modules déjà documenté.

## Résumé

Tous les points du Technical Context sont résolus par les décisions ci-dessus. Aucune dépendance tierce nouvelle introduite ; une seule extension de schéma (table `categories`) sur une base déjà actée.