🏗️ Architecture: How should the preview handle LLM-generated code that import...

Date: 2026-03-23
Time: 22:37:51 UTC
Session: gspace1-261.13
Agent: architecture
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should the preview handle LLM-generated code that imports non-existent files?

Task: S257: Preview stability

🎯 Decision Made

Chosen:

Three-layer stub generation in bundler-filesystem.service.ts: (1) fixBrokenLibPaths rewrites wrong relative paths by searching the file index, (2) generateMissingRouteComponents creates placeholder components for unresolvable route lazy imports, (3) generateMissingImportStubs creates service/model/utility stubs for ALL remaining unresolvable imports. Service stubs extend BaseCrudApiService with real HTTP — not noop of() — so CRUD operations work even with missing generated files.

Options Considered:

1. Fail the preview with descriptive error messages
2. Fix imports at generation time via auto-correction strategy
3. Generate stubs at preview enrichment time (chosen)

💭 Reasoning

LLM-generated code has three classes of import failures: (1) wrong relative path (./lib/ instead of ./) — fixable by searching file index, (2) missing route targets — LLM declares routes to components it never created, (3) missing services/models — LLM imports from paths that don't exist. Without stubs, rspack crashes with 'Module not found' and the entire preview fails. Critical design choice: service stubs must extend BaseCrudApiService (real HTTP) not return of() (noop), because users expect the generated platform to actually persist data. A noop stub makes the preview appear broken.

📁 Files Involved

• libs/libs-structural/platform-preview/src/lib/services/bundler-filesystem.service.ts

🔗 Related

• Decision ID: dev_1774305471347_i1mrdnu
• Session: 261
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation