rickub
fonzarely/regine-photos-archiverpublic⑂ Fork 0
⑂ b3c7a08
Branches
main View all branches → View all tags →
Commits
⬇ Clone ▾
git clone https://git.rickub.com/fonzarely/regine-photos-archiver.git
git clone ssh://git@rickub.com/fonzarely/regine-photos-archiver.git

Host key fingerprint (ed25519): SHA256:iycHnxEyq0Q7uyVpB7JlznP0G7JrTPXLYRcAU5CSLhc — verify it before your first connect.

Constitution

Fabien Champigny committed 2026-09-10T00:44:00+02:00 Browse files
b3c7a08 parent: 8e7f842
modified .gitignore +1 -0
@@ -1 +1,2 @@
11 .claude/
2+.DS_Store
@@ -1 +1,2 @@
1 .claude/1 .claude/
2+.DS_Store
modified .specify/memory/constitution.md +91 -35
@@ -1,50 +1,106 @@
1-# [PROJECT_NAME] Constitution
2-<!-- Example: Spec Constitution, TaskFlow Constitution, etc. -->
1+<!--
2+Sync Impact Report
3+Version change: [TEMPLATE] → 1.0.0 (ratification initiale)
4+Modified principles: aucun (première rédaction)
5+Added principles: I. Fichier maître intouchable, II. Confirmation explicite avant toute action destructive, III. Identité par contenu jamais par nom de fichier seul, IV. Métadonnées ouvertes et embarquées, V. L'utilisateur décide, Régine suggère
6+Added sections: Contraintes techniques, Workflow d'archivage, Governance (contenu)
7+Removed sections: aucune
8+Templates requiring follow-up: aucun contrôle croisé effectué sur plan-template.md / spec-template.md / tasks-template.md dans cette exécution — à vérifier manuellement lors du prochain /speckit-plan.
9+Deferred TODOs: aucun
10+-->
11+# Constitution du projet Régine
312
413 ## Core Principles
514
6-### [PRINCIPLE_1_NAME]
7-<!-- Example: I. Library-First -->
8-[PRINCIPLE_1_DESCRIPTION]
9-<!-- Example: Every feature starts as a standalone library; Libraries must be self-contained, independently testable, documented; Clear purpose required - no organizational-only libraries -->
15+### I. Fichier maître intouchable
16+Les fichiers maîtres (RAW, TIFF, BMP — capturés par l'appareil ou issus d'un scan) ne sont jamais
17+modifiés une fois entrés dans l'archive. Toute modification détectée sur un fichier maître par
18+rapport au manifeste de référence (hash SHA-256, cf. workflow de réconciliation) DOIT être
19+signalée à l'utilisateur comme anomalie et ne DOIT JAMAIS être réarchivée silencieusement. Seuls
20+les dérivés (JPEG, exports, sidecars XMP/DOP) peuvent être créés ou modifiés librement.
1021
11-### [PRINCIPLE_2_NAME]
12-<!-- Example: II. CLI Interface -->
13-[PRINCIPLE_2_DESCRIPTION]
14-<!-- Example: Every library exposes functionality via CLI; Text in/out protocol: stdin/args → stdout, errors → stderr; Support JSON + human-readable formats -->
22+**Rationale**: L'intégrité du fichier maître est le socle de toute pratique d'archivage
23+professionnelle (négatif original, planche-contact, tirage) ; la perdre rend l'archive non
24+fiable, même si elle reste volumineuse.
1525
16-### [PRINCIPLE_3_NAME]
17-<!-- Example: III. Test-First (NON-NEGOTIABLE) -->
18-[PRINCIPLE_3_DESCRIPTION]
19-<!-- Example: TDD mandatory: Tests written → User approved → Tests fail → Then implement; Red-Green-Refactor cycle strictly enforced -->
26+### II. Confirmation explicite avant toute action destructive
27+Aucune suppression de fichier dans l'archive n'est automatique. Qu'elle provienne d'une anomalie
28+de réconciliation (fichier absent de la copie de travail) ou d'un déchet identifié à l'import
29+(test d'exposition, déclenchement accidentel), la suppression DOIT toujours être présentée à
30+l'utilisateur et validée explicitement avant d'être exécutée sur l'archive.
2031
21-### [PRINCIPLE_4_NAME]
22-<!-- Example: IV. Integration Testing -->
23-[PRINCIPLE_4_DESCRIPTION]
24-<!-- Example: Focus areas requiring integration tests: New library contract tests, Contract changes, Inter-service communication, Shared schemas -->
32+**Rationale**: Une archive qui perd des fichiers sans confirmation humaine perd la confiance qui
33+justifie son existence.
2534
26-### [PRINCIPLE_5_NAME]
27-<!-- Example: V. Observability, VI. Versioning & Breaking Changes, VII. Simplicity -->
28-[PRINCIPLE_5_DESCRIPTION]
29-<!-- Example: Text I/O ensures debuggability; Structured logging required; Or: MAJOR.MINOR.BUILD format; Or: Start simple, YAGNI principles -->
35+### III. Identité par contenu, jamais par nom de fichier seul
36+La détection des renommages, déplacements, doublons et promotions (ex. capture promue à la racine
37+du projet) DOIT s'appuyer sur le hash de contenu (SHA-256) comme source de vérité, jamais sur le
38+nom de fichier ou le chemin seuls. L'identifiant pérenne attribué à chaque image relie ses
39+versions dans le temps indépendamment de tout renommage ultérieur.
3040
31-## [SECTION_2_NAME]
32-<!-- Example: Additional Constraints, Security Requirements, Performance Standards, etc. -->
41+**Rationale**: Les noms de fichiers changent (renommage à l'import, déplacement entre dossiers de
42+format) ; seul le contenu identifie fiablement une image dans la durée.
3343
34-[SECTION_2_CONTENT]
35-<!-- Example: Technology stack requirements, compliance standards, deployment policies, etc. -->
44+### IV. Métadonnées ouvertes et embarquées
45+Les métadonnées descriptives, administratives et de droits (légende, mots-clés, personnes,
46+crédit, copyright, licence) DOIVENT s'appuyer sur les standards ouverts IPTC/XMP embarqués dans
47+le fichier, complétés par les données techniques EXIF. Régine ne DOIT PAS faire dépendre ces
48+informations d'une base de données propriétaire séparée du fichier.
3649
37-## [SECTION_3_NAME]
38-<!-- Example: Development Workflow, Review Process, Quality Gates, etc. -->
50+**Rationale**: Des métadonnées embarquées dans le fichier survivent aux copies, aux transferts et
51+à un éventuel changement d'outil ou d'application ; une base séparée ne le garantit pas.
3952
40-[SECTION_3_CONTENT]
41-<!-- Example: Code review requirements, testing gates, deployment approval process, etc. -->
53+### V. L'utilisateur décide, Régine suggère
54+Toute détection automatique à caractère ambigu ou irréversible — découpage d'un import en
55+plusieurs projets, mise en avant d'un événement dans une plage de dates, association RAW+JPEG en
56+cas de collision — DOIT être présentée comme suggestion modifiable, jamais appliquée d'autorité.
57+La décision finale revient toujours à l'utilisateur.
58+
59+**Rationale**: Une détection automatique basée sur des horodatages ou des heuristiques n'est
60+jamais assez fiable pour décider seule d'une réorganisation qui touche l'archive.
61+
62+## Contraintes techniques
63+
64+- **CLI-first** : chaque fonctionnalité DOIT être exposée via une interface en ligne de commande
65+ avant toute interface graphique éventuelle, avec un protocole texte in/out (arguments/stdin →
66+ stdout, erreurs → stderr).
67+- **Formats ouverts et documentés** : Régine privilégie systématiquement les formats ouverts et
68+ documentés (RAW documentés, TIFF) aux formats propriétaires ou peu utilisés (ex. BMP), avec une
69+ migration planifiée quand un format devient obsolète.
70+- **Vérification d'intégrité systématique** : toute copie de fichier (import carte mémoire,
71+ checkout, réarchivage) DOIT être vérifiée par checksum avant que la source ne soit considérée
72+ comme sûre à effacer ou que la destination ne soit considérée comme fiable.
73+- **Règle 3-2-1 comme référence** : toute fonctionnalité de sauvegarde ou d'export s'inscrit dans
74+ la logique d'au moins 3 copies, sur 2 types de support différents, dont 1 hors site.
75+
76+## Workflow d'archivage
77+
78+- **Séparation checkout / travail local / réconciliation** : Régine ne modifie jamais l'archive
79+ directement pendant une phase d'édition. L'archive n'est mise à jour qu'après une réconciliation
80+ explicite, par hash, entre le manifeste de référence pris au checkout et l'état de la copie de
81+ travail.
82+- **Verrouillage de projet** : un projet « checké out » DOIT être marqué comme tel côté archive,
83+ pour empêcher que deux instances ou deux personnes modifient la même archive en parallèle.
84+- **Traçabilité humaine hors application** : la convention de nommage lisible
85+ (`date_titre_nomOrigine`) est maintenue en complément de l'identifiant pérenne, pour que
86+ l'archive reste compréhensible même ouverte dans dix ans sans Régine.
4287
4388 ## Governance
44-<!-- Example: Constitution supersedes all other practices; Amendments require documentation, approval, migration plan -->
4589
46-[GOVERNANCE_RULES]
47-<!-- Example: All PRs/reviews must verify compliance; Complexity must be justified; Use [GUIDANCE_FILE] for runtime development guidance -->
90+Cette constitution prévaut sur toute pratique de développement ponctuelle ou préférence
91+individuelle. Toute spécification (`/speckit-specify`), tout plan (`/speckit-plan`) et toute tâche
92+(`/speckit-tasks`) DOIT être conforme à ces principes avant d'être implémenté.
93+
94+Toute complexité d'implémentation qui contredit un principe DOIT être justifiée explicitement dans
95+le plan correspondant ; à défaut, le plan DOIT être simplifié pour s'y conformer.
96+
97+Les amendements à cette constitution suivent le versionnage sémantique :
98+- **MAJOR** : suppression ou redéfinition incompatible d'un principe existant.
99+- **MINOR** : ajout d'un principe ou d'une section, ou renforcement matériel d'une exigence.
100+- **PATCH** : clarification, reformulation, correction sans changement de sens.
101+
102+Chaque amendement DOIT inclure un rapport d'impact de synchronisation (Sync Impact Report) en
103+commentaire en tête du fichier, listant la version précédente, la nouvelle version, et les
104+sections modifiées, ajoutées ou supprimées.
48105
49-**Version**: [CONSTITUTION_VERSION] | **Ratified**: [RATIFICATION_DATE] | **Last Amended**: [LAST_AMENDED_DATE]
50-<!-- Example: Version: 2.1.1 | Ratified: 2025-06-13 | Last Amended: 2025-07-16 -->
106+**Version**: 1.0.0 | **Ratified**: 2026-09-09 | **Last Amended**: 2026-09-09
@@ -1,50 +1,106 @@
1-# [PROJECT_NAME] Constitution1+<!--
2-<!-- Example: Spec Constitution, TaskFlow Constitution, etc. -->2+Sync Impact Report
3+Version change: [TEMPLATE] → 1.0.0 (ratification initiale)
4+Modified principles: aucun (première rédaction)
5+Added principles: I. Fichier maître intouchable, II. Confirmation explicite avant toute action destructive, III. Identité par contenu jamais par nom de fichier seul, IV. Métadonnées ouvertes et embarquées, V. L'utilisateur décide, Régine suggère
6+Added sections: Contraintes techniques, Workflow d'archivage, Governance (contenu)
7+Removed sections: aucune
8+Templates requiring follow-up: aucun contrôle croisé effectué sur plan-template.md / spec-template.md / tasks-template.md dans cette exécution — à vérifier manuellement lors du prochain /speckit-plan.
9+Deferred TODOs: aucun
10+-->
11+# Constitution du projet Régine
3 12
4 ## Core Principles13 ## Core Principles
5 14
6-### [PRINCIPLE_1_NAME]15+### I. Fichier maître intouchable
7-<!-- Example: I. Library-First -->16+Les fichiers maîtres (RAW, TIFF, BMP — capturés par l'appareil ou issus d'un scan) ne sont jamais
8-[PRINCIPLE_1_DESCRIPTION]17+modifiés une fois entrés dans l'archive. Toute modification détectée sur un fichier maître par
9-<!-- Example: Every feature starts as a standalone library; Libraries must be self-contained, independently testable, documented; Clear purpose required - no organizational-only libraries -->18+rapport au manifeste de référence (hash SHA-256, cf. workflow de réconciliation) DOIT être
19+signalée à l'utilisateur comme anomalie et ne DOIT JAMAIS être réarchivée silencieusement. Seuls
20+les dérivés (JPEG, exports, sidecars XMP/DOP) peuvent être créés ou modifiés librement.
10 21
11-### [PRINCIPLE_2_NAME]22+**Rationale**: L'intégrité du fichier maître est le socle de toute pratique d'archivage
12-<!-- Example: II. CLI Interface -->23+professionnelle (négatif original, planche-contact, tirage) ; la perdre rend l'archive non
13-[PRINCIPLE_2_DESCRIPTION]24+fiable, même si elle reste volumineuse.
14-<!-- Example: Every library exposes functionality via CLI; Text in/out protocol: stdin/args → stdout, errors → stderr; Support JSON + human-readable formats -->
15 25
16-### [PRINCIPLE_3_NAME]26+### II. Confirmation explicite avant toute action destructive
17-<!-- Example: III. Test-First (NON-NEGOTIABLE) -->27+Aucune suppression de fichier dans l'archive n'est automatique. Qu'elle provienne d'une anomalie
18-[PRINCIPLE_3_DESCRIPTION]28+de réconciliation (fichier absent de la copie de travail) ou d'un déchet identifié à l'import
19-<!-- Example: TDD mandatory: Tests written → User approved → Tests fail → Then implement; Red-Green-Refactor cycle strictly enforced -->29+(test d'exposition, déclenchement accidentel), la suppression DOIT toujours être présentée à
30+l'utilisateur et validée explicitement avant d'être exécutée sur l'archive.
20 31
21-### [PRINCIPLE_4_NAME]32+**Rationale**: Une archive qui perd des fichiers sans confirmation humaine perd la confiance qui
22-<!-- Example: IV. Integration Testing -->33+justifie son existence.
23-[PRINCIPLE_4_DESCRIPTION]
24-<!-- Example: Focus areas requiring integration tests: New library contract tests, Contract changes, Inter-service communication, Shared schemas -->
25 34
26-### [PRINCIPLE_5_NAME]35+### III. Identité par contenu, jamais par nom de fichier seul
27-<!-- Example: V. Observability, VI. Versioning & Breaking Changes, VII. Simplicity -->36+La détection des renommages, déplacements, doublons et promotions (ex. capture promue à la racine
28-[PRINCIPLE_5_DESCRIPTION]37+du projet) DOIT s'appuyer sur le hash de contenu (SHA-256) comme source de vérité, jamais sur le
29-<!-- Example: Text I/O ensures debuggability; Structured logging required; Or: MAJOR.MINOR.BUILD format; Or: Start simple, YAGNI principles -->38+nom de fichier ou le chemin seuls. L'identifiant pérenne attribué à chaque image relie ses
39+versions dans le temps indépendamment de tout renommage ultérieur.
30 40
31-## [SECTION_2_NAME]41+**Rationale**: Les noms de fichiers changent (renommage à l'import, déplacement entre dossiers de
32-<!-- Example: Additional Constraints, Security Requirements, Performance Standards, etc. -->42+format) ; seul le contenu identifie fiablement une image dans la durée.
33 43
34-[SECTION_2_CONTENT]44+### IV. Métadonnées ouvertes et embarquées
35-<!-- Example: Technology stack requirements, compliance standards, deployment policies, etc. -->45+Les métadonnées descriptives, administratives et de droits (légende, mots-clés, personnes,
46+crédit, copyright, licence) DOIVENT s'appuyer sur les standards ouverts IPTC/XMP embarqués dans
47+le fichier, complétés par les données techniques EXIF. Régine ne DOIT PAS faire dépendre ces
48+informations d'une base de données propriétaire séparée du fichier.
36 49
37-## [SECTION_3_NAME]50+**Rationale**: Des métadonnées embarquées dans le fichier survivent aux copies, aux transferts et
38-<!-- Example: Development Workflow, Review Process, Quality Gates, etc. -->51+à un éventuel changement d'outil ou d'application ; une base séparée ne le garantit pas.
39 52
40-[SECTION_3_CONTENT]53+### V. L'utilisateur décide, Régine suggère
41-<!-- Example: Code review requirements, testing gates, deployment approval process, etc. -->54+Toute détection automatique à caractère ambigu ou irréversible — découpage d'un import en
55+plusieurs projets, mise en avant d'un événement dans une plage de dates, association RAW+JPEG en
56+cas de collision — DOIT être présentée comme suggestion modifiable, jamais appliquée d'autorité.
57+La décision finale revient toujours à l'utilisateur.
58+
59+**Rationale**: Une détection automatique basée sur des horodatages ou des heuristiques n'est
60+jamais assez fiable pour décider seule d'une réorganisation qui touche l'archive.
61+
62+## Contraintes techniques
63+
64+- **CLI-first** : chaque fonctionnalité DOIT être exposée via une interface en ligne de commande
65+ avant toute interface graphique éventuelle, avec un protocole texte in/out (arguments/stdin →
66+ stdout, erreurs → stderr).
67+- **Formats ouverts et documentés** : Régine privilégie systématiquement les formats ouverts et
68+ documentés (RAW documentés, TIFF) aux formats propriétaires ou peu utilisés (ex. BMP), avec une
69+ migration planifiée quand un format devient obsolète.
70+- **Vérification d'intégrité systématique** : toute copie de fichier (import carte mémoire,
71+ checkout, réarchivage) DOIT être vérifiée par checksum avant que la source ne soit considérée
72+ comme sûre à effacer ou que la destination ne soit considérée comme fiable.
73+- **Règle 3-2-1 comme référence** : toute fonctionnalité de sauvegarde ou d'export s'inscrit dans
74+ la logique d'au moins 3 copies, sur 2 types de support différents, dont 1 hors site.
75+
76+## Workflow d'archivage
77+
78+- **Séparation checkout / travail local / réconciliation** : Régine ne modifie jamais l'archive
79+ directement pendant une phase d'édition. L'archive n'est mise à jour qu'après une réconciliation
80+ explicite, par hash, entre le manifeste de référence pris au checkout et l'état de la copie de
81+ travail.
82+- **Verrouillage de projet** : un projet « checké out » DOIT être marqué comme tel côté archive,
83+ pour empêcher que deux instances ou deux personnes modifient la même archive en parallèle.
84+- **Traçabilité humaine hors application** : la convention de nommage lisible
85+ (`date_titre_nomOrigine`) est maintenue en complément de l'identifiant pérenne, pour que
86+ l'archive reste compréhensible même ouverte dans dix ans sans Régine.
42 87
43 ## Governance88 ## Governance
44-<!-- Example: Constitution supersedes all other practices; Amendments require documentation, approval, migration plan -->
45 89
46-[GOVERNANCE_RULES]90+Cette constitution prévaut sur toute pratique de développement ponctuelle ou préférence
47-<!-- Example: All PRs/reviews must verify compliance; Complexity must be justified; Use [GUIDANCE_FILE] for runtime development guidance -->91+individuelle. Toute spécification (`/speckit-specify`), tout plan (`/speckit-plan`) et toute tâche
92+(`/speckit-tasks`) DOIT être conforme à ces principes avant d'être implémenté.
93+
94+Toute complexité d'implémentation qui contredit un principe DOIT être justifiée explicitement dans
95+le plan correspondant ; à défaut, le plan DOIT être simplifié pour s'y conformer.
96+
97+Les amendements à cette constitution suivent le versionnage sémantique :
98+- **MAJOR** : suppression ou redéfinition incompatible d'un principe existant.
99+- **MINOR** : ajout d'un principe ou d'une section, ou renforcement matériel d'une exigence.
100+- **PATCH** : clarification, reformulation, correction sans changement de sens.
101+
102+Chaque amendement DOIT inclure un rapport d'impact de synchronisation (Sync Impact Report) en
103+commentaire en tête du fichier, listant la version précédente, la nouvelle version, et les
104+sections modifiées, ajoutées ou supprimées.
48 105
49-**Version**: [CONSTITUTION_VERSION] | **Ratified**: [RATIFICATION_DATE] | **Last Amended**: [LAST_AMENDED_DATE]106+**Version**: 1.0.0 | **Ratified**: 2026-09-09 | **Last Amended**: 2026-09-09
50-<!-- Example: Version: 2.1.1 | Ratified: 2025-06-13 | Last Amended: 2025-07-16 -->