March 7, 2026
Recent MockForge Reliability Updates: Admin Startup, Better Failure Reporting, and Correct Response-Code Checks
Reliability work is often the difference between an interesting tool and one that teams actually adopt.
The `0.3.72` and `0.3.73` releases focused on first-run usability and output accuracy. The admin UI now starts cleanly even when production auth is not configured, failed conformance checks are easier to inspect, and response-code and schema validation checks are based on the server returning the status codes and types the spec actually declares.
What improved
- `0.3.72` stopped `mockforge serve --admin` from panicking when no production auth is configured, added an auto-generated JWT secret fallback, and seeded default users so login works immediately.
- `0.3.72` also added failed-check reporting with pass/fail counts so conformance results are easier to debug.
- `0.3.73` added `X-Mockforge-Response-Status` handling so `response:400` and `response:404` checks can validate the intended response code instead of defaulting to the first status in the spec.
- `0.3.73` also corrected object and array generation so schema validation does not fail because a mock response used a placeholder string where the schema expected structured data.
Why this matters
These are not cosmetic fixes. They reduce setup friction, improve trust in first-run behavior, and make conformance results more believable. A failing check is only useful if the report is clear and the underlying mock server is returning the right shape and status code for the scenario being tested.
Practical outcome
Better first-run admin startup, clearer failed-check output, and conformance checks that line up with real response codes and schema types.
This is the kind of release work that makes a product feel dependable: fewer surprises on startup, better visibility when checks fail, and fewer false negatives caused by mock generation shortcuts.