Bug: total_additions reset to 0 for inherited prompts without checkpoint data

[peckfly]

Bug Description

When a commit involves multiple AI agent sessions (e.g., Cursor + Codex), prompts inherited from the INITIAL state that have no new checkpoint data in the current working session get their total_additions reset to 0. This causes the reported total_ai_additions to be less than ai_accepted (or ai_additions), which is logically impossible since total_ai_additions represents all AI-generated lines throughout a session, while ai_accepted represents the subset that survived into the final commit.

Steps to Reproduce

1. Start a coding session with Agent A (e.g., Cursor) — Agent A generates some code, creating checkpoint data with line_stats.additions > 0
2. Switch to Agent B (e.g., Codex) — Agent B generates additional code in a separate session, also creating checkpoint data
3. Commit the changes — both agents' contributions are present in the final commit

Expected: Both agents have total_additions > 0 reflecting their checkpoint line_stats
Actual: Agent B's prompt (inherited from INITIAL) has total_additions = 0 because no new checkpoints exist for Agent B's session ID in the current working log

Root Cause

In VirtualAttributions::calculate_and_update_prompt_metrics() (src/authorship/virtual_attribution.rs), the code unconditionally overwrites total_additions / total_deletions from the session_additions / session_deletions maps:

// Current behavior (buggy):
prompt_record.total_additions = session_additions.get(session_id).copied().unwrap_or(0);
prompt_record.total_deletions = session_deletions.get(session_id).copied().unwrap_or(0);

When a prompt is inherited from INITIAL attributions (e.g., from a previous agent session), its PromptRecord already carries the correct total_additions value. However, if no new checkpoints exist for that session in the current working log, session_additions won't contain the session ID, and unwrap_or(0) resets the value to 0.

This affects all code paths that call calculate_and_update_prompt_metrics:

• from_just_working_log()
• from_working_log_snapshot()
• from_persisted_working_log()

Proposed Fix

Only overwrite total_additions / total_deletions when checkpoint data actually exists for the session:

// Fixed behavior:
if let Some(&additions) = session_additions.get(session_id) {
    prompt_record.total_additions = additions;
}
if let Some(&deletions) = session_deletions.get(session_id) {
    prompt_record.total_deletions = deletions;
}

This preserves the existing total_additions value for prompts inherited from INITIAL that have no new checkpoint activity, while still correctly updating prompts that do have checkpoint data.

Impact

• Metric accuracy: total_ai_additions (used for "AI generated lines" reporting) is under-reported
• Acceptance rate: When total_ai_additions < ai_accepted, the acceptance rate exceeds 100%, which is logically impossible
• Scope: Affects any commit where multiple AI agent sessions contribute code and at least one session's prompt is inherited from INITIAL without new checkpoints

Environment

• Affected agents: any multi-agent workflow (e.g., Cursor + Codex)
  @svarlamov

[svarlamov]

@peckfly Hey, sorry about the noise on this thread. I misinterpreted this issue and actually ended up having to revert #1081.

The reported behavior is not a bug. It's an artifact of the per-note stats. The total_additions and total_deletions represent the totals from work that happened in the given commit. If the code was generated prior to the last commit, those counts already went towards the last commit's note, so they should NOT be carried forward.

Since there is no way to split the totals based on what was actually committed, so there's no possible mitigation that wouldn't corrupt data. If you want to know how many lines were added/deleted in total by a given prompt id, you must find all the notes for that prompt id. Reverting #1081 will also close #1098 and the associated PR.