sad-mcp 2.3.5 → 2.3.7

package/dist/bpmn/layout.d.ts

@@ -12,7 +12,7 @@ export declare const L: {
     readonly POOL_VGAP: 16;
     readonly LANE_MIN_H: 140;
     readonly LANE_CORRIDOR_H: 56;
-    readonly EMPTY_POOL_H: 60;
+    readonly EMPTY_POOL_H: 96;
     readonly CANVAS_TOP: 72;
     readonly CANVAS_LEFT_PAD: 20;
     readonly CANVAS_RIGHT_PAD: 40;

package/dist/bpmn/layout.js

@@ -31,7 +31,7 @@ export const L = {
     POOL_VGAP: 16,
     LANE_MIN_H: 140,
     LANE_CORRIDOR_H: 56, // bottom band for data stores/objects
-    EMPTY_POOL_H: 60,
+    EMPTY_POOL_H: 96, // tall enough for a wrapped 2-line pool label
     CANVAS_TOP: 72, // room for header bar above diagram
     CANVAS_LEFT_PAD: 20,
     CANVAS_RIGHT_PAD: 40,
@@ -389,10 +389,10 @@ export function layoutModel(m) {
 // ── Pool ordering ──────────────────────────────────────────────────────
 //
 // Heuristic:
-//  - Identify which external pool initiates the process by sending a
-//    message to the organization pool's start event.
-//  - Put that pool first, then the organization pool(s), then the rest.
-//  - Preserve relative order within each group from the input array.
+//  - If an external pool initiates the process by messaging the
+//    organization's start event, promote it to the top.
+//  - Otherwise preserve the modeler's input order (the natural expectation
+//    when the start event is a plain origin with no incoming message).
 function orderPools(m) {
     const initiators = new Set();
     const orgStartEvents = new Set();
@@ -409,16 +409,9 @@ function orderPools(m) {
             initiators.add(mf.fromPool);
         }
     }
-    const primary = [];
-    const org = [];
-    const supporting = [];
-    for (const p of m.pools) {
-        if (initiators.has(p.id))
-            primary.push(p);
-        else if (p.type === "organization")
-            org.push(p);
-        else
-            supporting.push(p);
-    }
-    return [...primary, ...org, ...supporting];
+    if (initiators.size === 0)
+        return [...m.pools]; // respect input order
+    const primary = m.pools.filter((p) => initiators.has(p.id));
+    const rest = m.pools.filter((p) => !initiators.has(p.id));
+    return [...primary, ...rest];
 }

package/dist/bpmn/svg.js

@@ -80,6 +80,24 @@ export function renderPool(pool) {
     const contentW = pool.w - headerW;
     const labelCx = headerX + headerW / 2;
     const labelCy = pool.y + pool.h / 2;
+    // Rotated pool labels run vertically, so their available length is the pool
+    // HEIGHT. Short (external-empty) pools clip long names — wrap to fit, and
+    // render the lines side by side across the header width.
+    const maxChars = Math.max(4, Math.floor((pool.h - 14) / 7));
+    const nameLines = wrapLabel(pool.name, maxChars, 3);
+    const lines = nameLines.length ? nameLines : [pool.name];
+    const nameFont = lines.length >= 3 ? 10 : lines.length === 2 ? 11 : 12;
+    const nameGap = nameFont + 1;
+    const nameSvg = lines
+        .map((ln, i) => {
+        const lx = labelCx + (i - (lines.length - 1) / 2) * nameGap;
+        return `<text x="${lx}" y="${labelCy}" text-anchor="middle"
+            dominant-baseline="middle"
+            transform="rotate(-90, ${lx}, ${labelCy})"
+            fill="#ffffff" font-size="${nameFont}" font-weight="600"
+            direction="rtl">${escapeXml(ln)}</text>`;
+    })
+        .join("\n      ");
     return `
     <!-- pool: ${escapeXml(pool.poolId)} -->
     <g class="bpmn-pool" data-pool="${escapeXml(pool.poolId)}">
@@ -87,11 +105,7 @@ export function renderPool(pool) {
             fill="${bodyFill}" stroke="${bodyStroke}" stroke-width="1.5"/>
       <rect x="${headerX}" y="${pool.y}" width="${headerW}" height="${pool.h}"
             fill="${headerFill}" stroke="${bodyStroke}" stroke-width="1.5"/>
-      <text x="${labelCx}" y="${labelCy}" text-anchor="middle"
-            dominant-baseline="middle"
-            transform="rotate(-90, ${labelCx}, ${labelCy})"
-            fill="#ffffff" font-size="12" font-weight="600"
-            direction="rtl">${escapeXml(pool.name)}</text>
+      ${nameSvg}
       <line x1="${contentX}" y1="${pool.y}" x2="${contentX}" y2="${pool.y + pool.h}"
             stroke="${bodyStroke}" stroke-width="1"/>
     </g>`;

package/package.json

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

package/skills/uml-class-diagram/SKILL.md

@@ -459,6 +459,7 @@ When splitting (§5), generate one `<svg id="svg-part-N">` per part. Split `CLAS
 ## 10. Output
 
 - Save as `[system_name]_class_diagram.html`
+- **Visual verification (required) — a loop, not a one-shot.** Structural validity ≠ visual validity. If a browser is available, render the HTML to an image, inspect it, and **fix → re-render → repeat until visually clean**. Scan every pass for: box overlaps; boxes off-canvas/clipped; a **multiplicity or role label landing inside a box** or on a line; **any line crossing through a foreign box**; the association-class tether hitting the wrong association; enum boxes overlapping. Do not report the diagram as done until a rendered pass is clean.
 - After saving, briefly state: number of classes, enumerations, relationships, whether split (and why), whether VP export is included
 
 ---

package/skills/uml-state-diagram/NOTATION.md

@@ -44,7 +44,7 @@ Two compartments separated by a horizontal line:
    - `exit /` actions on leaving
    - `do /` ongoing activity while in state
 
-Multiple activity lines in one compartment are fine.
+Multiple activity lines in one compartment are fine — but that means different *kinds* of lines (`entry /`, `exit /`, `do /`). Each kind appears **at most once per state**: a state has a single entry behavior, so multiple entry actions are written in the one `entry /` clause separated by `;`, never as a repeated `entry /` line.
 
 ## Layout Rules (from lectures)
 

package/skills/uml-state-diagram/SKILL.md

@@ -51,6 +51,7 @@ The shared files prepended to this prompt define the layout recipes, model shape
   2. **Activity compartment** — always present; minimum content is `entry / setStatus('SCREAMING_SNAKE_CASE')`
 - `setStatus()` is required in every state including composite states and archive states — it represents the object's tracked status in the implementation
 - Additional compartment lines: `entry / action`, `exit / action`, `do / activity`
+- **At most one `entry /` clause per state** (same for `exit /`). UML allows a single entry behavior; multiple entry actions go in that one clause, separated by `;` (wrap to an indented continuation line if too wide) — never write a second `entry /` line
 - Never produce a state with only a name and no compartment
 
 ### Transitions
@@ -257,6 +258,7 @@ Include at the bottom of every SVG:
 ## 11. Output
 
 - Save as `[entity_name]_state_diagram.html`
+- **Visual verification (required) — a loop, not a one-shot.** Structural validity ≠ visual validity. If a browser is available, render the HTML, inspect it, and **fix → re-render → repeat until visually clean**. Scan for: state-box overlaps; transition **labels/guards landing on a box or on another line**; arrows crossing through a foreign state; the initial/final markers misplaced; self-transitions unreadable. Confirm the lifecycle reads as **non-linear** (branches + returns), not a straight line. Don't report done until a rendered pass is clean.
 - Briefly state: entity modeled, state count, transition count, composite states, whether split
 
 ---

package/skills/uml-use-case-diagram/SKILL.md

@@ -907,6 +907,9 @@ The validator runs locally (no API cost) and catches what the §4 and CR gates c
 If the response is `✗ Model invalid`, fix every listed error and call the validator again. **Do not write the HTML file until the validator returns `✓ Model valid`.**
 
 After the validator passes, save the HTML as `[system_name]_use_case_diagram.html`.
+
+**Visual verification (required) — a loop, not a one-shot.** The validator passing is necessary but NOT sufficient: it does not catch layout problems. If a browser is available, render the HTML and inspect it, then **fix → re-render → repeat until visually clean**. Check **both tabs** (toggle which `.diagram-part` is `hidden`) and open at least one UC modal to confirm the wireframe renders. Scan every pass for: ellipse **overlaps**; actors too close (min ~200px); actor figure detached from its own line; a UC crowded into a **center column** (usually a recipient-only human actor on a system-initiated UC — remove it per §4.1); wide ellipses colliding with the boundary title bar; timing/label text on top of a line. Do not report the diagram as done until a rendered pass of each tab is clean.
+
 Briefly report: actor count, use case count, include/extend count, whether split, and any warnings the validator surfaced.
 
 ---