Draw resolves: and generates: in the intent Glue & Outputs diagram

[delchev]

Fixes #6954.

The problem

renderGlue() in editor-intent/js/intent-diagrams.js drew a card per form, report, notification, schedule, integration, inbound arrival, outbound departure and roll-up - and knew nothing about resolves: or generates:; neither word appeared in the file. For a model whose automation lives in those two, the BPMN correctly showed only the genuinely human steps and the diagram showed nothing else, so the picture said the model did almost nothing.

The fix

Two categories on the existing card + edge pattern:

• resolves: - one card per lookup, edged to the record it runs on, labelled with the moment and the to-one it fills (on create • sets driver), plus a second dashed reads edge from the register it reads. It is the one card with two edges, hence the new optional reads on a category descriptor.
• generates: - one card per create-from, edged to its source (or, when the source is foreign and therefore has no local node, to the local target it mints), labelled with its target, its trigger with the status guard, and its cardinality: → Declaration / on transition Status == 2 • append. The cardinality is the point - two appending rules on one transition, side by side, is a defect that is obvious in a picture and nearly invisible in YAML.

normalize() defaults both collections like the other twelve. cardLabel now accepts an array of detail lines for a card whose binding needs two; a string detail renders exactly as before, so a model declaring neither construct is byte-identical to today.

intent-diagrams.js is the shared renderer (window.IntentDiagrams), so the Builder shell gains the cards from the same change.

Test

IntentDiagramGlueIT - a browser test, because only a browser can catch this: the renderer is framework-free JavaScript over mxGraph, so every service behind it stays green whether or not a card is drawn. Its fixture (a fine identifying its driver from a vehicle-assignment register, then minting a declaration per identification and offering a notice on demand) is written straight into the workspace rather than cloned from a sample repository - the assertions are about the renderer, so the intent that feeds it belongs beside them, and the test needs no external repository merged first. It asserts, inside the Glue & Outputs section specifically, the lookup card + sets driver + the register node + the reads edge, the appending create-from's target/trigger/append badge, and the button-only one's button.

Verified locally, headless: IntentDiagramGlueIT green, formatter:validate clean on both touched modules.

Noticed while in here, deliberately not changed

• ICON.rollup = 'sap-icon--sum' does not exist in the shipped fundamental-styles 0.38.0 icon font, so every roll-up card's badge renders as nothing. Pre-existing; a one-word fix but not this issue's scope.
• eventOf() handles onCreate/onUpdate/onDelete and the step axis, but not onTransition or onPhase - which notifications: / integrations: / outbound: also accept. Such a card today gets an empty verb and no edge at all (eventEntity returns null), so it floats unlabelled. Same family as this issue; fixing it would change the rendering of models that use those bindings, which is why it is reported rather than folded in.
• The other undrawn collections, for completeness: expansions, settlements, actions, postings, transitions, posts, aggregates, widgets.

🤖 Generated with Claude Code