evidence-put¶
Provenance¶
- Source:
.spec/spexcode/spec-eval/evidence-put/spec.md - Source SHA-256:
c5b35ad02b6c62505f50d4fde331a4c1b9413cc2b7dbd0dbbe3badfbd765ea32
Evidence has two halves — the bytes (a clip, a screenshot, a transcript, content-addressed in the
shared cache) and the record that cites them (an eval reading's evidence[], an issue thread's typed
hashes). Until this verb the only door into the cache was spex eval add --video/--image, which welds
the two: you could not cache a clip without also filing a reading. spex evidence put <file|-> is the bare
transport half — put the bytes ([[eval-core]]'s putBlob, the same cache every surface reads via
/api/evidence), print the 64-hex content hash, file nothing. The hash is then citable anywhere a bare
hash is accepted: an issue reply's --evidence, a  body link the thread
renders ([[issues-view]]), a later reading. Its symmetric read twin is [[evidence-get]] — hash back to bytes.
Because putBlob is idempotent by content, the same command is also the repair verb for a checkout
whose cache lacks a blob some thread already references by hash (a fresh clone 404s on inherited
evidence): re-put the original file and the hash — being content-derived — lands exactly where the
references point. That idempotence is also why the cache dir rename (.git/spexcode/yatsu-blobs →
.git/spexcode/evidence, v0.3.0) shipped with no data migration: the dir is a per-clone cache, and a
missing blob re-fills by re-putting or streams from the backend on a get miss. No flags, no kind
argument — the kind is sniffed from the bytes at serve time ([[video-evidence]]), so the verb stays one
line and the data model grows nothing.