feat(automation): add a config connector that names reusable variables

[LeadcodeDev]

Stacked on #533 — review that one first; this diff shrinks to its own commit once #533 merges.

What this adds

A workflow had no way to declare a value once and reuse it. The same customer id, base URL or retry limit had to be written into every connector that needed it, and changing it meant hunting through the graph.

flow.config takes a JSON object of named variables and produces it as its output.

Why that is the whole implementation

Two pieces already existed, and this connector is the hinge between them:

• the engine resolves {{ }} expressions inside a connector's config before executing it, so a variable may itself be an expression — {{ trigger.payload.customer_id }} is already resolved when this connector runs;
• a connector's output is already readable downstream as {{ connectors.<id>.output.<path> }}.

So the executor is a handful of lines, and every connector after it in the graph reads the result through machinery that was already there. No change to the expression engine, the run engine, or the frontend.

Nothing changes in the webapp, and nothing should. The editor renders whatever the catalogue describes, and "no connector kind appears anywhere in the frontend" is a standing invariant here. Adding this node to the editor's palette required zero frontend code.

Error behaviour worth a look

variables resolving to anything but an object fails, with a message naming what arrived instead ("variables must resolve to a JSON object, got an array"). Someone who writes a list of variables rather than a map gets told, instead of being handed an output that nothing downstream can address.

A comment corrected, not bumped

The doc comment on flow_descriptors said "the two flow-control connectors" and there are now three. The count is dropped rather than incremented — it was only ever true by accident, and a number in prose beside a list is a fact that rots on the next addition.

Verification

cargo fmt --all -- --check	clean
cargo clippy --workspace --all-targets -- -D warnings	0 warnings
cargo test -p mestier-core --lib	1024 passed, 0 failed

The tests were verified non-hollow: making the executor return Value::Null instead of the variables object fails both the unit test and the registry dispatch test. The catalogue/registry completeness test (every_catalogue_kind_has_an_implementation_and_vice_versa) also failed at the right moment during development — after the descriptor was added but before the registry was wired — which is what proves the registration is real rather than assumed.

Closes #534

Also here: deleting a connection (second commit)

Removing a wire meant deleting one of the nodes it joined, or knowing that React Flow's keyboard delete applies to a selected edge. Neither is discoverable, so a mistaken connection stayed.

Hovering a connection now puts a trash button at its midpoint, over a transparent path widened to twenty pixels so the wire is catchable without precision aiming. Selection reveals it too — see the accessibility note below. It routes through the same onEdgesChange path the keyboard delete already took, so the graph is rebuilt and the editor marked dirty by the code that handled edge removal all along — no second way to remove an edge, and no second place for that logic to drift.

Every edge is deletable now, including the one leaving a trigger. That was forbidden while the canvas invented those edges and no user could have drawn them; now that a trigger is a node you wire by hand, being unable to unwire it would be the odd rule. A trigger left pointing at nothing is refused at save, by name — which is where that check belongs.

Verified non-hollow: forcing the trash button to never render makes the deletion test fail, while its companion ("no delete affordance until the connection is selected") passes either way by construction and is kept as a guard, not as evidence.

Re-verified after both commits: 441 automation tests pass, pnpm check clean on 545 files, tsc at main's 28-error baseline, build clean.

Two things the hover version had to get right

BaseEdge draws an interaction path of its own, so the first attempt stacked two hit areas and events landed on the wrong one. Its interactionWidth is now zero and this component owns the single layer carrying the handlers.

Hover alone would have put the button out of reach of a keyboard, which can focus an edge but cannot point at one. Selection still reveals it, so the affordance is not mouse-only. That is also why the interaction path suppresses noStaticElementInteractions rather than answering it: the path is a hit area, the control is the labelled button, and the button stays reachable without a mouse. The suppression carries that reason inline.

A config node's variables now reach the editor (third commit)

Found by using it: the editor listed the config node under "Données disponibles" and then offered customer_id and retry_limit beneath it — the descriptor's illustrative output_example. Those are names the author never wrote and no run will ever produce, so every path taken from that list resolved to nothing. Worse than an empty branch, because it looked like an answer.

For a config node the available data is known at edit time: it is exactly what the author typed. Nothing else in the catalogue is like that — an HTTP response exists only once the call has been made.

ConnectorDescriptor now says so. output_mirrors_field names the config field a connector's output is a copy of — Some("variables") for flow.config, None everywhere else — and the editor reads that declaration to show the connector's own configured value.

Declaring it rather than special-casing the kind is the point. "No connector kind appears anywhere in the frontend" is a standing invariant here, and a if (kind === 'flow.config') in the canvas would have broken it for one node's benefit. As it stands, the next connector whose output mirrors its input gets this behaviour by filling in a field, without the editor changing at all.

Verified non-hollow: removing the mirror lookup makes the new test fail on the configured name it can no longer find.

Re-verified across the branch: cargo clippy 0 warnings, 1534 Rust tests pass, 443 automation frontend tests pass, tsc at main's 28-error baseline, pnpm check clean on 545 files, build clean.

An empty branch now says why (fourth commit)

A connector always rendered as an expandable branch, so one exposing nothing gave a chevron that opened onto nothing. The trigger already had the opposite treatment — a sentence explaining it is not configured — and a connector deserved the same.

A connector with no data to offer is now a notice: "Ce connecteur n'expose aucune donnée pour l'instant." A config node with no variables typed yet is exactly that case, and it is the one that made the gap visible.

While doing it: a notice rendered its message alone, which was legible while the trigger was the only thing that could produce one. With several connectors upstream it would have printed the same sentence repeatedly with nothing to tell them apart, so a notice now names what it is about.

The upstream/sibling test moved from querying a button to querying text — a connector exposing nothing is no longer a button at all, and what that test pins is which connectors appear, not the element they render as.

445 automation tests pass; tsc at baseline; pnpm check and build clean.

[codspeed]

Congrats! CodSpeed is installed 🎉

🆕 11 new benchmarks were detected.

You will start to see performance impacts in the reports once the benchmarks are run from your default branch.

Detected benchmarks

• client_ip_x_forwarded_for: 4.6 µs
• client_ip_x_real_ip: 3.3 µs
• inject_headers_allowed: 4.5 µs
• inject_headers_blocked: 4.5 µs
• client_ip_fallback_only: 4.3 µs
• ip_v4_key: 4.2 µs
• decode_realistic_token: 37 µs
• extract_claims: 38.1 µs
• client_ip_forwarded_header: 4.2 µs
• ip_v6_key: 4.2 µs
• organization_key: 4.2 µs

---

[NathaelB]

🚀 Preview deployed: https://pr-535.mestier.fr

Synced revision <no value>.