Weles
Weles/Docs

Task guide

From no Weles state to one observable navigation result.

Build the CLI from its public source, confirm the installation, walk the first-use onboarding boundary, and produce your first fingerprinted navigation with captured output. Everything here runs locally; no hosted endpoint is required until you integrate the client.

Install the CLI from the canonical checkout#

The managed product catalogue provides a Weles CLI recipe for weles and weles-mcp. It uses the existing canonical wisent-ai/weles checkout on main, not an npm registry package or a second checkout. The npm prepare lifecycle compiles the CLI before installation; a compilation failure refuses the installation.

Shell
stado product install weles --surface cli --json
stado product status weles --surface cli --json
weles version

Native runtime on managed workers#

macOS worker archives include the signed Jeden CLI and jeden-sandbox-helper together under native/jeden/bin/; Linux worker archives include their native CLI. Stado and GitHub builds use the same release/native/runtime.mjs staging command and immutable input pins in .wisent-release.json. Building only the JavaScript CLI does not produce that worker payload.

Worker startup runs every native binary required by its platform with --version before acquiring credentials or starting the API. It selects them from its own release, never a host installation or an inherited WELES_JEDEN_BIN override. Page reading and capture diagnosis use that selection; model-only requests still go directly through Brama.

Each native task uses its screenshot or frame directory as Jeden's workspace. It can read those artifacts without write or command grants; the immutable worker installation is not the workspace for page evidence.

Confirm the installation#

Shell
weles version
weles doctor

Walk the authorization-boundary onboarding#

Onboarding explains what Weles will and will not execute before any browser automation runs. It never launches browser automation itself.

  1. Run weles onboarding status — it prints the current journey screen as key: value lines (add --json for the same screen as one JSON document) and starts at the authorization-boundary screen.
  2. Run weles onboarding next to reach the optional existing-data screen. Import a real Weles trajectory API export with weles onboarding import <trajectory-export.json> --host <managed-worker-hostname>, or run weles onboarding next again to keep an empty usable setup.
  3. The import operation validates the complete export before writing, returns every item as imported, unchanged, or refused, and advances onboarding only after the destination confirms at least one imported or already-persisted definition.
  4. Continue through the host-execution screen. Finish later with weles onboarding verify --receipt <receipt.json> --keys <receipt-keys.json>: completion requires cryptographic verification of a real workflow receipt and its bound evidence digest, which only a real production run can produce.

Reach one observable result#

weles open launches the fingerprinted browser (AsyncNewBrowser), navigates to the URL, and prints its result as key: value lines, or as one JSON document with --json:

Shell
weles open https://example.com --headless --text --json

Next steps#

  • CLI reference — every command and flag on weles 0.7.56.
  • Client reference — submit an approved workflow through @wisent-ai/weles-client once your deployment provides endpoint, organization ID, and token.
  • Concepts — what a workflow, trajectory, session, and receipt actually are before you depend on them.