gatewayFanOut

Decision gateways need 2+ on the in or out side; parallel pass-throughs flagged separately.

Why it matters

A decision gateway (exclusive, inclusive, complex, event-based) exists to either split a single token into multiple branches or merge multiple tokens into one. A diverging gateway with one outflow does no splitting; a converging gateway with one inflow does no merging — in both shapes the gateway acts as a pass-through shape that adds visual noise without semantic value. Worse, the engine still pays the synchronization cost of a gateway, slowing every execution that flows through it.

What triggers it

For every `<exclusiveGateway>`, `<inclusiveGateway>`, `<complexGateway>`, and `<eventBasedGateway>`, the validator counts incoming and outgoing flows. The rule fires when the maximum of (incoming, outgoing) is exactly 1 — i.e. the gateway is neither splitting nor merging on either side. Parallel-gateway pass-throughs are flagged by a separate rule (`conditionalFlowOnParallelGateway`) because their semantic is different.

How to fix

Three options depending on intent: (1) if the gateway is meant to mark a future decision, delete it and re-add when the decision actually exists; (2) if the diverging gateway has only one branch because the other branch was deleted in a refactor, restore the missing flow or convert the upstream/downstream chain into a direct sequence flow; (3) if the gateway is documentary (e.g. "decision point" annotation), use a `<textAnnotation>` linked by an `<association>` rather than a gateway shape — semantically free, visually equivalent.

Examples

<process id="P">
  <startEvent id="s" />
  <exclusiveGateway id="gw" name="Approved?" />
  <task id="t" name="Process" />
  <endEvent id="e" />
  <sequenceFlow id="f1" sourceRef="s" targetRef="gw" />
  <sequenceFlow id="f2" sourceRef="gw" targetRef="t" />
  <sequenceFlow id="f3" sourceRef="t" targetRef="e" />
</process>

<process id="P">
  <startEvent id="s" />
  <task id="t" name="Process" />
  <endEvent id="e" />
  <sequenceFlow id="f1" sourceRef="s" targetRef="t" />
  <sequenceFlow id="f2" sourceRef="t" targetRef="e" />
</process>