celuga-change-schema

Quand : Faire évoluer le schéma Payload/PostgreSQL d’un site create-celuga.

Portée : projet (.agents/skills, déjà livré par create-celuga) · Fichiers : 1

Tout installer

Copier le bloc et le coller dans un terminal. Il recrée tous les fichiers du skill.

dir=".agents/skills/celuga-change-schema"   # depuis la racine du projet
mkdir -p "$dir"
cat > "$dir/SKILL.md" <<'CELUGA_SKILL_EOF'
---
name: celuga-change-schema
description: Faire évoluer le schéma Payload/PostgreSQL d’un projet Celuga avec migration inspectée, conservation des données et recette de restauration.
---

# Modifier le schéma Celuga

Ne lancez jamais une migration contre une base cliente ou distante implicite. Utilisez une base locale jetable et vérifiez la cible affichée avant toute commande.

1. Modifiez la configuration Payload, puis lancez `bun run generate` afin que les types et l’import map décrivent le nouveau modèle. Corrigez les consommateurs typés avant de créer la migration.
2. Créez la migration avec `bun run migrate:create`. Relisez le SQL généré : tables, index, contraintes, valeurs par défaut, versions et champs localisés doivent correspondre au modèle. Remplacez toute perte implicite par une transformation de données explicite ou un arrêt documenté.
3. Si des données existantes doivent être recalculées, rendez l’opération idempotente, conservez brouillons et publications, et n’écrasez aucune traduction. Le second passage doit produire le même état.
4. Vérifiez une base neuve, puis une base représentative existante : migration, génération, lecture des données et répétition du recalcul. Pour une suppression ou transformation irréversible, appliquez auparavant la procédure de sauvegarde et restauration de `docs/DEPLOIEMENT.md`, uniquement sur des cibles locales jetables.
5. `migrate:create` met déjà à jour `apps/cms/src/migrations/index.ts` : relisez cet index. Exécutez les tests ciblés et `bun run verify`. Une option désactivée conserve les mêmes champs persistés ; vérifiez aussi que `migrate:create --skip-empty` ne propose aucun changement pour chaque composition. Le travail est terminé quand le modèle généré, les migrations enregistrées et les données observées concordent.
CELUGA_SKILL_EOF

SKILL.md

SKILL.md

---
name: celuga-change-schema
description: Faire évoluer le schéma Payload/PostgreSQL d’un projet Celuga avec migration inspectée, conservation des données et recette de restauration.
---

# Modifier le schéma Celuga

Ne lancez jamais une migration contre une base cliente ou distante implicite. Utilisez une base locale jetable et vérifiez la cible affichée avant toute commande.

1. Modifiez la configuration Payload, puis lancez `bun run generate` afin que les types et l’import map décrivent le nouveau modèle. Corrigez les consommateurs typés avant de créer la migration.
2. Créez la migration avec `bun run migrate:create`. Relisez le SQL généré : tables, index, contraintes, valeurs par défaut, versions et champs localisés doivent correspondre au modèle. Remplacez toute perte implicite par une transformation de données explicite ou un arrêt documenté.
3. Si des données existantes doivent être recalculées, rendez l’opération idempotente, conservez brouillons et publications, et n’écrasez aucune traduction. Le second passage doit produire le même état.
4. Vérifiez une base neuve, puis une base représentative existante : migration, génération, lecture des données et répétition du recalcul. Pour une suppression ou transformation irréversible, appliquez auparavant la procédure de sauvegarde et restauration de `docs/DEPLOIEMENT.md`, uniquement sur des cibles locales jetables.
5. `migrate:create` met déjà à jour `apps/cms/src/migrations/index.ts` : relisez cet index. Exécutez les tests ciblés et `bun run verify`. Une option désactivée conserve les mêmes champs persistés ; vérifiez aussi que `migrate:create --skip-empty` ne propose aucun changement pour chaque composition. Le travail est terminé quand le modèle généré, les migrations enregistrées et les données observées concordent.