fix(cli): close #283 bug 4 — tighten consolidate grouping + prune path-named projects#445
Conversation
… grouping + prune path-named projects Bug 4 from issue Gentleman-Programming#283 has two halves, both addressed here. Grouping (data-loss footgun): groupSimilarProjects unioned every project that shared ANY directory. A noisy ancestor (e.g. $HOME or a session root) listed under dozens of projects collapsed the whole store into one component, so `projects consolidate --all` proposed merging unrelated projects into a single bucket. Now skip any directory shared by more than maxSharedProjectsForDirMatch (3) distinct projects; genuine rename signals (a directory shared by a few projects) still group. Cleanup of pre-existing garbage: add `--paths-only` to `projects prune`, restricting the 0-observation candidate set to projects whose name is a filesystem path. Mirrors the write-boundary rejection in normalizeExplicitWriteProject (ContainsAny(name, "/\\")), so cleanup targets exactly the names newer versions already refuse to create. Reuses the existing prune machinery (dry-run, interactive selection, cascade delete). Regression coverage (unit + command-level): noisy shared dir not grouped; small shared dir still groups; name similarity untouched; path-like detector table; `consolidate --all` proposes no merge for noisy-shared-dir projects; `prune --paths-only` lists and deletes only path-named empty projects.
4f3a806 to
053923f
Compare
|
This is linked to the approved #283 scope and looks focused on the remaining consolidate/prune bug. I added the |
|
This PR has been inactive for 30 days. Please rebase, update it, or leave a comment — otherwise it will be closed in 14 days. |
Alan-TheGentleman
left a comment
Alan-TheGentleman
left a comment
There was a problem hiding this comment.
Reopening attention on this — the status:stale label is process drift, not code decay: groupSimilarProjects and cmdProjectsPrune are unchanged on main and the branch is still mergeable.
Your diagnosis is better than the issue's. #283 blamed a loose name-similarity threshold, but the actual collapse is the shared-directory union at cmd/engram/main.go:1946-1950, which unions every project sharing any directory — so one $HOME entry transitively merges the whole store. That matches Group 2 in the report containing <user-home> plus the path-named entries. Skipping directories touched by >3 distinct projects is the right lever, and leaving project.FindSimilar untouched is the right call.
One question before merge:
- The
--paths-onlyprune flag is #283 bug 2 cleanup, not bug 4. Would you split it into its own PR? It reuses existing prune machinery so it's low-risk, but this PR's title and tests are all about grouping.
Happy to merge the grouping fix as-is if you'd rather keep them together — just say so and I'll drop the request.
2 participants
Closes #283 — the remaining approved scope (bug 4).
Per your retest, bugs 1–3 are already fixed on
main. This PR covers the two halves of bug 4, kept tight and additive.🛟 Grouping — the data-loss footgun
groupSimilarProjectsunioned every project that shared any directory. A noisy ancestor ($HOMEor a session root) listed under many projects collapsed the whole store into one component, soprojects consolidate --allproposed merging dozens of unrelated projects into a single bucket.maxSharedProjectsForDirMatch(3) distinct projects.🧹 Cleanup of pre-existing path-named garbage
--paths-onlyflag onengram projects prunenarrows the 0-observation candidate set to projects whose name is a filesystem path.normalizeExplicitWriteProject(ContainsAny(name, "/\\")), so it targets exactly the names newer versions already refuse to create.✅ Regression coverage (TDD)
prune --paths-onlylists only path-named empty projects.go build ./...,go vet, andgofmtall clean on the touched packages.Suggested labels (external contributor can't self-apply):
type:bug·priority:high·status:needs-review