sad-mcp 0.1.30 → 0.1.32

package/dist/tools.js

@@ -248,6 +248,20 @@ export function registerToolHandlers(server) {
                     required: ["process_description"],
                 },
             },
+            {
+                name: "bpmn_render",
+                description: "Render a BPMN model as an interactive HTML/SVG diagram. Call this ONLY after the user has reviewed and approved the analysis output from bpmn_analysis, and explicitly asked you to draw/render the diagram. Pass the JSON model from the analysis phase.",
+                inputSchema: {
+                    type: "object",
+                    properties: {
+                        model_json: {
+                            type: "string",
+                            description: "The JSON model from the bpmn_analysis output (Section 8: מודל JSON)",
+                        },
+                    },
+                    required: ["model_json"],
+                },
+            },
         ],
     }));
     server.setRequestHandler(CallToolRequestSchema, async (request) => {
@@ -483,6 +497,18 @@ export function registerToolHandlers(server) {
             trackToolCall(name, toolArgs, { success: true, responseChars: fullResponse.length }, Date.now() - startTime);
             return { content: [{ type: "text", text: fullResponse }] };
         }
+        if (name === "bpmn_render") {
+            const modelJson = args.model_json;
+            if (!modelJson) {
+                return {
+                    content: [{ type: "text", text: "Error: model_json parameter is required. Use the JSON model from bpmn_analysis output." }],
+                };
+            }
+            const instructions = loadSkillContent("bpmn-render");
+            const fullResponse = `${instructions}\n\n---\n\n## JSON Model to Render\n\n\`\`\`json\n${modelJson}\n\`\`\``;
+            trackToolCall(name, toolArgs, { success: true, responseChars: fullResponse.length }, Date.now() - startTime);
+            return { content: [{ type: "text", text: fullResponse }] };
+        }
         throw new Error(`Unknown tool: ${name}`);
     });
 }

package/package.json

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

package/skills/bpmn-analysis/SKILL.md

@@ -9,7 +9,13 @@ You are a business process analyst. Analyze the process description and produce
 
 ## Critical Modeling Rules
 
-1. **CUSTOMERS / EXTERNAL PARTIES get their own POOL**: If a customer, patient, citizen, or external company (e.g., חברת אשראי, ספק) acts independently — they are a SEPARATE POOL with message flows. They are NOT a lane. The only exception: if the organization fully controls the participant's actions within its system (e.g., customer using a bank app).
+1. **EXTERNAL PARTIES get their own POOL** — but the pool type depends on who controls the process:
+
+   - **Independent external** (acts on their own, organization cannot dictate their process — e.g., חברת אשראי processing a charge, ספק deciding delivery schedule, customer deciding whether to complain): → **Empty/collapsed pool**. NO tasks, NO gateways, NO events inside. Just a labeled rectangle. Message flows connect to/from the **pool border**.
+
+   - **Organization-controlled external** (follows a process dictated by the organization step by step — e.g., customer filling out the organization's form, patient following the clinic's intake procedure): → **Regular expanded pool** with tasks, start/end events, gateways, and sequence flows inside. Treated like a full pool.
+
+   External participants are NEVER lanes — they are always separate pools. The question is only whether the pool is empty or expanded.
 
 2. **DATA STORES are mandatory**: If any task involves "block account", "generate invoice", "credit account", "update record", "register", "look up", or any read/write to persistent state — a Data Store is required.
 
@@ -17,6 +23,29 @@ You are a business process analyst. Analyze the process description and produce
 
 4. **GATEWAYS have types**: Every gateway must be classified as XOR (exclusive — one path), AND (parallel — all paths), or OR (inclusive — one or more paths).
 
+## ⚠️ EMPTY POOL VALIDATION — Read This Before Writing JSON
+
+An `external-empty` pool is JUST A LABEL. It has NOTHING inside it. Before finalizing your JSON, check every array and delete violations:
+
+**❌ WRONG — these violate empty pool rules:**
+```json
+{ "id": "t1", "name": "יצירת קשר", "pool": "pool-customer" }           ← task in empty pool!
+{ "id": "t10", "name": "זיכוי חשבון", "pool": "pool-credit" }           ← task in empty pool!
+{ "id": "start-customer", "type": "start", "pool": "pool-customer" }     ← event in empty pool!
+{ "id": "end-credit", "type": "end", "pool": "pool-credit" }             ← event in empty pool!
+{ "from": "start-customer", "to": "t1" }                                 ← sequence flow in empty pool!
+```
+
+**✅ RIGHT — empty pools appear ONLY in:**
+- `pools` array (with `"type": "external-empty"`)
+- `messageFlows` array (with `"fromTask": null` or `"toTask": null` for the empty pool side)
+
+**✅ RIGHT — customer's action is modeled as org-side task + message flow:**
+```json
+{ "id": "t2", "name": "קבלת פנייה מהלקוח", "pool": "pool-org", "lane": "lane-cs" }
+{ "from": "pool-customer", "to": "pool-org", "fromTask": null, "toTask": "t2", "description": "בקשת זיכוי" }
+```
+
 ## Analysis Steps
 
 ### Step 1 — Identify Participants
