Architecture: How should we restructure session management from workspace-...

Documentation for Sessions

🏗️ Architecture: How should we restructure session management from workspace-...

Date: 2026-02-05
Time: 21:23:27 UTC
Session: editor2-92.16
Agent: backend
Confidence: 92%
Status: ✅ Documented


📋 Decision Context

Question:

How should we restructure session management from workspace-folder-based to flat, globally-unique?

Task: Session management v12.0 restructuring


🎯 Decision Made

Chosen:

v12.0: Global monotonic counter (S1, S2... S94) via MongoDB atomic $inc, fully flat file structure (sessions/manifests/S{N}.json), lean sessions with rich sub-sessions carrying WHO/WHERE/WHAT/WHEN attribution, no inline decisions in manifests

Options Considered:


💭 Reasoning

Workspace folders (sessions-history/editor2/, gspace/) were a maintenance nightmare preventing cross-workspace session management. Sub-sessions are the real unit of work, not sessions. By making sessions lean containers and sub-sessions rich with developer/agent/workspace/platform attribution, we eliminate folder structure as an organizational mechanism while preserving all metadata. MongoDB atomic $inc prevents ID collisions. Decisions stay in MongoDB only (current session-92.json was 765 lines due to inline decisions; v12 manifests are ~80 lines).


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation