Delete teams

[sbmueller]

What problem does this solve?

Over time, many teams accumulate in ensemble.
One issue this creates is that each team name must be unique, but if there are already hundreds of old, unused teams, the team names get more and more ambiguous and less descriptive.

What would you like to see?

Removal of teams that are not needed anymore

Alternatives considered

No response

[shahrin014]

Hi @hueyexe, you can assign this to me if you want.

I think its just a matter of ensuring the team_cleanup is called (if not already), then just removing the record from the DB (instead of just "archived" status)

[hueyexe]

Thanks for the interest @shahrin014. This one is a bit more involved than it looks on the surface:

• All related records (members, tasks, messages) need cascade deletion
• Branch preservation must be enforced before any cleanup (worktree branches get destroyed if you skip this step)
• Need a guard against deleting teams that are still active
• The existing "archived" status from team_cleanup is intentional so this would likely be a separate operation or a flag

I'll get to this shortly since it touches some critical invariants around branch safety. That said, PRs are always welcome on anything. If you want to pick something up check out CONTRIBUTING.md.

[shahrin014]

Should we have 2 tools, one to permanently delete, and another to unarchive? I would image the one to unarchive would be simple to implement?

[shahrin014]

@hueyexe, I am preparing this change to unarchive. Let me know if you are okay an I will raise a pull request.
https://github.com/hueyexe/opencode-ensemble/compare/main...shahrin014:opencode-ensemble:feat/team-unarchive?expand=1

I did notice some issues, team members did not respond to new tasks after being unarchived, but I think that issue might be unrelated.

[hueyexe]

@shahrin014 thanks for digging into this and sharing the unarchive branch.

This is fixed in v0.14.0 through team_cleanup rather than a separate tool. The purge flow now previews what will be deleted, requires explicit user approval, deletes archived team records with cascaded members/tasks/messages, and safely handles preserved branches, stale resources and active-team guards.

I did not include unarchive in this change. Your note about members not responding after unarchive matches the main concern: reviving an archived team is not just a DB status change because sessions, worktrees and delivery state may no longer be valid. If we want unarchive later, it should be tracked separately with those semantics defined.

[sbmueller]

Thank you for the swift reaction and solution!