Architecture: How should generated platforms get their core infrastructure...

Documentation for Sessions

🏗️ Architecture: How should generated platforms get their core infrastructure...

Date: 2026-03-12
Time: 03:11:04 UTC
Session: gspace1-206.3
Agent: angular
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should generated platforms get their core infrastructure (Angular libs, UI components, data services, theme system)?

Task: S206: Fix platform generation pipeline so generated platforms actually compile and run

🎯 Decision Made

Chosen:

GitLab base template with 33+ gspace1 libraries pre-ported. Pipeline forks from gograbspace/platform-base-template via initializeFromTemplate(). Generated feature modules are committed on top of the template's existing libs.

Options Considered:

    1. Copy libs inline during each generation (S199-S204 approach — committed empty directories)
    1. Publish libs as npm packages (@gograb/platform-sdk)
    1. GitLab base template forked per-platform (chosen — Phase 1)
    1. ESM SDK on Cloudflare CDN with import maps (planned — Phase 2)

💭 Reasoning

Root cause: S199-S204 generated empty libs-core/, libs-foundational/, libs-ux/ directories because the pipeline created folder stubs but never provided actual library source code. Every generated platform failed to compile — all @libs-* imports were unresolvable. The template approach solves this by having all infrastructure pre-built and verified (0 build errors confirmed). npm packages (option 2) would work but requires a publish pipeline we don't have. ESM CDN (option 4) is the ideal end-state — eliminates source duplication, enables instant preview, shared caching — but requires building a compilation pipeline first. Phase 1 (template) ships today and unblocks generation. Phase 2 (ESM SDK) is the evolutionary step.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation