Summary
Replace diecut's custom template cache with a shared crate backed by cacache, a content-addressable disk cache (Rust port of npm's cacache).
Current state
Diecut has the most sophisticated cache of the three tools that will share this infrastructure (src/template/cache.rs, ~330 lines): SHA256 cache keys, advisory file locks (fs4), TOML metadata, cache listing and clearing. But no integrity verification and coarse-grained locking that blocks other processes entirely.
Why migrate
- Lockless concurrency — cacache replaces advisory file locks with a lockless design, better for agentic workloads where multiple processes clone templates concurrently. Current file locking blocks entirely; cacache allows concurrent reads and writes.
- Integrity verification — cacache verifies hashes on every read. Important for diecut specifically since cached templates become code people run — this is a supply chain safety property.
- Content dedup — if multiple templates share files (common with monorepo template sources), they're stored once.
- Less code to maintain — replace ~330 lines of custom cache (keys, locking, metadata, listing, clearing, cross-filesystem copy) with a shared dependency.
Migration notes
This is the most complex migration of the three tools since diecut caches whole directories (not individual files). The shared crate will need to handle this use case, or diecut may need to store a directory manifest that references individually cached files.
Plan
Build a shared repo-cache crate on top of cacache, migrate graft first (simplest), then ownrs (validates TTL), then diecut last (most complex, whole-directory caching).
Summary
Replace diecut's custom template cache with a shared crate backed by cacache, a content-addressable disk cache (Rust port of npm's cacache).
Current state
Diecut has the most sophisticated cache of the three tools that will share this infrastructure (
src/template/cache.rs, ~330 lines): SHA256 cache keys, advisory file locks (fs4), TOML metadata, cache listing and clearing. But no integrity verification and coarse-grained locking that blocks other processes entirely.Why migrate
Migration notes
This is the most complex migration of the three tools since diecut caches whole directories (not individual files). The shared crate will need to handle this use case, or diecut may need to store a directory manifest that references individually cached files.
Plan
Build a shared
repo-cachecrate on top of cacache, migrate graft first (simplest), then ownrs (validates TTL), then diecut last (most complex, whole-directory caching).