Getting started

This walkthrough runs the actual CLI against a tiny, repository-owned static demonstration. It is credential-free and uses only numeric loopback 127.0.0.1. It demonstrates command behavior and report reading, not detection accuracy or the security of an application.

One-command development demo

With Python 3.12.4 or newer, a reviewed current tools checkout, and an already acquired local development executable, run:

python3 scripts/local_demo.py --binary ./target/release/termivar --output local-demo-output

Windows PowerShell:

python scripts/local_demo.py --binary .\target\release\termivar.exe --output local-demo-output
if ($LASTEXITCODE -ne 0) { throw "Local demo did not pass; inspect its private evidence" }

Select the actual binary path on your machine. The output directory must be fresh, and its parent must already be a trusted, private user-owned directory. The helper does not acquire or build a binary. Keep local_demo.py, first_use.py, and report_bundle_example.py together in the tools checkout.

The command starts the fixed harmless numeric-loopback fixture, runs one scan --profile web-review --report-dir assessment, and checks that a repeated write is refused before target activity. It then stops the fixture and runs the executable's offline Report Verify and self-Compare commands. Success requires a complete, unchanged three-file bundle, matching integrity checks, and all source item identities in the four-array comparison. It does not request optional review capabilities or accept a target URL.

Open local-demo-output/bundle/assessment.html yourself after success; the helper never opens a browser. demo-evidence.json and bounded captures/ remain private inside the selected output directory. Captures contain local command paths and are not automatically safe to publish. The executable's version and SHA-256 are observed; optional --source-ref FULL_SHA_OR_VERSION_TAG is only an operator declaration, not source authentication. Trusted-parent and quiescent-file assumptions apply; hashes are not an atomic filesystem snapshot.

A host-blocked executable or a binary without the required report commands produces a failed result with available private evidence. Leave host protections enabled. This demo qualifies its fixed command/report flow, not detection accuracy, a feature-enabled package, or the complete S16 program qualification. The pinned prerelease walkthrough below retains its historical identities.

Choose one binary first:

The historical alpha.1 archives do not include maintenance from PRs #109–#111. Alpha.2 includes those changes, but neither release is independently audited or production-ready. The distribution comparison records the exact release identity and build features.

Prerequisites

Use Python 3.12.4 or newer and a reviewed Git checkout containing this guide and scripts/first_use.py. Run the examples from that tools checkout, not from the separate pinned source tree. Git is needed to obtain the scripts; they are not included in the binary archive. Record the tools checkout revision with git rev-parse HEAD and inspect the script before running it.

The runner takes an already acquired local executable. It never downloads, installs, compiles, or updates tools. Its output directory must not exist, and its parent must already exist in a trusted, private user-owned location. No administrator privileges or global PATH change is needed.

Once the binary and tools are acquired, exercise traffic stays on loopback. If HTTP, HTTPS, or all-proxy environment configuration is present, the runner refuses to begin instead of changing proxy policy. Host security controls stay enabled; a blocked executable is an unexecuted step, not a reason to bypass App Control, antivirus, or Gatekeeper.

Run the local walkthrough

For the verified, locally extracted published prerelease:

Linux/macOS:

python3 scripts/first_use.py \
  --binary ./termivar-alpha2/termivar \
  --output first-use-release-output \
  --source-ref v0.10.0-alpha.2 \
  --build-features release-bundle \
  --expect-version 0.10.0-alpha.2

Windows PowerShell:

python scripts/first_use.py --binary .\termivar-alpha2\termivar.exe --output first-use-release-output --source-ref v0.10.0-alpha.2 --build-features release-bundle --expect-version 0.10.0-alpha.2
if ($LASTEXITCODE -ne 0) { throw "First-use acceptance did not pass; inspect its diagnostics" }

