mesofact-dev — the dev-tier affordances, and nothing else.
This crate is deliberately small. The serving engine (Server, SSR
dispatch, the revalidate receiver, tenants, the same-origin proxy) used to
live here, which meant the prod mesofact-serve binary — which shipped
from this crate — linked the file watcher and the dev S3 surface. That broke
the dev/prod crate boundary W225 §2 relies on for its security claim
("prod is clean by construction … the crate boundary already keeps it out of
prod"). It wasn't: cleanliness rested on linker dead-stripping.
The engine now lives in the mesofact facade and this crate depends on
it, holding only the pieces that must never reach a prod binary:
- [
watcher] — the rebuild-on-change file watcher. - [
s3] — the local S3 surface that stands in for R2 duringdev(W225 §2 "local pond emulation"). - [
app] — the library-tier dev entry point, [serve_app]: the dev counterpart of [mesofact::serve_app] for a consumer whose routes are Rust handlers rather than a builtdist/tree. Read its module doc for what the dev half of that tier is and, just as load-bearing, what it deliberately is not. - [
cli] — themestoolchain CLI, and the two bin targets over it.
[cli] carries the prod verbs (serve, publish, new) as well as the
dev ones, so consumers learn one CLI — but it gets them by calling into
[mesofact::cli], which is the direction that costs the prod binary
nothing. The boundary above is about what links into a binary, not about
which verbs a binary spells.
Engine types are re-exported below so existing mesofact_dev::Server-style
callsites keep working; new code should prefer mesofact::… directly.
@arch:see(.yah/docs/working/W225-mesofact-consumer-deployment-model.md)