Mise à jour du submodule¶

Principe¶

Le kernel évolue par vagues (voir Journal des vagues). Un projet consommateur peut :

Rester figé sur une version : pas de surprise, mais pas de nouveaux skills.
Tirer régulièrement la dernière version : profiter des ajouts, absorber les évolutions de schéma.

Le choix dépend de la maturité du projet. Pendant le cadrage d'un BE critique, la stabilité prime. Entre deux cycles, la mise à jour est opportune.

Procédure standard¶

1. Tirer la dernière version du submodule¶

Depuis la racine du projet consommateur :

git submodule update --remote --merge .sdeg

Effet : .sdeg/ pointe vers le dernier commit de la branche main du kernel.

2. Relancer le bootstrap¶

pwsh .sdeg/scripts/bootstrap.ps1

Effet : les skills, agents, hooks et templates sont mis à jour dans leurs emplacements d'usage (.github/prompts/, .github/agents/, .github/scripts/, .meta/).

3. Valider la cohérence du registre¶

node .sdeg/sdlc/sdlc.js validate

Si un statut ou une porte a été renommé dans schema.js, cette commande le signale immédiatement. Voir plus bas la section « Migration de schéma ».

4. Vérifier les nouvelles portes et skills¶

# Skills ajoutés : comparer
ls .github/prompts/

# Portes et transitions : voir la doc générée
# https://<url-site>/portes/

Lire les notes de la vague correspondante dans Journal des vagues.

5. Commiter la mise à jour¶

git add .sdeg .github .meta
git commit -m "chore: update sdeg-kernel to <sha>"

Migration de schéma¶

Si schema.js a évolué, plusieurs cas :

Cas 1 — Ajout d'une nouvelle transition ou porte¶

Aucune action. Les objets existants ne sont pas impactés. Les nouvelles portes deviennent disponibles pour les futurs objets ou transitions.

Cas 2 — Renommage d'un statut¶

validate signalera « statut inconnu ». Trois options :

Rester sur l'ancienne version du kernel jusqu'à terminer les objets en cours.
Éditer manuellement sdlc-registry.json pour renommer les statuts. ⚠ Passer par un commit dédié hors CLI, avec message chore(sdlc): migration schéma vN→vN+1 et revue attentive.
Clore les objets concernés (move vers un état terminal) avant la mise à jour.

Cas 3 — Changement de préconditions ou checks d'une porte existante¶

Les objets en cours ne sont pas rétro-actifs. Un objet déjà passé par G2 ne re-vérifie pas les nouvelles préconditions de G2. Les nouveaux objets, eux, les verront.

Cas 4 — Suppression d'une porte ou d'un statut¶

Scénario rare. Si cela arrive, les release notes du kernel doivent inclure un script de migration. À défaut, fonctionner en cas 1 ou 3.

Vérification post-mise-à-jour¶

# 1. Le hook git pre-commit est toujours actif
cat .git/hooks/pre-commit

# 2. Tous les scripts PowerShell sont à jour
ls -la .github/scripts/

# 3. Les skills sont tous listés
ls .github/prompts/ | wc -l

# 4. Un move de test (sur un objet sans enjeu) passe bien
node .sdeg/sdlc/sdlc.js status

Rollback¶

Si la mise à jour pose problème :

cd .sdeg
git checkout <ancien-sha>
cd ..
pwsh .sdeg/scripts/bootstrap.ps1
git add .sdeg .github .meta
git commit -m "chore: rollback sdeg-kernel to <ancien-sha>"

Le registre sdlc-registry.json n'est jamais touché par la mise à jour du submodule — seuls les skills, agents et scripts le sont. Un rollback est donc non-destructif sur les données projet.

Fréquence recommandée¶

Contexte	Fréquence
Projet en cadrage intensif	Figer, pas de mise à jour
Projet en rythme de croisière	Mise à jour mensuelle
Entre deux cycles produit	Mise à jour à chaque début de cycle
Mise à jour urgente de sécurité annoncée	Immédiate

Voir aussi : Installation · Journal des vagues · Dépannage.