Localize devkit runtime mutations

README.md

@@ -24,8 +24,8 @@ For remote environments, the stable lane model is `testing` plus `prod`.
 Launchplane-managed PR previews are a separate control-plane concern rather
 than a third durable runtime lane exposed through `platform runtime`.
 `odoo-devkit` can publish artifact images for handoff, but remote ship,
-promote, gate, and preview lifecycle flow belongs in `launchplane`, not in
-branch-oriented `odoo-devkit` commands.
+promote, gate, restore, bootstrap, update, and preview lifecycle flow belongs
+in `launchplane`, not in branch-oriented `odoo-devkit` commands.
 
 ## Command surface
 
@@ -72,8 +72,8 @@ those workspaces.
   truth for handwritten tenant code.
 - Local runtime assets live in `odoo-devkit` itself. Tenant scaffolds keep
   `[repos.runtime]` pointed at the sibling `odoo-devkit` checkout so the same
-  tracked tenant manifest can target local runtime work and explicit
-  Dokploy-managed data workflows.
+  tracked tenant manifest can target local runtime work and artifact handoff
+  without growing a repo-local remote mutation surface.
 - Runtime repo ownership remains explicit. When `[repos.runtime]` is present it
   may be path-based or repo-addressable,
   `workspace sync` materializes repo-addressed runtime inputs into
@@ -90,14 +90,10 @@ Current runtime ownership is intentionally narrow and explicit:
   `odoo-shell`, `restore`,
   `workflow bootstrap`, `workflow init`, `workflow update`, and
   `workflow openupgrade`.
-- Dokploy-managed non-local runtime targets also run natively inside
-  `odoo-devkit` for `restore`, `workflow bootstrap`, and `workflow update`
-  using the runtime repo's generated env plus Dokploy target metadata from the
-  control-plane-owned `config/dokploy.toml` and
-  `config/dokploy-targets.toml` catalogs resolved through
-  `ODOO_CONTROL_PLANE_ROOT`.
-- Those non-local targets are the stable remote lanes (`testing`, `prod`). PR
-  preview lifecycle and release orchestration stay outside `platform runtime`.
+- Non-local runtime mutation is not a devkit command surface. Stable remote
+  lanes (`testing`, `prod`) route through Launchplane service APIs, operator UI,
+  or reusable Launchplane workflows. PR preview lifecycle also stays outside
+  `platform runtime`.
 - Release actions such as ship, promote, and gate execution belong in
   `launchplane`, not under `platform runtime`.
 - non-local `workflow init` and `workflow openupgrade` remain local-only and
@@ -121,19 +117,15 @@ Current runtime ownership is intentionally narrow and explicit:
 uv run python -m unittest discover -s tests
 ```
 
-For tenant repos that keep `instance = "local"` in the tracked manifest, use
-an explicit runtime target override only for Dokploy-managed data workflows.
-Release actions should run through `launchplane`. Data workflow
-examples:
+For tenant repos that keep `instance = "local"` in the tracked manifest,
+`--instance testing` or `--instance prod` is not a shortcut for remote
+mutation. Release and non-local data actions should run through `launchplane`.
+Local and artifact-handoff examples:
 
 ```bash
-uv --directory ../odoo-devkit run platform runtime restore \
-  --manifest ./workspace.toml \
-  --instance testing
 uv --directory ../odoo-devkit run platform runtime workflow \
   --manifest ./workspace.toml \
-  --workflow bootstrap \
-  --instance testing
+  --workflow bootstrap
 uv --directory ../odoo-devkit run platform runtime publish \
   --manifest ./workspace.toml \
   --instance testing \

docs/README.md

@@ -3,8 +3,9 @@
 This repo owns the shared DX/runtime contract used to assemble tenant
 workspaces.
 
-It does not own remote release actions. Ship, promote, gate, and Launchplane
-preview lifecycle for stable remote lanes live in `launchplane`.
+It does not own remote release or non-local data actions. Ship, promote, gate,
+restore, bootstrap, update, and Launchplane preview lifecycle for stable remote
+lanes live in `launchplane`.
 
 ## Start Here
 

