Persist Odoo website bootstrap intent in Launchplane overrides

[cbusillo]

Objective

Persist and render devkit website_bootstrap intent through Launchplane's Odoo override contract so stable bootstrap can apply website name, canonical/homepage state, and logo data for resettable Odoo targets.

Finish Line

Odoo Stable Bootstrap for odoo-tenant-cm cm/testing passes health, canonical, /cell-mechanic, and /web/image/website/1/logo verification using artifact artifact-cm-d86025a089905522 or a newer CM artifact that contains the same website bootstrap intent.

Current Status

State: Blocker for cbusillo/odoo-devkit#34. Launchplane #590 and #591 are merged/deployed. Current live stable-bootstrap evidence on 2026-05-12 shows health/canonical now pass, but logo still fails because the public page still renders My Website chrome and /web/image/website/1/logo returns plain 404.

Latest run: https://github.com/cbusillo/launchplane/actions/runs/25754751163

• artifact/source: artifact-cm-d86025a089905522 / ff348ec8df2de651e4d1a36a62e6c134374b4531
• bootstrap run: pass
• post-deploy: pass
• health: pass
• canonical: pass
• logo: fail
• trace: launchplane_req_931b3ae288b349c8ab64b2e0f17224d0

Working diagnosis: Launchplane's Odoo instance override record currently preserves config parameters/addon settings but does not preserve devkit's website_bootstrap object. As a result, #591 can pass web.base.url during bootstrap, but apply_website_bootstrap still does not receive the website name/logo/homepage payload.

Scope

• Add a Launchplane contract/model path for Odoo website bootstrap payload data.
• Preserve the payload from the artifact publish/runtime input boundary or an equivalent authoritative source.
• Render it into ODOO_INSTANCE_OVERRIDES_PAYLOAD_B64 for stable bootstrap and post-deploy paths where appropriate.
• Keep tenant-specific website data tenant-owned; Launchplane should persist/pass intent, not hard-code CM content.
• Add regression tests proving the bootstrap payload includes website_bootstrap.

Acceptance Criteria

• Stored Odoo override data can represent website bootstrap intent without dropping it.
• Stable bootstrap runner receives an override payload containing website_bootstrap for CM testing.
• CM testing stable bootstrap passes health and canonical verification.
• CM testing stable bootstrap passes logo verification for /web/image/website/1/logo.
• cbusillo/odoo-devkit#34 is updated with the passing run evidence and can be closed if no devkit-side issue remains.

Relationships

• Blocks: cbusillo/odoo-devkit#34
• Follows: Harden Odoo target replacement verification #590, Pass Odoo overrides into stable bootstrap #591

[EXDEV-oss]

Hey, I’m a Summer of Bitcoin contributor and came across this issue while reviewing the project. I mainly work around backend reliability, API validation, auth/session testing, infrastructure stability, edge-case debugging, and production-readiness checks before release.

I’d be interested in helping test the security-related changes here and documenting reproducible findings properly if needed. The project architecture looks solid. Could you please assign the issue to me?