Architecture: How to bridge the gap between generated platform output and ...

Documentation for Sessions

🏗️ Architecture: How to bridge the gap between generated platform output and ...

Date: 2026-02-28
Time: 21:39:40 UTC
Session: gspace1-156.4
Agent: angular
Confidence: 92%
Status: ✅ Documented


📋 Decision Context

Question:

How to bridge the gap between generated platform output and editing tools (page-builder, layout-builder, modularity-lib)?

Task: Not specified


🎯 Decision Made

Chosen:

Top-to-bottom PlatformBlueprint pipeline: ShellGeneratorService picks LayoutDefinition from layout-builder (5 presets), PageContentGeneratorService creates Page[] with real WidgetInstance[] from page-builder (25 widget types, 12 container presets), NavigationBlueprint maps modules to routes. All using the exact same types the editing tools understand.

Options Considered:


💭 Reasoning

ROOT CAUSE: vibe-universe generated a flat manifest (JSON metadata) that didn't use the same data structures as the editing tools. page-builder expected WidgetInstance[] with specific config shapes. layout-builder expected LayoutDefinition with named slots. The manifest had neither — it was ad-hoc JSON. The fix: generate using the editing tools' OWN types. ShellGeneratorService delegates to LayoutBuilderService.createLayoutDefinition(). PageContentGeneratorService uses WidgetInstanceBuilder.create() + ContainerPresetsService.getPreset() + UnifiedWidgetRegistry.get().createDefaultConfig(). The output is immediately editable because it IS the same data the tools render. Also fixed 3 bugs in page-builder's convertApiPageToPage (metadata field names, gridColumns/gridGap, recursive children) and 1 bug in the page save endpoint (was /pages, correct is /space-pages via SpaceApiService).


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation