VVADRA
Try freeGet startedSaved demoHandbookRoadmap

VADRA HANDBOOK · DEVELOPER PREVIEW

A clear next step.

Learn the controls. Understand the boundaries. Keep the human in charge.

01 · Getting startedYour first minute with VADRA
02 · Workspace & environmentChoose and verify a workspacePrepare your environment
03 · AI connectionsLogin status is not a live test
04 · Projects & CanvasStart a Verified workflowRevisions and Canvas branches
05 · Approvals, execution & verificationApprove bounded implementationUnderstand a proof-gated refusal
06 · Machines & cloud runnersPair, inspect and revoke machines
07 · Usage & availabilityRead usage without guessing capacity
08 · TroubleshootingRecover without widening authority
09 · Glossary & release notesTerms and the current release boundary
Contents · Getting started
01 · Getting startedYour first minute with VADRA
02 · Workspace & environmentChoose and verify a workspacePrepare your environment
03 · AI connectionsLogin status is not a live test
04 · Projects & CanvasStart a Verified workflowRevisions and Canvas branches
05 · Approvals, execution & verificationApprove bounded implementationUnderstand a proof-gated refusal
06 · Machines & cloud runnersPair, inspect and revoke machines
07 · Usage & availabilityRead usage without guessing capacity
08 · TroubleshootingRecover without widening authority
09 · Glossary & release notesTerms and the current release boundary

Current chapter: Getting started

Getting started

Your first minute with VADRA

AVAILABLE · stated scope

What this does

Start with a workspace you choose and explicit permission for local checks.

Where to find it

Open your operator's local URL → Set up VADRA. Public visitors can use Try demo.

Before you begin

Local package installed from its README/lockfiles: Node 22 deployment baseline, pnpm and Python 3.11. Official Codex/Claude Code CLIs are separate installs.

Step by step

  1. Click Set up VADRA; enter a workspace name and Git repository path.
  2. Click Verify workspace, then continue and choose Use this machine.
  3. Check optional providers explicitly or skip them; select Start using VADRA.

What you should see

Returning configured users see Dashboard. Public /demo needs no account or CLI.

If something goes wrong

If a prerequisite is missing, use the workspace or environment chapter. Do not put credentials into VADRA.

Availability & limits

Protected local execution currently requires macOS containment. Ubuntu public preview is saved replay only.

Related articlesChoose and verify a workspaceLogin status is not a live testPrepare your environment
Next: Choose and verify a workspace →

Workspace & environment

Choose and verify a workspace

AVAILABLE · stated scope

What this does

Bind work to a real Git directory rather than an assumed location.

Where to find it

Onboarding → Choose your workspace. Later: Settings → Workspace → Validate and save.

Before you begin

An existing local Git repository accessible to the local server.

Step by step

  1. Enter a name and path, or click Browse folders.
  2. Use the directory breadcrumbs/parent control; choose Select this folder. No files are read by this browser.
  3. Click Verify workspace. Continue only after verification succeeds.

What you should see

Folder available, Git repository detected and Workspace verified appear after the real check. Editing the path invalidates verification.

If something goes wrong

Check the folder exists and is a directory/Git repository. Do not select a different repository merely to clear an error.

Availability & limits

Browser folder browsing is local-server functionality, unavailable to anonymous public visitors. Project metadata alone is not execution authority.

Related articlesPrepare your environmentApprove bounded implementation
← Previous: Your first minute with VADRANext: Prepare your environment →

Workspace & environment

Prepare your environment

PREVIEW · stated scope

What this does

Understand what the selected local Verified workflow needs before starting.

Where to find it

Projects → Check environment → Prepare environment.

Before you begin

The local product, official CLIs and the intended configured repository. Existing authentication should not require login again without a stated cause.

Step by step

  1. Click Check environment. Opening Projects alone does not run the check.
  2. Read each blocker and open Prepare environment for its next safe action.
  3. Resolve the stated issue, then click Re-check. Use Help for a pending guard/model proof.

What you should see

Ready for local verified work only when the stated checks pass. Green means passed; amber pending/stale/degraded; red failed; neutral optional/disabled.

If something goes wrong

Mutation guard PENDING needs the explicit operator scratch probe. Model proof PENDING needs current eligible evidence; a separately consented live check may use allowance. A degraded/read-only workspace is not execution-ready.

Availability & limits

Optional Web tools do not block local CLI work. Re-check does not install, change settings, open tabs or infer. Preparation is not an artifact verdict.

Technical details for operators

The guard probe is an explicit operator command: services/hermes-core/.venv/bin/python scripts/model_lock_probe.py --evidence-root <your-runtime>/model-lock. It uses the existing subscription for two scratch requests, up to ten minutes each. Do not retry while a child is active. Close guide does not cancel a provider child. CLI/model/contract changes require fresh evidence; never force pending evidence green.

Related articlesChoose and verify a workspaceLogin status is not a live testRecover without widening authority
← Previous: Choose and verify a workspaceNext: Login status is not a live test →

AI connections

Login status is not a live test

