🏗️ Architecture: How should libs-structural libraries be consolidated without...

Date: 2026-02-28
Time: 21:40:06 UTC
Session: gspace1-156.5
Agent: architecture
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should libs-structural libraries be consolidated without losing reusability?

Task: Not specified

🎯 Decision Made

Chosen:

Reusability-first: DELETE only structure-management (5,661 LOC, 0 consumers). KEEP module-browser-lib (584 LOC, 2+ consumers, generic module selector), platform-shell (904 LOC, quick-switcher reusable across extensions/mobile/desktop), module-editor-lib (939 LOC, clean domain). Deprecation path for space-map-lib→universe-map and modular-universe→universe-canvas. 16→15 libs.

Options Considered:

• No alternatives documented

💭 Reasoning

ROOT CAUSE: Initial analysis recommended merging 3 libs into others (module-browser-lib→modularity-lib, platform-shell→core-angular). User correctly pushed back: small libs with clear domain boundaries and reuse potential should stay independent. Re-analysis showed: module-browser-lib is a generic 'pick a module' component usable by any builder tool; platform-shell's quick-switcher (Cmd+K) and PresenceOverlay are platform-wide utilities that should be adopted by Chrome/VSCode extensions, desktop, and mobile; module-editor-lib has a clean domain (file editing) at the right size. Only structure-management was truly orphaned (0 imports across entire codebase, 8 components duplicated by space-map-lib/universe-canvas). Types it defined already exist in @libs-foundational/core-models.

📁 Files Involved

• tsconfig.base.json
• libs/libs-structural/

🔗 Related

• Decision ID: dev_1772314806133_a7oway5
• Session: 156
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation