stroblmeandClaude Opus 5
d12c81c8a0
A zensical site under docs/, served by a new `docs` compose service behind Traefik, built with --strict in CI. Same pattern the sibling n3xd workspace uses. Getting started splits the way the landing page does — one path is `pip install fluksio` and a training script, the other is a Docker stack and an afternoon in the browser — because the two audiences will not spend the same amount of time. Everything after that is shared: the concepts, the web interface (app and portal), the CLI and the API, and a reference for node types, payload types and configuration. The three flow guides move here from the docs submodule rather than being copied, so there is one version of them. Styling mirrors DESIGN-GUIDELINES.md: the app's token palette remapped onto Material's variables in both schemes, Inter, the 16px panel radius, and the one terracotta accent spent on the facility lane of the audience split. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M7Xv3cJEW5c8AXxn2hoojV
2.5 KiB
Where a node's values come from
A node function is called with one argument per thing it needs, and every one of them is declared somewhere you can see. There are two kinds.
Ports: what the graph carries
A port binds to a message name. Whatever last published that message is the value the node is called with, and the wiring follows from the name rather than from a line somebody drew.
def process(reading, setpoint):
return {"heat": reading < setpoint}
with reading and setpoint as inputs and heat as an output.
Settings: constants of this node
A setting is a value that belongs to this node's code rather than to the graph: how many retries, which unit, how long to wait. It is typed into the node's Settings section, stored with the flow, and arrives as an argument like a port:
def process(reading, unit="C"):
return {"shown": reading if unit == "C" else reading * 1.8 + 32}
Because both arrive by name, a setting cannot share a name with a port — the node reports it rather than picking one.
Settings are part of the flow document, so changing one is an edit that gets published, not something that happens at runtime. A value that should change while the flow runs is a message, not a setting.
There is no global and no flow context. A constant several nodes need is a
node that provides it: one place it is set, an ordinary message out, and every
consumer visibly downstream of it.
Flow inputs: what arrives from outside
Some messages are not computed by any node in the flow — a dashboard control writes them, the API publishes them, a batch run passes them in. Declare those as the flow's inputs, with the value they start from:
{"inputs": [{"spec": {"name": "setpoint", "dtype": "float"}, "initial": 21.0}]}
Without that, the node reading setpoint waits for something nothing provides,
and the canvas says so. With it, the flow starts from 21.0 and whatever writes
the message afterwards takes over.
The canvas draws each one as a labelled endpoint feeding the nodes that read it, the same way it draws a dashboard tile or another flow — so a value never appears from nowhere. They are edited in the flow's own panel.
A batch flow's inputs are also its run parameters, and its outputs name what a run reports as its result; see Runs.
See also
- Flows, nodes and messages — how the graph is built from the names
- Keeping state in a flow — a value a node reads and writes
- Writing node code — the practical side