PROMPT (LLM-SAFE) — WordPress → SGBD apicole + registre sanitaire immuable (valeur probante)

RÔLE
Tu es un architecte logiciel senior spécialisé WordPress (WP 6+), sécurité, RGPD, systèmes de traçabilité et modélisation de données relationnelles.
Ta mission : produire une conception technique exploitable (architecture + modèle de données + API + règles d’intégrité + tests) pour un plugin WordPress métier.

OBJECTIF
Développer un plugin WordPress (avec thème enfant + widgets Gutenberg) transformant WordPress en SGBD métier apicole.
Le système doit gérer :
1) un registre sanitaire numérique immuable (valeur probante),
2) la gestion ruchers/colonies (NAPI),
3) traitements (médicaments/AMM/lot/dose/dates),
4) observations,
5) sélection génétique (reines F0/F1/F2, lots, généalogie, descendance, tests varroa/hygiène/VSH/SMR),
6) accès institutionnel en lecture (GDSA/GDS par département) via consentement et exports N/N-1/N-2.

CONTRAINTE CRITIQUE (NON NÉGOCIABLE) — IMMUTABILITÉ
- Après validation, une entrée de registre ne doit jamais être modifiée ni supprimée.
- Toute correction passe par un RECTIFICATIF append-only lié à l’entrée originale.
- Le registre doit être conçu comme un journal inviolable (append-only + audit log).
- Chaîne de hash obligatoire : chaque période (ex. mois) forme une séquence chaînée (hash(i)=H(hash(i-1)+payloadCanonique(i))).
- Toute tentative de mise à jour/suppression d’une entrée validée doit échouer au niveau applicatif ET être détectable via audit.

RGPD (NON NÉGOCIABLE)
- Gestion du consentement explicite pour tout partage / extraction institutionnelle.
- Journalisation des accès (qui, quand, quoi, pourquoi, base légale/consentement).
- Minimisation des données exposées.
- Possibilité de révoquer un consentement (sans altérer l’historique des actions déjà réalisées).

INTEROPÉRABILITÉ (NON NÉGOCIABLE)
- API REST + JSON Schemas versionnés.
- Les exports JSON doivent être conformes aux schémas versionnés.
- Les schémas doivent supporter migration et rétro-compatibilité : une donnée ancienne reste lisible et vérifiable.
- Séparer strictement données brutes (enregistrements) et données interprétées (scores, agrégats, analyses) pour éviter la contamination de l’historique probatoire.

RÈGLES ANTI-DÉGRADATION (LLM-SAFE)
NE PAS :
- remplacer des tables custom par des posts/custom post types + postmeta si cela nuit à l’intégrité/performances/audit.
- ignorer les capabilities WordPress (permissions fines).
- proposer une “immutabilité” purement logique sans audit log et sans hash chain.
- omettre la stratégie de canonicalisation des payloads avant hash.
- omettre le plan de tests et critères d’acceptation.
- omettre la stratégie d’export “valeur probante”.

TU DOIS PRODUIRE (FORMAT DE SORTIE IMPOSÉ)
Réponds avec les sections EXACTES ci-dessous, dans cet ordre, avec suffisamment de détail pour démarrer le développement :

1) Vision & périmètre
   - cas d’usage principaux (apiculteur, TSA, GDSA/GDS lecture)
   - hypothèses et limites

2) Modèle de données (tables custom)
   - liste des tables (nom, but)
   - champs essentiels (types)
   - clés primaires/étrangères
   - index nécessaires
   - stratégie de soft-delete : INTERDITE pour le registre validé (expliquer)

3) Mécanisme d’immutabilité
   - workflow brouillon→validation→immuable
   - rectificatifs (structure, lien, règles)
   - audit log append-only (structure)
   - canonicalisation payload (ordre des champs, normalisation dates/nombres/encodage, suppression champs volatiles)
   - hash chain (périodicité, calcul, stockage, vérification, rehash interdit)
   - stratégie de vérification d’intégrité (routine et endpoints)

4) Sécurité & permissions WordPress
   - rôles/capabilities proposées (apiculteur, admin, lecteur GDSA/GDS, etc.)
   - contrôle d’accès aux endpoints
   - protection contre altérations (CSRF, XSS, SQLi, nonce, prepared statements)

5) RGPD & consentements
   - modèle de consentement (données, portée, durée, révocation)
   - journalisation des accès (structure + conservation)
   - minimisation / pseudonymisation côté exports institutionnels

6) API REST & JSON Schemas versionnés
   - liste des endpoints (CRUD brouillons, validation, rectificatifs, exports, vérification hash)
   - versioning (v1/v2…), stratégie de migration
   - exemples d’objets JSON (minimal mais précis)

7) Exports “valeur probante”
   - PDF horodaté (contenu, métadonnées, empreinte hash)
   - JSON export signé/empreinté (méthode)
   - réconciliation : comment prouver qu’un PDF correspond à un JSON et à une entrée du registre

8) UI / UX (Gutenberg widgets + écrans)
   - écrans minimum viables (registre, ruchers, colonies, traitements, sélection)
   - UX anti-erreurs (validation irréversible, avertissements, prévisualisation)

9) Performance & scalabilité
   - volumes attendus, pagination, requêtes
   - stratégie de cache (si applicable) sans casser la valeur probante

10) Plan de tests & critères d’acceptation
   - tests unitaires, intégration, sécurité
   - tests d’intégrité hash chain (altération détectée)
   - tests RGPD (consentement/revocation)
   - critères d’acceptation “go/no-go”

RAPPEL IMPORTANT
- Ne produis pas de code complet ici : produis une conception technique détaillée, des structures, des exemples, et des pseudo-codes si utile.
- Chaque section doit contenir du concret, pas des généralités.