Executable Component Health Dashboard for Monorepos

Counting rows without proof

A monorepo often publishes a registry of internal components. The dashboard shows a thousand rows. Management interprets that as a healthy inventory. The reality is that most rows are stubs – a name, a version, maybe a README. No one has executed the artefact. The count is a claim, not an inventory. When a build fails because a “component” cannot be compiled, the problem is discovered too late. The failure mode is clear: the dashboard reports quantity, not quality.

Running every entry through the harness

The certification harness is the only source of a repeatable health signal. It classifies an artefact as CERTIFIED, PROVISIONAL, INCONCLUSIVE, or FAILED. The classification is a harness verdict – a concrete, reproducible result. To turn a raw count into an executable inventory you must feed every registry entry into the harness on a schedule.

A minimal pipeline can be built with the typed TypeScript client. The client talks to the same HTTP API that the offline edition uses, so no extra agent is required. The steps are:

1. Query the registry for all component identifiers.
2. For each identifier invoke the harness endpoint.
3. Record the verdict together with the component metadata.
4. Persist the result in a lightweight store (for example a JSON file).

import { RegistryClient, HarnessClient } from '@shpbl/sdk';

const registry = new RegistryClient({ baseUrl: '/api' });
const harness = new HarnessClient({ baseUrl: '/api' });

async function gradeAll() {
  const components = await registry.list();          // [{id, version, …}]
  const results = [];

  for (const c of components) {
    const verdict = await harness.run(c.id, c.version);
    results.push({ ...c, verdict });
  }

  // Write a simple JSON file that the dashboard will read.
  await Deno.writeTextFile('health.json', JSON.stringify(results));
}

The code runs in a CI job or a cron container. Each run is cheap: the harness executes the artefact in a sandbox and returns a verdict. Because the harness is model‑independent and its output is computed rather than generated, the verdict is repeatable across runs.

Visualising the health verdicts

Once health.json exists, a static HTML page can render a registry dashboard that shows component health at a glance. The page reads the JSON, groups by verdict, and colours rows accordingly. No JavaScript framework is needed – a few lines of vanilla script keep the page fast and easy to host alongside the repository.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Component Health Dashboard</title>
  <style>
    table { border-collapse: collapse; width: 100%; }
    th, td { padding: .5rem; border: 1px solid #ddd; }
    .CERTIFIED   { background:#e0f7e9; }
    .PROVISIONAL { background:#fff4e5; }
    .INCONCLUSIVE{ background:#e5e5e5; }
    .FAILED      { background:#fbe4e4; }
  </style>
</head>
<body>
  <h1>Component Health Dashboard</h1>
  <table id="grid"><thead><tr>
    <th>Component</th><th>Version</th><th>Verdict</th>
  </tr></thead><tbody></tbody></table>

  <script type="module">
    const resp = await fetch('health.json');
    const data = await resp.json();
    const tbody = document.querySelector('#grid tbody');

    for (const {id, version, verdict} of data) {
      const row = document.createElement('tr');
      row.className = verdict;
      row.innerHTML = `<td>${id}</td><td>${version}</td><td>${verdict}</td>`;
      tbody.append(row);
    }
  </script>
</body>
</html>

The dashboard turns a meaningless count into a trustworthy, executable inventory. Stakeholders can see at a glance how many components are CERTIFIED, how many are still PROVISIONAL, and where failures concentrate. The visual cue replaces the false confidence of a raw number.

Making the dashboard a regular part of your workflow

The only thing that separates a static count from a living inventory is discipline. Schedule the gradeAll script to run after every merge to the main branch, or nightly if the repository is large. Store the generated health.json in the same artefact store that holds your release archives, so the checksum of the dashboard matches the checksum of the code it describes. The result is a component health signal that can be referenced in release notes, sprint retrospectives, and compliance audits.

If you have not yet tried the harness, start with a free repository evaluation. It shows how the harness behaves on a small set of components without any entitlement cost. From there, adopt the pipeline described above and let the dashboard drive your next sprint. By Monday you can have a CI job that produces health.json and a static page that anyone on the team can open to see the current health of the monorepo. The effort is a few minutes of setup; the payoff is a dashboard that tells you what truly matters – not how many rows you have, but how many of those rows are executable and certified.