Architecture: How to enrich the platform generation pipeline with building...

Documentation for Sessions

πŸ—οΈ Architecture: How to enrich the platform generation pipeline with building...

Date: 2026-03-20
Time: 17:30:58 UTC
Session: gspace1-244.4
Agent: backend
Confidence: 93%
Status: βœ… Documented


πŸ“‹ Decision Context

Question:

How to enrich the platform generation pipeline with building block patterns from gmodules1?

Task: S244: Platform generation quality v3


🎯 Decision Made

Chosen:

6-change pipeline enrichment: (1) Update implement.prompt.md with 5 building block sections — workflow definitions, filter definitions, entity lookups, module registration, seed data. (2) Enrich system-analyze.prompt.md to detect buildingBlocks per entity. (3) Add BuildingBlockSpec/SchemaSpec/SeedDataSpec types. (4) Wire ANALYZE→EXECUTE metadata flow. (5) Extract schemas/seedData from LLM output. (6) Seed data to backend-api in INTEGRATE phase. Platform-base-template also updated to include @libs-core/workflow-engine.

Options Considered:

  1. Prompt-only update (no code changes)
  2. Template + Prompt (chosen β€” additive, low risk)
  3. Full 13-phase pipeline redesign (over-engineering)

πŸ’­ Reasoning

gspace1 had 21 libs/core libraries covering workflow, events, media, filters, entity-lookup, module-base β€” all available in the platform-base-template's tsconfig. But implement.prompt.md only taught ~30% of them. gmodules1's product-catalog module (most mature) uses all these patterns. The gap was not infrastructure β€” it was prompt completeness. The ANALYZE phase also needed buildingBlocks detection (hasWorkflow, foreignKeys, hasMedia, filterableFields) so the EXECUTE phase LLM knows WHICH patterns to apply per entity. normalizeAnalyzeResult() silently stripped buildingBlocks β€” critical fix. Schema registration already handled by BackendSetupPhaseService β€” only seed data added to INTEGRATE phase to avoid duplication.


πŸ“ Files Involved


πŸ”— Related


Auto-generated by MCP Smart Consolidation