🐛 Bugfix: How should findSlugsForUniverse() locate generated modules —...

Date: 2026-03-17
Time: 15:25:15 UTC
Session: gspace1-226.16
Agent: angular
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should findSlugsForUniverse() locate generated modules — via universe structure document or direct universeId query on space_modules?

Task: Fix Live Preview not rendering generated platform modules

🎯 Decision Made

Chosen:

Direct query on space_modules by universeId field, removing the structure-based recursive extraction approach

Options Considered:

1. Keep structure-based approach and also write moduleId into structure during generation
2. Query by universeId directly on space_modules (chosen)
3. Use a join/aggregation pipeline across universes and space_modules

💭 Reasoning

The structure-based approach (query universe doc → extract moduleIds from structure tree → find modules by _id) failed because generated modules are persisted to space_modules with a universeId field set during the deploy step, but they are NOT linked into the universe.structure tree. The structure tree is a UI/page-builder concern — it maps pages to modules for navigation. Generated modules exist in space_modules before any structure assignment. The old code returned empty arrays because extractModuleIdsFromStructure found zero moduleId references in structure nodes that don't exist yet. The fix queries space_modules directly where universeId matches, with a slug normalization variant ($or) to handle underscore/hyphen differences in older entries. This is simpler (1 query vs 3), more correct (matches actual data model), and eliminates a cross-collection dependency on universes.

📁 Files Involved

• APIs/backend-api/src/app/spaces/space-modules.service.ts

🔗 Related

• Decision ID: dev_1773761114786_rj9w3cd
• Session: 226
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation