Command, but it passes the command to bash via the -c flag.

Each use case for the tool should be declared as case which is a chain of elements (ideally groups and checks). Examples include "Ubuntu 22.04", "Fedora 36", "Windows", "CIS Benchmark Compilance", "System security check", and "Sanity Check"

Check, when run it returns good or bad.

Produces by running a shell command.

Global config object.

Patch file difference view. Shows how altered a file is from a standard install. Lazy loaded to avoid large diffs crashing browser.

An on-screen element that shows up the one report

File producer that reads and returns file when run.

A renderer that is customized through handlebars. Should be applicable for most use cases.

A group of elements. Will render as a collapsible section for easy browsing.

Like a check but returns a value from 0 to 1 indicating how likely it thins something is wrong.

Possibly problematic thing. Not meant to be used directly. Stuff should subclass this.

A producer is an object that returns a string when it's produce method is invoked. See it's subclasses, but most things will support Producer vs Producer comparisons so we don't need a dedicated check for shell command output vs a bundled file.

A renderer displays data from elements by generating html.

Command, but it passes the command to /bin/sh (most likely linked to dash) via the -c flag.

Just produces a single constant string. For trivial situations

Testing docs