vulkro-sf ai

Configure the local AI layer for Vulkro for Salesforce: pick a model, point at a runtime, and self-test it. The configuration is CLI-only (no config files); the selection is stored in the shared ~/.vulkro/scans.db settings table and is shared with the general vulkro binary, so a model configured once serves both CLIs.

The AI layer is opt-in and advisory. It never changes a deterministic finding, its severity, the AppExchange-readiness report, the SARIF / SBOM output, or an exit code. The published benchmark is AI-free. By default the layer talks to a local Ollama runtime on loopback, so nothing leaves your machine: a loopback model is allowed even under VULKRO_OFFLINE=1, while a cloud endpoint is refused offline.

vulkro-sf ai is a thin mirror of the core vulkro ai command group: every sub-action delegates to the same shared handlers and reads and writes the same settings. It exposes the configuration subset (setup / list / use / pull / status / test / off); the core binary additionally ships ai targets, ai chat, and ai ask. See vulkro ai for the core group.

Because it only configures a local model and never scans the licensed surface, vulkro-sf ai works without being signed in.

Synopsis

vulkro-sf ai <setup|list|use|pull|status|test|off> [flags]

Sub-actions

Sub-action	What it does
setup	Interactive wizard: install Ollama if missing (only after an explicit y/N, from the official source), probe the machine, recommend a model, pull or point at it, self-test, save.
list	List installed models plus the Tier-1 recommended set (Apache-2.0 / MIT) with size and license; the current model is marked.
use <MODEL>	Set the active model. Validates it is installed and offers to pull it if not.
pull <MODEL>	Pull a model with a progress bar (wraps the runtime's model pull).
status	Show the current model and runtime, reachability, warm state, offline mode, and the model's license tier.
test	Run a canned self-test against the active model and print the verdict.
off	Disable the AI layer (deterministic-only). Keeps the model selection so a later setup restores it.

vulkro-sf ai setup

Interactive on a TTY; fully scriptable in CI via the flags below (it never blocks on a prompt when they are supplied). A Tier-1 (Apache / MIT) model may auto-pull with --yes; a bring-your-own (Tier-2) model is never auto-pulled.

Flag	Description
--model <MODEL>	Model tag to use, skipping the interactive picker. Example: qwen2.5-coder:7b.
--url <URL>	OpenAI-compatible runtime base url. Default: http://127.0.0.1:11434/v1 (local Ollama). For --byok, a cloud url.
--yes	Answer yes to any prompt (start the daemon, pull a missing Tier-1 model without asking). Never auto-pulls a bring-your-own model.
--byok	Set up bring-your-own-key cloud mode instead of a local model. The API key is read from VULKRO_AI_KEY only and is never written to disk. Cloud means code context leaves the machine, and it is refused under VULKRO_OFFLINE.
--no-install	Do not install Ollama even if it is missing: print the official install command and stop (for locked-down / CI machines).

vulkro-sf ai use

Flag	Description
--url <URL>	Point at a different OpenAI-compatible runtime while switching.
--pull	Pull the model if it is not installed (no prompt).
--yes	Answer yes to any prompt.

vulkro-sf ai list and vulkro-sf ai status

Both take --format table (the default, human output) or --format json (a single-line machine-readable object for tooling such as a VS Code settings UI). For status --format json the Salesforce banner line is omitted so stdout stays a single valid JSON object.

Model resolution

Every AI-capable command resolves its model and runtime in this order, highest priority first:

1. Per-run flags: --ai-model, --ai-url, --no-ai.
2. Environment variables: VULKRO_AI_MODEL, VULKRO_AI_URL, VULKRO_AI_KEY.
3. The saved selection from vulkro-sf ai use (or vulkro ai use; the setting is shared).
4. A smart default: qwen2.5-coder:7b (Apache-2.0), falling back to phi4-mini:3.8b (MIT) on a constrained machine (fewer than 4 physical cores).

The smart default never selects qwen2.5-coder:3b: the 3B sibling ships under a non-commercial license and is not suitable for commercial use.

Environment variables

Variable	Effect
VULKRO_AI_MODEL	Model tag override (below the --ai-model flag, above the saved selection).
VULKRO_AI_URL	Runtime base-url override (OpenAI-compatible).
VULKRO_AI_KEY	Cloud API key for --byok mode. Read from the environment only; never persisted to disk.
VULKRO_OFFLINE	Air-gap switch. A loopback (local) model still runs because nothing leaves the machine; any cloud AI endpoint is refused with an actionable error.

Where the AI layer is used

Configuring a model here lights up the advisory AI surfaces of the Salesforce CLI. Each is opt-in per run, carries the same --ai-model / --ai-url / --no-ai overrides, and never changes the deterministic findings or the exit code:

Command	AI flag	What you get
vulkro-sf scan	--ai-explain	After the deterministic scan, a plain-Salesforce-language explanation of why each candidate finding matters for an AppExchange Security Review. With --format json each explained finding gains an additive ai_advisory object; with --format table the narrative goes to stderr so stdout stays byte-identical. SARIF and the PR-decoration formats stay fully deterministic.
vulkro-sf triage	on by default (disable with --no-ai)	The deterministic scan plus advisory explanations for the mandatory-review candidate classes (CRUD / FLS, SOQL injection, with / without sharing, IDOR, @AuraEnabled / @RestResource entry-point authz) and reachability-uncertain findings. Exit codes are the scan's own: 0 no findings, 1 findings, 2 error.
vulkro-sf fix	--ai (apply with --ai --write)	Minimal Apex patches for CRUD / FLS, sharing, and SOQL-injection findings, each validated by re-running the deterministic Apex detector on the patched class. A fix is shown as verified only if the patched class still parses, the originating finding disappears, and no new finding appears in the file; otherwise it is refused with a reason. Verified means the deterministic re-scan no longer reports the finding and the file still parses: it does not claim the build compiles or tests pass. --ai alone is a read-only dry run; --ai --write applies only verified diffs, each printed first, atomically.
vulkro-sf org perms	--explain	An advisory narrative (on stderr) explaining why each posture finding is risky. Narrative-only: it never proposes a config mutation and never makes an extra call to the live org.

The model proposes; the deterministic detector judges. If the runtime is unreachable, each command prints an actionable note and the deterministic result stands.

Note: vulkro-sf scan --ai-code-segregation is unrelated to this layer. It is a marker-based report (which findings landed on AI-authored files, per tool comment markers) and calls no model.

Examples

# One-time setup: recommend a model for this machine, pull it, self-test.
vulkro-sf ai setup

# CI / scripted setup, no prompts.
vulkro-sf ai setup --model qwen2.5-coder:7b --yes --no-install

# Check what is configured and whether the runtime is reachable.
vulkro-sf ai status
vulkro-sf ai status --format json    # for tooling

# Switch models, pulling if needed.
vulkro-sf ai use qwen2.5-coder:7b --pull

# Turn the layer off; the deterministic scanner is unaffected.
vulkro-sf ai off

Exit codes

• 0 - success.
• 2 - error (Ollama missing and not installed, runtime unreachable, model missing and declined, bad args).

The ai group configures; it does not scan, so it never exits 1.

Where to go next

• vulkro ai - the core command group this one mirrors; the model selection is shared between the two binaries.
• vulkro-sf scan - the deterministic scan that --ai-explain rides on.
• vulkro-sf org perms - live-org posture audit with the optional --explain narrative.