solverforge-cli 2.2.x: Current Runtime Scaffolds and Model Resources

solverforge-cli 2.2.1 is the current GitHub source line for generated SolverForge apps. It passed GitHub CI on 2026-06-10 and scaffolds new projects on solverforge 0.15.1, solverforge-ui 0.6.5, and solverforge-maps 2.1.4.

The latest crates.io package is still solverforge-cli 2.2.0 until the v2.2.1 tag and package publish are cut. If you install from crates.io today, confirm the exact scaffold target with solverforge --version.

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

Current Source Scaffold Targets

solverforge --version reports the CLI package version separately from the crate targets used by newly scaffolded projects:

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

Fresh web projects generated by the current source CLI target:

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

What Changed

Generated apps move forward one runtime patch

The previous published CLI line still scaffolded solverforge 0.11.1. CLI 2.2.0 moved fresh generated apps directly to the published solverforge 0.15.0 runtime. CLI 2.2.1 advances the source scaffold target to solverforge 0.15.1, keeping generated apps on the 0.15 patch line while the core runtime continues separately to solverforge 0.15.2.

Shell selection is explicit

solverforge new still creates a neutral shell, but the public shell options are now explicit:

solverforge new my-scheduler
solverforge new service-scheduler --shell api
solverforge new batch-scheduler --shell cli

The default web shell includes the Axum backend, solverforge-ui frontend assets, and solverforge-maps. The api shell keeps the HTTP API without static frontend assets. The cli shell emits a command-line app without Axum, UI, maps, or static/.

Model-resource generators are public

The generator surface now includes scalar groups and conflict repairs:

solverforge generate scalar-group required_assignment \
  --assignment Task.resource_idx \
  --required-entity required_task

solverforge generate conflict-repair required_assignment \
  --provider repair_required_assignment

By default these commands synchronize the planning solution, solverforge.app.toml, and a CLI-managed solver.toml region. Use --skip-solver-config when the app owns those phase and selector references manually.

Scalar variables can declare runtime hooks

Scalar variable generation can write hook metadata for app-owned candidate selection, nearby candidate selection, distance meters, and construction ordering:

solverforge generate variable resource_idx \
  --entity Task \
  --kind scalar \
  --range resources \
  --candidate-values resource_candidates \
  --construction-entity-order-key task_priority \
  --construction-value-order-key resource_priority

Those flags declare metadata only. The referenced Rust functions remain application code.

Non-web shells preserve their boundary

API and CLI shell projects do not generate static/, static/generated/ui-model.json, or ui_source. Later domain mutations keep that shell boundary intact instead of silently adding web assets.

Upgrade Notes

For a new project:

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 check
solverforge server

For an existing generated project, installing a newer CLI does not rewrite the project in place. Use solverforge --version to confirm what new scaffolds will target, then update an existing app’s Cargo.toml and solverforge.app.toml deliberately when that app is ready to move runtime lines.

Patch History

Where to read next

Use the solverforge-cli manual for the current workflow, the command reference for exact options, and the worked use cases for full apps on their checked-in bundle line.