Cleanup pass: docs, dead code, dead files, and stale config

[cbusillo]

Goal

After the product/site API and UI rebuild work lands, do a cross-repo cleanup pass that makes Launchplane and its operated site repos easier to maintain: remove dead code, delete stale docs/fixtures/workflows, reduce duplicated deployment plumbing, tighten typing, and make the remaining repo boundaries match the Launchplane-owned control-plane model.

Scope

• Launchplane code: remove dead compatibility paths, stale helpers, unused fixtures, duplicated read-model/action plumbing, and product-specific leakage in shared contracts.
• Launchplane docs: reconcile docs with the actual product/site API, driver contracts, workflow metadata, and repo-boundary decisions; delete transient or obsolete docs.
• Launchplane workflows: simplify and DRY GitHub Actions, repo workflow metadata, preview/deploy/security gates, and bot/PR automation where behavior is duplicated.
• Site repos, especially cbusillo/verireel and cbusillo/sellyouroutboard: shrink Launchplane-like scripts and workflows so they build/test/publish artifacts and call Launchplane with minimal OIDC trigger inputs.
• Odoo repos/devkit where relevant: keep Odoo source/local DX/product checks there, but remove duplicated control-plane lifecycle truth once Launchplane owns the equivalent route and records.
• Typing and best practices: improve type coverage around touched cleanup areas, prefer typed contracts over dict-shaped payloads, and avoid broad rewrites that hide behavior changes.

Suggested approach

1. Start after #152 and the dependent UI work are far enough along that old context-picker/product-config paths have replacements.
2. Inventory Launchplane and related site repos with reference searches before deleting anything; classify items as keep, move-to-Launchplane, delete, or temporary adapter.
3. Do cleanup in small PRs by ownership boundary: Launchplane API/contracts, Launchplane docs, Launchplane workflows, each site repo's workflows/scripts, then shared typing/baseline cleanup.
4. For site repos, first prove the equivalent Launchplane route/read model exists, then remove duplicated workflow/script behavior from the repo.
5. Prefer typed contract cleanup in touched areas. Do not start a broad typing rewrite unless it is the explicit PR scope.
6. Run repo-specific gates from .github/github.json; record any unavailable or pre-existing failing gate separately from cleanup regressions.

Notes

This issue was opened after the workflow metadata rollout so each repo has a durable follow-up for general cleanup that should not be mixed into metadata-only PRs.

Acceptance Criteria

• Launchplane product/site read models, docs, workflows, and repo metadata describe one DRY control-plane boundary, not four special-case products.
• Standard generic-web site repos can be onboarded or cleaned up without copying Launchplane lifecycle scripts, evidence rendering, provider mutation logic, or long-lived runtime truth into the site repo.
• Remaining site-repo workflows are thin: CI/product tests, immutable artifact publishing, product-specific smoke checks, and minimal OIDC requests to Launchplane.
• Dead code, stale fixtures, generated leftovers, obsolete compatibility docs, and unused workflow paths are removed rather than retained behind flags.
• Cleanup PRs improve or preserve typing in touched areas; any remaining repo-wide typing baseline is documented with a focused follow-up rather than ignored.
• Validation gates from each repo's workflow metadata are run or explicitly recorded as unavailable/blocking.

Relationships

• Follows backend pre-UI work: cbusillo/launchplane#161.
• Historical backend prerequisites completed: cbusillo/launchplane#168, cbusillo/launchplane#169, and cbusillo/launchplane#170.
• Historical UI rebuild prerequisite completed: cbusillo/launchplane#153; cleanup may still depend on rebuilt operator surfaces where old UI paths have replacements.
• Related repos to inspect during cleanup: cbusillo/verireel, cbusillo/sellyouroutboard, cbusillo/odoo-devkit, cbusillo/odoo-tenant-cm, and cbusillo/odoo-tenant-opw.
• Create focused repo-local issues only when a cleanup item cannot be completed from Launchplane or needs repo-owner review in that repo.
• related: Enroll preview products in Launchplane lifecycle backstop #508 - Enroll preview products in Launchplane lifecycle backstop #508
• related: Audit remaining orchestration code across product and tenant repos #510 - Audit remaining orchestration code across product and tenant repos #510

Current Status

State: Parked but newly relevant to the Odoo preview pivot. After Launchplane Odoo preview and runtime key-safety boundaries are wired, run a cross-repo hygiene pass over launchplane, odoo-devkit, and odoo-tenant-cm: remove dead/duplicated bootstrap, restore, env override, preview, and request-client scripts only after the Launchplane-owned route/record path is verified.
Next action: After cbusillo/odoo-tenant-cm#29 live preview smoke passes, inventory old bootstrap/restore/upstream scripts, duplicated provider mutation paths, and tenant-side control-plane shims; classify keep, move to devkit, move to Launchplane, or delete.
Blocked by: Parked on Odoo preview MVP proof and enough Launchplane-owned replacement coverage to safely delete old paths; no native issue blocker.
Last verified: 2026-05-16 during issue-graph audit. Existing runtime key-safety and Odoo override systems appear present in Launchplane, and odoo-devkit exposes bootstrap/restore workflow surfaces. This issue should capture cleanup after the safe preview path is proven, not block the client preview.

[cbusillo]

Metadata filename correction: .github/github.json is the current repo workflow metadata filename. Any older mention of .github/github.json in this issue should be read as .github/github.json.