| @@ -1,19 +1,34 @@ |
| 1 | <!-- | 1 | <!-- |
| 2 | Sync Impact Report | 2 | Sync Impact Report |
| 3 | -Version change: 2.0.0 → 2.1.0 (renforcement matériel d'exigences existantes, périmètre des | 3 | +Version change: 2.1.0 → 2.2.0 (ajouts et clarifications matériels, aucun principe supprimé ni |
| 4 | - principes inchangé) | 4 | + rendu rétroactivement incompatible) |
| 5 | -Modified principles: I. Fichier maître intouchable — précision du mécanisme de détection d'une | 5 | +Modified principles: |
| 6 | - modification : hash fichier entier pour les RAW propriétaires, hash image-only requis en | 6 | + I. Fichier maître intouchable — le statut de fichier maître est désormais défini par le rôle |
| 7 | - complément pour DNG/TIFF/JPEG (les outils d'édition courants peuvent légitimement réécrire les | 7 | + (fichier faisant autorité pour une capture) plutôt qu'automatiquement par le format : un JPEG |
| 8 | - métadonnées de ces formats directement dans le fichier). III. Identité par contenu, jamais par | 8 | + en mode RAW+JPEG peut devenir le fichier maître de la capture, au cas par cas selon l'usage |
| 9 | - nom de fichier seul — renvoi ajouté vers cette distinction à deux niveaux pour éviter toute | 9 | + jugé par le photographe, le RAW n'étant alors conservé qu'en complément. Cette nuance ne |
| 10 | - lecture contradictoire avec le hash unique mentionné au principe. | 10 | + retire aucune protection existante : les deux fichiers restent protégés à l'identique par le |
| 11 | -Added sections: aucune (ajout de deux exigences dans « Contraintes techniques » : vérification | 11 | + Principe II, quel que soit celui qui porte le statut de fichier maître. |
| 12 | - périodique indépendante du checkout / scrub, et distinction détection vs réparation) | 12 | + II. Confirmation explicite avant toute action destructive → renommé « Confirmation explicite |
| | 13 | + avant toute action à risque » — portée élargie de la seule suppression à toute action |
| | 14 | + modifiant l'état persistant de l'archive (écriture, restauration, écrasement), et rendue |
| | 15 | + explicitement applicable à toute façade (CLI, GUI, agent IA), pas seulement au flux de |
| | 16 | + réconciliation historique. |
| | 17 | +Added sections: |
| | 18 | + VI. Bibliothèque centrale, façades minces — nouveau principe formalisant l'architecture en |
| | 19 | + bibliothèque centrale + façades minces (CLI, GUI, agent IA) sans logique métier dupliquée. |
| | 20 | + Contraintes techniques — clarification de la règle 3-2-1 (NAS + cloud ne comptent que pour 2 |
| | 21 | + copies, troisième copie sur disque de sauvegarde local dédié requise) et ajout d'une |
| | 22 | + exigence d'exécution sans démon (bibliothèque en Python, import direct, un processus par |
| | 23 | + lancement, concurrence couverte par le verrou de checkout). |
| | 24 | + Workflow d'archivage — ajout d'une clause sur les projets composés par copie (distincts de la |
| | 25 | + hiérarchie dossier/sous-dossier/dossier parent, copie vérifiée par checksum, fiche de |
| | 26 | + provenance obligatoire). |
| 13 | Removed sections: aucune | 27 | Removed sections: aucune |
| 14 | Templates requiring follow-up: aucun contrôle croisé effectué sur plan-template.md / | 28 | Templates requiring follow-up: aucun contrôle croisé effectué sur plan-template.md / |
| 15 | spec-template.md / tasks-template.md dans cette exécution — à vérifier manuellement lors du | 29 | spec-template.md / tasks-template.md dans cette exécution — à vérifier manuellement lors du |
| 16 | - prochain /speckit-plan. | 30 | + prochain /speckit-plan, en particulier pour le nouveau Principe VI (façades minces) et la |
| | 31 | + portée élargie du Principe II (action à risque plutôt que suppression seule). |
| 17 | Deferred TODOs: aucun | 32 | Deferred TODOs: aucun |
| 18 | --> | 33 | --> |
| 19 | # Constitution du projet Régine | 34 | # Constitution du projet Régine |
| @@ -21,20 +36,31 @@ Deferred TODOs: aucun |
| 21 | ## Core Principles | 36 | ## Core Principles |
| 22 | | 37 | |
| 23 | ### I. Fichier maître intouchable | 38 | ### I. Fichier maître intouchable |
| 24 | -Est un fichier maître : tout RAW, tout TIFF ou BMP issu d'un scan, ET tout JPEG issu directement | 39 | +Le fichier maître est défini par son rôle, pas automatiquement par son format (précisé le |
| 25 | -de l'appareil photo — que ce JPEG soit la seule capture (mode JPEG seul) ou qu'il forme un couple | 40 | +2026-09-18) : c'est le fichier faisant autorité pour une capture donnée, celui à conserver |
| 26 | -RAW+JPEG avec un RAW du même nom. Aucun fichier maître n'est modifié une fois entré dans | 41 | +indéfiniment sans jamais le modifier. Sont fichiers maîtres par défaut : tout RAW propriétaire, |
| 27 | -l'archive. Toute modification détectée sur un fichier maître par rapport au manifeste de | 42 | +tout TIFF ou BMP issu d'un scan. Un JPEG issu directement de l'appareil (jamais un export généré |
| | 43 | +depuis un RAW, qui reste un dérivé) est également fichier maître dans deux cas : lorsqu'il |
| | 44 | +constitue la seule capture pour cette prise de vue (mode JPEG seul, sans RAW correspondant) ; et, |
| | 45 | +même en mode RAW+JPEG, lorsque le photographe juge le JPEG satisfaisant pour l'usage prévu et ne |
| | 46 | +conserve le RAW que pour un usage secondaire (ex. un agrandissement futur qui demanderait plus de |
| | 47 | +latitude) — décision prise au cas par cas selon l'usage, jamais déduite automatiquement d'une |
| | 48 | +règle de format. Aucun fichier maître, quel que soit son format, n'est modifié une fois entré |
| | 49 | +dans l'archive. Toute modification détectée sur un fichier maître par rapport au manifeste de |
| 28 | référence (hash SHA-256, cf. workflow de réconciliation) DOIT être signalée à l'utilisateur comme | 50 | référence (hash SHA-256, cf. workflow de réconciliation) DOIT être signalée à l'utilisateur comme |
| 29 | anomalie et ne DOIT JAMAIS être réarchivée silencieusement. | 51 | anomalie et ne DOIT JAMAIS être réarchivée silencieusement. |
| 30 | | 52 | |
| 31 | -Un JPEG issu de l'appareil n'est jamais un simple dérivé jetable du RAW : certaines captures | 53 | +Ce statut de fichier maître ne retire aucune protection au fichier qui ne le porte pas dans une |
| 32 | -n'existent qu'en JPEG (pas de RAW correspondant, photo par ailleurs précieuse) et sont donc | 54 | +paire RAW+JPEG. Un JPEG issu de l'appareil n'est jamais un simple dérivé jetable du RAW, qu'il |
| 33 | -irremplaçables ; et même quand un RAW existe, le JPEG de la même capture (même nom de fichier hors | 55 | +porte ou non le statut de fichier maître de la capture : certaines captures n'existent qu'en JPEG |
| 34 | -extension) est une version distincte de la photo, pas une copie de secours du RAW. Régine ne DOIT | 56 | +et sont de ce fait irremplaçables ; et même quand un RAW reste la référence, le JPEG de la même |
| 35 | -JAMAIS supprimer ou modifier un JPEG au seul prétexte qu'un RAW du même nom existe dans l'archive, | 57 | +capture (même nom de fichier hors extension) demeure une version distincte de la photo, pas une |
| 36 | -et réciproquement. Seuls les dérivés créés par l'utilisateur après capture (exports web, | 58 | +copie de secours. Réciproquement, quand le JPEG est désigné fichier maître, le RAW conservé en |
| 37 | -retouches enregistrées à part, sidecars XMP/DOP) peuvent être créés ou modifiés librement. | 59 | +complément n'est pas pour autant jetable. Régine ne DOIT JAMAIS supprimer ou modifier l'un au |
| | 60 | +seul prétexte que l'autre existe ou porte le statut de fichier maître (cf. Principe II, qui |
| | 61 | +applique cette protection à l'identique aux deux, indépendamment du statut). Seuls les dérivés |
| | 62 | +créés par l'utilisateur après capture (exports web, retouches enregistrées à part, sidecars |
| | 63 | +XMP/DOP) peuvent être créés ou modifiés librement. |
| 38 | | 64 | |
| 39 | Le mécanisme de détection d'une modification dépend du format, et cette dépendance ne relâche en | 65 | Le mécanisme de détection d'une modification dépend du format, et cette dépendance ne relâche en |
| 40 | rien l'interdiction ci-dessus. Pour les RAW propriétaires (RAF, CR2, NEF, ARW...), jamais réécrits | 66 | rien l'interdiction ci-dessus. Pour les RAW propriétaires (RAF, CR2, NEF, ARW...), jamais réécrits |
| @@ -51,22 +77,37 @@ anomalie et d'éroder la confiance dans les signalements réels. |
| 51 | | 77 | |
| 52 | **Rationale**: Une capture JPEG seule, ou un JPEG appairé à un RAW, peut être la seule version | 78 | **Rationale**: Une capture JPEG seule, ou un JPEG appairé à un RAW, peut être la seule version |
| 53 | existante d'une photo — l'appareil ne produit pas toujours de RAW, et l'utilisateur choisit | 79 | existante d'une photo — l'appareil ne produit pas toujours de RAW, et l'utilisateur choisit |
| 54 | -parfois le mode JPEG seul. Traiter le JPEG comme un simple dérivé jetable du RAW risquerait de | 80 | +parfois le mode JPEG seul, ou juge le JPEG suffisant pour l'usage prévu même quand un RAW existe. |
| 55 | -faire perdre des photos qui n'ont aucune autre copie. Quant au hash image-only pour DNG/TIFF/JPEG, | 81 | +Fixer le statut de fichier maître au format plutôt qu'au rôle empêcherait de refléter ce choix réel |
| 56 | -il découle du même comportement vérifié (2026-09-11, Lightroom Classic et DxO PhotoLab) : sans | 82 | +du photographe, sans pour autant justifier de traiter l'un des deux fichiers comme jetable : les |
| 57 | -lui, chaque édition légitime de métadonnées sur ces formats déclencherait une fausse alerte, ce qui | 83 | +deux restent protégés, seul le rôle de référence peut se déplacer. Quant au hash image-only pour |
| 58 | -pousserait à terme à ignorer les signalements — l'exact inverse de l'objectif de ce principe. | 84 | +DNG/TIFF/JPEG, il découle du même comportement vérifié (2026-09-11, Lightroom Classic et DxO |
| 59 | - | 85 | +PhotoLab) : sans lui, chaque édition légitime de métadonnées sur ces formats déclencherait une |
| 60 | -### II. Confirmation explicite avant toute action destructive | 86 | +fausse alerte, ce qui pousserait à terme à ignorer les signalements — l'exact inverse de l'objectif |
| 61 | -Aucune suppression de fichier dans l'archive n'est automatique. Qu'elle provienne d'une anomalie | 87 | +de ce principe. |
| 62 | -de réconciliation (fichier absent de la copie de travail) ou d'un déchet identifié à l'import | 88 | + |
| 63 | -(test d'exposition, déclenchement accidentel), la suppression DOIT toujours être présentée à | 89 | +### II. Confirmation explicite avant toute action à risque |
| 64 | -l'utilisateur et validée explicitement avant d'être exécutée sur l'archive. Cette règle s'applique | 90 | +Toute action à risque — écriture sur l'archive, suppression, restauration, écrasement, ou plus |
| 65 | -à l'identique aux RAW et aux JPEG : l'existence d'un fichier maître de l'autre type sous le même | 91 | +largement toute opération qui modifie l'état persistant de l'archive (portée élargie le |
| 66 | -nom ne justifie jamais une suppression automatique. | 92 | +2026-09-18 au-delà de la seule suppression) — DOIT toujours être présentée à l'utilisateur avec un |
| 67 | - | 93 | +résumé clair, puis validée explicitement avant d'être exécutée. Cette règle s'applique à |
| 68 | -**Rationale**: Une archive qui perd des fichiers sans confirmation humaine perd la confiance qui | 94 | +l'identique quelle que soit la façade qui déclenche l'action (CLI, GUI, agent IA) et quelle que |
| 69 | -justifie son existence. | 95 | +soit la formulation de la demande : une phrase à l'impératif ("supprime X", "archive ce dossier") |
| | 96 | +reste soumise à confirmation dès lors qu'elle déclenche une écriture. Une action sans risque |
| | 97 | +(recherche, consultation, prévisualisation, comptage) peut en revanche s'exécuter directement, |
| | 98 | +sans demander la permission préalable de chercher. |
| | 99 | + |
| | 100 | +Cette protection s'applique à l'identique aux RAW et aux JPEG pour toute suppression : l'existence |
| | 101 | +d'un fichier maître de l'autre type ou statut (cf. Principe I) sous le même nom ne justifie jamais |
| | 102 | +une suppression automatique. Face à une anomalie ambiguë (ex. un fichier maître disparu de la |
| | 103 | +copie de travail), l'utilisateur choisit lui-même entre les options possibles — confirmer la |
| | 104 | +suppression dans l'archive, ou restaurer le fichier depuis l'archive — aucune façade ne DOIT |
| | 105 | +trancher à sa place. |
| | 106 | + |
| | 107 | +**Rationale**: Une archive qui perd ou modifie des fichiers sans confirmation humaine perd la |
| | 108 | +confiance qui justifie son existence. Étendre cette exigence à toute façade, agent IA compris, |
| | 109 | +évite que la protection dépende du canal utilisé pour piloter Régine plutôt que de la nature de |
| | 110 | +l'opération. |
| 70 | | 111 | |
| 71 | ### III. Identité par contenu, jamais par nom de fichier seul | 112 | ### III. Identité par contenu, jamais par nom de fichier seul |
| 72 | La détection des renommages, déplacements, doublons et promotions (ex. capture promue à la racine | 113 | La détection des renommages, déplacements, doublons et promotions (ex. capture promue à la racine |
| @@ -102,6 +143,22 @@ La décision finale revient toujours à l'utilisateur. |
| 102 | **Rationale**: Une détection automatique basée sur des horodatages ou des heuristiques n'est | 143 | **Rationale**: Une détection automatique basée sur des horodatages ou des heuristiques n'est |
| 103 | jamais assez fiable pour décider seule d'une réorganisation qui touche l'archive. | 144 | jamais assez fiable pour décider seule d'une réorganisation qui touche l'archive. |
| 104 | | 145 | |
| | 146 | +### VI. Bibliothèque centrale, façades minces |
| | 147 | +Toute la logique métier de Régine (import, checkout/réconciliation, structure de dossier, |
| | 148 | +métadonnées, intégrité, profil de boîtiers) DOIT vivre dans une bibliothèque centrale unique. La |
| | 149 | +CLI, la GUI et l'agent IA sont des façades minces au-dessus de cette bibliothèque : elles |
| | 150 | +appellent les mêmes modules et formatent le résultat pour leur canal, sans dupliquer ni |
| | 151 | +réinventer de logique métier — en particulier, aucune façade ne DOIT recalculer une classification |
| | 152 | +de changement, un critère d'anomalie ou une règle de nommage déjà tranchés par la bibliothèque. La |
| | 153 | +bibliothèque DOIT renvoyer des objets structurés (comptes, listes, diffs typés), jamais du texte |
| | 154 | +déjà formaté pour un terminal, pour qu'une façade n'ait jamais à parser une sortie ni à deviner un |
| | 155 | +chiffre. |
| | 156 | + |
| | 157 | +**Rationale**: Les enchaînements de décisions de Régine (destinations d'un import, classification |
| | 158 | +à la réconciliation, structure par format) sont trop fins pour être ré-implémentés |
| | 159 | +indépendamment par chaque interface sans diverger tôt ou tard ; une bibliothèque unique garantit |
| | 160 | +que CLI, GUI et agent IA se comportent identiquement pour une même situation. |
| | 161 | + |
| 105 | ## Contraintes techniques | 162 | ## Contraintes techniques |
| 106 | | 163 | |
| 107 | - **CLI-first** : chaque fonctionnalité DOIT être exposée via une interface en ligne de commande | 164 | - **CLI-first** : chaque fonctionnalité DOIT être exposée via une interface en ligne de commande |
| @@ -122,7 +179,17 @@ jamais assez fiable pour décider seule d'une réorganisation qui touche l'archi |
| 122 | (règle 3-2-1 ci-dessous) ou un mécanisme de redondance/réparation dédié — jamais sur la seule | 179 | (règle 3-2-1 ci-dessous) ou un mécanisme de redondance/réparation dédié — jamais sur la seule |
| 123 | existence d'un hash. | 180 | existence d'un hash. |
| 124 | - **Règle 3-2-1 comme référence** : toute fonctionnalité de sauvegarde ou d'export s'inscrit dans | 181 | - **Règle 3-2-1 comme référence** : toute fonctionnalité de sauvegarde ou d'export s'inscrit dans |
| 125 | - la logique d'au moins 3 copies, sur 2 types de support différents, dont 1 hors site. | 182 | + la logique d'au moins 3 copies, sur 2 types de support différents, dont 1 hors site. Précision du |
| | 183 | + 2026-09-18 : le NAS et le stockage cloud ne comptent que pour 2 copies — l'ordinateur du |
| | 184 | + photographe ne conserve que des checkouts partiels et temporaires, jamais une copie complète de |
| | 185 | + l'archive, donc il ne compte jamais comme copie au sens de cette règle. La troisième copie DOIT |
| | 186 | + être un support physique dédié (ex. disque de sauvegarde local), régulièrement synchronisé avec |
| | 187 | + le NAS, sur un support différent du NAS et du cloud. |
| | 188 | +- **Exécution sans démon** : la bibliothèque centrale (cf. Principe VI) s'exécute en import direct, |
| | 189 | + un seul processus par lancement, pour la CLI comme pour la GUI — pas de service/démon permanent |
| | 190 | + à installer, gérer ou superviser. La concurrence multi-instances est couverte par le verrou de |
| | 191 | + checkout (cf. Workflow d'archivage), qui joue ce rôle sans complexité de déploiement |
| | 192 | + supplémentaire. |
| 126 | | 193 | |
| 127 | ## Workflow d'archivage | 194 | ## Workflow d'archivage |
| 128 | | 195 | |
| @@ -131,11 +198,19 @@ jamais assez fiable pour décider seule d'une réorganisation qui touche l'archi |
| 131 | explicite, par hash, entre le manifeste de référence pris au checkout et l'état de la copie de | 198 | explicite, par hash, entre le manifeste de référence pris au checkout et l'état de la copie de |
| 132 | travail. Pour DNG/TIFF/JPEG, cette réconciliation DOIT comparer le hash image-only en plus du | 199 | travail. Pour DNG/TIFF/JPEG, cette réconciliation DOIT comparer le hash image-only en plus du |
| 133 | hash fichier entier avant de qualifier un changement d'anomalie (cf. Principe I). | 200 | hash fichier entier avant de qualifier un changement d'anomalie (cf. Principe I). |
| 134 | -- **Verrouillage de projet** : un projet « checké out » DOIT être marqué comme tel côté archive, | 201 | +- **Verrouillage de projet** : un dossier « checké out » DOIT être marqué comme tel côté archive, |
| 135 | pour empêcher que deux instances ou deux personnes modifient la même archive en parallèle. | 202 | pour empêcher que deux instances ou deux personnes modifient la même archive en parallèle. |
| 136 | - **Traçabilité humaine hors application** : la convention de nommage lisible | 203 | - **Traçabilité humaine hors application** : la convention de nommage lisible |
| 137 | (`date_titre_nomOrigine`) est maintenue en complément de l'identifiant pérenne, pour que | 204 | (`date_titre_nomOrigine`) est maintenue en complément de l'identifiant pérenne, pour que |
| 138 | l'archive reste compréhensible même ouverte dans dix ans sans Régine. | 205 | l'archive reste compréhensible même ouverte dans dix ans sans Régine. |
| | 206 | +- **Projets composés par copie, traçables** : un projet (livre, sélection thématique) est un |
| | 207 | + répertoire de travail distinct de la hiérarchie dossier/sous-dossier/dossier parent de |
| | 208 | + l'archive — jamais rattaché à celle-ci, jamais mis à jour par lien ou déplacement. Il est |
| | 209 | + composé par copie vérifiée par checksum, à l'identique de tout autre transfert (cf. |
| | 210 | + Vérification d'intégrité systématique). Chaque copie DOIT être accompagnée d'une fiche de |
| | 211 | + provenance (dossier source, identifiant pérenne, nom d'origine) enregistrée au moment de la |
| | 212 | + copie, pour que le fichier copié reste traçable vers son fichier maître d'origine même après un |
| | 213 | + travail de retouche non destructif. |
| 139 | | 214 | |
| 140 | ## Governance | 215 | ## Governance |
| 141 | | 216 | |
| @@ -155,4 +230,4 @@ Chaque amendement DOIT inclure un rapport d'impact de synchronisation (Sync Impa |
| 155 | commentaire en tête du fichier, listant la version précédente, la nouvelle version, et les | 230 | commentaire en tête du fichier, listant la version précédente, la nouvelle version, et les |
| 156 | sections modifiées, ajoutées ou supprimées. | 231 | sections modifiées, ajoutées ou supprimées. |
| 157 | | 232 | |
| 158 | -**Version**: 2.1.0 | **Ratified**: 2026-09-09 | **Last Amended**: 2026-09-11 | 233 | +**Version**: 2.2.0 | **Ratified**: 2026-09-09 | **Last Amended**: 2026-09-18 |