Model Odoo lane data authority and rebuild sources

[cbusillo]

Objective

Model Odoo lane data authority and rebuild sources so Launchplane can safely distinguish real production lanes from provisional prod-shaped lanes and resettable testing lanes.

Finish Line

An operator can see and enforce whether an Odoo lane is authoritative, resettable from empty bootstrap, restorable from an upstream source, or protected by backup/restore proof before any destructive recreate/bootstrap/restore action runs.

Current Status

State: Created after clarifying current rollout reality: SYO and VeriReel are real Launchplane production products, OPW remains on its old non-Docker production server, and CM is not yet using the system for real production data. Some lanes named prod are currently provisional and may be safe to recreate, while real production lanes must remain protected.
Next action: Add a product/lane policy model for data authority and rebuild source before generalizing Odoo stable target replacement or bootstrap beyond CM testing.
Blocked by: None for design. Runtime identity and async operation tracking strengthen enforcement but do not block policy modeling.
Last verified: 2026-05-10; Launchplane now has lane bootstrap policy and bootstrap provenance evidence, but not a durable distinction between authoritative production data, provisional prod-shaped lanes, and resettable testing lanes.

Scope

• Add lane policy fields such as authoritative_data, bootstrap_empty_allowed, restore_from_upstream_allowed, upstream_source, requires_backup_before_destroy, requires_restore_proof, and requires_runtime_identity or equivalent names.
• Treat environment name (testing, prod) as metadata, not sufficient safety authority.
• Allow CM and OPW provisional lanes to be explicitly resettable while protecting SYO, VeriReel, and any other real production products.
• Connect the policy to Odoo stable bootstrap, stable target replacement, backup gate, restore, and operator read models.
• Document rollout states: real production, provisional prod/pre-cutover, and testing/resettable.

Acceptance Criteria

• Odoo lane read models expose whether a lane is authoritative and what rebuild sources are allowed.
• Destructive bootstrap/recreate/restore flows refuse unless the lane policy permits the requested data source mode.
• Real production lanes require backup/restore proof before destroy/recreate flows.
• Provisional prod-shaped lanes can be explicitly marked resettable without weakening real production defaults.
• Tests cover CM provisional lanes, OPW upstream-restore lanes, SYO/VeriReel protected production lanes, and unknown/default fail-closed lanes.
• Docs update operations, records, driver descriptors, and product repo contracts.

Relationships

• Blocks Add safe Odoo stable target replacement workflow #520 because stable target replacement must know whether a lane is real production or resettable before destroy/create operations.
• Related to Add service-backed Odoo stable bootstrap workflow #542 because stable bootstrap policy is one rebuild mechanism.
• Related to Replace hard-coded Odoo bootstrap allowlist with lane policy #555 because bootstrap allowlist policy is one piece of the broader lane safety model.
• Related to Make Odoo stable bootstrap a durable operation #556 because durable operations should record the selected rebuild source and policy proof.
• Related to Add driver-neutral runtime identity breadcrumbs #516 because runtime identity should be required for higher-risk lanes.

Validation

• Unit tests for policy parsing and fail-closed defaults.
• Workflow/service tests for permitted empty bootstrap, permitted upstream restore, refused real production recreate, and refused unknown lanes.
• Operator read-model tests showing lane authority and rebuild source status.

Decisions

• Do not infer production safety from the instance name alone.
• Launchplane owns policy, orchestration, evidence, and provider target proof.
• Odoo/devkit and tenant repos own how allowed data sources are materialized inside Odoo.

Open Questions

• Should upstream source references point to Launchplane records, tenant repo declarations, or both?
• Should provisional prod lanes require a time-boxed expiration before they become protected by default?
• What operator approval is required to flip a lane from provisional to authoritative?

[cbusillo]

Added focused child issue #573 for the concrete issue-backed prelaunch policy signal: CM testing/prod empty bootstrap allowed while inactive, OPW testing/prod restore-from-upstream allowed until Launchplane-managed prod launches. #564 should remain the broader data-authority model; #573 can carry the immediate enablement implementation.