The durable service's documents join the version contract. A set's result
(wai.quantum.set/1) and a result's provenance (wai.quantum.provenance/1) are
engine schemas; the service's receipt key set (wai.quantum.receipt-keys/1,
with its signed transitions) and the command line's scheduler lease
(wai.quantum.lease/1) are their hosts'. The job request names programs, sweep
and dry_run, a job's result may be a set's, an energy figure may be the
processor packages', and a job names its store digests.
A set's head now names the engine and its schema, inside what its receipt
seals, as every other result does. A result's provenance names the gate set
its compile wrote as basis (it read the compile summary's old target field,
which the rename left empty).
run_quantum_set and dry_run_quantum_job answer to output schemas, each with
its verdict whether refused or not, and run_quantum_circuit asked as a dry
run answers as one. The strict tests call both and hold every answer, the
job's set form and the key set after a rotation to their schemas; the
contract workflow requires the new tests by name, and check_schemas.py reads
the new files and holds a set's run to its schema.
The service's store stays at ~/.local/share/wai-quantum-service/store by
default; the Python check and its tests start the service with a store in
their own scratch, as the service workflow's legs already do.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
a4dee88425