The runner first captures --version, --help, and scan --help. It then binds its own allocated loopback port before checking readiness. There is no target-URL option. The fixture serves only fixed / and /example documents with simple GET/HEAD behavior and a fixed response for unknown paths. It never serves your checkout, home directory, or other files.

There are no forms, query-driven endpoints, credentials, callbacks, external links/assets, or external fetches. The runner starts and stops only its own fixture and CLI child. Success, error, and cancellation paths request cleanup; any recorded cleanup failure is a failure to investigate, not a passed run. It never kills an unrelated process or reclaims an occupied port.

Development source binary

After the separate pinned source build, run from the tools checkout with the default source binary:

Linux/macOS:

python3 scripts/first_use.py \
  --binary ../termivar-source-a29ba40/target/release/termivar \
  --output first-use-source-output \
  --source-ref a29ba40c8cfdc7d0385431ea4d9e374e213ca4e0 \
  --build-features default \
  --expect-version 0.10.0-alpha.2

Windows PowerShell:

python scripts/first_use.py --binary ..\termivar-source-a29ba40\target\release\termivar.exe --output first-use-source-output --source-ref a29ba40c8cfdc7d0385431ea4d9e374e213ca4e0 --build-features default --expect-version 0.10.0-alpha.2
if ($LASTEXITCODE -ne 0) { throw "First-use acceptance did not pass; inspect its diagnostics" }

The default CLI feature list is empty; its scanner dependency enables scanning and reporting. If you deliberately built the same source with release-bundle, use that separate executable path, declare --build-features release-bundle, and choose another fresh output directory. Compiling optional capabilities does not enable their runtime actions. No optional review flags are used here.

The runner measures the executable hash and checks the actual version. The source ref and feature set are caller declarations, not inferred or attested by --version. Record the real revision and build command; never relabel a source build as release-archive acceptance.

Inspect compiled CLI capabilities

A development binary whose top-level help lists capabilities can describe its own fixed CLI surface without a target, credentials, repository, Cargo, Git, Python, or scanner startup:

termivar capabilities
termivar capabilities --format json

The synchronous command reports the exact termivar-cli feature gates compiled into that executable. compiled does not mean selected, exercised, runtime-ready, production-ready, or officially released: profiles and review options still require their listed explicit inputs. The package version and feature states are self-reported build metadata, not source authentication.

The CLI's default feature list is empty, while its unconditional scanner dependency still provides scanning and reporting. The release-bundle composition marker compiles artifact-adapter, normalization-resilience, graphql-review, openapi-review, rest-review, and authorization-review in the published alpha.2 composition. The current untagged alpha.3 development composition also compiles the wordpress-review Preview. It does not activate any of them: WordPress still requires explicit --profile web-review --wordpress-review. Current alpha.3 excludes control-reference-mapping, supplied-session-review, secret-exposure-review, tls-negotiation-review, tls-observation, jwt-policy-review, jwt-target-acceptance-review, recon-ct-provider, recon-snapshot-import, ssrf-oast-review, template-evaluation-review, websocket-review, xml-external-entity-owned-https-test-profile, xml-external-entity-review, legacy-scanner, api-adapter, and proxy-adapter. The stock curated inventory is therefore exactly 25 known identities: eight compiled (the release-bundle marker plus seven members) and seventeen excluded. The owned-HTTPS test profile adds no CLI option and remains outside default, release-bundle, and published packages. Enabling the seven current member features individually can therefore produce the same member surface states while release-bundle remains not_compiled.

These preserved excerpts are from real Windows x86_64 development binaries built in separate directories from source implementation commit 5bd1260e1d9f57226046a6a955662c32fcad6464 on 2026-09-06. Both reported 0.10.0-alpha.2, 20 surface records, the historical six-member bundle composition, and runtime_execution: not_performed:

