abstraction: format 2.0, source.digests

format 2.0, source.digest covers every markup file, the sha256 over one
line per markup file, "<sha256> <filename>", sorted by filename.

source.digest was the sha256 of the master file as read, before any
insert. This is right for a .sst, which is the whole document. For a
.ssm with inserts .ssi (containing the substantive part of a documents
text) this is close to meaningless.

Considered change of meaning (rather than an addition) and given the
major part of the format version with it: 1.1 becomes 2.0, in the .ssp
header line and in the database's schema.version row together.
A 1.x reader refuses a 2.0 artefact, which is what that check is for.

- Sorted, so the value does not depend on the order a filesystem hands
  back a directory.
- By filename (rather than by path), so it does not depend on where the
  pod sits, which is the property the pod rebuild comparison rests on:
  a pod unzipped elsewhere must still give the same abstraction.
  Within one language every markup file lives in one directory, so a
  filename identifies it.

Each line is checkable on its own against a digests.txt line or a files
row, which the single value was not. The whole is reproducible with
sha256sum and sort, and was verified that way for a one file document
and for a twenty file one.

An unreadable file is named in the digest rather than skipped. The parse
has failed elsewhere by then, and a digest that quietly left a file out
would claim the document is something it is not.

The reference abstractions are regenerated. Two lines change in each and
no others: the version, and the digest.

(assisted by Claude-Code)

0 files changed, 0 insertions, 0 deletions