solverforge-cli 2.0.x: One Entry Point and Explicit Scaffold Targets

solverforge-cli 2.0.x was the CLI line that introduced the neutral generated app shell and explicit scaffold target reporting. It is now superseded by solverforge-cli 2.2.x. The last 2.0.x patch scaffolds new projects on solverforge 0.11.1, solverforge-ui 0.6.5, and solverforge-maps 2.1.4.

Patch releases are folded into this line note instead of published as separate release-note pages.

This was the release that made the public CLI contract match the current SolverForge application architecture. New projects start from one neutral app shell, then grow through explicit generator commands. The CLI no longer exposes problem-family scaffold commands or starter flags as public commands.

cargo install solverforge-cli --force
solverforge --version
solverforge new my-scheduler

Why this release matters

The old onboarding story mixed two ideas: create an app shell, and choose a domain shape up front. That was useful while the scaffold was still learning what a SolverForge app should contain, but it became the wrong boundary.

SolverForge apps now share the same generated shell:

• an Axum backend
• retained solver-job routes and typed SSE
• shipped solverforge-ui assets
• generated scalar/list UI metadata
• solver.toml runtime configuration
• solverforge.app.toml scaffold metadata and UI contract

The domain shape belongs inside the generated project, not in a scaffold-family choice before the project exists. CLI 2.0.0 commits to that model.

2.0.4 scaffold targets

solverforge-cli is its own versioned product. The CLI package version and the crate versions used by newly scaffolded projects are deliberately reported separately:

solverforge solverforge-cli 2.0.4
CLI version: 2.0.4
Scaffold runtime target: SolverForge crate target 0.11.1
Scaffold UI target: solverforge-ui 0.6.5
Scaffold maps target: solverforge-maps 2.1.4
Runtime source: crates.io: solverforge 0.11.1
UI source: crates.io: solverforge-ui 0.6.5
Maps source: crates.io: solverforge-maps 2.1.4

Fresh projects generated by the current 2.0.x CLI target:

• solverforge 0.11.1
• solverforge-ui 0.6.5
• solverforge-maps 2.1.4
• Rust 1.95

That means new generated apps start on the CLI’s manifest-owned runtime target, the retained lifecycle UI contract, and the current map sidecar dependency.

What changed

solverforge new is the scaffold entry point

The public scaffold command is now only:

solverforge new my-scheduler

It creates a neutral application shell. There are no public problem-class flags such as --scalar, --list, or --mixed, and there is no public generate scaffold command.

Generators grow the model after scaffolding

Once the app exists, use generator commands to add the real domain:

solverforge generate fact employee --field skill:String
solverforge generate entity shift --field starts_at:String --field ends_at:String
solverforge generate variable employee_idx --entity Shift --kind scalar --range employees --allows-unassigned
solverforge generate constraint no_overlap --pair --hard
solverforge generate solution schedule --score HardSoftScore
solverforge generate data --size standard

The documented generator commands are:

• generate fact
• generate entity
• generate variable
• generate constraint
• generate solution
• generate score
• generate data

Planning-variable kinds are exactly scalar and list. The word mixed describes an app or model that contains both families; it is not a third variable kind. The word standard is only a demo dataset size label.

Generated apps include the retained lifecycle shell

The neutral shell is not empty. It boots immediately and includes the generated backend/frontend contract expected by current SolverForge apps:

• retained /jobs lifecycle routes
• typed SSE progress events
• pause, resume, cancel, and terminal delete operations
• exact snapshot and score-analysis routes
• solverforge-ui primitives such as SF.createBackend(...), SF.createSolver(...), and SF.rail.createTimeline(...)

The generated frontend is intentionally thin. It consumes generated metadata and mounts shipped UI primitives instead of vendoring a separate frontend app.

Configuration ownership is explicit

Generated projects now make the two configuration layers clear:

• solver.toml is the user-owned runtime search configuration.
• solverforge.app.toml records scaffold metadata, demo defaults, generated model summaries, and the UI contract.

The CLI derives static/generated/ui-model.json from the app spec. Treat that file as generated output. static/sf-config.json remains the lightweight frontend shell config for labels such as title and subtitle.

Breaking changes

This is a major CLI release because stale public scaffold commands are gone.

• solverforge generate scaffold is no longer part of the CLI.
• solverforge new --scalar, --list, --mixed, and starter-family flags are not public commands.
• standard is not a planning-variable kind.
• New generated apps use the current retained-job API, including terminal DELETE /jobs/{id} cleanup.

Existing projects created by older CLI versions are not rewritten in place by installing 2.0.0. Use the current docs when generating new resources.

Upgrade notes

For new projects:

cargo install solverforge-cli --force
solverforge --version
solverforge new my-scheduler
cd my-scheduler
solverforge generate fact resource --field category:String --field load:i32
solverforge generate entity task --field label:String --field priority:i32
solverforge generate variable resource_idx --entity Task --kind scalar --range resources --allows-unassigned
solverforge generate data --size large
solverforge server

For installed CLIs:

cargo install solverforge-cli --force
solverforge --version

Check the solverforge --version output before publishing docs, templates, or tutorials that claim current scaffold targets.

Patch History

Where to read next

Use the solverforge-cli manual for command details, the command reference for exact options, and the hospital scheduling use case for a complete current app on the latest scaffold target.

solverforge-cli 2.0.0 is the line where the CLI stops pretending that scaffold families are the product. The product is the generated SolverForge app: one shell, explicit model generators, explicit runtime targets, and a retained lifecycle UI that is ready to extend.