What runx Added to a Sourcey Documentation Run

The job

I used Sourcey 3.6.5 to generate a navigable reference for cenkalti/backoff v7 at commit ffcfd8ab39e2910a1180ba0b7a02a52f0485adc9. The output covers all 24 exported API symbols and is published at the durable Backoff reference.

Why add runx?

A generated site can look correct while its source revision, command, or validation steps remain ambiguous. runx made the execution inspectable: it produced a sealed receipt for the governed validation graph, linked its child steps, and gave the delivery a stable reference that a reviewer could compare with the public artifacts.

The useful distinction is simple: Sourcey produced the documentation; runx recorded the governed execution and its closure. The receipt supports the claim—it does not replace inspection of the generated pages.

The reproducible path

runx --version
# runx-cli 0.8.2

git checkout ffcfd8ab39e2910a1180ba0b7a02a52f0485adc9
npm run docs:build
# sourcey build --output ../public/backoff

The resulting evidence packet records the upstream repository, pinned commit, MIT license, generator version, adapter configuration, command, page list, symbol count, and coverage notes. The public receipt is runx:receipt:sha256:9bea6ad29f1540914390d42d4ffca6671db7bd677e9d879866b0afa7882a2aa8.

What was actually verified

The Sourcey output loads over public HTTPS and exposes package navigation and search.
Every documented symbol maps to the pinned upstream source rather than a moving default branch.
The evidence JSON contains concrete observations instead of a prose-only completion claim.
The maintainer report identifies specific documentation gaps, including retry-count semantics, context deadlines, concurrent statefulness, and ticker overlap behavior.
The runx graph receipt is structurally verifiable and links the governed build and validation steps.

Where runx helped—and where it did not

The receipt made provenance and execution closure easier to audit, especially when the final result crossed tools: Git, Go source, Sourcey, static hosting, and a public review packet. It did not prove that every explanation was editorially perfect, that the hosting would remain online forever, or that a maintainer endorsed the output. Those still require human review and live URL checks.

When this pattern is worth using

For disposable local experiments, a receipt may be more process than value. For public agent work—where a reviewer must distinguish a real run from a plausible narrative—the combination of pinned inputs, explicit commands, inspectable outputs, and a sealed run receipt is useful. The runx repository is the right starting point for contributors who want to inspect or extend that execution model.