Parses every TypeScript and JavaScript file in the current repository via ts-morph and returns a structural summary: total file count, class count, top-level function count, exported symbol count, plus a per-file breakdown. This is the first step in the Veris analysis chain — it builds the AST cache that all downstream tools (export_behavioral_graph, list_workflows, generate_verification_plan, etc.) consume. Call this once at the start of an agent session for any repo.

Exports the full behavioral graph of the current repository as JSON: nodes (every class, method, top-level function detected by ts-morph) and edges (DependsOn from imports plus real Invokes from call-expression resolution). Each node is colored by its semantic workflow domain (Authentication, Payments, Webhooks, Caching, Queue, and 20 more). Use this when you need machine-readable graph data for downstream analysis or visualization. Returns nodeCount, edgeCount, and the full nodes/edges arrays.

Computes a real behavioral diff between two git refs using git worktree (not a synthetic mock). Returns the set of impacted workflows, the added/removed/changed nodes, the per-node risk scores (blast radius, dependency fragility, runtime criticality), and a plain-English narrative of what changed. Use this on a PR branch to answer 'what behaviors are at risk in this PR?' before merging. Falls back to a synthetic 70% slice when git is unavailable so the call never fails. Defaults to comparing against origin/main, then main, then HEAD~1.

Generates a tiered verification plan for every node impacted by the current PR or graph state. Returns concrete directives at three tiers: Tier 1 (structural — syntax, schema, type, lint checks), Tier 2 (behavioral — workflow correctness, contracts, integration boundaries), and Tier 3 (adversarial — concurrency, idempotency, retry storms, replay, cache stampede, partial failure). Each directive is keyed to a specific nodeId so an agent can prioritize execution. Use this to answer 'what should I verify before merging this PR?'.

Returns an overall confidence score for the current repository plus the list of unverified behaviors (nodes flagged as risky but with no matching execution coverage). Confidence math weighs real execution history with a 14-day half-life decay — recent successful runs raise the score, recent failures or stale data lower it. Use this as the final readout after analyze_pr_behavior + generate_verification_plan, or as a gate in CI ('exit non-zero if confidence < 70'). Pass executedTargetsCount to model a what-if ('what would confidence be if 5 more targets were executed?').

Auto-clusters the entire repository graph into 25 semantic workflow domains (Authentication, Authorization, Session, Payments, Billing, Checkout, Cart, Notifications, Webhooks, Realtime, Queue, Caching, Persistence, Sync, Search, Onboarding, Profile, Admin, Analytics, AI, Routing, Orchestration, Reporting, Configuration, Infrastructure) using a weighted vote across path tokens, import tokens, and symbol tokens. Returns per-workflow narrative impact, member count, max risk, average risk, and runtime risk hypotheses. This is the workflow-first view of the repository — the most important Veris tool for understanding what a codebase actually does rather than how it's structured.

Deep-dive on a single workflow by id: returns every member node, every inference signal that placed it in this workflow (path token / import token / symbol token + weight), the top-5 highest-risk nodes with full risk breakdown, all runtime-risk hypotheses, and the adversarial probe deck. Use this after list_workflows surfaces the one you care about — typically the highest-max-risk workflow affected by a PR.

Compares the current workflow fingerprints (SHA-256 hash of sorted members + edges + signals per workflow) against fingerprints from prior Veris runs persisted in .veris/state.db. Surfaces three classes of drift: silent rewrites (member set identical but internal topology changed — most dangerous because nobody's watching), surface expansion/contraction (members added/removed), and oscillating refactors (same workflow flips back and forth across runs — usually a sign of unresolved indecision). Run after every PR merge to catch behavioral regressions before users do.

Generates concrete Tier-3 adversarial test directives per affected workflow. Each probe is a specific failure scenario plus the invariant that must hold — not a vague 'add more tests' nudge. Categories: concurrency (visibility-timeout races, write-write conflicts), idempotency (same request twice within 500ms), retry storms (50 redeliveries of same event id), replay (24-hour-old signed payload), partial failure (worker crashes after side effect before ack), cache stampede (mass expiry → thundering herd), and ordering (out-of-order event arrival). Probes are domain-aware — Payments probes are different from Caching probes. Use this to brief an agent on what to actually run against a PR before merging.

Given a time budget in minutes, greedy-allocates the highest-leverage subset of verification targets that fits in that budget. Leverage formula: (tier-leverage × workflow-criticality × node-risk) / estimated-execution-cost-in-seconds. Tier-1 targets cost ~5s, Tier-2 ~30s, Tier-3 ~120s. Returns an ordered list — execute top-down. Use this when CI minutes are scarce or when an agent needs to pick what to verify before merging within a deadline.

Counterfactual reasoning: simulates removing the named nodes from the head graph, then recomputes the behavioral diff and risk scores against the actual base. Answers 'what behaviors recover if I revert this commit / function / class?'. Useful for triaging post-incident commits — quickly see whether a revert restores prior workflow shape without actually running the revert.

Closes the verification feedback loop. External executors (any MCP-compatible coding agent, CI runner, or human) post back verification results — pass / fail / flaky / skipped — keyed to nodeId + tier + directive. Veris persists these in local SQLite state, applies them to confidence math (14-day half-life decay, flaky = half-credit), and uses them on subsequent runs to raise or lower confidence per node. Without this call, confidence is a static prior; with it, confidence reflects ground truth. Call once per batch of executed targets, not per-target — payload accepts an array.

Returns the confidence-score and execution-depth trend across the last N Veris runs persisted in local state (.veris/state.db). Confidence math uses a 14-day half-life decay over real execution results — so this surface shows whether the project's verification confidence is improving, decaying, or oscillating over time. Useful for dashboards, weekly health checks, or detecting regressions in test coverage discipline. Defaults to last 20 runs; pass limit to widen.

Returns the full timeline for a specific node across every Veris run persisted in .veris/state.db: risk score over time, execution attempts (pass / fail / flaky / skipped per tier), and the runs in which it was added, modified, or removed. Use this for forensic analysis — 'this function broke prod, what does its Veris history look like?' — or to verify that a high-risk node has accumulated enough successful executions to lower its risk weighting.

Generates a workflow-first onboarding package for a new engineer (or new coding agent) joining the repository. Writes one markdown file per workflow under veris-reports/onboarding/ — each file lists the workflow's purpose, member files, key risks, suggested first reads, plus an index.md tying them together. Beats reading raw source code in tree order. Use this when bringing a contributor up to speed on an unfamiliar codebase.

Returns the latest confidence score and drift summary across every repository registered in the user-level registry at ~/.veris/registry.json. Useful when a single logical workflow spans multiple services — e.g., a checkout flow that touches a frontend repo, an orders service, and a payments service. Surfaces the weakest-confidence repo in the fleet first so an oncall engineer or release manager knows where to look.

Adds a local repository to the user-level cross-repo registry at ~/.veris/registry.json. Subsequent calls to cross_repo_snapshot will include this repo in the fleet view. Setup-time call, typically run once per repo when bootstrapping a multi-service Veris environment.