Why PRs Matter
The Pull Request is your safeguard. It ensures:- No blind merges — You see every line of generated code
- Normal workflow — Uses the same review process as any other PR
- Team involvement — Other reviewers can participate
- CI/CD validation — Your existing pipelines run against the changes
Opening a Milestone PR
- When a milestone is complete, the milestone card on the Roadmap will have an entrypoint to the Code Review drawer.
- The drawer will have a button that takes you to the individual pull requests
What to Review
Code Quality
- Does the generated code follow good practices?
- Are there any obvious bugs or issues?
- Is the code readable and maintainable?
Correctness
- Does the migration preserve the original functionality?
- Are edge cases handled?
- Do the transformations make sense?
Consistency
- Does the code match your team’s conventions?
- Are naming patterns consistent with existing code?
- Is the style what you expected?
Tests
- Were tests migrated or generated?
- Do they cover the key functionality?
- Do they pass?
Taking Action
If Everything Looks Good
- Open the pull requests by clicking the PR links in the top-right corner of the Code Review drawer
- Approve each PR in your SCM (GitHub, GitLab, Azure DevOps)
- Merge using your preferred strategy (merge commit, squash, rebase)
- Return to —the milestone status updates to Merged
- The next milestone unlocks
All pull requests for a milestone must be merged before the next milestone can begin. If any PR remains unmerged, the milestone stays in its current state and the next one will not unlock.
If You Find Issues
You have several options: Make Manual Fixes The PR is a standard Pull Request. You can:- Push additional commits to fix issues
- Edit files directly
- Clone locally and push changes
- Close the PR without merging
- In , the milestone returns to a state where you can retry
- Consider editing the milestone before regenerating
If Checks Fail
CI/CD checks run on PRs automatically. If they fail:- Click into the failed check
- Review the failure reason
- Common causes:
- Linting violations (may need style adjustments)
- Test failures (tests may need updates for new code)
- Build errors (configuration may need tweaks)
- Fix the issues and push updates
- Merge once checks pass
PR States in
The milestone status reflects the PR state:| Status | PR State |
|---|---|
| Pending Review | PR open, awaiting review |
| Pending Review (with warning) | PR checks failed |
| Merged | PR merged into target branch |
Best Practices
Review Promptly
Don’t let PRs sit. The next milestone is blocked until you merge. Review and merge (or address issues) to keep momentum.Use Your Normal Process
Treat milestone PRs like any other PR:- Add reviewers if your team normally does
- Require approval if that’s your policy
- Run additional manual tests if needed
Check Related Changes
When reviewing, consider:- Do changes in this milestone connect properly to previous milestones?
- Are there any inconsistencies with already-merged code?
Document Decisions
If you make manual changes to a PR before merging, consider noting why. This helps if similar issues come up in later milestones.After Merging
Once merged:- The milestone shows Merged status
- The next milestone becomes available
- Repeat the process: Review → Generate → Execute → Review PR → Merge
Troubleshooting
”PR was closed without merging”
If you accidentally close a PR:- Reopen it, or
- In , retry the milestone to generate a new PR
”Merge conflicts”
Conflicts can occur if:- You made manual changes to the repository
- Another branch was merged between milestones
”PR stuck in pending state”
If doesn’t detect your merge:- Refresh page
- Check that the PR is actually merged
- Wait a moment—status updates poll periodically
- Contact support if the issue persists