sad-mcp 0.1.31 → 0.1.33

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sad-mcp",
-  "version": "0.1.31",
+  "version": "0.1.33",
   "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,6 +249,19 @@ Output the complete structured model as a JSON code block. This is the machine-r
 }
 ```
 
+## 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:

package/skills/bpmn-render/SKILL.md

@@ -17,7 +17,7 @@ You have an approved structural model (the JSON below). Render it as a single se
 
 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. **DATA STORES** appear as cylinders with data association lines to their tasks.
+4. **DATA STORES** appear as cylinders with data association lines to their tasks. **Duplicate data stores** when needed — if a data store is used by tasks in different lanes or distant parts of the diagram, draw multiple copies of the same cylinder, each placed close to its connected tasks. This avoids long crossing arrows. Each copy has the same label.
 
 5. **NO ELEMENTS ON LANE BOUNDARIES**: Every element fully inside one lane, centered vertically.