Architecture: How should the platform generation preview work — batch-all-...

Documentation for Sessions

🏗️ Architecture: How should the platform generation preview work — batch-all-...

Date: 2026-03-20
Time: 18:22:07 UTC
Session: gspace1-246.5
Agent: architecture
Confidence: 92%
Status: ✅ Documented

📋 Decision Context

Question:

How should the platform generation preview work — batch-all-then-show or progressive per-module rendering?

Task: Not specified

🎯 Decision Made

Chosen:

Progressive per-module preview: as each module is generated by the LLM, immediately send files to the frontend VFS and trigger a preview recompile. User sees modules appearing one by one in real-time, with an activity feed via embeddable-bridge streaming (AI_STREAM_CHUNK). The rspack WASM + Angular JIT + Service Worker architecture stays unchanged.

Options Considered:

  1. Keep batch-all-then-show (status quo)
  2. Progressive per-module preview with embeddable-bridge streaming (chosen)
  3. WebContainers like Bolt.new (rejected — would replace working rspack pipeline)
  4. Server-side rendering preview

💭 Reasoning

Today users wait 25-40 min seeing only progress indicators. The EXECUTE phase already generates modules in batches (parallel within batch, sequential across). Each module's files are available when that module completes. The embeddable-bridge already has production-ready streaming (AI_STREAM_START/CHUNK/END, StreamBuffer for concurrent streams, used in Studio preview). The preview system already supports hot-reload (PREVIEW_HOT_RELOAD message type). Change is in emission pattern — emit per-module instead of batch-all-at-end — not in the compilation architecture. Rspack WASM, SDK stubs, Service Worker, Angular JIT all stay. S244 proved the preview architecture works (13 stubs, module detection fix, real CRUD rendering).

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation