fonzarely/regine-photos-archiver · b50cd7b

fonzarely/regine-photos-archiverpublic⑂ Fork 0

⑂ b50cd7b

plan

Fabien Champigny committed 2026-09-21T15:11:24+02:00 Browse files

b50cd7b parent: 780946f

modified specs/003-config-contexte-travail/checklists/requirements.md +8 -0 Viewed

@@ -44,3 +44,11 @@
44	44	capacité optionnelle et volontaire (FR-012, SC-007). Nouvelle entité « Base de contexte
45	45	centralisée » ajoutée aux Key Entities, distincte de la base de données de travail par
46	46	dossier.
	47	+- Session de clarification du 2026-09-21 (`/speckit-clarify`) : deux questions posées et
	48	+ intégrées (voir section « Clarifications » du spec.md).
	49	+ 1. Emplacement de la base de contexte selon l'OS : pas de convention par plateforme pour
	50	+ l'instant, l'emplacement unique déjà en place (`~/.regine/`) est conservé ; amélioration
	51	+ explicitement différée (nouvelle Assumption).
	52	+ 2. Accès de la GUI au contexte de travail : oui, en appelant directement `regine_core.config`
	53	+ sans logique propre à la GUI (Principe VI) — nouvelle User Story 4, nouveau FR-013, nouveau
	54	+ SC-008 (parité stricte CLI/GUI).

       capacité optionnelle et volontaire (FR-012, SC-007). Nouvelle entité « Base de contexte
       centralisée » ajoutée aux Key Entities, distincte de la base de données de travail par
       dossier.
++- **Session de clarification du 2026-09-21** (`/speckit-clarify`) : deux questions posées et
++  intégrées (voir section « Clarifications » du spec.md).
++  1. Emplacement de la base de contexte selon l'OS : pas de convention par plateforme pour
++     l'instant, l'emplacement unique déjà en place (`~/.regine/`) est conservé ; amélioration
++     explicitement différée (nouvelle Assumption).
++  2. Accès de la GUI au contexte de travail : oui, en appelant directement `regine_core.config`
++     sans logique propre à la GUI (Principe VI) — nouvelle User Story 4, nouveau FR-013, nouveau
++     SC-008 (parité stricte CLI/GUI).

modified specs/003-config-contexte-travail/contracts/regine-core-api.md +1 -0 Viewed

@@ -51,3 +51,4 @@ Parcours volontaire de l'archive (FR-012) : lit le tag `Model` de chaque fichier
51	51	- Réutilisation de la colonne `source` de `camera_profile.db.boitiers` : `data-model.md` (rédigé avant `specs/002`) envisageait `source` à deux valeurs (`import`/`parcours_nas`). Le schéma réellement livré par specs/002 utilise déjà cette colonne pour une distinction différente (`modele`/`numero_serie`/`manuel` — comment un boîtier a été désambiguïsé). Cette colonne texte libre n'a pas été migrée ni renommée (déjà testée par specs/002) : `parcourir_nas` y ajoute simplement la valeur `parcours_nas` en plus des valeurs existantes. À l'affichage (`cameras list`), toute valeur différente de `parcours_nas` est implicitement « détecté via import ».
52	52	- Emplacement de la base de contexte centralisée : non fixé par `research.md`. Décision prise à l'implémentation (T005) : `~/.regine/contexte.sqlite3`, fixe par utilisateur, indépendant de `local_work_dir` (qui reste modifiable, FR-010/SC-005, sans jamais risquer de perdre boîtiers/catégories déjà enregistrés).
53	53	- Intégration avec `regine_cli.import_cmd`/`archive_cmd` (specs/001/005) non construite ici : ces façades prennent aujourd'hui `--archive-root`/`--local-root` en flags CLI explicites, indépendamment de ce contexte configuré. `FR-010` ne protège donc que le travail effectivement réalisé sous le `local_work_dir` configuré ici — cohérent tant que cette intégration (lire `regine config show` par défaut plutôt que d'exiger les flags) n'a pas été demandée séparément.
	54	+- Extension du 2026-09-21 (User Story 4) : `regine-gui` (`config_view.py`, implémentée après `specs/006-gui-tri-consultation`) consomme les mêmes fonctions ci-dessus telles quelles — aucune fonction supplémentaire n'a été nécessaire pour cette extension, confirmant que le contrat était déjà complet côté `regine-core` avant même que la GUI existe.

  - **Réutilisation de la colonne `source` de `camera_profile.db.boitiers`** : `data-model.md` (rédigé avant `specs/002`) envisageait `source` à deux valeurs (`import`/`parcours_nas`). Le schéma réellement livré par specs/002 utilise déjà cette colonne pour une distinction différente (`modele`/`numero_serie`/`manuel` — **comment** un boîtier a été désambiguïsé). Cette colonne texte libre n'a pas été migrée ni renommée (déjà testée par specs/002) : `parcourir_nas` y ajoute simplement la valeur `parcours_nas` en plus des valeurs existantes. À l'affichage (`cameras list`), toute valeur différente de `parcours_nas` est implicitement « détecté via import ».
  - **Emplacement de la base de contexte centralisée** : non fixé par `research.md`. Décision prise à l'implémentation (T005) : `~/.regine/contexte.sqlite3`, fixe par utilisateur, indépendant de `local_work_dir` (qui reste modifiable, FR-010/SC-005, sans jamais risquer de perdre boîtiers/catégories déjà enregistrés).
  - **Intégration avec `regine_cli.import_cmd`/`archive_cmd` (specs/001/005) non construite ici** : ces façades prennent aujourd'hui `--archive-root`/`--local-root` en flags CLI explicites, indépendamment de ce contexte configuré. `FR-010` ne protège donc que le travail effectivement réalisé sous le `local_work_dir` configuré ici — cohérent tant que cette intégration (lire `regine config show` par défaut plutôt que d'exiger les flags) n'a pas été demandée séparément.
++- **Extension du 2026-09-21 (User Story 4)** : `regine-gui` (`config_view.py`, implémentée après `specs/006-gui-tri-consultation`) consomme les mêmes fonctions ci-dessus telles quelles — aucune fonction supplémentaire n'a été nécessaire pour cette extension, confirmant que le contrat était déjà complet côté `regine-core` avant même que la GUI existe.

modified specs/003-config-contexte-travail/data-model.md +2 -0 Viewed

@@ -71,3 +71,5 @@ Vue logique sur une ligne de la table `boitiers` dont `nom_lisible` n'est pas `N
71	71	▼
72	72	Nommé (nom_lisible défini)
73	73	```
	74	+
	75	+Extension du 2026-09-21 (User Story 4) : aucune nouvelle entité. L'onglet de configuration de la GUI lit et écrit exactement le même `Contexte de travail` et les mêmes `Boîtier`/`Boîtier nommé` que la CLI, via les mêmes fonctions (`contracts/regine-core-api.md`) — pas un second modèle de données parallèle.

          ▼
     Nommé (nom_lisible défini)
  ```
++
++**Extension du 2026-09-21 (User Story 4)** : aucune nouvelle entité. L'onglet de configuration de la GUI lit et écrit exactement le même `Contexte de travail` et les mêmes `Boîtier`/`Boîtier nommé` que la CLI, via les mêmes fonctions (`contracts/regine-core-api.md`) — pas un second modèle de données parallèle.

modified specs/003-config-contexte-travail/plan.md +17 -4 Viewed

@@ -8,6 +8,8 @@
8	8
9	9	Le module de configuration établit le contexte de travail dont dépendent tous les autres modules de Régine : trois emplacements (répertoire temporaire, répertoire de travail local, archive NAS/SMB), l'initialisation d'une base de données de travail à la racine du répertoire de travail local (archivée avec chaque dossier), une base de contexte centralisée alimentée à chaque import avec les références de boîtiers rencontrés (permettant de leur attribuer un nom lisible sans réimport ni parcours du NAS), et une assistance au montage natif du partage SMB quand il est indisponible. Approche technique : un module Python (`config`) dans le paquet `regine-core` d'un monorepo à quatre parties (bibliothèque centrale `regine-core`, façades `regine-cli`, `regine-gui`, `regine-agent`), exposé dans un premier temps via `regine-cli` (cf. Principe CLI-first et Principe VI de la constitution), stockant son état dans SQLite selon les mêmes conventions que le manifeste persistant par dossier déjà retenu (`PRAGMA user_version`/`application_id`).
10	10
	11	+Extension du 2026-09-21 (User Story 4, clarification post-implémentation) : `regine-gui` (implémentée entre-temps par `specs/006-gui-tri-consultation`, avec une fenêtre à onglets Tri/Consultation) reçoit un troisième onglet de configuration, appelant directement les fonctions déjà documentées dans `contracts/regine-core-api.md` (`context.charger_contexte`/`enregistrer_chemins`, `cameras_screen.lister_boitiers`/`nommer_boitier`). Aucune nouvelle fonction `regine-core` requise — tout l'API nécessaire existe et est déjà testée ; ce périmètre est une façade pure (Principe VI), au même titre que `tri_view.py`/`consultation_view.py` l'ont déjà été pour leurs propres capacités.
	12	+
11	13	## Technical Context
12	14
13	15	Language/Version: Python 3.11+ (langage retenu pour la bibliothèque centrale de Régine, cf. `docs/interface-cli-gui-architecture.md`)
@@ -20,7 +22,7 @@ Le module de configuration établit le contexte de travail dont dépendent tous
20	22
21	23	Target Platform: Poste de travail de bureau (macOS en priorité pour cette itération ; Windows/Linux non couverts par ce plan, cf. research.md) — l'abstraction de déclenchement du montage SMB isole ce choix pour ne pas bloquer une extension future
22	24
23		-Project Type: Monorepo — une bibliothèque centrale (`regine-core`) et trois façades indépendantes et installables séparément (`regine-cli`, `regine-gui`, `regine-agent`), conformément au Principe VI de la constitution. Ce plan implémente `regine-core` (module `config`) et `regine-cli` ; `regine-gui` et `regine-agent` sont réservés dans la structure du dépôt mais ne sont pas construits par ce plan (cf. Structure Decision et research.md § 5).
	25	+Project Type: Monorepo — une bibliothèque centrale (`regine-core`) et trois façades indépendantes et installables séparément (`regine-cli`, `regine-gui`, `regine-agent`), conformément au Principe VI de la constitution. Ce plan implémente `regine-core` (module `config`) et `regine-cli` ; `regine-agent` reste réservé. `regine-gui` a depuis été implémentée par `specs/006-gui-tri-consultation` (PySide6, fenêtre à onglets) — ce plan (extension du 2026-09-21) y ajoute un onglet de configuration (User Story 4), sans toucher aux onglets Tri/Consultation déjà livrés.
24	26
25	27	Performance Goals: Pas de cible chiffrée spécifique ; la détection de boîtiers (FR-008/SC-007) doit rester quasi instantanée car elle ne lit que la base de contexte locale, sans parcours réseau par défaut
26	28
@@ -39,7 +41,7 @@ Le module de configuration établit le contexte de travail dont dépendent tous
39	41	\| III. Identité par contenu, jamais par nom de fichier seul \| N/A \| Hors périmètre : ce module ne détecte ni renommage ni doublon de fichier. \|
40	42	\| IV. Métadonnées ouvertes et embarquées \| PASS \| Le nom lisible d'un boîtier (FR-009) est une convenance locale d'affichage, pas une métadonnée descriptive/de droits au sens du Principe IV (légende, mots-clés, personnes, crédit, copyright, licence) ; l'identité du boîtier reste fondée sur les tags EXIF déjà embarqués par l'appareil (modèle, numéro de série), lesquels restent la source de vérité portable. \|
41	43	\| V. L'utilisateur décide, Régine suggère \| PASS \| FR-003 (création de répertoire) et FR-012 (parcours NAS) restent des propositions/actions volontaires, jamais automatiques. \|
42		-\| VI. Bibliothèque centrale, façades minces \| PASS \| Le monorepo matérialise physiquement la séparation : `regine-core` porte toute la logique métier (module `config`), `regine-cli` ne fait qu'appeler `regine-core` et formatter le résultat. `regine-gui`/`regine-agent` sont réservés dans la structure pour dépendre de `regine-core` de la même façon le moment venu, sans logique dupliquée. \|
	44	+\| VI. Bibliothèque centrale, façades minces \| PASS \| Le monorepo matérialise physiquement la séparation : `regine-core` porte toute la logique métier (module `config`), `regine-cli` et, depuis l'extension du 2026-09-21, `regine-gui` ne font qu'appeler `regine-core` et formatter le résultat — le nouvel onglet de configuration n'introduit aucune règle de validation propre à la GUI (FR-013). `regine-agent` reste réservé. \|
