## Review Migrated .sf Directory

A `/migrate` command just wrote a `.sf/` directory from an old `.planning` source. Your job is to audit the output and verify it meets SF standards before the user starts working with it.

### Source
- Old `.planning` directory: `{{sourcePath}}`
- Written `.sf` directory: `{{sfPath}}`

### Migration Stats
{{previewStats}}

### Review Checklist

Work through each check. Report PASS/FAIL with specifics. Fix anything fixable in-place.

#### 1. Structure Validation
- Run `deriveState()` on the `.sf` directory (import from `state.ts`, pass the **project root** as basePath)
- Confirm it returns a coherent phase (not `pre-planning` unless the project is truly empty)
- Confirm activeMilestone, activeSlice, activeTask are sensible for the project's completion state
- Confirm progress counts match the migration preview stats

#### 2. Roadmap Quality
- Read `M001-ROADMAP.md` (and any other milestone roadmaps)
- Confirm slice entries have meaningful titles (not file paths or garbled text)
- Confirm `[x]`/`[ ]` completion markers are correct relative to the old roadmap
- Confirm vision statement is present and meaningful (not empty or "Migration")

#### 3. Content Spot-Check
- Pick 2-3 slices with the most tasks and read their plan files
- Confirm task titles and descriptions carry over meaningfully from the old plans
- Confirm summary files exist for completed tasks and contain relevant content
- Check that research files (if present) contain consolidated content, not empty stubs

#### 4. Requirements (if any)
- Read REQUIREMENTS.md
- Confirm requirement IDs are present and non-duplicate
- Confirm statuses make sense: completed old requirements should be `validated`, in-progress should be `active`

#### 5. PROJECT.md
- Read the written PROJECT.md
- Confirm it contains the old project's description, not boilerplate
- Confirm it reads like a useful project summary

#### 6. Decisions
- If DECISIONS.md was written, confirm it contains extracted decisions from old summaries (or is empty if no decisions existed)

### Output Format

Summarize your findings as:

```
Migration Review: <project name>
================================
Structure:     PASS/FAIL — <details>
Roadmap:       PASS/FAIL — <details>
Content:       PASS/FAIL — <details>
Requirements:  PASS/FAIL/SKIP — <details>
Project:       PASS/FAIL — <details>
Decisions:     PASS/FAIL/SKIP — <details>

Overall: PASS / PASS WITH NOTES / FAIL
Issues: <list any problems found>
Fixes applied: <list any in-place fixes made>
```

If the overall result is FAIL, explain what needs manual attention. If PASS WITH NOTES, explain what's imperfect but acceptable. If PASS, confirm the `.sf` directory is ready for SF-2 autonomous mode.

### Report sf-internal observations

If during this unit you observe sf-the-tool friction — ambiguous prompts, missing context, misleading instructions, surprising behavior, prompt-quality issues, or improvement ideas — file them via `report_issue` before sealing the unit. This is the only way these observations reach forge's backlog and get triaged. Over-reporting is preferred to under-reporting; dedup happens later. Do NOT use this to file bugs in the user's project; only sf-the-tool itself. Do NOT autonomously act on or fix existing backlog entries — your scope is your unit.
