Skip to content

Plugin source and runtime validation

Plugin documentation is not accurate merely because it passes Markdown or link validation. Review configuration/default claims, C++ and Lua APIs, and runnable examples against the release source and, where behaviour matters, a runtime built from the same release.

Inventory

Run the inventory from the documentation repository, supplying the exact RT source checkout used for the release review.

python3 assets/scripts/inventory_plugin_guides.py \
  --docs-root . \
  --source-root /path/to/cvedia-rt \
  --coverage /path/to/review-coverage.json \
  --output plugin-guide-inventory.json

The JSON report enumerates every plugins/**/index.md guide, maps it to a source plugin directory where one exists, and counts configuration, API, default-value, and code-example claim surfaces. A directory match is discovery evidence only; it does not validate the claims.

Coverage record

Use the optional coverage JSON to record evidence for each guide. Omitted guides are reported explicitly as unreviewed for configuration, API, and examples.

{
  "guides": {
    "input/appsrc": {
      "configuration": "source-verified",
      "api": "source-verified",
      "examples": "source-only",
      "evidence": "AppSrc interface/configuration source paths; no injection fixture executed"
    }
  }
}

Valid evidence labels are unreviewed, source-verified, runtime-verified, and source-only. Use source-only when source proves a contract but a representative runtime run is still required. Record the exact source paths and subclaims in evidence; do not promote unreviewed claims on the same page. A runtime receipt covers only the command and path it executes—for example, a C++ rtcmd debug read file-read smoke does not verify Lua examples. Do not mark a guide accurate from link or lint success.

Review procedure

  1. Pin and record the RT source revision and installed runtime version.
  2. Inspect plugin headers, Lua bindings, configuration descriptors, and read-config code for every claim-bearing guide.
  3. Run an isolated representative fixture for each plugin family where accepted configuration or runtime behaviour matters.
  4. Record the command, inputs, outputs, environment, and remaining coverage gaps in the coverage file or release evidence.
  5. Correct only independently confirmed mismatches. Keep guides with incomplete evidence visibly unreviewed.