xTr1m/RpgRoller
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Clarify migration acceptance criteria

Browse Source
This commit is contained in:
Frank Tovar
2026-04-03 00:08:54 +02:00
parent da9dc24d8e
commit 13c6215c89
1 changed files with 10 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
TASKS.md
View File

@@ -25,6 +25,7 @@ The initial scope is only roll definition, validation, execution, logging, and U
- Negative modifiers are supported for Rolemaster only. - 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. - 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. - 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 ## 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 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. - 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. - 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. - 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. - Update `SqliteSchemaUpgrader` coverage expectations if schema assumptions change.
- Verify serialized roll log payloads remain readable for old entries after DTO extension. - 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. - 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: Data migration recommendations:
- Legacy D6 / D&D 5e skills should retain current behavior with deterministic defaults. - 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. - New Rolemaster fields should be nullable or have safe defaults during migration.
- Avoid destructive migration patterns; favor additive schema evolution. - 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: Affected areas:
- `RpgRoller/Data/RpgRollerDbContext.cs` - `RpgRoller/Data/RpgRollerDbContext.cs`
@@ -297,6 +302,7 @@ API tests to add:
- roll each Rolemaster skill type via API - roll each Rolemaster skill type via API
- verify log page and detail endpoints for Rolemaster rolls - verify log page and detail endpoints for Rolemaster rolls
- verify old D6 / D&D contracts still round-trip without requiring Rolemaster-only fields - 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: Frontend/regression checks:
- Rolemaster ruleset appears in campaign creation UI - Rolemaster ruleset appears in campaign creation UI
@@ -339,6 +345,7 @@ Recommended implementation order:
#### Iteration 2: structured skill model #### Iteration 2: structured skill model
- Preserve `DiceRollDefinition` as the canonical persisted expression and add only the extra persisted Rolemaster fields the expression cannot represent. - 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 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. - Update API contracts and service mapping.
- Keep existing D6 / D&D behavior green. - 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. - 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. - 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. - 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. - 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. - 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` - subtract a recursive high-end chain on first-roll `<= fumble range`
- Roll logs and detail views clearly show how a Rolemaster result was produced. - Roll logs and detail views clearly show how a Rolemaster result was produced.
- Existing D6 and D&D 5e flows remain unchanged. - 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. - Local CI, coverage checks, and frontend verification all pass.