attribution

func ChangedPaths ¶

func ChangedPaths(before, after map[string]string) (changed, deleted []string)

ChangedPaths diffs two working-tree signatures (repo-relative path → content hash) captured before and after a shell command, returning the paths the command created or modified (changed) and the paths it removed (deleted). Both slices are sorted for deterministic recording. Used to attribute files touched by agent-run shell commands, which never fire the file-writing tool hooks.

func ComputeLineRanges ¶

func ComputeLineRanges(before, after []byte) ([]aicodingsession.LineRange, bool)

ComputeLineRanges computes which line ranges in "after" are new or modified compared to "before". Returns 1-indexed, inclusive line ranges plus a `changed` flag that is true whenever before and after differ — including deletion-only changes where no "after" ranges exist. If before is nil, the entire file is considered new.

func Enrich ¶

func Enrich(sessionID string, aiFiles map[string][]aicodingsession.LineRange, changes *aicodingsession.CodeChanges)

Enrich adds AI/human attribution to code changes based on AI line range data. The sessionID identifies which session produced the changes, and aiFiles maps file paths to the line ranges modified by the AI in that session.

func FilterGenerated ¶

func FilterGenerated(changes *aicodingsession.CodeChanges, isGenerated func(path string) bool)

FilterGenerated removes files matched by isGenerated from changes.Files and subtracts their contributions from the aggregate line and file-count totals, so generated code does not skew downstream AI/human attribution. A nil isGenerated leaves changes untouched.

func ReverseApplyEdits ¶

func ReverseApplyEdits(after []byte, edits []trace.HookEdit) []byte

ReverseApplyEdits reconstructs the "before" content of a file given its "after" content and the sequence of old_string → new_string replacements that were applied to produce it. Edits are reversed in reverse order.

Best-effort and inherently ambiguous when new_string is not unique in the current content: bytes.Index always picks the first occurrence, which can be the wrong one if the same literal appears more than once. Cursor's afterFileEdit edits are typically context-rich enough that this rarely misfires in practice, and the worst-case outcome is a downstream line-range comparison reporting noisy ranges rather than a crash — but callers should treat the reconstructed bytes as a hint, not ground truth.

If an edit's new_string cannot be located in the current content (because a later edit overlapped it, or the file was touched externally), that edit is skipped. When the resulting "before" equals "after" we return nil so callers can fall back to other reconstruction strategies.