Module store 

The project’s state tree on disk: where it is anchored (paths), how a source asset is found inside it (source), how the compiled blob is read out of it (blob), how the runtime’s regenerable artifacts are kept in it (cache), and how a regenerable container is published without a reader ever seeing it part-written (atomic).

This is the engine’s only home for filesystem knowledge below the engine and cook crates. concinnity_core::blob owns the pure bytes <-> metadata transforms and performs no I/O; concinnity-core owns the runtime blob types and the PayloadStore seam and knows neither paths nor files. The reads that join the two live here.

Modules

atomic

Replacing a file whole, for the state tree’s regenerable containers.

blob

Runtime blob access: the state root’s data/ path layout, the payload residency store, and all blob file I/O. The concinnity-blob crate owns the format contract (schema, header, version, bytes <-> metadata) and is deliberately I/O-free, so every read below is fs here plus a pure parse there. Blob data is read-only at runtime; concinnity-cook writes what concinnity_core::blob::encode_cnb returns.

cache

The runtime cache segment: regenerable artifacts the running application writes for its own later launches, all of them in cache/0.

paths

The project state tree: where the engine’s state is anchored, and the names of the directories hanging off it.

source

Finding an authored source asset on disk.