Fix project deletion being blocked by archived threads

[notkainoa]

This fixes an error where removing a project could fail with “Delete all threads in this project before removing it,” even when the only remaining threads were archived. This happened because archived threads were still being treated as blockers for project deletion.

What changed:

• Project removal now only blocks when there are active threads
• If a project has only archived threads left, removing the project also cleans up those archived threads

Testing:

• Added web tests for deleting projects with archived-only vs active threads
• Added server tests for the project deletion rules and archived-thread cleanup

Note

Fix project deletion being blocked by archived threads

• The project.delete command now emits thread.deleted events for each archived thread before emitting project.deleted, allowing deletion when only archived threads remain.
• A new requireProjectDeletionArchivedThreads invariant in commandInvariants.ts blocks deletion if any active (non-archived) threads exist, returning an error.
• The sidebar's SidebarProjectItem no longer disables the 'Remove project' menu item statically; instead it fetches a fresh shell snapshot on demand, checks for active threads, and shows a warning toast if any exist.
• Behavioral Change: projects with active threads now fail deletion at the command level with an invariant error rather than being silently blocked via a disabled UI control.

^{Macroscope summarized ace2723.}

---

Note

Medium Risk
Changes event emission for project.delete to a multi-event sequence and adds a new invariant that can reject deletions, which may impact projections/clients that assumed single project.deleted behavior.

Overview
Fixes project.delete semantics so archived threads no longer block project removal.

On the server, a new invariant requireProjectDeletionArchivedThreads rejects project deletion if any active (non-archived) threads exist, and decider.ts now emits thread.deleted events for each remaining (archived) thread before emitting project.deleted.

On the web, the sidebar “Remove project” flow refreshes the project’s shell snapshot before deciding whether deletion is allowed, blocks only on active threads (updated warning copy), and adds browser/UI tests covering archived-only vs active-thread deletion behavior; additional tests were added for buildSidebarProjectSnapshots grouping behavior.

^{Reviewed by Cursor Bugbot for commit ace2723. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: a19b6622-59e9-486e-bef4-720d11a0e750

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR changes project deletion behavior to allow deleting projects that have only archived threads (which are auto-deleted in a cascade). While well-tested and the logic is clear, this modifies core deletion semantics and introduces cascading delete behavior that warrants human verification of the intended workflow.

^{You can customize Macroscope's approvability policy. Learn more.}