Skip to content

The scout ecosystem

What exists, what each piece is for, and what is only planned. Nothing on this page is aspirational unless it says so: a map that lists things which do not exist is worse than no map, because it costs a reader the trip.

Today: one repository, three surfaces, one engine

scout is a single repository. Everything below ships from it.

Surface Entry point What it is
CLI scout check The diagnostic as a command. Text, JSON, NDJSON, Markdown or HTML.
TUI scout tui The same run, driven interactively, for picking a tool and watching a phase.
Web scout serve The same run in a browser, on the operator's own machine.

The three are not three implementations. internal/engine owns a run: RunSpec carries the intent, Run executes it, a Sink receives events. Each surface builds a spec and presents the events.

That is enforced rather than intended. cmd/parity_test.go fails the build when a flag configures a run but carries no RunSpec field, because a capability reachable only through a flag is one the TUI and the web UI can never have. See ADR 0005 for how the hosted surface inherits the same guarantee.

Published artefacts

Every release produces the same set, from one tag.

Artefact Where Provenance
Binaries GitHub Releases SHA256SUMS, keyless cosign signature, SLSA provenance
Container image ghcr.io/sebastienrousseau/scout Multi-arch, cosign-signed, digest-addressable
SBOM Attached to each release CycloneDX, generated by Syft
Packages deb, rpm, AUR, Homebrew cask, Nix Built from the release archives — see pkg/

Verification instructions, including the cosign certificate identity, are in pkg/VERIFY.md. There is no KEYS.asc: signing is keyless, so there is no long-lived key to publish, and the thing to check is the workflow identity in the certificate rather than a key fingerprint.

Planned

These do not exist yet. They are recorded here so the layout cannot drift silently once they do, and so nobody goes looking for them.

Repository Status What it would own
scout-mcp Designed, not created scoutmcp.io — the public site and the hosted diagnostic. Deploys the published container image by digest; contains no Go source, so it cannot drift from the tool.
scout-action Proposed A GitHub Action wrapping the published image. scout check --output sarif already writes what code scanning reads, so what is left is packaging, not capability.

scout-lsp and scout-wasm have been considered and deliberately deferred. A browser build is a target rather than a repository, and is blocked against most servers by CORS; a language server is a large permanent surface with no demand behind it yet. Most of that value was scout check emitting SARIF, which it now does, plus scout-action.

The version rule

Every repository in the ecosystem always carries the same version.

This is a hard rule, not a convention, and it exists because ambiguity about which build of the tool is behind a hosted service is the expensive kind of ambiguity for a security diagnostic.

  1. One source. scout's tag is the only place a version is authored. Satellites never choose their own.
  2. Propagation is automatic. A release fires repository_dispatch at each satellite, which writes the version, pins the image by digest, tags itself and deploys.
  3. Drift is a red check. Each satellite carries a required Version Lockstep status check comparing its version to the latest published scout release. Disagreement blocks the merge.

The cost is real and accepted: a typo on the site cannot ship as a site-only patch. It bumps the whole ecosystem, including a scout release in which nothing changed. A no-op release is cheap and automated; not knowing what is deployed is not.

Rule 2 and rule 3 take effect when the first satellite exists. Rule 1 is in force now.

Where to go next