43	45	\| CLI-first \| PASS \| Toute capacité de ce module est exposée en CLI avant toute GUI. \|
44	46	\| Exécution sans démon \| PASS \| Chaque commande CLI est un processus isolé ; le déclenchement du montage SMB est une action ponctuelle, pas un service en arrière-plan. \|
45	47	\| Formats ouverts et documentés \| PASS \| SQLite, déjà retenu par la constitution pour le manifeste persistant, réutilisé ici avec les mêmes conventions (`PRAGMA user_version`/`application_id`). \|
@@ -97,8 +99,17 @@ packages/
97	99	│ └── contract/
98	100	│ └── test_cli_config.py # Contrat de la surface CLI (entrées/sorties texte, codes de sortie)
99	101	│
100		-├── regine-gui/ # Façade GUI — réservée, non implémentée par ce plan
101		-│ └── (scaffold vide : pyproject.toml déclarant la dépendance à regine-core, aucun code métier)
	102	+├── regine-gui/ # Façade GUI (PySide6) — implémentée par specs/006, étendue ici
	103	+│ ├── pyproject.toml
	104	+│ └── src/
	105	+│ └── regine_gui/
	106	+│ ├── app.py # existant (specs/006) — ajoute un 3e onglet "Configuration"
	107	+│ ├── tri_view.py # existant (specs/006), inchangé
	108	+│ ├── consultation_view.py # existant (specs/006), inchangé
	109	+│ └── config_view.py # NOUVEAU (User Story 4) — appelle regine_core.config
	110	+│ (context.charger_contexte/enregistrer_chemins,
	111	+│ cameras_screen.lister_boitiers/nommer_boitier),
	112	+│ aucune logique de validation propre
102	113	│
103	114	└── regine-agent/ # Façade agent IA — réservée, non implémentée par ce plan
104	115	└── (scaffold vide : pyproject.toml déclarant la dépendance à regine-core, aucun code métier)
@@ -106,6 +117,8 @@ packages/
106	117
107	118	Structure Decision: Monorepo à quatre parties (Option 1 adaptée du template, multi-packages plutôt que `src/` unique), conformément au Principe VI de la constitution (bibliothèque centrale, façades minces) et à la demande explicite d'organiser dès maintenant la place de la GUI et de l'agent IA. `regine-core` est le premier package de la bibliothèque centrale de Régine (aucun code existant avant ce plan) et pose la convention `packages/<nom>/src/<nom_paquet>/` que les modules métier futurs (`import`, `archive`, `dossier`, `metadata`, `integrity`, `camera_profile` de specs/002) réutiliseront à l'intérieur de `regine-core`. Ce plan implémente `regine-core/config` (chemins, montage SMB, écran de nommage des boîtiers) et `regine-cli` ; `regine-gui` et `regine-agent` sont créés comme paquets vides (dépendance déclarée vers `regine-core`, sans code métier) pour réserver la structure, sans être développés ici. Correction du 2026-09-18 : la logique de désambiguïsation et la table `boitiers` (initialement esquissées ici sous `config/cameras.py`) sont possédées par le module `regine_core.camera_profile`, spécifié séparément par `specs/002-profil-boitiers-optionnel/plan.md` — `config` ne fait qu'exposer un écran qui délègue à cette API, cohérent avec le Principe VI (une seule bibliothèque centrale, pas de logique dupliquée entre deux specs). L'outillage de workspace (gestion des dépendances inter-paquets, lockfile commun) est tranché en research.md § 5.
108	119
	120	+Extension du 2026-09-21 (User Story 4) : `regine-gui` n'est plus un paquet vide — `specs/006-gui-tri-consultation` l'a implémenté entre-temps (PySide6, `FenetrePrincipale` à onglets dans `app.py`). Cette extension y ajoute un troisième onglet (`config_view.py`), construit à l'identique de `tri_view.py`/`consultation_view.py` (une classe `QMainWindow`/`QWidget` qui n'appelle que des fonctions déjà publiques de `regine_core.config`, jamais de logique propre) — aucun nouveau research nécessaire (aucune inconnue technique introduite), aucun nouveau contrat `regine-core-api.md` (les fonctions appelées sont déjà toutes documentées).
	121	+
109	122	## Complexity Tracking
110	123
111	124	Aucune violation de gate à justifier — section laissée vide intentionnellement.

  Le module de configuration établit le contexte de travail dont dépendent tous les autres modules de Régine : trois emplacements (répertoire temporaire, répertoire de travail local, archive NAS/SMB), l'initialisation d'une base de données de travail à la racine du répertoire de travail local (archivée avec chaque dossier), une base de contexte centralisée alimentée à chaque import avec les références de boîtiers rencontrés (permettant de leur attribuer un nom lisible sans réimport ni parcours du NAS), et une assistance au montage natif du partage SMB quand il est indisponible. Approche technique : un module Python (`config`) dans le paquet `regine-core` d'un monorepo à quatre parties (bibliothèque centrale `regine-core`, façades `regine-cli`, `regine-gui`, `regine-agent`), exposé dans un premier temps via `regine-cli` (cf. Principe CLI-first et Principe VI de la constitution), stockant son état dans SQLite selon les mêmes conventions que le manifeste persistant par dossier déjà retenu (`PRAGMA user_version`/`application_id`).
