Add an optional, local-first `vestige.toml` config file (loaded from the active
data directory alongside vestige.db) that lets users control the default shape
and size of high-traffic MCP responses without recompiling and without a cloud
service.
- New `vestige-core::config` module: `VestigeConfig` / `OutputConfig` /
`OutputProfile` with a dependency-free, lenient minimal-TOML parser for the
`[defaults]` table (detail_level, limit, profile).
- Output profiles: lean | default | audit | research. `default` reproduces
pre-2.1.24 behavior byte-for-byte so existing users see no change.
- Precedence (per call): explicit MCP param > config file > built-in default.
- Wired into search, memory_timeline, codebase (get_context), session_context.
Each echoes the active `profile`; `lean` masks scores/timestamps via a shared
`apply_output_masks` helper.
- McpServer loads config once at construction from storage.data_dir().
- Tests: config precedence/profile unit tests in core (10) + per-tool precedence
and lean-masking tests. Full workspace suite green, clippy -D warnings clean,
dashboard check + build green.
- Docs: new "Output Configuration (vestige.toml)" section in docs/CONFIGURATION.md
and CHANGELOG 2.1.24 entry. Version bumped 2.1.23 -> 2.1.24.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
CI / Release Build (aarch64-apple-darwin) (push) Blocked by required conditions
CI / Release Build (x86_64-unknown-linux-gnu) (push) Blocked by required conditions
CI / Release Build (x86_64-apple-darwin) (push) Blocked by required conditions
Test Suite / Unit Tests (push) Waiting to run
Test Suite / MCP E2E Tests (push) Waiting to run
Test Suite / User Journey Tests (push) Blocked by required conditions
Test Suite / Dashboard Build (push) Waiting to run
Test Suite / Code Coverage (push) Waiting to run
Nine tool modules in crates/vestige-mcp/src/tools/ had zero callers after
the v2.0.x unification work shipped *_unified + maintenance::* replacements.
They'd been #[allow(dead_code)]-papered over and forgotten. Verified each
module independently: grep for tools::<name>::, string dispatch in server.rs,
cross-crate usage — all nine returned zero external callers.
Removed modules (all superseded):
checkpoint (364 LOC) — no callers anywhere
codebase (298) — superseded by codebase_unified
consolidate (36) — superseded by maintenance::execute_consolidate
ingest (456) — superseded by smart_ingest
intentions (1,093) — superseded by intention_unified
knowledge (106) — no callers anywhere
recall (403) — superseded by search_unified
search (184) — superseded by search_unified
stats (132) — superseded by maintenance::execute_system_status
Also removed:
- EmotionCategory::base_arousal (10 LOC, zero callers)
Kept (still string-dispatched from server.rs):
- context, feedback, memory_states, review, tagging
Doc fixes (ghost env vars that were documented but zero Rust source reads):
- docs/CONFIGURATION.md — dropped VESTIGE_DATA_DIR, VESTIGE_LOG_LEVEL rows
(neither is read anywhere; --data-dir CLI flag + RUST_LOG are the real
mechanisms). Added the full real env-var table.
- packages/vestige-mcp-npm/README.md — same two ghost rows dropped
- docs/VESTIGE_STATE_AND_PLAN.md:399 — dropped VESTIGE_DATA_DIR row
- docs/VESTIGE_STATE_AND_PLAN.md:709 — typo VESTIGE_API_KEY
-> VESTIGE_AUTH_TOKEN (matches shipping convention), "open if unset"
-> "auto-generated if unset" to match actual behavior
Verified post-cleanup:
- cargo check --workspace clean
- cargo clippy --workspace -D warnings clean
- cargo test --workspace 1,223 passing / 0 failed
- cargo build --release -p vestige-mcp clean
Net: -3,091 LOC (14 files), zero behavior change, zero regressions.
Previously, fastembed created .fastembed_cache in the current working
directory, polluting project folders with symlinks.
Now uses platform-appropriate cache directories:
- macOS: ~/Library/Caches/com.vestige.core/fastembed
- Linux: ~/.cache/vestige/fastembed
- Windows: %LOCALAPPDATA%\vestige\cache\fastembed
Can still be overridden with FASTEMBED_CACHE_PATH env var.
Fixes user feedback about .fastembed_cache appearing in random folders.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
