set_city used a plain `phrases = [...]` array which fails the lang-map schema
in JCommand — the whole weather pack was being skipped at load. Normalized
to per-language phrases.
browser/command.toml pointed at Priler's bundled AutoHotKey exes that do not
ship in this fork, so the entries were dead. Renamed to .disabled (the loader
skips packs without command.toml) so we do not collide with the new Lua
apps pack while keeping the directory for reference.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds webrtc-vad-driven listening window for the post-wake-word phase.
State machine in jarvis-core::audio_processing::vad::listen_window;
adapter in vad::webrtc; integrated in app.rs::recognize_command and
stt::vosk::finalize_speech. Same parameters as Python v0.2.0
(aggressiveness 2, end-silence 1200ms, min-speech 500ms,
min-listen 1000ms, hard-cap 15000ms).
Wires LlmClient into the voice loop with a trigger-prefix pattern
(скажи / ответь / произнеси). Conversation history bounded at 8
turns, system prompt always preserved. LlmReply published via IPC;
pre-recorded play_ok cue accompanies the text reply. On error,
plays play_error and sends russian fallback line over IPC.
mark the v0.3 promise from the v0.2.x section as done and add a new
subsection that documents the GROQ_TOKEN env var, trigger phrases,
the LlmReply ipc event and the rollback-on-error behaviour.
new module crates/jarvis-app/src/llm_fallback.rs holds an optional
LlmClient + ConversationHistory built once at startup. if GROQ_TOKEN is
unset the module logs a warning and stays disabled — voice commands keep
working as before.
both the wake-word voice path (recognize_command in app.rs) and the
gui-side text command path (process_text_command) now check whether the
recognized phrase starts with one of the configured trigger phrases
(ru: 'скажи' / 'ответь' / 'произнеси'). when it does, the remainder of
the phrase is sent to Groq and the reply is published as a new
IpcEvent::LlmReply { text } so the gui can speak it.
on api error the trailing user turn is popped from history, the russian
fallback line is sent over ipc and a 'error' voice cue plays. the loop
itself never panics.
add LLM_DEFAULT_ENABLED / LLM_DEFAULT_MAX_HISTORY / LLM_DEFAULT_MAX_TOKENS
defaults, the russian J.A.R.V.I.S. system prompt, a fallback error line,
and per-language helpers get_llm_trigger_phrases() and get_llm_system_prompt()
so the voice loop can opt into Groq with a 'скажи …' style prefix.
split llm.rs into a module with separate client and history submodules.
ConversationHistory holds an optional system prompt plus a FIFO of user/
assistant turns capped at max_turns; oldest turns evict on overflow,
system prompt is preserved across truncation and clear().
Adds Groq (OpenAI-compatible) LlmClient in jarvis-core behind the
new 'llm' cargo feature, plus a jarvis-cli 'ask <prompt>' subcommand
for one-shot testing. Not yet wired into the wake-word/intent loop —
that's the next feature. thiserror added to workspace deps.
Adds a Russian-language section describing the new jarvis-core::llm
module, the Groq-related environment variables (GROQ_TOKEN,
GROQ_BASE_URL, GROQ_MODEL), the one-shot 'jarvis-cli ask' usage and
a short Rust example. Notes that the module is intentionally not yet
wired into the voice/intent loop — that lands in v0.3.
One-shot invocation: jarvis-cli ask "..." reads GROQ_TOKEN, calls
LlmClient::complete and prints the reply to stdout. Exits 2 when the
env var is missing, 1 on API/HTTP failure. Also available as an 'ask'
command inside the interactive REPL.
New jarvis-core::llm module providing a blocking client for
OpenAI-compatible chat completions endpoints (Groq by default).
- LlmClient::new / from_env (GROQ_TOKEN, GROQ_BASE_URL, GROQ_MODEL)
- complete(messages, max_tokens) -> String
- thiserror-based LlmError / ConfigError
- gated behind a new llm feature, included in default jarvis_app
Not yet wired into the wake-word/intent loop; that lands in v0.3.
Make all 4 workspace crates build cleanly: add build.rs to jarvis-cli
and jarvis-gui for vosk link path, build frontend assets so tauri
generate_context! finds them, gitignore tauri-regenerated schemas.
Workspace feature unification pulls vosk into jarvis-gui through
jarvis-core, so jarvis-gui needs the same rustc-link-search as
jarvis-app and jarvis-cli for libvosk.lib at link time.
The build script now runs 'routify build' before svelte-check so the
generated routes module exists when type-checking. vite build still
runs last to produce dist/client/, which tauri::generate_context!
needs at compile time for jarvis-gui.
desktop-schema.json and windows-schema.json under crates/jarvis-gui/gen/schemas
are regenerated by tauri-build on every compile and only produce diff noise.
