# Agent — Recreate the database

Read `_shared.md` first. There is **no** CLI colocated with this agent —
the two `dotnet ef` invocations are straightforward enough that the agent
runs them directly with the correct parameters.

## Goal

Drop the target database and reapply every migration from scratch. Used in
local development when the schema has drifted too far from the migrations
or when the user wants a clean slate. **Destructive** — the caller (Studio
MigrationsTab) always asks for explicit confirmation before invoking this
agent.

## Refuses to run when

- The connection string points to anything labelled `prod` / `production`
  / `staging`. When in doubt, bail and ask the user.
- Multiple DbContexts resolve to the same physical database (avoid
  dropping Core while Extensions still depends on it).

## Steps

1. Resolve the target DbContext + migration assembly from the spec
   (passed by the MigrationsTab or by the user):
   - `contextName` — e.g. `CoreDbContext`, `ExtensionsDbContext`, `StudioDbContext`.
   - `assembly`    — the migrations project. For the Studio, pick the one
     matching the active provider from `~/.smartstack/config.json`
     (Sqlite / Postgres / SqlServer).
   - `startupProject` — auto-detected (Host / Api / Web) unless overridden.

2. Dump the idempotent SQL script so the user has a record of what will
   run after the drop:

   ```bash
   dotnet ef migrations script --idempotent \
     --project <csproj> \
     --context <contextName> \
     --startup-project <startup> \
     -o recreate-<contextName>.sql
   ```

3. Drop the database:

   ```bash
   dotnet ef database drop --force --no-color \
     --project <csproj> \
     --context <contextName> \
     --startup-project <startup>
   ```

   `--force` skips the interactive confirmation since the caller already
   asked the user.

4. Apply every migration:

   ```bash
   dotnet ef database update --no-color \
     --project <csproj> \
     --context <contextName> \
     --startup-project <startup>
   ```

5. Dual-context apps (Core + Extensions): always `Core` first, then
   `Extensions`. Extensions' FKs reference Core tables.

6. Report: `dropped ✓`, `applied N migrations`, and any seed data the
   user might want to re-run manually.

## What NOT to do

- Never call this against a connection string tagged `prod` or
  `production`. The caller is responsible for checking the environment but
  the agent MUST verify too before running the drop.
- Never run this on a schema shared with another app without also
  dropping that app's contexts — otherwise you leave orphan FKs.
- Never skip the idempotent script. It's the user's only paper trail if
  they lose data in step 3.
