Veda Lane

Veda Lane

Veda is an execution adapter and oracle lane, a way to run a bounded task through an alternate backend, model, or persona when the execution router has already decided a Veda mechanism is justified. It is not "the Gemini tool" or "the Opus tool", and it does not own model routing: backend/model resolution uses live discovery and model judgment (skills/model-resolution); this skill covers how to execute correctly through Veda once chosen. Probe the installed pair at runtime; delegate through Fabric's Veda runner when it works, else the direct veda CLI; when neither is available, the normal Pi path carries the work.

Core Principle

Veda output is advisory. Probe availability instead of trusting claims (no hard-coded "broken" or "works" rules), select models/personas from the runtime catalog, delegate through the simplest supported path, and verify load-bearing conclusions against source/tests/runtime evidence.

When to Use / NOT

• Use when: hard architecture, difficult debugging, high-risk review, frontend/design reasoning, an independent second opinion, or a very hard ambiguous problem justifies a stronger or different model family.
• NOT when: normal implementation (Veda is never mandatory); when unavailable, fall back to native execution and report honestly instead of faking a result.

Workflow

1. Probe once per session. Use veda --version, veda models (installed backends and aliases), and veda personas (built-in versus locally installed). Inspect other host inventories directly when they affect the lane; runtime-capabilities.py is an optional aggregate diagnostic.
2. Pick the lane by task, personas map to execution-router roles: navigator-plan → NAVIGATOR, reviewer → REVIEWER, frontend / frontend-auditor → FRONTEND-CRITIC, worker → WORKER, deep → SOLVER/JUDGE/VERIFIER (k× cost, only for hard ambiguous problems). The persona picks the behavior; skills/model-resolution picks the backend/model from the runtime catalog, a UI-critique lane needs a UI-capable reasoning model, whichever provider currently offers one.
3. Select models from the runtime catalog only, veda models <backend>, agy models. Never hard-code a slug: AGY-hosted Claude may or may not exist in the installed catalog; Claude opus rides the claude-code backend when installed.
4. Delegate through the simplest supported path. Prefer Fabric's agents.run({ runner: "veda", persona, model }), a one-shot headless child at the outer fabric_exec boundary (see the installed pi-fabric docs/agents.md, "Veda runner"). If the installed Fabric/Veda pair rejects it, fall back to the direct CLI and note the version pair, do not encode a temporary incompatibility as a permanent rule.

The Pi backend bridge

veda -b pi routes to whatever Pi has configured, the abstraction is Veda → Pi backend → currently configured Pi provider/model, so new Pi providers become usable lanes automatically. Re-verify at runtime: Veda's Pi backend may not enumerate Pi's catalog (veda models pi has reported models (unavailable)), discover Pi models with pi --list-models, pass an explicit model, and one-shot probe the lane before trusting it. 5. Parse structured output where the persona provides it (the worker persona's report file, a reviewer pass/needs-fix verdict), not prose; Fabric's Veda runner returns a normalized result for programmatic use. 6. Verify load-bearing findings against source/tests/runtime before acting on them.

CLI mechanics (direct path; verified on veda 0.75.x)

• -S <task> isolates selection and conversation under <project>/.veda/sessions/; reuse one session across plan/worker/review. .veda/ is ignored runtime state, never commit it.
• Quote prompts with single quotes (backticks inside double quotes execute as command substitution); read stdout and stderr separately, or use -o file.md.
• Built-in personas: navigator-plan, navigator-chat, reviewer, worker; anything else listed by veda personas is locally installed or custom, do not assume it exists elsewhere.

Rules

• Veda is never mandatory and never runs for routine implementation.
• Advisory output: load-bearing conclusions require source/tests/runtime verification.
• Model and persona selection comes only from the runtime catalog (veda models [backend], veda personas, agy models when present).
• Personas never write repo files outside their delegated slice; you validate and integrate. Failed or unauthenticated calls are reported honestly, never faked.

Red Flags

• Hard-coding model slugs or "runner broken / runner works" claims instead of probing the installed pair. HARD-GATE.
• Invoking Veda for routine implementation, or making it a mandatory phase.
• Faking a persona result when a call fails or is unauthenticated. HARD-GATE.
• Committing .veda/ runtime state.

Verification

• Availability probed and recorded (versions, installed backends, personas).
• Structured outputs parsed where applicable (report.yaml, review status).
• Load-bearing findings verified against source/tests; fallback honestly reported when Veda is unavailable.

References

No reference capsules, the skill is self-contained; routing policy lives in evidence-router.