[nilsmechtel]

A soup member's bytes were never checked against the digest the pool recorded
for them. pool_index.json stores a weights_sha256 per contribution — the only
field that says which weights a contribution was — and no read path compared it
to anything. The replica souped whatever bytes the presigned URL returned, and the
community manifest published afterwards asserted a digest over members whose own
provenance had never been confirmed.

Backlog #139. Found via the round-2 model-soup campaign (aged-mink-nvaylz).

What changed

pool.member_digest_refusal(key, expected_sha256, content) returns a reason
string — so the caller owns the exception type, as soup_admission does — and is
wired into CellposeRuntime._fetch_member, the single download point for every
soup member, shared by score_soup and materialize_soup via _build_soup.

• The check runs before the cache write, so a member that does not hash to
  what the pool recorded never reaches the cache and cannot be served to a later
  merge as if it had been verified.
• A cache hit is trusted on the strength of the check that admitted it. Sound
  only because the cache key is the immutable pool weights_path and the file is
  written via a temporary name, so a cached entry can only be bytes this method
  already verified. Noted in the docstring.
• entry.py passes the expected digest down via a weights_path → weights_sha256
  map built off the index, attached as sha256 on each member spec.
• Both lookups are bare subscripts, matching the existing idiom at
  entry.py:1828. An index row without a digest raises here rather than degrading
  into an unverified soup, and member_digest_refusal takes a required digest with
  no falsy-skip path — the one failure this exists to prevent must not be reachable
  as a silent no-op.

A premise was refuted mid-implementation, and the first commit is the record

The first commit on this branch also excluded contributions with no recorded
digest, on the strength of a report that 8 of 92 campaign deposit rows carried
none. The reporter then re-probed the live pools and refuted their own finding:
all 8 carry a digest in the stored pool_index.json, on all three affected pools,
8/8 exact against independently derived values. The absence was only ever in the
client-side deposit journal, never in the index the merge reads.

Measured here to rule out a legacy window as well:

append_contribution introduced by	eb1f748 — the commit that created the pool backend, so no pool predates it
its index stub at that commit	already carried weights_sha256 (line 1300)
the later 6eec958 hit	the expression changing to info["weights_sha256"], not the field being added
every path reaching _specs	by_id[cid]["weights_path"] or cand_path[cid] — both built off index["contributions"]

So every soup member is a pool contribution and every pool contribution has a
digest. The second commit removes the filter, the unverified record key and the
decided-marking it required. A branch for an unreachable state is untested in
production forever and makes the reachable path harder to read.

The net diff is 87 insertions, 4 deletions across four files.

Cost — measured, not assumed

These are 1.2 GiB checkpoints and the hash is over the whole file.

sha256 over 1.2 GiB on europa	2.56 s (0.47 GiB/s)
frequency	once per member per replica — a cache hit skips it
allocation	none; hashlib.sha256(content) does not copy the buffer, so #87's three-member-equivalents invariant (pool.py:214-218) is unchanged

Not per scoring pass. A merge is 2*len(batch)+3 passes and only the first use of
a member downloads.

Verification

Run in ghcr.io/aicell-lab/bioengine-worker:0.16.58-dev1 with pytest and
pytest-asyncio installed. Without the plugin, 6 @pytest.mark.asyncio cases
report as failures unrun — in both arms, so the count is unreadable otherwise.

arm	result
full app suite, this branch	77 passed, 2 skipped
full app suite, origin/main	73 passed, 2 skipped

+4 exactly, zero failures, identical skips (a pre-existing corpus fixture gated on
MODEL_FINETUNE_CORPUS_DIR, and test_soup_math.py needing torch).

Two mutation controls, each with the marker's uniqueness asserted (count 1) before
the edit:

mutation	result
member_digest_refusal → return None first	3 failed — exactly the three refusal assertions
got == expected → got.startswith(expected)	1 failed — exactly the prefix control, nothing else

The second control is the one worth noting: it proves
test_the_whole_digest_is_compared_and_not_a_prefix catches something no other
test here does. test_matching_bytes_are_accepted stayed green under the first
mutation, which is what makes it a control against a guard that just refuses
everything.

Honest coverage gap

Only the pure pool.py helper is unit-tested. The wiring — _fetch_member's
call, the before-cache ordering, and the sha256 attachment in _specs — is
not covered by any test, because aggregate needs a live Hypha artifact and a
GPU runtime. It was read and reasoned about, not executed. A reviewer should treat
it as unverified by CI.

Not in this PR

No version bump yet, deliberately. apps/model-finetune is gated by
app-version-check.yml, which requires the version to be already published
before gh pr ready, so bumping reserves a published version — and reserving out
of order is what collided PR #257 with PR #249. Five other apps/model-finetune
PRs are open (#237, #239, #255, #256, #260) and backlog #127 is paused on the
landing order. Nothing has been uploaded or deployed: a paper campaign is live on
the production instance.

Out of scope: any writer change (already correct), get_pool_state's projection
dropping the digest it has in hand (filed separately), making schema_version
track semantics (#122/#114), and what the merge gate decides on (#121 owns
the scoring decomposition). This adds a provenance check to the load path; it does
not change the ranking.

🤖 Generated with Claude Code