Source: PR #79 review (discovered while auditing the visible-survivor safety model; #53 covers aging/consolidation, not this).
recall prune deletes records with no awareness of dedup_lineage: pruning a record that is a recorded survivor orphans every duplicate marked under it — the duplicates stay hidden from search while their visible representative no longer exists. Same class as #63's visible-survivor decay, via a different door.
Also noted in the same review (non-blocking, fold in here): the semantic pass has an asymmetry — a recorded survivor never acquires NEW semantic duplicates after #79's stickiness (exact pass unaffected); the docs' visible-survivor prose should state both this and the prune interaction honestly.
Fix sketch: prune either refuses/warns on records appearing as survivors in active lineage (mirroring PR #79's destructive-mode guard), or re-points/unmarks their duplicates first. Sequence after #63/#73 — same design territory.
Source: PR #79 review (discovered while auditing the visible-survivor safety model; #53 covers aging/consolidation, not this).
recall prunedeletes records with no awareness ofdedup_lineage: pruning a record that is a recorded survivor orphans every duplicate marked under it — the duplicates stay hidden from search while their visible representative no longer exists. Same class as #63's visible-survivor decay, via a different door.Also noted in the same review (non-blocking, fold in here): the semantic pass has an asymmetry — a recorded survivor never acquires NEW semantic duplicates after #79's stickiness (exact pass unaffected); the docs' visible-survivor prose should state both this and the prune interaction honestly.
Fix sketch: prune either refuses/warns on records appearing as survivors in active lineage (mirroring PR #79's destructive-mode guard), or re-points/unmarks their duplicates first. Sequence after #63/#73 — same design territory.