docs/tooling/command-patterns.md

@@ -11,9 +11,9 @@ When
 
 ## Quick Start
 
-These examples are workspace and local/data-workflow patterns. Remote release
-actions such as ship, promote, and Launchplane preview lifecycle belong in
-`launchplane`.
+These examples are workspace, local runtime, and artifact-handoff patterns.
+Remote release and non-local data actions such as ship, promote, restore,
+bootstrap, update, and Launchplane preview lifecycle belong in `launchplane`.
 
 - Sync the current tenant workspace:
 

docs/tooling/tenant-overlay.md

@@ -54,15 +54,15 @@ When
   runtime assets come from `odoo-devkit` itself.
 - The scaffold also keeps `[repos.runtime]` pointed at the sibling
   `../odoo-devkit` checkout so the same tracked manifest can keep
-  `instance = "local"` while still running Dokploy-managed data workflows
-  through an explicit runtime `--instance` override.
+  `instance = "local"` while artifact publish can stage runtime inputs for
+  Launchplane handoff.
 - The scaffold includes a repo-owned `artifact-inputs.toml` beside
   `workspace.toml` so source selection lives in the tenant repo instead of
   depending on implicit runtime defaults.
 - Website bootstrap intent, when present, also lives beside `workspace.toml` as
   `website-bootstrap.toml`. Devkit consumes that file during runtime selection
   and data workflows apply the resulting typed payload after module install.
-- Release actions for remote environments still belong in
+- Remote release and non-local data actions for shared/testing/prod belong in
   `launchplane`, not in tenant-root `platform runtime` commands.
 - The generated `Workspace Sync` and `Workspace Status` entrypoints call the
   tenant-root helper scripts so the manifest stays anchored at the tenant repo

docs/tooling/workspace-cli.md

@@ -10,12 +10,9 @@ Runtime ownership is split by target type:
   `logs`, `psql`, `odoo-shell`,
   `restore`, and
   `platform runtime workflow --workflow bootstrap|init|update|openupgrade`.
-- Dokploy-managed non-local data workflows run natively in `odoo-devkit`
-  for `platform runtime restore` and
-  `platform runtime workflow --workflow bootstrap|update`.
-- Those non-local targets are the stable remote lanes (`testing`, `prod`). PR
-  previews belong to Launchplane preview workflows in `launchplane`, not to
-  `platform runtime` as another durable lane.
+- Non-local restore/bootstrap/update, release, and preview lifecycle flow
+  belongs in Launchplane. `platform runtime` fails closed for shared/testing/prod
+  mutation instead of shelling into a sibling runtime checkout.
 - non-local `platform runtime workflow --workflow init|openupgrade` remains
   local-only and fail early with a clear `--instance local` requirement.
 - Release actions such as ship, promote, and gate execution belong in
@@ -153,9 +150,9 @@ Purpose
 - Expose the local runtime command surface through `odoo-devkit` so tenant
   overlays and generated PyCharm run configurations do not need to call a
   sibling runtime repo directly.
-- Resolve the runtime target from `workspace.toml` and execute the supported
-  local or Dokploy-backed workflow natively against the repo declared in
-  `[repos.runtime]`.
+- Resolve the runtime target from `workspace.toml` and execute supported local
+  workflows natively against `odoo-devkit`, while leaving non-local mutation to
+  Launchplane service routes and reusable workflows.
 
 Notes
 
@@ -166,15 +163,8 @@ Notes
   at a different `origin` than the manifest declares.
 - Keep the runtime repo explicit in the manifest. Tenant scaffolds point
   `[repos.runtime]` at the sibling `odoo-devkit` checkout so the same tracked
