app/ROADMAP.md

Roadmap

Component-level breakdown. The milestone-level master (M1–M5, with the vision decisions behind it) is docs/private/roadmap.md in the docs submodule.

Implementation strategy and record of existing/planned features. Completed items are terse checklists — the requirement detail lives in docs/private/vision.md (goals, requirements, decisions) and docs/architecture/structure.canvas (the four-way component split). Remaining tasks keep enough scope to be actionable.

Legend: [x] done · [ ] planned · sub-lists split done vs. remaining for partial items.

Within each phase, remaining [ ] items are listed in rough priority order: making the existing flow engine reachable and persistent precedes new feature breadth.

Phase 0 — Workspace and platform

• Root orchestrator repo with app, index and docs as submodules
• make init bootstrap: secrets generation, per-stack .env propagation, shared proxy docker network
• Layered compose (compose.yml → compose.dev.yml → compose.local.yml) for both stacks, one Traefik serving ${DOMAIN}, app.${DOMAIN}, api.${DOMAIN}
• Design token contract: root DESIGN-GUIDELINES.md, per-repo DESIGN.md, byte-identical token blocks verified by make design-check
• CI on Codeberg (Forgejo Actions): pre-commit, backend tests, Playwright, compose smoke

Phase 1 — Backend: management

Python, optimised for development speed. Owns the graph structure, persistence and the external interfaces. See docs/architecture/structure.canvas → Backend – Management.

• FastAPI + SQLModel + Alembic + Postgres base with JWT auth and user management
• Flow engine prototype in backend/app/flow/: Node / Pipeline / StateBackend (memory + Redis) / PipelineController with watchfiles hot-reload
• Node types: HTTP, MQTT, InfluxDB, Delay, MLP
• Make app/flow an importable package (__init__.py, absolute app.flow.* imports) — nothing can consume it until this lands
• Typed, serializable node I/O: declared input/output schemas (Pydantic), JSON-serializable messages with explicit binary codecs, no pickle in the state backends
• Secrets/credentials store for node integrations managed via the API/UI; .env bootstrap-only
• Persistence models for flows, nodes, edges and node source, replacing the filesystem-and-hot-reload prototype
• REST + WebSocket API over the engine: create/read/update flows, run, stream results
• Dependency-loop detection and graph validation surfaced as API errors
• Redis / MQTT broker / InfluxDB compose services (blocked on the API wiring above — no runtime path reaches them today)
• Git-based versioning of the in-memory flow database
• Import/export of a flow as human-readable code plus a JSON structure
• Per-input/-output discretization interval setting
• Alert / notification handler
• Test nodes: a small node dragged onto an existing one, smoke or unit, blocking deployment on failure
• User management scoped per flow and per data set
• Plugin system for third-party node types
• LLM interface for natural-language flow authoring

Phase 2 — Backend: processing

Rust, optimised for throughput. Executes nodes and distributes them across workers. See docs/architecture/structure.canvas → Backend – Processing.

• Parallel invocation of stateless nodes over independent input sets, to keep I/O delay minimal (stateful I/O nodes keep serializing via the synchronous mechanism)
• Extract node execution from the Python prototype into a Rust engine
• Worker distribution and load balancing across capable devices
• Input/output validation at the node boundary
• Data aggregation and discretization

Phase 3 — Frontend: admin view

React + Vite, primarily desktop but usable on mobile. See docs/architecture/structure.canvas → Frontend – Admin View.

• Dashboard SPA shell: TanStack Router, floating frosted sidebar, auth flows, generated OpenAPI SDK
• Node canvas (@xyflow/react) showing nodes and connections
• Tab-style view of atomic flows, with a floating dock
• Embedded code editor (Monaco) for node source
• Device assignment per node, selectable from compatible devices
• Test-node affordance on the canvas
• User management screens
• Mobile view for minor adjustments (PWA via vite-plugin-pwa)

Phase 4 — Frontend: dashboard view

Shares components with the admin view. See docs/architecture/structure.canvas → Frontend – Dashboard View.

• User-defined dashboard layout with edit and view modes
• Responsive layout targeting wall panels, mobile and desktop
• Per-device view

Phase 5 — Website and docs

• Marketing site with a live node-graph demo, shared design system
• Published documentation site fed from the docs submodule
• Umami analytics configured (the site still ships the placeholder script)