# smart-migration fragment

**ID:** `fvcms.fragment.smart-migration.001`

## What it is

The **Smart Migration** panel. v0.1: analyzes the site (`annotation.json` + content store) and suggests panel/content-type migrations. Operator approves each one before apply.

Per `a493 v22 Phase 6.2`: "Smart panel migration logic (analyze + suggest + apply with operator approval)."

Per `app-pact` §3.13: each migration is a **SMALL** tier write (1 write per migration), so the agent makes the change and asks "save?" before committing.

## The 4 migration kinds (analyzer)

1. **unbound-region** — a region exists in `annotation.json` but has no `content_type` binding. Suggest binding based on the modules present (heuristic: blog-* → BlogPost, recipe-* → Recipe, listing-* → Listing).
2. **unused-panel** — a panel is enabled in `chrome.panels` but no region uses it. Suggest disabling.
3. **cross-region-duplicate** — the same module appears in 3+ regions. Suggest making it a shared bundle.
4. **mismatched-template** — a region has `blog-post-list` but is missing `blog-post-card`. Lists usually render cards.

## Public API

```js
import { openSmartMigration, renderSmartMigration, analyzeSite } from 'app-fragments/smart-migration/index.js';

// Programmatic analysis (used by tests + the AI agent in v0.2)
const suggestions = analyzeSite();
// Returns: [{ id, kind, severity, regionId, description, fix }]

// Or as a panel
const panel = openSmartMigration();
```

## Recipe (10-item, abbreviated)

1. **purpose** — site analysis + migration suggestions
2. **inputs** — `annotation.json`, `content-types/*` (in v0.2)
3. **outputs** — a list of suggestions, each with severity + fix
4. **state machine** — same as other panels
5. **event bus** — emits `migration:analyzed`, `migration:applied`, `migration:skipped`
6. **dependencies** — `admin-audit` (for logging)
7. **constitutional refs** — app-pact §3.13 (SMALL tier)
8. **tier** — T2
9. **canonical home** — `app-fragments/smart-migration/`
10. **recipe** — this file

## v0.1 limitations

- The "Apply" button is a **preview** (logs to audit, fades the row). v0.2 will write to the store per §3.14.
- The 4 heuristics are simple. v0.2 will add LLM-driven analysis for more complex cases.
- No undo. v0.2 will add a "revert" button that walks back the migration in reverse order.

## v0.2 plan

1. Wire the "Apply" button to actually write to the store (via the runtime's content-store path)
2. Add an "Apply all" button (with §3.13 tier escalation if >10 migrations)
3. Add a "Revert last" button
4. Add LLM-driven analysis for the mismatched-template case
5. Add cross-site migration support (compare two sites, suggest what to import)