Roadmap

Known intentions, honestly staged. Items here were consciously deferred during design — the architecture anticipates several of them — rather than overlooked. Nothing on this page is a promise of timing.

Planned

Shared recording stores (v2 headline). A flight-recorder-store config node representing a named recording that multiple capture nodes feed — several inline recorders and a tap all writing one black box, dumped from one place. The architecture has been ready since v0.1: the store engine is capture-source-agnostic, nodes attach/detach with reference counting, persistence is keyed by store id, the registry is the attachment seam, and the control node's target field was designed to gain a "recorder store" option. What remains is the config node itself and the editor UX.

Integration tests against real Node-RED. The harness suite (430+ checks) stubs the runtime, which leaves the hook event shapes as a believed-not-proven seam. A thin integration layer using node-red-node-test-helper with Node-RED as a devDependency would prove it on every run — paired naturally with a GitHub Actions workflow running npm test and attaching a packed .tgz to each push.

Recipes collection. A guide page of worked patterns beyond Home Assistant: incidents into MariaDB/Postgres with a recommended relational schema (incidents + records tables, indexed for Grafana), catch-node → control for inline error dumps, scheduled status reports, dashboard embedding of HTML reports. The database recipe is the headline — the hard part of "incidents in a database" is schema design, and that's solvable in documentation with zero dependencies.

Considered

Webhook destination on the report node. POST the incident (raw or rendered) to a configured URL — one zero-dependency integration reaching everything with an inbound webhook (n8n, Discord/Slack, collectors). Held because a downstream http request node already does this; the value-add is convenience plus per-delivery results in msg.report.files, which may yet justify it.

Sidebar elision option. A "max timeline rows in message output" setting rendering first/last N rows around a self-documenting … 32 rows elided … rule — full timeline always in files. Addresses the debug sidebar's display cap more elegantly than the current documented workaround. Waiting on evidence that the debugMaxLength guidance isn't enough.

Events activity log. An append-mode file destination where recorder events become one-liners — a rolling activity journal beside the incident archive. Different write semantics (append, rotation) than the current one-file-per-incident model, hence parked rather than bolted on.

Deluxe scope picker. The flow picker shipped in 0.2; a tree/checkbox picker for individual nodes (grouped by flow, searchable) is the remaining scope-UX step.

Parked

Per-source sampling ("record 1 in N from this source") for firehose-adjacent scopes — summary mode and muting cover current needs. Progressive record truncation (per-property trimming instead of the summary fallback) — deterministic summaries have proven adequate. Enriched JSON export (the internal report model — computed anomalies, humanized fields — as a format) — deliberately unfrozen so the renderers can evolve; raw JSON is the analysis contract. Editor sidebar viewer — a browsing UI inside the Node-RED editor; a different engineering species (plugin API, websockets, client state), and the report/file path serves the need meanwhile.