🏗️ Architecture: How should generated modules produce high-quality, productio...

Date: 2026-03-08
Time: 15:38:56 UTC
Session: gspace1-190.2
Agent: backend
Confidence: 92%
Status: ✅ Documented

📋 Decision Context

Question:

How should generated modules produce high-quality, production-grade code instead of non-functional stubs?

Task: S190: Fix module generation quality, Studio integration, MongoDB structure

🎯 Decision Made

Chosen:

Three-layer strategy: (1) Deterministic templates as primary base using UniverseDataService + correct collection names, (2) LLM enhance with entity-specific fields guided by improved prompts with anti-patterns + golden examples, (3) Auto-correction safety net detecting mock data, nav-only submit, collection name mismatch, route ordering. Template-first: generateFromTemplates() now runs BEFORE LLM files, with LLM overriding at same paths. Critical discovery: templates were dead code (never called in execute pipeline) — wired into phase executor DEPLOY step.

Options Considered:

1. LLM-only: Better prompts without templates (unreliable — LLM still produces stubs)
2. Template-only: No LLM, pure interpolation (can't customize entity-specific fields)
3. Template-first + LLM enhance + auto-correction (chosen — deterministic base with LLM customization)
4. Composable-based: Generate code using useCrudList/useCrudForm composables from @libs-core/module-base (best long-term, requires prompt rewrite — deferred to next session)

💭 Reasoning

Root cause: Generated modules had 8 defects (hardcoded mock data in detail, navigation-only form submit, navigation-only delete, generic form fields, wrong field names in HTML, missing components, HttpClient instead of UniverseDataService, wrong route ordering). The template system existed but generateFromTemplates() was never called — only generateScaffoldFiles() as fallback. The LLM generated everything from scratch, producing stubs. Fix: templates provide deterministic working CRUD wiring; LLM customizes entity-specific parts; auto-correction catches remaining defects. Collection name mismatch (frontend used moduleName, backend registered entityName+s) was a data integrity bug causing orphaned data.

📁 Files Involved

• APIs/backend-vitto-api/src/app/module-generation/templates/template-registry.service.ts
• APIs/backend-vitto-api/src/app/module-generation/validation/auto-correction.service.ts
• APIs/backend-vitto-api/src/prompts/module-gen/implement.prompt.md
• APIs/backend-vitto-api/src/app/module-generation/phases/module-gen-phase.executor.ts
• APIs/backend-vitto-api/src/app/module-generation/phases/backend-setup.phase.ts

🔗 Related

• Decision ID: dev_1772984336177_fw917wo
• Session: 190
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation