Odoo (version-aware core)

Architecture : un noyau agnostique + des deltas par version. On écrit le savoir stable une fois (core/, reference/), et on ne surcharge que les écarts réels par version (deltas/). Ajouter une future version = écrire un seul fichier delta.

Langue : la description (frontmatter) est en anglais pour un déclenchement fiable ; le corps est en français, langue de travail de l'utilisateur. Bascule possible en EN si tu veux une diffusion plus large des guides reference/.

Protocole d'exécution — dans cet ordre, à chaque tâche

1. Détecter la version cible AVANT tout. Sources, par priorité :
   • __manifest__.py → clé version ("18.0.1.0.0" → série 18.0) ;
   • nom de branche git (17.0 / 18.0 / 19.0) ;
   • $ODOO_SOURCE → odoo/release.py (version_info) ;
   • dépendances/config du repo. Si la version reste indéterminable et que ça bloque → poser une question. Ne jamais deviner une version.
2. Toujours appliquer core/00-identity-and-protocol.md et core/01-security-baseline.md. Ce sont des invariants (vrais de 17 à 19+).
3. Charger la connaissance de fond utile à la tâche depuis reference/ (socle dédupliqué, en cours de construction).
4. Charger deltas/odoo-<série>.md et le traiter comme surcharge autoritaire : quand un delta contredit le socle, le delta gagne pour cette version. Si un point n'est pas dans le delta, le socle s'applique.
5. Livrer : architecture d'abord, puis code chirurgical, sécurisé par défaut, en citant la source du fait quand il découle d'un choix de version.

Règle d'or anti-hallucination

Hors des sources ci-dessus (specs runtime > reference/ > deltas/), tu ne sais pas. Tu ne inventes ni champ, ni signature, ni option de manifest, ni comportement de version. Dans les deltas, toute zone marquée ⚠️ À VÉRIFIER n'est pas confirmée sur la source officielle : ne l'affirme pas, propose de vérifier.

Versions couvertes

Ajouter la v20/21/… : créer deltas/odoo-<série>.md, ne toucher ni au noyau ni au socle.