++**Extension du 2026-09-21 (User Story 4, clarification post-implémentation)** : `regine-gui` (implémentée entre-temps par `specs/006-gui-tri-consultation`, avec une fenêtre à onglets Tri/Consultation) reçoit un troisième onglet de configuration, appelant directement les fonctions déjà documentées dans `contracts/regine-core-api.md` (`context.charger_contexte`/`enregistrer_chemins`, `cameras_screen.lister_boitiers`/`nommer_boitier`). **Aucune nouvelle fonction `regine-core` requise** — tout l'API nécessaire existe et est déjà testée ; ce périmètre est une façade pure (Principe VI), au même titre que `tri_view.py`/`consultation_view.py` l'ont déjà été pour leurs propres capacités.
++
  ## Technical Context
  **Language/Version**: Python 3.11+ (langage retenu pour la bibliothèque centrale de Régine, cf. `docs/interface-cli-gui-architecture.md`)
  **Target Platform**: Poste de travail de bureau (macOS en priorité pour cette itération ; Windows/Linux non couverts par ce plan, cf. research.md) — l'abstraction de déclenchement du montage SMB isole ce choix pour ne pas bloquer une extension future
--**Project Type**: Monorepo — une bibliothèque centrale (`regine-core`) et trois façades indépendantes et installables séparément (`regine-cli`, `regine-gui`, `regine-agent`), conformément au Principe VI de la constitution. Ce plan implémente `regine-core` (module `config`) et `regine-cli` ; `regine-gui` et `regine-agent` sont réservés dans la structure du dépôt mais ne sont pas construits par ce plan (cf. Structure Decision et research.md § 5).
++**Project Type**: Monorepo — une bibliothèque centrale (`regine-core`) et trois façades indépendantes et installables séparément (`regine-cli`, `regine-gui`, `regine-agent`), conformément au Principe VI de la constitution. Ce plan implémente `regine-core` (module `config`) et `regine-cli` ; `regine-agent` reste réservé. **`regine-gui` a depuis été implémentée par `specs/006-gui-tri-consultation`** (PySide6, fenêtre à onglets) — ce plan (extension du 2026-09-21) y ajoute un onglet de configuration (User Story 4), sans toucher aux onglets Tri/Consultation déjà livrés.
  **Performance Goals**: Pas de cible chiffrée spécifique ; la détection de boîtiers (FR-008/SC-007) doit rester quasi instantanée car elle ne lit que la base de contexte locale, sans parcours réseau par défaut
  | III. Identité par contenu, jamais par nom de fichier seul | N/A | Hors périmètre : ce module ne détecte ni renommage ni doublon de fichier. |
  | IV. Métadonnées ouvertes et embarquées | PASS | Le nom lisible d'un boîtier (FR-009) est une convenance locale d'affichage, pas une métadonnée descriptive/de droits au sens du Principe IV (légende, mots-clés, personnes, crédit, copyright, licence) ; l'identité du boîtier reste fondée sur les tags EXIF déjà embarqués par l'appareil (modèle, numéro de série), lesquels restent la source de vérité portable. |
  | V. L'utilisateur décide, Régine suggère | PASS | FR-003 (création de répertoire) et FR-012 (parcours NAS) restent des propositions/actions volontaires, jamais automatiques. |
--| VI. Bibliothèque centrale, façades minces | PASS | Le monorepo matérialise physiquement la séparation : `regine-core` porte toute la logique métier (module `config`), `regine-cli` ne fait qu'appeler `regine-core` et formatter le résultat. `regine-gui`/`regine-agent` sont réservés dans la structure pour dépendre de `regine-core` de la même façon le moment venu, sans logique dupliquée. |
++| VI. Bibliothèque centrale, façades minces | PASS | Le monorepo matérialise physiquement la séparation : `regine-core` porte toute la logique métier (module `config`), `regine-cli` et, depuis l'extension du 2026-09-21, `regine-gui` ne font qu'appeler `regine-core` et formatter le résultat — le nouvel onglet de configuration n'introduit aucune règle de validation propre à la GUI (FR-013). `regine-agent` reste réservé. |
  | CLI-first | PASS | Toute capacité de ce module est exposée en CLI avant toute GUI. |
  | Exécution sans démon | PASS | Chaque commande CLI est un processus isolé ; le déclenchement du montage SMB est une action ponctuelle, pas un service en arrière-plan. |
  | Formats ouverts et documentés | PASS | SQLite, déjà retenu par la constitution pour le manifeste persistant, réutilisé ici avec les mêmes conventions (`PRAGMA user_version`/`application_id`). |
  │       └── contract/
  │           └── test_cli_config.py     # Contrat de la surface CLI (entrées/sorties texte, codes de sortie)
  │
