[shiny-code-app]

The CM testing restore for #5206 still could not start after #5833. A fresh preflight at 2:46 PM ET refused testing_rebuild_inputs_unverified (trace launchplane_req_01591f0ba4c34b20b1cbabd1c154e330): "The selected build is not the current testing release." CM main moved at 2:12 PM ET (odoo-devkit pin, odoo-tenant-cm#389). Testing now runs that build, and the retained migrated pair is bound to the earlier main image. Naming the new build fails the pair's image check (trace launchplane_req_a1750868cc8e4438935fce186bb8ce71). So every main merge stranded a pair that had already been verified, and re-producing the pair is the heavy offline migration.

What changed: when a migrated restore names a main build, Launchplane verifies it as a release of the default branch's first-parent history. It no longer requires that build to be the lane's newest release. Everything else is unchanged: the pair's exact product/context/image binding, release provenance (repository id, successful push run, manifest, image repository, tenant lock), recorded-artifact conflict refusal, and the use, needed-copy, separation and hold checks. After the restore, normal reconciliation sees the older release serving and deploys current main forward with data_source_mode=existing.

Removed: the "must be the current testing release" refusal for an explicitly requested main build, added in #5791 without a recorded reason.

Net lines: +16 (+39/-23). Product code +8, tests +4, docs +4.

Refs #5206

Validation

• Failing first: the new test fails on the old selector with "The selected build is not the current testing release." It passes now.
• 562 tests across test_product_reconcile, test_testing_rebuild_http, test_testing_rebuild_worker, test_migrated_testing_source and test_build_provenance pass. Ruff, format and mypy are clean on the changed files.
• IDE inspection: UNKNOWN. The isolated PyCharm worker is missing its Pydantic support plugin, so no fresh run was attempted.
• Independent review: OpenAI via Codex (model not reported by the CLI). No actionable findings. It traced the forward path (native inventory, then _current_testing_release, _plan_testing_target, require_forward_build, and recreate-in-place with existing data). Its one note: no single end-to-end test runs older-main restore, then forward deploy. Existing tests cover each step separately. I left that as is rather than add a long fixture.

Client test notes

Nothing for the Client to test. This is a control-plane fix. The CM restore itself stays with its operator.

[shiny-code-app]

Review result: weighed
Head: ae20972

Independent review: OpenAI via Codex, read-only. The CLI did not report the model. Result: no actionable findings.

• Provenance, the pair's image binding, recorded-artifact conflicts and the worker's candidate recheck are unchanged. Release builds keep the stored manifest.
• After the restore, the forward path deploys current main with existing data. It runs through native inventory, _current_testing_release, _plan_testing_target, require_forward_build, and recreate-in-place.
• The only callers are migrated preflight and the worker recheck. No unwanted change found in either.
• Coverage note: no single test runs older-main restore through to the forward deploy. Each step is covered on its own. Declined: a long end-to-end fixture would add upkeep without catching a different break.

[shiny-code-app]

Ready for the merge train

Head: 0b2e456

[shiny-code-app]

Launchplane completed the merge-train step for this pull request.

• Repository: cbusillo/launchplane
• Base branch: main
• Pull request: Let a migrated restore use the main build its pair was made for #5837
• Controller action: land_batch
• Controller record: merge-train-batch-landing-plan-20261109T203908Z-e967eedb09864874

Launchplane landed this pull request through protected batch PR #5839.

Launchplane manages this comment and will update it as the train moves.