# Agent — Recreate the database

Read `_shared.md` first. Two different lanes in this agent:

- the **drop** is 🔴 (irreversible data loss) AND `ef-guard` blocks a raw
  `dotnet ef database drop` at the shell — so the agent never runs it: it
  hands the exact command to the USER, who runs it themselves (type
  `! <command>` in the prompt to run it in-session);
- the **re-apply** goes through the colocated **`cli/apply/`** (policy-gated,
  bypasses `ef-guard` by design) — never a raw `dotnet ef database update`.

## 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 — **USER-run, never agent-run** (🔴 + blocked by
   `ef-guard` in a raw shell). Present the exact command and wait:

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

   Suggest the user runs it with the `! ` prefix so the output lands in the
   session. Do NOT proceed until the drop is confirmed done.

4. Apply every migration through the sanctioned CLI (parse the JSON
   envelope; a fresh empty DB on a local host is a 🟢 verdict):

   ```bash
   npx --prefer-offline tsx skills/efcore/cli/apply/index.ts \
     --spec '{"cwd":"<WORKTREE>","contextName":"<contextName>"}'
   ```

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.