--├── regine-gui/                        # Façade GUI — réservée, non implémentée par ce plan
++├── regine-gui/                        # Façade GUI (PySide6) — implémentée par specs/006, étendue ici
--│   └── (scaffold vide : pyproject.toml déclarant la dépendance à regine-core, aucun code métier)
++│   ├── pyproject.toml
++│   └── src/
++│       └── regine_gui/
++│           ├── app.py                 # existant (specs/006) — ajoute un 3e onglet "Configuration"
++│           ├── tri_view.py            # existant (specs/006), inchangé
++│           ├── consultation_view.py   # existant (specs/006), inchangé
++│           └── config_view.py         # NOUVEAU (User Story 4) — appelle regine_core.config
++│                                         (context.charger_contexte/enregistrer_chemins,
++│                                         cameras_screen.lister_boitiers/nommer_boitier),
++│                                         aucune logique de validation propre
  │
  └── regine-agent/                      # Façade agent IA — réservée, non implémentée par ce plan
      └── (scaffold vide : pyproject.toml déclarant la dépendance à regine-core, aucun code métier)
  **Structure Decision**: Monorepo à quatre parties (Option 1 adaptée du template, multi-packages plutôt que `src/` unique), conformément au Principe VI de la constitution (bibliothèque centrale, façades minces) et à la demande explicite d'organiser dès maintenant la place de la GUI et de l'agent IA. `regine-core` est le premier package de la bibliothèque centrale de Régine (aucun code existant avant ce plan) et pose la convention `packages/<nom>/src/<nom_paquet>/` que les modules métier futurs (`import`, `archive`, `dossier`, `metadata`, `integrity`, `camera_profile` de specs/002) réutiliseront à l'intérieur de `regine-core`. Ce plan implémente `regine-core/config` (chemins, montage SMB, écran de nommage des boîtiers) et `regine-cli` ; `regine-gui` et `regine-agent` sont créés comme paquets vides (dépendance déclarée vers `regine-core`, sans code métier) pour réserver la structure, sans être développés ici. **Correction du 2026-09-18** : la logique de désambiguïsation et la table `boitiers` (initialement esquissées ici sous `config/cameras.py`) sont possédées par le module `regine_core.camera_profile`, spécifié séparément par `specs/002-profil-boitiers-optionnel/plan.md` — `config` ne fait qu'exposer un écran qui délègue à cette API, cohérent avec le Principe VI (une seule bibliothèque centrale, pas de logique dupliquée entre deux specs). L'outillage de workspace (gestion des dépendances inter-paquets, lockfile commun) est tranché en research.md § 5.
++**Extension du 2026-09-21 (User Story 4)** : `regine-gui` n'est plus un paquet vide — `specs/006-gui-tri-consultation` l'a implémenté entre-temps (PySide6, `FenetrePrincipale` à onglets dans `app.py`). Cette extension y ajoute un troisième onglet (`config_view.py`), construit à l'identique de `tri_view.py`/`consultation_view.py` (une classe `QMainWindow`/`QWidget` qui n'appelle que des fonctions déjà publiques de `regine_core.config`, jamais de logique propre) — aucun nouveau research nécessaire (aucune inconnue technique introduite), aucun nouveau contrat `regine-core-api.md` (les fonctions appelées sont déjà toutes documentées).
++
  ## Complexity Tracking
  *Aucune violation de gate à justifier — section laissée vide intentionnellement.*

modified specs/003-config-contexte-travail/quickstart.md +9 -1 Viewed

@@ -66,6 +66,14 @@ regine config cameras scan-nas --confirm
66	66
67	67	Résultat attendu : la première invocation avertit du coût potentiel et n'exécute rien (code non-zéro) ; la seconde, avec `--confirm`, parcourt l'archive et ajoute les boîtiers trouvés avec la source `parcours_nas`.
68	68
	69	+## Scénario 7 — Configurer depuis la GUI, vérifier la parité avec la CLI (User Story 4, P4, extension du 2026-09-21)
	70	+
	71	+```bash
	72	+uv run python -m regine_gui.app
	73	+```
	74	+
	75	+Résultat attendu : l'onglet « Configuration » affiche les mêmes trois chemins et le même état SMB que `regine config show` (scénario 1) ; modifier un chemin depuis cet onglet puis lancer `regine config show` en CLI reflète immédiatement le changement (SC-008) ; tenter d'y reproduire le scénario 3 (changement de `local-work-dir` avec travail non réconcilié) échoue avec le même message d'erreur que la CLI, présenté clairement dans l'interface plutôt que comme une exception technique ; la liste des boîtiers de cet onglet correspond à `regine config cameras list` (scénario 5), et y nommer un boîtier produit le même résultat.
	76	+
69	77	## Critères de sortie
70	78
71		-Les six scénarios ci-dessus, exécutés dans l'ordre sur un contexte propre, doivent tous produire le résultat attendu sans intervention manuelle sur la base de données (uniquement via la CLI). Tout écart doit être tracé comme régression avant de considérer la fonctionnalité prête pour `/speckit-tasks` → implémentation suivante.
	79	+Les sept scénarios ci-dessus, exécutés dans l'ordre sur un contexte propre, doivent tous produire le résultat attendu — les scénarios 1 à 6 sans intervention manuelle (uniquement via la CLI), le scénario 7 en validation manuelle de la GUI (cf. `specs/006-gui-tri-consultation/research.md` § 2 : pas de suite de tests automatisée pour l'interface elle-même). Tout écart doit être tracé comme régression avant de considérer la fonctionnalité prête pour `/speckit-tasks` → implémentation suivante.

  **Résultat attendu** : la première invocation avertit du coût potentiel et n'exécute rien (code non-zéro) ; la seconde, avec `--confirm`, parcourt l'archive et ajoute les boîtiers trouvés avec la source `parcours_nas`.
++## Scénario 7 — Configurer depuis la GUI, vérifier la parité avec la CLI (User Story 4, P4, extension du 2026-09-21)
++
++```bash
++uv run python -m regine_gui.app
++```
++
++**Résultat attendu** : l'onglet « Configuration » affiche les mêmes trois chemins et le même état SMB que `regine config show` (scénario 1) ; modifier un chemin depuis cet onglet puis lancer `regine config show` en CLI reflète immédiatement le changement (SC-008) ; tenter d'y reproduire le scénario 3 (changement de `local-work-dir` avec travail non réconcilié) échoue avec le même message d'erreur que la CLI, présenté clairement dans l'interface plutôt que comme une exception technique ; la liste des boîtiers de cet onglet correspond à `regine config cameras list` (scénario 5), et y nommer un boîtier produit le même résultat.
++
  ## Critères de sortie
