Clarify migration acceptance criteria

TASKS.md

@@ -25,6 +25,7 @@ The initial scope is only roll definition, validation, execution, logging, and U
 - Negative modifiers are supported for Rolemaster only.
 - D6 and D&D 5e keep their current non-negative modifier rules unless separately re-scoped in a future change.
 - Existing D6 and D&D 5e behavior must remain unchanged.
+- The migration must be validated against a copied temp-file instance of `RpgRoller/App_Data/rpgroller.development.db`, which currently contains a D6 campaign.
 
 ## Clarifications
 
@@ -52,6 +53,7 @@ The initial scope is only roll definition, validation, execution, logging, and U
 
 - Existing D6 and D&D 5e API request and response fields must remain valid throughout the Rolemaster rollout.
 - Existing persisted skills, skill groups, and roll log rows must continue to load without migration-time data loss.
+- Startup migration against the existing development SQLite database shape must succeed without data loss or post-migration behavior regressions for legacy D6 data.
 - Any richer die metadata must deserialize safely for old rows that only contain the current `RollDieResult` shape.
 - Payload budgets for roster, log page, roll mutation responses, and lazy-loaded roll detail must remain explicitly guarded by tests.
 
@@ -202,11 +204,14 @@ Tasks:
 - Update `SqliteSchemaUpgrader` coverage expectations if schema assumptions change.
 - Verify serialized roll log payloads remain readable for old entries after DTO extension.
 - Ensure additive schema changes allow mixed old/new data during migration and startup upgrade.
+- Validate the real startup migration path against a copied temp-file instance of `RpgRoller/App_Data/rpgroller.development.db`.
+- Verify that the migrated copy still loads the existing D6 campaign data and that legacy D6 skills remain rollable after startup migration.
 
 Data migration recommendations:
 - Legacy D6 / D&D 5e skills should retain current behavior with deterministic defaults.
 - New Rolemaster fields should be nullable or have safe defaults during migration.
 - Avoid destructive migration patterns; favor additive schema evolution.
+- Never run destructive migration verification against the source development DB file; always copy it first and test the copy.
 
 Affected areas:
 - `RpgRoller/Data/RpgRollerDbContext.cs`
@@ -297,6 +302,7 @@ API tests to add:
 - roll each Rolemaster skill type via API
 - verify log page and detail endpoints for Rolemaster rolls
 - verify old D6 / D&D contracts still round-trip without requiring Rolemaster-only fields
+- verify that a migrated copy of `RpgRoller/App_Data/rpgroller.development.db` still supports legacy D6 API flows after startup migration
 
 Frontend/regression checks:
 - Rolemaster ruleset appears in campaign creation UI
@@ -339,6 +345,7 @@ Recommended implementation order:
 #### Iteration 2: structured skill model
 - Preserve `DiceRollDefinition` as the canonical persisted expression and add only the extra persisted Rolemaster fields the expression cannot represent.
 - Add migration and schema tests.
+- Add startup-migration validation against a copied temp-file instance of `RpgRoller/App_Data/rpgroller.development.db`.
 - Update API contracts and service mapping.
 - Keep existing D6 / D&D behavior green.
 
@@ -367,6 +374,7 @@ Recommended implementation order:
 - The current `RollDieResult` type is too generic for clear Rolemaster open-ended auditing.
 - Allowing negative Rolemaster modifiers requires carefully scoping validation changes so D6/D&D rules do not loosen unintentionally.
 - Migration design needs care to avoid breaking legacy SQLite databases.
+- A migration that works on an empty test database but fails on the existing D6 production-shaped database would be a release blocker.
 - UI complexity will grow if ruleset-specific fields are bolted onto the current `IsD6` logic instead of replacing it with a ruleset-aware form model.
 - Richer Rolemaster die metadata could regress payload sizes or list readability if detail is not kept behind the existing lazy-load flow.
 
@@ -383,4 +391,6 @@ Recommended implementation order:
   - subtract a recursive high-end chain on first-roll `<= fumble range`
 - Roll logs and detail views clearly show how a Rolemaster result was produced.
 - Existing D6 and D&D 5e flows remain unchanged.
+- App startup successfully migrates a copied temp-file instance of `RpgRoller/App_Data/rpgroller.development.db`.
+- The migrated copy preserves the existing D6 campaign data and passes legacy D6 read/roll regression checks after startup migration.
 - Local CI, coverage checks, and frontend verification all pass.