Config-getrieben — Designer und KI bearbeiten denselben Code

Tech-USP: Quelle der Wahrheit ist die Feature-Datei (defineFeature.ts). Designer (visueller Editor) und AI-Builder (Prompt) erzeugen denselben Output über einen Code-Patcher. 100 % Abdeckung — kein „70/30-Drop-Out” wie bei Bubble.

Wie das funktioniert

• Pattern-Schema: typisierte Repräsentation aller r.*-Aufrufe (30 Pattern-Arten)
• Reader: Liest die Feature-Datei → typisierte Pattern-Liste
• Patcher: Fügt Pattern hinzu, ersetzt sie oder entfernt sie. Custom-Code zwischen Pattern überlebt
• Renderer: Schreibt eine kanonische Object-Form raus (r.entity({ name, fields }))
• Designer: Formulare für jede Pattern-Art. Speichern = Git-Commit
• AI-Builder: Prompt → Patcher-Aufrufe. Custom-Code-Bereiche bleiben Code, KI generiert über Tool-Use

Was Ihr dadurch bekommt

• Kein Plattform-Lock-in — der Code lebt in Eurem Repo
• Änderungsprotokoll = Git-Log — jede Designer-Änderung ist ein Commit
• CI/CD greift sofort — kein Problem „Designer-DB driftet vom Code-Repo”
• Custom-Code bleibt — Designer editiert was er als Pattern erkennt, ignoriert Custom-Handler-Bodies

Architektur-Tiefendoku

• ../roadmap C-Pfad (C1–C7): AST-Foundation, Designer Read/Edit, Migration-Auto-Gen
• packages/framework/src/engine/feature-ast/ (Code) — 30 Pattern-Kinds, parse + render + patch + patcher
• feature-structure — Feature-File-Konventionen

Wo das im Pitch landet

• Quer durch beide Märkte: „Ihr kriegt ein Repo, keinen Black-Box-Service”
• Differenzierung gegen Bubble/Webflow: volle Code-Abdeckung, Custom-Code überlebt
• Differenzierung gegen Lovable/v0: Backend-Generierung, nicht nur UI