Separate Odoo bootstrap provenance from deployment evidence

[cbusillo]

Objective

Separate Odoo bootstrap operation evidence from artifact deployment provenance so Launchplane does not claim a data bootstrap deployed or verified an artifact it did not actually deploy.

Finish Line

After an Odoo bootstrap, Launchplane records exactly what changed: bootstrap run status, post-deploy status, verification status, observed runtime identity, and whether current environment inventory should be advanced, retained, or marked stale.

Current Status

State: First implementation slice merged in PR #560. Launchplane now records bootstrap-specific evidence, result status split (bootstrap_run_status and readiness_status), and bootstrap_record_id on inventory so failed/partial bootstrap attempts remain visible without moving the current deployment pointer.
Next action: Runtime identity comparison remains related follow-up through #516. Full async operation tracking remains separate in #556.
Blocked by: None for the merged status/provenance slice.
Last verified: 2026-05-10; PR #560 CI, Security, and CodeQL checks passed before merge.

Scope

• Add or reuse a record type for Odoo bootstrap operations distinct from artifact deployment records.
• Split statuses into bootstrap execution, post-deploy application, health verification, canonical verification, logo verification, runtime identity verification, and overall readiness.
• Define inventory update rules for full success, bootstrap-success/verification-fail, bootstrap-fail-before-mutation, and unknown/timeout states.
• Preserve previous deployment artifact/source evidence without re-stamping it as newly deployed unless runtime identity proves it.
• Make read models surface stale, partial, or unverifiable current state explicitly.
• Update workflow/service responses so operators can distinguish "bootstrap did not run" from "bootstrap ran but verification failed".

Acceptance Criteria

• A bootstrap run that succeeds but fails canonical/logo verification does not report bootstrap_status=fail as the only top-level truth.
• Launchplane can mark environment state as partially_bootstrapped, verification_failed, stale_inventory, or an equivalent explicit state rather than silently retaining old inventory as current.
• Deployment records are not used to assert a fresh artifact deployment when no artifact deployment occurred.
• Runtime identity, when available, is recorded as observed evidence and compared to expected identity.
• Tests cover all major mutation/verification combinations and inventory/read-model outcomes.
• Docs explain the difference between artifact deployment provenance, data bootstrap provenance, and public readiness.

Relationships

• Blocks Add service-backed Odoo stable bootstrap workflow #542 because the bootstrap workflow should report partial success accurately before further CM testing repair runs.
• Blocks Add safe Odoo stable target replacement workflow #520 because stable target replacement needs truthful provenance before old targets are destroyed.
• Related to Add driver-neutral runtime identity breadcrumbs #516 because runtime identity breadcrumbs provide observed runtime proof.

Validation

• Unit tests for status mapping and inventory advancement/retention/stale marking.
• Service response tests for partial success and timeout states.
• Read-model serialization tests for expected vs observed runtime/bootstrap state.
• Live CM testing run should show bootstrap/post-deploy/canonical/logo as separate fields.

Decisions

• Bootstrap is not the same thing as artifact deployment.
• Partial success is a first-class operator state, not a generic failure string.

Open Questions

• Should bootstrap evidence live on deployment records as a new evidence field or in a separate bootstrap operation record referenced by inventory?
• How should operator UI prioritize stale inventory versus last known good deployment evidence?
• What state should be used when the service loses the HTTP connection but the Dokploy schedule continues running?

[cbusillo]

Status update 2026-05-10:

Merged #565 as a follow-up to #560. Bootstrap provenance now handles post-deploy helper exceptions as a structured partial failure: the bootstrap execution can be recorded as successful while post-deploy/readiness fails, and the environment inventory keeps the previous deployment pointer plus the latest bootstrap evidence pointer.

Verified on #565 and post-merge main:

• CI: success
• Security: success
• CodeQL: success
• code scanning open alerts: 0
• Dependabot open alerts: 0

Remaining provenance work: runtime identity comparison (#516), fuller async operation records (#556), and read-model/UI surfacing for stale or partial bootstrap states.