--Les six scénarios ci-dessus, exécutés dans l'ordre sur un contexte propre, doivent tous produire le résultat attendu sans intervention manuelle sur la base de données (uniquement via la CLI). Tout écart doit être tracé comme régression avant de considérer la fonctionnalité prête pour `/speckit-tasks` → implémentation suivante.
++Les sept scénarios ci-dessus, exécutés dans l'ordre sur un contexte propre, doivent tous produire le résultat attendu — les scénarios 1 à 6 sans intervention manuelle (uniquement via la CLI), le scénario 7 en validation manuelle de la GUI (cf. `specs/006-gui-tri-consultation/research.md` § 2 : pas de suite de tests automatisée pour l'interface elle-même). Tout écart doit être tracé comme régression avant de considérer la fonctionnalité prête pour `/speckit-tasks` → implémentation suivante.

modified specs/003-config-contexte-travail/spec.md +26 -0 Viewed

@@ -15,6 +15,11 @@
15	15	- Q: Que doit devenir le contenu déjà présent (checkouts en cours, base de données de travail) dans l'ancien répertoire de travail local quand l'utilisateur change ce chemin de configuration ? → A: Régine refuse le changement tant qu'un checkout ou un import n'est pas réconcilié/archivé ; le changement n'est autorisé qu'une fois le répertoire vide de tout travail non archivé.
16	16	- Q: La détection des boîtiers déjà rencontrés (User Story 3) doit-elle parcourir tout le NAS en direct, ou s'appuyer sur des informations déjà connues localement ? → A: Les références de boîtiers sont enregistrées dans une base de contexte centralisée à chaque import ; un parcours à la demande sur l'ensemble du NAS est une capacité complémentaire, optionnelle et à déclenchement volontaire, pas une dépendance obligatoire de la détection de base.
17	17
	18	+### Session 2026-09-21
	19	+
	20	+- Q: La base de contexte centralisée doit-elle vivre à un emplacement standard différent selon le système d'exploitation (Linux/macOS/Windows) ? → A: Non, pas pour l'instant — l'emplacement unique déjà en place (`~/.regine/`, indépendant de l'OS) est conservé tel quel ; une convention par OS reste une amélioration possible d'une prochaine version, pas un besoin actuel.
	21	+- Q: L'interface graphique doit-elle pouvoir consulter et modifier le contexte de travail ? → A: Oui — en appelant directement `regine_core.config` (mêmes fonctions que la CLI), sans aucune logique de configuration propre à la GUI (Principe VI). Couvert par la nouvelle User Story 4 ci-dessous.
	22	+
18	23	## User Scenarios & Testing (mandatory)
19	24
20	25	### User Story 1 - Configuration initiale des emplacements de travail (Priority: P1)
@@ -68,6 +73,23 @@ Un photographe consulte la configuration de Régine et veut donner un nom lisibl
68	73
69	74	---
70	75
	76	+### User Story 4 - Configurer le contexte de travail depuis l'interface graphique (Priority: P4)
	77	+
	78	+Un photographe qui utilise déjà l'interface graphique de Régine pour trier ses photos (`specs/006-gui-tri-consultation`) veut aussi pouvoir consulter et modifier son contexte de travail (chemins, état du partage SMB, boîtiers nommés) sans repasser par la ligne de commande.
	79	+
	80	+Why this priority: Confort d'usage pur — la CLI (`regine config ...`) couvre déjà 100% de ces capacités et continue de fonctionner à l'identique ; un utilisateur à l'aise avec la ligne de commande peut se passer entièrement de cet onglet.
	81	+
	82	+Independent Test: Peut être testé en ouvrant l'onglet de configuration de la GUI sur une installation neuve, en y saisissant les trois emplacements de travail, puis en vérifiant via `regine config show` que la CLI reflète exactement ce qui a été saisi dans la GUI (et réciproquement).
	83	+
	84	+Acceptance Scenarios:
	85	+
	86	+1. Given l'interface graphique ouverte, When l'utilisateur sélectionne l'onglet de configuration, Then il voit les trois emplacements de travail actuels (ou leur absence) et l'état connu du partage SMB, identiques à ce que renverrait `regine config show`.
	87	+2. Given l'onglet de configuration, When l'utilisateur y modifie un chemin et confirme, Then le changement est appliqué en appelant directement `regine_core.config.context.enregistrer_chemins` — même fonction, mêmes règles (répertoire manquant, collision de chemins, travail non réconcilié) que celles déjà validées côté CLI (FR-003/FR-010), jamais une logique de validation propre à la GUI.
	88	+3. Given une tentative de changement refusée par `regine_core.config` (ex. travail non réconcilié sous l'ancien répertoire de travail local), When l'erreur remonte à la GUI, Then elle est présentée clairement à l'utilisateur (quel dossier réconcilier), jamais une exception technique brute.
	89	+4. Given l'onglet de configuration, When l'utilisateur consulte la liste des boîtiers, Then il retrouve les mêmes boîtiers, dans le même état (nommé ou non), que `regine config cameras list` — et peut leur attribuer un nom depuis cet onglet.
	90	+
	91	+---
	92	+
71	93	### Edge Cases
72	94
73	95	- Que se passe-t-il si le répertoire temporaire et le répertoire de travail local pointent vers le même emplacement ? Régine DOIT avertir l'utilisateur de cette configuration ambiguë plutôt que de l'accepter silencieusement.
@@ -92,6 +114,7 @@ Un photographe consulte la configuration de Régine et veut donner un nom lisibl
92	114	- FR-010: Le système DOIT permettre de modifier tout paramètre du contexte de travail (chemins, boîtiers nommés) après la configuration initiale, sans réinstallation. Pour le répertoire de travail local spécifiquement, le système DOIT refuser ce changement tant qu'un checkout ou un import n'a pas été réconcilié ou archivé, et indiquer clairement ce qui bloque le changement, plutôt que de déplacer ou d'abandonner silencieusement du travail en cours.
93	115	- FR-011: Le système DOIT être conçu pour accueillir de nouveaux paramètres de configuration à l'avenir sans remettre en cause les paramètres déjà définis.
94	116	- FR-012: Le système PEUT proposer, comme action distincte et déclenchée volontairement par l'utilisateur, un parcours complet de l'archive NAS pour détecter les boîtiers de dossiers archivés avant l'existence de cette fonctionnalité ou jamais revus depuis ; cette capacité est complémentaire et n'est pas requise pour que FR-008 soit satisfaite.
	117	+- FR-013: L'interface graphique DOIT pouvoir consulter et modifier le contexte de travail (chemins, boîtiers nommés) en appelant directement les mêmes fonctions de `regine_core.config` que la CLI, sans dupliquer la moindre règle de validation ou de désambiguïsation (Principe VI) — toute règle déjà vraie côté CLI (FR-003/FR-004/FR-010/FR-012) reste vraie à l'identique depuis la GUI.
95	118
96	119	### Key Entities
97	120
@@ -114,6 +137,7 @@ Un photographe consulte la configuration de Régine et veut donner un nom lisibl
114	137	- SC-007: L'ouverture de l'écran de configuration des boîtiers ne déclenche par défaut aucun parcours du NAS ; un tel parcours ne survient que sur action explicite de l'utilisateur (FR-012).
115	138	- SC-005: Modifier un chemin du contexte de travail après la configuration initiale ne provoque la perte d'aucun boîtier déjà nommé.
116	139	- SC-006: 100% des tentatives de changer le répertoire de travail local alors qu'un travail non réconcilié y est présent sont bloquées, avec une explication claire de ce qui doit être réconcilié ou archivé au préalable.
	140	+- SC-008: Toute modification du contexte de travail effectuée depuis la GUI est immédiatement visible via `regine config show`/`cameras list` en CLI, et réciproquement — les deux façades lisent et écrivent le même état, jamais deux états divergents.
117	141
118	142	## Assumptions
119	143
@@ -121,4 +145,6 @@ Un photographe consulte la configuration de Régine et veut donner un nom lisibl
121	145	- Les paramètres supplémentaires évoqués comme "à intégrer plus tard" ne sont pas définis dans cette spécification ; seule l'exigence d'extensibilité (FR-011) les anticipe.
122	146	- Cette spécification s'appuie sur le mécanisme de profil de boîtiers optionnel déjà défini (`specs/002-profil-boitiers-optionnel`) : elle ajoute un point d'entrée proactif de nommage à partir de l'archive existante, sans modifier les règles de désambiguïsation par collision déjà établies.
123	147	- La base de données de travail mentionnée correspond au manifeste persistant par dossier déjà prévu dans la constitution du projet (Workflow d'archivage) ; cette spécification couvre son initialisation au niveau du contexte de travail, pas son schéma détaillé.
	148	+- L'emplacement de la base de contexte centralisée reste unique et indépendant du système d'exploitation (`~/.regine/`) pour cette itération (Clarification 2026-09-21) ; une convention par OS (XDG sur Linux, `Application Support` sur macOS, `%APPDATA%` sur Windows) est une amélioration explicitement différée, pas un besoin de cette spécification.
	149	+- L'onglet de configuration de la GUI (User Story 4) réutilise l'infrastructure déjà en place dans `regine-gui` depuis `specs/006-gui-tri-consultation` (fenêtre à onglets) plutôt que d'introduire une nouvelle application ; il n'ajoute aucune capacité que la CLI n'a pas déjà.
124	150	- La base de contexte centralisée (boîtiers) est distincte des bases de données de travail par dossier : elle vit au niveau du contexte de travail, n'est pas archivée avec un dossier particulier, et n'a pas vocation à remplacer l'index inter-dossiers en lecture seule déjà anticipé comme travail futur dans les notes de conception du projet — le parcours à la demande (FR-012) reste une capacité complémentaire, pas une dépendance de cette spécification.

  - Q: Que doit devenir le contenu déjà présent (checkouts en cours, base de données de travail) dans l'ancien répertoire de travail local quand l'utilisateur change ce chemin de configuration ? → A: Régine refuse le changement tant qu'un checkout ou un import n'est pas réconcilié/archivé ; le changement n'est autorisé qu'une fois le répertoire vide de tout travail non archivé.
  - Q: La détection des boîtiers déjà rencontrés (User Story 3) doit-elle parcourir tout le NAS en direct, ou s'appuyer sur des informations déjà connues localement ? → A: Les références de boîtiers sont enregistrées dans une base de contexte centralisée à chaque import ; un parcours à la demande sur l'ensemble du NAS est une capacité complémentaire, optionnelle et à déclenchement volontaire, pas une dépendance obligatoire de la détection de base.
++### Session 2026-09-21
++
++- Q: La base de contexte centralisée doit-elle vivre à un emplacement standard différent selon le système d'exploitation (Linux/macOS/Windows) ? → A: Non, pas pour l'instant — l'emplacement unique déjà en place (`~/.regine/`, indépendant de l'OS) est conservé tel quel ; une convention par OS reste une amélioration possible d'une prochaine version, pas un besoin actuel.
++- Q: L'interface graphique doit-elle pouvoir consulter et modifier le contexte de travail ? → A: Oui — en appelant directement `regine_core.config` (mêmes fonctions que la CLI), sans aucune logique de configuration propre à la GUI (Principe VI). Couvert par la nouvelle User Story 4 ci-dessous.
++
  ## User Scenarios & Testing *(mandatory)*
  ### User Story 1 - Configuration initiale des emplacements de travail (Priority: P1)
  ---
++### User Story 4 - Configurer le contexte de travail depuis l'interface graphique (Priority: P4)
++
++Un photographe qui utilise déjà l'interface graphique de Régine pour trier ses photos (`specs/006-gui-tri-consultation`) veut aussi pouvoir consulter et modifier son contexte de travail (chemins, état du partage SMB, boîtiers nommés) sans repasser par la ligne de commande.
++
++**Why this priority**: Confort d'usage pur — la CLI (`regine config ...`) couvre déjà 100% de ces capacités et continue de fonctionner à l'identique ; un utilisateur à l'aise avec la ligne de commande peut se passer entièrement de cet onglet.
++
++**Independent Test**: Peut être testé en ouvrant l'onglet de configuration de la GUI sur une installation neuve, en y saisissant les trois emplacements de travail, puis en vérifiant via `regine config show` que la CLI reflète exactement ce qui a été saisi dans la GUI (et réciproquement).
++
++**Acceptance Scenarios**:
++
++1. **Given** l'interface graphique ouverte, **When** l'utilisateur sélectionne l'onglet de configuration, **Then** il voit les trois emplacements de travail actuels (ou leur absence) et l'état connu du partage SMB, identiques à ce que renverrait `regine config show`.
++2. **Given** l'onglet de configuration, **When** l'utilisateur y modifie un chemin et confirme, **Then** le changement est appliqué en appelant directement `regine_core.config.context.enregistrer_chemins` — même fonction, mêmes règles (répertoire manquant, collision de chemins, travail non réconcilié) que celles déjà validées côté CLI (FR-003/FR-010), jamais une logique de validation propre à la GUI.
++3. **Given** une tentative de changement refusée par `regine_core.config` (ex. travail non réconcilié sous l'ancien répertoire de travail local), **When** l'erreur remonte à la GUI, **Then** elle est présentée clairement à l'utilisateur (quel dossier réconcilier), jamais une exception technique brute.
++4. **Given** l'onglet de configuration, **When** l'utilisateur consulte la liste des boîtiers, **Then** il retrouve les mêmes boîtiers, dans le même état (nommé ou non), que `regine config cameras list` — et peut leur attribuer un nom depuis cet onglet.
++
++---
++
  ### Edge Cases
  - Que se passe-t-il si le répertoire temporaire et le répertoire de travail local pointent vers le même emplacement ? Régine DOIT avertir l'utilisateur de cette configuration ambiguë plutôt que de l'accepter silencieusement.
  - **FR-010**: Le système DOIT permettre de modifier tout paramètre du contexte de travail (chemins, boîtiers nommés) après la configuration initiale, sans réinstallation. Pour le répertoire de travail local spécifiquement, le système DOIT refuser ce changement tant qu'un checkout ou un import n'a pas été réconcilié ou archivé, et indiquer clairement ce qui bloque le changement, plutôt que de déplacer ou d'abandonner silencieusement du travail en cours.
  - **FR-011**: Le système DOIT être conçu pour accueillir de nouveaux paramètres de configuration à l'avenir sans remettre en cause les paramètres déjà définis.
  - **FR-012**: Le système PEUT proposer, comme action distincte et déclenchée volontairement par l'utilisateur, un parcours complet de l'archive NAS pour détecter les boîtiers de dossiers archivés avant l'existence de cette fonctionnalité ou jamais revus depuis ; cette capacité est complémentaire et n'est pas requise pour que FR-008 soit satisfaite.
++- **FR-013**: L'interface graphique DOIT pouvoir consulter et modifier le contexte de travail (chemins, boîtiers nommés) en appelant directement les mêmes fonctions de `regine_core.config` que la CLI, sans dupliquer la moindre règle de validation ou de désambiguïsation (Principe VI) — toute règle déjà vraie côté CLI (FR-003/FR-004/FR-010/FR-012) reste vraie à l'identique depuis la GUI.
  ### Key Entities
  - **SC-007**: L'ouverture de l'écran de configuration des boîtiers ne déclenche par défaut aucun parcours du NAS ; un tel parcours ne survient que sur action explicite de l'utilisateur (FR-012).
  - **SC-005**: Modifier un chemin du contexte de travail après la configuration initiale ne provoque la perte d'aucun boîtier déjà nommé.
  - **SC-006**: 100% des tentatives de changer le répertoire de travail local alors qu'un travail non réconcilié y est présent sont bloquées, avec une explication claire de ce qui doit être réconcilié ou archivé au préalable.
++- **SC-008**: Toute modification du contexte de travail effectuée depuis la GUI est immédiatement visible via `regine config show`/`cameras list` en CLI, et réciproquement — les deux façades lisent et écrivent le même état, jamais deux états divergents.
  ## Assumptions
  - Les paramètres supplémentaires évoqués comme "à intégrer plus tard" ne sont pas définis dans cette spécification ; seule l'exigence d'extensibilité (FR-011) les anticipe.
  - Cette spécification s'appuie sur le mécanisme de profil de boîtiers optionnel déjà défini (`specs/002-profil-boitiers-optionnel`) : elle ajoute un point d'entrée proactif de nommage à partir de l'archive existante, sans modifier les règles de désambiguïsation par collision déjà établies.
  - La base de données de travail mentionnée correspond au manifeste persistant par dossier déjà prévu dans la constitution du projet (Workflow d'archivage) ; cette spécification couvre son initialisation au niveau du contexte de travail, pas son schéma détaillé.
++- L'emplacement de la base de contexte centralisée reste unique et indépendant du système d'exploitation (`~/.regine/`) pour cette itération (Clarification 2026-09-21) ; une convention par OS (XDG sur Linux, `Application Support` sur macOS, `%APPDATA%` sur Windows) est une amélioration explicitement différée, pas un besoin de cette spécification.
++- L'onglet de configuration de la GUI (User Story 4) réutilise l'infrastructure déjà en place dans `regine-gui` depuis `specs/006-gui-tri-consultation` (fenêtre à onglets) plutôt que d'introduire une nouvelle application ; il n'ajoute aucune capacité que la CLI n'a pas déjà.
  - La base de contexte centralisée (boîtiers) est distincte des bases de données de travail par dossier : elle vit au niveau du contexte de travail, n'est pas archivée avec un dossier particulier, et n'a pas vocation à remplacer l'index inter-dossiers en lecture seule déjà anticipé comme travail futur dans les notes de conception du projet — le parcours à la demande (FR-012) reste une capacité complémentaire, pas une dépendance de cette spécification.