Architecture: team creation handler is not atomic (DB + FS without rollback)

[Fullstop000]

Problem

🔴 Pre-existing architectural limitation.

📌 Discovered: 2026-04-23 during Gemini CLI review of dogfooding fixes #87–#92.

📁 File: src/server/handlers/teams.rs

🔍 Code: handle_create_team

📝 Current Behavior:
handle_create_team performs SQLite writes, filesystem mutations (init_team, init_team_memory), and agent process restarts without a transaction or rollback mechanism.

❌ If a late-stage failure occurs (e.g. agent restart fails), DB records persist while FS state is partial.

Impact

• Severity: Low-probability in Chorus's local-first, single-user model, but high-impact if it occurs.
• Risk: Partial-state corruption on failure (DB records exist but FS is incomplete).

Precedent

All Chorus handlers that touch both DB and FS share this pattern. Fixing it requires a systemic solution, not a one-off patch.

Potential Solutions

1. SQLite transactions spanning filesystem operations — Impossible without WAL + external coordination.
2. Two-phase commit / compensation rollback — Staging DB writes and FS mutations, then committing or rolling back atomically.
3. Shared UnitOfWork abstraction — Survey all handlers that touch DB+FS, design a shared abstraction.

Acceptance Criteria

• Survey all handlers that touch DB+FS
• Design a shared UnitOfWork or equivalent abstraction
• Implement atomic commit/rollback for team creation as pilot
• Apply pattern to remaining handlers

Related

• Fixed in: backend: team creator is not added as a member of the team channel #88 (added upfront validation to reduce failure surface)
• Blocks: None (pre-existing, not urgent)