sad-mcp 1.0.2 → 1.0.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sad-mcp",
-  "version": "1.0.2",
+  "version": "1.0.3",
   "description": "MCP server for Software Analysis and Design course materials at BGU",
   "type": "module",
   "bin": {

package/skills/bpmn-render/SKILL.md

@@ -171,26 +171,47 @@ Plain double circle, NO icon inside:
 
 ## Arrow Routing
 
-**Arrows must never be ambiguous.**
+**Arrows must never be ambiguous. This section is CRITICAL for diagram quality.**
 
-### Orthogonal lines ONLY
-- **NO diagonal or straight-across lines.** Every arrow segment is either horizontal or vertical.
-- Use SVG `polyline` or `path` with L commands (not straight lines between arbitrary points).
-- Break the line as many times as needed to route around elements. A single arrow may have 3, 5, or more segments.
-- Example: to go from a task on the right to a task below-left, route: horizontal right → vertical down → horizontal left.
+### Orthogonal lines ONLY — NO exceptions
+- **EVERY arrow is built from horizontal and vertical segments ONLY.** No diagonal lines anywhere.
+- Use SVG `<polyline points="x1,y1 x2,y1 x2,y2 x3,y2">` — each point shares one coordinate with the next (same x = vertical, same y = horizontal).
+- **Test**: For every two consecutive points in a polyline, either `x1==x2` (vertical segment) or `y1==y2` (horizontal segment). If neither — it's diagonal and WRONG.
+
+### Routing algorithm for cross-lane flows
+When a flow goes from one lane to another (e.g., gateway branch dropping to a lower lane):
+1. Exit the source element horizontally (left or right)
+2. Run horizontally to a clear vertical channel (at least 20px from any element)
+3. Drop/rise vertically to the target lane's y-coordinate
+4. Run horizontally to the target element
+5. Connect to the target element
+
+**Never draw a single straight line between elements in different lanes** — always use this H→V→H pattern (or V→H→V if needed).
+
+### Vertical channels
+- Reserve 2-3 vertical "channel" x-positions between task columns for routing cross-lane flows
+- Each channel is a fixed x-coordinate used by vertical segments
+- Offset parallel vertical flows by at least 30px so they don't overlap
 
 ### No overlapping arrows
-- **At least 30px between parallel flow lines.** If two arrows run side by side, offset them vertically or horizontally.
-- When arrows must cross, make the crossing perpendicular (one horizontal, one vertical) so it's visually clear.
+- **At least 30px between parallel flow lines.** If two arrows run side by side, offset them.
+- When arrows must cross, make the crossing perpendicular (one horizontal, one vertical).
+- **Data association lines** (dashed) must also be routed orthogonally and must not cross over sequence flow lines. Route them around tasks, not through the flow area.
 
 ### Separate connection points
 - **NEVER attach two arrows to the exact same point.** Multiple arrows CAN connect to the same side/edge of a shape, but they must be spaced apart along that edge (e.g., 2-3 arrows on the top edge of a task, each at a different x-coordinate with at least 15px between them).
 - For gateways with multiple outgoing branches: use different edges of the diamond (top, bottom, left, right) OR spread multiple connections along one edge.
 - For tasks: use all 4 edges (top, bottom, left, right) and spread connections along each edge as needed. A single edge can have 2-3 connection points.
 
+### Data store and data object placement
+- Place data stores/objects **directly above or below** the task they connect to, in the gap between elements — NOT at the lane edges.
+- Data association lines should be short and direct (ideally a single vertical segment).
+- If a data store connects to multiple tasks, duplicate it near each task (see rule 4 above).
+
 ### Labels
 - Labels (כן/לא) near the gateway, not at path end.
 - Flow labels must not overlap other elements.
+- Place labels on the horizontal segment of the arrow, not on the vertical drop.
 
 ## Typography & Hebrew