mirror of
https://tangled.org/evan.jarrett.net/at-container-registry
synced 2026-09-02 08:16:57 +00:00
264d332fixed the behaviour but encoded it badly. manifestBelongsToHold returned (true, false) for an unreachable hold — "yes, but not really" — a return value that contradicts itself, and isPredecessorHold both applied the fail-open policy and handed back the raw material for that policy. The behaviour was right and the shape was wrong. The underlying problem is that ownership has three states and the return type had two: ours - this hold's manifest, or a confirmed predecessor's not ours - the hold answered, and it is someone else's unknown - the hold did not answer; don't delete, but do not adopt For the first two, "is it ours" and "should its blobs stay referenced" have the same answer, so one bool worked and the design was never stressed. They diverge only on unknown. Every version so far has had to collapse unknown onto one of the other two: before95d4f7conto "not ours", which deleted a live predecessor's blobs, and after it onto "ours", which adopted foreign manifests and put ten phantom missing layer records on hold01. Same shape error, opposite sides. That conflation is original, not something95d4f7cintroduced: manifestBelongsToHold has fed knownManifests since the function was written. So name the state. manifestClaim has three values, classifyManifest and classifyPredecessorHold report what they found and apply no policy, and the one decision that matters — an unknown claim is carried for blob protection but never adopted — now sits in the open at the call site instead of two functions deep, which is how it leaked into ownership to begin with. No behaviour change from 264d332; the three outcomes and the blob protection are identical. The regression test was re-verified against this shape: it fails, reporting the adoption, when claimUnknown is allowed to adopt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KWoKzpgtBJ33sCyGxJGR7x