Architecture: What are the correct gspace1 import paths for generated modu...

Documentation for Sessions

🏗️ Architecture: What are the correct gspace1 import paths for generated modu...

Date: 2026-02-06
Time: 02:19:17 UTC
Session: editor2-95.7
Agent: backend
Confidence: 98%
Status: ✅ Documented

📋 Decision Context

Question:

What are the correct gspace1 import paths for generated module code templates?

Task: P1-A: Verify template imports match gspace1 @libs-core/ paths

🎯 Decision Made

Chosen:

BaseEntity → @libs-core/shared-models (NOT @libs/core). BaseRepository → @libs-core/data-access. ModuleManifest + BrowserModuleContract → @libs-core/module-base. MockDefinition → @libs-core/mock-api (NOT @libs/mock-api). PublicAction → @libs-core/action-registry. BaseService → @libs-core/data-access. The aliases @libs/core and @libs/mock-api DO NOT EXIST in gspace1 tsconfig.base.json.

Options Considered:

Fix all 6 import paths in templates + prompts
Create @libs/core alias in tsconfig
Keep as-is and fix at generation time

💭 Reasoning

The template-registry.service.ts and prompt files were using @libs/core and @libs/mock-api which are gmodules1 conventions. gspace1 uses the @libs-core/* prefix pattern. BaseEntity specifically lives in shared-models (not data-access), BaseRepository in data-access, ModuleManifest in module-base. This was verified by reading tsconfig.base.json paths and the actual index.ts barrel exports of each library. Without this fix, ALL generated CRUD modules would fail to compile.

📁 Files Involved

apis/backend-ai-api/src/app/workflow/templates/template-registry.service.ts
apis/backend-ai-api/src/app/workflow/prompts/templates/crud/implement.prompt.md
apis/backend-ai-api/src/app/workflow/prompts/templates/integration/validate.prompt.md

🔗 Related

Decision ID: dev_1770344357269_559rz6e
Session: 95
Workspace: editor2

Auto-generated by MCP Smart Consolidation