Description
When performing large upgrades, the agent should break changes into smaller, focused PRs (e.g., per project or per task) instead of one massive PR. This makes code review more manageable, reduces risk, and allows teams to merge incrementally.
Problem
The tool currently bundles all migration changes into one large PR: SDK conversion, package upgrades, TFM changes, and API fixes all land together. In large enterprise repos this creates problems with deployment cycles, rollback, and code review.
Expected Behavior
Support a "one theme per PR" approach that breaks the migration into isolated, sequential stages:
- SDK-style conversion — Convert csproj format and move from packages.config to PackageReference. No TFM or version changes. Must build before proceeding.
- Multi-targeting — Add net8.0 alongside net472. Both TFMs must build. This is a valid stopping point.
- Package upgrades — Bump packages to net8.0 compatible versions. Both TFMs still building.
- Finalize — Drop net472 and finalize on net8.0.
Each PR maps to one failure domain. If something breaks in staging, you know exactly where to look and can revert just that step.
Additional Context
Scoping is also a gap. Instead of migrating a full 40-project solution at once, users should be able to pick one target service and only pull in the projects needed to build it (e.g., 8 out of 40), leaving the rest untouched.
The tool currently tries to drive everything to a final state in one flow rather than giving the engineer a recommended sequence they can move through step by step.
Description
When performing large upgrades, the agent should break changes into smaller, focused PRs (e.g., per project or per task) instead of one massive PR. This makes code review more manageable, reduces risk, and allows teams to merge incrementally.
Problem
The tool currently bundles all migration changes into one large PR: SDK conversion, package upgrades, TFM changes, and API fixes all land together. In large enterprise repos this creates problems with deployment cycles, rollback, and code review.
Expected Behavior
Support a "one theme per PR" approach that breaks the migration into isolated, sequential stages:
Each PR maps to one failure domain. If something breaks in staging, you know exactly where to look and can revert just that step.
Additional Context
Scoping is also a gap. Instead of migrating a full 40-project solution at once, users should be able to pick one target service and only pull in the projects needed to build it (e.g., 8 out of 40), leaving the rest untouched.
The tool currently tries to drive everything to a final state in one flow rather than giving the engineer a recommended sequence they can move through step by step.