The executable contract for the YAML representation of Vis configuration.
YAMLStar returns maps with string keys. This namespace validates that exact representation: snake_case string keys ONLY (kebab-case is rejected), no recursive keywordization, and no acceptance of keyword-keyed lookalikes. Maps are closed unless their keys are deliberately user-defined (environment variables, headers, toggle ids, MCP server names, pricing/model tables, and provider request bodies).
Security consumers derive their internal policy maps through the adapters at the end of this namespace, so validation and enforcement share one contract.
The executable contract for the YAML representation of Vis configuration. YAMLStar returns maps with string keys. This namespace validates that exact representation: snake_case string keys ONLY (kebab-case is rejected), no recursive keywordization, and no acceptance of keyword-keyed lookalikes. Maps are closed unless their keys are deliberately user-defined (environment variables, headers, toggle ids, MCP server names, pricing/model tables, and provider request bodies). Security consumers derive their internal policy maps through the adapters at the end of this namespace, so validation and enforcement share one contract.
(assert-config! config)(assert-config! config source)Return a string-keyed YAML config when it satisfies the complete contract. The thrown message names each offending field path, because the raw spec problem for a closed map is an unreadable dump of the entire config.
The violation is a USER error (:vis/user-error) carrying a rendered
:vis/panel: a mistyped key deserves the field list, never a stack trace.
Return a string-keyed YAML config when it satisfies the complete contract. The thrown message names each offending field path, because the raw spec problem for a closed map is an unreadable dump of the entire config. The violation is a USER error (`:vis/user-error`) carrying a rendered `:vis/panel`: a mistyped key deserves the field list, never a stack trace.
(assert-process-jail-config! policy)Validate and return the exact internal policy consumed by process-jail.
Validate and return the exact internal policy consumed by process-jail.
The wire dialects a provider may declare. api_style remains the raw svar
escape hatch for anything outside this two-dialect world (e.g. gemini).
The wire dialects a provider may declare. `api_style` remains the raw svar escape hatch for anything outside this two-dialect world (e.g. `gemini`).
(config-error-panel fields source)Caller-facing screen for an invalid config: the offending field lines and
nothing else. Entry points print :vis/panel verbatim, so a bad YAML key
must never reach the fatal path (a Java stack trace tells the user nothing
about which key they mistyped).
Caller-facing screen for an invalid config: the offending field lines and nothing else. Entry points print `:vis/panel` verbatim, so a bad YAML key must never reach the fatal path (a Java stack trace tells the user nothing about which key they mistyped).
(explain-problems config)Best-effort, model-readable reasons a string-keyed YAML config fails the
contract — one line per offending FIELD, named by its dotted path
(search.include_gitignored_paths, providers[1].models[0].context,
mcp.servers.docs.transport): a non-string key, an unknown key (maps are
closed, with a did-you-mean when a known key is close), a missing required
key, or a value the schema rejects. Returns [] for a valid or nil map, so a
caller surfaces a config_error hint ONLY when the live config is actually
denied. This points a fix straight at the field rather than dumping the whole
opaque spec problem.
Best-effort, model-readable reasons a string-keyed YAML `config` fails the contract — one line per offending FIELD, named by its dotted path (`search.include_gitignored_paths`, `providers[1].models[0].context`, `mcp.servers.docs.transport`): a non-string key, an unknown key (maps are closed, with a did-you-mean when a known key is close), a missing required key, or a value the schema rejects. Returns [] for a valid or nil map, so a caller surfaces a `config_error` hint ONLY when the live config is actually denied. This points a fix straight at the field rather than dumping the whole opaque spec problem.
(network-config config)Derive the keyword-keyed internal egress policy from validated YAML config.
Egress filtering is one facet of the process jail: jail.enabled is the single
gate. When the jail is off the policy is empty (egress open); when on, the
jail.network block (allowed/denied/exclude domains, allow_private, rules)
is enforced alongside the filesystem and inbound-port confinement.
Derive the keyword-keyed internal egress policy from validated YAML config. Egress filtering is one facet of the process jail: `jail.enabled` is the single gate. When the jail is off the policy is empty (egress open); when on, the `jail.network` block (allowed/denied/exclude domains, `allow_private`, rules) is enforced alongside the filesystem and inbound-port confinement.
(process-jail-config config)Derive the internal process-jail policy from validated string-keyed config.
The workspace.filesystem catalog is the single source of roots. When the
jail is DISABLED (the default) nothing is confined, so every catalog root is
available and the allow list is ignored. When ENABLED,
jail.filesystem.allow selects which catalog ids enter the OS jail
(deny-by-omission). Each admitted entry's access sets RW vs read-only and
search: false marks it out of the default search sweep.
Derive the internal process-jail policy from validated string-keyed config. The `workspace.filesystem` catalog is the single source of roots. When the jail is DISABLED (the default) nothing is confined, so every catalog root is available and the `allow` list is ignored. When ENABLED, `jail.filesystem.allow` selects which catalog ids enter the OS jail (deny-by-omission). Each admitted entry's `access` sets RW vs read-only and `search: false` marks it out of the default search sweep.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |