Architecture
SolveCraft is a Cargo workspace in layers. A crate only depends on crates in lower layers, and
cargo xtask layers fails the build otherwise.
| Layer | Crates | Role |
|---|---|---|
| L0 | geom | vectors, planes, profiles, meshes and their measures |
| L1 | sketch, kernel, render | constraint solver and profiles; the B-rep kernel boundary (truck); view math and CPU rasterizer |
| L2 | doc | parameters, expressions, the feature timeline and its incremental evaluation |
| L3 | io | design files, STL/OBJ/STEP/3MF export, STEP and 3MF/STL import features |
| L4 | engine | the session and the command registry (everything is a command) |
| L5 | ui-egui, mcp | the swappable desktop front end; the MCP server (headless or bridged to the app) |
| apps | solvecraft, solvecraft-cli | desktop app, headless CLI |
The web app, apps/solvecraft-web, is the desktop front end compiled to wasm with
trunk. xtask holds the repository’s own tooling: cargo xtask ci,
layers, assets, oracle, parity, step-corpus and book.
A few rules follow from the layering:
- Only
crates/kerneltouches truck. Everything above it sees SolveCraft’s own types: bodies, faces, edges, meshes and measures. See The kernel boundary. - The document knows nothing about commands or the UI.
crates/docholds the parameters, the feature timeline and the component tree, and evaluates them into a model. - Everything the user can do is a command in
crates/engine. See The command engine. - The front end is swappable. Nothing below
ui-eguidepends on egui. The CLI and the MCP server run the same engine without a window, andcrates/renderhas a CPU rasterizer so headless screenshots work anywhere.