🏗️ Architecture: Why did backend-ai-api build 46+ Angular UI libraries as dep...

Date: 2026-02-06
Time: 19:33:01 UTC
Session: editor2-97.6
Agent: backend
Confidence: 100%
Status: ✅ Documented

📋 Decision Context

Question:

Why did backend-ai-api build 46+ Angular UI libraries as dependencies?

Task: Session 97: Fix backend-ai-api pulling 46+ Angular UI libraries

🎯 Decision Made

Chosen:

Extracted PhaseResultToModuleContextAdapter as standalone pure-TypeScript file inside backend-ai-api, removing the modularity-lib dependency entirely

Options Considered:

1. Keep modularity-lib import and accept slow builds
2. Create a modularity-core pure-TS library
3. Move adapter into backend-ai-api with inlined types

💭 Reasoning

One import in phase-orchestrator.service.ts pulled PhaseResultToModuleContextAdapter from @libs-structural/modularity-lib — a full Angular feature library. This caused NX to build modularity-lib → singularity-lib → gograb-ai-lib → the entire Angular UI ecosystem (46+ libs) before the NestJS backend could start. The adapter was pure data transformation (no Angular logic needed), it just had @Injectable decorator and imported types from modularity-lib. Fix: created a self-contained adapter file with inlined types and factory functions, removed Angular dependency. Build tasks dropped from ~46 to ~8.

📁 Files Involved

• apis/backend-ai-api/src/app/workflow/phase-executor/phase-module-context.adapter.ts
• apis/backend-ai-api/src/app/workflow/phase-executor/phase-orchestrator.service.ts

🔗 Related

• Decision ID: dev_1770406381712_3xdh3uw
• Session: 97
• Workspace: editor2

Auto-generated by MCP Smart Consolidation