5 Commits

Author	SHA1	Message	Date
Jake	ce6dc1e728	agent: lumotia-rebrand — fix QC blockers for phase 2 ... Phase 2 QC found three explicit blockers + a broader sweep needed: Explicit (QC-named): - crates/mcp/src/lib.rs:15 — SERVER_NAME public MCP wire identity - crates/transcription/build.rs:59 — panic message prefix - crates/llm/tests/content_tags_smoke.rs:7 — docstring -p flag Swept (string literals + dev env vars + doc comments + test fixtures): - crates/mcp/src/main.rs — eprintln log prefixes - src-tauri/src/commands/diagnostics.rs — diagnostic filename + MAGNOTIA_VERSION - src-tauri/src/commands/audio.rs — recording filename pattern lumotia-<secs>-...wav - src-tauri/src/commands/fs.rs — test placeholder path - crates/transcription/src/model_manager.rs — .lumotia-verified marker - crates/storage/src/database.rs — lumotia-storage-ro-<pid> temp dirs + doc comments - crates/cloud-providers/src/keystore.rs — LUMOTIA_API_KEY_<PROVIDER> env var - crates/audio/src/{wav,decode}.rs — lumotia_test_* / lumotia_decode_* test fixtures - crates/core/src/tuning.rs — LUMOTIA_INFERENCE_THREADS env var - All MAGNOTIA_LLM_TEST_MODEL / MAGNOTIA_WHISPER_TEST_* env vars - Doc comments referencing crate names Excluded (intentional Phase 4/5 scope): - magnotia_preferences, magnotia_history, magnotia_morning_triage_last_shown DB setting keys (Phase 5 paths.rs migration) - magnotia_startup tracing target (Phase 4) - crates/core/src/paths.rs (Phase 5 wholesale rewrite + migration shim) cargo build --workspace passes. cargo test --workspace: 330 pass, 0 fail. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-13 08:52:47 +01:00
Jake	089349d966	agent: lumotia-rebrand — rust workspace crates magnotia-* -> lumotia-* ... Phase 2 of the rebrand cascade. Renames all 9 workspace crates from magnotia-* to lumotia-* plus the src-tauri binary crate name: - magnotia-ai-formatting -> lumotia-ai-formatting - magnotia-audio -> lumotia-audio - magnotia-cloud-providers -> lumotia-cloud-providers - magnotia-core -> lumotia-core - magnotia-hotkey -> lumotia-hotkey - magnotia-llm -> lumotia-llm - magnotia-mcp -> lumotia-mcp - magnotia-storage -> lumotia-storage - magnotia-transcription -> lumotia-transcription - magnotia -> lumotia (src-tauri binary) - magnotia_lib -> lumotia_lib (src-tauri lib target) Crate directories (crates/audio/ etc.) stay as-is; only the Cargo.toml [package] name field changes plus all consumer module imports (magnotia_core -> lumotia_core, etc.). Remaining magnotia_* references at this point are intentional and scoped to later phases: tracing targets (Phase 4), DB setting keys magnotia_preferences/magnotia_history (Phase 5). cargo build --workspace passes. cargo test --workspace: 330 pass, 0 fail. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-13 08:48:09 +01:00
Jake	b463c32f17	chore: stabilize current head before Phase 10a QC	2026-05-10 23:00:25 +01:00
jars	a58c2f0994	test(transcription): thread_sweep prints power-aware 4-panel table ... Extends the JFK thread-count sweep to print four labelled panels (AC+CPU, AC+GPU, battery+CPU, battery+GPU) driven by MAGNOTIA_POWER_STATE_OVERRIDE. Each panel shows the helper's predicted thread count for its (power, gpu) combination alongside the empirical RTF table for n_threads = [1, 2, 4, physical, logical, maybe 8]. The actual whisper context is initialised once (Vulkan if compiled in and resolvable, CPU otherwise), so the RTF rows themselves are produced by the same backend across panels. The CPU vs GPU axis controls only the helper-pick column, which is the empirical question we want answered: is the LLM=2 / Whisper=4 GPU floor right? Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-09 12:43:04 +01:00
jars	4cb954ece4	perf: route whisper + llm n_threads through physical-core helper ... Both inference call sites previously called `num_cpus::get()` (logical thread count). Established whisper.cpp / llama.cpp guidance is that SMT siblings contend for shared FPU resources during heavy F16/F32 matmul, so going past physical core count anti-scales. Empirical sweep on Whisper Tiny / 11s JFK clip / Ryzen 5 4650U (6c12t): n_threads | xc_time | RTF | speedup_vs_1 ----------|---------|--------|------------- 1 | 0.33s | 0.030 | 1.00x 2 | 0.33s | 0.030 | 1.00x 4 | 0.30s | 0.028 | 1.09x 6 | 0.32s | 0.029 | 1.04x 8 | 0.31s | 0.028 | 1.06x 12 | 0.32s | 0.029 | 1.03x Tiny doesn't scale (work dominated by overhead) but the larger Whisper variants and Qwen LLMs do. Sources: whisper.cpp #200, #1033, #1252, #403; llama.cpp #3167, #572. Changes: - crates/core/src/constants.rs: * MIN_INFERENCE_THREADS lowered 4 → 2 (research-derived floor) * MAX_INFERENCE_THREADS = 8 added (research-derived ceiling) * inference_thread_count() rewritten: - reads MAGNOTIA_INFERENCE_THREADS env var (override) - num_cpus::get_physical() with available_parallelism fallback - clamped to [MIN_INFERENCE_THREADS, MAX_INFERENCE_THREADS] - crates/core/Cargo.toml: + num_cpus = "1" - crates/transcription/src/whisper_rs_backend.rs: call site uses helper. - crates/llm/src/lib.rs: call site uses helper. - crates/transcription/Cargo.toml: drop num_cpus from [features] + [dependencies] (production no longer needs it). Move to [dev-dependencies] for tests/thread_sweep.rs only. - crates/llm/Cargo.toml: drop num_cpus = "1" (no longer used directly). Per-machine maps (after this patch): Ryzen 5 4650U 6c12t → 6 big-iron 12c24t → 8 (clamp; users can override) cheap 2c2t laptop → 2 1c container/VM → 2 Adds crates/transcription/tests/thread_sweep.rs — env-gated like jfk_bench, prints the table above against any model + WAV. Useful for re-baselining on new hardware or when tuning the clamp values. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-09 09:26:23 +01:00