Web dashboard and JSON API¶
adacovex --target=. --serve --port=8080 runs the full assessment and then
starts a built-in HTTP/1.1 server (no external web stack) serving a
viewable HTML dashboard, a machine-readable JSON API, and the SVG
badges. The server blocks until interrupted – run it in its own terminal
(or as a background process when scripting).
adacovex --target=. --serve --port=8080
# in another terminal:
curl http://localhost:8080/api/metrics
The dashboard guide is split across five pages. This page covers using the served dashboard and its endpoint table. The dashboard document itself (tabs, dependency views, split-view detail panel, search) is on The dashboard document and its dependency views; the JSON API, the API playground, and the themes are on The dashboard JSON API, playground, and themes; the chart cards and the robustness tier are on Dashboard metric charts; the bundled offline manual and its compression and navigation are on The bundled offline manual.
How to use the dashboard¶
Open http://localhost:8080 in a browser. The page is a single self-contained
document (no external assets) with hash-routed tabs; the theme dropdown and
Save settings persist your choice.
Overview tab¶
Start here. The Robustness tier (S / A / B / C / D) is a single letter summarising five quality axes: Docs, Proof, Tests, Compliance, and Deps. S means healthy across the board; D means an axis is below 50%. Below that:
SPARK radar – proved verification conditions per check category (flow, initialization, runtime, assertions, functional). A balanced polygon means every category has strong coverage; a spike in one corner and a flat line in another means the proof effort is uneven.
Tests donut – passed vs failed tests. A full green arc means 100% passing. Any red slice means the test suite has failures that must be fixed before the project can be assessed as
Achieved.Doc coverage donut – documented subprograms as a percentage of total. Strict mode requires 100%. A shortfall here shows exactly how many subprograms are missing
--docstrings.Dependency scope ring – the resolved graph broken down by scope (base / dev / transitive / vendored / system / test), hoverable per segment (hover shows the scope name and its component count, for example
test: 3).
Proof check bars scale with the category’s magnitude, the same way as the test-category bars: a 407-VC category reads as a longer bar than a 56-VC one, so relative proof effort is visible at a glance.
Proof tab¶
Shows the SPARK level (Stone .. Platinum) and per-category VC counts. The mini VCs proved / total at the top is the headline number; a low category is where the proof effort must focus.
Tests tab¶
Every test category with its count and Pass / Fail. A single failing category
is enough to fail the compliance gate (Tests passing must be Yes for
every tier except QM / DAL-E).
Compliance tab¶
Shows the target integrity level, overall Achieved / Unmet, HLRs traced,
orphan-tag state, and every unmet criterion. Use this to verify that every HLR
is tagged in source and that no tags are orphaned (tagged but not defined in
compliance/HLR.md).
Dependencies tab¶
An interactive dependency tree (or diagram) of every component in the graph.
Use the filter input and scope checkboxes to focus on a scope; click a node
to see its licence, PURL, parent, and a registry link. Use this tab to audit
your supply chain: confirm every vendored licence is compatible, see which
system tools the build needs (the system scope), and trace each component
back to its source.
The diagram view (toggle Tree / Diagram) renders the same graph as a directed diagram.
Charts tab¶
Eight CSS-only cards show the same data as the Overview tab in a different format. See Dashboard metric charts for the full card-by-card breakdown.
API tab¶
An interactive REST API playground: every endpoint the server dispatches on
as a searchable, clickable button, with a pretty-printed, syntax-highlighted
JSON preview. The first endpoint (/api/metrics) runs automatically. See
The API playground for the full detail.
Interpreting the charts¶
Green / full arcs – the metric is at 100% or close to it.
Red slices or flat corners – there is a regression or missing data.
Scope rings – a large vendored wedge means strict-mode docstrings are being suppressed by patches.
Tier letter drops – the average across the five axes fell; check the axis table to see which one regressed.
The same data is headlessly available at /api/metrics and via
--emit-metrics=PATH ({"metrics":..., "dependencies":...}).
Path |
Content |
|---|---|
|
HTML dashboard (tabbed) |
|
JSON object with the key assessment metrics |
|
JSON dependency graph (same data as the Dependencies tab) |
|
JSON endpoint catalog (the list the API playground builds its UI from) |
|
JSON SPARK proof coverage: the three metrics, off classes, and per-group rollups |
|
JSON server and run metadata: version, target, port, workers, uptime, cache counters, assessment time, and per-route request counters |
|
JSON health probe for scripts: |
|
The bundled offline manual (the Sphinx manual, built into the binary) |
|
SPARK assurance level badge |
|
Test pass/fail badge |
|
DO-178C compliance badge (Achieved / Unmet) |
|
ISO 26262 compliance badge |
|
IEC 62304 compliance badge |
anything else |
|
The server runs a small HTTP/1.1 implementation with a task pool that
scales to the host’s logical CPU count within 2..8 workers (configurable
with --serve-workers=N or its
--workers=N alias) and serves
requests until the process is interrupted (Ctrl-C). Query strings and URL
fragments are stripped before routing, so /?theme=light,
/api/metrics?x=1 and /api/deps#top reach the same handlers as /,
/api/metrics and /api/deps instead of 404ing.
Scripts poll GET /health for the
liveness verdict and read GET /api/info for the counters of the running
server. Both stay on loopback with the rest of the dashboard: the server
binds 127.0.0.1 only.
The bundled offline manual served at /docs is documented on
The bundled offline manual.
Charts¶
The eight chart cards and the robustness tier are documented on Dashboard metric charts.