feat(snippets): un-merge — reverse one source out of a merged survivor
CI & Build / Python lint (push) Successful in 3s
CI & Build / integration (push) Successful in 24s
CI & Build / TypeScript typecheck (push) Successful in 36s
CI & Build / Python tests (push) Successful in 54s
CI & Build / Build & push image (push) Successful in 40s

Closes the last of milestone #232. The task said to settle the design
before coding; here is what was settled and why.

THE HAZARD. Restoring a merged-in source from the trash brought the record
back but never stripped its locations off the survivor, so both claimed
the same call sites and the reverse lookup read the duplicate claims as
real. Subtracting blindly is not a fix: a location can arrive from a
source AND genuinely be the survivor's own, and _normalize_locations dedups
them into one, so blind subtraction would strip a call site the survivor
owns. Same problem defeated partial un-merge — `merged_from` recorded ids,
not which locations came from which source.

THE ANSWER. Record per-source attribution AT MERGE TIME, where it is known
exactly: each entry keeps only what that source ADDED, computed
incrementally as sources fold in. Anything the survivor already had, or an
earlier source already brought, is attributed to nobody. Both open
questions fall out of that one change — partial un-merge is exact, and a
survivor-owned location can never be stripped, because it was never
attributed in the first place.

The shape moved from [id] to [{id, locations, tags}]. Free to do: the
corpus holds one snippet and zero merges, so there is no legacy data (rule
#22). A bare int still normalizes to {"id": n} — not legacy tolerance, but
because snippet_fields falls back to PARSING THE BODY when a row has no
`data`, and the body's provenance line can only carry ids. Such an entry
shows history and refuses un-merge with a reason rather than guessing.

WHICH SURFACE. Neither option in the task, quite. Making trash-restore
notice the merge would teach the generic trash path snippet semantics for
one record type. Instead un-merge OWNS the restore: one operation, one
authorization check, trash stays ignorant. Restoring by hand is still
allowed and still leaves both records claiming the same places — so
un-merge treats an already-alive source as the normal case and goes
straight to the subtraction that repairs it. That is the state that
motivated the feature, not an error.

Adds trash.restore_entity(user_id, type, id) — the missing inverse of
delete(), which returns a batch id callers don't keep. Restores the whole
batch, since the batch is the entity plus its cascade.

Refs #2165

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UaYUaouG9jjhATyuxCKrQs
This commit is contained in:
2026-07-28 18:42:29 -04:00
co-authored by Claude Opus 5
parent 6db791965f
commit fe63f3985b
11 changed files with 624 additions and 30 deletions
+45
View File
@@ -190,6 +190,46 @@ async def get_snippet(snippet_id: int) -> dict:
return data
async def unmerge_snippet(survivor_id: int, source_id: int) -> dict:
"""Reverse ONE source out of a merged snippet — the inverse of merge_snippets.
Restores the source record and strips exactly what it contributed from the
survivor: the locations and tags it ADDED at merge time, never the ones the
survivor already had. Reach for it when a merge turns out to have unified two
things that only looked alike.
Also the fix for a half-undone merge. Restoring a merged-in source from the
trash by hand brings the record back but leaves the survivor still claiming
its call sites, so both records claim the same places and the reverse lookup
reads the duplicate claims as real. Running this on an already-restored
source repairs that: it skips the restore and does the subtraction.
Args:
survivor_id: The snippet that absorbed the other.
source_id: The snippet to pull back out of it.
Returns {"survivor": {...}, "restored": {...}}.
Refuses, with the reason, when: the survivor has no record of absorbing that
id; the source was purged from the trash; or the merge predates per-source
provenance, in which case what it contributed isn't known and subtracting a
guess could strip call sites the survivor genuinely owns — restore it from
the trash and adjust both records by hand instead.
"""
uid = current_user_id()
try:
result = await snippets_svc.unmerge_snippet(uid, survivor_id, source_id)
except snippets_svc.UnmergeError as exc:
raise ValueError(str(exc)) from exc
if result is None:
raise ValueError(f"snippet {survivor_id} not found")
survivor, restored = result
return {
"survivor": snippets_svc.snippet_to_dict(survivor),
"restored": snippets_svc.snippet_to_dict(restored) if restored else None,
}
async def find_duplicate_snippets(threshold: float = 0.0) -> dict:
"""Find snippets already recorded that look like duplicates of each other.
@@ -376,6 +416,10 @@ async def merge_snippets(target_id: int, source_ids: list[int]) -> dict:
fields and as a "Merged from: #ids" line in the body), so a variant that got
folded in leaves a trace outside the trash. It accumulates across merges.
Reversible: each entry also records what that source contributed, so
`unmerge_snippet(target_id, source_id)` can restore it and strip exactly
those locations back off — never the ones the target already had.
Args:
target_id: The snippet to keep (the canonical record).
source_ids: Snippet ids to fold into the target and retire. Ids that
@@ -404,5 +448,6 @@ def register(mcp) -> None:
for fn in (
list_snippets, create_snippet, get_snippet, update_snippet,
delete_snippet, merge_snippets, verify_snippet, find_duplicate_snippets,
unmerge_snippet,
):
mcp.tool(name=fn.__name__)(fn)