# cargo build --locked -p termivar-cli
# executable SHA-256: 55d6eec93eb21869ae134e4572564f315430b9b3ee03ab559ec506474493a72d
[compiled] Compiled CLI capabilities (command, preview; implemented)
[compiled] Bounded deterministic scan (command, preview; implemented)
[not_compiled] REST read-only review (scan_option, preview; implemented)
[not_compiled] HTTP API adapter (command, unsupported; unsupported_stub)

# cargo build --locked -p termivar-cli --no-default-features --features release-bundle
# executable SHA-256: 35ebb7a766653c94263f589c12e0fda71f44d551a192244de7a10b739b782782
release-bundle=compiled
artifact-adapter=compiled
authorization-review=compiled
graphql-review=compiled
normalization-resilience=compiled
openapi-review=compiled
rest-review=compiled
ssrf-oast-review=not_compiled

The hashes identify the two files that were executed; they are not build attestations. The historical v0.10.0-alpha.1 archives and earlier pinned a29ba40c8cfdc7d0385431ea4d9e374e213ca4e0 source walkthrough predate this command; the published alpha.2 archives include it. Those published archives report ssrf-oast-review=not_compiled, as shown above. The published alpha.2 tag retains the historical source defect; current development source corrects candidate/replay polling-phase completion. Compiling ssrf-oast-review still does not activate it or raise its maximum result above NeedsReview / KnowledgeOnly.

Review one supplied JWT against a local policy

The unreleased development source has a non-default jwt-policy-review feature. It is not part of the seven-member release-bundle or published alpha.2 archives. Build a feature-specific executable:

cargo build --locked -p termivar-cli --no-default-features \
  --features jwt-policy-review

Then select one strict local policy, one local ES256 public JWK, and exactly one token source:

termivar scan <AUTHORIZED_EXACT_ROOT> \
  --profile web-review \
  --jwt-policy jwt-policy.toml \
  --jwt-public-jwk public-key.jwk \
  --jwt-token-file compact-token.txt \
  --report-dir jwt-assessment

Use --jwt-token-env ENV_VAR or --jwt-token-stdin instead of the file option when appropriate; never put the token in argv. The local JWT evaluator is transport-free: it does not retrieve a remote key or add a target request. Unless the separate non-bundled jwt-target-acceptance-review feature and explicit --jwt-target-acceptance-policy are selected, it does not send or replay the token. The surrounding scan retains its ordinary authorized web requests. It supports only bounded compact ES256 JWS input and one strict local P-256 public JWK. The V1 policy requires an explicit non-secret policy_revision plus intended typ, issuer, and audience bindings; none of these three checks can be disabled. Preflight validates its closed structure and canonical 32-byte coordinates, while curve membership and signature validity are decided by local verification. A parsed token is not thereby signature-verified, and local verification does not mean a target accepted the token. The optional target child uses six bounded valid/anonymous/invalid candidate/replay requests against one exact authorized JSON resource, but it does not authenticate the issuer, prove authorization bypass, validate impact, or emit a Confirmed finding. See the local JWT and optional target-acceptance contract.

Map completed items to reviewed control references

The unreleased development source has a non-default control-reference-mapping feature. It is outside the seven-member release-bundle and published alpha.2 archives. Build a feature-specific binary, then select the option with an explicit web-review profile:

cargo build --locked -p termivar-cli --no-default-features \
  --features control-reference-mapping

termivar scan <AUTHORIZED_TARGET> \
  --profile web-review \
  --control-reference-mapping \
  --report-dir assessment-with-control-references

The mapper runs only over completed typed assessment items. It adds zero target or provider requests and never retrieves standards content at scan time. The V1 built-in catalogue includes attributed OWASP Top 10:2025 IDs/exact title references and original Termivar rationale. PCI DSS 4.0.1 and ISO/IEC 27001:2022+Amd 1:2024 are bibliographic rights_deferred sources with no embedded control mappings. KVKK Law No. 6698 Article 12 and Guide No. 72 (April 2025) are relevant technical context with applicability unestablished.

