Release and review
Chasing Mastery public platform
Compatibility and evolution
Decide whether a change can share history, needs migration, requires a new result lane, or must remain pinned to old runs.
Package versions are immutable. An update produces a new release, and review classifies the semantic change.
| Change | Typical treatment |
|---|---|
| Layout, copy, accessibility, animation | presentation-compatible update |
| Bug fix preserving all semantic fixtures | compatible only with differential proof |
| New optional mode | additive Suite release; old mode lanes remain |
| Saved configuration shape | explicit forward migration |
| Default exercise meaning | new configuration identity and review |
| Metric key, unit, direction, precision, or calculation | new result-contract revision |
| Progression thresholds/window/evidence | new progression version and retained lane |
| Observation payload meaning/schema | new exact protocol identity and binding verification |
Active and historical behavior
- An active run keeps the release and capability versions it began with.
- Upgrade affects future runs only after review and install-plan application.
- Old Attempts remain readable with their exact provenance.
- Rollback selects an older approved release for future runs; it never rewrites evidence already committed by a newer release.
- A compatible presentation update must not require a result-history rewrite.
Run the project-local evolution command against the retained prior archive.
Treat its report as review input, not permission to override an incompatible
change.