Add Odoo website bootstrap support for Launchplane

[cbusillo]

Objective

Add Odoo/devkit support for Launchplane-driven website bootstrap data so an empty CM testing database can be rebuilt with the expected public website identity, page route, and logo state.

Finish Line

After Launchplane runs Odoo Stable Bootstrap for odoo-tenant-cm cm/testing, public verification passes for health, canonical URL, /cell-mechanic, and /web/image/website/1/logo without manual Odoo UI repair or Dokploy edits.

Current Status

State: Blocked by Launchplane follow-up cbusillo/launchplane#593. Devkit website bootstrap support is merged, and the Launchplane route/inventory/env-handoff blockers found on 2026-05-12 were fixed in Launchplane #590 and #591. Current live stable-bootstrap run now uses the newer CM artifact and passes health/canonical, but still fails logo because Launchplane does not yet persist/render devkit website_bootstrap intent into the Odoo override payload.

Latest evidence:

• Launchplane stable bootstrap 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

Next action: Complete cbusillo/launchplane#593, rerun Odoo Stable Bootstrap for odoo-tenant-cm cm/testing with health/canonical/logo verification enabled, then close this issue if logo and public website identity pass.

Blocked by: cbusillo/launchplane#593.
Last verified: 2026-05-12; Launchplane #590/#591 merged and deployed; health/canonical pass, logo still fails.

Scope

• Inspect run_odoo_data_workflows.py --bootstrap and the launchplane.settings addon apply path.
• Add typed website bootstrap/apply support for canonical/base URL and website domain state.
• Add or wire CM-owned website content for /cell-mechanic.
• Add or wire a CM-owned logo asset so /web/image/website/1/logo is not 404.
• Keep the implementation tenant-safe: do not hard-code CM content into generic devkit paths unless it is behind an explicit tenant input or fixture boundary.
• Document how Launchplane should pass or reference website bootstrap intent.

Acceptance Criteria

• A clean CM testing bootstrap creates a valid /cell-mechanic route.
• Health verification passes for https://cm-testing.shinycomputers.com/web/health.
• Canonical verification passes for https://cm-testing.shinycomputers.com/cell-mechanic.
• Logo verification passes for https://cm-testing.shinycomputers.com/web/image/website/1/logo.
• Website identity reflects the CM bootstrap intent instead of generic My Website chrome.
• The bootstrap path remains tenant-safe and driven by tenant/Launchplane input.

Relationships

• Blocked by: cbusillo/launchplane#593
• Follow-up fixes already merged/deployed: cbusillo/launchplane#590, cbusillo/launchplane#591

[cbusillo]

Launchplane live verification update from 2026-05-10:

• A fresh CM artifact including odoo-devkit main at bae74b93c111d597a0827284608b72e85658c164 was published: https://github.com/cbusillo/odoo-tenant-cm/actions/runs/25634663925.
  • artifact_id: artifact-cm-48094d7cee46aa28
  • image_digest: sha256:48094d7cee46aa2836831e6f019510573584c5c1fb83ad35b1dcf2282fd819e2
• Launchplane applied the artifact after route-focused fixes #571 and #572, but public ingress still returns Traefik/plain 404 page not found before Odoo responds: https://github.com/cbusillo/launchplane/actions/runs/25635383414.
• Follow-up Launchplane plan shows the compose target deployment is done, runtime identity is present for deployment-20260510T174113Z-cm-testing, and the raw compose SHA changed to f6f01e173ac941e249a9a4f52501053bdcf1e9ab79e10d8ae1946cfae751d903.

Conclusion: this devkit issue should stay open only as blocked verification, not as evidence of a devkit data/bootstrap failure. We did not run Odoo Stable Bootstrap because the current blocker is public Dokploy/Traefik route attachment for cm-testing, before Odoo or website bootstrap data can be exercised.

[cbusillo]

Live verification update from 2026-05-12:

• Public route attachment is no longer the primary blocker. https://cm-testing.shinycomputers.com/web/health returns 200 with {"status": "pass"}, and /cell-mechanic returns an Odoo page.
• The Odoo page still emits <link rel="canonical" href="http://localhost:8069/cell-mechanic"/>, so canonical verification still fails.
• /web/image/website/1/logo and the logo variants referenced by the page still return plain 404 page not found before Odoo image content is served.
• Rerunning Launchplane Odoo Stable Bootstrap with the correct confirmation phrase still used stale inventory: artifact-cm-56978ff75c57c6a0, source f358c2d378defb24a5a992e3e0228137e9bce272, which predates CM website-bootstrap.toml.
• Explicit target replacement with newer CM artifact artifact-cm-d86025a089905522 / ff348ec8df2de651e4d1a36a62e6c134374b4531 exposed a Launchplane workflow issue: the service accepted the request, but the driver result reported deploy_status: fail after a transient /web/health 404, while the GitHub Actions job still showed success. Because the driver result failed, inventory did not advance, and stable bootstrap continued to read the stale artifact.

Follow-up opened in Launchplane: cbusillo/launchplane#590. That PR retries target-replacement verification across the configured timeout and makes the target replacement workflow fail when the accepted driver result reports failed deploy/post-deploy status.

Next action after #590 lands/deploys: rerun Odoo Target Replacement Apply for artifact-cm-d86025a089905522 with health-only verification so inventory advances, then rerun Odoo Stable Bootstrap with health/canonical/logo verification enabled.

[cbusillo]

Second live verification update from 2026-05-12:

Resolved Launchplane blockers:

• Harden Odoo target replacement verification launchplane#590 merged and deployed. Target replacement now retries transient verification failures and the workflow fails if the accepted driver result reports failed deploy/post-deploy status.
• After #590 deployed, Odoo Target Replacement Apply for artifact-cm-d86025a089905522 / ff348ec8df2de651e4d1a36a62e6c134374b4531 passed with health verification. Result: deployment-20260512T181543Z-cm-testing, trace launchplane_req_23ccbd3b89744e4d98d8386b2f0ee263.
• Pass Odoo overrides into stable bootstrap launchplane#591 merged and deployed. Stable bootstrap now passes Odoo override env into the bootstrap data workflow.

Current live stable-bootstrap result after #591:

• Run: https://github.com/cbusillo/launchplane/actions/runs/25754751163
• Artifact/source used: artifact-cm-d86025a089905522 / ff348ec8df2de651e4d1a36a62e6c134374b4531
• Bootstrap run: pass
• Post-deploy: pass
• Health: pass
• Canonical: pass
• Logo: fail
• Deployment record: deployment-20260512T183951Z-cm-testing
• Trace: launchplane_req_931b3ae288b349c8ab64b2e0f17224d0
• Remaining error: Logo check https://cm-testing.shinycomputers.com/web/image/website/1/logo returned HTTP 404.

Direct public checks now show canonical fixed:

• /web/health returns pass.
• / advertises https://cm-testing.shinycomputers.com/cell-mechanic as canonical.
• Website chrome/title still says My Website, and /web/image/website/1/logo plus logo variants still return plain 404.

Current conclusion: devkit bootstrap code is partially exercised now because web.base.url applies, but Launchplane's persisted Odoo override record currently only carries config parameters/addon settings. It does not preserve the devkit website_bootstrap object from artifact publish/runtime payload, so stable bootstrap cannot yet pass website name/logo/homepage intent into apply_website_bootstrap. Next work is a Launchplane contract/model follow-up to persist and render website_bootstrap in the Odoo instance override payload, then rerun stable bootstrap and close this issue if logo passes.