Enable issue-backed Odoo prelaunch rebuild policies

[cbusillo]

Objective

Add an explicit, issue-backed Launchplane policy signal for Odoo lanes that are safe to rebuild before launch, instead of relying on environment names or informal operator memory.

Desired Policy

For CM:

• cm/testing: allow empty stable bootstrap.
• cm/prod: allow empty stable bootstrap while CM prod is not active/authoritative yet.
• Both lanes should remain issue-backed so the permission is auditable and easy to retire when CM launches.

For OPW:

• opw/testing: allow restore from the current upstream/non-Docker source while OPW has not cut over.
• opw/prod: allow restore from the current upstream/non-Docker source while OPW prod is not yet authoritative in Launchplane.
• Both lanes should be issue-backed and expire/retire when OPW launches on Launchplane-managed prod.

Why

The current odoo_stable_bootstrap profile policy is disabled for odoo-tenant-cm cm/testing, so Odoo Stable Bootstrap is correctly rejected even though CM testing/prod are currently inactive and intended to be rebuildable.

Recent evidence:

• Fresh CM artifact with odoo-devkit Add Odoo prod backup gate driver #38 was published: https://github.com/cbusillo/odoo-tenant-cm/actions/runs/25636123548
  • artifact_id: artifact-cm-d86025a089905522
  • devkit runtime commit: c80c291ee9221ad728a2d536105a13864bf8687d
• Artifact apply succeeded far enough to run the service and post-deploy: https://github.com/cbusillo/launchplane/actions/runs/25636160522
  • deployment_record_id: deployment-20260510T181714Z-cm-testing
  • runtime_identity_injected: true
  • post_deploy_status: pass
• Live CM testing probes now pass for /web/health, /, and /cell-mechanic.
• /web/image/website/1/logo remains 404, and the intended next repair is stable bootstrap/logo bootstrap.
• Odoo Stable Bootstrap was attempted with confirmation bootstrap cm testing: https://github.com/cbusillo/launchplane/actions/runs/25636213212
  • rejected with HTTP 400 before execution
  • deployed product profile shows odoo_stable_bootstrap.enabled=false for odoo-tenant-cm cm/testing

Scope

• Add/enable a Launchplane-owned policy signal for specific prelaunch Odoo lanes.
• Store/link the policy to this issue or an explicit issue reference so the operator approval is visible in records/read models.
• Permit CM empty bootstrap for both testing and prod while they are inactive/prelaunch.
• Permit OPW restore-from-upstream for both testing and prod while Launchplane-managed prod is not authoritative.
• Preserve fail-closed defaults for unknown lanes and real production lanes.
• Make the policy easy to retire when CM or OPW launches.

Acceptance Criteria

• CM testing and prod read models show they are provisional/prelaunch and empty-bootstrap allowed, with this issue as the approval signal.
• OPW testing and prod read models show they are provisional/prelaunch and restore-from-upstream allowed, with this issue as the approval signal.
• Odoo Stable Bootstrap for CM testing is accepted only when the issue-backed policy is present and the confirmation phrase matches.
• Real production lanes still reject destructive bootstrap/recreate/restore without appropriate backup/restore proof.
• Tests cover CM empty bootstrap allow, OPW upstream restore allow, issue reference requirement, and default refusal for unmarked lanes.
• Docs explain that instance names like prod are not authority by themselves; the issue-backed lane policy is the authority until launch/cutover.

Related

• Child/focused implementation of Model Odoo lane data authority and rebuild sources #564.
• Unblocks the remaining CM bootstrap proof in Add service-backed Odoo stable bootstrap workflow #542.
• Supports safe stable target replacement work in Add safe Odoo stable target replacement workflow #520.
• Related to Replace hard-coded Odoo bootstrap allowlist with lane policy #555 because this should replace hard-coded allowlists with auditable lane policy.

[cbusillo]

Status update after PR #574 and follow-up PR #576:

• PR Require issue-backed Odoo bootstrap approval #574 landed the contract guard: enabled Odoo stable-bootstrap policies must carry an approval_issue_url, and docs now say this issue should close when policy is encoded rather than when CM/OPW launch.
• PR Encode CM issue-backed bootstrap policy #576 encodes the CM side into Launchplane-owned onboarding records: cm/testing and cm/prod both get issue-backed empty-bootstrap policy tied to this issue, and the deploy payload now preserves that lane policy into product profile records.
• I am keeping this issue open for the OPW acceptance criteria. The current service contract only supports odoo_stable_bootstrap.data_source_mode = "empty"; it does not yet model OPW restore-from-upstream. Closing Enable issue-backed Odoo prelaunch rebuild policies #573 before adding that first-class restore policy would blur the authority boundary the issue is trying to make explicit.

