When a Function Moves, Its History Should Not Be Guessed
Why semantic lineage needs ambiguous and unresolved outcomes.
Scope: Archive capabilities are website-described; semantic context and later roadmap capabilities are in development or planned. No delivery date is promised.
A function disappears from one file and a similar function appears in another. Did it move, get rewritten, split into two responsibilities, or merely share a common pattern with something new?
KodeAtlas’s next-phase lineage design treats those as different possibilities. Its intended vocabulary includes moves, renames, extractions, splits, merges, deletions, and unresolved or ambiguous relationships. That vocabulary is a development direction, not a claim that the current archive CLI already resolves semantic identity.
A name is evidence, not identity
In a synthetic refactor, a function named loadData might be renamed and moved while retaining its behavior. Another function might keep the name but take on a different responsibility.
A name-only index would struggle with both cases. A line-number anchor would also become fragile when imports or neighboring declarations change. Useful lineage needs to consider the code and its relationships, while admitting that the evidence may still be insufficient.
The purpose is not to produce a confident arrow between every pair of revisions. It is to preserve the distinction between a supported connection and an attractive guess.
Splits and merges resist a single answer
An extraction can leave part of a responsibility in the original function and move another part into a helper. A later merge can combine behavior from several places. Historical discussion may apply to only one part of the new implementation.
Treating either operation as a simple rename risks attaching the wrong rationale, regression history, or backlog item to the new symbol. A lineage model should represent that complexity rather than flattening it for a cleaner visualization.
Ambiguity should reach the reader
A future context packet that relies on a lineage relationship should make the relationship and its uncertainty visible. An engineer may then inspect the associated change or supply additional evidence.
That is more useful than silently borrowing a predecessor’s entire history because two functions look similar. It also creates a clearer boundary for automation: a system can offer a candidate relationship without authorizing a downstream conclusion.
KodeAtlas’s roadmap places semantic context and lineage after the archive foundation. The archive preserves the history needed to investigate these questions. The next layer must earn the right to explain that history, one supported relationship at a time.