bug(cli): projects prune reports all candidates as pruned while printing FOREIGN KEY errors for three of them

[AlejandroTatum]

Summary

engram projects prune reports a success count that includes projects it failed to prune. In the same output it prints three FOREIGN KEY constraint failed errors and then claims all nine projects were pruned. Six were.

The underlying data stayed consistent — no observations were lost and PRAGMA integrity_check / PRAGMA foreign_key_check are clean — so this is a reporting defect, not corruption. But the summary line is the only thing a caller sees, and it asserts an outcome that did not happen.

Steps to Reproduce

1. Have a store with several zero-observation projects, at least one of which has sessions referenced by another table.
2. Run engram projects prune.
3. Answer all at the selection prompt.

Actual Behavior

Error pruning "<project-a>": prune sessions: constraint failed: FOREIGN KEY constraint failed (787)
Error pruning "<project-b>": prune sessions: constraint failed: FOREIGN KEY constraint failed (787)
Error pruning "<project-c>": prune sessions: constraint failed: FOREIGN KEY constraint failed (787)

Pruned 9 project(s): 1911 sessions, 489 prompts removed.

Nine were listed, three errored, and the summary says nine were pruned.

Verified against the store before and after:

	before	after	delta
sessions	3,626	1,715	−1,911
user_prompts	7,253	6,764	−489
observations	6,549	6,549	0

The session and prompt deltas match the summary exactly, so those two numbers are truthful. The project count is not — the three failed projects still exist, each still holding one session:

<project-a>: 1 session
<project-b>: 1 session
<project-c>: 1 session

Store integrity after the run:

PRAGMA foreign_key_check  → 0 rows
PRAGMA integrity_check    → ok

Expected Behavior

Either of these would be correct; the first seems closer to the intent of the command:

• Report only what succeeded: Pruned 6 project(s), 3 failed: 1911 sessions, 489 prompts removed, with a non-zero exit code.
• Or treat the batch as atomic and roll back on any failure.

What should not happen is a count that sums attempts while errors for the failures are printed directly above it. A caller scripting around this command, or a user skimming the last line, would conclude the store is clean when three projects remain.

Note on the constraint itself

The failures look legitimate — those sessions are referenced elsewhere, so the delete is correctly refused. The defect here is only that the refusal is not reflected in the summary. Whether zero-observation projects whose sessions are still referenced should be prunable at all is a separate design question, and if the answer is no, listing them as prune candidates in the first place is arguably the earlier bug.

Environment

• engram v1.20.0+patch.busytimeout
• Linux x86_64, Arch
• SQLite store in WAL mode, ~6.5k observations across 39 projects at the time of the run

[atirna]

Confirmed the root cause. The summary line counts the number of selected candidates, not the number that actually pruned:

fmt.Printf("\nPruned %d project(s): %d sessions, %d prompts removed.\n", len(selected), totalSessions, totalPrompts)

selected is built up before the loop, and the error path just continues, so projects that fail the FK check still count toward len(selected). The session and prompt totals are only incremented on success, which is why those two match your deltas while the project count doesn't.

I'd go with your first option: count successes separately, print the failed count too, and exit non-zero when any fail. i can put up a PR with that scope if that's fine.

[dnlrsls]

Closing as resolved on main by commit aac45b0310f4. Project pruning now counts only successful projects, covered by TestCmdProjectsPruneReportsOnlySuccessfulProjects. Thanks for catching the misleading summary.