Opening the store rewrites every `conflicts_with` edge to `overlaps` (data loss; can brick the store)

[jiang4wqy]

Problem

init_schema() runs on every Store.open() and unconditionally executes:

UPDATE edges SET type='overlaps' WHERE type='conflicts_with'

But conflicts_with is a current edge type — written by the edge-judge subagent to mean "genuinely incompatible", and read by graphview and recall. It is not a legacy alias, so this runs on every command and silently rewrites live data.

It can also brick the store: edges has UNIQUE(src, dst, type), and a baseline overlaps edge plus its upgraded conflicts_with for the same pair coexist by design (that is the edge-judge flow). When both rows exist, the UPDATE collides with the unique constraint and raises IntegrityError — after which every command that opens the store fails.

Reproduction

From a fresh repo (edges --add conflicts_with is the manual equivalent of what the edge-judge writes):

rgit init
rgit edges --add conflicts_with capA capB
rgit features          # edge is now ('capA','capB','overlaps') — conflicts_with lost

rgit edges --add overlaps capA capB
rgit edges --add conflicts_with capA capB
rgit features          # sqlite3.IntegrityError: UNIQUE constraint failed — store bricked

Fix

Delete the UPDATE in init_schema (src/rgit/store/db.py) — conflicts_with is a supported type and should not be migrated away. If a genuine one-time migration for old databases is still wanted, guard it with PRAGMA user_version (run once) and make it collision-safe.

[Lum1104]

This was fixed by #5 (merged): the unconditional UPDATE edges SET type='overlaps' WHERE type='conflicts_with' was removed from init_schema in src/rgit/store/db.py, so opening the store no longer rewrites (or collides on) live conflicts_with edges. Current main no longer contains that statement. Closing as resolved — thanks for the precise reproduction.