@@ -29,9 +58,13 @@ List every actor/role. Classify each as POOL or LANE:
 
 ### Step 2 — Identify Tasks
 
-List every action/task. Assign each to a specific lane or pool.
+List every action/task. Assign each to:
+- A **lane within the organization pool**, OR
+- An **organization-controlled external pool** (expanded — has its own tasks)
+
+Do NOT assign tasks to **independent external pools** — those are empty.
 
-Look for implied activities — phrases like "is expected to be in phone contact" or "will coordinate directly" describe real tasks, not annotations.
+Look for implied activities — phrases like "is expected to be in phone contact" or "will coordinate directly" describe real tasks, not annotations. If an independent external party performs an action, model the organization's side of that interaction as a task in the relevant lane (e.g., "קבלת בקשה מהלקוח") with a message flow from the external pool border.
 
 ### Step 3 — Identify Gateways
 
@@ -53,20 +86,23 @@ List transient data flowing between tasks (e.g., "בקשת ביטול", "חשב
 
 ### Step 6 — Identify Flows
 
-- **Sequence flows** (within a pool): Task ordering within each pool
-- **Message flows** (between pools): Every communication between separate pools. Check bidirectional — every message expecting a response needs a return flow.
+- **Sequence flows** (within pools that have tasks): Task ordering within the organization pool and within organization-controlled external pools. Independent external pools (empty) have NO sequence flows.
+- **Message flows** (between pools): Every communication between pools. For **independent external pools** (empty), message flows connect to/from the **pool border** (not to any element inside — there are none). For **organization-controlled external pools** (expanded), message flows connect to specific tasks. Check bidirectional — every message expecting a response needs a return flow.
 - **Data associations**: Connections between tasks and data stores / data objects.
 
 ### Step 7 — Identify Events
 
-- **Start events**: One per pool
-- **End events**: One or more per pool (different outcomes)
+Events exist in the **organization pool** and in **organization-controlled external pools** (expanded). NOT in independent external pools (empty).
+
+- **Start events**: One per expanded pool (organization + organization-controlled external)
+- **End events**: One or more per expanded pool (different outcomes)
 - **Intermediate events**: For passive waiting — when a participant waits for a signal/message
 
 ### Step 8 — Verify Completeness & Note Assumptions
 
-- Every pool has a complete flow: start → tasks/gateways → end
-- External parties have their full process modeled, not just a single task
+- Every expanded pool (organization + organization-controlled external) has a complete flow: start → tasks/gateways → end
+- Independent external pools are EMPTY — no tasks, no events, no gateways inside them
+- Every external participant mentioned in the description appears as a pool (empty or expanded, based on control)
 - List any assumptions you made about the process
 - List any open questions where the description was ambiguous
 
@@ -80,7 +116,8 @@ Show pools and lanes as a hierarchy:
 
 ```
 מאגרים (Pools):
-├── לקוח (מאגר חיצוני — פועל באופן עצמאי)
+├── חברת אשראי (מאגר חיצוני — ריק, פועל באופן עצמאי)
+├── לקוח (מאגר חיצוני — מורחב, תהליך נשלט ע״י הארגון)
 └── חברת אישימוטו (מאגר ארגוני)
     ├── שירות לקוחות
     ├── שימור לקוחות
@@ -89,7 +126,7 @@ Show pools and lanes as a hierarchy:
 
 ### Section 2: זרימת העבודה (Workflow)
 
-For each pool and lane, show the task flow as a numbered list with gateway branches indented:
+For each **expanded pool** (organization lanes + organization-controlled external pools), show the task flow as a numbered list with gateway branches indented. Do NOT show workflow for independent external pools (they are empty):
 
 ```
 שירות לקוחות:
@@ -114,7 +151,7 @@ Each data object with source task and target task.
 
 ### Section 6: זרימות הודעות (Message Flows)
 
-Between which pools, what's communicated, direction.
+Between which pools, what's communicated, direction. For **independent external pools** (empty), the message flow connects to/from the **pool border**. For expanded pools (organization or organization-controlled external), specify which task sends/receives the message.
 
 ### Section 7: הנחות ושאלות פתוחות (Assumptions & Open Questions)
 
@@ -129,14 +166,19 @@ Output the complete structured model as a JSON code block. This is the machine-r
   "title": { "he": "שם התהליך", "en": "Process Name" },
   "pools": [
     {
-      "id": "pool-id",
-      "name": "שם המאגר",
-      "type": "external",
-      "reason": "why this is a separate pool",
-      "lanes": []
+      "id": "pool-customer",
+      "name": "לקוח",
+      "type": "external-empty",
+      "reason": "acts independently — empty pool, no internal elements"
+    },
+    {
+      "id": "pool-patient",
+      "name": "מטופל",
+      "type": "external-expanded",
+      "reason": "follows clinic's prescribed intake process"
     },
     {
-      "id": "org-id",
+      "id": "pool-org",
       "name": "שם הארגון",
       "type": "organization",
       "reason": "main organization",
@@ -149,8 +191,8 @@ Output the complete structured model as a JSON code block. This is the machine-r
     {
       "id": "task-id",
       "name": "שם המשימה",
-      "pool": "pool-id",
-      "lane": "lane-id-or-null",
+      "pool": "pool-org",
+      "lane": "lane-id",
       "description": "optional details"
     }
   ],
@@ -160,8 +202,8 @@ Output the complete structured model as a JSON code block. This is the machine-r
       "type": "XOR",
       "role": "split",
       "question": "מה השאלה?",
-      "pool": "pool-id",
-      "lane": "lane-id-or-null",
+      "pool": "pool-org",
+      "lane": "lane-id",
       "branches": [
         { "label": "תיאור הענף", "target": "task-or-gw-id" }
       ]
@@ -187,8 +229,8 @@ Output the complete structured model as a JSON code block. This is the machine-r
     {
       "id": "event-id",
       "type": "start",
-      "pool": "pool-id",
-      "lane": "lane-id-or-null",
+      "pool": "pool-org",
+      "lane": "lane-id",
       "name": "תיאור האירוע"
     }
   ],
@@ -196,7 +238,7 @@ Output the complete structured model as a JSON code block. This is the machine-r
     { "from": "element-id", "to": "element-id", "label": "optional" }
   ],
   "messageFlows": [
-    { "from": "pool-id", "to": "pool-id", "description": "מה מועבר" }
+    { "from": "pool-customer", "to": "pool-org", "fromTask": null, "toTask": "task-id", "description": "מה מועבר" }
   ],
   "assumptions": [
     "הנחה שנעשתה..."
@@ -207,11 +249,26 @@ Output the complete structured model as a JSON code block. This is the machine-r
 }
 ```
 
-## After the Analysis
+## Final JSON Validation Checklist
+
+Before outputting the JSON, scan every array and verify:
+
+1. **`tasks` array**: Every task has `"pool": "pool-org"` (or an `external-expanded` pool). NO task has `"pool"` pointing to an `external-empty` pool.
+2. **`events` array**: Every event has `"pool": "pool-org"` (or an `external-expanded` pool). NO event has `"pool"` pointing to an `external-empty` pool.
+3. **`gateways` array**: Every gateway has `"pool": "pool-org"` (or an `external-expanded` pool). NO gateway has `"pool"` pointing to an `external-empty` pool.
+4. **`sequenceFlows` array**: NO sequence flow references any element in an `external-empty` pool.
+5. **`messageFlows` array**: For `external-empty` pools, `fromTask` or `toTask` is `null` (connects to pool border). The other side points to a specific task in the org pool.
+6. **`pools` array**: Empty pools use `"type": "external-empty"`. NOT `"external"`.
+
+If any violation is found, fix it — move the action to the org side and add a message flow instead.
+
+## After the Analysis — STOP
+
+After outputting the analysis, you MUST stop and wait for user feedback. Do NOT proceed to create a diagram, HTML file, or any visual output. Do NOT call any other tools. End your response with exactly this text:
 
-End your response with:
+**"זהו הניתוח המבני של התהליך. אפשר לבקש תיקונים או שינויים. כשהמודל מאושר, אמרו ״צייר את הדיאגרמה״ ואצור קובץ BPMN."**
 
-**"זהו הניתוח המבני של התהליך. אפשר לבקש תיקונים או שינויים. כשהמודל מאושר, אפשר לבקש ממני לצייר את דיאגרמת ה-BPMN."**
+Your response ends here. Do not continue.
 
 ## Hebrew Language Guidelines
 

package/skills/bpmn-render/SKILL.md

@@ -1,35 +1,78 @@
 ---
 name: bpmn-render
-description: "Internal skill: Render an approved BPMN structural model as an interactive HTML/SVG file. Do not invoke directly — use bpmn-diagram first to build the model."
+description: "Render an approved BPMN structural model as an interactive HTML/SVG file."
 ---
 
-# BPMN Rendering — Phase 2 & 3
+# BPMN Rendering
 
-You have an approved structural model from the conversation above (output of the `bpmn-diagram` prompt). Now render it as an HTML file with embedded SVG, then validate.
+You have an approved structural model (the JSON below). Render it as a single self-contained HTML file with embedded SVG.
 
-**Every participant, task, gateway, data store, data object, and flow from the approved model MUST appear in the SVG. Do not add or remove elements.**
+**Every participant, task, gateway, data store, data object, and flow from the model MUST appear in the SVG. Do not add or remove elements. The header pool/lane count MUST match the actual diagram.**
 
-## NON-NEGOTIABLE RENDERING RULES
+## NON-NEGOTIABLE RULES
 
-1. **GATEWAYS**: The diamond contains ONLY the marker symbol: **X** (XOR), **+** (AND), or **O** (OR). NEVER text inside. Labels go ABOVE the diamond. Every gateway (split AND merge) must show its marker.
+1. **GATEWAYS**: The diamond contains ONLY a marker symbol. NEVER text inside. Labels go ABOVE the diamond. Every gateway (split AND merge) must show its marker.
 
-2. **EXTERNAL PARTICIPANTS** are separate pools with message flows (dashed). NOT lanes.
+2. **EXTERNAL PARTICIPANT POOLS**: Separate pool rectangles with message flows (dashed). NOT lanes.
 
-3. **DATA STORES** appear as cylinders with data association lines to their tasks.
+3. **EMPTY POOLS** (external participants with no internal tasks): Message flows connect to/from the **pool border itself** — NOT to any element inside. The pool is just a labeled rectangle. No start/end events inside empty pools.
 
-4. **NO ELEMENTS ON LANE BOUNDARIES**: Every element fully inside one lane, centered vertically.
+4. **DATA STORES** appear as cylinders with data association lines to their tasks.
+
+5. **NO ELEMENTS ON LANE BOUNDARIES**: Every element fully inside one lane, centered vertically.
+
+6. **HEADER ACCURACY**: The header must show the correct count of pools and lanes matching the actual diagram. Count external pools + organization pool.
+
+7. **NO LEGEND**: Do not include a legend section. Students know BPMN notation.
+
+## Gateway Marker Styling
+
+Gateway markers must be clean and visually prominent. Use SVG paths, not text characters:
+
+### XOR Gateway — bold X
+```svg
+<g class="gateway-group">
+  <rect x="X" y="Y" width="34" height="34" fill="#fff8e1" stroke="#f9a825" stroke-width="2" transform="rotate(45, CX, CY)"/>
+  <line x1="CX-8" y1="CY-8" x2="CX+8" y2="CY+8" stroke="#e65100" stroke-width="3" stroke-linecap="round"/>
+  <line x1="CX+8" y1="CY-8" x2="CX-8" y2="CY+8" stroke="#e65100" stroke-width="3" stroke-linecap="round"/>
+</g>
+<text x="CX" y="CY-28" text-anchor="middle" class="gateway-label">label here</text>
+```
+
+### AND Gateway — bold +
+```svg
+<g class="gateway-group">
+  <rect x="X" y="Y" width="34" height="34" fill="#e8f5e9" stroke="#2e7d32" stroke-width="2" transform="rotate(45, CX, CY)"/>
+  <line x1="CX" y1="CY-9" x2="CX" y2="CY+9" stroke="#1b5e20" stroke-width="3" stroke-linecap="round"/>
+  <line x1="CX-9" y1="CY" x2="CX+9" y2="CY" stroke="#1b5e20" stroke-width="3" stroke-linecap="round"/>
+</g>
+<text x="CX" y="CY-28" text-anchor="middle" class="gateway-label">label here</text>
+```
+
+### OR Gateway — bold O
+```svg
+<g class="gateway-group">
+  <rect x="X" y="Y" width="34" height="34" fill="#e3f2fd" stroke="#1565c0" stroke-width="2" transform="rotate(45, CX, CY)"/>
+  <circle cx="CX" cy="CY" r="9" fill="none" stroke="#0d47a1" stroke-width="3"/>
+</g>
+<text x="CX" y="CY-28" text-anchor="middle" class="gateway-label">label here</text>
+```
 
 ## Architecture & Layout
 
 ### Pools and Lanes
 
 - **External participant pools**: Own pool rectangle, visually separated. Brown header, orange tasks (`#fff3e0` fill, `#e65100` stroke).
