Executable Registry Entries as True Inventory

Stub entries break the audit

Teams often publish a component registry that looks impressive on paper. The count climbs into the hundreds. Behind the numbers sit placeholder files, empty wrappers, or generated stubs that never load. When an audit asks for a runnable artifact, the registry cannot answer.

The failure is not a lack of tooling. It is a mismatch between what a “row” means and what the audit expects. A row that cannot be executed is metadata, not inventory. The inflated count gives a false sense of coverage and hides the real maintenance burden.

Run every row through the harness

The SHPBL harness provides a single, repeatable way to exercise a registry entry. It loads the artifact, satisfies its declared contract, and records a verdict: CERTIFIED, PROVISIONAL, INCONCLUSIVE, or FAILED.

A correct posture treats the harness verdict as the source of truth. If the harness returns CERTIFIED, the row is load‑bearing and reusable. If it returns PROVISIONAL, the artifact runs but its correctness is not yet asserted; it still counts as a functional entry. INCONCLUSIVE signals a limitation of the harness, not a defect in the component. FAILED means the row cannot be executed and must be removed or fixed.

Running the harness against the whole registry turns a static list into a live inventory. The process is model‑independent; the harness does not rely on any AI model, only on the code itself. The result is repeatable byte‑for‑byte, and the published checksums act as the root of trust.

A concrete audit workflow

Pick a recent release of your internal component catalog. Export the list of registry rows as a JSON file. Feed that file to the harness via the HTTP API or the typed TypeScript client.

import { HarnessClient } from '@shpbl/sdk'

const client = new HarnessClient({ baseUrl: 'https://api.shpbl.com' })
const rows = JSON.parse(await Deno.readTextFile('registry.json'))

for (const row of rows) {
  const result = await client.run(row.id)
  console.log(`${row.id}: ${result.verdict}`)
}

The loop prints a verdict for every entry. Collect the rows that returned CERTIFIED or PROVISIONAL. Those are your true inventory.

Rows that returned FAILED should be examined. Often they are stub files that never compiled, or wrappers that reference missing dependencies. Fix the underlying code or delete the entry.

Rows that returned INCONCLUSIVE deserve a separate investigation. The harness may lack the necessary runtime environment, or the component’s contract may be underspecified. Address the harness limitation or enrich the component’s metadata, then re‑run.

When the audit finishes, you have a count that matches the number of executable rows. That count is no longer a claim; it is an inventory you can trust.

The pillar post “A component count is not an inventory” explains why a raw number is insufficient. This workflow supplies the missing execution layer that turns a count into a verifiable inventory.

Monday’s actionable step

Schedule a two‑hour slot early next week. Export your current component registry. Run the harness against every row and record the verdicts. Remove or fix any FAILED entries.

By the end of the session you will have a trimmed, executable registry and a concrete inventory you can quote in audits. The effort pays for itself the next time a stakeholder asks, “How many of these components actually work?”

---

Further reading: the live‑run harness documentation is available at /harness.