Cette commande applique la regle d'or "1 migration par feature" : chaque branche feature ou hotfix ne doit avoir qu'une seule migration. Si vous modifiez le modele de donnees plusieurs fois pendant le developpement, la commande detecte la migration existante, la supprime, et en cree une nouvelle qui consolide tous les changements. Avant de creer, elle effectue une validation cross-branch pour detecter les conflits potentiels avec d'autres branches actives. Le nom de migration suit un pattern standardise incluant le type de branche, la version, et une description. Cette approche garantit un historique de migrations propre et evite les conflits lors des merges.

This command enforces the "1 migration per feature" golden rule: each feature or hotfix branch should have only one migration. If you modify the data model multiple times during development, the command detects the existing migration, deletes it, and creates a new one that consolidates all changes. Before creating, it performs cross-branch validation to detect potential conflicts with other active branches. The migration name follows a standardized pattern including branch type, version, and description. This approach ensures a clean migration history and prevents conflicts during merges.

Workflow en 9 etapes

9-Step Workflow

Options

# Usage example
/efcore migration

# With options
/efcore migration --force --no-apply

Cette commande de diagnostic rapide (read-only) fournit une vue complete de l'etat des migrations EF Core et de la base de donnees. Elle detecte automatiquement le fichier de configuration (appsettings.Local.json en priorite), teste la connexion a la base, et liste toutes les migrations en distinguant celles appliquees de celles en attente. Elle verifie egalement le respect de la regle "1 migration par feature" en analysant les migrations presentes sur la branche courante. Utilisez cette commande avant toute operation pour connaitre l'etat exact du systeme.

This quick diagnostic command (read-only) provides a complete view of EF Core migrations and database state. It automatically detects the configuration file (appsettings.Local.json as priority), tests database connection, and lists all migrations distinguishing applied from pending ones. It also verifies "1 migration per feature" rule compliance by analyzing migrations present on the current branch. Use this command before any operation to know the exact system state.

Informations affichees

Displayed Information

================================================================================
                         EF CORE - DATABASE STATUS
================================================================================

PROJET
  Nom:           MyApp.Data
  Config:        appsettings.Local.json
  DbContext:     ApplicationDbContext

CONNEXION
  Status:        OK
  Server:        localhost
  Database:      MyAppDb

MIGRATIONS
  Total:         12
  Appliquees:    11
  En attente:    1

REGLE "1 MIGRATION PAR FEATURE"
  Branche:      feature/user-auth
  Migrations:   1 pour cette branche
  Regle respectee

================================================================================

Options

Cette commande applique toutes les migrations en attente sur votre base de donnees locale. Elle utilise le fichier appsettings.Local.json pour obtenir la connection string, verifie d'abord qu'il y a des migrations a appliquer, puis execute dotnet ef database update. Le processus affiche les details SQL en mode verbose pour suivre les modifications appliquees. Cette commande est essentielle apres avoir cree une nouvelle migration ou apres avoir recupere des modifications d'autres developpeurs contenant des migrations.

This command applies all pending migrations to your local database. It uses appsettings.Local.json file to get the connection string, first verifies there are migrations to apply, then executes dotnet ef database update. The process displays SQL details in verbose mode to track applied modifications. This command is essential after creating a new migration or after pulling changes from other developers containing migrations.

Prerequis

Prerequisites

# Deploy migrations
/efcore db-deploy

# Equivalent to:
dotnet ef database update --verbose

Options

Cette commande peuple la base de donnees avec des donnees de test ou initiales pour le developpement local. Elle detecte automatiquement les methodes de seeding disponibles dans le projet : classe Seeder dediee, methode HasData() dans le DbContext, script SQL seed.sql, ou argument CLI --seed. Elle vous propose ensuite de choisir la methode a utiliser. Ideale apres un /efcore db-reset ou pour initialiser un nouvel environnement de developpement avec des donnees coherentes.

This command populates the database with test or initial data for local development. It automatically detects available seeding methods in the project: dedicated Seeder class, HasData() method in DbContext, seed.sql SQL script, or CLI --seed argument. It then offers you to choose which method to use. Ideal after /efcore db-reset or to initialize a new development environment with consistent data.

Methodes de seeding detectees

Detected Seeding Methods

# Execute seeding
/efcore db-seed

# The agent automatically detects available methods
# and offers you a choice

Cette commande destructive remet la base de donnees a zero en la supprimant completement puis en la recreant avec toutes les migrations. Elle est protegee par plusieurs securites : confirmation obligatoire, proposition de backup avant suppression, blocage si l'environnement est detecte comme Production. Apres la recreation, elle propose optionnellement d'executer le seeding. Utilisez cette commande quand vous avez besoin d'un environnement de developpement completement propre, par exemple apres des modifications majeures du schema ou pour tester le processus complet de migrations.

This destructive command resets the database to zero by completely dropping it then recreating it with all migrations. It's protected by several safeguards: mandatory confirmation, backup offer before deletion, blocking if environment is detected as Production. After recreation, it optionally offers to run seeding. Use this command when you need a completely clean development environment, for example after major schema changes or to test the complete migration process.

Protections de securite

Safety Protections

# Complete database reset
/efcore db-reset

# Workflow:
# 1. Mandatory confirmation
# 2. Optional backup (recommended)
# 3. DROP DATABASE
# 4. CREATE DATABASE (via migrations)
# 5. Optional seed

