## [2026-05-15T16:04:09.399Z]
New orchestration module — sequences runMigrations + updateConfigVersion from migrator.ts, flattens migration actions/warnings into UpgradeResult. Extracted from cli/init.ts::runVersionUpgrade so the version-upgrade sequence lives in the engine layer without presentation concerns.
## [2026-05-27T07:22:23.871Z]
Phase 1 change: updated migrator-runner to work with new ReviewerConfig and AspectReviewerSpec types after the v5 reviewer-tiers model change.
## [2026-05-28T05:09:52.679Z]
Runner now owns incremental version bumping. Each applicable migration runs in semver order; after each successful migration the runner writes the migration target into yg-config.yaml so the next step observes the freshly advanced version. A migration that returns bumpVersion false stops the chain and leaves the project at the last successfully completed step. The runner no longer accepts a global toVersion or a fromVersion parameter; the current version is detected from yg-config.yaml on entry. The result now includes the fromVersion and landedVersion for callers that need to display the journey.
## [2026-05-31T03:04:38.731Z]
The upgrade runner now reports whether the migration chain stopped early because a step could not be safely applied — distinct from a chain that completed but emitted informational notices. Previously the only signals were the landed version and the accumulated notices, which conflated a completed-with-notices upgrade with an incomplete one, so a caller could not reliably tell whether the version actually reached its target. A dedicated incomplete/withheld flag is set exactly where the chain breaks on a step that declines to advance the version. The motivation is to let the command layer report an incomplete upgrade as a failure while still treating a completed upgrade's notices as informational.
## [2026-06-01T07:58:00.665Z]
Clarified that the runner is the sole writer of the project config's version field. Migrations no longer write the version themselves, so the runner's per-step version write is the only one that ever happens; the prior note about a migration possibly having already written the same value is obsolete. The runner advances the version one step per successfully-completed migration and withholds the bump when a migration reports it withheld completion (recoverable warnings the user must resolve first). Concentrating the write in one place keeps the version monotonic and keeps the warnings gate honest — there is no second writer that could move the version past a withheld step.
