Architecture: Should module generation use outputMode BOTH (visual + code)...

Documentation for Sessions

🏗️ Architecture: Should module generation use outputMode BOTH (visual + code)...

Date: 2026-02-23
Time: 22:22:55 UTC
Session: gspace1-139.6
Agent: angular
Confidence: 98%
Status: ✅ Documented


📋 Decision Context

Question:

Should module generation use outputMode BOTH (visual + code) or VISUAL only, given that generated code strings are never compiled or persisted?

Task: S138.8 switch default outputMode to VISUAL


🎯 Decision Made

Chosen:

Switched default from BOTH to VISUAL. Code generation is kept as an option but no longer the default.

Options Considered:

  1. Keep BOTH as default (generates .ts/.html/.scss code strings)
  2. Switch to VISUAL only (JSON schema for dynamic rendering)
  3. Make it configurable per request

💭 Reasoning

The MongoDB analysis (S138.8) revealed that generated modules NEVER become static Angular files. The system uses dynamic rendering from JSON schema at runtime. The code strings from Path B of the EXECUTE phase (actual .ts/.html/.scss content) are: (1) stored only in the manifestJSON blob, (2) never extracted to files, (3) never compiled, (4) never executed. They're throwaway artifacts that add ~90s per module to generation time and cause LLM timeouts (every code gen call in our tests timed out). Switching to VISUAL mode cuts generation from ~10 min to ~5 min with zero functional impact on the deployed platform. Code generation remains available via outputMode='code' or 'both' for a future 'export to standalone project' feature.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation