Expand description
verdant-runtime — live cache runtime that the M1 MCP server consumes.
Build sequence so far: step 2 lands the content-addressed object
store (store); step 3 lands the LiveCache surface that wraps the
store with a registry, file-root revalidation, and dirty invalidation
(cache). Step 4 (file revalidation path) is folded into the cache
module; step 5 wires LiveCache into the verdant-mcp read tool.
Re-exports§
pub use cache::hash_file;pub use cache::CacheError;pub use cache::FileRoot;pub use cache::LiveCache;pub use cache::LookupOutcome;pub use remote::RemoteStore;pub use remote::RemoteStoreConfig;pub use store::FileRootSerde;pub use store::FileStore;pub use store::Key;pub use store::Payload;pub use store::PayloadMeta;pub use store::Store;pub use store::StoreError;
Modules§
- cache
LiveCache— the M1 cache surface that the MCP server consumes.- remote
RemoteStore—Storeimpl that talks to averdant-serverinstance over HTTP. Wired soLiveCache::new(RemoteStore::new(...))Just Works at every existing call site (verdant-mcp, verdant-proxy), letting a binary swap a local on-disk cache for a shared multi-user cache by configuration alone.- store
- Content-addressed payload store. The cache key is the blake3 hash of the canonical input bytes for a tool call (not the output); the value is the exact output payload bytes that the MCP tool fed back to the model on its original execution. The store is append-only for M1; M2 will add eviction.