SolverForge
Search docs Ctrl K

releases

solverforge-cli 3.8.x: SolverForge 0.24.0 and Scaffolds That Build and Solve

solverforge-cli 3.8.1 targets SolverForge 0.24.0. Fresh apps solve, generated code imports its field types and stays rustfmt-clean, and destroy refuses to leave dangling references.

solverforge-cli 3.8.1 was published on November 3, 2026, following 3.8.0 the same day, which introduced this line after 3.7.1 scaffolded solverforge 0.23.0. The 3.8.x packages target solverforge 0.24.0; the web UI (solverforge-ui 0.9.0), maps (solverforge-maps 2.1.4), and MCP (rmcp 3.8.0) targets are unchanged. Existing applications keep their own manifests and generated source.

What Changed

Fresh scaffolds target SolverForge 0.24.0 and solve

New projects pin solverforge 0.24.0 and read solver.toml through solver_toml = "../../solver.toml" on the planning solution, because the runtime no longer reads it from the working directory. The generated solver.toml declares only a 30-second termination limit and leaves the phases to the runtime’s model-aware default pipeline, with an explicit pipeline shown in comments. A fresh project with no planning variables solves to COMPLETED; the previous explicit local-search phase failed every solve on 0.24.0. Score analysis DTOs carry the runtime’s weightMultiplier.

Generators write code that compiles

  • --field types are imported: std collections, the chrono types the CLI recognizes, and use super::<Type> for other names. The first chrono field adds chrono to Cargo.toml, and demo data seeds Weekday and Utc fields without Default.
  • A --field type that is not defined in src/domain/ prints a warning that names the type and where to define it.
  • --field id:... and, for facts, --field name:... are rejected, because the generator already writes those fields.
  • generate score refuses BendableScore: a planning solution’s score must be parseable, and SolverForge 0.24.0 parses only HardSoftScore, HardSoftDecimalScore, HardMediumSoftScore, and SoftScore. A generic score type is imported by its bare name.
  • --unary --soft penalizes instead of rewarding, --unary and --reward filter before scoring, and --pair counts each unordered pair once.
  • generate scalar-group with an assignment target no longer leaves a construction phase that the runtime rejects.

Generated constraint skeletons and hook stubs still panic until their placeholders are replaced; a solve before that ends FAILED with a message naming the function and file.

Formatting and the managed blocks agree

solverforge new emits rustfmt-clean sources, and every generator and destroyer runs rustfmt on the Rust files it writes. cargo fmt no longer breaks the CLI: managed mod lists are matched by name in rustfmt’s sorted order, and the rustfmt pass never moves a managed block marker. The CLI shell compiles without dead-code warnings.

Commands report what they do

  • solverforge check states that it validates structure and did not compile the project.
  • solverforge server honours the PORT environment variable after --port and before .solverforgerc.
  • solverforge routes lists chained methods such as get(a).delete(b) and route calls split across lines.
  • solverforge test -- --nocapture passes arguments after -- to the test binaries.

Destroy refuses dangling references

destroy entity and destroy fact refuse a type that constraint files or planning variables still reference, list the referencing files, and change nothing; the hint names the destroy commands to run first. In 3.8.1 the file list uses forward slashes on every platform.

3.8.1 also re-renders src/data/data_seed.rs from other generate and destroy commands only while the file still starts with the // @generated by solverforge-cli: data v1 header, so hand-written demo data survives later commands. generate data still rewrites it on request.

Publication and exact-commit validation are separate

The current 3.8.1 crate carries source SHA 1e14044e924164a9aaf974628135b7a75a1f341f in .cargo_vcs_info.json. Its SHA-256 is 40e017937e0df564f2c767291bf1dc7eda4bded3f67cd4928b3f7566497851c0, matching the crates.io index. The exact-commit publication workflow and GitHub Release workflow succeeded, and the exact-commit CI run passed Linux, macOS, Windows, and Integration Tests.

The 3.8.0 crate carries source SHA 96ddbeefc5076761b9d69ad667a177330fd374dd; its SHA-256 is 2bfd9820d774bb33229a8044979a2b89673c65b0149d198c620b12dd12be61f3, matching the crates.io index. Its publication workflow and GitHub Release workflow succeeded. The exact-commit CI run failed: Linux and macOS passed, but Windows failed. A destroy test expected the refusal to name src/constraints/x.rs and Windows printed backslashes; the panic poisoned a shared test lock, so Windows reported 190 passed and 39 failed, and the dependent Integration Tests job was skipped. 3.8.1 fixes the message and keeps one failing test from failing the rest.

Published Version Boundaries

Surface Version Role
CLI solverforge-cli 3.8.1 Fresh scaffolds target solverforge 0.24.0
Runtime solverforge 0.24.0 Modeling, configuration, search, constraint weights; see the 0.24.x release note
Web UI solverforge-ui 0.9.0 Web shell only
Maps solverforge-maps 2.1.4 Web shell only
MCP SDK rmcp 3.8.0 MCP shell only
Previous CLI solverforge-cli 3.8.0 Same scaffold targets; exact-commit CI failed on Windows
Earlier CLI line solverforge-cli 3.7.1 Scaffolds solverforge 0.23.0; see the 3.7.x release note

Patch History

Version Date Notes
3.8.1 2026-11-03 Destroy refusals name files with forward slashes on every platform; generate and destroy re-render only a data seed that still carries the CLI header. Scaffold targets unchanged; exact-commit CI passed.
3.8.0 2026-11-03 Targets solverforge 0.24.0; fresh scaffolds solve; field types imported; duplicate fields and BendableScore refused; rustfmt-stable generation; check, server, routes, test, and destroy fixes. Exact-commit CI failed on Windows.

Upgrade Checklist

  • Install with cargo install solverforge-cli --version 3.8.1 --locked --force and inspect solverforge --version.
  • Upgrading the CLI does not change existing apps. To move an app to solverforge 0.24.0, follow the core release note’s checklist; in particular add solver_toml = "../../solver.toml" to the planning solution and remove unknown solver.toml keys.
  • Stop passing --field id:... or --field name:...; remove the header line from src/data/data_seed.rs once you own the demo data.
  • Replace every generated placeholder before you solve, then run cargo build: solverforge check does not compile.