Runtime, Provider, and Worker

Responsibility boundary

• Runtime: website globals, types, request handling, auth, storage, and lightweight clients
• Provider: Core's AI, Codex, MCP browser, SMTP, Gmail, Telegram, and payment execution
• Worker: Prisma DB, DB metering, ZIP, and XLSX parsing and serialization
• Core: external authentication, browser editor, and Provider/Worker lifecycle management
• Core and Hub: source of truth for ownership, Releases, deployment, and operations

Execution modes

• CLI auto/local: automatically started or reused local IPC Worker with project PGlite
• CLI server: Cake20 login → Core authentication → private server Worker
• Server website: Runtime → local IPC Worker started by Core
• Core AI, browser, and integration: Core → local IPC Provider → approved execution
• Older server: existing DB tunnel or direct Runtime compatibility fallback

Website source compatibility

Website source continues to call Runtime APIs such as db.user.findMany(), db.$transaction([...]), and zip.pack(). Build and execution layers inject the Worker connection, so ordinary website source does not change.

• Generated Prisma-compatible types and delegate method names remain unchanged.
• The protocol preserves Date, BigInt, Bytes, Decimal, and JSON null values.
• Standard CRUD, aggregate, groupBy, and array transactions are supported.
• Interactive transactions and raw queries require a planned migration.
• The public row-data API and storage paths remain in Runtime; Worker handles XLSX.
• User job/task execution moves only after compatibility design.

Access and authentication

• Provider and Worker expose no public domain or service port and accept local IPC only.
• Users never select a Provider or configure its address or process.
• Only Core registers a site Release and its private database URL.
• External CLI clients receive a short-lived Core token, never the DB URL or admin Secret.
• Core validates the token, site, and scope before forwarding an allowed operation.