Applications¶

This page maps the user-facing application surfaces in apps/.

These are intentionally separate from the core engine. They have different runtimes, UX concerns, and contributor workflows even when they share the same underlying platform code.

App map¶

App	Path	Runtime	Purpose
Cloud	`apps/cloud/`	Django	Hosted dashboard authoring, project management, and collaboration surface
Playground	`apps/playground/`	FastAPI-style app surface	Live dashboard editing and preview environment
IDE	`apps/ide/`	VS Code extension	Editor integration, preview, diagnostics, and authoring support
Docs	`apps/docs/`	Docs app/build surface	Documentation publishing surface
A Lie	`apps/a_lie/`	App-specific	Separate AI-facing application surface

Cloud¶

Path: apps/cloud/

Cloud is the main web application surface. It adds product concerns on top of the shared platform:

accounts, organizations, and project management
repo and branch workflows
dashboard editing UX
connection management
snapshots and app-level AI features

Cloud should use dataface/core for rendering and execution rather than re-implementing engine logic.

Playground¶

Path: apps/playground/

Playground is a lighter-weight interactive editing surface focused on fast iteration:

live YAML editing
rapid preview loops
websocket-driven refresh
temporary share-link behavior
prompt-assisted generation/editing flows

It shares engine capabilities with Cloud but has a different product goal and much less account/project infrastructure.

IDE¶

Path: apps/ide/

The IDE app is the editor integration surface:

syntax highlighting and snippets
diagnostics and validation in-editor
preview and navigation workflows
language tooling and extension packaging

This is not a web app and should be documented separately from Cloud and Playground.

Docs¶

Path: apps/docs/

The docs app is the documentation delivery surface. It is not part of the rendering engine or the product authoring surfaces, but it matters for contributor workflow and publishing.

A Lie¶

Path: apps/a_lie/

apps/a_lie/ is another application surface and should be treated as such in documentation. If work expands there, give it a focused app page rather than burying its behavior inside generic AI notes.

Boundary rule¶

When deciding where to document or implement something:

put shared dashboard engine behavior in dataface/core
put app-specific UI, workflow, and runtime behavior in the relevant apps/<name>/
document stable cross-app architecture here
keep app-specific operational details in the app's local docs when that is more precise