Implemented confi snapshots

docs/FUNCTIONAL_SPEC.md

@@ -279,7 +279,7 @@ copy/paste.
 |----------|-------|
 | Triggers | Button press, threshold crossing, value change, timer/interval, panel loop, On-open / On-close lifecycle |
 | Logic | AND gate, If (then/else), Loop (count or while) |
-| Actions | Write to signal/variable, Delay, Log; Accumulate / Export-CSV / Clear for in-memory data arrays |
+| Actions | Write to signal/variable, Delay, Log; Accumulate / Export-CSV / Clear for in-memory data arrays; Apply config / Read config / Write config / Create config / Snapshot config (see §11) |
 | Dialogs | Info and Error pop-ups; Set-point prompt (asks the user for a number and writes it) |
 
 **System helpers in expressions:** `{sys:time}` (epoch seconds) and `{sys:dt}` (seconds
@@ -296,6 +296,12 @@ managed through the REST API.
 
 - Triggers include *cron* schedules and signal *alarm*/threshold conditions.
 - A **Lua** block provides custom logic; results are written back to signals.
+- **Apply / Read / Write / Create config** action nodes drive the configuration manager
+  (§11): *Apply config* writes every value of a chosen instance to its bound signals
+  (audited); *Read config* reads one parameter's value into a target signal or variable;
+  *Write config* stores a value into a parameter (creating a new instance revision); *Create
+  config* makes a new instance for a set, optionally seeded from another instance. Both
+  mutating nodes are audited.
 - Each graph can be enabled/disabled independently; saving reloads the engine live.
 - Editing is gated by the logic-edit restriction (§2).
 
@@ -305,7 +311,7 @@ managed through the REST API.
 
 - Interfaces are saved to the server in XML format and are available to all connected clients.
 - Per-panel access rules and panel-folder placement are stored server-side (sidecar JSON).
-- Saved versions are retained; a panel's version history can be listed, tagged and promoted.
+- Saved versions are retained; a panel's version history can be listed, tagged, viewed, promoted, forked and diffed — the same git-style versioning shared by all versioned documents (§12).
 - Export/Import allows local file exchange of XML files.
 - The XML schema records: interface kind (panel/plot) and split layout, widget type,
   position, size, signal bindings, all property values, local variables, and panel logic.
@@ -345,7 +351,93 @@ When the server has archive access configured:
 
 ---
 
-## 11. Non-functional Requirements
+## 11. Configuration Manager
+
+The **Configuration manager** (opened from the View-mode toolbar) manages three kinds of
+versioned documents, on **Sets**, **Instances** and **Rules** tabs, in a full-screen modal.
+
+**Configuration sets** are schemas: an ordered list of typed parameters, each binding a
+target signal. Parameters can be organised into **groups** and **subgroups** via a
+drag-and-drop tree.
+- A parameter's **type** (number, integer, boolean, string, enum, array/waveform) and its
+  unit/range/enum values are auto-derived from the bound signal's metadata when available;
+  the type is read-only.
+- Each parameter may declare a **default**, a **mandatory** flag, and **min/max** /
+  **enum** constraints.
+- Sets can be **exported / imported** as JSON.
+
+**Configuration instances** assign concrete values to a chosen set's parameters.
+- The editor renders the right control per type (number input, enum/boolean combo, and a
+  waveform editor with live sparkline, table editing, CSV import and a pop-out plot for
+  arrays); empty fields fall back to the parameter default.
+- Validation mirrors the backend (required-but-unset, out-of-range, wrong type, bad enum)
+  and is surfaced inline with hover detail.
+- **Apply** writes every value to its target signal and reports a per-parameter
+  applied / failed / skipped result.
+- **Snapshot** (⎙ in the Instances tab) captures the *current live value* of every target
+  signal of a chosen set into a new instance — an optional label, otherwise an auto name. This
+  records "what the hardware holds right now" as a reusable configuration.
+- **Diff vs current** compares a stored instance (resolved with defaults) against the current
+  live signal values, so an operator can see how the saved configuration differs from what the
+  system currently has.
+
+The Sets and Instances tabs support the shared version history (§12): view, fork and promote
+revisions, plus a **structural diff** between any two revisions (per-parameter added / removed
+/ changed / unchanged).
+
+**Validation / transformation rules** (Rules tab) attach **CUE** logic to a set. Each rule is
+CUE source describing constraints and/or derivations over the parameter values: a field like
+`voltage: >=0 & <=24` validates a value, while a concrete derivation like
+`power: voltage * current` computes one. When an instance of the bound set is saved, every
+rule runs — a failed constraint **blocks the save** and surfaces the violation, and derived
+values are written into the stored instance. The rule editor is a CUE-aware code editor with
+syntax highlighting and autocomplete (parameter keys, target signal names, and CUE
+keywords/types via Ctrl+Space); a live panel re-evaluates the rule against the set's default
+values on every keystroke, showing compile errors, violations, or the derived values. Rules
+are versioned like the other documents, with a side-by-side / unified source diff, and every
+create / edit / delete is audited. (A full CUE language server is intentionally out of scope:
+it does not fit the no-dependency, single portable-binary design.)
+
+**Automation:** both the panel-logic (§6) and control-logic (§7) editors expose **Apply
+config**, **Read config**, **Write config**, **Create config** and **Snapshot config** action
+nodes. *Apply config* applies a chosen instance exactly like the Apply button; *Read config*
+reads a single numeric parameter into a target signal or variable; *Write config* stores a
+value into a parameter, creating a new instance revision; *Create config* makes a new instance
+for a set, optionally seeded from another instance; *Snapshot config* captures every target
+signal's current live value of a set into a new instance (like the ⎙ Snapshot button). The
+mutating nodes are audited.
+
+**Config Selector widget:** a panel widget that lets an operator pick which configuration a
+flow operates on at run time. It lists the instances of a chosen set — all of them or a
+defined subset — in a combo and writes the selected instance id to a panel-local string
+variable. The panel-logic Apply / Read / Write nodes can take their instance "From variable"
+(reading that id) instead of a fixed instance, so the operator's choice drives the flow.
+Control-logic nodes use fixed instances only (their variables are numeric).
+
+---
+
+## 12. Version History & Diff
+
+All versioned documents — panels, synthetic signals, control-logic graphs, and
+configuration sets/instances — share one git-style version model and a common history
+pane:
+
+- A **vertical version tree** lists every revision (one node each); the **current**
+  (executed) revision is filled, the **viewed** revision is enlarged, and unsaved edits show
+  a dashed connector.
+- **View** loads any past revision read-only into the editor — viewing alone is not an edit
+  and does not mark the document dirty; saving from a viewed revision creates a new revision
+  on top (history is never destroyed).
+- **Fork** copies a revision into a brand-new document (version reset to 1).
+- **Promote** re-saves an older revision as a new current revision.
+- **Diff** compares two revisions, defaulting to *current-vs-selected*, shown either
+  **unified** or **side-by-side**. Panels, synthetic and control-logic use a generic line
+  diff of the serialized document; configuration sets/instances use a richer per-parameter
+  structural diff.
+
+---
+
+## 13. Non-functional Requirements
 
 | Requirement | Target |
 |-------------|--------|