Verentis

Documentation

Tokens & context

The lower-level building blocks — mint scoped tokens, generate an execution context, and validate a manifest.

dev run is built from smaller commands you can also use directly.

Mint a scoped token

verentis dev token --workspace <id>                              # scopes from ./engine.yaml
verentis dev token --scopes node.file.read --boundary /scripts   # node-bounded, like platform runs
--scopes <scope...>

Explicit scopes (default: manifest spec.permissions, else the engine default set).

--manifest <path>

Engine/app manifest to read spec.permissions from.

--boundary <path>

Confine the token to a workspace directory subtree.

--json

Output JSON with token metadata.

Generate an execution context

Write the platform execution context to a file and let the SDK auto-load it:

verentis dev context --file /scripts/transform.py --out .verentis/context.json
export VERENTIS_CONTEXT_PATH=$PWD/.verentis/context.json
python transform.py                              # SDK auto-loads the context

dev context accepts the same targeting flags as dev run (--tool, --mode, --timeout, --arg, --env, --params, --scopes, --manifest, --boundary, --branch) plus --out (default .verentis/context.json).

Validate a manifest

Check an engine or app manifest before you publish:

verentis validate engine.yaml
verentis validate ./my-project        # validate a directory

The token is a secret

Both dev token and dev context produce short-lived credentials. Treat their output — and .verentis/context.json (written mode 600) — as secrets and keep .verentis/ out of git.