# Maison Cadillac — Cahier des charges

## Vision
Application privée de gestion du jardin et de la collection botanique Maison Cadillac, conçue d'abord pour un usage personnel sur iPad/iPhone et pour une collection de 1 500 plantes ou davantage.

Le projet doit rester durable, simple à maintenir et évolutif. Une commercialisation future est possible, mais ne doit pas compliquer inutilement le produit actuel.

## Principes métier
- Une **Variété / Taxon** décrit l'entité botanique (genre, espèce, cultivar, famille, synonymes...).
- Un **Exemplaire / Plante** représente un individu physique du jardin.
- Un exemplaire possède un identifiant permanent, indépendant de son emplacement.
- Une plante peut être déplacée sans changer d'identifiant.
- Les données réelles doivent pouvoir être exportées et sauvegardées indépendamment du thème WordPress.

## Entités principales
1. Variétés
2. Exemplaires
3. Emplacements
4. Fournisseurs
5. Acquisitions
6. Correspondances EAN/Gencode
7. Jardin / garden_id
8. Photos
9. Carte / coordonnées

## Fiche exemplaire
À terme : identifiant permanent, variété, photo principale et galerie, emplacement actuel, fournisseur, date d'acquisition, prix/valeur, EAN, quantité, notes, statut, historique utile et coordonnées de carte.

## Recherche
La recherche globale doit pouvoir retrouver un exemplaire par :
- nom ou repère ;
- identifiant permanent ;
- EAN/Gencode ;
- genre, espèce ou cultivar ;
- nom commun et synonymes ;
- emplacement ;
- fournisseur.

Objectifs concrets : savoir pendant un achat si la variété est déjà possédée ; identifier la plante située devant soi ; retrouver où se trouve une plante achetée auparavant.

## UX
- Priorité iPad/iPhone.
- L'interface Maison Cadillac doit éviter Gutenberg pour les opérations quotidiennes.
- Les formulaires doivent permettre de créer les relations nécessaires sans imposer de préparer manuellement toutes les Variétés/Fournisseurs/Emplacements.
- Le style visuel est provisoire : ne pas figer la direction graphique tant que les fonctions essentielles ne sont pas validées.

## Carte interactive — phase ultérieure
Plan illustré du jardin : maison, piscine, terrasse, serre, pelouses, allées, massifs. Navigation vue générale → zone → plante, recherche avec zoom sur marqueur, popup et fiche, coordonnées relatives X/Y et marqueurs déplaçables.

## QR / étiquettes — phase ultérieure
Une plante physique = un ID permanent = une étiquette. Les QR doivent utiliser une URL stable qui ne dépend pas directement des permaliens WordPress.

## Botanique et IA — phase ultérieure
Prévoir l'intégration future de référentiels botaniques (POWO/Kew, GBIF, WFO, Catalogue of Life) après examen des API/licences. La reconnaissance d'image viendra plus tard et devra être une aide à l'identification/enrichissement, avec confirmation utilisateur, notamment une option « identifier parmi ma collection ».

## Architecture future
Prévoir dès le socle la notion de `garden_id` :
USER → GARDEN → VARIETIES / SPECIMENS / LOCATIONS / ACQUISITIONS / SUPPLIERS / MAP / QR / PHOTOS.

Pour une éventuelle version multi-jardins/SaaS, privilégier une seule application avec séparation stricte par garden_id plutôt qu'un WordPress Multisite au départ.

## Sécurité
HTTPS, contrôles de capacité côté serveur, nonces WordPress, validation/sanitation/escaping systématiques, 2FA côté administration, pas de secrets dans Git, export et sauvegardes. Les données sont privées par défaut ; une publication sélective pourra être ajoutée plus tard.

## Priorités après le socle stable
1. Fiche plante personnalisée sans Gutenberg.
2. Modification et déplacement d'un exemplaire.
3. Création/recherche de variété directement depuis le formulaire plante.
4. Création rapide fournisseur/emplacement.
5. Photo depuis iPad/iPhone.
6. Recherche globale multi-champs.
7. garden_id + migrations versionnées.
8. Identifiant permanent découplé de l'ID de post WordPress avant création des vraies étiquettes.
9. Export/sauvegarde.
10. QR, carte interactive, enrichissement botanique et reconnaissance plus tard.