# Nature des ressources — Article / Outil

`Ressource.nature` accepte `article`, `outil` et `NULL` (« À qualifier »).
La nature est facultative en brouillon, obligatoire pour publier. Toute intention
homepage exige `outil`, même pour une ressource dépubliée. Retirer la sélection
homepage permet ensuite de changer la nature en Article. Aucun choix éditorial
n'est retiré automatiquement ; `featured` reste indépendant de la nature.

Les contraintes de l'entité sont actives dans le groupe de validation par défaut.
Le formulaire et les mises à jour AJAX du Cockpit utilisent le même validateur,
y compris la limite de trois intentions homepage, publiées ou non. Les refus de
publication depuis la liste affichent le message et restaurent l'interrupteur.
La homepage sélectionne uniquement les Outils publiés explicitement sélectionnés,
sans remplacement automatique. Catalogue, pages détail et URL restent inchangés.

## Déploiement

1. Sauvegarder la base de l'environnement concerné. Vérifier que la migration
   additive `Version20261002120000` y a été exécutée avant de déployer ce code.
2. Inventorier les ressources de cet environnement : publication sans nature
   valide, nature inconnue même en brouillon, sélection homepage autre qu'Outil,
   plus de trois intentions homepage. Qualifier et arbitrer explicitement avant
   déploiement ; ne jamais recopier des IDs locaux comme correspondance universelle.
3. Prévoir une interruption des écritures éditoriales pour déployer le code et
   appliquer, après validation, `Version20261002130000`. Son précontrôle refuse
   toute anomalie et signale les IDs propres à l'environnement. Les deux triggers
   de limite homepage doivent être présents. Aucun contenu n'est corrigé.
4. La migration ajoute deux triggers de validation à l'insertion et à la mise à
   jour de nature/publication/homepage. Elle emploie `sqlite_master`, des conditions
   simples et `RAISE(ABORT, 'message constant')`, sans reconstruction de table,
   DROP COLUMN, UPDATE FROM, RETURNING ou fonctions PRAGMA tabulaires. Les deux
   triggers de limite homepage, les données, index et relations sont conservés.
5. Vérifier le cache Symfony puis la publication depuis la liste et la fiche,
   les changements de nature, les refus homepage et la dépublication/republication
   d'un Outil sélectionné. Contrôler visuellement les messages dans la liste.

La version exacte SQLite d'OVH doit être vérifiée en préproduction ; les tests
locaux ne prouvent pas une exécution sur OVH. Le retour arrière de la nouvelle
migration retire uniquement ses deux triggers et conserve la qualification et
la limite homepage. Il doit être coordonné avec le code applicatif.

Les migrations existantes restent intactes. Les tests de migration utilisent une
base SQLite en mémoire ; les tests Cockpit utilisent une base temporaire isolée.