Plan Odoo operational ownership under Launchplane

[shiny-code-bot]

Intent

Move the remaining Odoo operational ownership into Launchplane so Odoo-related repos can stay focused on source code, builds, tests, local DX, and thin authenticated requests. This plan is the cleanup gate for reducing repo churn across tenant, shared-addon, image, devkit, and retired Odoo repos.

Finish Line

Odoo repos retain source/build/test/local DX/thin requests; Launchplane owns durable runtime operations and cleanup criteria

Current Status

State: Active. Generic/Odoo infra inheritance is now through the generic-web base driver plus Odoo post-deploy extension hook. PR #924 wired Odoo post-deploy into generic deploy/rollback apply; PR #925 fixed post-deploy failure evidence; PR #926 moved the Odoo generic-web post-deploy adapter out of control_plane/service.py and into a workflow/driver adapter boundary.
Next action: Continue #907 by adding the first Launchplane-owned Odoo preview planning endpoint so tenant workflows stop assembling provider preview plans.
Blocked by: No native issue blocker.
Waiting for: None.
Last verified: 2026-05-26 after PR #926 merged, post-merge CI/Security/CodeQL/Deploy passed, and live Launchplane health returned status=ok with Postgres storage.

Validation Notes

• Tenant repo audit: CM/OPW are mostly thin request repos already, but still duplicate Node request clients and assemble some preview/runtime request details locally.
• Platform repo audit: odoo-docker and odoo-enterprise-docker correctly own image builds and smoke gates; GHCR retention and runner health are candidates for central policy; odoo-devkit still owns local DX plus some non-local data workflow affordances; odoo-ai is retired but still has archival remote-ops config/docs that should be quarantined.
• Launchplane capability audit: Odoo service routes and records already cover artifact publish, post-deploy overrides, promotion, rollback, backup gates, preview lifecycle, stable bootstrap, target replacement, product profiles, runtime environments, managed secrets, inventory, and evidence. The main gaps are standardizing thin repo calls, broadening a few strategy paths, and making cleanup checks explicit.

Scope

• Inventory Odoo-related repos and classify each operational surface as Launchplane-owned, repo-owned, transitional, or retired.
• Create a reusable thin OIDC request pattern for Odoo driver calls so tenant repos stop carrying bespoke scripts.
• Move or explicitly retire any non-local Odoo data/runtime workflows still living in odoo-devkit or tenant repos.
• Quarantine retired odoo-ai remote-ops configuration so future sessions do not treat it as current authority.
• Decide whether Odoo image-repo GHCR retention and runner health remain repo-local package hygiene or move under Launchplane policy.
• Add regression checks so broad provider/runtime mutation does not creep back into Odoo repos.

Acceptance Criteria

• Owner matrix exists for odoo-tenant-cm, odoo-tenant-opw, odoo-shared-addons, disable_odoo_online, odoo-docker, odoo-enterprise-docker, odoo-devkit, and retired odoo-ai.
• Every cleanup PR has a Launchplane capability or explicit exception linked before deleting repo-owned scripts/workflows.
• Tenant repos share one maintained Launchplane request adapter/template instead of duplicating per-operation Node clients.
• Stable bootstrap and target replacement cleanup are gated on whether current Odoo needs only the implemented empty and recreate-in-place strategies or additional restore/cutover strategies.
• Retired odoo-ai remote-ops files are clearly marked archival or removed from active discovery paths.
• Contract checks catch reintroduced provider mutation, durable runtime config, managed-secret authority, direct Dokploy mutation, or shared runner hygiene in Odoo repos.

Relationships

• Follows completed runner-host hygiene work and the chris-testing replacement runbook.
• Related closed Odoo ownership plans include Extract remaining Odoo driver CLI groups #814, Extract Odoo override and target CLI #803, Decide Odoo base-image promotion ownership #728, Make Odoo driver derive health and logo probes #645, Persist Odoo website bootstrap intent in Launchplane overrides #593, Audit remaining orchestration code across product and tenant repos #510, Add Odoo preview adapter over Launchplane preview records #488, Replace Odoo staged preview with isolated runtimes #495, Enable issue-backed Odoo prelaunch rebuild policies #573, Make Odoo stable bootstrap a durable operation #556, Separate Odoo bootstrap provenance from deployment evidence #557, Add safe Odoo stable target replacement workflow #520, and Add service-backed Odoo stable bootstrap workflow #542.