Generator Commands

Generator commands synchronize Rust domain files, app metadata, and generated frontend model files. They expect the current project to retain the managed @solverforge:begin ... / @solverforge:end ... regions emitted by the current scaffold.

solverforge generate

solverforge generate [OPTIONS] <COMMAND>

Subcommands:

The bash examples on this page run in order in one project, a staffing model that assigns employees to shifts. Start it with:

solverforge new staffing
cd staffing

generate solution

solverforge generate solution [OPTIONS] <NAME>

A fresh neutral scaffold’s Plan can be replaced once by this command. If the project is already shaped, destroy the existing solution first.

The solution type and its score type are rewritten together across the generated contract as well as the solution file, so the web/API/MCP DTOs, the solver service, lib.rs, and the MCP files never keep a reference to the previous solution or score.

solverforge generate solution schedule --score HardSoftScore

generate fact

solverforge generate fact [OPTIONS] <NAME>

Creates src/domain/<name>.rs with id and name fields, updates src/domain/mod.rs, wires the collection into the planning solution, and syncs solverforge.app.toml, the generated UI model, and the demo data.

solverforge generate fact employee --field skill:String

--field accepts any Rust type. The command rejects --field id:... and --field name:..., because it already writes both fields. It imports the chrono types it recognizes (such as NaiveDate, NaiveDateTime, and Weekday) and adds chrono to Cargo.toml when one is used. For any other type that is not defined in src/domain/, it prints a warning: define that type in src/domain/ and export it from src/domain/mod.rs before you build. Quote a type that contains < or >, such as 'skills:Vec<String>', so the shell does not read it as a redirection.

generate entity

solverforge generate entity [OPTIONS] <NAME>

The entity gets an id field; --field id:... is rejected.

solverforge generate entity shift --field required_skill:String

--planning-variable <FIELD> adds an Option<usize> scalar variable with #[planning_variable(allows_unassigned = true)] and no value range. Use generate variable when the variable needs a range or a list element collection, as below.

generate variable

solverforge generate variable [OPTIONS] --entity <ENTITY_TYPE> --kind <KIND> <FIELD>

Scalar variables are always Option<usize> candidate indexes. --range and --countable-range choose the candidate domain; --countable-range validates a non-negative usize range with from < to and projects it into solverforge.app.toml and, for web shells, the generated UI model. The stock cvrp profile owns its meters, route and savings hooks, metric class, and solution trait, so those entries cannot be overridden alongside --domain cvrp.

standard is not a variable kind. It is only the default demo data size label used by solverforge.app.toml.

Scalar examples on the Shift entity, over the employees collection and an hour of the day:

solverforge generate variable employee_idx --entity Shift --kind scalar --range employees --allows-unassigned
solverforge generate variable hour --entity Shift --kind scalar --countable-range 0..24

A list variable on a new Route entity, over a new Visit fact:

solverforge generate fact visit
solverforge generate entity route
solverforge generate variable stops --entity Route --kind list --elements visits

Scalar-hook and list-metadata flags such as --candidate-values or --domain cvrp only write #[planning_variable(...)] or #[planning_list_variable(...)] metadata; they project it into solverforge.app.toml and the web-shell UI model. The project compiles only after you write the Rust they name: the hook function for --candidate-values employee_candidates, or the VrpSolution implementation on the planning solution that --domain cvrp requires.

generate constraint

solverforge generate constraint [OPTIONS] <NAME>

Hardness options:

Pattern options:

Write options:

Choose at most one pattern flag. If no pattern flag is supplied, the command scans the current domain and opens an interactive wizard. --balance and --reward always score soft.

solverforge generate constraint max_hours --unary --hard
solverforge generate constraint no_overlap --pair
solverforge generate constraint required_skill --join --hard

max_hours filters single shifts, no_overlap pairs shifts that share an employee_idx, and required_skill joins each shift to the employee its employee_idx points at.

Each command writes src/constraints/<NAME>.rs, adds mod <NAME>; to the constraint-modules block of src/constraints/mod.rs, and appends super::<NAME>::constraint() to the constraint-calls block of create_constraints in src/constraints/assemble.rs. The command refuses to run when src/constraints/mod.rs holds code; see Project Anatomy.

Every skeleton compiles, but its rule is a placeholder that panics. A solve fails with lifecycleState FAILED until you replace it; the panic message names the function and file to edit. The Getting Started guide replaces two of them.

generate score

solverforge generate score [OPTIONS] <SCORE_TYPE>

<SCORE_TYPE> can be HardSoftScore, HardSoftDecimalScore, HardMediumSoftScore, or SoftScore. BendableScore is refused: a planning solution’s score must be parseable, and the runtime parses only those four. SimpleScore is not a score type.

The command rewrites the score type on every surface that carries it — the solution, every src/constraints/*.rs module, and the generated contract files (src/solver/service.rs, src/api/dto.rs, src/lib.rs, src/mcp/dto.rs, src/mcp/tasks.rs) — computing all rewrites before it writes any of them, so a score change cannot leave the project in a state that does not compile. Asking for the score type the project already uses is a no-op rather than an error.

solverforge generate score HardSoftDecimalScore

generate data

solverforge generate data [OPTIONS]

The command rewrites src/data/data_seed.rs, ensures the stable src/data/mod.rs wrapper exists, and updates [demo].default_size in solverforge.app.toml when --size is provided.

Other generate and destroy commands also re-render the seed so it matches the model, but only while the file still starts with the // @generated by solverforge-cli: data v1 header. Remove that line once you write your own demo data, and later commands leave the file alone; generate data still rewrites it when you ask.

solverforge generate data
solverforge generate data --size large
solverforge generate data --mode stub

generate scalar-group

solverforge generate scalar-group [OPTIONS] <NAME>

Scalar groups are opt-in runtime model resources for coupled scalar construction and search.

Target options:

Assignment hook options:

Limit and write options:

A candidate-backed group that moves a shift’s employee and hour together:

solverforge generate scalar-group shift_slot --candidates shift_slot_candidates --target Shift.employee_idx --target Shift.hour

An assignment-backed group names one nullable scalar variable instead, for example --assignment Shift.employee_idx --required-entity required_shift. A variable belongs to at most one group.

The command adds a stub for each hook function to the planning solution file and its phases to the managed solver.toml region. Each stub is a todo!() that panics until you write the function.

generate conflict-repair

solverforge generate conflict-repair [OPTIONS] --provider <FN_PATH> <CONSTRAINT>

Example:

solverforge generate conflict-repair no_overlap --provider repair_no_overlap

The constraint must exist; the provider stub repair_no_overlap in the planning solution file is a todo!() until you write it.

solverforge destroy

solverforge destroy [OPTIONS] <COMMAND>

Removes generated resources and resyncs the app spec, the generated demo data, and the UI model; the demo-data seed follows the header rule above. Remove dependents before what they depend on:

1. constraints that read an entity or fact (destroy constraint)
2. conflict repairs and scalar groups that name a constraint or variable
3. planning variables, or the entity that owns them
4. facts whose collection a variable ranges over
5. the solution

destroy refuses a resource that something else still references, names the references, and changes nothing: an entity read by constraint files or targeted by a scalar group, a fact whose collection a planning variable ranges over, a constraint named by a conflict repair, or a variable targeted by a scalar group. For example, after the repair and the group are gone but the three constraints still read Shift:

error: cannot destroy entity 'Shift' because source files still reference it: src/constraints/max_hours.rs, src/constraints/no_overlap.rs, src/constraints/required_skill.rs

Destroying the solution does not re-render the seed, because no planning solution remains to render it against. The confirmation flag belongs to the destroy command itself, so place it before the resource subcommand.

Subcommands:

solverforge destroy --yes conflict-repair no_overlap
solverforge destroy --yes scalar-group shift_slot
solverforge destroy --yes constraint no_overlap
solverforge destroy --yes constraint max_hours
solverforge destroy --yes constraint required_skill
solverforge destroy -y variable --entity Shift hour
solverforge destroy --yes entity shift
solverforge destroy --yes fact employee

Without --yes, each command asks for confirmation.

See Also

• Modeling & Generation - how generated files fit together
• Operations Commands - validation, testing, routes, and config helpers