-  manifest can keep `instance = "local"` by default while still targeting
-  Dokploy-managed data restore/bootstrap/update flows through an explicit
-  runtime `--instance` override.
-- Keep the runtime repo explicit in the manifest for non-local targets because
-  `odoo-devkit` may still need external runtime metadata from that repo or its
-  managed `sources/runtime` checkout. Dokploy target definitions prefer the
-  control-plane-owned `config/dokploy.toml` route catalog and
-  `config/dokploy-targets.toml` target-id catalog resolved through
-  `ODOO_CONTROL_PLANE_ROOT`.
+  manifest can keep `instance = "local"` by default while artifact publish can
+  still stage runtime inputs for Launchplane handoff.
 - Runtime ownership remains fail-closed and explicit for non-local targets.
   `odoo-devkit` does not guess a runtime repo from `[repos.shared_addons]`,
   even if that path points at a sibling `odoo-shared-addons` checkout.
@@ -210,9 +200,9 @@ Notes
   treated as a hard conflict so environment authority stays single-source, and
   build/restore requirements are expected to live in `launchplane`'s
   `config/runtime-environments.toml` surface.
-- Native non-local ownership currently covers Dokploy-backed `restore`,
-  `workflow bootstrap`, and `workflow update`; anything else should fail closed
-  unless `odoo-devkit` grows an explicit remote contract for it.
+- Non-local `restore`, `workflow bootstrap`, and `workflow update` now fail
+  closed with Launchplane handoff guidance. Devkit should not grow arbitrary
+  checkout remote mutation flows; add or use a Launchplane service route first.
 - Public and non-local Odoo runtimes fail closed on unsafe startup credentials:
   the master password must be present and non-default, and an explicit admin
   password must be configured before the startup wrapper marks the runtime
@@ -224,12 +214,10 @@ Notes
 - Release/deploy ownership for remote environments stays in
   `launchplane`, even when the same tenant manifest is used to anchor
   local runtime context.
-- The runtime CLI accepts `--instance <name>` so a tenant repo can keep one
-  tracked local-first manifest and still run remote data workflows like
-  `platform runtime restore --manifest ./workspace.toml --instance testing`.
-- Do not treat `--instance` as a general environment-expansion hook. The
-  stable remote lane model is `testing` plus `prod`; preview runtime belongs
-  in Launchplane preview records and generation workflows instead.
+- The runtime CLI accepts `--instance <name>` for selection and artifact
+  context, but it is not a remote mutation hook. The stable remote lane model is
+  `testing` plus `prod`; those mutations belong in Launchplane service routes
+  and reusable workflows.
 - `platform runtime logs` and `platform runtime psql` are intentionally
   local-only helpers for manifest-backed debugging. They require
   `--instance local` and fail closed for non-local targets instead of falling

odoo_devkit/cli.py

@@ -372,23 +372,13 @@ def _handle_runtime_down(arguments: argparse.Namespace) -> None:
 def _handle_runtime_workflow(arguments: argparse.Namespace) -> None:
     manifest = _load_runtime_manifest(arguments)
     native_exit_code = _run_runtime_handler(lambda: run_native_runtime_workflow(manifest=manifest, workflow=arguments.workflow))
-    if native_exit_code is not None:
-        raise SystemExit(native_exit_code)
-    exit_code = run_runtime_platform_command(
-        manifest=manifest,
-        platform_subcommand="run",
-        platform_arguments=("--workflow", arguments.workflow),
-    )
-    raise SystemExit(exit_code)
+    raise SystemExit(native_exit_code)
 
 
 def _handle_runtime_restore(arguments: argparse.Namespace) -> None:
     manifest = _load_runtime_manifest(arguments)
     native_exit_code = _run_runtime_handler(lambda: run_native_runtime_restore(manifest=manifest))
-    if native_exit_code is not None:
-        raise SystemExit(native_exit_code)
-    exit_code = run_runtime_platform_command(manifest=manifest, platform_subcommand="restore")
-    raise SystemExit(exit_code)
+    raise SystemExit(native_exit_code)
 
 
 def _handle_runtime_inspect(arguments: argparse.Namespace) -> None: