fix(orchestration): allow deleting a project whose only threads are archived (#2866)

[leorivastech]

Fixes #2866.

Right now, if you archive every thread in a project and then try to remove the
project, "Remove project" just doesn't work. You get a confusing error:
"Project '...' is not empty and cannot be deleted without force=true" — even
though the project looks empty in the UI.

The reason is that the client and the server don't agree on what "empty" means.
The shell snapshot the client receives leaves archived threads out (it filters
on archived_at IS NULL), so the client sees zero threads and sends a plain
project.delete without force=true. The server, on the other hand, treats any
thread that isn't deleted as still counting — archived ones included — so it
rejects the command. The button ends up dead.

This change teaches the server to count the same way the client already does.
In decideOrchestrationCommand's project.delete branch, I split apart two things
that were previously lumped into one list. One question is "what should block a
plain delete?", and the answer is now only the threads that are neither deleted
nor archived. The other question is "what gets cleaned up along with the
project?", and that still includes every non-deleted thread, archived ones too,
so nothing is left orphaned when the project goes away.

Projects that actually have active (non-archived) threads behave exactly as
before: they still require force=true. The only thing that changes is that a
project whose remaining threads are all archived can now be removed normally,
and those archived threads are deleted with it.

I also considered fixing this on the client side instead (detect the archived
threads and show the "Delete anyway" force dialog), but matching the server's
definition of "empty" to the snapshot the client already uses is the smaller,
single-place fix.

For tests, I added a regression case in decider.delete.test.ts: a project whose
only thread is archived. It fails on main with the exact invariant error, and
passes with this change, deleting the project and emitting thread.deleted
followed by project.deleted. The existing delete tests are untouched and still
pass, the full orchestration suite is green (152/152), and typecheck, lint and
formatting are clean.

---

Note

Medium Risk
Changes orchestration invariants for project deletion; behavior for active threads is preserved, but archived-thread edge cases now delete data without force.

Overview
Fixes #2866 by aligning server project.delete with the client’s notion of an “empty” project.

In decideOrchestrationCommand, non-forced deletion is blocked only by undeleted, non-archived threads (blockingThreads), not every undeleted thread. Projects whose remaining threads are all archived can be removed without force=true. Cascade cleanup is unchanged: all undeleted threads (including archived) still get thread.delete before project.deleted, so nothing is orphaned.

A regression test seeds a project with a single archived thread and expects thread.deleted then project.deleted on a plain project.delete.

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

Note

Fix project deletion to allow deleting projects with only archived threads

• In the project.delete case of decideOrchestrationCommand, renames activeThreads to undeletedThreads and introduces blockingThreads as the subset of undeleted threads that are not archived.
• The precondition blocking non-forced deletion now checks blockingThreads.length > 0 instead of all undeleted threads, so archived-only projects can be deleted without the force flag.
• Thread deletion commands are still cascaded for all undeleted threads (including archived ones) before emitting project.deleted.

^{Macroscope summarized 4c66c55.}

[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: 5731c34f-fe98-4786-a120-8cd616450819

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.}

[macroscopeapp]

Approvability

Verdict: Approved

Straightforward bug fix allowing deletion of projects with only archived threads without requiring force=true. The change is limited in scope, well-documented with comments referencing issue #2866, and includes comprehensive test coverage.

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

[paulbettner]

Additional repro for the same invariant, in case it helps scope this fix:

1. Create a folder and add it as a project.
2. Create/use a thread in that project.
3. Delete the folder outside T3 Code.
4. Restart T3 Code.
5. Try to remove the project from the sidebar.

Actual: the client sends plain project.delete, then the server rejects it with Project '...' is not empty and cannot be deleted without force=true even though the sidebar has no visible threads for the project.

Expected: either the delete succeeds when the server can safely cascade, or the client falls back to the existing force-confirm flow when project.delete reports that the project is non-empty.

This PR may cover the case when the hidden remaining threads are archived-only. If not, the complementary client-side fallback is small: catch this specific invariant and show the existing "Delete anyway" confirmation.

[leorivastech]

Thanks, that's a great repro 🙏 I think it's a slightly different case from this PR. Yours sounds like real (non-archived) threads still hanging around after the external delete, while this change only handles the archived-only case on the server. I'd like to keep this PR small and focused so it's easy to review and hopefully get it merged, then open a separate issue to dig into your scenario. The client-side "Delete anyway" fallback you described sounds like the right approach. Appreciate you flagging it!