overview architecture

Architecture

MyPrompt is a single-process Electron desktop application whose product logic lives in a plain TypeScript library layer. The entire project is one standalone capsule at the repository root.

There are two code surfaces:

1. The desktop shell (desktop/) — Electron main, context-isolated preload, and a local static renderer that draws a terminal-style console.
2. The product library (lib/) — all prompt logic, LLM adapters, evaluator, billing, auth, and data access. This layer is framework-free TypeScript that the desktop shell imports through the @/ alias.

A PostgreSQL database (via prisma/) and Supabase (auth) sit behind the desktop shell's IPC command router, but all of them are optional at runtime: the Transform tool and guest Optimizer path work with nothing configured.

Component map

graph TD
    subgraph Renderer["Desktop renderer (chromium)"]
        Console[terminal console<br/>renderer.ts] --> Preload[preload.ts bridge]
    end

    Preload -->|ipcRenderer.invoke| IPC

    subgraph Main["Electron main process"]
        IPC[desktop:command router<br/>ipc/core.ts]
        AuthIPC[auth IPC]
        WorkspaceIPC[workspace IPC]
    end

    IPC --> Transform[lib/transform/engine.ts]
    IPC --> Optimizer[lib/optimizer/engine.ts]
    IPC --> Evaluator[lib/evaluator/engine.ts]
    IPC --> Library[lib/.../ipc/library.ts]
    IPC --> Billing[lib/billing/*]

    Optimizer --> Providers[lib/llm/provider-registry.ts]
    Evaluator --> Providers
    Providers --> SDKs[OpenAI / Anthropic / Mistral / Qwen / Grok SDKs]

    Optimizer --> Quality[lib/prompt-quality/contract.ts]
    Optimizer --> Templates[lib/templates/*]

    Library --> Prisma[lib/db/prisma.ts]
    Billing --> Prisma
    Billing --> Xendit[lib/billing/xendit-client.ts]
    AuthIPC --> Supabase[lib/supabase/*]

    Prisma --> DB[(PostgreSQL / pgvector)]
    Supabase --> SupabaseCloud[(Supabase auth)]

Loading

The two surfaces in detail

Desktop shell

desktop/bootstrap.ts patches Node's module resolver so @/ resolves inside dist-electron/, then loads desktop/main.ts. The main process constructs a frameless BrowserWindow with contextIsolation: true and nodeIntegration: false, sized in transcript columns and rows rather than pixels. desktop/preload.ts exposes a narrow window.sentraDesktop API; the renderer never touches Node directly.

The renderer (desktop/renderer/renderer.ts, ~3,400 lines) is the largest file in the codebase. It parses a terminal-style command line, renders the console transcript, drives the Optimizer streaming "scramble → decode" effect, and renders Coding Brief clarification rounds. All user-facing strings are separated into desktop/renderer/strings.ts, which must stay import-free.

Product library

lib/ holds the actual product. The main pipeline families are:

• lib/transform/ — the deterministic Transform engine plus the four compiler profiles (compiler/).
• lib/optimizer/ — the Optimizer engine with its Super Prompt and Coding Brief routes, plus the two markdown parsers (super-prompt-format.ts, coding-brief-format.ts).
• lib/evaluator/ — the LLM-as-a-judge scorer.
• lib/llm/ — the provider registry, readiness resolution, API-key storage, and prompt builders.
• lib/prompt-quality/contract.ts — the single source of truth for prompt-quality shapes and the Coding Brief validator V1–V14.

Data flow

A typed prompt flows through desktop:command. The router in desktop/ipc/core.ts validates the payload with Zod, resolves the caller (guest vs authenticated user), checks billing quota and model access for authenticated Optimizer/Evaluator runs, resolves a provider API key, and dispatches to the right engine. Optimizer runs stream their deltas back over optimize:chunk / optimize:done / optimize:error channels.

The Optimizer engine itself is the richest path: it picks an output kind (Super Prompt vs Coding Brief), resolves an Optimizer lane (INTERACTIVE or DEEP), optionally matches a template with embeddings, builds the system/user prompt, streams from the provider, reparses the markdown, and for Coding Briefs runs the V1–V14 validator with a single repair attempt on failure.

Where the data lives

prisma/schema.prisma models users, provider-key metadata, prompts, evaluations, templates, subscriptions, payments, usage records, feature flags, rate-limit counters, and email jobs. The Prisma client is a process singleton in lib/db/prisma.ts. Provider API keys are AES-256-GCM encrypted before they touch the database (lib/crypto.ts).

For the standalone contract, the structural and extraction verifiers (scripts/verify-structure.mjs, scripts/verify-extraction.mjs) prove the capsule has no parent-path or workspace dependency.