vulkro-sf ai

Chooses and tests the optional local AI model that the advisory commands use. The AI layer never changes a finding, its severity, the readiness report, SARIF or SBOM output, or an exit code.

vulkro-sf ai setup                                      # pick, pull and test a model
vulkro-sf ai setup --model qwen2.5-coder:7b --yes --no-install   # scripted
vulkro-sf ai status

By default it uses a local Ollama runtime on loopback, so nothing leaves your machine, and it still works under VULKRO_OFFLINE. A cloud endpoint is refused offline. The selection is stored in ~/.vulkro/scans.db and shared with vulkro ai.

Subcommand	What it does
setup	Wizard: install Ollama if missing (only after you confirm), recommend a model, pull it, self-test, save. Flags: --model, --url, --yes, --no-install, --byok (cloud, key from VULKRO_AI_KEY only, never written to disk).
list	Installed models plus the recommended Apache-2.0 and MIT models.
use <model>	Set the active model. --pull pulls it if missing.
pull <model>	Pull a model.
status	Current model, runtime, reachability and offline mode. --format json for tools.
test	Run a short self-test against the active model.
off	Turn the AI layer off, keeping the selection.

Precedence: the per-run flags --ai-model, --ai-url, --no-ai, then VULKRO_AI_MODEL and VULKRO_AI_URL, then the saved selection, then a default for the machine.

Where it is used

Command	Flag	What you get
scan	--ai-explain	A plain-language note on why each finding matters for the security review.
triage	on by default	Advisory explanations for the classes a reviewer always checks.
fix	--ai, --ai --write	Apex patches, kept only if a re-scan shows the finding gone.
org perms	--explain	Why each posture finding is risky.

If the runtime is unreachable, the command says so and the deterministic result stands.

Exit codes

Code	Meaning
0	Success.
2	Error (runtime unreachable, model missing and declined, bad arguments).