[iliyan-velichkov]

Cause

BpmnIntentGenerator gave every start event the fixed id start (START_ID), and every step becomes a BPMN element whose id is the step's name. A step named start produced two elements with one id: Generate succeeded, publish failed with cvc-id.2: There are multiple occurrences of ID value 'start', and the .bpmn stayed FAILED with the process never starting.

Change

Option 1 of the issue (generator, no author-facing rule), narrowed to avoid its trade-off:

• The start event's id is chosen per process (startEventId): start unless an element of the process already carries it (authored and synthesized steps, parallel joins, the abort then step), then startEvent (startEvent2, ... if that is taken too).
• The linear chain, the <startEvent>, its outgoing flow and the diagram layout all use the chosen id. nodeSize takes it too, so a step named start is drawn as a task, not as the event's 30x30 circle.
• Only a colliding process changes. Every other generated .bpmn stays byte-identical, so no existing project churns on regeneration, and the ITs that assert sourceRef="start" are unaffected.

Nothing reads the generated start event by id: the hits for id="start" outside the generator are hand-written BPMN fixtures (and IntentResilienceBpmnContractTest, a hand-written copy of the generated shape).

Not addressed here, same family: the abort subprocess's start event is <Process>AbortStart, which an author could also claim by naming a step exactly that. It is prefixed by the process id, so it never hits by accident the way start did.

Verification

• StartEventIdBpmnTest (new): every id in the document unique, startEvent -> start flow, the step drawn as a task, the fallback also moving aside, and a non-colliding process keeping <startEvent id="start">. Against the unfixed generator it fails with duplicate id [start].
• engine-intent unit suite: 1796 tests, green.
• IntentEngineIT (83), IntentEmissionCoverageIT, IntentSetManyIT: green. IntentSetManyIT's trigger step is named start again (it had been renamed to begin to dodge this in intent: one setter step writes several members of one record in one statement - set: { slotKey: null, Status: DONE } (#8042) #8055), so it now generates, publishes, deploys and runs the colliding shape; no Failed to deploy BPMN in the log.
• mvn -T 1C formatter:validate green with the formatter cache wiped.
• Not run: the full IT suite, PostgreSQL. The release javadoc build was not needed, since only private members gained Javadoc.

Fixes #8058

🤖 Generated with Claude Code