Skip to main content

Which node kinds the flow editor may offer

GET 
/api/flows/node-types

Read from the RUNNER's own handler registry, so the editor cannot advertise a node the runner will not run. The palette used to keep a hand-written copy of this list and it drifted: twelve kinds were draggable while no handler existed for any of them, and a flow saved with one of them stopped dead at its first node.

THREE lists, because "can run it" and "may create one" stopped being the same question when the node catalogue rebuild began (defter 51 §K12):

  • available — every kind the runner has a handler for. The node inspector's type picker reads this, so a tenant's existing node stays editable even when its kind is no longer handed out.
  • offered — the narrower set the palette may PLACE into a new flow while the catalogue is being redesigned. Always a subset of available; the server intersects the two so a test set can never name a kind the runner cannot run.
  • coming — empty, on purpose. The fourteen phantom kinds were deleted rather than reclassified: the catalogue is being rebuilt from a taxonomy not yet settled, so republishing the old list as a roadmap would advertise a plan already abandoned. The key stays so the contract does not change when the real roadmap arrives.

conditions and actions travel with the list for the SAME reason, and after the same mistake one level down: the condition form kept its own operator vocabulary (greater_than, equals, is_set) that the runner has never recognised, and wrote it into a flat config.field/operator/ value where the runner reads config.condition. Both halves fail silently and identically — a missing condition object evaluates false, and an unknown operator falls through to false — so every branch built on the canvas took the same exit forever while looking correct on screen.

Responses​

The node kinds this deployment can run, and their vocabularies.