You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Migrate Launchplane from Dokploy target/id records as implicit target identity authority to explicit provider-target records as the stable target identity boundary.
Current Status
Phase Two initial data authority setup is complete through the deployed service/workflow path. Evidence:
Provider Target Operations final audit run 26827648062 returned complete:1 for discord-blue/prod, verireel/testing, verireel/prod, cm/testing, cm/prod, opw/testing, and opw/prod.
Service health after deploy was OK on Postgres, trace launchplane_req_5e307808247b4046979fc17a26efa187.
Next action: #1104 is now unblocked and active. Cut over live target identity reads to provider-target authority while keeping Dokploy records as provider execution config until #1106 retirement.
Finish Line
Launchplane writes explicit provider-target rows on target identity mutations, backfills existing live lanes, uses provider-target records as live identity authority for deploy/promotion/read workflows, validates VeriReel/SYO/Odoo/generic-web evidence, and retires compatibility aliases/fallbacks only after production evidence is clean.
Audit must report zero unresolved mismatches before backfill apply or authority cutover.
Backfill must be dry-run first, idempotent, and fail closed on partial/conflicting records.
Dual-write errors must surface; no silent fallback.
Provider-target identity must agree with Dokploy execution metadata before any Dokploy adapter action.
Odoo and VeriReel prod cutovers happen only after lower-risk lanes produce clean deploy/promotion/health evidence.
Live Production Risks
VeriReel depends on Dokploy route metadata for base URLs and health checks, so identity cutover must preserve provider-specific execution reads.
SYO can expose product-profile/lane drift and target category/name defaults.
Odoo is highest risk because compose targets, post-deploy, overrides, backup gates, runtime identity, target replacement, and rollback all depend on exact target identity.
generic-web is shared blast radius; resolver tests must cover base-driver inheritance and route-scoped compatibility.
Existing stale explicit provider-target rows already take precedence, so audit/backfill must block conflicts before cutover.
Explicit Non-Goals
Do not add new non-Dokploy providers in this phase.
Do not move release ownership back to product, tenant, shared-addon, or local-DX repos.
Do not make ProviderTargetRecord absorb Dokploy route/runtime execution config yet.
Do not remove Dokploy execution adapters or Dokploy execution records.
Do not use broad feature flags; use audits, explicit data evidence, PR sequencing, and fail-closed validation.
Intent
Migrate Launchplane from Dokploy target/id records as implicit target identity authority to explicit provider-target records as the stable target identity boundary.
Current Status
Phase Two initial data authority setup is complete through the deployed service/workflow path. Evidence:
Next action: #1104 is now unblocked and active. Cut over live target identity reads to provider-target authority while keeping Dokploy records as provider execution config until #1106 retirement.
Finish Line
Launchplane writes explicit provider-target rows on target identity mutations, backfills existing live lanes, uses provider-target records as live identity authority for deploy/promotion/read workflows, validates VeriReel/SYO/Odoo/generic-web evidence, and retires compatibility aliases/fallbacks only after production evidence is clean.
Sequencing
Safety Gates
Live Production Risks
Explicit Non-Goals
ProviderTargetRecordabsorb Dokploy route/runtime execution config yet.