SolverForge Use Cases: Four Repository-Only Apps on the 0.19.7 Line

The solverforge-usecases bundle is the publication source for the runnable SolverForge example applications. It now carries eight apps instead of four: uc-furnace, uc-orders, uc-fleet, and uc-flightcrew were added alongside the published hospital, lessons, deliveries, and field-service cases.

All eight target solverforge 0.19.7 and solverforge-ui 0.9.0. The four new apps are repository-only: they are complete, runnable open-source applications with Dockerfiles, tests, and browser workspaces, but they have no hosted Hugging Face Space. The four published cases keep theirs.

The New Apps

Heat-treatment scheduling

solverforge-furnace 2.0.2 plans 155 work orders across 11 furnaces and 39 operators over a seven-day horizon, with 467 planning entities and 30 constraints (22 hard, 8 soft).

This is the coupled-planning case: a valid plan has to decide which furnace can process each order, when the batch runs, which operators own the related manual tasks, whether monitoring capacity is available, and whether the roster can support the work. Solving those layers separately produces schedules that look legal in one layer and fail in another.

It answers one concrete question:

Given furnaces, work orders, task operators, and a weekly shift roster, when should each order run, on which furnace, and which operator performs each manual task?

Warehouse order picking

solverforge-orders 0.1.2 plans 8 grocery orders, 145 pick steps, 37 products, and 5 trolleys. It is a faithful port of its source application’s single page, including the isometric warehouse canvas with aisle-routed trolley paths, numbered pickup markers, and trolleys animated while a solve runs.

The scoring is deliberately small and exact: hard required_buckets counts buckets past four per order, soft order_incidence penalizes distinct trolley/order incidences, and soft route_distance penalizes one point per meter over the closed route. Warehouse distance reproduces every piecewise branch of the source, and the source UI’s historical 100x display error is not reproduced.

Fleet readiness planning

solverforge-fleet 0.1.5 is a synthetic, non-operational readiness planner: 24 vessels, 24 work packages, 5 docks, 5 technician pools, 12 parts, 8 deliveries, and 56 days grouped into eight display weeks, with 66 planning decisions and 15 constraints (9 hard, 6 soft).

The identifier weekly_readiness_floor is historical. Its hard score does not sample once per week: it iterates every modeled day and enforces all three readiness thresholds daily. The workspace renders all 56 days; the separate weekly result summary samples the first day of each display week and does not weaken that enforcement.

Flight-crew assignment

solverforge-flightcrew 0.1.2 assigns every required pilot and flight-attendant seat across 6 airports, 24 crew members, 10 flight legs, and 42 required seats, with 12 constraints (10 hard, 2 soft).

It preserves the executable scheduling concepts from its source Java/Timefold application while using SolverForge’s retained-job runtime and exact snapshot analysis. Hard rules cover seat coverage, exact skill qualification, overlap prevention, connection continuity, availability, home- and away-base minimum rest, 36-hour extended recovery, and 48-hour recovery after long-haul duty. The long-haul threshold follows the source’s executable rule: at least 10 hours.

How They Are Released

Each app keeps its own version in uc-*/Cargo.toml, its own CHANGELOG.md, and its own app-prefixed tag stream, so a bare v<version> tag is never used in this bundle because it would be ambiguous:

solverforge-furnace@2.0.2
solverforge-orders@0.1.2
solverforge-fleet@0.1.5
solverforge-flightcrew@0.1.2

uc-furnace, uc-orders, uc-fleet, and uc-flightcrew are intentionally excluded from the Hugging Face sync workflow. They are published from this repository only, and an app joins the sync matrix only once its Space target exists.

October Runtime Updates

The October 14 releases moved all eight apps to solverforge 0.21.2; the October 15 releases moved them to solverforge 0.21.3, carrying the corrected net-adjacency updates for list-precedence scoring. The October 18 releases move all eight to solverforge 0.22.0, carrying the shared grouping-accumulator kernel and position-based membership updates. UI assets remain at 0.9.0; map-backed apps retain solverforge-maps 2.1.4. These are runtime dependency updates: the domain models, constraints, and demo datasets are unchanged.

The October 15 hosted apps’ release-tag sync workflows completed: Hospital, Lessons, Deliveries, and Field service. The October 15 bundle CI run passed at c5a30f6113d3b4e60ea2e9b6b7f22c5eb6bdc8c3, and the October 18 bundle CI run passed at abc4905537bc38d7e0fbeeea9576084d27db274c. The October 18 hosted apps’ release-tag sync workflows also completed: Hospital, Lessons, Deliveries, and Field service. The release command rejects a detached HEAD before creating a release.

Published Version Boundaries

The table below records the original September release. The October releases above supersede these versions without changing which apps have hosted Spaces.

Where to read next

Inspect all eight in the use-case showcase, which carries each case’s data shape, constraint summary, narrated walkthrough, and annotated screenshots, or follow the written guides for hospital, lessons, deliveries, and field service.