Saphan StudioDocs
Working with git

Verifying what came home

What to measure before anyone gates it — including the branch merged onto its trunk — and the three things a green result has to name.

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: build, vet, the module-wide test run, then the format check. Every stage runs even after an earlier failure, so the first red cannot mask a later independent one.

Two neighbours, for two different questions:

  • saphan verify <ref|path> — state-neutral and worktree-bound; it asks about a tree, not about a stream's standing.
  • saphan verify-union <stream> — the full-suite measurement of the branch merged onto its trunk in a detached tree. ⚠ It is advisory. It gates nothing, and the merge never reads its record. 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. Section 2's table decides which trunk that is.
  • the confinement — sandboxed or not. The same tree at the same commit can read zero failures unconfined and about nineteen inside a sandbox, and neither reading lies: they are answers to different questions. A remote agent reporting nineteen and a coordinator reporting zero are both 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".

On this page