The output does not change item severity, disposition or claim authority. It is not a score, pass/fail result, certification, legal advice or compliance determination, and absence of an item is not control fulfilment. See the versioned mapping contract.

Import a bounded local reconnaissance snapshot

The development-only recon-snapshot-import feature adds one explicit, transport-free reference input to web-review:

cargo run --locked -p termivar-cli --no-default-features \
  --features recon-snapshot-import -- \
  scan https://owned.example/ --profile web-review \
  --recon-snapshot recon-snapshot.json \
  --report-dir assessment-recon

The strict V1 document contains only source-qualified CT-name, DNS-history, service-banner-product and reputation-label hypotheses. Import does not contact those assets or providers, extend target scope, or create assessment items. Its byte digest identifies the supplied bytes without authenticating their source, rights, freshness, completeness or truth. See the local recon snapshot contract.

Review one explicitly authorized WebSocket endpoint

The development-only websocket-review feature is not part of default, the seven-member release-bundle, or the published alpha.2 archives. Build a feature-specific executable and supply one strict local policy:

cargo build --locked -p termivar-cli --no-default-features \
  --features websocket-review

termivar scan https://owned.example/app/ \
  --profile web-review \
  --websocket-review-policy websocket-review.json \
  --report-dir assessment-websocket

A minimal policy shape is:

{
  "schema": "security.websocket-review-policy/v1",
  "target_authorized": true,
  "messages_read_only_acknowledged": true,
  "message_content_is_non_secret": true,
  "endpoint": "wss://owned.example/app/socket",
  "origin_mode": "application_origin",
  "subprotocol": null,
  "compression": false,
  "reconnect": false,
  "messages": [
    {
      "id": "status",
      "text": "{\"type\":\"status\"}",
      "expected_response": {
        "sha256": "a29ee2b15c494311c52521766e44af56a3ad2248e7a8ab465e5206463c13d288",
        "length": 15
      }
    }
  ],
  "limits": {
    "max_inbound_message_bytes": 4096,
    "max_outbound_message_bytes": 4096,
    "max_messages": 1,
    "max_control_frames": 4,
    "max_wall_time_ms": 3000
  }
}

The example is a template, not an executable fixture: replace the endpoint, message, digest, length and limits with independently reviewed values for an owned application. The three booleans record operator assertions; Termivar does not verify that a message is side-effect-free or that its content is non-secret. V1 does not support credentials or other secret material in message bodies. Each message id is a non-secret revision handle and must change whenever that message or its expected-response semantics change. Public report references do not hash either private byte sequence. By default V1 opens one isolated anonymous connection. When both websocket-review and supplied-session-review are compiled, an operator may explicitly add --websocket-supplied-session to one V1 Authorization-header session policy with exactly one protected resource. That composition runs startup health, resource staging, one credentialed WebSocket exchange and terminal health; both checkpoints must be healthy before the declared context and resource are qualified. Without the flag, the WebSocket remains anonymous. V2 cookie and V3 form-login policies are rejected before secret/output acquisition, and the same session cannot feed both the WordPress and WebSocket consumers.

Both paths send at most eight sequential text messages, allow at most 64 KiB of application payload in each direction, and stop at ten seconds or the smaller parent deadline. Plain ws is accepted only for numeric-loopback test fixtures; other targets require wss with normal certificate validation. There is no endpoint discovery, retry, reconnect, redirect following, compression, proxy inheritance, cookie forwarding, arbitrary credential forwarding, or HTTP/2 extended CONNECT. The report distinguishes raw socket transport accounting from complete application-message bytes. Binary application messages fail closed. The backend does not expose a reliable physical continuation-frame count, so it is reported as unavailable; message/frame-size ceilings, observable control-frame events and the absolute deadline still bound work. A client-selected Origin does not prove a browser exploit path, and an Upgrade or expected-response match does not establish authentication, authorization, availability, source authenticity, a vulnerability, exploitability or impact. Session checkpoints qualify only the declared bounded context window; they do not prove continuous authentication. See the WebSocket review contract.

