Extension Support

Extensions are explicit descriptors, not hidden runtime plugins.

The page separates discovery, explicit execution, and custom remote execution so users do not have to infer the boundary from code.

• core commands do not execute extension providers at runtime
• top-level extensions is parsed for discovery and inspection
• explicit check execution happens through ota extensions --run <name>
• explicit export publication happens through ota extensions --publish <name>
• custom remote execution is selected by execution.backends.remote.provider
• use check_provider when a repo check must stay explicit but still be runnable
• use export_provider when a publish or export step should stay separate from core commands
• use backend_provider when ota must delegate remote task execution to your own transport or platform

• ota doctor stays core-focused
• ota run stays task-focused
• ota up stays repo readiness focused
• ota check stays check-focused

This page describes the current shipped seam and the structured contract for custom remote execution.

extensions:  release-check:    kind: check_provider    command: ota-ext-check    api_version: 1    description: Run a custom repo readiness check   release-upload:    kind: export_provider    command: ota-ext-upload    api_version: 1    description: Upload the release bundle to an artifact endpoint   remote-shell:    kind: backend_provider    command: ota-ext-remote-shell    api_version: 1    description: Execute tasks through a custom remote backend    config:      transport: ssh      workspace_root: /workspace

• a readiness checker exists as contract data without becoming hidden runtime behavior
• a release flow needs a clearly named publish seam
• a remote backend needs a structured request and response contract
• an agent or CI job needs to inspect extension intent before running it
• the user should understand the boundary from one page instead of reverse-engineering the runtime

When ota hands execution to a backend_provider, the provider gets a structured request and must return a structured response.

That makes the adapter easy to debug and keeps the contract stable across HTTP, SSH, queues, or custom platform APIs.

{  extension_id: "remote-shell",  extension_kind: "backend_provider",  api_version: 1,  command_context: "run",  repo_context_path: "/workspace/repo",  working_dir: "/workspace/repo",  task: {    name: "build",    command: "pnpm build",    mode: "capture",    target: "sandbox-dev",    cwd: "/workspace",    environment: {      NODE_ENV: "production"    }  }}

{  ok: true,  result: {    exit_code: 0,    stdout: "build succeeded\n",    stderr: "",    target: "sandbox-dev"  },  errors: []}

• not automatic plugin execution
• not a hidden extension framework
• not a replacement for tasks
• not a general-purpose runtime plugin host