Skip to main content

Module codemode

Module codemode 

Source
Expand description

Implements soma-application’s [CodeModePort] over soma-codemode’s sandboxed JS snippet runner (plan section 3.20, “CodeModeExecutor” in section 5’s illustrative flow).

There is exactly one Code Mode execution engine in the workspace (soma_codemode::execute::execute_inline, which spawns the bounded soma-codemode-runner subprocess); this adapter calls it directly rather than re-implementing any part of the runner, sandbox, or result-shaping pipeline — the same engine soma-provider-adapters::codemode bridges to for drop-in providers.

CodeModeExecuteRequest::input is not yet threaded into the snippet: the runner’s Start protocol message has no side-channel for caller-supplied input today. This mirrors the identical, already-documented limitation on soma_provider_adapters::codemode::CodeModeSnippetProvider, not a new gap introduced here.

CodeModeConfig::enabled (default false) is checked explicitly by this adapter before delegating to execute_inline, unlike soma_provider_adapters::codemode::CodeModeSnippetProvider and execute_inline itself, neither of which consult the flag. No action, CLI command, or REST route dispatches to codemode_execute yet (see crates/soma/domain/src/actions.rs), so this check has no observable effect today; it exists so a future PR that wires a live surface to this port gets a clear codemode_disabled error instead of silently running snippets through a config the operator marked disabled.

Structs§

CodeModeApplicationPort