Why every code-changing automation should open a Change Request

Automation should not bypass review

The more capable automation becomes, the more important the review boundary becomes. A system that can edit code should not push directly to the main branch, mutate a checkout without a record, or hide the diff behind a chat summary.

Every meaningful code change needs a branch, a diff, tests, and a review path. That is not bureaucracy. It is how teams preserve shared ownership over production behavior.

Change Request is the provider-neutral boundary

xmode uses Change Request as the common abstraction across GitHub pull requests and GitLab merge requests. The provider can differ, but the workflow contract stays the same: create a branch, attach the run context, publish the diff, and sync review state back into the app.

This gives the pipeline a stable target. It does not need to care whether the team uses GitHub or GitLab for every internal decision. It only needs to guarantee that code-changing work becomes a reviewable Change Request.

Fresh branches reduce hidden state

xmode always creates a new branch for code-changing runs. Reusing an old branch makes it too easy to mix unrelated work, hide stale state, or confuse reviewers about what the automation actually produced.

A fresh branch creates a clear boundary around the run. The branch name, commit messages, run logs, artifacts, and review notes can all point back to the same objective.

Reviewers need more than a diff

A diff tells reviewers what changed. It does not always explain why the automation made those choices, what plan it followed, which tests ran, or which errors were encountered and recovered.

That is why the Change Request should link back to the run timeline. The timeline can show the approved plan, action steps, captured command output, structured artifacts, and any manual approvals or revisions.

The practical rule

The rule is simple: if automation changes code, it opens a Change Request. That rule keeps agent work compatible with existing engineering practice while still allowing teams to delegate more of the execution path.