sad-mcp 0.1.33 → 1.0.1

package/package.json

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

package/skills/bpmn-render/SKILL.md

@@ -27,6 +27,8 @@ You have an approved structural model (the JSON below). Render it as a single se
 
 ## Gateway Marker Styling
 
+**CRITICAL: The marker MUST match the gateway `type` field from the JSON model.** XOR → X marker (amber). AND → + marker (green). OR → O marker (blue). If the JSON says `"type": "XOR"`, the diamond MUST show an X, NOT a +. Getting this wrong makes the diagram factually incorrect.
+
 Gateway markers must be clean and visually prominent. Use SVG paths, not text characters:
 
 ### XOR Gateway — bold X
@@ -171,11 +173,24 @@ Plain double circle, NO icon inside:
 
 **Arrows must never be ambiguous.**
 
-- Orthogonal (right-angle) routing preferred
-- At least 30px between parallel flow lines
-- Cross-lane flows: clear vertical drops/rises
-- Labels (כן/לא) near the gateway, not at path end
-- Flow labels must not overlap other elements
+### 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.
+
+### 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.
+
+### Separate connection points
+- **NEVER attach two arrows to the same point on a task/gateway.** If a task has 2 incoming arrows, connect them to different spots on the border (e.g., one to the top edge, one to the left edge). Same for outgoing arrows.
+- For gateways with multiple outgoing branches: use different edges of the diamond (top, bottom, left, right) for different branches.
+- For tasks: use the 4 edges (top, bottom, left, right) to spread out connections. Never stack two arrows on the same edge point.
+
+### Labels
+- Labels (כן/לא) near the gateway, not at path end.
+- Flow labels must not overlap other elements.
 
 ## Typography & Hebrew
 
@@ -213,7 +228,8 @@ Single self-contained HTML file:
 - [ ] External participants are separate pools with message flows
 - [ ] Empty pools have NO elements inside — message flows connect to pool border
 - [ ] Every pool has complete flow (start → ... → end) — except empty external pools
-- [ ] Every gateway has the correct type marker (bold X/+/O via SVG paths) — no text inside
+- [ ] Every gateway marker matches its JSON `type`: XOR→X (amber), AND→+ (green), OR→O (blue). Verify each one individually.
+- [ ] No text inside gateway diamonds
 - [ ] Every data store appears as a cylinder with data associations
 - [ ] Every message flow appears as dashed line between pools
 - [ ] Header pool/lane count matches actual diagram
@@ -223,5 +239,10 @@ Single self-contained HTML file:
 - [ ] Gateways show tooltips with decision question and branches
 - [ ] Data stores show tooltips with connected tasks
 
+## Arrow Routing
+- [ ] All arrows use only horizontal and vertical segments — no diagonals
+- [ ] No two arrows share the same connection point on any element
+- [ ] No arrows overlapping or running on top of each other
+
 ## Hebrew Language
 - [ ] Male grammatical form used for all roles