Home

DesignForge AI Wiki

An AI-native visual design, advanced prototyping, and design-to-code platform.

DesignForge AI brings together a professional object-based design editor, a context-aware AI design engine, an interactive prototype runtime, and a deterministic React/TypeScript compiler. Its core promise is simple: one editable design document powers the canvas, inspector, AI operations, prototype, and exported code.

This wiki describes the proposed product architecture, interaction contracts, engineering principles, delivery plan, and quality gates for evolving the existing DesignForge application. It is an implementation blueprint—not a claim that every capability listed here is already shipped.

Start here

• Product Vision and Principles
• System Architecture
• Design Engine and Interaction Model
• AI Engine
• Prototyping Engine
• React Compiler and Export
• Project Files, Persistence, and Assets
• Device Frames and Responsive Design
• Quality, Testing, and Roadmap
• Engineering Guardrails

Product vision

DesignForge is intended for product designers, UX/UI designers, design-system teams, design engineers, and frontend developers who need to move from an idea to an editable design, a realistic prototype, and maintainable application code without repeatedly rebuilding the same work in disconnected tools.

Core capabilities

Capability	Intended outcome
Professional design editor	Object-level editing, layers, components, vectors, typography, layout, styles, and design tokens
Infinite canvas	Pan, zoom, selection, snapping, guides, and efficient rendering for large documents
AI design engine	Convert natural-language intent into validated, reviewable edits to the real design document
Advanced prototyping	Interactive flows, variables, conditions, overlays, scrolling, animation, test scenarios, and a realistic player
Design-to-code compiler	Export supported designs to maintainable React and TypeScript projects
Local-first project ownership	Save, reopen, recover, import, and export portable .dforge projects
Extensible ecosystem	MCP integration, adapters, plugins, scripting, and optional services under controlled contracts

The central architecture rule

The canonical design document is the source of truth. The canvas is a projection of it; the properties inspector edits it; AI proposes operations against it; the prototype runtime interprets its interaction graph; and the compiler translates supported semantics into code. These systems must not maintain conflicting copies of design truth.

flowchart TD
    User[Designer / Developer] --> Shell[Application Shell]
    Shell --> Workspace[Design Workspace]
    Workspace --> Commands[Command and Transaction Engine]
    Commands <--> Document[Canonical Design Document]
    Document --> Renderer[Canvas and Layout Renderer]
    Document --> AI[AI Context and Planning]
    AI --> Validation[Schema and Scope Validation]
    Validation --> Commands
    Document --> Prototype[Prototype Runtime]
    Document --> Compiler[React / TypeScript Compiler]
    Document <--> Store[Project Store and Recovery]
    Prototype --> Player[Preview / Presentation Player]
    Compiler --> Export[Runnable Exported Project]

Loading

Working principles

1. Inspect before changing. Understand the existing repository, dependencies, state management, rendering, persistence, and public contracts before refactoring.
2. Prefer working vertical slices. Complete a capability end-to-end before expanding the interface.
3. No decorative controls. Every visible control in scope must execute real logic or remain hidden/disabled with a clear reason.
4. One mutation pipeline. Manual edits, AI edits, imports, and supported automation must use validated commands and transactions.
5. Undo is fundamental. User-visible operations should be atomic, reversible where practical, and recoverable.
6. Local-first by default. Core design and project workflows should not require cloud connectivity. Remote AI, collaboration, publishing, and shared libraries are optional services with explicit status and consent.
7. Deterministic core, AI-assisted judgment. Geometry, serialization, layout resolution, validation, and code generation should be deterministic wherever possible.
8. Familiar interaction conventions, original identity. Adopt useful industry-standard workflows without copying another product’s branding, proprietary assets, icons, source code, or marketing copy.
9. Document limitations honestly. Unsupported export or prototype semantics must produce diagnostics rather than silently disappearing.
10. Test claims. Performance, compatibility, and parity claims require repeatable tests and recorded results.

Status vocabulary

Use these labels consistently in planning and release notes:

• Implemented — available and covered by relevant tests.
• In progress — actively being implemented; incomplete behavior is documented.
• Planned — specified but not yet implemented.
• Limited — works for a documented subset of cases.
• Blocked — depends on an unresolved technical or product decision.

Do not mark a capability implemented solely because its UI exists.

Suggested implementation order

1. Repository audit, architecture map, and protected integration boundaries.
2. Canonical document model, command/transaction engine, geometry, renderer, and basic editor.
3. Layers, selection, property inspector, keyboard shortcuts, undo/redo, and local save/recovery.
4. Layout, tokens, styles, components, variants, and asset handling.
5. Deterministic React compiler and build diagnostics.
6. AI planning, validated operations, diff preview, approval, and evaluation.
7. Prototype runtime, player, animation, variables, conditions, diagnostics, and scenario tests.
8. Accessibility, performance, import/export coverage, and optional ecosystem services.

See Quality, Testing, and Roadmap for readiness gates and Engineering Guardrails for protected contracts.

Source specifications

This wiki consolidates the following project materials supplied for the DesignForge initiative:

• Design Engine Logical Parameters & Figma-Inspired Interaction Specification
• DesignForge AI Product Architecture
• Advanced Design Editor Master Prompt
• DesignForge Master Prompt
• Device and Frame Specifications
• Project README

The original specification documents remain the detailed reference for field-level requirements and acceptance scenarios. Where a detail is not explicitly established in the source material, it should be recorded as a design decision rather than silently treated as settled.