AVAILABLE · stated scope

What this does

Know exactly what your local provider connection has proved.

Where to find it

Onboarding → Connect your AI; Settings → AI providers.

Before you begin

Official CLIs installed and authenticated through their own login flows. Never enter provider passwords, cookies or keys into VADRA.

Step by step

  1. Click Check local Codex connection or Check local Claude connection (Settings has explicit status refresh).
  2. If signed out, use the official local codex login or claude auth login flow.
  3. Only when needed, click Test live connection. This separate request uses a small amount of your selected allowance.

What you should see

Installed, authenticated and live-check results remain distinct. Successful observable inference includes a bounded model label.

If something goes wrong

Read the actual class: auth failure, quota/rate limit, timeout, refusal or local validation error. Do not label refusal as quota or repeat unchanged checks for footage.

Availability & limits

Login ≠ live request ≠ execution-ready ≠ completed task ≠ independent review ≠ protected authorization. No automatic API-key billing fallback.

Related articlesPrepare your environmentRead usage without guessing capacityRecover without widening authority
← Previous: Prepare your environmentNext: Start a Verified workflow →

Projects & Canvas

Start a Verified workflow

AVAILABLE · stated scope

What this does

Choose how work proceeds and keep human approval explicit.

Where to find it

Projects → New project → project composer.

Before you begin

A verified workspace, eligible local providers and environment readiness.

Step by step

  1. Create/open your project; enter a bounded goal and allowed scope.
  2. Keep Verified workflow selected (the default). Choose Debate only intentionally when available.
  3. Read the real plan and answer planner questions in the console. Request a revision when necessary.

What you should see

A versioned plan and review appear before the canonical approval checkpoint.

If something goes wrong

Follow the visible question/blocker. Missing required reviewers still block their operation.

Availability & limits

Starting planning is not approval to execute, push or deploy. The full live artifact-review workflow remains Preview.

Related articlesRevisions and Canvas branchesApprove bounded implementationUnderstand a proof-gated refusal
← Previous: Login status is not a live testNext: Revisions and Canvas branches →

Projects & Canvas

Revisions and Canvas branches

AVAILABLE · stated scope

What this does

Keep both chosen and abandoned directions visible.

Where to find it

Project workspace → revision controls → Version story / Canvas.

Before you begin

An existing project with a persisted plan.

Step by step

  1. Submit a bounded plan revision.
  2. Read the interpreted change. Use Change/reject if it is wrong; confirm only the intended interpretation.
  3. Open Canvas and the plan-version documents to inspect accepted and abandoned branches.

What you should see

Plan versions and branch history persist. Canvas's own legend distinguishes travelled task paths from unvisited ones.

If something goes wrong

Do not recreate earlier versions for a cleaner recording. Inspect the existing plan/version history.

Availability & limits

Canvas lines describe task history. Roadmap lines describe product development. A plan review is not an artifact review.

Related articlesStart a Verified workflowApprove bounded implementation
← Previous: Start a Verified workflowNext: Approve bounded implementation →

Approvals, execution & verification

Approve bounded implementation

PREVIEW · stated scope

What this does

Authorize only the reviewed plan, target and bounded execution envelope.

Where to find it

At final_human_approval, follow the workspace CTA to the canonical console.

Before you begin

A reviewed current plan, verified pinned repository/machine and an available approval action.

Step by step

  1. Inspect the current plan, target repository and permitted actions.
  2. Choose the maximum automatic repair rounds for this approval.
  3. Click Approve & execute once. Inspect execution, actual tests and the separate artifact-review result.

What you should see

Only an accepted, bound approval launches implementation. Genuine repairs require fresh review; missing proof still blocks protected actions.

If something goes wrong

If files were created before a failure, reconcile evidence first. execution_already_attempted means the consumed attempt cannot be replayed: do not repeat approval or edit runtime state.

Availability & limits

The preserved acceptance task implemented files and ran 35 tests, but result recovery blocked independent artifact review. Do not infer a verdict from tests or a plan critic.

Technical details for operators

Bindings include plan/version/digest, repository and machine. Safe defaults do not grant push, deployment, system changes or credential access. UI timeout is not proof a child stopped.

Related articlesUnderstand a proof-gated refusalRecover without widening authorityRevisions and Canvas branches
← Previous: Revisions and Canvas branchesNext: Understand a proof-gated refusal →

Approvals, execution & verification

Understand a proof-gated refusal

AVAILABLE · stated scope

What this does

Separate technical completion from permission to take a protected action.

Where to find it

/demo → Final evidence-bound decision; live work exposes its own actual verdict when reached.

Before you begin

No account is needed to inspect saved demo evidence.

Step by step

  1. Keep the Deterministic demo / saved protocol evidence label visible.
  2. Follow Blind spot → Repair → Fresh independent re-verification.
  3. Read external_action_astra_proof_missing, External actions 0 and Models used Not available.

What you should see

Missing required target-bound proof results in refusal, not an inferred approval.

If something goes wrong