+- **Empty external pools**: Just a labeled rectangle (header bar + empty body). No elements inside. Height: ~60px.
 - **Organization pool**: Dark gray header, contains internal lanes. Each lane has a labeled sidebar and subtle background tint. Dashed divider lines between lanes.
 - Pool headers: Vertical text bars on the left side.
 
-### Element Placement
+### Message Flows with Empty Pools
 
-Every BPMN element must be fully contained within a single lane or pool. Center elements vertically within their lane with visible spacing from borders.
+When a message flow connects to/from an empty pool:
+- The arrow starts/ends at the **pool border** (the rectangle edge)
+- It does NOT connect to any element inside the pool
+- Use dashed lines (`stroke-dasharray: 10 5`), open circle at source, filled arrow at target
 
 ### Color Scheme
 
@@ -39,6 +82,8 @@ Every BPMN element must be fully contained within a single lane or pool. Center
 | Reception/admin tasks | `#e3f2fd` | `#1976d2` |
 | Clinical/operational tasks | `#f3e5f5` | `#7b1fa2` |
 | XOR Gateways | `#fff8e1` | `#f9a825` |
+| AND Gateways | `#e8f5e9` | `#2e7d32` |
+| OR Gateways | `#e3f2fd` | `#1565c0` |
 | Start event | `#e8f5e9` | `#2e7d32` |
 | End event | `#ffebee` | `#c62828` |
 | Data objects | `#fff` | `#1565c0` |
