PLAN REVIEW Fullstack Crud Generation

Documentation for Handoffs

Plan Review: Full-Stack CRUD Generation with Universe Integration

Reviewer: Browser Agent (S138 testing context) Date: 2026-02-25 Based on: 3 test cycles of module generation (modgen-6b995d73, modgen-a3e90163, modgen-f1d7b0ad)

Verdict: Right Direction, Wrong Scope and Sequencing

The core insight is correct — using DataController as the generic CRUD backend and bridging LLM entity specs to EntityDefinition is the right architecture. No NestJS codegen needed. The bottom-up implementation order is sound and the file list is reasonable.

The problems are in scope (too much at once) and sequencing (building on an unreliable foundation without fixing it first).

What's Actually Fine

Critical Issues

1. Building on an Unreliable Foundation

We just spent three test cycles proving that LLM extraction fails for 2/5 modules consistently, falling back to scaffold garbage (duplicate fields, of(null) services, wrong casing). This plan adds 5 new downstream phases that all depend on EXECUTE producing good output.

If EXECUTE fails for a module, what happens? BACKEND_SETUP will either register a broken EntityDefinition schema into MongoDB (now you have garbage in your database, which is worse than garbage on disk), or it needs to detect the failure and skip — which the plan doesn't address at all.

Recommendation: Either (a) explicitly handle the scaffold-fallback case in BACKEND_SETUP (skip schema registration, mark module as degraded), or (b) fix the LLM extraction reliability first. Fixing extraction before starting this work is strongly recommended, because debugging failures across 6+ pipeline phases when the root cause is in phase 4 is going to be miserable.

2. Changing the LLM Prompt for DataController URLs Is High-Risk and Unnecessary

The DataController API is non-standard — POST .../data/:collection/query for listing, POST .../data/:collection/insert for create. LLMs are trained on millions of standard REST examples (GET /members, POST /members, PUT /members/:id). The LLM is currently generating clean, well-structured services with standard REST patterns. Asking it to generate DataController's unusual API pattern will likely destabilize output quality.

Better approach: Don't change the prompt at all. Let the LLM generate standard REST services (which it's good at), then add an auto-correction method — rewriteServiceUrlsToDataController() — that mechanically rewrites the URLs post-generation. The auto-correction pipeline is already working. This is a string transformation, not an LLM task. The LLM shouldn't be responsible for knowing internal API conventions.

3. Module Contract Surface Area Explosion

The plan wants to generate: module class with BrowserModuleContract, @ModuleDecorator, @PublicAction action classes (5 per entity), event classes (4 per entity), repositories, barrel exports. For a 5-module generation, that's roughly 50+ additional files the LLM needs to produce correctly, and the auto-correction pipeline needs to validate. We just got 6 auto-corrections working — this plan would need maybe 15-20 more.

The gmodules1 module contract pattern (BrowserModuleContract, @ModuleDecorator) was designed for NgModule-based architecture. gspace1 has moved to standalone components and signals. The "adaptation" is hand-waved — "adapted for gspace1" — but BrowserModuleContract's lifecycle methods, module manifest, and action registration system may not map cleanly to standalone component architecture.

Verification needed: Does @ModuleDecorator and BrowserModuleContract actually work with standalone components in gspace1? If not, that's a prerequisite investigation before writing any code.

Recommendation: Split this — ship DataController integration first (phases 1-3 without module contracts), prove it works end-to-end, then add module contracts as a separate effort.

4. Bug 10 Makes This Untestable

The Vibe page freezes after ~15-20 minutes of generation due to 6 compounding memory/performance issues (see TEST-REPORT-S138.30). This plan adds more phases (BACKEND_SETUP), which means longer generation times, which means Bug 10 will be even worse. Each test cycle during development will require opening a fresh tab after the freeze to check results.

Recommendation: Fix Bug 10 first. The highest-impact fix (truncating phase content in handleContentDelta() and throttling signal updates) is probably 30 minutes of work. Do that before starting multi-week feature work that requires extensive testing.

5. No Error Handling or Rollback Strategy

BACKEND_SETUP pushes schemas to DataController and creates MongoDB collections. What happens if the generation fails halfway through? You now have orphaned schemas and collections in the database with no corresponding frontend. The plan needs a rollback strategy — either transactional (all or nothing) or cleanup-on-failure.

The current pipeline has no concept of this because it only writes files to disk (cheap to delete). Database state is different.

Similarly for UniversalModule tree: if DEPLOY writes a malformed tree to Universe.structure, does the visual editor crash? Can it handle partial trees? What's the recovery path?

6. Singularity Flow Skeletons Are Underspecified

"Generate skeleton flows for each CRUD action (status: 'skeleton')" — what's in a skeleton flow? What nodes? What connections? What happens when the Flow Engine encounters a skeleton? Is there precedent for this in the codebase? This could be either trivial (just an empty flow document) or a rabbit hole (the Flow Engine expects certain nodes/connections to be valid). Needs investigation before committing to it.

7. Missing Prerequisite: EXECUTE.output.files Persistence

The frontend shows "Generated Modules: 0" because the EXECUTE output isn't persisted to the checkpoint. This plan adds more output (EntityDefinitions, CRUD actions, UniversalModule tree) that presumably also needs to be persisted and displayed. If the basic persistence is broken, all the new data will also be invisible.

Recommendation: Fix the persistence first.

Recommended Implementation Order

Instead of doing phases 4-7 simultaneously, ship smaller increments and prove each layer before building the next:

Prerequisites (Fix Before Starting)

  1. Fix Bug 10 (~30 min) — truncate phase content in handleContentDelta(), throttle signal updates
  2. Fix EXECUTE.output.files persistence — frontend shows 0 modules/files
  3. Investigate and fix the 2/5 LLM extraction failure — understand why some modules always fall to scaffold
  4. Fix ChangeDetectionStrategy import bug — auto-correction adds enum but not the import

Phase 1: DataController URL Auto-Correction Only

Add rewriteServiceUrlsToDataController() to auto-correction.service.ts. No prompt changes. The LLM generates standard REST; auto-correction rewrites to DataController URLs. Ship and verify.

Phase 2: BACKEND_SETUP with EntityDefinition

Schema registration with DataController, with explicit handling for scaffold-fallback modules (skip them, mark as degraded). Include rollback/cleanup on failure.

Phase 3: UniversalModule Tree in DEPLOY

Update DEPLOY phase to produce visual editor-compatible structure. Include error handling and validation. Test that the visual editor can actually load the tree.

Phase 4: Module Contracts (If Still Needed)

After everything else is stable, evaluate whether BrowserModuleContract patterns are actually needed or if the simpler standalone component approach is sufficient.

Summary

The plan's direction is right. The scope and sequencing need work. Ship smaller, prove each layer before building the next one. Fix the known reliability issues (Bug 10, extraction failures, persistence) before adding complexity that depends on them.

The biggest single mistake would be changing the LLM prompt for DataController URLs — use auto-correction instead. The second biggest would be trying to ship module contracts simultaneously with DataController integration.