# The agent fixed the bug on main and never backported it to the release branch

The agent reproduced the error on main, wrote the fix, watched the suite go green, and reported done. The error kept reaching customers through the next release because the supported branch they actually run still carried the old code, and the fix existed only on main.

Nobody lied about the patch. It was correct on the tip. The gap was between the tip and the versions that are actually deployed.

## Done on main is not done for people on older releases

Most maintained repos keep supported release branches that users stay on for months, while main represents whatever ships next. A merged fix on main does not travel backward by itself. The agent's mental model of the codebase is the checkout it started in; a separate release branch is another working tree it never opened, so the fix never appears there.

Customers pinned to an older line keep running the old binary no matter how clean main looks. Reporting closed on main describes the next release, not their build.

## Why the backport disappears from the plan

The task prompt names the symptom, not the supported version matrix. A review checklist usually asks whether tests pass on the current branch; almost nothing asks which release lines must receive the patch.

When the fix leans on a refactor that exists only on main, a straight cherry-pick can compile in the release branch yet call a helper that moved or changed signature. A green compile there hides a behavior shift. Release branches also freeze features and accept only fixes, so a backport that drags in unrelated cleanup belongs nowhere on that line.

## Make backports an explicit artifact, not an afterthought

Before fixing, list the supported versions actually affected and write them into the task. Treat each backport as a separate deliverable with its own branch, its own CI run, and its own review rather than a sentence buried in the PR body.

Cherry-pick onto every affected release line, re-run that branch's tests against its own runtime, and confirm the fix behaves the same where the helpers differ. Gate any customer-facing "fixed in" claim on a confirmed merge into that release branch. If the patch cannot cleanly backport, say so openly instead of claiming main coverage solved it.

A fix that lives only on main is a fix for the next release, not for the users still pinned to an older one. How does your team decide which supported lines a hotfix reaches, and does your agent ever check that list before calling it done?