Package evolution and release compatibility
Ship fixes and improvements while preserving pinned runs, historical evidence, and honest progression lanes.
Never replace bytes for a published semantic version. Build a new version and classify how it relates to the exact prior archive.
Compatible presentation change
Examples:
- responsive layout improvement;
- accessibility correction;
- copy or visual polish;
- overlay animation change;
- bug fix that does not affect any declared result fixture.
The result and progression lanes may remain comparable after differential proof.
New result lane
Examples:
- scoring rule correction;
- changed Attempt terminal condition;
- altered configuration semantics;
- previously accepted observation now interpreted differently;
- new primary metric or unit.
Historical Attempts keep their pinned result contract. New evidence enters the new lane unless a reviewed migration proves equivalence.
New progression lane
Changing rank thresholds or aggregation can preserve raw result comparability while producing a new progression definition. Both ladders remain attributable to their exact policy version.
Active run safety
An active Attempt or Live Run continues with the release and capability versions it began with. Updating the installation affects future runs only. Rollback selects another immutable release for future runs; it never mutates evidence.
Evolution command
npm run cm -- evolution --from ./previous-release.cmpkgThe report compares manifests, schemas, declared contracts, artifacts, and representative fixture behavior. Resolve every breaking finding deliberately; do not edit the report or bump a version until it turns green.