specs
88ae6fa parent: bea02b7 added
specs/001-import-photos/checklists/requirements.md +51 -0 | new file mode 100644 | ||
| @@ -0,0 +1,51 @@ | ||
| 1 | +# Specification Quality Checklist: Importation de photos depuis une carte mémoire | |
| 2 | + | |
| 3 | +**Purpose**: Validate specification completeness and quality before proceeding to planning | |
| 4 | +**Created**: 2026-09-18 | |
| 5 | +**Feature**: [spec.md](../spec.md) | |
| 6 | + | |
| 7 | +## Content Quality | |
| 8 | + | |
| 9 | +- [x] No implementation details (languages, frameworks, APIs) | |
| 10 | +- [x] Focused on user value and business needs | |
| 11 | +- [x] Written for non-technical stakeholders | |
| 12 | +- [x] All mandatory sections completed | |
| 13 | + | |
| 14 | +## Requirement Completeness | |
| 15 | + | |
| 16 | +- [x] No [NEEDS CLARIFICATION] markers remain | |
| 17 | +- [x] Requirements are testable and unambiguous | |
| 18 | +- [x] Success criteria are measurable | |
| 19 | +- [x] Success criteria are technology-agnostic (no implementation details) | |
| 20 | +- [x] All acceptance scenarios are defined | |
| 21 | +- [x] Edge cases are identified | |
| 22 | +- [x] Scope is clearly bounded | |
| 23 | +- [x] Dependencies and assumptions identified | |
| 24 | + | |
| 25 | +## Feature Readiness | |
| 26 | + | |
| 27 | +- [x] All functional requirements have clear acceptance criteria | |
| 28 | +- [x] User scenarios cover primary flows | |
| 29 | +- [x] Feature meets measurable outcomes defined in Success Criteria | |
| 30 | +- [x] No implementation details leak into specification | |
| 31 | + | |
| 32 | +## Notes | |
| 33 | + | |
| 34 | +- Spécification entièrement dérivée des notes de conception existantes | |
| 35 | + (`docs/archivage-photo-elements-cles.md` section 9, `docs/lexique.md`) et de la constitution du | |
| 36 | + projet (`.specify/memory/constitution.md`, notamment Principes I, II, III, IV, V), qui | |
| 37 | + répondent déjà à la quasi-totalité des questions de périmètre — aucun marqueur | |
| 38 | + [NEEDS CLARIFICATION] n'a été nécessaire. | |
| 39 | +- Le tri ultérieur (sélection, promotion à la racine, suppression de déchets évidents) et le | |
| 40 | + mécanisme de checkout/réconciliation d'un dossier déjà archivé sont explicitement hors périmètre | |
| 41 | + de ce module et documentés en section Assumptions — à couvrir par des spécifications distinctes. | |
| 42 | +- **Mise à jour du 2026-09-18** : FR-015, FR-016, l'entrée "Profil de boîtiers" et l'Assumption | |
| 43 | + correspondante ont été alignés sur `specs/002-profil-boitiers-optionnel` — le profil de boîtiers | |
| 44 | + n'est plus un prérequis avant le premier import, la désambiguïsation par défaut se fait via le | |
| 45 | + tag EXIF de modèle, et le profil/numéro de série/étiquetage manuel ne sont sollicités qu'en cas | |
| 46 | + de collision réelle non résolue par ce tag seul. | |
| 47 | +- **Mise à jour du 2026-09-18 (bis)** : FR-001, un edge case et SC-001 précisent désormais que la | |
| 48 | + vérification par somme de contrôle ne relit jamais une seconde fois la carte mémoire — la somme | |
| 49 | + de la source est calculée au fil de l'unique lecture de la carte pendant la copie, et seule la | |
| 50 | + copie locale (rapide) est relue pour la comparaison, afin de ne pas doubler le temps d'import sur | |
| 51 | + une carte à vitesse d'accès faible. | |
| new file mode 100644 | |||
| @@ -0,0 +1,51 @@ | |||
| 1 | +# Specification Quality Checklist: Importation de photos depuis une carte mémoire | ||
| 2 | + | ||
| 3 | +**Purpose**: Validate specification completeness and quality before proceeding to planning | ||
| 4 | +**Created**: 2026-09-18 | ||
| 5 | +**Feature**: [spec.md](../spec.md) | ||
| 6 | + | ||
| 7 | +## Content Quality | ||
| 8 | + | ||
| 9 | +- [x] No implementation details (languages, frameworks, APIs) | ||
| 10 | +- [x] Focused on user value and business needs | ||
| 11 | +- [x] Written for non-technical stakeholders | ||
| 12 | +- [x] All mandatory sections completed | ||
| 13 | + | ||
| 14 | +## Requirement Completeness | ||
| 15 | + | ||
| 16 | +- [x] No [NEEDS CLARIFICATION] markers remain | ||
| 17 | +- [x] Requirements are testable and unambiguous | ||
| 18 | +- [x] Success criteria are measurable | ||
| 19 | +- [x] Success criteria are technology-agnostic (no implementation details) | ||
| 20 | +- [x] All acceptance scenarios are defined | ||
| 21 | +- [x] Edge cases are identified | ||
| 22 | +- [x] Scope is clearly bounded | ||
| 23 | +- [x] Dependencies and assumptions identified | ||
| 24 | + | ||
| 25 | +## Feature Readiness | ||
| 26 | + | ||
| 27 | +- [x] All functional requirements have clear acceptance criteria | ||
| 28 | +- [x] User scenarios cover primary flows | ||
| 29 | +- [x] Feature meets measurable outcomes defined in Success Criteria | ||
| 30 | +- [x] No implementation details leak into specification | ||
| 31 | + | ||
| 32 | +## Notes | ||
| 33 | + | ||
| 34 | +- Spécification entièrement dérivée des notes de conception existantes | ||
| 35 | + (`docs/archivage-photo-elements-cles.md` section 9, `docs/lexique.md`) et de la constitution du | ||
| 36 | + projet (`.specify/memory/constitution.md`, notamment Principes I, II, III, IV, V), qui | ||
| 37 | + répondent déjà à la quasi-totalité des questions de périmètre — aucun marqueur | ||
| 38 | + [NEEDS CLARIFICATION] n'a été nécessaire. | ||
| 39 | +- Le tri ultérieur (sélection, promotion à la racine, suppression de déchets évidents) et le | ||
| 40 | + mécanisme de checkout/réconciliation d'un dossier déjà archivé sont explicitement hors périmètre | ||
| 41 | + de ce module et documentés en section Assumptions — à couvrir par des spécifications distinctes. | ||
| 42 | +- **Mise à jour du 2026-09-18** : FR-015, FR-016, l'entrée "Profil de boîtiers" et l'Assumption | ||
| 43 | + correspondante ont été alignés sur `specs/002-profil-boitiers-optionnel` — le profil de boîtiers | ||
| 44 | + n'est plus un prérequis avant le premier import, la désambiguïsation par défaut se fait via le | ||
| 45 | + tag EXIF de modèle, et le profil/numéro de série/étiquetage manuel ne sont sollicités qu'en cas | ||
| 46 | + de collision réelle non résolue par ce tag seul. | ||
| 47 | +- **Mise à jour du 2026-09-18 (bis)** : FR-001, un edge case et SC-001 précisent désormais que la | ||
| 48 | + vérification par somme de contrôle ne relit jamais une seconde fois la carte mémoire — la somme | ||
| 49 | + de la source est calculée au fil de l'unique lecture de la carte pendant la copie, et seule la | ||
| 50 | + copie locale (rapide) est relue pour la comparaison, afin de ne pas doubler le temps d'import sur | ||
| 51 | + une carte à vitesse d'accès faible. | ||
added
specs/001-import-photos/spec.md +131 -0 | new file mode 100644 | ||
| @@ -0,0 +1,131 @@ | ||
| 1 | +# Feature Specification: Importation de photos depuis une carte mémoire | |
| 2 | + | |
| 3 | +**Feature Branch**: `[001-import-photos]` | |
| 4 | + | |
| 5 | +**Created**: 2026-09-18 | |
| 6 | + | |
| 7 | +**Status**: Draft | |
| 8 | + | |
| 9 | +**Input**: User description: "utilise les docs pour generer la specification du module d'importation des photos" | |
| 10 | + | |
| 11 | +## User Scenarios & Testing *(mandatory)* | |
| 12 | + | |
| 13 | +### User Story 1 - Import simple d'une carte mémoire vers un nouveau dossier (Priority: P1) | |
| 14 | + | |
| 15 | +Un photographe rentre d'une sortie photo avec une carte mémoire. Il demande à Régine d'importer le contenu de la carte : Régine copie les fichiers en sécurité, propose un titre et un nom de dossier à partir des dates de prise de vue, renomme les fichiers de façon lisible, puis archive le tout dans un nouveau dossier. | |
| 16 | + | |
| 17 | +**Why this priority**: C'est le point d'entrée de toute photo dans Régine — sans cette histoire, aucun autre module (tri, sélection, archivage, planche-contact) n'a de matière à traiter. C'est aussi la première fois qu'une carte mémoire peut être effacée en confiance. | |
| 18 | + | |
| 19 | +**Independent Test**: Peut être testé de façon autonome en branchant une carte mémoire contenant les photos d'une seule journée, en lançant l'import, et en vérifiant qu'un dossier correctement nommé apparaît dans l'archive avec tous les fichiers renommés et vérifiés — sans dépendre d'aucune autre fonctionnalité de Régine. | |
| 20 | + | |
| 21 | +**Acceptance Scenarios**: | |
| 22 | + | |
| 23 | +1. **Given** une carte mémoire contenant des photos d'une seule journée, jamais importées auparavant, **When** l'utilisateur lance l'import, **Then** Régine copie les fichiers vers un espace de travail local en vérifiant chaque fichier par somme de contrôle avant de signaler la carte comme sûre à effacer. | |
| 24 | +2. **Given** la copie locale vérifiée d'une carte à une seule journée, **When** Régine analyse les dates de prise de vue, **Then** elle propose un seul groupe couvrant cette journée et invite l'utilisateur à donner un titre. | |
| 25 | +3. **Given** un titre saisi par l'utilisateur, **When** Régine construit le nom du dossier, **Then** elle produit un nom au format `AAAA-MM-JJ_Titre`, nettoyé des caractères interdits et des espaces, et vérifie qu'aucun dossier identique n'existe déjà avant de le créer. | |
| 26 | +4. **Given** un nom de dossier validé, **When** Régine renomme les fichiers avant archivage, **Then** chaque fichier maître est renommé en `date_titre_nomOrigine.ext` en conservant le nom d'origine du boîtier en suffixe, et tout fichier associé (JPEG jumeau, sidecar) est renommé de façon synchronisée. | |
| 27 | +5. **Given** des fichiers renommés localement, **When** Régine pousse le dossier vers l'archive, **Then** elle présente d'abord un résumé (nombre de fichiers, taille, nom du dossier de destination) et attend une confirmation explicite avant d'écrire quoi que ce soit sur l'archive. | |
| 28 | + | |
| 29 | +--- | |
| 30 | + | |
| 31 | +### User Story 2 - Découpage d'un import multi-jours en plusieurs groupes (Priority: P2) | |
| 32 | + | |
| 33 | +Un photographe importe une carte couvrant plusieurs jours consécutifs (ex. une semaine de vacances incluant un anniversaire). Il veut que l'anniversaire devienne son propre dossier plutôt que d'être noyé dans le dossier de vacances. | |
| 34 | + | |
| 35 | +**Why this priority**: Une carte couvrant plusieurs jours est un cas courant (voyages, week-ends prolongés) ; sans ce découpage, l'utilisateur devrait réorganiser l'archive manuellement après coup, ce que Régine cherche justement à éviter. | |
| 36 | + | |
| 37 | +**Independent Test**: Peut être testé en important une carte dont les dates EXIF couvrent une semaine avec un pic de prise de vue isolé sur une journée, en vérifiant que Régine propose ce jour comme candidat au détachement, et que l'utilisateur peut confirmer ou ignorer cette suggestion pour obtenir deux dossiers distincts au lieu d'un. | |
| 38 | + | |
| 39 | +**Acceptance Scenarios**: | |
| 40 | + | |
| 41 | +1. **Given** une copie locale vérifiée dont les dates EXIF couvrent une plage contiguë de plusieurs jours, **When** Régine analyse la répartition jour par jour, **Then** elle affiche le nombre de photos et la plage horaire par jour et propose par défaut un seul groupe couvrant toute la plage. | |
| 42 | +2. **Given** cette répartition jour par jour, **When** un jour présente un pic de prises de vue nettement différent du reste, **Then** Régine met en avant ce jour comme candidat plausible à détacher, sans jamais le détacher elle-même. | |
| 43 | +3. **Given** la proposition d'un seul groupe, **When** l'utilisateur détache un ou plusieurs jours au milieu de la plage, **Then** Régine crée un groupe séparé pour les jours détachés et conserve pour le groupe restant le nom de la plage d'origine plutôt que de la recalculer. | |
| 44 | +4. **Given** plusieurs groupes issus du découpage, **When** l'utilisateur valide, **Then** Régine demande la destination et le titre de chaque groupe indépendamment, avant de renommer et d'archiver chacun séparément. | |
| 45 | + | |
| 46 | +--- | |
| 47 | + | |
| 48 | +### User Story 3 - Import s'intégrant à un voyage en plusieurs étapes (Priority: P3) | |
| 49 | + | |
| 50 | +Un photographe est en voyage sur plusieurs villes. Pour la deuxième étape, il importe une nouvelle carte et veut qu'elle s'intègre comme sous-dossier du voyage déjà commencé plutôt que de créer un dossier indépendant. Il peut aussi avoir utilisé deux boîtiers ou une carte de secours pour la même étape. | |
| 51 | + | |
| 52 | +**Why this priority**: Couvre le cas d'usage le plus riche fonctionnellement (structure à deux niveaux, fusion de sources multiples) mais reste un raffinement de l'import simple (P1) : un utilisateur qui ne voyage jamais en plusieurs étapes n'a pas besoin de cette histoire pour tirer de la valeur de Régine. | |
| 53 | + | |
| 54 | +**Independent Test**: Peut être testé en import et une première carte comme "nouveau dossier parent avec sa première étape", puis en import et une seconde carte en choisissant "nouveau sous-dossier dans un dossier parent existant", et en vérifiant que la structure finale a bien deux niveaux avec les deux étapes correctement nommées et rattachées. | |
| 55 | + | |
| 56 | +**Acceptance Scenarios**: | |
| 57 | + | |
| 58 | +1. **Given** un premier import connu comme le début d'un voyage à plusieurs étapes, **When** l'utilisateur choisit la destination "nouveau dossier parent avec sa première étape", **Then** Régine crée directement une structure à deux niveaux (dossier parent au format `AAAA-MM_Titre`, sous-dossier au format `AAAA-MM-JJ_Titre_Lieu`). | |
| 59 | +2. **Given** un dossier parent de voyage déjà existant, **When** l'utilisateur importe une nouvelle carte pour une étape suivante et choisit "nouveau sous-dossier dans un dossier parent existant", **Then** Régine liste les dossiers parents existants (locaux et archivés) pour que l'utilisateur choisisse le bon, puis crée le sous-dossier à l'intérieur. | |
| 60 | +3. **Given** deux cartes mémoire couvrant la même étape (deux boîtiers, ou une carte de secours), **When** l'utilisateur choisit "fusion dans un dossier existant" pour la seconde carte, **Then** Régine ajoute directement les nouveaux fichiers au dossier ciblé, sans créer de sous-dossier supplémentaire, en détectant les doublons éventuels par somme de contrôle. | |
| 61 | +4. **Given** une fusion vers un dossier déjà archivé sur l'archive plutôt que seulement local, **When** Régine prépare la fusion, **Then** elle effectue d'abord un aller-retour de vérification (checkout) sur ce dossier avant d'y intégrer les nouveaux fichiers. | |
| 62 | +5. **Given** deux boîtiers différents produisant chacun un fichier de même nom d'origine au sein d'un même import, **When** Régine détecte la collision par somme de contrôle, **Then** elle désambiguïse par défaut les deux sources à partir du tag EXIF de modèle de chaque fichier, sans exiger de profil de boîtiers préalablement déclaré, et ne sollicite l'utilisateur (profil, numéro de série, étiquetage manuel) que si ce tag ne suffit pas à distinguer les sources (cf. `specs/002-profil-boitiers-optionnel`). | |
| 63 | + | |
| 64 | +--- | |
| 65 | + | |
| 66 | +### Edge Cases | |
| 67 | + | |
| 68 | +- Que se passe-t-il si un fichier ne peut pas être vérifié par somme de contrôle pendant la copie depuis la carte (lecture corrompue) ? La copie de ce fichier DOIT être signalée en échec et la carte ne DOIT PAS être considérée comme sûre à effacer tant que le fichier n'est pas correctement recopié et vérifié. | |
| 69 | +- Que se passe-t-il si la carte mémoire a une vitesse d'accès en lecture particulièrement faible ? La vérification d'intégrité ne DOIT jamais nécessiter une seconde lecture de la carte pour un même fichier : la comparaison se fait entre la somme de contrôle calculée pendant l'unique lecture de la carte et celle recalculée en relisant la copie locale sur disque, pour ne pas doubler le temps d'import sur une carte lente. | |
| 70 | +- Comment le système gère-t-il une carte contenant des dates de prise de vue aberrantes (horloge de boîtier réinitialisée, ex. dates en 1980 ou 2002) ? Ces fichiers DOIVENT être exclus du calcul de la plage de dates et signalés à l'utilisateur comme anomalie, plutôt que de fausser silencieusement le découpage en groupes. | |
| 71 | +- Comment le système gère-t-il une carte contenant à la fois des fichiers déjà importés lors d'une session précédente (non effacés de la carte) et des fichiers réellement nouveaux ? Seuls les fichiers réellement nouveaux (identifiés par somme de contrôle, absents des imports précédents) DOIVENT entrer dans l'analyse et le découpage en groupes. | |
| 72 | +- Que se passe-t-il si le nom de dossier calculé entre en collision avec un dossier existant (local ou archivé) ? Le système DOIT proposer un suffixe ou demander une confirmation explicite, jamais écraser silencieusement le dossier existant. | |
| 73 | +- Que se passe-t-il si l'espace disque local est insuffisant pour accueillir la copie de travail avant même de commencer la copie ? Le système DOIT vérifier l'espace disponible avant de démarrer la copie et interrompre l'import avec un message clair plutôt que d'échouer en cours de copie. | |
| 74 | +- Comment le système traite-t-il un fichier présent sur la carte qui n'est ni une photo ni un fichier associé reconnu (ex. vidéo, fichier système du boîtier) ? Ce fichier est hors périmètre de l'import et n'est ni copié ni pris en compte dans l'analyse (cf. Assumptions). | |
| 75 | + | |
| 76 | +## Requirements *(mandatory)* | |
| 77 | + | |
| 78 | +### Functional Requirements | |
| 79 | + | |
| 80 | +- **FR-001**: Le système DOIT copier l'intégralité des fichiers nouveaux d'une carte mémoire vers un espace de travail local en une seule lecture de la carte par fichier, en calculant la somme de contrôle de la source au fil de cette copie. Il DOIT ensuite vérifier l'intégrité de la copie en relisant le fichier déjà écrit sur le disque local — jamais en relisant une seconde fois la carte mémoire — et comparer les deux sommes de contrôle avant de considérer la carte comme sûre à effacer. | |
| 81 | +- **FR-002**: Le système DOIT lire la date de prise de vue (métadonnée EXIF d'origine, jamais la date de fichier) de chaque fichier nouvellement importé, et construire une répartition jour par jour (nombre de photos, plage horaire) du lot importé. | |
| 82 | +- **FR-003**: Le système DOIT exclure du calcul de plage les fichiers dont la date de prise de vue est aberrante et signaler cette anomalie à l'utilisateur, plutôt que d'inclure silencieusement ces dates dans la plage détectée. | |
| 83 | +- **FR-004**: Le système DOIT ne prendre en compte, pour l'analyse et le découpage en groupes, que les fichiers réellement nouveaux pour l'import en cours (identifiés par somme de contrôle), à l'exclusion de tout fichier déjà importé lors d'une session précédente et resté sur la carte. | |
| 84 | +- **FR-005**: Le système DOIT proposer par défaut un seul groupe couvrant toute la plage de dates contiguë détectée, et permettre à l'utilisateur de détacher un ou plusieurs jours de cette plage pour former des groupes distincts. | |
| 85 | +- **FR-006**: Le système PEUT mettre en avant un ou plusieurs jours comme candidats plausibles au détachement (ex. pic de prises de vue isolé), mais ne DOIT jamais détacher un groupe automatiquement sans validation de l'utilisateur. | |
| 86 | +- **FR-007**: Pour chaque groupe résultant du découpage, le système DOIT demander explicitement à l'utilisateur sa destination, parmi : nouveau dossier simple, nouveau sous-dossier d'un dossier parent existant, fusion dans un dossier existant, ou nouveau dossier parent avec sa première étape — sans jamais retenir un état "voyage en cours" d'un import à l'autre. | |
| 87 | +- **FR-008**: Pour aider l'utilisateur à choisir une destination de sous-dossier ou de fusion, le système DOIT lister les dossiers candidats existants à la fois dans l'espace de travail local et dans l'archive (recherche par titre ou date proche). | |
| 88 | +- **FR-009**: Lorsqu'une fusion cible un dossier déjà présent dans l'archive (et pas seulement en local), le système DOIT d'abord effectuer une vérification (checkout) de ce dossier avant d'y intégrer les nouveaux fichiers. | |
| 89 | +- **FR-010**: Le système DOIT demander un titre pour chaque groupe, le nettoyer pour en faire un nom de dossier valide (espaces convertis, caractères interdits refusés), puis le combiner avec la plage de dates selon la granularité appropriée (jour unique, plage dans le même mois, plage à cheval sur deux mois/années, ou granularité mois pour un dossier parent de voyage). | |
| 90 | +- **FR-011**: Le système PEUT suggérer automatiquement un lieu à partir de coordonnées GPS présentes dans les métadonnées EXIF, mais cette suggestion reste modifiable et ne DOIT jamais être imposée à l'utilisateur. | |
| 91 | +- **FR-012**: Le système DOIT vérifier, avant de créer un dossier final, qu'aucun dossier de nom identique n'existe déjà ; en cas de collision, il DOIT proposer un suffixe ou demander une confirmation explicite plutôt que d'écraser. | |
| 92 | +- **FR-013**: Le système DOIT renommer chaque fichier maître importé selon la convention `date_titre_nomOrigine.ext`, en conservant le nom d'origine attribué par le boîtier en suffixe, une fois le titre du groupe choisi et juste avant l'archivage. | |
| 93 | +- **FR-014**: Le système DOIT renommer de façon synchronisée tout fichier partageant le même nom de base qu'un fichier maître renommé (JPEG jumeau en mode RAW+JPEG, sidecar de réglages), pour préserver leur appariement. | |
| 94 | +- **FR-015**: Le système DOIT désambiguïser par défaut deux fichiers de même nom d'origine provenant de boîtiers différents à partir du tag EXIF de modèle de chaque fichier, sans exiger qu'un profil de boîtiers ait été préalablement déclaré ; il ne DOIT solliciter l'utilisateur (profil, numéro de série, étiquetage manuel) qu'au moment où une collision réelle est détectée par somme de contrôle et où ce tag ne suffit pas à distinguer les sources (cf. `specs/002-profil-boitiers-optionnel`, qui définit ce mécanisme de désambiguïsation en détail). | |
| 95 | +- **FR-016**: La détection d'un modèle de boîtier jamais rencontré auparavant dans les métadonnées d'un fichier ne DOIT, en l'absence de toute collision réelle, ni interrompre l'import ni exiger une action sur le profil de boîtiers. | |
| 96 | +- **FR-017**: Le système DOIT attribuer un identifiant pérenne, indépendant du nom de fichier, à chaque photo importée, et l'inscrire dans les métadonnées embarquées du fichier. | |
| 97 | +- **FR-018**: Avant d'écrire quoi que ce soit sur l'archive (création de dossier, archivage des fichiers renommés, fusion dans un dossier existant), le système DOIT présenter à l'utilisateur un résumé de l'opération (nombre de fichiers concernés, dossier de destination) et attendre une confirmation explicite. | |
| 98 | +- **FR-019**: Le système DOIT effectuer le transfert final vers l'archive à partir de la copie de travail locale déjà vérifiée et renommée, plutôt que par une copie directe de la carte mémoire vers l'archive. | |
| 99 | + | |
| 100 | +### Key Entities | |
| 101 | + | |
| 102 | +- **Carte mémoire** : support source d'un import, contenant des fichiers déjà importés lors de sessions précédentes et des fichiers réellement nouveaux à traiter. | |
| 103 | +- **Copie de travail locale** : copie temporaire et vérifiée par somme de contrôle des fichiers nouveaux d'une carte, base de toute l'analyse et du renommage avant archivage. | |
| 104 | +- **Groupe d'import** : sous-ensemble de fichiers nouvellement importés partageant une plage de dates contiguë, destiné à devenir un dossier ou un sous-dossier de l'archive. | |
| 105 | +- **Dossier** : unité d'archive résultant d'un groupe simple, avec sa structure par format et sa racine de sélection. | |
| 106 | +- **Dossier parent / sous-dossier** : structure à deux niveaux résultant d'un import s'intégrant à un voyage en plusieurs étapes. | |
| 107 | +- **Profil de boîtiers** : liste optionnelle d'appareils, alimentée à la demande (cf. `specs/002-profil-boitiers-optionnel`), utilisée pour désambiguïser la source d'un fichier lorsqu'une collision réelle de nom d'origine survient et que le tag de modèle seul ne suffit pas à la résoudre. | |
| 108 | +- **Fichier maître** : photo issue directement du boîtier (RAW ou JPEG selon les cas), renommée à l'import et jamais modifiée une fois archivée. | |
| 109 | +- **Fichier associé** : fichier partageant le nom de base d'un fichier maître (JPEG jumeau, sidecar de réglages), renommé de façon synchronisée avec lui. | |
| 110 | +- **Identifiant pérenne** : identifiant attribué à chaque photo importée, indépendant de son nom de fichier, inscrit dans ses métadonnées. | |
| 111 | + | |
| 112 | +## Success Criteria *(mandatory)* | |
| 113 | + | |
| 114 | +### Measurable Outcomes | |
| 115 | + | |
| 116 | +- **SC-001**: 100% des fichiers copiés depuis une carte mémoire sont vérifiés par somme de contrôle avant que la carte ne soit signalée comme sûre à effacer, sans qu'aucun fichier ne nécessite plus d'une lecture complète de la carte, quelle que soit sa vitesse d'accès. | |
| 117 | +- **SC-002**: Pour un import à une seule journée sur un seul boîtier, l'utilisateur obtient un dossier archivé, correctement nommé et vérifié, en validant au plus deux décisions (titre, confirmation d'archivage). | |
| 118 | +- **SC-003**: 100% des dates de prise de vue aberrantes détectées sur une carte sont signalées à l'utilisateur plutôt qu'intégrées silencieusement au découpage en groupes. | |
| 119 | +- **SC-004**: 100% des collisions de nom de dossier sont présentées à l'utilisateur avec un choix explicite ; aucune collision ne provoque d'écrasement silencieux. | |
| 120 | +- **SC-005**: 100% des paires de fichiers associés (fichier maître + JPEG jumeau ou sidecar) conservent leur appariement (même nom de base) après renommage à l'import. | |
| 121 | +- **SC-006**: Aucune écriture sur l'archive (création de dossier, ajout de fichiers) ne survient sans qu'un résumé de l'opération n'ait été présenté et explicitement confirmé par l'utilisateur. | |
| 122 | +- **SC-007**: Un utilisateur qui importe une carte couvrant un voyage en plusieurs étapes peut obtenir une structure à deux niveaux correctement rattachée sans avoir à renommer ou déplacer manuellement de dossier après l'import. | |
| 123 | + | |
| 124 | +## Assumptions | |
| 125 | + | |
| 126 | +- Le module d'importation couvre le trajet complet depuis la carte mémoire jusqu'au premier archivage des fichiers renommés ; il ne couvre pas le tri ultérieur (sélection, promotion à la racine) ni la suppression de déchets évidents, qui relèvent du flux de réconciliation lors d'une édition (hors périmètre de ce module). | |
| 127 | +- Les fichiers présents sur la carte mémoire qui ne sont ni des photos (RAW, JPEG, TIFF) ni des fichiers associés reconnus (sidecars) sont hors périmètre de l'import : ils ne sont ni copiés ni pris en compte dans l'analyse. | |
| 128 | +- Le profil de boîtiers est une capacité optionnelle, alimentée à la demande et non un prérequis avant le premier import (cf. `specs/002-profil-boitiers-optionnel`, qui révise et détaille ce comportement) : ce module se désambiguïse par défaut via le tag EXIF de modèle, et ne sollicite le profil, un numéro de série, ou un étiquetage manuel qu'en cas de collision réelle non résolue par ce tag seul. | |
| 129 | +- Le mécanisme de checkout/réconciliation d'un dossier déjà archivé (utilisé au cas de fusion vers un dossier existant sur l'archive) est une capacité déjà disponible ou livrée avant ou avec ce module ; ce module ne redéfinit pas ce mécanisme, il s'appuie dessus. | |
| 130 | +- La suggestion automatique de lieu par coordonnées GPS dépend de la présence de ces coordonnées dans les métadonnées du fichier ; en leur absence, l'utilisateur saisit le lieu librement, sans que cela bloque l'import. | |
| 131 | +- Une seule carte mémoire est traitée à la fois par import ; l'import simultané de plusieurs cartes n'est pas couvert par ce module. | |
| new file mode 100644 | |||
| @@ -0,0 +1,131 @@ | |||
| 1 | +# Feature Specification: Importation de photos depuis une carte mémoire | ||
| 2 | + | ||
| 3 | +**Feature Branch**: `[001-import-photos]` | ||
| 4 | + | ||
| 5 | +**Created**: 2026-09-18 | ||
| 6 | + | ||
| 7 | +**Status**: Draft | ||
| 8 | + | ||
| 9 | +**Input**: User description: "utilise les docs pour generer la specification du module d'importation des photos" | ||
| 10 | + | ||
| 11 | +## User Scenarios & Testing *(mandatory)* | ||
| 12 | + | ||
| 13 | +### User Story 1 - Import simple d'une carte mémoire vers un nouveau dossier (Priority: P1) | ||
| 14 | + | ||
| 15 | +Un photographe rentre d'une sortie photo avec une carte mémoire. Il demande à Régine d'importer le contenu de la carte : Régine copie les fichiers en sécurité, propose un titre et un nom de dossier à partir des dates de prise de vue, renomme les fichiers de façon lisible, puis archive le tout dans un nouveau dossier. | ||
| 16 | + | ||
| 17 | +**Why this priority**: C'est le point d'entrée de toute photo dans Régine — sans cette histoire, aucun autre module (tri, sélection, archivage, planche-contact) n'a de matière à traiter. C'est aussi la première fois qu'une carte mémoire peut être effacée en confiance. | ||
| 18 | + | ||
| 19 | +**Independent Test**: Peut être testé de façon autonome en branchant une carte mémoire contenant les photos d'une seule journée, en lançant l'import, et en vérifiant qu'un dossier correctement nommé apparaît dans l'archive avec tous les fichiers renommés et vérifiés — sans dépendre d'aucune autre fonctionnalité de Régine. | ||
| 20 | + | ||
| 21 | +**Acceptance Scenarios**: | ||
| 22 | + | ||
| 23 | +1. **Given** une carte mémoire contenant des photos d'une seule journée, jamais importées auparavant, **When** l'utilisateur lance l'import, **Then** Régine copie les fichiers vers un espace de travail local en vérifiant chaque fichier par somme de contrôle avant de signaler la carte comme sûre à effacer. | ||
| 24 | +2. **Given** la copie locale vérifiée d'une carte à une seule journée, **When** Régine analyse les dates de prise de vue, **Then** elle propose un seul groupe couvrant cette journée et invite l'utilisateur à donner un titre. | ||
| 25 | +3. **Given** un titre saisi par l'utilisateur, **When** Régine construit le nom du dossier, **Then** elle produit un nom au format `AAAA-MM-JJ_Titre`, nettoyé des caractères interdits et des espaces, et vérifie qu'aucun dossier identique n'existe déjà avant de le créer. | ||
| 26 | +4. **Given** un nom de dossier validé, **When** Régine renomme les fichiers avant archivage, **Then** chaque fichier maître est renommé en `date_titre_nomOrigine.ext` en conservant le nom d'origine du boîtier en suffixe, et tout fichier associé (JPEG jumeau, sidecar) est renommé de façon synchronisée. | ||
| 27 | +5. **Given** des fichiers renommés localement, **When** Régine pousse le dossier vers l'archive, **Then** elle présente d'abord un résumé (nombre de fichiers, taille, nom du dossier de destination) et attend une confirmation explicite avant d'écrire quoi que ce soit sur l'archive. | ||
| 28 | + | ||
| 29 | +--- | ||
| 30 | + | ||
| 31 | +### User Story 2 - Découpage d'un import multi-jours en plusieurs groupes (Priority: P2) | ||
| 32 | + | ||
| 33 | +Un photographe importe une carte couvrant plusieurs jours consécutifs (ex. une semaine de vacances incluant un anniversaire). Il veut que l'anniversaire devienne son propre dossier plutôt que d'être noyé dans le dossier de vacances. | ||
| 34 | + | ||
| 35 | +**Why this priority**: Une carte couvrant plusieurs jours est un cas courant (voyages, week-ends prolongés) ; sans ce découpage, l'utilisateur devrait réorganiser l'archive manuellement après coup, ce que Régine cherche justement à éviter. | ||
| 36 | + | ||
| 37 | +**Independent Test**: Peut être testé en important une carte dont les dates EXIF couvrent une semaine avec un pic de prise de vue isolé sur une journée, en vérifiant que Régine propose ce jour comme candidat au détachement, et que l'utilisateur peut confirmer ou ignorer cette suggestion pour obtenir deux dossiers distincts au lieu d'un. | ||
| 38 | + | ||
| 39 | +**Acceptance Scenarios**: | ||
| 40 | + | ||
| 41 | +1. **Given** une copie locale vérifiée dont les dates EXIF couvrent une plage contiguë de plusieurs jours, **When** Régine analyse la répartition jour par jour, **Then** elle affiche le nombre de photos et la plage horaire par jour et propose par défaut un seul groupe couvrant toute la plage. | ||
| 42 | +2. **Given** cette répartition jour par jour, **When** un jour présente un pic de prises de vue nettement différent du reste, **Then** Régine met en avant ce jour comme candidat plausible à détacher, sans jamais le détacher elle-même. | ||
| 43 | +3. **Given** la proposition d'un seul groupe, **When** l'utilisateur détache un ou plusieurs jours au milieu de la plage, **Then** Régine crée un groupe séparé pour les jours détachés et conserve pour le groupe restant le nom de la plage d'origine plutôt que de la recalculer. | ||
| 44 | +4. **Given** plusieurs groupes issus du découpage, **When** l'utilisateur valide, **Then** Régine demande la destination et le titre de chaque groupe indépendamment, avant de renommer et d'archiver chacun séparément. | ||
| 45 | + | ||
| 46 | +--- | ||
| 47 | + | ||
| 48 | +### User Story 3 - Import s'intégrant à un voyage en plusieurs étapes (Priority: P3) | ||
| 49 | + | ||
| 50 | +Un photographe est en voyage sur plusieurs villes. Pour la deuxième étape, il importe une nouvelle carte et veut qu'elle s'intègre comme sous-dossier du voyage déjà commencé plutôt que de créer un dossier indépendant. Il peut aussi avoir utilisé deux boîtiers ou une carte de secours pour la même étape. | ||
| 51 | + | ||
| 52 | +**Why this priority**: Couvre le cas d'usage le plus riche fonctionnellement (structure à deux niveaux, fusion de sources multiples) mais reste un raffinement de l'import simple (P1) : un utilisateur qui ne voyage jamais en plusieurs étapes n'a pas besoin de cette histoire pour tirer de la valeur de Régine. | ||
| 53 | + | ||
| 54 | +**Independent Test**: Peut être testé en import et une première carte comme "nouveau dossier parent avec sa première étape", puis en import et une seconde carte en choisissant "nouveau sous-dossier dans un dossier parent existant", et en vérifiant que la structure finale a bien deux niveaux avec les deux étapes correctement nommées et rattachées. | ||
| 55 | + | ||
| 56 | +**Acceptance Scenarios**: | ||
| 57 | + | ||
| 58 | +1. **Given** un premier import connu comme le début d'un voyage à plusieurs étapes, **When** l'utilisateur choisit la destination "nouveau dossier parent avec sa première étape", **Then** Régine crée directement une structure à deux niveaux (dossier parent au format `AAAA-MM_Titre`, sous-dossier au format `AAAA-MM-JJ_Titre_Lieu`). | ||
| 59 | +2. **Given** un dossier parent de voyage déjà existant, **When** l'utilisateur importe une nouvelle carte pour une étape suivante et choisit "nouveau sous-dossier dans un dossier parent existant", **Then** Régine liste les dossiers parents existants (locaux et archivés) pour que l'utilisateur choisisse le bon, puis crée le sous-dossier à l'intérieur. | ||
| 60 | +3. **Given** deux cartes mémoire couvrant la même étape (deux boîtiers, ou une carte de secours), **When** l'utilisateur choisit "fusion dans un dossier existant" pour la seconde carte, **Then** Régine ajoute directement les nouveaux fichiers au dossier ciblé, sans créer de sous-dossier supplémentaire, en détectant les doublons éventuels par somme de contrôle. | ||
| 61 | +4. **Given** une fusion vers un dossier déjà archivé sur l'archive plutôt que seulement local, **When** Régine prépare la fusion, **Then** elle effectue d'abord un aller-retour de vérification (checkout) sur ce dossier avant d'y intégrer les nouveaux fichiers. | ||
| 62 | +5. **Given** deux boîtiers différents produisant chacun un fichier de même nom d'origine au sein d'un même import, **When** Régine détecte la collision par somme de contrôle, **Then** elle désambiguïse par défaut les deux sources à partir du tag EXIF de modèle de chaque fichier, sans exiger de profil de boîtiers préalablement déclaré, et ne sollicite l'utilisateur (profil, numéro de série, étiquetage manuel) que si ce tag ne suffit pas à distinguer les sources (cf. `specs/002-profil-boitiers-optionnel`). | ||
| 63 | + | ||
| 64 | +--- | ||
| 65 | + | ||
| 66 | +### Edge Cases | ||
| 67 | + | ||
| 68 | +- Que se passe-t-il si un fichier ne peut pas être vérifié par somme de contrôle pendant la copie depuis la carte (lecture corrompue) ? La copie de ce fichier DOIT être signalée en échec et la carte ne DOIT PAS être considérée comme sûre à effacer tant que le fichier n'est pas correctement recopié et vérifié. | ||
| 69 | +- Que se passe-t-il si la carte mémoire a une vitesse d'accès en lecture particulièrement faible ? La vérification d'intégrité ne DOIT jamais nécessiter une seconde lecture de la carte pour un même fichier : la comparaison se fait entre la somme de contrôle calculée pendant l'unique lecture de la carte et celle recalculée en relisant la copie locale sur disque, pour ne pas doubler le temps d'import sur une carte lente. | ||
| 70 | +- Comment le système gère-t-il une carte contenant des dates de prise de vue aberrantes (horloge de boîtier réinitialisée, ex. dates en 1980 ou 2002) ? Ces fichiers DOIVENT être exclus du calcul de la plage de dates et signalés à l'utilisateur comme anomalie, plutôt que de fausser silencieusement le découpage en groupes. | ||
| 71 | +- Comment le système gère-t-il une carte contenant à la fois des fichiers déjà importés lors d'une session précédente (non effacés de la carte) et des fichiers réellement nouveaux ? Seuls les fichiers réellement nouveaux (identifiés par somme de contrôle, absents des imports précédents) DOIVENT entrer dans l'analyse et le découpage en groupes. | ||
| 72 | +- Que se passe-t-il si le nom de dossier calculé entre en collision avec un dossier existant (local ou archivé) ? Le système DOIT proposer un suffixe ou demander une confirmation explicite, jamais écraser silencieusement le dossier existant. | ||
| 73 | +- Que se passe-t-il si l'espace disque local est insuffisant pour accueillir la copie de travail avant même de commencer la copie ? Le système DOIT vérifier l'espace disponible avant de démarrer la copie et interrompre l'import avec un message clair plutôt que d'échouer en cours de copie. | ||
| 74 | +- Comment le système traite-t-il un fichier présent sur la carte qui n'est ni une photo ni un fichier associé reconnu (ex. vidéo, fichier système du boîtier) ? Ce fichier est hors périmètre de l'import et n'est ni copié ni pris en compte dans l'analyse (cf. Assumptions). | ||
| 75 | + | ||
| 76 | +## Requirements *(mandatory)* | ||
| 77 | + | ||
| 78 | +### Functional Requirements | ||
| 79 | + | ||
| 80 | +- **FR-001**: Le système DOIT copier l'intégralité des fichiers nouveaux d'une carte mémoire vers un espace de travail local en une seule lecture de la carte par fichier, en calculant la somme de contrôle de la source au fil de cette copie. Il DOIT ensuite vérifier l'intégrité de la copie en relisant le fichier déjà écrit sur le disque local — jamais en relisant une seconde fois la carte mémoire — et comparer les deux sommes de contrôle avant de considérer la carte comme sûre à effacer. | ||
| 81 | +- **FR-002**: Le système DOIT lire la date de prise de vue (métadonnée EXIF d'origine, jamais la date de fichier) de chaque fichier nouvellement importé, et construire une répartition jour par jour (nombre de photos, plage horaire) du lot importé. | ||
| 82 | +- **FR-003**: Le système DOIT exclure du calcul de plage les fichiers dont la date de prise de vue est aberrante et signaler cette anomalie à l'utilisateur, plutôt que d'inclure silencieusement ces dates dans la plage détectée. | ||
| 83 | +- **FR-004**: Le système DOIT ne prendre en compte, pour l'analyse et le découpage en groupes, que les fichiers réellement nouveaux pour l'import en cours (identifiés par somme de contrôle), à l'exclusion de tout fichier déjà importé lors d'une session précédente et resté sur la carte. | ||
| 84 | +- **FR-005**: Le système DOIT proposer par défaut un seul groupe couvrant toute la plage de dates contiguë détectée, et permettre à l'utilisateur de détacher un ou plusieurs jours de cette plage pour former des groupes distincts. | ||
| 85 | +- **FR-006**: Le système PEUT mettre en avant un ou plusieurs jours comme candidats plausibles au détachement (ex. pic de prises de vue isolé), mais ne DOIT jamais détacher un groupe automatiquement sans validation de l'utilisateur. | ||
| 86 | +- **FR-007**: Pour chaque groupe résultant du découpage, le système DOIT demander explicitement à l'utilisateur sa destination, parmi : nouveau dossier simple, nouveau sous-dossier d'un dossier parent existant, fusion dans un dossier existant, ou nouveau dossier parent avec sa première étape — sans jamais retenir un état "voyage en cours" d'un import à l'autre. | ||
| 87 | +- **FR-008**: Pour aider l'utilisateur à choisir une destination de sous-dossier ou de fusion, le système DOIT lister les dossiers candidats existants à la fois dans l'espace de travail local et dans l'archive (recherche par titre ou date proche). | ||
| 88 | +- **FR-009**: Lorsqu'une fusion cible un dossier déjà présent dans l'archive (et pas seulement en local), le système DOIT d'abord effectuer une vérification (checkout) de ce dossier avant d'y intégrer les nouveaux fichiers. | ||
| 89 | +- **FR-010**: Le système DOIT demander un titre pour chaque groupe, le nettoyer pour en faire un nom de dossier valide (espaces convertis, caractères interdits refusés), puis le combiner avec la plage de dates selon la granularité appropriée (jour unique, plage dans le même mois, plage à cheval sur deux mois/années, ou granularité mois pour un dossier parent de voyage). | ||
| 90 | +- **FR-011**: Le système PEUT suggérer automatiquement un lieu à partir de coordonnées GPS présentes dans les métadonnées EXIF, mais cette suggestion reste modifiable et ne DOIT jamais être imposée à l'utilisateur. | ||
| 91 | +- **FR-012**: Le système DOIT vérifier, avant de créer un dossier final, qu'aucun dossier de nom identique n'existe déjà ; en cas de collision, il DOIT proposer un suffixe ou demander une confirmation explicite plutôt que d'écraser. | ||
| 92 | +- **FR-013**: Le système DOIT renommer chaque fichier maître importé selon la convention `date_titre_nomOrigine.ext`, en conservant le nom d'origine attribué par le boîtier en suffixe, une fois le titre du groupe choisi et juste avant l'archivage. | ||
| 93 | +- **FR-014**: Le système DOIT renommer de façon synchronisée tout fichier partageant le même nom de base qu'un fichier maître renommé (JPEG jumeau en mode RAW+JPEG, sidecar de réglages), pour préserver leur appariement. | ||
| 94 | +- **FR-015**: Le système DOIT désambiguïser par défaut deux fichiers de même nom d'origine provenant de boîtiers différents à partir du tag EXIF de modèle de chaque fichier, sans exiger qu'un profil de boîtiers ait été préalablement déclaré ; il ne DOIT solliciter l'utilisateur (profil, numéro de série, étiquetage manuel) qu'au moment où une collision réelle est détectée par somme de contrôle et où ce tag ne suffit pas à distinguer les sources (cf. `specs/002-profil-boitiers-optionnel`, qui définit ce mécanisme de désambiguïsation en détail). | ||
| 95 | +- **FR-016**: La détection d'un modèle de boîtier jamais rencontré auparavant dans les métadonnées d'un fichier ne DOIT, en l'absence de toute collision réelle, ni interrompre l'import ni exiger une action sur le profil de boîtiers. | ||
| 96 | +- **FR-017**: Le système DOIT attribuer un identifiant pérenne, indépendant du nom de fichier, à chaque photo importée, et l'inscrire dans les métadonnées embarquées du fichier. | ||
| 97 | +- **FR-018**: Avant d'écrire quoi que ce soit sur l'archive (création de dossier, archivage des fichiers renommés, fusion dans un dossier existant), le système DOIT présenter à l'utilisateur un résumé de l'opération (nombre de fichiers concernés, dossier de destination) et attendre une confirmation explicite. | ||
| 98 | +- **FR-019**: Le système DOIT effectuer le transfert final vers l'archive à partir de la copie de travail locale déjà vérifiée et renommée, plutôt que par une copie directe de la carte mémoire vers l'archive. | ||
| 99 | + | ||
| 100 | +### Key Entities | ||
| 101 | + | ||
| 102 | +- **Carte mémoire** : support source d'un import, contenant des fichiers déjà importés lors de sessions précédentes et des fichiers réellement nouveaux à traiter. | ||
| 103 | +- **Copie de travail locale** : copie temporaire et vérifiée par somme de contrôle des fichiers nouveaux d'une carte, base de toute l'analyse et du renommage avant archivage. | ||
| 104 | +- **Groupe d'import** : sous-ensemble de fichiers nouvellement importés partageant une plage de dates contiguë, destiné à devenir un dossier ou un sous-dossier de l'archive. | ||
| 105 | +- **Dossier** : unité d'archive résultant d'un groupe simple, avec sa structure par format et sa racine de sélection. | ||
| 106 | +- **Dossier parent / sous-dossier** : structure à deux niveaux résultant d'un import s'intégrant à un voyage en plusieurs étapes. | ||
| 107 | +- **Profil de boîtiers** : liste optionnelle d'appareils, alimentée à la demande (cf. `specs/002-profil-boitiers-optionnel`), utilisée pour désambiguïser la source d'un fichier lorsqu'une collision réelle de nom d'origine survient et que le tag de modèle seul ne suffit pas à la résoudre. | ||
| 108 | +- **Fichier maître** : photo issue directement du boîtier (RAW ou JPEG selon les cas), renommée à l'import et jamais modifiée une fois archivée. | ||
| 109 | +- **Fichier associé** : fichier partageant le nom de base d'un fichier maître (JPEG jumeau, sidecar de réglages), renommé de façon synchronisée avec lui. | ||
| 110 | +- **Identifiant pérenne** : identifiant attribué à chaque photo importée, indépendant de son nom de fichier, inscrit dans ses métadonnées. | ||
| 111 | + | ||
| 112 | +## Success Criteria *(mandatory)* | ||
| 113 | + | ||
| 114 | +### Measurable Outcomes | ||
| 115 | + | ||
| 116 | +- **SC-001**: 100% des fichiers copiés depuis une carte mémoire sont vérifiés par somme de contrôle avant que la carte ne soit signalée comme sûre à effacer, sans qu'aucun fichier ne nécessite plus d'une lecture complète de la carte, quelle que soit sa vitesse d'accès. | ||
| 117 | +- **SC-002**: Pour un import à une seule journée sur un seul boîtier, l'utilisateur obtient un dossier archivé, correctement nommé et vérifié, en validant au plus deux décisions (titre, confirmation d'archivage). | ||
| 118 | +- **SC-003**: 100% des dates de prise de vue aberrantes détectées sur une carte sont signalées à l'utilisateur plutôt qu'intégrées silencieusement au découpage en groupes. | ||
| 119 | +- **SC-004**: 100% des collisions de nom de dossier sont présentées à l'utilisateur avec un choix explicite ; aucune collision ne provoque d'écrasement silencieux. | ||
| 120 | +- **SC-005**: 100% des paires de fichiers associés (fichier maître + JPEG jumeau ou sidecar) conservent leur appariement (même nom de base) après renommage à l'import. | ||
| 121 | +- **SC-006**: Aucune écriture sur l'archive (création de dossier, ajout de fichiers) ne survient sans qu'un résumé de l'opération n'ait été présenté et explicitement confirmé par l'utilisateur. | ||
| 122 | +- **SC-007**: Un utilisateur qui importe une carte couvrant un voyage en plusieurs étapes peut obtenir une structure à deux niveaux correctement rattachée sans avoir à renommer ou déplacer manuellement de dossier après l'import. | ||
| 123 | + | ||
| 124 | +## Assumptions | ||
| 125 | + | ||
| 126 | +- Le module d'importation couvre le trajet complet depuis la carte mémoire jusqu'au premier archivage des fichiers renommés ; il ne couvre pas le tri ultérieur (sélection, promotion à la racine) ni la suppression de déchets évidents, qui relèvent du flux de réconciliation lors d'une édition (hors périmètre de ce module). | ||
| 127 | +- Les fichiers présents sur la carte mémoire qui ne sont ni des photos (RAW, JPEG, TIFF) ni des fichiers associés reconnus (sidecars) sont hors périmètre de l'import : ils ne sont ni copiés ni pris en compte dans l'analyse. | ||
| 128 | +- Le profil de boîtiers est une capacité optionnelle, alimentée à la demande et non un prérequis avant le premier import (cf. `specs/002-profil-boitiers-optionnel`, qui révise et détaille ce comportement) : ce module se désambiguïse par défaut via le tag EXIF de modèle, et ne sollicite le profil, un numéro de série, ou un étiquetage manuel qu'en cas de collision réelle non résolue par ce tag seul. | ||
| 129 | +- Le mécanisme de checkout/réconciliation d'un dossier déjà archivé (utilisé au cas de fusion vers un dossier existant sur l'archive) est une capacité déjà disponible ou livrée avant ou avec ce module ; ce module ne redéfinit pas ce mécanisme, il s'appuie dessus. | ||
| 130 | +- La suggestion automatique de lieu par coordonnées GPS dépend de la présence de ces coordonnées dans les métadonnées du fichier ; en leur absence, l'utilisateur saisit le lieu librement, sans que cela bloque l'import. | ||
| 131 | +- Une seule carte mémoire est traitée à la fois par import ; l'import simultané de plusieurs cartes n'est pas couvert par ce module. | ||
added
specs/002-profil-boitiers-optionnel/checklists/requirements.md +39 -0 | new file mode 100644 | ||
| @@ -0,0 +1,39 @@ | ||
| 1 | +# Specification Quality Checklist: Profil de boîtiers optionnel, déclaré à la demande | |
| 2 | + | |
| 3 | +**Purpose**: Validate specification completeness and quality before proceeding to planning | |
| 4 | +**Created**: 2026-09-18 | |
| 5 | +**Feature**: [spec.md](../spec.md) | |
| 6 | + | |
| 7 | +## Content Quality | |
| 8 | + | |
| 9 | +- [x] No implementation details (languages, frameworks, APIs) | |
| 10 | +- [x] Focused on user value and business needs | |
| 11 | +- [x] Written for non-technical stakeholders | |
| 12 | +- [x] All mandatory sections completed | |
| 13 | + | |
| 14 | +## Requirement Completeness | |
| 15 | + | |
| 16 | +- [x] No [NEEDS CLARIFICATION] markers remain | |
| 17 | +- [x] Requirements are testable and unambiguous | |
| 18 | +- [x] Success criteria are measurable | |
| 19 | +- [x] Success criteria are technology-agnostic (no implementation details) | |
| 20 | +- [x] All acceptance scenarios are defined | |
| 21 | +- [x] Edge cases are identified | |
| 22 | +- [x] Scope is clearly bounded | |
| 23 | +- [x] Dependencies and assumptions identified | |
| 24 | + | |
| 25 | +## Feature Readiness | |
| 26 | + | |
| 27 | +- [x] All functional requirements have clear acceptance criteria | |
| 28 | +- [x] User scenarios cover primary flows | |
| 29 | +- [x] Feature meets measurable outcomes defined in Success Criteria | |
| 30 | +- [x] No implementation details leak into specification | |
| 31 | + | |
| 32 | +## Notes | |
| 33 | + | |
| 34 | +- Cette fonctionnalité révise le comportement du profil de boîtiers précédemment décrit dans | |
| 35 | + `specs/001-import-photos/spec.md` (FR-015, FR-016 et l'hypothèse de profil pré-requis) : il | |
| 36 | + devient une capacité optionnelle, alimentée à la demande plutôt qu'en configuration obligatoire. | |
| 37 | + Un alignement de la spécification 001 sur ce comportement révisé reste à faire (via | |
| 38 | + `/speckit-clarify` sur 001, ou une mise à jour manuelle) avant la planification du module | |
| 39 | + d'import. | |
| new file mode 100644 | |||
| @@ -0,0 +1,39 @@ | |||
| 1 | +# Specification Quality Checklist: Profil de boîtiers optionnel, déclaré à la demande | ||
| 2 | + | ||
| 3 | +**Purpose**: Validate specification completeness and quality before proceeding to planning | ||
| 4 | +**Created**: 2026-09-18 | ||
| 5 | +**Feature**: [spec.md](../spec.md) | ||
| 6 | + | ||
| 7 | +## Content Quality | ||
| 8 | + | ||
| 9 | +- [x] No implementation details (languages, frameworks, APIs) | ||
| 10 | +- [x] Focused on user value and business needs | ||
| 11 | +- [x] Written for non-technical stakeholders | ||
| 12 | +- [x] All mandatory sections completed | ||
| 13 | + | ||
| 14 | +## Requirement Completeness | ||
| 15 | + | ||
| 16 | +- [x] No [NEEDS CLARIFICATION] markers remain | ||
| 17 | +- [x] Requirements are testable and unambiguous | ||
| 18 | +- [x] Success criteria are measurable | ||
| 19 | +- [x] Success criteria are technology-agnostic (no implementation details) | ||
| 20 | +- [x] All acceptance scenarios are defined | ||
| 21 | +- [x] Edge cases are identified | ||
| 22 | +- [x] Scope is clearly bounded | ||
| 23 | +- [x] Dependencies and assumptions identified | ||
| 24 | + | ||
| 25 | +## Feature Readiness | ||
| 26 | + | ||
| 27 | +- [x] All functional requirements have clear acceptance criteria | ||
| 28 | +- [x] User scenarios cover primary flows | ||
| 29 | +- [x] Feature meets measurable outcomes defined in Success Criteria | ||
| 30 | +- [x] No implementation details leak into specification | ||
| 31 | + | ||
| 32 | +## Notes | ||
| 33 | + | ||
| 34 | +- Cette fonctionnalité révise le comportement du profil de boîtiers précédemment décrit dans | ||
| 35 | + `specs/001-import-photos/spec.md` (FR-015, FR-016 et l'hypothèse de profil pré-requis) : il | ||
| 36 | + devient une capacité optionnelle, alimentée à la demande plutôt qu'en configuration obligatoire. | ||
| 37 | + Un alignement de la spécification 001 sur ce comportement révisé reste à faire (via | ||
| 38 | + `/speckit-clarify` sur 001, ou une mise à jour manuelle) avant la planification du module | ||
| 39 | + d'import. | ||
added
specs/002-profil-boitiers-optionnel/spec.md +103 -0 | new file mode 100644 | ||
| @@ -0,0 +1,103 @@ | ||
| 1 | +# Feature Specification: Profil de boîtiers optionnel, déclaré à la demande | |
| 2 | + | |
| 3 | +**Feature Branch**: `[002-profil-boitiers-optionnel]` | |
| 4 | + | |
| 5 | +**Created**: 2026-09-18 | |
| 6 | + | |
| 7 | +**Status**: Draft | |
| 8 | + | |
| 9 | +**Input**: User description: "Par defaut on a pas besoin d'avoir sepcifié le les models de boitiers qu'il possède. Ceci est necessaire pour les photogrpahes avancés qui ont plusieurs fois le même modèle ou bien si il y a confusion entre les boitier dont il n'y a pas d'identifiant unique des boitiers de la même marque" | |
| 10 | + | |
| 11 | +## User Scenarios & Testing *(mandatory)* | |
| 12 | + | |
| 13 | +### User Story 1 - Premier import sans configuration préalable (Priority: P1) | |
| 14 | + | |
| 15 | +Un photographe installe Régine et importe sa première carte mémoire sans avoir rien déclaré au sujet de son matériel. Il possède un seul boîtier, ou plusieurs boîtiers de marques/modèles différents. L'import se déroule normalement, sans qu'aucune question sur le profil de boîtiers ne lui soit posée. | |
| 16 | + | |
| 17 | +**Why this priority**: C'est le cas le plus fréquent (un ou plusieurs boîtiers facilement distingués par leur modèle) et la friction à éliminer en priorité : obliger tout le monde à déclarer son matériel avant le premier import pénaliserait la majorité des utilisateurs pour un besoin qui ne concerne qu'une minorité de cas avancés. | |
| 18 | + | |
| 19 | +**Independent Test**: Peut être testé en installant Régine sans déclarer aucun boîtier, puis en important une carte mémoire d'un seul appareil (ou de plusieurs appareils de modèles différents, sans collision de nom de fichier) : l'import doit aboutir sans qu'aucune étape de configuration de profil ne soit demandée. | |
| 20 | + | |
| 21 | +**Acceptance Scenarios**: | |
| 22 | + | |
| 23 | +1. **Given** aucun profil de boîtiers déclaré, **When** l'utilisateur importe une carte provenant d'un seul boîtier, **Then** l'import se déroule normalement sans qu'aucune question relative aux boîtiers ne soit posée. | |
| 24 | +2. **Given** aucun profil de boîtiers déclaré, **When** l'utilisateur importe des fichiers provenant de deux boîtiers de modèles différents sans collision de nom de fichier, **Then** l'import se déroule normalement, chaque fichier étant associé à son modèle lu directement dans ses métadonnées. | |
| 25 | + | |
| 26 | +--- | |
| 27 | + | |
| 28 | +### User Story 2 - Résolution ponctuelle d'une collision réelle entre boîtiers (Priority: P2) | |
| 29 | + | |
| 30 | +Un photographe importe deux cartes mémoire (deux boîtiers, ou un boîtier et une carte de secours) dont certains fichiers portent le même nom d'origine. Le système détecte cette collision et ne demande de précision à l'utilisateur qu'à ce moment précis, pas avant. | |
| 31 | + | |
| 32 | +**Why this priority**: C'est la valeur centrale de la fonctionnalité : la désambiguïsation ne doit intervenir qu'au moment où elle est réellement nécessaire, jamais en amont sous forme de configuration obligatoire. | |
| 33 | + | |
| 34 | +**Independent Test**: Peut être testé en import et deux jeux de fichiers partageant un même nom d'origine mais un contenu différent (somme de contrôle différente), et en vérifiant qu'une question de désambiguïsation n'apparaît qu'à cet instant, jamais avant l'import ni pour des fichiers sans collision. | |
| 35 | + | |
| 36 | +**Acceptance Scenarios**: | |
| 37 | + | |
| 38 | +1. **Given** deux fichiers de même nom d'origine mais de contenu différent (somme de contrôle différente), **When** leurs métadonnées EXIF indiquent des modèles de boîtier différents, **Then** le système les distingue automatiquement par ce tag, sans poser de question à l'utilisateur. | |
| 39 | +2. **Given** deux fichiers en collision de nom, **When** leurs métadonnées EXIF indiquent le même modèle de boîtier ou n'indiquent aucun modèle, **Then** le système signale la collision à l'utilisateur et demande une résolution, uniquement à cet instant. | |
| 40 | +3. **Given** une source de boîtier résolue une première fois (par modèle, numéro de série ou étiquette manuelle), **When** l'utilisateur importe ultérieurement d'autres fichiers du même boîtier, **Then** le système réutilise cette résolution sans reposer la question. | |
| 41 | + | |
| 42 | +--- | |
| 43 | + | |
| 44 | +### User Story 3 - Repli sur numéro de série pour deux boîtiers identiques (Priority: P3) | |
| 45 | + | |
| 46 | +Un photographe avancé possède deux exemplaires du même modèle de boîtier (même marque, même modèle) utilisés en parallèle. Le tag de modèle seul ne suffit plus à les distinguer en cas de collision ; le système doit s'appuyer sur un identifiant plus précis, ou, à défaut, demander un étiquetage manuel. | |
| 47 | + | |
| 48 | +**Why this priority**: C'est le cas avancé explicitement à l'origine de cette demande — moins fréquent que les deux histoires précédentes, mais celui qui justifie l'existence même d'un mécanisme de résolution au-delà du simple tag de modèle. | |
| 49 | + | |
| 50 | +**Independent Test**: Peut être testé en simulant une collision entre deux fichiers partageant le même modèle de boîtier dans leurs métadonnées mais un numéro de série différent et exploitable : le système doit les distinguer automatiquement. Un second test, avec numéro de série absent ou inexploitable pour les deux fichiers, doit à la place déclencher une demande d'étiquetage manuel. | |
| 51 | + | |
| 52 | +**Acceptance Scenarios**: | |
| 53 | + | |
| 54 | +1. **Given** une collision entre deux fichiers de même modèle de boîtier, **When** leurs métadonnées EXIF contiennent chacune un numéro de série de boîtier présent et exploitable, **Then** le système les distingue automatiquement à partir de ce numéro, sans intervention de l'utilisateur. | |
| 55 | +2. **Given** une collision entre deux fichiers de même modèle de boîtier, **When** le numéro de série est absent, vide ou non exploitable pour l'un des deux fichiers ou les deux, **Then** le système demande à l'utilisateur d'étiqueter manuellement la source de chaque fichier concerné. | |
| 56 | +3. **Given** un étiquetage manuel effectué pour résoudre une collision, **When** l'utilisateur revient consulter ou modifier son profil de boîtiers, **Then** il retrouve cette entrée et peut la modifier librement (ex. après la revente d'un des deux boîtiers). | |
| 57 | + | |
| 58 | +--- | |
| 59 | + | |
| 60 | +### Edge Cases | |
| 61 | + | |
| 62 | +- Que se passe-t-il si un modèle de boîtier jamais rencontré auparavant apparaît dans les métadonnées d'un import, sans qu'aucune collision de nom ne survienne ? Le système ne DOIT poser aucune question et ne DOIT PAS interrompre l'import : l'absence de collision signifie l'absence de besoin de désambiguïsation. | |
| 63 | +- Que se passe-t-il si les métadonnées EXIF d'un fichier ne contiennent aucun tag de modèle (métadonnées effacées ou boîtier atypique) ? Ce fichier est traité comme non désambiguïsable par le modèle ; en cas de collision réelle, le système passe directement au repli sur numéro de série puis, à défaut, à l'étiquetage manuel. | |
| 64 | +- Que se passe-t-il si plus de deux fichiers entrent en collision sous le même nom d'origine (rare, trois boîtiers ou plus) ? Le même mécanisme de résolution (modèle, puis numéro de série, puis étiquetage manuel) s'applique à chaque source impliquée dans la collision, pas seulement à une paire. | |
| 65 | +- Que se passe-t-il si l'utilisateur modifie son profil de boîtiers (achat, revente, prêt) entre deux imports ? Les résolutions déjà établies pour les boîtiers toujours déclarés restent valables ; un boîtier retiré du profil redevient sujet à une nouvelle résolution s'il réapparaît dans une collision future. | |
| 66 | + | |
| 67 | +## Requirements *(mandatory)* | |
| 68 | + | |
| 69 | +### Functional Requirements | |
| 70 | + | |
| 71 | +- **FR-001**: Le système DOIT permettre de réaliser un import complet sans qu'aucun profil de boîtiers n'ait été déclaré au préalable. | |
| 72 | +- **FR-002**: Le système DOIT désambiguïser par défaut deux fichiers de même nom d'origine à partir du tag EXIF de modèle de chaque fichier, sans exiger que ce modèle soit préalablement enregistré dans un profil déclaré. | |
| 73 | +- **FR-003**: Le système DOIT ne demander une résolution à l'utilisateur qu'au moment où une collision réelle de nom de fichier est détectée entre des fichiers dont le tag de modèle est identique ou absent — jamais par anticipation avant qu'une collision ne survienne. | |
| 74 | +- **FR-004**: Lorsqu'une collision oppose deux fichiers indiquant le même modèle de boîtier, le système DOIT tenter de les distinguer automatiquement à partir du numéro de série de boîtier lu dans les métadonnées, quand celui-ci est présent et exploitable (non vide, non valeur générique), sans intervention de l'utilisateur. | |
| 75 | +- **FR-005**: Lorsque le numéro de série est absent, vide ou inexploitable pour une collision réelle, le système DOIT demander à l'utilisateur d'étiqueter manuellement la source de chaque fichier concerné. | |
| 76 | +- **FR-006**: Une fois une source de boîtier résolue (par modèle, numéro de série ou étiquetage manuel), le système DOIT réutiliser automatiquement cette résolution pour les imports ultérieurs du même boîtier, sans reposer la question. | |
| 77 | +- **FR-007**: L'utilisateur DOIT pouvoir consulter, ajouter ou modifier les boîtiers déclarés à tout moment, indépendamment de tout import en cours — cette action reste disponible bien qu'elle ne soit jamais une étape obligatoire avant un import. | |
| 78 | +- **FR-008**: La détection d'un modèle de boîtier jamais rencontré auparavant dans les métadonnées d'un fichier ne DOIT, en l'absence de toute collision réelle, ni interrompre l'import ni exiger une action sur le profil. | |
| 79 | + | |
| 80 | +### Key Entities | |
| 81 | + | |
| 82 | +- **Profil de boîtiers (optionnel)** : liste facultative d'appareils associés à des identifiants de résolution (modèle, numéro de série, ou étiquette manuelle), alimentée à la demande plutôt qu'en prérequis d'installation. | |
| 83 | +- **Collision de nom d'origine** : événement déclencheur, détecté lorsque deux fichiers partagent un même nom de fichier d'origine mais un contenu différent (somme de contrôle différente). | |
| 84 | +- **Tag de modèle (métadonnées)** : source primaire et silencieuse de désambiguïsation entre boîtiers de modèles différents. | |
| 85 | +- **Numéro de série de boîtier (métadonnées)** : source de repli pour distinguer deux boîtiers strictement identiques (même marque, même modèle). | |
| 86 | +- **Étiquette manuelle de source** : dernier recours attribué par l'utilisateur quand aucune métadonnée ne permet de distinguer deux boîtiers en collision. | |
| 87 | + | |
| 88 | +## Success Criteria *(mandatory)* | |
| 89 | + | |
| 90 | +### Measurable Outcomes | |
| 91 | + | |
| 92 | +- **SC-001**: 100% des imports sans collision de nom de fichier se terminent sans qu'aucune question relative aux boîtiers ne soit posée à l'utilisateur. | |
| 93 | +- **SC-002**: Un photographe découvrant Régine peut réaliser son premier import sans jamais avoir eu à ouvrir ou configurer un profil de boîtiers. | |
| 94 | +- **SC-003**: 100% des collisions réelles de nom de fichier sont résolues automatiquement (par modèle ou numéro de série) dès que cette information est présente et exploitable dans les métadonnées, sans intervention de l'utilisateur. | |
| 95 | +- **SC-004**: 100% des collisions non résolvables automatiquement déclenchent une demande d'étiquetage manuel plutôt qu'un classement erroné silencieux. | |
| 96 | +- **SC-005**: Une fois une source désambiguïsée pour un boîtier donné, aucune nouvelle question n'est posée pour ce même boîtier lors des imports ultérieurs. | |
| 97 | + | |
| 98 | +## Assumptions | |
| 99 | + | |
| 100 | +- Cette spécification révise le comportement décrit dans `specs/001-import-photos/spec.md` (exigences FR-015 et FR-016, ainsi que l'hypothèse selon laquelle le profil de boîtiers est un prérequis existant avant le premier import) : le profil devient une capacité optionnelle alimentée à la demande, et la détection d'un modèle inconnu sans collision ne déclenche plus de signalement systématique. Un alignement de la spécification 001 sur ce comportement révisé est nécessaire avant ou pendant la planification de l'import. | |
| 101 | +- Le mécanisme de détection de collision par somme de contrôle et le tag EXIF de numéro de série de boîtier restent ceux déjà décrits dans les notes de conception du projet ; seule la condition de déclenchement de la question posée à l'utilisateur change. | |
| 102 | +- Un boîtier qui ne rencontre jamais de collision réelle ne nécessite jamais d'entrée dans le profil : celui-ci peut rester vide indéfiniment pour un utilisateur qui n'a pas besoin de désambiguïsation. | |
| 103 | +- Cette fonctionnalité s'applique dans le contexte du module d'import (`specs/001-import-photos`) ; elle n'introduit pas de nouveau canal d'import ni de nouvelle destination de dossier. | |
| new file mode 100644 | |||
| @@ -0,0 +1,103 @@ | |||
| 1 | +# Feature Specification: Profil de boîtiers optionnel, déclaré à la demande | ||
| 2 | + | ||
| 3 | +**Feature Branch**: `[002-profil-boitiers-optionnel]` | ||
| 4 | + | ||
| 5 | +**Created**: 2026-09-18 | ||
| 6 | + | ||
| 7 | +**Status**: Draft | ||
| 8 | + | ||
| 9 | +**Input**: User description: "Par defaut on a pas besoin d'avoir sepcifié le les models de boitiers qu'il possède. Ceci est necessaire pour les photogrpahes avancés qui ont plusieurs fois le même modèle ou bien si il y a confusion entre les boitier dont il n'y a pas d'identifiant unique des boitiers de la même marque" | ||
| 10 | + | ||
| 11 | +## User Scenarios & Testing *(mandatory)* | ||
| 12 | + | ||
| 13 | +### User Story 1 - Premier import sans configuration préalable (Priority: P1) | ||
| 14 | + | ||
| 15 | +Un photographe installe Régine et importe sa première carte mémoire sans avoir rien déclaré au sujet de son matériel. Il possède un seul boîtier, ou plusieurs boîtiers de marques/modèles différents. L'import se déroule normalement, sans qu'aucune question sur le profil de boîtiers ne lui soit posée. | ||
| 16 | + | ||
| 17 | +**Why this priority**: C'est le cas le plus fréquent (un ou plusieurs boîtiers facilement distingués par leur modèle) et la friction à éliminer en priorité : obliger tout le monde à déclarer son matériel avant le premier import pénaliserait la majorité des utilisateurs pour un besoin qui ne concerne qu'une minorité de cas avancés. | ||
| 18 | + | ||
| 19 | +**Independent Test**: Peut être testé en installant Régine sans déclarer aucun boîtier, puis en important une carte mémoire d'un seul appareil (ou de plusieurs appareils de modèles différents, sans collision de nom de fichier) : l'import doit aboutir sans qu'aucune étape de configuration de profil ne soit demandée. | ||
| 20 | + | ||
| 21 | +**Acceptance Scenarios**: | ||
| 22 | + | ||
| 23 | +1. **Given** aucun profil de boîtiers déclaré, **When** l'utilisateur importe une carte provenant d'un seul boîtier, **Then** l'import se déroule normalement sans qu'aucune question relative aux boîtiers ne soit posée. | ||
| 24 | +2. **Given** aucun profil de boîtiers déclaré, **When** l'utilisateur importe des fichiers provenant de deux boîtiers de modèles différents sans collision de nom de fichier, **Then** l'import se déroule normalement, chaque fichier étant associé à son modèle lu directement dans ses métadonnées. | ||
| 25 | + | ||
| 26 | +--- | ||
| 27 | + | ||
| 28 | +### User Story 2 - Résolution ponctuelle d'une collision réelle entre boîtiers (Priority: P2) | ||
| 29 | + | ||
| 30 | +Un photographe importe deux cartes mémoire (deux boîtiers, ou un boîtier et une carte de secours) dont certains fichiers portent le même nom d'origine. Le système détecte cette collision et ne demande de précision à l'utilisateur qu'à ce moment précis, pas avant. | ||
| 31 | + | ||
| 32 | +**Why this priority**: C'est la valeur centrale de la fonctionnalité : la désambiguïsation ne doit intervenir qu'au moment où elle est réellement nécessaire, jamais en amont sous forme de configuration obligatoire. | ||
| 33 | + | ||
| 34 | +**Independent Test**: Peut être testé en import et deux jeux de fichiers partageant un même nom d'origine mais un contenu différent (somme de contrôle différente), et en vérifiant qu'une question de désambiguïsation n'apparaît qu'à cet instant, jamais avant l'import ni pour des fichiers sans collision. | ||
| 35 | + | ||
| 36 | +**Acceptance Scenarios**: | ||
| 37 | + | ||
| 38 | +1. **Given** deux fichiers de même nom d'origine mais de contenu différent (somme de contrôle différente), **When** leurs métadonnées EXIF indiquent des modèles de boîtier différents, **Then** le système les distingue automatiquement par ce tag, sans poser de question à l'utilisateur. | ||
| 39 | +2. **Given** deux fichiers en collision de nom, **When** leurs métadonnées EXIF indiquent le même modèle de boîtier ou n'indiquent aucun modèle, **Then** le système signale la collision à l'utilisateur et demande une résolution, uniquement à cet instant. | ||
| 40 | +3. **Given** une source de boîtier résolue une première fois (par modèle, numéro de série ou étiquette manuelle), **When** l'utilisateur importe ultérieurement d'autres fichiers du même boîtier, **Then** le système réutilise cette résolution sans reposer la question. | ||
| 41 | + | ||
| 42 | +--- | ||
| 43 | + | ||
| 44 | +### User Story 3 - Repli sur numéro de série pour deux boîtiers identiques (Priority: P3) | ||
| 45 | + | ||
| 46 | +Un photographe avancé possède deux exemplaires du même modèle de boîtier (même marque, même modèle) utilisés en parallèle. Le tag de modèle seul ne suffit plus à les distinguer en cas de collision ; le système doit s'appuyer sur un identifiant plus précis, ou, à défaut, demander un étiquetage manuel. | ||
| 47 | + | ||
| 48 | +**Why this priority**: C'est le cas avancé explicitement à l'origine de cette demande — moins fréquent que les deux histoires précédentes, mais celui qui justifie l'existence même d'un mécanisme de résolution au-delà du simple tag de modèle. | ||
| 49 | + | ||
| 50 | +**Independent Test**: Peut être testé en simulant une collision entre deux fichiers partageant le même modèle de boîtier dans leurs métadonnées mais un numéro de série différent et exploitable : le système doit les distinguer automatiquement. Un second test, avec numéro de série absent ou inexploitable pour les deux fichiers, doit à la place déclencher une demande d'étiquetage manuel. | ||
| 51 | + | ||
| 52 | +**Acceptance Scenarios**: | ||
| 53 | + | ||
| 54 | +1. **Given** une collision entre deux fichiers de même modèle de boîtier, **When** leurs métadonnées EXIF contiennent chacune un numéro de série de boîtier présent et exploitable, **Then** le système les distingue automatiquement à partir de ce numéro, sans intervention de l'utilisateur. | ||
| 55 | +2. **Given** une collision entre deux fichiers de même modèle de boîtier, **When** le numéro de série est absent, vide ou non exploitable pour l'un des deux fichiers ou les deux, **Then** le système demande à l'utilisateur d'étiqueter manuellement la source de chaque fichier concerné. | ||
| 56 | +3. **Given** un étiquetage manuel effectué pour résoudre une collision, **When** l'utilisateur revient consulter ou modifier son profil de boîtiers, **Then** il retrouve cette entrée et peut la modifier librement (ex. après la revente d'un des deux boîtiers). | ||
| 57 | + | ||
| 58 | +--- | ||
| 59 | + | ||
| 60 | +### Edge Cases | ||
| 61 | + | ||
| 62 | +- Que se passe-t-il si un modèle de boîtier jamais rencontré auparavant apparaît dans les métadonnées d'un import, sans qu'aucune collision de nom ne survienne ? Le système ne DOIT poser aucune question et ne DOIT PAS interrompre l'import : l'absence de collision signifie l'absence de besoin de désambiguïsation. | ||
| 63 | +- Que se passe-t-il si les métadonnées EXIF d'un fichier ne contiennent aucun tag de modèle (métadonnées effacées ou boîtier atypique) ? Ce fichier est traité comme non désambiguïsable par le modèle ; en cas de collision réelle, le système passe directement au repli sur numéro de série puis, à défaut, à l'étiquetage manuel. | ||
| 64 | +- Que se passe-t-il si plus de deux fichiers entrent en collision sous le même nom d'origine (rare, trois boîtiers ou plus) ? Le même mécanisme de résolution (modèle, puis numéro de série, puis étiquetage manuel) s'applique à chaque source impliquée dans la collision, pas seulement à une paire. | ||
| 65 | +- Que se passe-t-il si l'utilisateur modifie son profil de boîtiers (achat, revente, prêt) entre deux imports ? Les résolutions déjà établies pour les boîtiers toujours déclarés restent valables ; un boîtier retiré du profil redevient sujet à une nouvelle résolution s'il réapparaît dans une collision future. | ||
| 66 | + | ||
| 67 | +## Requirements *(mandatory)* | ||
| 68 | + | ||
| 69 | +### Functional Requirements | ||
| 70 | + | ||
| 71 | +- **FR-001**: Le système DOIT permettre de réaliser un import complet sans qu'aucun profil de boîtiers n'ait été déclaré au préalable. | ||
| 72 | +- **FR-002**: Le système DOIT désambiguïser par défaut deux fichiers de même nom d'origine à partir du tag EXIF de modèle de chaque fichier, sans exiger que ce modèle soit préalablement enregistré dans un profil déclaré. | ||
| 73 | +- **FR-003**: Le système DOIT ne demander une résolution à l'utilisateur qu'au moment où une collision réelle de nom de fichier est détectée entre des fichiers dont le tag de modèle est identique ou absent — jamais par anticipation avant qu'une collision ne survienne. | ||
| 74 | +- **FR-004**: Lorsqu'une collision oppose deux fichiers indiquant le même modèle de boîtier, le système DOIT tenter de les distinguer automatiquement à partir du numéro de série de boîtier lu dans les métadonnées, quand celui-ci est présent et exploitable (non vide, non valeur générique), sans intervention de l'utilisateur. | ||
| 75 | +- **FR-005**: Lorsque le numéro de série est absent, vide ou inexploitable pour une collision réelle, le système DOIT demander à l'utilisateur d'étiqueter manuellement la source de chaque fichier concerné. | ||
| 76 | +- **FR-006**: Une fois une source de boîtier résolue (par modèle, numéro de série ou étiquetage manuel), le système DOIT réutiliser automatiquement cette résolution pour les imports ultérieurs du même boîtier, sans reposer la question. | ||
| 77 | +- **FR-007**: L'utilisateur DOIT pouvoir consulter, ajouter ou modifier les boîtiers déclarés à tout moment, indépendamment de tout import en cours — cette action reste disponible bien qu'elle ne soit jamais une étape obligatoire avant un import. | ||
| 78 | +- **FR-008**: La détection d'un modèle de boîtier jamais rencontré auparavant dans les métadonnées d'un fichier ne DOIT, en l'absence de toute collision réelle, ni interrompre l'import ni exiger une action sur le profil. | ||
| 79 | + | ||
| 80 | +### Key Entities | ||
| 81 | + | ||
| 82 | +- **Profil de boîtiers (optionnel)** : liste facultative d'appareils associés à des identifiants de résolution (modèle, numéro de série, ou étiquette manuelle), alimentée à la demande plutôt qu'en prérequis d'installation. | ||
| 83 | +- **Collision de nom d'origine** : événement déclencheur, détecté lorsque deux fichiers partagent un même nom de fichier d'origine mais un contenu différent (somme de contrôle différente). | ||
| 84 | +- **Tag de modèle (métadonnées)** : source primaire et silencieuse de désambiguïsation entre boîtiers de modèles différents. | ||
| 85 | +- **Numéro de série de boîtier (métadonnées)** : source de repli pour distinguer deux boîtiers strictement identiques (même marque, même modèle). | ||
| 86 | +- **Étiquette manuelle de source** : dernier recours attribué par l'utilisateur quand aucune métadonnée ne permet de distinguer deux boîtiers en collision. | ||
| 87 | + | ||
| 88 | +## Success Criteria *(mandatory)* | ||
| 89 | + | ||
| 90 | +### Measurable Outcomes | ||
| 91 | + | ||
| 92 | +- **SC-001**: 100% des imports sans collision de nom de fichier se terminent sans qu'aucune question relative aux boîtiers ne soit posée à l'utilisateur. | ||
| 93 | +- **SC-002**: Un photographe découvrant Régine peut réaliser son premier import sans jamais avoir eu à ouvrir ou configurer un profil de boîtiers. | ||
| 94 | +- **SC-003**: 100% des collisions réelles de nom de fichier sont résolues automatiquement (par modèle ou numéro de série) dès que cette information est présente et exploitable dans les métadonnées, sans intervention de l'utilisateur. | ||
| 95 | +- **SC-004**: 100% des collisions non résolvables automatiquement déclenchent une demande d'étiquetage manuel plutôt qu'un classement erroné silencieux. | ||
| 96 | +- **SC-005**: Une fois une source désambiguïsée pour un boîtier donné, aucune nouvelle question n'est posée pour ce même boîtier lors des imports ultérieurs. | ||
| 97 | + | ||
| 98 | +## Assumptions | ||
| 99 | + | ||
| 100 | +- Cette spécification révise le comportement décrit dans `specs/001-import-photos/spec.md` (exigences FR-015 et FR-016, ainsi que l'hypothèse selon laquelle le profil de boîtiers est un prérequis existant avant le premier import) : le profil devient une capacité optionnelle alimentée à la demande, et la détection d'un modèle inconnu sans collision ne déclenche plus de signalement systématique. Un alignement de la spécification 001 sur ce comportement révisé est nécessaire avant ou pendant la planification de l'import. | ||
| 101 | +- Le mécanisme de détection de collision par somme de contrôle et le tag EXIF de numéro de série de boîtier restent ceux déjà décrits dans les notes de conception du projet ; seule la condition de déclenchement de la question posée à l'utilisateur change. | ||
| 102 | +- Un boîtier qui ne rencontre jamais de collision réelle ne nécessite jamais d'entrée dans le profil : celui-ci peut rester vide indéfiniment pour un utilisateur qui n'a pas besoin de désambiguïsation. | ||
| 103 | +- Cette fonctionnalité s'applique dans le contexte du module d'import (`specs/001-import-photos`) ; elle n'introduit pas de nouveau canal d'import ni de nouvelle destination de dossier. | ||
added
specs/003-config-contexte-travail/checklists/requirements.md +37 -0 | new file mode 100644 | ||
| @@ -0,0 +1,37 @@ | ||
| 1 | +# Specification Quality Checklist: Configuration du contexte de travail de Régine | |
| 2 | + | |
| 3 | +**Purpose**: Validate specification completeness and quality before proceeding to planning | |
| 4 | +**Created**: 2026-09-18 | |
| 5 | +**Feature**: [spec.md](../spec.md) | |
| 6 | + | |
| 7 | +## Content Quality | |
| 8 | + | |
| 9 | +- [x] No implementation details (languages, frameworks, APIs) | |
| 10 | +- [x] Focused on user value and business needs | |
| 11 | +- [x] Written for non-technical stakeholders | |
| 12 | +- [x] All mandatory sections completed | |
| 13 | + | |
| 14 | +## Requirement Completeness | |
| 15 | + | |
| 16 | +- [x] No [NEEDS CLARIFICATION] markers remain | |
| 17 | +- [x] Requirements are testable and unambiguous | |
| 18 | +- [x] Success criteria are measurable | |
| 19 | +- [x] Success criteria are technology-agnostic (no implementation details) | |
| 20 | +- [x] All acceptance scenarios are defined | |
| 21 | +- [x] Edge cases are identified | |
| 22 | +- [x] Scope is clearly bounded | |
| 23 | +- [x] Dependencies and assumptions identified | |
| 24 | + | |
| 25 | +## Feature Readiness | |
| 26 | + | |
| 27 | +- [x] All functional requirements have clear acceptance criteria | |
| 28 | +- [x] User scenarios cover primary flows | |
| 29 | +- [x] Feature meets measurable outcomes defined in Success Criteria | |
| 30 | +- [x] No implementation details leak into specification | |
| 31 | + | |
| 32 | +## Notes | |
| 33 | + | |
| 34 | +- FR-004/FR-005 précisent, après clarification avec l'utilisateur (2026-09-18) : Régine déclenche | |
| 35 | + le montage natif du système d'exploitation pour le partage SMB et mémorise son emplacement, mais | |
| 36 | + ne gère ni ne stocke elle-même d'identifiants réseau — cette responsabilité reste entièrement | |
| 37 | + déléguée à l'OS. | |
| new file mode 100644 | |||
| @@ -0,0 +1,37 @@ | |||
| 1 | +# Specification Quality Checklist: Configuration du contexte de travail de Régine | ||
| 2 | + | ||
| 3 | +**Purpose**: Validate specification completeness and quality before proceeding to planning | ||
| 4 | +**Created**: 2026-09-18 | ||
| 5 | +**Feature**: [spec.md](../spec.md) | ||
| 6 | + | ||
| 7 | +## Content Quality | ||
| 8 | + | ||
| 9 | +- [x] No implementation details (languages, frameworks, APIs) | ||
| 10 | +- [x] Focused on user value and business needs | ||
| 11 | +- [x] Written for non-technical stakeholders | ||
| 12 | +- [x] All mandatory sections completed | ||
| 13 | + | ||
| 14 | +## Requirement Completeness | ||
| 15 | + | ||
| 16 | +- [x] No [NEEDS CLARIFICATION] markers remain | ||
| 17 | +- [x] Requirements are testable and unambiguous | ||
| 18 | +- [x] Success criteria are measurable | ||
| 19 | +- [x] Success criteria are technology-agnostic (no implementation details) | ||
| 20 | +- [x] All acceptance scenarios are defined | ||
| 21 | +- [x] Edge cases are identified | ||
| 22 | +- [x] Scope is clearly bounded | ||
| 23 | +- [x] Dependencies and assumptions identified | ||
| 24 | + | ||
| 25 | +## Feature Readiness | ||
| 26 | + | ||
| 27 | +- [x] All functional requirements have clear acceptance criteria | ||
| 28 | +- [x] User scenarios cover primary flows | ||
| 29 | +- [x] Feature meets measurable outcomes defined in Success Criteria | ||
| 30 | +- [x] No implementation details leak into specification | ||
| 31 | + | ||
| 32 | +## Notes | ||
| 33 | + | ||
| 34 | +- FR-004/FR-005 précisent, après clarification avec l'utilisateur (2026-09-18) : Régine déclenche | ||
| 35 | + le montage natif du système d'exploitation pour le partage SMB et mémorise son emplacement, mais | ||
| 36 | + ne gère ni ne stocke elle-même d'identifiants réseau — cette responsabilité reste entièrement | ||
| 37 | + déléguée à l'OS. | ||
added
specs/003-config-contexte-travail/spec.md +109 -0 | new file mode 100644 | ||
| @@ -0,0 +1,109 @@ | ||
| 1 | +# Feature Specification: Configuration du contexte de travail de Régine | |
| 2 | + | |
| 3 | +**Feature Branch**: `[003-config-contexte-travail]` | |
| 4 | + | |
| 5 | +**Created**: 2026-09-18 | |
| 6 | + | |
| 7 | +**Status**: Draft | |
| 8 | + | |
| 9 | +**Input**: User description: "le module de configuration permet de definir le context de travail de Regine. Permet de nomer les boitiers du photographe en fonction des photos déjà integrées. Configure les chemins : repertoire temporaire, repertoire de travaille local , chemin du nas (SMB) et aide au montage auto du SMB si pas disponible. d'autres paramètres pourronts êtres integrés plus tard. Il faut aussi préparer la base de données de travail qui sera à la racine du répértoire de travail et archivée en même temps que l'archivage des dossiers locaux." | |
| 10 | + | |
| 11 | +## User Scenarios & Testing *(mandatory)* | |
| 12 | + | |
| 13 | +### User Story 1 - Configuration initiale des emplacements de travail (Priority: P1) | |
| 14 | + | |
| 15 | +Avant tout import ou archivage, un photographe indique à Régine où se trouvent ses trois emplacements de travail : un répertoire temporaire pour les copies brutes, un répertoire de travail local pour l'édition, et l'emplacement de l'archive sur le NAS. Une fois ces trois chemins enregistrés, Régine est prête à réaliser sa première opération. | |
| 16 | + | |
| 17 | +**Why this priority**: Aucune autre fonctionnalité de Régine (import, checkout, réconciliation, archivage) ne peut fonctionner sans savoir où lire et écrire. C'est le prérequis strict de tout le reste. | |
| 18 | + | |
| 19 | +**Independent Test**: Peut être testé en configurant les trois chemins sur une installation neuve de Régine, sans réaliser aucun import, puis en vérifiant qu'une autre fonctionnalité (ex. import) peut lire ces chemins et les utiliser sans reconfiguration supplémentaire. | |
| 20 | + | |
| 21 | +**Acceptance Scenarios**: | |
| 22 | + | |
| 23 | +1. **Given** une installation de Régine sans contexte de travail configuré, **When** l'utilisateur renseigne un répertoire temporaire, un répertoire de travail local et un emplacement d'archive NAS, **Then** Régine enregistre ces trois chemins comme contexte de travail actif. | |
| 24 | +2. **Given** un chemin de répertoire temporaire ou de répertoire de travail local qui n'existe pas encore, **When** l'utilisateur le configure, **Then** Régine propose de le créer plutôt que d'échouer silencieusement. | |
| 25 | +3. **Given** un répertoire de travail local nouvellement configuré, **When** Régine initialise le contexte de travail, **Then** une base de données de travail est créée et prête à la racine de ce répertoire, avant qu'aucune autre opération n'en ait besoin. | |
| 26 | +4. **Given** un contexte de travail déjà configuré, **When** l'utilisateur modifie l'un des trois chemins, **Then** Régine applique le changement sans nécessiter de réinstallation ni perdre les autres paramètres déjà définis (boîtiers nommés compris). | |
| 27 | + | |
| 28 | +--- | |
| 29 | + | |
| 30 | +### User Story 2 - Assistance quand l'archive NAS n'est pas accessible (Priority: P2) | |
| 31 | + | |
| 32 | +Un photographe lance une opération nécessitant l'archive (import, archivage, consultation), mais le partage réseau vers le NAS n'est pas monté ou pas accessible à cet instant (ex. redémarrage récent de l'ordinateur, réseau non encore établi). Plutôt que d'échouer avec une erreur incompréhensible, Régine détecte la situation et aide l'utilisateur à rétablir l'accès. | |
| 33 | + | |
| 34 | +**Why this priority**: L'indisponibilité temporaire d'un partage réseau est un incident courant et non bloquant en soi ; sans cette assistance, chaque redémarrage ou coupure réseau se traduirait par une erreur confuse plutôt qu'une situation récupérable. | |
| 35 | + | |
| 36 | +**Independent Test**: Peut être testé en configurant un emplacement d'archive NAS valide mais actuellement inaccessible, en déclenchant une opération qui en a besoin, et en vérifiant que Régine propose une assistance au rétablissement de l'accès plutôt qu'un simple message d'erreur, puis que l'opération peut reprendre une fois l'accès rétabli. | |
| 37 | + | |
| 38 | +**Acceptance Scenarios**: | |
| 39 | + | |
| 40 | +1. **Given** un emplacement d'archive NAS configuré mais non accessible au moment d'une opération, **When** cette opération démarre, **Then** Régine détecte l'indisponibilité avant d'échouer et propose une action pour rétablir l'accès. | |
| 41 | +2. **Given** une assistance au rétablissement de l'accès proposée, **When** l'accès au NAS est rétabli, **Then** l'opération initialement bloquée peut reprendre sans que l'utilisateur ait à reconfigurer le contexte de travail depuis le début. | |
| 42 | +3. **Given** une tentative de rétablissement de l'accès qui échoue de façon répétée, **When** Régine ne parvient toujours pas à accéder au NAS, **Then** elle informe clairement l'utilisateur de l'échec plutôt que de retenter indéfiniment en silence. | |
| 43 | + | |
| 44 | +--- | |
| 45 | + | |
| 46 | +### User Story 3 - Nommer les boîtiers à partir des photos déjà archivées (Priority: P3) | |
| 47 | + | |
| 48 | +Un photographe consulte la configuration de Régine et veut donner un nom lisible à ses boîtiers (ex. "Fuji principal", "Fuji secours") sans avoir à réimporter une carte mémoire : Régine détecte les boîtiers déjà rencontrés dans les photos déjà intégrées à l'archive et propose de les nommer. | |
| 49 | + | |
| 50 | +**Why this priority**: Complète le profil de boîtiers optionnel (déjà couvert par ailleurs) avec un point d'entrée proactif et confortable, mais reste un raffinement : un utilisateur peut se passer de cette fonctionnalité, le nommage restant possible au moment d'une collision réelle. | |
| 51 | + | |
| 52 | +**Independent Test**: Peut être testé sur une archive contenant déjà des photos d'au moins un boîtier identifiable, en ouvrant l'écran de configuration des boîtiers et en vérifiant que ce boîtier apparaît comme détecté à partir des photos existantes, sans qu'aucun nouvel import ne soit nécessaire. | |
| 53 | + | |
| 54 | +**Acceptance Scenarios**: | |
| 55 | + | |
| 56 | +1. **Given** des photos déjà intégrées à l'archive provenant d'au moins un boîtier identifiable, **When** l'utilisateur ouvre la configuration des boîtiers, **Then** Régine liste les boîtiers détectés (regroupés par modèle et, si disponible, numéro de série) à partir de ces photos. | |
| 57 | +2. **Given** un boîtier détecté mais non nommé, **When** l'utilisateur lui attribue un nom, **Then** ce nom est associé au boîtier et réutilisé partout où Régine identifie ce même boîtier par la suite. | |
| 58 | +3. **Given** deux boîtiers de même modèle jamais distingués faute de collision ou de numéro de série exploitable, **When** l'utilisateur consulte la liste, **Then** ils apparaissent comme une seule entrée détectée tant qu'aucune information ne permet de les séparer. | |
| 59 | + | |
| 60 | +--- | |
| 61 | + | |
| 62 | +### Edge Cases | |
| 63 | + | |
| 64 | +- 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. | |
| 65 | +- Que se passe-t-il si le chemin renseigné pour l'archive NAS ne correspond pas à un partage réseau valide (ex. confusion avec un dossier local) ? Régine DOIT signaler l'anomalie de configuration plutôt que de l'enregistrer telle quelle. | |
| 66 | +- Que se passe-t-il si l'espace disque du répertoire de travail local devient insuffisant pour accueillir la base de données de travail ? Régine DOIT signaler une erreur de configuration claire plutôt que de créer une base de données partiellement écrite. | |
| 67 | +- Que se passe-t-il si l'utilisateur tente de lancer une opération avant d'avoir configuré le contexte de travail ? Régine DOIT indiquer clairement quels chemins manquent plutôt que d'échouer avec une erreur technique. | |
| 68 | + | |
| 69 | +## Requirements *(mandatory)* | |
| 70 | + | |
| 71 | +### Functional Requirements | |
| 72 | + | |
| 73 | +- **FR-001**: Le système DOIT permettre de configurer, indépendamment de tout import, trois emplacements de travail : un répertoire temporaire, un répertoire de travail local, et l'emplacement de l'archive sur le NAS. | |
| 74 | +- **FR-002**: Le système DOIT permettre de spécifier l'emplacement de l'archive comme un partage réseau SMB. | |
| 75 | +- **FR-003**: Lorsqu'un répertoire temporaire ou un répertoire de travail local configuré n'existe pas encore, le système DOIT proposer de le créer plutôt que d'échouer silencieusement. | |
| 76 | +- **FR-004**: Lorsque le partage SMB configuré n'est pas accessible au moment où une opération en a besoin, le système DOIT détecter cette indisponibilité et déclencher le mécanisme de montage natif du système d'exploitation pour ce partage, plutôt que d'échouer avec une erreur générique. Le système ne DOIT PAS gérer ou stocker lui-même d'identifiants réseau : l'authentification et la sécurité des paramètres de connexion restent entièrement déléguées au système d'exploitation. | |
| 77 | +- **FR-005**: Le système DOIT mémoriser l'emplacement SMB configuré (cf. FR-001) afin de pouvoir redéclencher son montage natif à chaque nouvelle indisponibilité détectée, sans que l'utilisateur ait à ressaisir ce chemin. Une fois l'accès au NAS rétabli après une indisponibilité détectée, le système DOIT permettre de reprendre l'opération initialement bloquée sans reconfiguration complète du contexte de travail. | |
| 78 | +- **FR-006**: Le système DOIT initialiser, à la racine du répertoire de travail local, une base de données de travail prête à l'usage avant qu'aucune autre opération de Régine n'en ait besoin. | |
| 79 | +- **FR-007**: Lorsqu'un dossier du répertoire de travail local est archivé vers le NAS, la base de données de travail correspondant à ce dossier DOIT être archivée avec lui, comme partie intégrante du dossier archivé. | |
| 80 | +- **FR-008**: Le système DOIT détecter, à partir des photos déjà intégrées à l'archive, les boîtiers déjà rencontrés (regroupés par modèle et, si disponible, numéro de série), et permettre à l'utilisateur de leur attribuer un nom lisible, sans nécessiter de nouvel import. | |
| 81 | +- **FR-009**: Un nom attribué à un boîtier via la configuration DOIT être réutilisé partout où Régine identifie ce même boîtier par la suite (import, désambiguïsation de collision). | |
| 82 | +- **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. | |
| 83 | +- **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. | |
| 84 | + | |
| 85 | +### Key Entities | |
| 86 | + | |
| 87 | +- **Contexte de travail** : ensemble des paramètres de configuration actifs (chemins, boîtiers nommés) utilisés par l'ensemble des modules de Régine. | |
| 88 | +- **Répertoire temporaire** : emplacement local destiné aux copies brutes avant analyse, en amont d'un import. | |
| 89 | +- **Répertoire de travail local** : emplacement local où résident les copies de travail (checkout, import en cours) et leur base de données. | |
| 90 | +- **Emplacement de l'archive (NAS/SMB)** : chemin réseau où réside l'archive persistante de Régine. | |
| 91 | +- **Base de données de travail** : base persistante créée à la racine du répertoire de travail local, associée à chaque dossier local et archivée avec lui. | |
| 92 | +- **Boîtier nommé** : entrée associant un nom lisible choisi par l'utilisateur à un boîtier détecté (modèle et, si disponible, numéro de série) à partir des photos déjà intégrées à l'archive. | |
| 93 | + | |
| 94 | +## Success Criteria *(mandatory)* | |
| 95 | + | |
| 96 | +### Measurable Outcomes | |
| 97 | + | |
| 98 | +- **SC-001**: Un utilisateur configure les trois emplacements de travail et réalise un premier import sans aucune erreur liée à un chemin manquant ou incorrect. | |
| 99 | +- **SC-002**: 100% des opérations nécessitant l'accès au NAS alors que le partage SMB est indisponible déclenchent une assistance au rétablissement de l'accès plutôt qu'un échec brut. | |
| 100 | +- **SC-003**: La base de données de travail est présente et utilisable à la racine du répertoire de travail local avant la première opération qui en a besoin, dans 100% des cas. | |
| 101 | +- **SC-004**: Un utilisateur peut nommer un boîtier détecté à partir de photos déjà archivées sans avoir à réimporter ou reconnecter de carte mémoire. | |
| 102 | +- **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é. | |
| 103 | + | |
| 104 | +## Assumptions | |
| 105 | + | |
| 106 | +- Le contexte de travail est unique par installation de Régine (un seul jeu de chemins et de boîtiers nommés actif à la fois) ; la gestion de plusieurs contextes en parallèle n'est pas couverte par cette spécification. | |
| 107 | +- 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. | |
| 108 | +- 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. | |
| 109 | +- 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é. | |
| new file mode 100644 | |||
| @@ -0,0 +1,109 @@ | |||
| 1 | +# Feature Specification: Configuration du contexte de travail de Régine | ||
| 2 | + | ||
| 3 | +**Feature Branch**: `[003-config-contexte-travail]` | ||
| 4 | + | ||
| 5 | +**Created**: 2026-09-18 | ||
| 6 | + | ||
| 7 | +**Status**: Draft | ||
| 8 | + | ||
| 9 | +**Input**: User description: "le module de configuration permet de definir le context de travail de Regine. Permet de nomer les boitiers du photographe en fonction des photos déjà integrées. Configure les chemins : repertoire temporaire, repertoire de travaille local , chemin du nas (SMB) et aide au montage auto du SMB si pas disponible. d'autres paramètres pourronts êtres integrés plus tard. Il faut aussi préparer la base de données de travail qui sera à la racine du répértoire de travail et archivée en même temps que l'archivage des dossiers locaux." | ||
| 10 | + | ||
| 11 | +## User Scenarios & Testing *(mandatory)* | ||
| 12 | + | ||
| 13 | +### User Story 1 - Configuration initiale des emplacements de travail (Priority: P1) | ||
| 14 | + | ||
| 15 | +Avant tout import ou archivage, un photographe indique à Régine où se trouvent ses trois emplacements de travail : un répertoire temporaire pour les copies brutes, un répertoire de travail local pour l'édition, et l'emplacement de l'archive sur le NAS. Une fois ces trois chemins enregistrés, Régine est prête à réaliser sa première opération. | ||
| 16 | + | ||
| 17 | +**Why this priority**: Aucune autre fonctionnalité de Régine (import, checkout, réconciliation, archivage) ne peut fonctionner sans savoir où lire et écrire. C'est le prérequis strict de tout le reste. | ||
| 18 | + | ||
| 19 | +**Independent Test**: Peut être testé en configurant les trois chemins sur une installation neuve de Régine, sans réaliser aucun import, puis en vérifiant qu'une autre fonctionnalité (ex. import) peut lire ces chemins et les utiliser sans reconfiguration supplémentaire. | ||
| 20 | + | ||
| 21 | +**Acceptance Scenarios**: | ||
| 22 | + | ||
| 23 | +1. **Given** une installation de Régine sans contexte de travail configuré, **When** l'utilisateur renseigne un répertoire temporaire, un répertoire de travail local et un emplacement d'archive NAS, **Then** Régine enregistre ces trois chemins comme contexte de travail actif. | ||
| 24 | +2. **Given** un chemin de répertoire temporaire ou de répertoire de travail local qui n'existe pas encore, **When** l'utilisateur le configure, **Then** Régine propose de le créer plutôt que d'échouer silencieusement. | ||
| 25 | +3. **Given** un répertoire de travail local nouvellement configuré, **When** Régine initialise le contexte de travail, **Then** une base de données de travail est créée et prête à la racine de ce répertoire, avant qu'aucune autre opération n'en ait besoin. | ||
| 26 | +4. **Given** un contexte de travail déjà configuré, **When** l'utilisateur modifie l'un des trois chemins, **Then** Régine applique le changement sans nécessiter de réinstallation ni perdre les autres paramètres déjà définis (boîtiers nommés compris). | ||
| 27 | + | ||
| 28 | +--- | ||
| 29 | + | ||
| 30 | +### User Story 2 - Assistance quand l'archive NAS n'est pas accessible (Priority: P2) | ||
| 31 | + | ||
| 32 | +Un photographe lance une opération nécessitant l'archive (import, archivage, consultation), mais le partage réseau vers le NAS n'est pas monté ou pas accessible à cet instant (ex. redémarrage récent de l'ordinateur, réseau non encore établi). Plutôt que d'échouer avec une erreur incompréhensible, Régine détecte la situation et aide l'utilisateur à rétablir l'accès. | ||
| 33 | + | ||
| 34 | +**Why this priority**: L'indisponibilité temporaire d'un partage réseau est un incident courant et non bloquant en soi ; sans cette assistance, chaque redémarrage ou coupure réseau se traduirait par une erreur confuse plutôt qu'une situation récupérable. | ||
| 35 | + | ||
| 36 | +**Independent Test**: Peut être testé en configurant un emplacement d'archive NAS valide mais actuellement inaccessible, en déclenchant une opération qui en a besoin, et en vérifiant que Régine propose une assistance au rétablissement de l'accès plutôt qu'un simple message d'erreur, puis que l'opération peut reprendre une fois l'accès rétabli. | ||
| 37 | + | ||
| 38 | +**Acceptance Scenarios**: | ||
| 39 | + | ||
| 40 | +1. **Given** un emplacement d'archive NAS configuré mais non accessible au moment d'une opération, **When** cette opération démarre, **Then** Régine détecte l'indisponibilité avant d'échouer et propose une action pour rétablir l'accès. | ||
| 41 | +2. **Given** une assistance au rétablissement de l'accès proposée, **When** l'accès au NAS est rétabli, **Then** l'opération initialement bloquée peut reprendre sans que l'utilisateur ait à reconfigurer le contexte de travail depuis le début. | ||
| 42 | +3. **Given** une tentative de rétablissement de l'accès qui échoue de façon répétée, **When** Régine ne parvient toujours pas à accéder au NAS, **Then** elle informe clairement l'utilisateur de l'échec plutôt que de retenter indéfiniment en silence. | ||
| 43 | + | ||
| 44 | +--- | ||
| 45 | + | ||
| 46 | +### User Story 3 - Nommer les boîtiers à partir des photos déjà archivées (Priority: P3) | ||
| 47 | + | ||
| 48 | +Un photographe consulte la configuration de Régine et veut donner un nom lisible à ses boîtiers (ex. "Fuji principal", "Fuji secours") sans avoir à réimporter une carte mémoire : Régine détecte les boîtiers déjà rencontrés dans les photos déjà intégrées à l'archive et propose de les nommer. | ||
| 49 | + | ||
| 50 | +**Why this priority**: Complète le profil de boîtiers optionnel (déjà couvert par ailleurs) avec un point d'entrée proactif et confortable, mais reste un raffinement : un utilisateur peut se passer de cette fonctionnalité, le nommage restant possible au moment d'une collision réelle. | ||
| 51 | + | ||
| 52 | +**Independent Test**: Peut être testé sur une archive contenant déjà des photos d'au moins un boîtier identifiable, en ouvrant l'écran de configuration des boîtiers et en vérifiant que ce boîtier apparaît comme détecté à partir des photos existantes, sans qu'aucun nouvel import ne soit nécessaire. | ||
| 53 | + | ||
| 54 | +**Acceptance Scenarios**: | ||
| 55 | + | ||
| 56 | +1. **Given** des photos déjà intégrées à l'archive provenant d'au moins un boîtier identifiable, **When** l'utilisateur ouvre la configuration des boîtiers, **Then** Régine liste les boîtiers détectés (regroupés par modèle et, si disponible, numéro de série) à partir de ces photos. | ||
| 57 | +2. **Given** un boîtier détecté mais non nommé, **When** l'utilisateur lui attribue un nom, **Then** ce nom est associé au boîtier et réutilisé partout où Régine identifie ce même boîtier par la suite. | ||
| 58 | +3. **Given** deux boîtiers de même modèle jamais distingués faute de collision ou de numéro de série exploitable, **When** l'utilisateur consulte la liste, **Then** ils apparaissent comme une seule entrée détectée tant qu'aucune information ne permet de les séparer. | ||
| 59 | + | ||
| 60 | +--- | ||
| 61 | + | ||
| 62 | +### Edge Cases | ||
| 63 | + | ||
| 64 | +- 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. | ||
| 65 | +- Que se passe-t-il si le chemin renseigné pour l'archive NAS ne correspond pas à un partage réseau valide (ex. confusion avec un dossier local) ? Régine DOIT signaler l'anomalie de configuration plutôt que de l'enregistrer telle quelle. | ||
| 66 | +- Que se passe-t-il si l'espace disque du répertoire de travail local devient insuffisant pour accueillir la base de données de travail ? Régine DOIT signaler une erreur de configuration claire plutôt que de créer une base de données partiellement écrite. | ||
| 67 | +- Que se passe-t-il si l'utilisateur tente de lancer une opération avant d'avoir configuré le contexte de travail ? Régine DOIT indiquer clairement quels chemins manquent plutôt que d'échouer avec une erreur technique. | ||
| 68 | + | ||
| 69 | +## Requirements *(mandatory)* | ||
| 70 | + | ||
| 71 | +### Functional Requirements | ||
| 72 | + | ||
| 73 | +- **FR-001**: Le système DOIT permettre de configurer, indépendamment de tout import, trois emplacements de travail : un répertoire temporaire, un répertoire de travail local, et l'emplacement de l'archive sur le NAS. | ||
| 74 | +- **FR-002**: Le système DOIT permettre de spécifier l'emplacement de l'archive comme un partage réseau SMB. | ||
| 75 | +- **FR-003**: Lorsqu'un répertoire temporaire ou un répertoire de travail local configuré n'existe pas encore, le système DOIT proposer de le créer plutôt que d'échouer silencieusement. | ||
| 76 | +- **FR-004**: Lorsque le partage SMB configuré n'est pas accessible au moment où une opération en a besoin, le système DOIT détecter cette indisponibilité et déclencher le mécanisme de montage natif du système d'exploitation pour ce partage, plutôt que d'échouer avec une erreur générique. Le système ne DOIT PAS gérer ou stocker lui-même d'identifiants réseau : l'authentification et la sécurité des paramètres de connexion restent entièrement déléguées au système d'exploitation. | ||
| 77 | +- **FR-005**: Le système DOIT mémoriser l'emplacement SMB configuré (cf. FR-001) afin de pouvoir redéclencher son montage natif à chaque nouvelle indisponibilité détectée, sans que l'utilisateur ait à ressaisir ce chemin. Une fois l'accès au NAS rétabli après une indisponibilité détectée, le système DOIT permettre de reprendre l'opération initialement bloquée sans reconfiguration complète du contexte de travail. | ||
| 78 | +- **FR-006**: Le système DOIT initialiser, à la racine du répertoire de travail local, une base de données de travail prête à l'usage avant qu'aucune autre opération de Régine n'en ait besoin. | ||
| 79 | +- **FR-007**: Lorsqu'un dossier du répertoire de travail local est archivé vers le NAS, la base de données de travail correspondant à ce dossier DOIT être archivée avec lui, comme partie intégrante du dossier archivé. | ||
| 80 | +- **FR-008**: Le système DOIT détecter, à partir des photos déjà intégrées à l'archive, les boîtiers déjà rencontrés (regroupés par modèle et, si disponible, numéro de série), et permettre à l'utilisateur de leur attribuer un nom lisible, sans nécessiter de nouvel import. | ||
| 81 | +- **FR-009**: Un nom attribué à un boîtier via la configuration DOIT être réutilisé partout où Régine identifie ce même boîtier par la suite (import, désambiguïsation de collision). | ||
| 82 | +- **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. | ||
| 83 | +- **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. | ||
| 84 | + | ||
| 85 | +### Key Entities | ||
| 86 | + | ||
| 87 | +- **Contexte de travail** : ensemble des paramètres de configuration actifs (chemins, boîtiers nommés) utilisés par l'ensemble des modules de Régine. | ||
| 88 | +- **Répertoire temporaire** : emplacement local destiné aux copies brutes avant analyse, en amont d'un import. | ||
| 89 | +- **Répertoire de travail local** : emplacement local où résident les copies de travail (checkout, import en cours) et leur base de données. | ||
| 90 | +- **Emplacement de l'archive (NAS/SMB)** : chemin réseau où réside l'archive persistante de Régine. | ||
| 91 | +- **Base de données de travail** : base persistante créée à la racine du répertoire de travail local, associée à chaque dossier local et archivée avec lui. | ||
| 92 | +- **Boîtier nommé** : entrée associant un nom lisible choisi par l'utilisateur à un boîtier détecté (modèle et, si disponible, numéro de série) à partir des photos déjà intégrées à l'archive. | ||
| 93 | + | ||
| 94 | +## Success Criteria *(mandatory)* | ||
| 95 | + | ||
| 96 | +### Measurable Outcomes | ||
| 97 | + | ||
| 98 | +- **SC-001**: Un utilisateur configure les trois emplacements de travail et réalise un premier import sans aucune erreur liée à un chemin manquant ou incorrect. | ||
| 99 | +- **SC-002**: 100% des opérations nécessitant l'accès au NAS alors que le partage SMB est indisponible déclenchent une assistance au rétablissement de l'accès plutôt qu'un échec brut. | ||
| 100 | +- **SC-003**: La base de données de travail est présente et utilisable à la racine du répertoire de travail local avant la première opération qui en a besoin, dans 100% des cas. | ||
| 101 | +- **SC-004**: Un utilisateur peut nommer un boîtier détecté à partir de photos déjà archivées sans avoir à réimporter ou reconnecter de carte mémoire. | ||
| 102 | +- **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é. | ||
| 103 | + | ||
| 104 | +## Assumptions | ||
| 105 | + | ||
| 106 | +- Le contexte de travail est unique par installation de Régine (un seul jeu de chemins et de boîtiers nommés actif à la fois) ; la gestion de plusieurs contextes en parallèle n'est pas couverte par cette spécification. | ||
| 107 | +- 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. | ||
| 108 | +- 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. | ||
| 109 | +- 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é. | ||