mos-cache

Incremental build cache boundary for Mosaic.

Current state: small public API plus in-memory implementation. This crate is not wired into a persistent build pipeline yet, and it does not write .mos-cache/ on disk.

API

• CacheKey(pub ContentHash): opaque cache address wrapper. Today it is just a mos_core::ContentHash.
• Cache: trait with get and put for byte payloads.
• InMemoryCache: HashMap<CacheKey, Vec<u8>> implementation for tests and future integration slices.

Behavior:

• get(&CacheKey) returns Some(Vec<u8>) when present, cloned from the cache.
• get(&CacheKey) returns None for misses.
• put(CacheKey, Vec<u8>) stores bytes and replaces any prior value for the same key.
• Values are untyped byte payloads. Serialization and cache validity are caller responsibilities.
• Data lasts only as long as the InMemoryCache value.

Example

use mos_cache::{Cache, CacheKey, InMemoryCache};
use mos_core::ContentHash;

let mut cache = InMemoryCache::default();
let key = CacheKey(ContentHash(7));

assert_eq!(cache.get(&key), None);

cache.put(key, b"layout-bytes".to_vec());

assert_eq!(cache.get(&key), Some(b"layout-bytes".to_vec()));

Boundary

mos-cache depends only on mos-core. Keep it close to core types and away from parser, evaluator, layout, PDF, CLI, package, and LSP logic until a real integration slice needs more.

The manifest describes a content-addressed dependency graph cache with persisted artifacts. That is design direction, not shipped behavior.

Known Non-Goals Today

• No disk persistence.
• No .mos-cache/ directory management.
• No dependency graph or invalidation engine.
• No stable key schema for node/style/width hashes.
• No cache eviction, locking, versioning, or cross-process sharing.
• No CLI integration for mos check, mos build, watch, or clean.