Running Registry Entries in Isolation to Validate Inventory

Stubs masquerade as inventory

A software inventory that lists 1 200 components but cannot be built is not an inventory. The count is a claim, not a fact. In many monorepos half the registry rows are placeholders – a name, a version range, a brief description. They never compile, never run, and never get exercised by a test suite. When a downstream team asks “does the component exist?”, the answer is “it is listed”. The reality is “the code cannot be executed”. That gap is the source of brittle releases and wasted effort.

Execute each entry in a sandbox

The remedy is simple: treat every registry entry as a runnable artifact. Spin up a lightweight sandbox – a container or a VM with only the declared dependencies – and invoke the component’s entry point. The sandbox must be identical for every entry, so the environment does not become a hidden variable. The process is:

## Pseudo‑code for a single entry
sandbox=$(create_sandbox --deps $(cat entry.deps))
run "$sandbox" ./bin/${entry.name} || record_failure $entry.id

The sandbox isolates side effects. If the component expects a database, provide a mock. If it needs a compiler, install the exact version declared in its manifest. The key is that the run is computed rather than generated: the code is owned, the result is repeatable, and no model decides the outcome.

When the run finishes, the harness records a verdict. The SHPBL harness distinguishes CERTIFIED, PROVISIONAL, INCONCLUSIVE, and FAILED. For registry validation we care only about CERTIFIED (the component executed successfully) and FAILED (the component could not be run). Anything else signals a missing contract – a harness limit, not a defect in the component itself.

Prune failures, keep health signals

After the batch run, collect the verdicts. Entries that returned FAILED are stubs or mis‑configured assets. Remove them from the public catalog, or flag them for remediation. The remaining CERTIFIED rows form a true, executable inventory. Because each row has been exercised, you can now trust the count: every line corresponds to a runnable piece of code.

The process also yields a code health signal. Re‑run the harness periodically; a component that flips from CERTIFIED to FAILED signals a regression. Conversely, a PROVISIONAL entry that later passes a full test suite can be promoted. This continuous executable audit turns a static list into a living health dashboard.

Monday’s concrete step

1. Clone the repository you want to audit.
2. Run the SHPBL harness locally (see the /harness page for the command line).
3. Capture the CSV of verdicts and delete every row marked FAILED.

You will finish the day with a trimmed registry that only contains components you can actually run. The next sprint can focus on fixing the removed stubs, turning them into reliable assets.

For a deeper walk‑through of why a count alone is insufficient, see the pillar post “A component count is not an inventory”. It explains how executable audits close the gap between metadata and reality.

By the end of the week you will have replaced a speculative inventory with a verifiable one. The effort pays off in reduced integration pain, clearer dependency graphs, and a healthier codebase.