Problem statement

There's currently no way to confirm the Flask backend is running correctly or to check whether solvers are available without actually starting a model run.

I ran into this while installing MUIO v5.5 on Windows 11 — the Flask backend failed to start due to Windows Defender blocking the PyInstaller subprocess, but there was no diagnostic endpoint I could hit to verify the issue. I ended up having to trace the failure manually. On macOS or Linux (which MUIOGO is targeting for cross-platform support), users will hit different solver availability issues and need a quick way to check what's working.

This becomes especially relevant for the cross-platform packaging work where we need a reliable way to verify that the backend came up correctly and that solvers resolved on the target OS.

Proposed solution

Add two lightweight GET endpoints under /api/health:

1. GET /api/health — basic liveness check: returns OS name, architecture, Python version, and confirms DataStorage is writable. This is the endpoint that the Electron startup guard (or any external health poller) can hit to know the backend is ready.

2. GET /api/health/solvers — reports GLPK and CBC availability. Uses the same three-tier resolution chain as Osemosys._resolve_solver_folder (env var → PATH → bundled). Returns which solver was found where, so users can debug solver issues before running a model.

Both endpoints go in a new API/Routes/System/HealthRoute.py blueprint, keeping the existing route structure clean. Includes a pytest test suite.

Acceptance criteria

• GET /api/health returns 200 with platform, architecture, python version, and DataStorage status
• GET /api/health/solvers returns 200 with glpk/cbc availability info
• Solver detection matches the resolution order in Osemosys._resolve_solver_folder
• pytest tests cover both endpoints (happy path + mocked solver scenarios)
• No changes to existing CLEWS functionality

Dependencies and constraints

None. This is additive — no existing endpoints or classes are modified beyond registering the new blueprint in app.py.

Related work checked

Searched open issues and PRs:

• [Bug] Non-Windows solver paths in OsemosysClass are hardcoded dead-end stubs #43 (solver resolution refactor) — related but different scope; [Bug] Non-Windows solver paths in OsemosysClass are hardcoded dead-end stubs #43 was about fixing the resolver itself, this adds a diagnostic endpoint that uses it
• test: add pytest smoke tests for core API endpoints #315 (pytest smoke tests) — has needs-intake-fix label; my tests are scoped specifically to the health endpoints
• No other health-check or diagnostics PRs found after search

Proposed track

{"Track" => "Cross-Platform"}