Publish the documentation site: docs.fluksio.com

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

docs/concepts/values.md

@@ -0,0 +1,67 @@
+# 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.
+
+```python
+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:
+
+```python
+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:
+
+```json
+{"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](runs.md).
+
+## See also
+
+- [Flows, nodes and messages](flows.md) — how the graph is built from the names
+- [Keeping state in a flow](state.md) — a value a node reads *and* writes
+- [Writing node code](../code/nodes.md) — the practical side