Someday/maybe. Found while testing Basic Memory Cloud readiness on development (2026-10-01). The user-visible symptom, empty search reported as "never indexed", is fixed separately by the readiness "ever indexed" rule.

Problem

On cloud, entity.checksum holds two different checksums, depending on which path wrote it last:

Both meanings are needed:

• Content SHA-256: accepted-write CAS, live-update and provenance matching (storage_object_checksum_for_index_match compares bm-file-checksum with the indexed checksum), guarded deletes.
• Storage ETag: cheap change detection from a listing (full index runs, project status).

Effects

• Cloud project status (GET /v2/projects/{id}/status) compares listing ETags with entity.checksum, so notes indexed through the write or webhook path count as pending forever. Readiness on cloud never reaches idle.
• Every webhook index and full pass re-downloads and re-hashes such notes, because the comparison never matches.

Proposed fix

Add nullable entity.storage_checksum, the checksum storage reports (S3 ETag on cloud, the SHA-256 locally), and keep entity.checksum as the content SHA-256 everywhere.

• Writers:
  • materialization, from the upload response;
  • single-file indexing, from the GET that returned the bytes;
  • full index, from the listing.
• Readers: full-index change detection and readiness compare listing against storage_checksum. NULL means unknown: fall back to today's behavior, and count as indexed in readiness.
• Fills itself as notes are touched; no reindex needed. Optional cheap backfill:
  • copy rows where checksum already equals the listing ETag;
  • otherwise use one HEAD request for bm-file-checksum, and if it equals checksum, take the ETag.

A partial start, adding storage_checksum to RuntimeWrittenFileState and recording it on materialization, was drafted and set aside. It is not in any branch.