Current next blocker for full closure: add/encode a Launchplane-owned OPW upstream-restore policy contract, then seed OPW testing/prod records with this issue URL as the approval signal.

[cbusillo]

OPW follow-up is now included in PR #576:

• Added lane-owned odoo_prelaunch_rebuild policy for resettable Odoo lanes.
• Seeded odoo-tenant-opw testing and prod with data_source_mode="upstream_restore", the Enable issue-backed Odoo prelaunch rebuild policies #573 approval URL, target proof, and confirmation phrase.
• Target replacement plan/apply now accepts data_source_mode and confirmation; prelaunch rebuild requests must match the lane policy before allow_empty_data is accepted as intentional.
• Product environment read models expose whether prelaunch rebuild is allowed, which data source mode applies, and the approval issue URL.

With PR #576 merged and deployed, #573 should be closable. Launch/cutover retirement of these provisional policies should remain a separate follow-up.

[cbusillo]

Live verification update from May 10, 2026:

• Merged and deployed issue-backed Odoo prelaunch policy work plus follow-up repairs:
  • Pass Odoo onboarding target IDs #579 passed Odoo onboarding target IDs through deploy seeding.
  • Align OPW prelaunch domain proof #580 aligned OPW prod prelaunch domain proof with the current prelaunch Dokploy host, opw-prod.shinycomputers.com.
  • Use live domains for Odoo prelaunch proof #581 changed OPW replacement planning to prove domains from the live Dokploy target snapshot.
  • Use live domains for Odoo bootstrap proof #582 changed CM stable bootstrap to prove domains from the live Dokploy target snapshot and use live domains for verification URLs.
• OPW prod target replacement plan now returns plan_status=ready with data_source_mode=upstream_restore, allow_empty_data=true, approval issue Enable issue-backed Odoo prelaunch rebuild policies #573, target opw-prod, domain opw-prod.shinycomputers.com, and no blockers. Run: https://github.com/cbusillo/launchplane/actions/runs/25639229242
• CM testing stable bootstrap was accepted and executed. Bootstrap run passed, Odoo post-deploy passed, and /web/health passed. Readiness failed only at verification: canonical page advertises http://localhost:8069/cell-mechanic instead of https://cm-testing.shinycomputers.com, and the logo route remains 404. Run: https://github.com/cbusillo/launchplane/actions/runs/25639531806

Remaining: repair CM Odoo site/base-url/logo content so the issue-backed bootstrap verification can pass end to end. OPW apply/actual upstream restore has not been run; the validated path is planning/policy proof, not a completed restore.

[cbusillo]

Follow-up from the CM stable bootstrap/base-url investigation:

• Apply Odoo config overrides during deploy #594 merged and makes service-written Odoo web.base.url overrides apply during deploy and promotion, even when updating an older override record that had narrower apply_on phases.
• This keeps the generic Odoo driver path responsible for canonical URL mutation; no CM-specific Launchplane code was added.
• Local and CI validation passed on Apply Odoo config overrides during deploy #594: CI, Security, and CodeQL were green before merge.

Live read-only probes after the recent override work showed:

• https://cm-testing.shinycomputers.com/ returns HTTP 200.
• The page advertises canonical https://cm-testing.shinycomputers.com/cell-mechanic; the previous localhost canonical problem appears fixed.
• Tenant static assets under /cm_website/static/... return HTTP 200.
• Odoo website logo/favicon routes under /web/image/website/1/... still return HTTP 404, including the exact URLs emitted by the page.

Current diagnosis: the website addon/static assets are present, but Odoo website/logo attachment state is not being seeded/restored for the stable target. The likely next investigation is the tenant website-bootstrap.toml -> devkit website_bootstrap payload -> Launchplane stable bootstrap path. The devkit script already knows how to set website.logo from logo_path; Launchplane stable bootstrap currently applies DB-backed instance override payloads, so the remaining question is whether website bootstrap intent is being materialized into that payload for stable lanes.