bherbruckandClaude Opus 5.5
0d7e456bc1
An mdBook under docs/book: a user guide (getting started, UI tour, sketching, features, parameters, components and joints, sheet metal, plastic, files, shortcuts, MCP) and a developer guide (CONTRIBUTING, architecture, command engine, kernel boundary, persistent naming, test harnesses, and the existing docs/*.md pages). `cargo xtask book` generates the command reference from `solvecraft-cli commands` and renders the screenshots with `solvecraft-cli snapshot`, then runs mdbook. .github/workflows/pages.yml publishes the book at /solvecraft/ and the web app at /solvecraft/app/ (skipped while the repository is private). .github/workflows/ci.yml runs `cargo xtask ci` on pull requests. README and Help → Documentation link to the book. Fixes #28 Fixes #8 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.1 KiB
1.1 KiB
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.
{{#include ../../../../README.md:architecture}}
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.