🏗️ Architecture: How should generated platforms be structured — loose modules...

Date: 2026-03-10
Time: 18:57:32 UTC
Session: gspace1-199.3
Agent: angular
Confidence: 92%
Status: ✅ Documented

📋 Decision Context

Question:

How should generated platforms be structured — loose modules or a runnable Angular app?

Task: S199: App shell generation for deployable platforms

🎯 Decision Made

Chosen:

New AppShellGeneratorService that produces a complete Angular app (main.ts, app.config.ts, app.routes.ts, app.component, index.html, project.json, tsconfig, styles) wrapping all generated modules via lazy-loaded routes.

Options Considered:

1. Generate only modules (current — not deployable)
2. Generate app shell (chosen — complete deployable platform)
3. Use a pre-built shell template (too rigid, doesn't adapt to module count/names)

💭 Reasoning

ROOT CAUSE: The pipeline generated module files but no container app. Without an app shell, the generated code couldn't be built, served, or deployed — it was just loose library files. Users expected a working platform but got disconnected modules. The app shell connects all modules via lazy routes, registers manifests at runtime via ModuleRegistryService, and provides the navigation/layout shell. This makes the output immediately deployable to Cloudflare Pages. The shell follows existing gograb-space patterns (standalone Angular 20, signals, provideRouter) and uses the theme system variables. The shell is generated alongside modules in the DEPLOY phase, before auto-corrections, so it gets the same quality treatment.

📁 Files Involved

• APIs/backend-vitto-api/src/app/module-generation/generators/app-shell-generator.service.ts
• APIs/backend-vitto-api/src/app/module-generation/module-generation.module.ts
• APIs/backend-vitto-api/src/app/module-generation/phases/module-gen-phase.executor.ts

🔗 Related

• Decision ID: dev_1773169052759_4167th2
• Session: 199
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation