constitution dans docs
acfa8f4 parent: 04cb3c3 added
docs/constitution.md +158 -0 | new file mode 100644 | ||
| @@ -0,0 +1,158 @@ | ||
| 1 | +<!-- | |
| 2 | +Sync Impact Report | |
| 3 | +Version change: 2.0.0 → 2.1.0 (renforcement matériel d'exigences existantes, périmètre des | |
| 4 | + principes inchangé) | |
| 5 | +Modified principles: I. Fichier maître intouchable — précision du mécanisme de détection d'une | |
| 6 | + modification : hash fichier entier pour les RAW propriétaires, hash image-only requis en | |
| 7 | + complément pour DNG/TIFF/JPEG (les outils d'édition courants peuvent légitimement réécrire les | |
| 8 | + métadonnées de ces formats directement dans le fichier). III. Identité par contenu, jamais par | |
| 9 | + nom de fichier seul — renvoi ajouté vers cette distinction à deux niveaux pour éviter toute | |
| 10 | + lecture contradictoire avec le hash unique mentionné au principe. | |
| 11 | +Added sections: aucune (ajout de deux exigences dans « Contraintes techniques » : vérification | |
| 12 | + périodique indépendante du checkout / scrub, et distinction détection vs réparation) | |
| 13 | +Removed sections: aucune | |
| 14 | +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 | |
| 16 | + prochain /speckit-plan. | |
| 17 | +Deferred TODOs: aucun | |
| 18 | +--> | |
| 19 | +# Constitution du projet Régine | |
| 20 | + | |
| 21 | +## Core Principles | |
| 22 | + | |
| 23 | +### 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 | |
| 25 | +de l'appareil photo — que ce JPEG soit la seule capture (mode JPEG seul) ou qu'il forme un couple | |
| 26 | +RAW+JPEG avec un RAW du même nom. Aucun fichier maître n'est modifié une fois entré dans | |
| 27 | +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 | |
| 29 | +anomalie et ne DOIT JAMAIS être réarchivée silencieusement. | |
| 30 | + | |
| 31 | +Un JPEG issu de l'appareil n'est jamais un simple dérivé jetable du RAW : certaines captures | |
| 32 | +n'existent qu'en JPEG (pas de RAW correspondant, photo par ailleurs précieuse) et sont donc | |
| 33 | +irremplaçables ; et même quand un RAW existe, le JPEG de la même capture (même nom de fichier hors | |
| 34 | +extension) est une version distincte de la photo, pas une copie de secours du RAW. Régine ne DOIT | |
| 35 | +JAMAIS supprimer ou modifier un JPEG au seul prétexte qu'un RAW du même nom existe dans l'archive, | |
| 36 | +et réciproquement. Seuls les dérivés créés par l'utilisateur après capture (exports web, | |
| 37 | +retouches enregistrées à part, sidecars XMP/DOP) peuvent être créés ou modifiés librement. | |
| 38 | + | |
| 39 | +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 | |
| 41 | +par les outils d'édition courants (Lightroom Classic, DxO PhotoLab — réglages et métadonnées vont | |
| 42 | +systématiquement en sidecar séparé), un hash du fichier entier suffit : tout changement de hash | |
| 43 | +est une anomalie réelle. Pour le DNG et pour les masters TIFF/JPEG (scans, ou JPEG promu à la | |
| 44 | +racine du projet), ces mêmes outils écrivent légitimement les métadonnées et réglages directement | |
| 45 | +dans le fichier, sans sidecar — un hash du fichier entier y change donc à chaque édition de | |
| 46 | +métadonnées sans qu'il y ait ni corruption ni altération des pixels. Pour ces formats, Régine DOIT | |
| 47 | +fonder la détection d'anomalie sur un hash portant uniquement sur les données image (pixels), | |
| 48 | +stable à travers les éditions de métadonnées, en complément du hash fichier entier — jamais sur le | |
| 49 | +hash fichier entier seul, sous peine de signaler à tort chaque édition de métadonnées comme une | |
| 50 | +anomalie et d'éroder la confiance dans les signalements réels. | |
| 51 | + | |
| 52 | +**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 | |
| 54 | +parfois le mode JPEG seul. Traiter le JPEG comme un simple dérivé jetable du RAW risquerait de | |
| 55 | +faire perdre des photos qui n'ont aucune autre copie. Quant au hash image-only pour DNG/TIFF/JPEG, | |
| 56 | +il découle du même comportement vérifié (2026-09-11, Lightroom Classic et DxO PhotoLab) : sans | |
| 57 | +lui, chaque édition légitime de métadonnées sur ces formats déclencherait une fausse alerte, ce qui | |
| 58 | +pousserait à terme à ignorer les signalements — l'exact inverse de l'objectif de ce principe. | |
| 59 | + | |
| 60 | +### II. Confirmation explicite avant toute action destructive | |
| 61 | +Aucune suppression de fichier dans l'archive n'est automatique. Qu'elle provienne d'une anomalie | |
| 62 | +de réconciliation (fichier absent de la copie de travail) ou d'un déchet identifié à l'import | |
| 63 | +(test d'exposition, déclenchement accidentel), la suppression DOIT toujours être présentée à | |
| 64 | +l'utilisateur et validée explicitement avant d'être exécutée sur l'archive. Cette règle s'applique | |
| 65 | +à l'identique aux RAW et aux JPEG : l'existence d'un fichier maître de l'autre type sous le même | |
| 66 | +nom ne justifie jamais une suppression automatique. | |
| 67 | + | |
| 68 | +**Rationale**: Une archive qui perd des fichiers sans confirmation humaine perd la confiance qui | |
| 69 | +justifie son existence. | |
| 70 | + | |
| 71 | +### 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 | |
| 73 | +du projet) DOIT s'appuyer sur le hash de contenu (SHA-256) comme source de vérité, jamais sur le | |
| 74 | +nom de fichier ou le chemin seuls. L'identifiant pérenne attribué à chaque image relie ses | |
| 75 | +versions dans le temps indépendamment de tout renommage ultérieur. Le nom de fichier identique | |
| 76 | +hors extension sert à apparier un RAW et son JPEG jumeau (même capture), mais ne fait jamais foi | |
| 77 | +seul pour décider qu'un des deux fichiers est superflu. | |
| 78 | + | |
| 79 | +Pour DNG/TIFF/JPEG, ce hash de contenu se décline en deux niveaux à des fins distinctes : le hash | |
| 80 | +fichier entier identifie et dédoublonne comme pour tout autre format, tandis que le hash | |
| 81 | +image-only sert spécifiquement à distinguer une édition légitime de métadonnées d'une anomalie | |
| 82 | +réelle — cf. Principe I pour le détail de ce mécanisme. | |
| 83 | + | |
| 84 | +**Rationale**: Les noms de fichiers changent (renommage à l'import, déplacement entre dossiers de | |
| 85 | +format) ; seul le contenu identifie fiablement une image dans la durée. | |
| 86 | + | |
| 87 | +### IV. Métadonnées ouvertes et embarquées | |
| 88 | +Les métadonnées descriptives, administratives et de droits (légende, mots-clés, personnes, | |
| 89 | +crédit, copyright, licence) DOIVENT s'appuyer sur les standards ouverts IPTC/XMP embarqués dans | |
| 90 | +le fichier, complétés par les données techniques EXIF. Régine ne DOIT PAS faire dépendre ces | |
| 91 | +informations d'une base de données propriétaire séparée du fichier. | |
| 92 | + | |
| 93 | +**Rationale**: Des métadonnées embarquées dans le fichier survivent aux copies, aux transferts et | |
| 94 | +à un éventuel changement d'outil ou d'application ; une base séparée ne le garantit pas. | |
| 95 | + | |
| 96 | +### V. L'utilisateur décide, Régine suggère | |
| 97 | +Toute détection automatique à caractère ambigu ou irréversible — découpage d'un import en | |
| 98 | +plusieurs projets, mise en avant d'un événement dans une plage de dates, association RAW+JPEG en | |
| 99 | +cas de collision — DOIT être présentée comme suggestion modifiable, jamais appliquée d'autorité. | |
| 100 | +La décision finale revient toujours à l'utilisateur. | |
| 101 | + | |
| 102 | +**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. | |
| 104 | + | |
| 105 | +## Contraintes techniques | |
| 106 | + | |
| 107 | +- **CLI-first** : chaque fonctionnalité DOIT être exposée via une interface en ligne de commande | |
| 108 | + avant toute interface graphique éventuelle, avec un protocole texte in/out (arguments/stdin → | |
| 109 | + stdout, erreurs → stderr). | |
| 110 | +- **Formats ouverts et documentés** : Régine privilégie systématiquement les formats ouverts et | |
| 111 | + documentés (RAW documentés, TIFF) aux formats propriétaires ou peu utilisés (ex. BMP), avec une | |
| 112 | + migration planifiée quand un format devient obsolète. | |
| 113 | +- **Vérification d'intégrité systématique** : toute copie de fichier (import carte mémoire, | |
| 114 | + checkout, réarchivage) DOIT être vérifiée par checksum avant que la source ne soit considérée | |
| 115 | + comme sûre à effacer ou que la destination ne soit considérée comme fiable. | |
| 116 | +- **Vérification périodique indépendante du checkout (scrub)** : la vérification faite à chaque | |
| 117 | + checkout/réarchivage ne couvre pas une corruption survenant pendant que l'archive dort sur le | |
| 118 | + NAS sans qu'on y touche (bit rot). Régine DOIT prévoir une tâche de vérification périodique (ex. | |
| 119 | + mensuelle) qui recalcule et compare les hash de l'archive, indépendamment de tout checkout. | |
| 120 | +- **Détection ne vaut pas réparation** : un hash, quel qu'il soit (fichier entier ou image-only), | |
| 121 | + détecte une corruption, il ne la répare jamais. La récupération DOIT reposer sur une copie saine | |
| 122 | + (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. | |
| 124 | +- **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. | |
| 126 | + | |
| 127 | +## Workflow d'archivage | |
| 128 | + | |
| 129 | +- **Séparation checkout / travail local / réconciliation** : Régine ne modifie jamais l'archive | |
| 130 | + directement pendant une phase d'édition. L'archive n'est mise à jour qu'après une réconciliation | |
| 131 | + 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 | |
| 133 | + 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, | |
| 135 | + 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 | |
| 137 | + (`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. | |
| 139 | + | |
| 140 | +## Governance | |
| 141 | + | |
| 142 | +Cette constitution prévaut sur toute pratique de développement ponctuelle ou préférence | |
| 143 | +individuelle. Toute spécification (`/speckit-specify`), tout plan (`/speckit-plan`) et toute tâche | |
| 144 | +(`/speckit-tasks`) DOIT être conforme à ces principes avant d'être implémenté. | |
| 145 | + | |
| 146 | +Toute complexité d'implémentation qui contredit un principe DOIT être justifiée explicitement dans | |
| 147 | +le plan correspondant ; à défaut, le plan DOIT être simplifié pour s'y conformer. | |
| 148 | + | |
| 149 | +Les amendements à cette constitution suivent le versionnage sémantique : | |
| 150 | +- **MAJOR** : suppression ou redéfinition incompatible d'un principe existant. | |
| 151 | +- **MINOR** : ajout d'un principe ou d'une section, ou renforcement matériel d'une exigence. | |
| 152 | +- **PATCH** : clarification, reformulation, correction sans changement de sens. | |
| 153 | + | |
| 154 | +Chaque amendement DOIT inclure un rapport d'impact de synchronisation (Sync Impact Report) en | |
| 155 | +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. | |
| 157 | + | |
| 158 | +**Version**: 2.1.0 | **Ratified**: 2026-09-09 | **Last Amended**: 2026-09-11 | |
| new file mode 100644 | |||
| @@ -0,0 +1,158 @@ | |||
| 1 | +<!-- | ||
| 2 | +Sync Impact Report | ||
| 3 | +Version change: 2.0.0 → 2.1.0 (renforcement matériel d'exigences existantes, périmètre des | ||
| 4 | + principes inchangé) | ||
| 5 | +Modified principles: I. Fichier maître intouchable — précision du mécanisme de détection d'une | ||
| 6 | + modification : hash fichier entier pour les RAW propriétaires, hash image-only requis en | ||
| 7 | + complément pour DNG/TIFF/JPEG (les outils d'édition courants peuvent légitimement réécrire les | ||
| 8 | + métadonnées de ces formats directement dans le fichier). III. Identité par contenu, jamais par | ||
| 9 | + nom de fichier seul — renvoi ajouté vers cette distinction à deux niveaux pour éviter toute | ||
| 10 | + lecture contradictoire avec le hash unique mentionné au principe. | ||
| 11 | +Added sections: aucune (ajout de deux exigences dans « Contraintes techniques » : vérification | ||
| 12 | + périodique indépendante du checkout / scrub, et distinction détection vs réparation) | ||
| 13 | +Removed sections: aucune | ||
| 14 | +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 | ||
| 16 | + prochain /speckit-plan. | ||
| 17 | +Deferred TODOs: aucun | ||
| 18 | +--> | ||
| 19 | +# Constitution du projet Régine | ||
| 20 | + | ||
| 21 | +## Core Principles | ||
| 22 | + | ||
| 23 | +### 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 | ||
| 25 | +de l'appareil photo — que ce JPEG soit la seule capture (mode JPEG seul) ou qu'il forme un couple | ||
| 26 | +RAW+JPEG avec un RAW du même nom. Aucun fichier maître n'est modifié une fois entré dans | ||
| 27 | +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 | ||
| 29 | +anomalie et ne DOIT JAMAIS être réarchivée silencieusement. | ||
| 30 | + | ||
| 31 | +Un JPEG issu de l'appareil n'est jamais un simple dérivé jetable du RAW : certaines captures | ||
| 32 | +n'existent qu'en JPEG (pas de RAW correspondant, photo par ailleurs précieuse) et sont donc | ||
| 33 | +irremplaçables ; et même quand un RAW existe, le JPEG de la même capture (même nom de fichier hors | ||
| 34 | +extension) est une version distincte de la photo, pas une copie de secours du RAW. Régine ne DOIT | ||
| 35 | +JAMAIS supprimer ou modifier un JPEG au seul prétexte qu'un RAW du même nom existe dans l'archive, | ||
| 36 | +et réciproquement. Seuls les dérivés créés par l'utilisateur après capture (exports web, | ||
| 37 | +retouches enregistrées à part, sidecars XMP/DOP) peuvent être créés ou modifiés librement. | ||
| 38 | + | ||
| 39 | +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 | ||
| 41 | +par les outils d'édition courants (Lightroom Classic, DxO PhotoLab — réglages et métadonnées vont | ||
| 42 | +systématiquement en sidecar séparé), un hash du fichier entier suffit : tout changement de hash | ||
| 43 | +est une anomalie réelle. Pour le DNG et pour les masters TIFF/JPEG (scans, ou JPEG promu à la | ||
| 44 | +racine du projet), ces mêmes outils écrivent légitimement les métadonnées et réglages directement | ||
| 45 | +dans le fichier, sans sidecar — un hash du fichier entier y change donc à chaque édition de | ||
| 46 | +métadonnées sans qu'il y ait ni corruption ni altération des pixels. Pour ces formats, Régine DOIT | ||
| 47 | +fonder la détection d'anomalie sur un hash portant uniquement sur les données image (pixels), | ||
| 48 | +stable à travers les éditions de métadonnées, en complément du hash fichier entier — jamais sur le | ||
| 49 | +hash fichier entier seul, sous peine de signaler à tort chaque édition de métadonnées comme une | ||
| 50 | +anomalie et d'éroder la confiance dans les signalements réels. | ||
| 51 | + | ||
| 52 | +**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 | ||
| 54 | +parfois le mode JPEG seul. Traiter le JPEG comme un simple dérivé jetable du RAW risquerait de | ||
| 55 | +faire perdre des photos qui n'ont aucune autre copie. Quant au hash image-only pour DNG/TIFF/JPEG, | ||
| 56 | +il découle du même comportement vérifié (2026-09-11, Lightroom Classic et DxO PhotoLab) : sans | ||
| 57 | +lui, chaque édition légitime de métadonnées sur ces formats déclencherait une fausse alerte, ce qui | ||
| 58 | +pousserait à terme à ignorer les signalements — l'exact inverse de l'objectif de ce principe. | ||
| 59 | + | ||
| 60 | +### II. Confirmation explicite avant toute action destructive | ||
| 61 | +Aucune suppression de fichier dans l'archive n'est automatique. Qu'elle provienne d'une anomalie | ||
| 62 | +de réconciliation (fichier absent de la copie de travail) ou d'un déchet identifié à l'import | ||
| 63 | +(test d'exposition, déclenchement accidentel), la suppression DOIT toujours être présentée à | ||
| 64 | +l'utilisateur et validée explicitement avant d'être exécutée sur l'archive. Cette règle s'applique | ||
| 65 | +à l'identique aux RAW et aux JPEG : l'existence d'un fichier maître de l'autre type sous le même | ||
| 66 | +nom ne justifie jamais une suppression automatique. | ||
| 67 | + | ||
| 68 | +**Rationale**: Une archive qui perd des fichiers sans confirmation humaine perd la confiance qui | ||
| 69 | +justifie son existence. | ||
| 70 | + | ||
| 71 | +### 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 | ||
| 73 | +du projet) DOIT s'appuyer sur le hash de contenu (SHA-256) comme source de vérité, jamais sur le | ||
| 74 | +nom de fichier ou le chemin seuls. L'identifiant pérenne attribué à chaque image relie ses | ||
| 75 | +versions dans le temps indépendamment de tout renommage ultérieur. Le nom de fichier identique | ||
| 76 | +hors extension sert à apparier un RAW et son JPEG jumeau (même capture), mais ne fait jamais foi | ||
| 77 | +seul pour décider qu'un des deux fichiers est superflu. | ||
| 78 | + | ||
| 79 | +Pour DNG/TIFF/JPEG, ce hash de contenu se décline en deux niveaux à des fins distinctes : le hash | ||
| 80 | +fichier entier identifie et dédoublonne comme pour tout autre format, tandis que le hash | ||
| 81 | +image-only sert spécifiquement à distinguer une édition légitime de métadonnées d'une anomalie | ||
| 82 | +réelle — cf. Principe I pour le détail de ce mécanisme. | ||
| 83 | + | ||
| 84 | +**Rationale**: Les noms de fichiers changent (renommage à l'import, déplacement entre dossiers de | ||
| 85 | +format) ; seul le contenu identifie fiablement une image dans la durée. | ||
| 86 | + | ||
| 87 | +### IV. Métadonnées ouvertes et embarquées | ||
| 88 | +Les métadonnées descriptives, administratives et de droits (légende, mots-clés, personnes, | ||
| 89 | +crédit, copyright, licence) DOIVENT s'appuyer sur les standards ouverts IPTC/XMP embarqués dans | ||
| 90 | +le fichier, complétés par les données techniques EXIF. Régine ne DOIT PAS faire dépendre ces | ||
| 91 | +informations d'une base de données propriétaire séparée du fichier. | ||
| 92 | + | ||
| 93 | +**Rationale**: Des métadonnées embarquées dans le fichier survivent aux copies, aux transferts et | ||
| 94 | +à un éventuel changement d'outil ou d'application ; une base séparée ne le garantit pas. | ||
| 95 | + | ||
| 96 | +### V. L'utilisateur décide, Régine suggère | ||
| 97 | +Toute détection automatique à caractère ambigu ou irréversible — découpage d'un import en | ||
| 98 | +plusieurs projets, mise en avant d'un événement dans une plage de dates, association RAW+JPEG en | ||
| 99 | +cas de collision — DOIT être présentée comme suggestion modifiable, jamais appliquée d'autorité. | ||
| 100 | +La décision finale revient toujours à l'utilisateur. | ||
| 101 | + | ||
| 102 | +**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. | ||
| 104 | + | ||
| 105 | +## Contraintes techniques | ||
| 106 | + | ||
| 107 | +- **CLI-first** : chaque fonctionnalité DOIT être exposée via une interface en ligne de commande | ||
| 108 | + avant toute interface graphique éventuelle, avec un protocole texte in/out (arguments/stdin → | ||
| 109 | + stdout, erreurs → stderr). | ||
| 110 | +- **Formats ouverts et documentés** : Régine privilégie systématiquement les formats ouverts et | ||
| 111 | + documentés (RAW documentés, TIFF) aux formats propriétaires ou peu utilisés (ex. BMP), avec une | ||
| 112 | + migration planifiée quand un format devient obsolète. | ||
| 113 | +- **Vérification d'intégrité systématique** : toute copie de fichier (import carte mémoire, | ||
| 114 | + checkout, réarchivage) DOIT être vérifiée par checksum avant que la source ne soit considérée | ||
| 115 | + comme sûre à effacer ou que la destination ne soit considérée comme fiable. | ||
| 116 | +- **Vérification périodique indépendante du checkout (scrub)** : la vérification faite à chaque | ||
| 117 | + checkout/réarchivage ne couvre pas une corruption survenant pendant que l'archive dort sur le | ||
| 118 | + NAS sans qu'on y touche (bit rot). Régine DOIT prévoir une tâche de vérification périodique (ex. | ||
| 119 | + mensuelle) qui recalcule et compare les hash de l'archive, indépendamment de tout checkout. | ||
| 120 | +- **Détection ne vaut pas réparation** : un hash, quel qu'il soit (fichier entier ou image-only), | ||
| 121 | + détecte une corruption, il ne la répare jamais. La récupération DOIT reposer sur une copie saine | ||
| 122 | + (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. | ||
| 124 | +- **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. | ||
| 126 | + | ||
| 127 | +## Workflow d'archivage | ||
| 128 | + | ||
| 129 | +- **Séparation checkout / travail local / réconciliation** : Régine ne modifie jamais l'archive | ||
| 130 | + directement pendant une phase d'édition. L'archive n'est mise à jour qu'après une réconciliation | ||
| 131 | + 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 | ||
| 133 | + 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, | ||
| 135 | + 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 | ||
| 137 | + (`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. | ||
| 139 | + | ||
| 140 | +## Governance | ||
| 141 | + | ||
| 142 | +Cette constitution prévaut sur toute pratique de développement ponctuelle ou préférence | ||
| 143 | +individuelle. Toute spécification (`/speckit-specify`), tout plan (`/speckit-plan`) et toute tâche | ||
| 144 | +(`/speckit-tasks`) DOIT être conforme à ces principes avant d'être implémenté. | ||
| 145 | + | ||
| 146 | +Toute complexité d'implémentation qui contredit un principe DOIT être justifiée explicitement dans | ||
| 147 | +le plan correspondant ; à défaut, le plan DOIT être simplifié pour s'y conformer. | ||
| 148 | + | ||
| 149 | +Les amendements à cette constitution suivent le versionnage sémantique : | ||
| 150 | +- **MAJOR** : suppression ou redéfinition incompatible d'un principe existant. | ||
| 151 | +- **MINOR** : ajout d'un principe ou d'une section, ou renforcement matériel d'une exigence. | ||
| 152 | +- **PATCH** : clarification, reformulation, correction sans changement de sens. | ||
| 153 | + | ||
| 154 | +Chaque amendement DOIT inclure un rapport d'impact de synchronisation (Sync Impact Report) en | ||
| 155 | +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. | ||
| 157 | + | ||
| 158 | +**Version**: 2.1.0 | **Ratified**: 2026-09-09 | **Last Amended**: 2026-09-11 | ||