@@ -47,8 +92,9 @@ Every BPMN element must be fully contained within a single lane or pool. Center
 ### Pool Ordering
 
 When multiple external pools exist, minimize message flow crossing distance:
-- Primary actor (initiates, interacts with multiple parties) in the middle
-- Interacting pools above and below
+- Primary actor (initiates, interacts with multiple parties) near top
+- Organization pool in the middle
+- Supporting external participants (credit company, supplier) at bottom
 
 ### Flow Types
 
@@ -58,22 +104,44 @@ When multiple external pools exist, minimize message flow crossing distance:
   - Data object: `#7986cb`
   - Data store: `#4caf50`
 
-## SVG Templates
-
-### XOR Gateway (split or merge)
-
-```svg
-<rect x="X" y="Y" width="34" height="34" class="gateway" transform="rotate(45, CX, CY)"/>
-<line x1="CX-7" y1="CY-10" x2="CX+7" y2="CY+10" class="gateway-x"/>
-<line x1="CX+7" y1="CY-10" x2="CX-7" y2="CY+10" class="gateway-x"/>
-<text x="CX" y="CY-25" text-anchor="middle">label ABOVE diamond</text>
+## Interactivity
+
+Make the diagram interactive with hover tooltips and click behavior:
+
+### Clickable Tasks
+Each task rectangle should show a tooltip on hover with:
+- The task name
+- Which pool/lane it belongs to
+- Any data stores it reads from or writes to
+
+### Clickable Gateways
+Each gateway should show a tooltip on hover with:
+- Gateway type (XOR/AND/OR)
+- The decision question
+- The branch conditions and where each leads
+
+### Clickable Data Stores
+Each data store should show a tooltip on hover with:
+- The data store name
+- Which tasks read from it
+- Which tasks write to it
+
+### Implementation
+Use CSS hover tooltips or simple JavaScript click-to-show panels. Keep it lightweight — no external libraries. Example approach:
+
+```html
+<style>
+  .bpmn-tooltip { display: none; position: absolute; background: #1a1a2e; color: #fff;
+    padding: 8px 12px; border-radius: 6px; font-size: 12px; max-width: 250px;
+    z-index: 100; direction: rtl; pointer-events: none; }
+  .bpmn-element:hover .bpmn-tooltip { display: block; }
+</style>
 ```
 
-**WRONG — never do this:**
-```svg
-<polygon points="..." fill="..." stroke="..."/>
-<text x="CX" y="CY">text inside diamond</text>  <!-- FORBIDDEN -->
-```
+### Assumptions Panel
+If the model includes assumptions or open questions, show a small floating info button in the top-right corner. Clicking it shows the assumptions list.
+
+## SVG Templates
 
 ### Intermediate Events (BPMN 1.1)
 
@@ -99,39 +167,16 @@ Plain double circle, NO icon inside:
 <ellipse cx="CX" cy="BOTTOM" rx="28" ry="8" class="data-store-body"/>
 ```
 
