SolverForge
Search docs Ctrl K

Documentation

Create a neutral generated project shell and run its development server.

Scaffold Commands

Scaffold commands create and run generated app shells. They do not choose a problem class; scalar and list planning variables are added later through generator commands.

solverforge new

solverforge new [OPTIONS] <NAME>

Creates one neutral project shell. The current public shell set is exactly web, api, cli, and mcp; a Tauri shell is intentionally deferred and is not generated by this release line. There are no public problem-class flags such as --scalar, --list, or --mixed; scalar and list planning variables are created after scaffolding with solverforge generate ....

Arguments:

Argument Meaning
<NAME> Project directory to create

Options:

Option Meaning
--shell <SHELL> Generated shell: web, api, cli, or mcp; default web
--skip-git Skip git init and the initial commit
--skip-readme Do not generate README.md

Project names must start with an ASCII letter and contain only letters, digits, hyphens, or underscores. Hyphens are converted to underscores for the generated Rust crate name, and Rust keywords are rejected.

Unless --skip-git is set, the command initializes a Git repository and attempts an initial commit. Unless --skip-readme is set, it writes a generated README. When not running quiet, it prompts to run cargo check after scaffolding.

Example:

solverforge new my-optimizer
solverforge new api-optimizer --shell api
solverforge new batch-optimizer --shell cli
solverforge new agent-optimizer --shell mcp

What Each Shell Generates

Every shell shares one generated core (src/domain/, src/constraints/, src/solver/, src/data/, and the DTO contract), so solverforge generate and solverforge destroy mutate any shell the same way. The shells differ in their delivery surface and dependencies:

Shell Delivery surface Key dependencies Omitted
web (default) Axum server plus the bundled solverforge-ui frontend under static/ solverforge, solverforge-ui 0.9.0, solverforge-maps 2.1.4, Axum, Tokio, tokio-stream, tower-http, serialization, parking_lot -
api Axum HTTP API with retained-job routes and SSE, no frontend solverforge, Axum, Tokio, SSE, tower-http CORS, serialization, parking_lot solverforge-ui, solverforge-maps, static/, ui_source
cli Clap command-line app; no HTTP server solverforge, Clap, Tokio, serialization, parking_lot Axum, tower-http, tokio-stream, solverforge-ui, solverforge-maps, static/, ui_source
mcp MCP server exposing the solver as schema-typed tools solverforge, rmcp 3.4.0, Axum, Tokio, tracing, tracing-subscriber, serialization, parking_lot solverforge-ui, solverforge-maps, static/, ui_source

Every shell declares rust-version = "1.95" and schemars as an optional dependency behind a schema feature; only the MCP shell enables it, so it can publish typed tool schemas over the shared DTO contract. The MCP shell also keeps the runtime console feature off because the runtime banner writes to stdout, which is the stdio MCP transport channel.

solverforge server

solverforge server [OPTIONS]

Options:

Option Meaning
-p, --port <PORT> Port to bind; when omitted, use .solverforgerc and then 7860
--debug Run in debug mode (faster compilation, slower runtime)

Command behavior depends on the shell:

  • web and api apps run through Cargo; --debug switches from release to debug compilation.
  • An mcp project boots the stateless Streamable HTTP transport.
  • A cli project cannot use solverforge server; run it directly with cargo run -- demo-data.

An MCP-shell project defaults to the stdio transport, which you start directly with cargo run; use --http on the generated binary for HTTP. See the MCP Shell page.

Examples:

solverforge server
solverforge server --port 8080
solverforge server --debug

See Also