Slopo reports a bad embedding configuration as the two words "Embedding failed."
on stdout, with the real reason in its agent log. That is a slow way to learn
that a model string has the wrong provider prefix, or that the dimensions do not
match what the model actually returns — the second of which is expensive, because
slopo freezes the dimensions into the index at first use.
`status` now does three things instead of one: it reports the resolved settings,
it runs `slopo --version` through the shell seam, and it makes one tiny embedding
request against the configured endpoint and compares the returned width with the
configured one. Verified against a real Ollama: a correct config reports ok, a
dimension mismatch names both numbers, and a wrong model returns the endpoint's
own 404 rather than a silent failure minutes into an embed.
The probe is a direct fetch rather than a shell call, because it is one small
HTTP request and does not belong behind a boundary that exists to confine
filesystem writes.
Two smaller things this needed:
- the sandbox policy is now resolved once at the top of execute, so `status` can
use it without a second resolution
- provider-prefix stripping is an allow-list, not "drop the first segment".
`unclemusclez/jina-embeddings-v2-base-code:latest` is a real model name with no
prefix at all, and an unknown first segment is left alone so a wrong guess is
visible in the reported `sentModel` rather than silent
Three things live here: where the plugin keeps its files, how it renders a
slopo config, and how it finds, installs and invokes the binary.
The adapter is driven by behaviour observed against slopo 0.8.0 rather than by
its documentation:
* --config is a global option and must precede the subcommand
* every path is written absolute, because slopo resolves relative paths
against the process working directory, not against the config file
* unknown config keys are a hard error, so the renderer writes from a closed
allow-list
* the embedding API key is never written at all -- slopo reads
SLOPO_EMBEDDING_API_KEY from the environment ahead of the file, so the
secret stays out of every file this plugin touches. Enforced in pruneConfig
rather than at the call site, so no future caller can leak it by passing one.
explainFailure maps slopo's deliberately terse agent-facing messages onto a
message and a next step, and reads the log tail because stderr alone leaves the
agent with no move: on a real failure stderr said "Embedding failed." while the
log named the exact litellm parameter that was rejected.
installEnv redirects UV_TOOL_DIR, UV_TOOL_BIN_DIR and UV_PYTHON_INSTALL_DIR
into $DSH_HOME. Only two directories in this container are persistent mounts;
~/.local, where uv installs by default, is on the container's writable layer
and does not survive a recreation.
Every path the plugin owns is under $DSH_HOME. Only two directories in the
container this runs in are persistent volumes ($DSH_HOME and the workspace
root); $HOME/.local -- where 'uv tool install' puts slopo and its CPython by
default -- is on the container's writable layer and dies on recreation, not
merely on restart.
renderSlopoConfig writes from a closed allow-list because slopo treats an
unknown config key as a hard error, and quotes every scalar because a path
can contain a colon or a leading dash. Verified against slopo 0.8.0 itself:
it reads the generated file back with no complaint and round-trips all 19
keys. The embedding API key is deliberately absent -- slopo reads
SLOPO_EMBEDDING_API_KEY from the environment ahead of the YAML value, so the
secret never lands on disk.
dsh-slopo agent