Standardize thin Odoo Launchplane request wrapper

[shiny-code-bot]

Intent

Create one maintained thin Launchplane request pattern for Odoo repos so tenant repos stop duplicating bespoke OIDC request clients for artifact publish, promotion, rollback, post-deploy, preview, and feedback calls.

Finish Line

Tenant repos share one maintained Launchplane OIDC request adapter/template

Current Status

State: Active. Generic-web inheritance and Odoo post-deploy hook wiring are merged; PR #926 completed the adapter cleanup so service.py now delegates Odoo post-deploy selection to a workflow/driver adapter boundary.
Next action: Continue #907 preview planning, then use #908 to thin Odoo tenant handoff workflows once the Launchplane-side route contracts are stable.
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.

Validated Direction

• Generic-web is the base infrastructure driver for common web/service lifecycle.
• Odoo and VeriReel should extend generic-web only through named hooks/capabilities that are genuinely product-specific.
• Tenant repos should build/test/publish artifacts and submit minimal source/product facts. They should not own provider plans, target IDs, preview URLs, durable record shaping, or repo-local OIDC clients.
• SYO is the closest existing reference for thin generic-web handoff, but still has preview decision logic that may move later.
• VeriReel is mostly right as a product-specific-gates example, but some preview/stable lifecycle pieces may need to collapse into generic-web hooks.

Subissues

• Make generic-web inheritance real for infra lifecycle #906 Make generic-web inheritance real for infra lifecycle.
• Move Odoo preview planning into Launchplane driver #907 Move Odoo preview planning into Launchplane driver.
• Thin Odoo tenant Launchplane handoff workflows #908 Thin Odoo tenant Launchplane handoff workflows.
• Converge SYO and VeriReel on driver-owned infra boundary #909 Converge SYO and VeriReel on driver-owned infra boundary.

Direction Change

The earlier wrapper framing was too tactical. The target is:

• Generic driver owns common infra lifecycle: preview desired state, preview refresh/readiness/inventory/destroy, deploy, health, feedback, promotion/deployment records, runtime target/profile resolution, URL derivation, idempotency conventions, and generic provider evidence.
• Odoo driver inherits from generic-web and adds only Odoo-specific behavior: artifact publish inputs/evidence, Odoo post-deploy and overrides, isolated Odoo preview runtime planning/apply, Odoo smoke/verification evidence, backup gates, prod rollback semantics, stable bootstrap, and target replacement.
• Tenant repos should keep source/addons, build/test/smoke facts, artifact/image publication, and minimal Launchplane trigger inputs. They should not own provider mutation details, durable record shaping, URL/slug/target derivation, or duplicated Launchplane request clients.

Revised Acceptance Criteria

• The first implementation reduces tenant infra wiring by moving request/payload/idempotency derivation into Launchplane-owned generic/Odoo driver surfaces, not by creating another repo-local shared client.
• Any reusable action/template is explicitly a thin connector to Launchplane driver operations and does not become product-specific infra authority.
• Odoo tenant cleanup only deletes scripts after Launchplane can derive or own the same behavior through product profiles, OIDC claims, driver defaults, and typed route contracts.
• VR/SYO patterns are used only when they match the driver-owned infra target; otherwise they are tracked for the same migration direction.

Acceptance Criteria

• Shared wrapper covers Odoo artifact publish input/report, post-deploy, preview apply/refresh/destroy/readiness/writeback, prod promotion, prod rollback, and backup-gate calls as applicable.
• Wrapper uses GitHub OIDC and Launchplane service routes; it does not embed provider mutation or durable config authority in product repos.
• CM and OPW can delete duplicated request client code after adopting it.
• Tests prove request payload shape, fail-closed auth/config handling, and clear unsupported-call errors.