# 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

- [x] Root orchestrator repo with `app`, `index` and `docs` as submodules
- [x] `make init` bootstrap: secrets generation, per-stack `.env` propagation, shared
      `proxy` docker network
- [x] Layered compose (`compose.yml` → `compose.dev.yml` → `compose.local.yml`) for both
      stacks, one Traefik serving `${DOMAIN}`, `app.${DOMAIN}`, `api.${DOMAIN}`
- [x] 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*.

- [x] FastAPI + SQLModel + Alembic + Postgres base with JWT auth and user management
- [x] Flow engine prototype in `backend/app/flow/`: `Node` / `Pipeline` / `StateBackend`
      (memory + Redis) / `PipelineController` with `watchfiles` hot-reload
- [x] 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
- [ ] Connector node contract: declared I/O schemas, UI-driven credential and
      setup flow, polling/discretization behaviour, health reporting, packaging
      metadata — plus an authoring guide and skeleton repo. Device-specific
      nodes are written against it as external plugins; the registry follows
      later
- [ ] 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
- [ ] 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*.

- [x] 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

- [x] 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)