Rewrite ROADMAP and NOTEPAD from the real requirement sources

ROADMAP.md was an empty scaffold carried over from another project, pointing
at a docs-private/architecture/ directory that does not exist. Rebuild it
from org/README.md and org/structure.canvas as five phases matching the
intended component split, and seed NOTEPAD.md with the findings from the
architecture survey (flow package not importable, tests outside tests/, CI,
chart tokens).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

ROADMAP.md

@@ -1,11 +1,89 @@
 # Roadmap
 
 Implementation strategy and record of existing/planned features. Completed items are
-terse checklists - technical detail lives in the architecture docs (`docs-private/architecture/`). Remaining tasks keep
-enough scope to be actionable.
+terse checklists — the requirement detail lives in `org/README.md` (software requirements,
+evaluated tooling, hardware) and `org/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: correctness
-and robustness of the existing modeling workflow (especially after edits/imports) precede
-new feature breadth.
+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 `fluksio`, `website`, `docs`, `org` 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 `org/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
+- [ ] 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
+`org/structure.canvas` → *Backend – Processing*.
+
+- [ ] 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 `org/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 `org/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)