[SimonHeybrock]

Stacked on #193 (base branch 184-spec-digest), which is stacked on #192. Merge #192, then #193, then this, or this PR lands in its base branch and not in main.

Second part of ADR 0009: a workspace's log stores the digest of each spec, and a record whose spec is not the one bound now stays readable as stored data.

The problem. A folder outlives the technique package that wrote it. Before this change, an outputs class changed under the same version was filled from the stored data without an error, and an output of a spec with no binding could not be read at all:

# iofq/v1 wrote Centre(x=0.5, y=0.25); the package now has, still under v1:
class Centre(BaseModel):
    x_mm: float = 0.0   # renamed from x
    y: float

client.output(old_record, 'centre')
# before: Centre(x_mm=0.0, y=0.25), no error
# now:    DataGroup({'x': 0.5, 'y': 0.25})

The rule. Every submission carries the digest of each spec it names that the log does not hold yet, or holds with another digest. A record is of the bound spec if the workspace has a binding with the same name, version, and digest. Otherwise it is of another spec: the version was bumped, the models changed, or no binding is given.

Of a record of another spec	What a client gets
its request	name, version, and the params as the stored dict
output, describe, select=	the stored scipp data: a DataArray, or a DataGroup
readable, records, latest, provenance, the change feed	as for any record
a new request that references its output	SubmitError at the reference's position
a restart while it is pending and would run	it fails with a reason that says its spec is not bound, and so does a pending record that reads an output of it

Store.read(record, output, None) reads a value as stored; its docstring defines that form, so that another store knows what to return. The log format is 3; a format 2 log is refused and left as it was.

For Simon to decide: Client.bound(records) -> list[bool]. A new public call, shaped like readable. I had said I would propose it before adding it, and added it since a fix needed it: Listing raised KeyError for a folder in which a top-level output was renamed under the same version, so the batch web server, the batch Panel view, and the sheet could not open such a folder. Listing now holds a spec only for records of the bound spec. For any other record it shows the spec's name and version, labels outputs by name, offers no configured plot, and does not offer the outputs for reference in a form. The call is in its own commit (the last one) with the views' use of it. An alternative is a digest field on Record, which exposes a detail of the log.

How a batch row shows, until #191 decides what a batch is:

The record's spec	Row
another version than the one bound	not reduced
the same version with changed models	completed; export writes the stored data

A batch does not yet show the second kind as no longer current.

Known wart. For a record of another spec, the Panel outputs view decides from the described fields whether an output is a group, since no class says so. A stored group with one field named like its output would be shown as an array.

Removed during the work. ADR 0009 briefly said that a request made with a spec object whose digest differs from the bound one's is refused. Only client.submit(spec, ...) holds the spec object; Request(spec) and Template(spec) keep only name and version. A rule that holds on one path was dropped, with the sentence.

Review. A fresh reviewer wrote folders with one set of bindings and opened them with another. It found the Listing crash above, a crash of the Panel plot on a group read as stored, and the as-stored form of numbers and lists misstated; all fixed here, with tests. It found no path that still builds a changed class from stored data (freezes, stages, export, restart chains, a digest that changes and changes back). Four mutations, such as treating a changed digest as bound, each fail tests.

🤖 Generated with Claude Code

[SimonHeybrock]

LGTM