ProtostarMetrics.
Can the tests catch a bug?
Mutation testing introduces small deliberate bugs into selected engine modules. The score is the share caught by a failing test or timeout, out of caught, surviving, and suspicious mutants. Mutants no test reaches are excluded. This measures the modules listed below, not the whole codebase.
The overall line combines raw counts, so larger modules carry more weight. Dashed vertical markers show a change in the module set; compare across them with care. Toggle module lines in the legend to inspect their trends.
Loading mutation history…
Latest module scores
| Module | Score | Caught / decided | Not reached |
|---|
Recent scores and changes of scopeLast 30 runs
| Measured | Overall | Commit | Module set |
|---|
Does a failed run leave nothing behind?
Every night, Protostar fails a real init or sync at each
write, directory, removal, and command of every built-in template, with an error and with an interrupt,
before, during, and after the step. A fault counts as restored when the project and home directory come back
byte for byte. The count covers every operating system the nightly run uses.
The overall line adds every job’s count, so it rises when a template, a step, or a platform is added. Dashed vertical markers show a change in the set of jobs. Toggle operating systems and templates in the legend to inspect them.
Loading rollback history…
Latest faults by template
| Template |
|---|
Recent runs and changes of scopeLast 30 runs
| Recorded | Faults restored | Commit | Jobs |
|---|
Is Protostar getting slower?
Every night, a new commit on main is timed against the last one recorded, on Linux: init for every built-in template, sync, status, and
diff on a project with nothing to update, the recipe editor’s first frame, and startup.
Both versions run on the same runner in alternating rounds, so the comparison holds even though a shared
runner’s speed varies from one night to the next.
A scenario counts as slower when Protostar’s own CPU time is at least 10% slower across its whole 95% interval, and a second run against the same baseline must find it again before an issue opens. Wall time includes the commands Protostar waits on, such as uv. Shared runners are slower than most computers, so read the trend rather than the number.
Loading benchmark history…
Latest run
| Scenario | Wall | CPU | Commands | CPU change | Verdict |
|---|
Recent runsLast 30 runs
| Recorded | OS | Commit | Compared with | Slower |
|---|
Archived startup timingsMarch to October 2026
Until October 2026, CI timed protostar help init and the recipe
editor’s first frame with Hyperfine on every push to main, as the mean of 90 runs. Each push ran on
whichever runner it got, so these points compare different machines, and they are kept apart from the
nightly comparisons above.