Restore supported local Odoo runtime config resolution

[shiny-code-bot]

Finish Line

Local Odoo workspaces run supported local runtime commands without retired Launchplane file config or direct production DB access.

Current Status

State: In review; implementation is complete on fix/78-local-runtime-config.

Implementation PR: cbusillo/odoo-devkit#79.

Validation: 169 tests passed with 1 expected skip; Ruff format/lint, package build, CLI smoke, live workspace sync/runtime inspect/runtime select, Docker Compose config, proof-value redaction, changed-file PyCharm inspection, and independent follow-up reviews are green.

Next action: watch PR checks and review feedback, fix any branch issues, then merge through the protected-branch flow.

Blocked by: none.

Waiting for: GitHub checks and review state on PR #79.

Last verified: July 16, 2026.

Ownership Boundary

odoo-devkit owns local Odoo DX, workspace generation, and local runtime commands. Launchplane owns shared/testing/prod runtime records, managed secrets, and remote lifecycle operations.

Do not solve this by:

• restoring config/runtime-environments.toml as Launchplane authority;
• reading the Launchplane production database from an arbitrary checkout;
• copying shared/testing/prod runtime or secret values into tenant manifests;
• making local DX depend on unsupported direct-DB Launchplane CLI behavior;
• adding non-local mutation behavior to platform runtime.

A service-backed Launchplane read contract is acceptable only if it is separately specified, scoped, authenticated, redacted where appropriate, and explicitly intended for this use. Until then, local runtime configuration must remain an operator-local devkit concern with a typed fail-closed boundary.

Acceptance Criteria

• platform runtime select, inspect, up, and local workflow commands have one documented supported runtime-input path.
• A freshly materialized workspace can run runtime inspect --instance local after documented operator setup.
• Local runtime inputs are typed, context/instance scoped, and fail closed when required values are absent or mismatched.
• Secret values are never written to tracked manifests, generated docs, command output, or test fixtures.
• Testing/prod operations remain Launchplane-owned and non-local devkit mutation continues to fail closed.
• Error messages and docs no longer mention a harbor checkout or the retired config/runtime-environments.toml authority path.
• Tests cover missing configuration, context/instance mismatch, explicit local payload resolution, legacy-file rejection, and the supported workspace command path.
• Shared docs and generated workspace guidance are updated in the same change.
• A live workspace sync plus a safe local runtime inspect smoke succeeds with the supported contract.

Validation

• uv run python -m unittest discover -s tests
• uv run ruff format --check .
• uv run ruff check .
• uv build
• uv run platform --help
• Live platform workspace sync and local runtime-inspect smoke against a non-secret proof manifest.
• Changed-file JetBrains/PyCharm inspection.

Relationships

• Follows completed Launchplane lifecycle-ownership work in cbusillo/launchplane#1526 and Odoo driver ownership work in cbusillo/launchplane#1529.
• The Launchplane config boundary is authoritative: DB-backed managed runtime records must not be replaced by checked-in or operator-local Launchplane file authority.
• Related tenant workflow-thinning plans may be re-evaluated after local DX is restored, but this issue does not own remote lifecycle orchestration.