Inspect the required proof. Do not substitute another model, a general audit or readiness evidence for required Astra-specific artifact proof.

Availability & limits

The public replay is not a live model run. Never splice its verdict into an unfinished local task.

Related articlesApprove bounded implementationYour first minute with VADRA
← Previous: Approve bounded implementationNext: Pair, inspect and revoke machines →

Machines & cloud runners

Pair, inspect and revoke machines

AVAILABLE · stated scope

What this does

Register where bounded execution capacity exists, without expanding authority.

Where to find it

Machines → Add another machine; select a registered machine for details and Revoke machine.

Before you begin

A runner installed on an operator-controlled machine and operator-provided connectivity. Non-local control planes require the configured secure transport boundary.

Step by step

  1. Click Add another machine, then generate a pairing session.
  2. Run the shown join command on that machine before the ten-minute code expires. Never record the code or command.
  3. Confirm the waiting machine in VADRA, inspect heartbeat/capabilities, and use Revoke machine when access should stop.

What you should see

One-use enrollment issues a scoped credential; revocation denies further authenticated communication.

If something goes wrong

Expired code? Generate a new session. Offline runner? Check operator-provided network and runner health; do not fabricate connected status.

Availability & limits

Isolated runner processes validate the protocol, not production multi-host GPU/cloud jobs. No automatic cloud provisioning, NAT traversal or SSH management. Public demo nodes are illustrative.

Related articlesApprove bounded implementationRead usage without guessing capacity
← Previous: Understand a proof-gated refusalNext: Read usage without guessing capacity →

Usage & availability

Read usage without guessing capacity

PLANNED · stated scope

What this does

Distinguish observed activity from a reliable subscription balance.

Where to find it

Provider live-result/error messages and existing local observation surfaces; Roadmap describes unvalidated capacity features.

Before you begin

A supported, identified observation source before any capacity conclusion.

Step by step

  1. Read the provider's actual error and observation freshness.
  2. Keep quota domain, reset window and source separate when available.
  3. When no reliable balance is available, treat it as Unknown. Wait for an evidenced reset rather than buying or switching automatically.

What you should see

Accurate bounded observations—not an invented remaining percentage or bill.

If something goes wrong

A timeout, safety refusal and parsing failure are not exhausted quota. Resolve the stated blocker.

Availability & limits

Model-reported token counts are not a subscription balance. Monitoring is not routing; reliable automatic capacity routing is planned, with no paid fallback or reviewer substitution.

Related articlesLogin status is not a live testRecover without widening authority
← Previous: Pair, inspect and revoke machinesNext: Recover without widening authority →

Troubleshooting

Recover without widening authority

PREVIEW · stated scope

What this does

Take one safe next action based on the actual failure.

Where to find it

The stopped work card, its evidence and Projects → Prepare environment.

Before you begin

Preserve the current run and inspect existing effects before a retry.

Step by step

  1. Authentication not ready: use official login only if genuinely signed out; expected result is authenticated status.
  2. MODEL_LOCK_VIOLATED / pending guard: inspect model/guard evidence and use the explicit preparation instructions; expected result is new valid evidence, not an override.
  3. malformed_output / timeout: reconcile child and filesystem evidence; expected result is a supported checkpoint, not duplicate work.
  4. execution_already_attempted: stop re-approval. Preserve the consumed attempt and obtain a bounded product repair; no second executor should launch.

What you should see

Failures remain historically visible. A later successful check is new evidence, not a rewritten PASS.

If something goes wrong

If no supported recovery exists, keep the task stopped. Use saved demo only with an explicit replay label.

Availability & limits

No hidden API advancement, manual runtime JSON changes, provider-safety bypass or automatic billing change.

Related articlesPrepare your environmentLogin status is not a live testApprove bounded implementation
← Previous: Read usage without guessing capacityNext: Terms and the current release boundary →

Glossary & release notes

Terms and the current release boundary

PLANNED · stated scope

What this does

Know what a product label does—and does not—promise.

Where to find it

This handbook, Roadmap and the dated release acceptance records.

Before you begin

None; public documentation contains no account or runtime evidence.

Step by step

  1. Available means validated within the stated scope; Preview means implemented with explicit limits; Planned is not available yet.
  2. A machine supplies capacity, a model proposes/reviews work, and VADRA enforces whether evidence permits an action.
  3. Read the 2026-09-18 closeout boundary: setup and saved replay validated; live artifact-review completion blocked.

What you should see

Clear expectations before choosing a workflow or recording a demonstration.

If something goes wrong

When a status conflicts with a task's current evidence, trust the runtime safety gate; do not assume the roadmap authorizes work.

Availability & limits

PWA installation is not a native filesystem bridge. Extra provider/API-key onboarding and automatic Web planning remain separate future integrations. Engineering closeout is not independent release certification.

Related articlesYour first minute with VADRAApprove bounded implementationRead usage without guessing capacity
← Previous: Recover without widening authority
On this page

Your first minute with VADRA

What this doesWhere to find itStep by stepExpected resultRecoveryLimitsExplore the roadmap →