Cette commande read-only scanne tous les worktrees actifs (main, develop, et toutes les branches feature/hotfix) pour cartographier les migrations EF Core presentes. Elle compare chaque ModelSnapshot avec celui de develop pour calculer un niveau de risque : NONE (identique), LOW (tables differentes), MEDIUM (FK vers memes tables), HIGH (meme table modifiee), ou CRITICAL (meme colonne). Le resultat inclut un ordre de merge recommande basant sur ces risques. Executez cette commande avant de commencer une integration pour avoir une vue globale de l'etat des migrations dans l'equipe.

This read-only command scans all active worktrees (main, develop, and all feature/hotfix branches) to map present EF Core migrations. It compares each ModelSnapshot with develop's to calculate a risk level: NONE (identical), LOW (different tables), MEDIUM (FK to same tables), HIGH (same table modified), or CRITICAL (same column). The result includes a recommended merge order based on these risks. Run this command before starting an integration to get a global view of migration state across the team.

Niveaux de risque

Risk Levels

================================================================================
                    EF CORE CROSS-BRANCH SCAN
================================================================================

WORKTREES DETECTES (5)
  main/                    [main]
  develop/                 [develop]
  features/user-auth/      [feature/user-auth]
  features/add-products/   [feature/add-products]
  hotfixes/login-fix/      [hotfix/login-fix]

MIGRATIONS PAR BRANCHE
  develop               | 12 migrations | Snapshot: a1b2c3d4 (REFERENCE)
  feature/user-auth     | 13 migrations | Snapshot: e5f6g7h8
  feature/add-products  | 13 migrations | Snapshot: i9j0k1l2
  hotfix/login-fix      | 12 migrations | Snapshot: a1b2c3d4

ANALYSE DES RISQUES
  feature/user-auth     : LOW      (tables differentes)
  feature/add-products  : MEDIUM   (FK vers meme table)
  hotfix/login-fix      : NONE     (snapshot = develop)

ORDRE DE MERGE RECOMMANDE
  1. hotfix/login-fix      (NONE - merge direct)
  2. feature/user-auth     (LOW - merge OK)
  3. feature/add-products  (MEDIUM - apres user-auth)

================================================================================

Options

Cette commande analyse si la branche courante peut etre mergee dans develop sans conflit de migration EF Core. Elle compare le ModelSnapshot local avec celui de develop et des autres branches actives pour detecter les modifications qui se chevauchent : tables communes modifiees, colonnes identiques ajoutees, ou FK vers les memes entites. Si un conflit HIGH ou CRITICAL est detecte, la commande est BLOQUANTE et retourne un code d'erreur, empechant le merge. Elle recommande alors d'utiliser /efcore rebase-snapshot pour resoudre le conflit avant de continuer.

This command analyzes if the current branch can be merged into develop without EF Core migration conflict. It compares local ModelSnapshot with develop's and other active branches to detect overlapping modifications: common tables modified, identical columns added, or FK to same entities. If a HIGH or CRITICAL conflict is detected, the command is BLOCKING and returns an error code, preventing merge. It then recommends using /efcore rebase-snapshot to resolve the conflict before continuing.

Exit Codes

Exit Codes

# Check conflicts before merge
/efcore conflicts

# If conflict detected:
# → /efcore rebase-snapshot (recommended)
# → /efcore conflicts --force (not recommended)

Options

Cette commande resout les conflits ModelSnapshot detectes par /efcore conflicts en resynchronisant votre branche avec develop. Elle commence par creer un backup automatique de vos migrations, identifie les migrations specifiques a votre branche, remplace le ModelSnapshot par la version de develop, supprime vos migrations de branche, puis regenere une nouvelle migration consolidee qui inclut tous vos changements mais base sur le snapshot actuel de develop. En cas d'echec du build, elle peut restaurer automatiquement depuis le backup. C'est la solution recommandee quand un conflit HIGH est detecte.

This command resolves ModelSnapshot conflicts detected by /efcore conflicts by resynchronizing your branch with develop. It starts by creating an automatic backup of your migrations, identifies branch-specific migrations, replaces ModelSnapshot with develop's version, deletes your branch migrations, then regenerates a new consolidated migration that includes all your changes but based on develop's current snapshot. On build failure, it can automatically restore from backup. This is the recommended solution when a HIGH conflict is detected.

Workflow en 8 etapes

8-Step Workflow

Quand utiliser

When to use

Options

Cette commande destructive consolide toutes les migrations existantes en une seule migration propre pour les releases. Elle est utilisee typiquement avant de creer une release pour avoir un historique de migrations clean en production. Le processus cree un backup complet (migrations + script SQL du schema actuel), supprime toutes les migrations, genere une migration unique representant l'etat final du schema, puis genere un script SQL idempotent. Important : si des migrations sont deja appliquees en production, utilisez le script SQL genere plutot que la nouvelle migration pour eviter les conflits d'historique.

This destructive command consolidates all existing migrations into a single clean migration for releases. It's typically used before creating a release to have a clean migration history in production. The process creates a full backup (migrations + SQL script of current schema), deletes all migrations, generates a single migration representing the final schema state, then generates an idempotent SQL script. Important: if migrations are already applied in production, use the generated SQL script rather than the new migration to avoid history conflicts.

Quand utiliser Squash

When to use Squash

Options