Live assessment progress

The unreleased 0.10.0-alpha.3 development source adds opt-in live progress for an explicit web-review assessment:

termivar scan <AUTHORIZED_TARGET> \
  --profile web-review \
  --progress \
  --format json > assessment.json 2> progress.log

The published v0.10.0-alpha.2 archives do not contain --progress. The flag is rejected for no-profile invocations (including a bare decision-scan) and for baseline before secret loading, output reservation, or network construction. The decision-scan alias accepts it when --profile web-review is explicit. It does not enable a scanner capability or add requests.

Progress is a bounded, best-effort presentation channel on stderr. Report Markdown/JSON on stdout and files selected with --report-output or --report-dir keep their existing bytes and schemas. Each ASCII line begins with [progress] and names a coarse lifecycle state such as assessment_running, composing_report, rendering_report, writing_stdout, publishing_report, or a terminal state. Periodic running snapshots are sampled once per second; a slow sink may cause intermediate snapshots to be coalesced or dropped rather than delaying the assessment.

The counters are explicitly last-observed accounting snapshots. accounted_requests is cumulative parent-broker request accounting, including already-accounted child activity; it is not a response count. accounted_active_verifications is a cumulative charged-verification count, not current concurrency. subjects_started counts child-runtime execution boundaries; subjects_processed counts subject states committed for report projection, not successful subjects or findings. Neither predicts future work. Before the first runtime checkpoint, unavailable counts are shown as unknown rather than being presented as measured zeroes. Elapsed milliseconds use a separate monotonic presentation clock. It starts after runtime construction, immediately before the one assessment analysis, and ends when the terminal line is prepared after the selected stdout or file publication succeeds or fails. It therefore includes report composition, rendering, publication, and progress handoff time; it does not replace, extend, or alter the runtime deadline clock.

There is no percentage, ETA, endpoint, finding title, severity, vulnerability verdict, or raw evidence in this stream. A terminal completed state means the selected report output also completed; render or publication failure remains a distinct failed state. On bundle-publication failure, the terminal record can state whether the manifest commit point was reached, without exposing the directory. Progress-write failure disables further presentation and does not change the scan result. If an operating-system stderr write blocks forever, one detached presentation worker may remain until process exit. A later diagnostic using the same process stderr lock can then also wait behind that OS write, so the command cannot promise bounded exit in this host-level failure. The writer is never used for scan control or backpressure.

Opt in to WordPress evidence review in current development builds

The unreleased development source has a non-default wordpress-review build feature. The current untagged alpha.3 release-bundle compiles the Preview, but the ordinary default build and published alpha.2 archives do not. Build the current development bundle deliberately:

cargo build --locked -p termivar-cli --no-default-features --features release-bundle

For a smaller feature-specific development build, the existing direct feature selection remains available:

cargo build --locked -p termivar-cli --no-default-features --features wordpress-review

Neither build command activates WordPress review. Runtime selection remains explicit.

Against an already running, authorized fixture or exact origin, select the review explicitly:

termivar scan <AUTHORIZED_EXACT_ROOT> \
  --profile web-review \
  --wordpress-review \
  --wordpress-context <CONTEXT.json> \
  --wordpress-advisories <CATALOGUE.json> \
  --report-dir <NEW_REPORT_DIRECTORY>

Instead of the native Termivar catalogue, an already saved Wordfence V3 Production-format export can be selected explicitly:

termivar scan <AUTHORIZED_EXACT_ROOT> \
  --profile web-review \
  --wordpress-review \
  --wordpress-plugins-json <WP_CLI_PLUGINS.json> \
  --wordpress-themes-json <WP_CLI_THEMES.json> \
  --wordpress-core-version-file <CORE_VERSION.txt> \
  --wordpress-advisories <WORDFENCE_PRODUCTION.json> \
  --wordpress-advisories-format wordfence-v3-production \
  --wordpress-external-version-profile php-release-subset/v1 \
  --report-dir <NEW_REPORT_DIRECTORY>

