Branches et propositions

Le schéma d'ontologie est versionné. Il existe une baseline publiée canonique — main — et chaque modification se fait sur une branche de proposition qui est examinée avant d'être fusionnée.

Pourquoi versionner

Le schéma est consommé par les workflows, les agents, la vue graphique, l'analyste et toute interface personnalisée. Un changement de schéma qui casse le type de propriété attendu par un workflow est exactement le type de modification que vous souhaitez voir en révision avant sa mise en production. Les propositions vous offrent cette révision sans ralentir le travail quotidien.

main

main est la baseline publiée. Depuis le plan de travail :

• main apparaît dans le sélecteur de branche comme valeur par défaut.
• main est en lecture seule. Vous pouvez naviguer, rechercher, traverser — vous ne pouvez pas modifier.
• Chaque consommateur (outils de workflow, vue graphique, analyste) lit depuis main par défaut.

Propositions

Une proposition est une branche depuis main avec un nom comme proposal/add-customer-tier ou proposal/rename-account-status. Les propositions peuvent :

• Ajouter de nouveaux types d'objets, types de liens, types d'actions, bindings.
• Modifier des types existants (changer un type de propriété, ajouter une propriété, modifier les règles d'identité).
• Supprimer des types (avec un chemin de migration).
• Mettre à jour les bindings (remapper des colonnes, changer de tables source).

Le plan de travail affiche le diff entre la proposition et main. Un réviseur peut voir exactement quels types ont changé et comment.

Cycle de vie

   ┌─────────┐    proposer    ┌──────────────┐
   │  main   │ ──────────────▶│  proposition │
   └─────────┘                └──────────────┘
        ▲                             │
        │ publier (remplace main)     │ révision
        └─────────────────────────────┘
                                     │
                                     ▼ archiver (abandonnée)
                                  [fin]

Ce que « publier » fait

La publication d'une proposition :

1. Valide la proposition par rapport au main actuel — signale les conflits.
2. Remplace atomiquement la baseline de main par la baseline de la proposition.
3. Réédite le tampon de version sur chaque binding, type d'action et type d'objet.
4. Émet un événement structuré pour les consommateurs en aval.
5. Enregistre un événement d'audit avec l'acteur, la proposition et les modifications publiées.

Après la publication, la branche de proposition est fermée. Les futures modifications repartent depuis le nouveau main.

Ce que « archiver » fait

L'archivage d'une proposition :

1. Marque la proposition comme archivée dans le catalogue.
2. La retire du sélecteur de branches actives.
3. Enregistre un événement d'audit.

Les propositions archivées sont conservées à des fins de conformité mais n'apparaissent pas dans la navigation normale. Elles peuvent être restaurées — utile lorsqu'une proposition a été archivée par erreur.

Modifications simultanées

Plusieurs propositions peuvent être en cours simultanément. L'étape de publication effectue une vérification des conflits — si une deuxième proposition touche un type qu'une première proposition a déjà publié, le réviseur de la deuxième proposition voit le conflit et décide comment le résoudre.

Autorisation

Voir aussi

• Concepts → Branches — où les branches s'inscrivent dans les cinq couches.
• Journalisation des audits — chaque publication et archivage est journalisé.
• SDK d'authoring → Ontologies — les packs se déploient sur main par défaut ; les mises à jour de packs arrivent via des propositions.