-### Data Artifact Placement
-
-- Data objects above or below their task, never overlapping flow lines
-- Data stores typically below their tasks
-- Association lines must not cross sequence flow arrows
-
 ## Arrow Routing
 
 **Arrows must never be ambiguous.**
 
-### Split-Merge Pattern
-
-1. YES task above gateway center, NO task below
-2. Merge gateway to the right of BOTH tasks
-3. YES path: task → right → down into merge (from top)
-4. NO path: task → right → up into merge (from bottom)
-5. Single clean line from merge to next task
-
-### General Rules
-
 - 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
 
-### Rejection/Retry Loops
-
-- Rejection = explicit task (not just gateway output)
-- After rejection: model the rejecting participant's next state
-- Response to rejection = concrete task sequence
-- Loop-back to earliest meaningful re-entry point
-
 ## Typography & Hebrew
 
 - `Noto Sans Hebrew` from Google Fonts
@@ -145,43 +190,38 @@ Plain double circle, NO icon inside:
 
 Single self-contained HTML file:
 
-1. **Header bar**: Gradient, process title in Hebrew + English subtitle. Must say "BPMN 1.1"
-2. **Legend**: All BPMN symbols used (start, end, task, XOR gateway, intermediate event, data object, data store, message flow)
-3. **SVG canvas**: Full diagram in scrollable wrapper
-4. **SVG definitions**: Drop shadow filters, arrow markers
+1. **Header bar**: Gradient, process title in Hebrew + English subtitle. Must say "BPMN 1.1". Show correct pool and lane counts.
+2. **SVG canvas**: Full diagram in scrollable wrapper
+3. **SVG definitions**: Drop shadow filters, arrow markers
+4. **Interactivity**: Hover tooltips on all elements
+5. **NO LEGEND**: Do not include a legend.
 
 ### SVG Sizing
 
 - Width: 1700–1800px (overflow scroll)