All local files are optional, but each requires --wordpress-review; the saved inventory files conflict with --wordpress-context. External format selection never fetches the feed or searches for an API key, and omitting it keeps the native Termivar catalogue contract. The optional external version profile is accepted only for an explicitly selected local wordfence-v3-production file. Choose numeric-dotted/v1 or php-release-subset/v1 to request that named Termivar interpretation. Omitting the selector preserves the unresolved v4 behavior; selecting it produces the strict v5 audit and records explicit_operator selection with source semantics still not_established. There is no profile inference or fallback. WordPress interpretation reuses the complete root HTML already obtained by the assessment and adds no request or active verification. Generator metadata and asset paths are hints rather than authenticated installation facts; the context is an operator declaration, the catalogue is a supplied snapshot, and advisory applicability stays audit-only. See the WordPress evidence review contract and its clearly labelled input examples.

Export one assessment in two formats

The published v0.10.0-alpha.2 binary and later development builds whose scan --help includes --report-dir can create HTML and JSON from one completed assessment:

termivar scan <AUTHORIZED_TARGET> \
  --profile web-review \
  --report-dir ./assessment-001

Use only an exact origin you are authorized to assess. The parent of assessment-001 must already exist as a trusted, private, user-owned directory, and assessment-001 itself must not exist. The command neither overwrites nor reuses an existing file, directory, or link and does not create missing parent directories. On Windows, the new directory inherits the parent's ACL. Termivar checks the immediate parent is an existing non-link directory; the operator supplies the trust/ownership assertion for that parent and its ancestors.

A successful directory contains exactly assessment.html, assessment.json, and manifest.json. The runtime runs once, composes one completed typed assessment, and renders both report formats from it. manifest.json is published last and records exact lengths and hashes for the other two files. Those hashes identify bytes; they are not a signature or proof of scope. The payload files can be visible while publication is in progress, so readers must require and verify the final manifest rather than assume whole-directory atomic visibility.

--report-dir requires explicit web-review and cannot be combined with --report-format or --report-output. --format still selects only the existing diagnostic encoding for an incomplete/failed run; it does not change the bundle's fixed HTML and JSON formats. An incomplete run creates no completion manifest. A crash can leave an incomplete directory, which must not be silently reused.

The bundled JSON retains the normal assessment schema. Two deliberately chosen bundles can be compared offline:

termivar report compare \
  --before assessment-001/assessment.json \
  --after assessment-002/assessment.json \
  --same-scope

The published alpha.2 archives include this option. The preserved alpha.1 archives and checked-in first-use captures do not. See the full bundle and manifest contract.

Verify a saved bundle offline

The published v0.10.0-alpha.2 binary and later development builds whose report --help includes verify can check the fixed three-file bundle without scanning, launching, or rendering the HTML:

# Text result.
termivar report verify --dir ./assessment-001

# Structured result.
termivar report verify --dir ./assessment-001 --format json

Exit 0 and integrity_match mean that the supported directory layout, manifest contract, exact payload lengths and SHA-256 digests, and the completed assessment JSON summary matched for the bytes read during this invocation. Exit 1 and not_verified identify an incomplete, unsupported, unreadable, or mismatched bundle with typed reason codes; checks prevented by an earlier failure remain not_checked. Invalid CLI syntax exits 2.

Run verification only on a quiescent directory beneath trusted parent directories. Termivar rejects a linked/reparse-point final directory and non-regular payloads, but it does not prove every ancestor is trustworthy or create an atomic filesystem snapshot. The command makes no application writes, repairs, removals, or permission changes. It reads only manifest.json, assessment.html, and assessment.json, hashes and validates the same captured payload bytes, and initializes no scanner, credentials, provider, or network client.

