Content-addressable storage: blobs on disk, addressed by content hash (fjs/cas/module.f.mjs). The store is type-agnostic — it keeps raw bytes only, sharded by cBase32 hash under ~/.cas/ — and never records a mutable pointer or a per-blob type tag; both are recovered at the edges that need them.

• fjs/mcp — an MCP front end for agents, including read-time media-type detection: cas_add / cas_get / cas_list plus fjs/cas/evo's evo_list / evo_head / evo_revision / evo_add, all served from one process.
• cas CLI — direct filesystem access for content larger than the MCP inline-content cap.
• fjs/cas/git — the same store in a Git branch: a commit's tree as the map, add as one commit on a local branch; fjs cas git from the command line, and git push, git fetch and git merge for the rest.
• fjs/cas/evo — the Evo API: subjects and revision heads (vnd.fjs.revision) cached in memory over this store.

Because the store is type-agnostic, a blob's format is recovered on read, not declared on write. fjs/media does that recovery: byte-signature sniffing (PNG/JPEG/GIF/WebP/PDF/ZIP, fjs/media/type) plus, for JSON blobs that opt in, a self-describing dialect tag validated against an rtti schema.

• vnd.fjs.revision — one step in the evolution of a mutable object (a document, a config, any mutable state referenced by a stable name) on top of this immutable store: it links back to its parent revision(s) (a DAG, so concurrent edits can merge) and carries the full materialized content of that step. Served as application/vnd.fjs.revision+json; see fjs/media/revision/README.md for the full spec.
• vnd.fjs.lock — a revision's lock map stored on its own, so several revisions can point at one agreed dependency resolution instead of each carrying a copy. History-free by design: history for lock content is an ordinary revision whose snapshot is one of these blobs. Served as application/vnd.fjs.lock+json; see fjs/media/lock/README.md for the full spec.