-- Height: ~130px per external pool, ~250px per lane, plus data artifacts
+- Height: ~60px per empty external pool, ~130px per external pool with tasks, ~250px per lane, plus data artifacts
 - `viewBox` matching width/height
 
 ---
 
-# PHASE 3 — VALIDATION
+# VALIDATION
 
-**Before delivering, verify EVERY item. Fix any failure before delivering.**
+**Before delivering, verify EVERY item. Fix any failure.**
 
-## Structural Accuracy (cross-reference with approved model)
+## Structural Accuracy
 - [ ] Every participant from the model appears — none omitted
 - [ ] External participants are separate pools with message flows
-- [ ] Every pool has complete flow (start → ... → end)
-- [ ] Every gateway has the correct type marker (X/+/O) — no text inside
+- [ ] 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 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
 
-## BPMN Compliance
-- [ ] Gateway labels ABOVE or BESIDE the diamond, never inside
-- [ ] Every element fully inside one lane — nothing on boundaries
-- [ ] Passive waiting uses intermediate events, not tasks
-- [ ] Data objects (folded document) and data stores (cylinder) are visually distinct
-
-## Visual Quality
-- [ ] No arrow paths overlap or cross ambiguously
-- [ ] Flow labels clearly positioned near their gateway
-- [ ] Legend includes every symbol type used
-- [ ] Data artifacts don't overlap sequence flow paths
-- [ ] Pool ordering minimizes message flow crossing distance
+## Interactivity
+- [ ] Tasks show tooltips on hover
+- [ ] Gateways show tooltips with decision question and branches
+- [ ] Data stores show tooltips with connected tasks
 
 ## Hebrew Language
-- [ ] Male grammatical form used for all roles (רופא not אחות, אח not אחות, מטופל not מטופלת)
+- [ ] Male grammatical form used for all roles