Skip to main content

Module seal

Module seal 

Source
Expand description

Making the gate unforgeable.

crate::Acceptance asks whether the work is really done. It is worth nothing if the agent can edit the thing doing the asking — and that is not a hypothetical: the reliably-observed failure is a model that cannot make a test pass loosening the test until it does, then reporting success. The run ends green, the gate was consulted, and it agreed, because by then it was a different gate.

So a check may declare the files that define it — Acceptance::seals. Those are digested before the model gets its first turn and re-digested before any pass is accepted. A difference means the contract moved during the run, and the run fails on that ground alone, whatever the checks said.

What this enforces, precisely. It detects that a sealed file’s bytes changed between the start of the run and the verdict. That is the whole claim. It does not stop the write — the filesystem sandbox is what does that, and sealing is the check for hosts that do not have one, or for paths outside it. It also cannot see a file the check reads but did not declare; seals() is a promise the check makes about itself, and a check that lies about its inputs is not sealed no matter what this module does.

Sealing is opt-in and empty by default, because some runs are supposed to rewrite the tests. Seal what must not move.

Structs§

SealBreach
One file that moved while the run was in flight.
SealSet
The digests of every sealed path, taken together.

Type Aliases§

Digest64
A sealed file’s state at a point in time.