Architecture: How should the Platform Elements generation pipeline coexist...

Documentation for Sessions

🏗️ Architecture: How should the Platform Elements generation pipeline coexist...

Date: 2026-03-25
Time: 02:55:22 UTC
Session: gspace1-268.5
Agent: backend
Confidence: 93%
Status: ✅ Documented

📋 Decision Context

Question:

How should the Platform Elements generation pipeline coexist with the existing Angular generation pipeline?

Task: S268: Dual generation pipeline design

🎯 Decision Made

Chosen:

Single pipeline, two output modes. The existing 8-phase pipeline (ENHANCE → ANALYZE → DECOMPOSE → PLAN → EXECUTE → INTEGRATE → DEPLOY) remains unchanged. Phases 1-4 are format-agnostic (entity extraction, module decomposition). Only the EXECUTE phase loads a different prompt: implement.prompt.md for Angular, implement-platform-elements.prompt.md for Platform HTML. Selected via outputFormat field on the generation request.

Options Considered:

  1. Fork entire pipeline into separate service
  2. Add outputFormat routing to phase executor (chosen)
  3. Create separate controller/endpoint for Platform Elements
  4. Replace Angular pipeline entirely (too risky)

💭 Reasoning

Forking the entire pipeline would create maintenance burden — any improvement to entity extraction or module decomposition would need to be applied in two places. The ANALYZE and DECOMPOSE phases don't care about output format; they extract entities, relationships, and module structure. Only the EXECUTE phase (where the LLM generates code) needs different instructions. The new implement-platform-elements.prompt.md was created with: complete element registry, column/field type references, two full working examples, common mistakes checklist, and validation rules. This approach was validated by manually generating a restaurant management platform from the prompt's examples and confirming it renders correctly with real MongoDB data.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation