releases
SolverForge Use Cases: Four Repository-Only Apps on the 0.19.7 Line
The solverforge-usecases bundle now ships eight runnable apps. Heat-treatment scheduling, warehouse order picking, fleet readiness, and flight-crew assignment join the four published use cases, all on solverforge 0.19.7 with solverforge-ui 0.9.0.
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.
Published Version Boundaries
| App | Version | Space |
|---|---|---|
solverforge-hospital |
2.0.8 |
SolverForge/solverforge-hospital |
solverforge-lessons |
2.0.10 |
SolverForge/solverforge-lessons |
solverforge-deliveries |
2.0.9 |
SolverForge/solverforge-deliveries |
solverforge-fsr |
2.0.10 |
SolverForge/solverforge-fsr |
solverforge-furnace |
2.0.2 |
repository-only |
solverforge-orders |
0.1.2 |
repository-only |
solverforge-fleet |
0.1.5 |
repository-only |
solverforge-flightcrew |
0.1.2 |
repository-only |
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.