An integrity match is not a signature or source-authenticity result. It does not establish original target scope, finding accuracy, remediation, HTML safety, or HTML-to-JSON semantic equivalence. A consistently edited payload and manifest can still be internally consistent. For a control-reference audit it does not establish catalogue truth, source authenticity, applicability, legal meaning or control fulfilment. The HTML is never executed.

Once checked, compare two deliberately selected assessment payloads with the existing offline command:

termivar report compare \
  --before assessment-001/assessment.json \
  --after assessment-002/assessment.json \
  --same-scope

The verifier checks one bundle's supported internal consistency; comparison groups observations and separately relies on the operator's same-scope assertion. See the full verification contract. The published alpha.2 archives contain both --report-dir and report verify; the preserved alpha.1 archives contain neither.

Open the outputs

A passed run prints first-use: passed and retains these files in the selected output directory:

File What it contains
default.json Actual no-profile decision-scan/v1 operational output, not a findings report
assessment.json Completed root web-review assessment from the existing JSON renderer
assessment.html Completed root web-review assessment from a separate CLI execution using the existing HTML renderer
provenance.json Binary hash/version, declared ref/features, host, fixture digest, exact command arguments, exit codes, timings, and output hashes
captures/ Bounded stdout and stderr for each command, including failure cases

Open the local HTML file in a browser or inspect the JSON in an editor. The HTML is self-contained; it does not add scripts, tracking, or external assets. The JSON and HTML runs have separate invocation records. Do not assume that independent executions share IDs, timings, or evidence.

See the genuine, version-labelled example reports for the tested binary, native platform, exact fixture/report hashes, and a guide to the actual observations. Downloadable platform archives are not evidence that each architecture was executed. A local isolated-directory run or hosted CI run is not a clean-machine certification.

Read the result accurately

The checked-in Windows alpha.1 sample completed the root assessment and contains four informational, observation-based items: four named response headers were not observed. Those are observations from the demonstration, not confirmed vulnerabilities.

Informational records an observation. NeedsReview asks a human to review evidence without confirming a vulnerability; the sample does not manufacture such an item. An action's Success outcome means that its objective was achieved, not that a vulnerability was confirmed.

A default scan is an operational path. An ordinary stop can be complete or halt with no_eligible_action; it is not an assessment findings report. A begun-but-incomplete assessment is different from a completed report with no items. The absence of reported observations does not mean “secure,” “clean,” or “not vulnerable.”

No optional review flags were supplied. Capabilities that the report does not name were not demonstrated by this fixture; the guide does not invent per-capability “passed” or “not vulnerable” statuses. This fixture cannot establish detection accuracy, exploitability, or comprehensive coverage. See the report contract and operational JSON contract.

What acceptance checks

The same runner checks the existing interfaces without modifying CLI behavior:

  • Actual version and documented help syntax.
  • The no-profile operational path and completed root JSON/HTML assessments.
  • Refusal to replace an existing report: its original bytes remain unchanged.
  • A separate preflight failure: nonzero exit and no success report or fixture I/O.
  • A begun local /example run that returns the existing incomplete diagnostic after fixture I/O, with no partial success report.
  • Bounded captures, report privacy, and cleanup of the runner's own resources.

Expected failing CLI cases are recorded individually; they do not mean the overall acceptance failed when their refusal/incomplete behavior matches the checks. An unexpected failure makes the runner exit nonzero. Inspect provenance.json and captures/ when they exist; early prerequisite failures may occur before an output directory is created. Do not reuse a prior output directory or treat an earlier successful report as the result of a failed run.

Raw provenance and diagnostics may contain local paths. Keep them local or review them before sharing. Published sample provenance replaces only the executable path fields listed in its normalization record with <LOCAL_BINARY>; report bytes, observations, counts, completion state, and errors are not rewritten. Raw captures are retained as local/CI evidence.

Further reading