Comment les archétypes de rôle sont modélisés

La table roles de RPF porte une colonne role_archetype (enum Postgres) avec trois valeurs plus un état NULL explicite. L'enum est ce sur quoi chaque consommateur du catalogue de rôles s'appuie — le badge d'archétype, le filtre de navigation, le sélecteur de cible de différence, la carte du métro (M18.4) et le contexte des chips d'agent.

NULL signifie « pas encore classé ». Les lignes publiées avant M18.3.1 sont NULL jusqu'à ce qu'un administrateur les ouvre dans le builder et choisisse un archétype. Le badge est supprimé pour les lignes NULL.

Chaque rôle peut porter succeeds_role_id, une clé étrangère auto-référencée pointant vers le rôle à partir duquel celui-ci se transforme. La contrainte est posée au niveau de la base de données (db/schema.ts §40-47), avec un index sur (succeeds_role_id) afin que la recherche de cible de différence soit en O(1).

La FK est nullable. Les rôles prêts pour l'avenir n'ont généralement pas de successeur (ils sont la destination) ; les rôles hérités et hybrides pointent généralement vers l'avant vers un successeur prêt pour l'avenir publié. La FK n'impose pas la cohérence de la forme d'archétype — c'est une règle de validation au moment de la publication, pas une contrainte de base de données.

À la publication d'un rôle dont l'archétype est future_ready, RPF valide que chaque item attaché au rôle porte au moins une source citée du registre SMC. La barrière est implémentée dans le chemin de publication des rôles (la PR #217 a livré ceci) — elle retourne une erreur de validation structurée par item-sans-citation, que le builder de rôles rend en ligne à côté de la ligne fautive.

La barrière ne valide pas à l'enregistrement-en-brouillon ni sur les propositions intermédiaires ; seul le chemin final de publication l'applique. Cela garde l'expérience d'autorat fluide : vous pouvez esquisser un rôle prêt pour l'avenir avec des items non cités en brouillon, puis parcourir la liste de citations avant de publier.

Les archétypes hérité et hybride sont exemptés de la barrière. Ils documentent la pratique observée, qui est ancrée dans la surface elle-même plutôt que dans une citation. Si vous voulez quand même citer les items hybrides, l'interface standard des sources citées est toujours disponible — la barrière ne le contraint simplement pas.

• Un rôle avec role_archetype = NULL s'affiche sans badge et est exclu des filtres par archétype sauf si le filtre « non défini » est choisi explicitement. Il est publiable jusqu'à ce qu'un administrateur définisse l'archétype, à quel point la fermeture prêt-pour-l'avenir s'applique rétroactivement.
• Un rôle ne peut pas se succéder à lui-même (succeeds_role_id = id). La FK au niveau base ne l'impose pas ; le validateur du chemin de publication l'attrape.
• Si succeeds_role_id pointe vers un rôle archivé/non publié, le lien de successeur dans l'UI affiche un avertissement « successeur archivé » ; la cible de différence se rabat sur l'override ?vs=.
• Les citations sur les items brouillons ne comptent pas pour la barrière de citations jusqu'à ce que l'item lui-même soit publié ; la barrière s'exécute sur l'ensemble des items publiés du rôle au moment de la publication.
• Basculer l'archétype de hérité → prêt pour l'avenir sur un rôle publié existant réexécute la barrière de citations à la prochaine publication ; les items non cités bloquent le basculement jusqu'à ce qu'ils portent des citations ou que les items soient retirés.

L'enum role_archetype et la FK succeeds_role_id sont au niveau de stabilité bêta. Ajouter un quatrième archétype (par exemple « expérimental ») serait un changement additif d'enum et ne nécessiterait pas de bump majeur ; supprimer ou renommer une valeur existante l'exigerait. Les changements de schéma sont pilotés par le journal (db/migrations/meta/_journal.json) ; les changements de forme seront signalés dans le journal des changements.