Verifying what came home

Verifying what came home, before anyone gates it

Verification is deterministic and uses no model at all.

saphan verify-stream <stream>

It runs, in the stream's local worktree and in a fixed order: go build, go vet, the module-wide go test, then gofmt. Every stage runs even after an earlier failure, so the first red cannot mask a later independent one. ⚠ It is built for Go modules: a worktree with no go.mod is refused (not-a-go-worktree), and a missing go, gofmt or git is refused before anything runs.

What the verdict holds you to:

• A test run that executed zero tests is red, not green; a module with no test files gets its own status, no-test-files.
• The format check scores only files this stream changed since its recorded base; anything else it finds is reported as inherited and never scored.
• A dirty worktree never certifies green — it reads green-dirty, because "green" is a claim about a commit.
• A step that did not finish is not a failure: it records timeout, killed or unrunnable. Each step has its own wall clock, ten minutes unless verify.full.timeout says otherwise.

The verdict is recorded. saphan verify-stream <stream> --status reads it back later and exits non-zero unless it is fresh and actually green — a moved HEAD or a changed tree reads as stale.

The neighbour, for a different question:

• saphan verify-union <stream> — the full-suite measurement of the branch merged onto its trunk in a detached tree. ⚠ It is advisory. The merge reads the latest union verdict for the exact branch-and-trunk pair it is landing and records it beside the merge, but it does not refuse on it — a pair whose union was never measured still lands. It answers "would the combination be healthy", which is a question worth asking and is not the question the merge asks.

"Green" carries three things — name all three

A bare "green" is not a measurement. When you report one, report:

• the set — the whole module, or the packages you actually ran. A filtered run prints a pass for a package where the filter matched zero tests, and that pass is indistinguishable from a real one.
• the reference — which commit, and which trunk you measured against. The table in Delivering a branch decides which trunk that is.
• the confinement — sandboxed or not. The same tree at the same commit can read zero failures unconfined and a handful inside a sandbox, and neither reading lies: they are answers to different questions. A remote agent reporting failures and a coordinator reporting none can both be right, and the disagreement is only readable because both said where they stood.

⛔ Never fold a pre-existing failure into your own count without measuring it on the base commit. If you did not re-measure it there, the honest word is "unverified as pre-existing", not "clean".