Skip to content

Launchplane modularity and safety quality pause #1041

@shiny-code-bot

Description

@shiny-code-bot

Current Status

Active quality pause; several small safety/modularity slices have shipped.

Merged during this continuation:

Current state:

  • The immediate OPW/SYO troubleshooting smell has been converted into durable plans plus several low-risk boundary fixes.
  • Dokploy is more modular than before: generic-web deploy already has a provider seam, ingress env/client construction is behind an adapter, workflow service identity is configured, and records/extensions now avoid two small Dokploy-default leaks.
  • Dokploy is not yet fully replaceable. Remaining work is larger: split dokploy.py into client/target/orchestration modules and continue provider-neutral contract migration around ShipRequest, generic deploy result fields, and read models.

Recommended next action:

  • Open a child issue under this parent for the larger Dokploy adapter split before implementing it. Acceptance should require a DeployProvider protocol/fake-provider test path, generic_web_deploy.py free of direct Dokploy dependencies, and Odoo-specific compose rendering kept outside provider HTTP/client code.

Local cleanup note:

  • Multiple merged task branches remain checked out in clean worktrees. GitHub PR merges succeeded, but gh pr merge --delete-branch could not perform local deletion because another worktree has main checked out. Clean worktree hygiene is useful but separate from product behavior.

Finish Line

Launchplane's core deploy, ingress, workflow, and product-driver contracts are modular enough to support non-Dokploy, non-NPMplus, and non-GitHub providers without central rewrites, while Odoo stable deploy safety/evidence gaps are explicitly closed.

Workstreams

  • Phase 0: close urgent safety gaps that can affect live deploy behavior.
  • Phase 1: make stable deploy and Odoo post-deploy payload/evidence typed and fail-closed.
  • Phase 2: extract provider-neutral deploy and ingress adapter seams.
  • Phase 3: make driver routes descriptor-backed instead of service.py hardcoding.
  • Phase 4: split god modules and remove duplicated helper logic.

Acceptance Criteria

  • There is one canonical stable deploy authority for Odoo testing, promotion, and rollback, guarded by tests.
  • Odoo post-deploy/sanitize payloads are typed, phase-aware, redacted, and fail closed when required evidence or secret-backed runtime keys are missing.
  • Deployment records and read models expose provider-neutral target/evidence fields, with provider-specific detail demoted to adapter evidence.
  • Generic-web deploy does not import Dokploy directly; ingress route intent does not expose NPMplus-prefixed public fields.
  • Driver route metadata and service dispatch have one source of truth or parity tests that fail on drift.
  • Break-glass/provider compatibility paths are either retired or explicitly bounded with audit/evidence.

Notes

Recent completed work: PR #1036 and PR #1039 moved Odoo testing, promotion, and rollback onto the stable target replacement authority. That reduced the authority split but did not finish typed override payloads, provider-neutral contracts, or first-class evidence.

Known concrete carry-ins: OPW public ingress still needs provider/edge diagnosis; NPMplus auto-review found compatibility env cleanup and dry-run option issues; the Odoo restore override guard may still need a true production-code fix rather than test-only assurance.

Relationships

Metadata

Metadata

Assignees

No one assigned

    Labels

    planDurable planning issueplan:activeCurrent active plan

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions