sad-mcp 0.1.23 → 0.1.24

package/package.json

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

package/skills/bpmn-diagram/SKILL.md

@@ -7,6 +7,8 @@ description: Create BPMN (Business Process Model and Notation) diagrams as inter
 
 This skill creates professional BPMN 1.1 diagrams rendered as interactive HTML files with embedded SVG. The diagrams support Hebrew (RTL) and English text.
 
+**This skill operates in 3 phases. You MUST complete each phase fully before moving to the next.**
+
 ## NON-NEGOTIABLE RULES — READ BEFORE ANYTHING ELSE
 
 These rules are violated most often. You MUST follow every one. No exceptions.
@@ -21,8 +23,6 @@ These rules are violated most often. You MUST follow every one. No exceptions.
 
 5. **EVERY PARTICIPANT MUST APPEAR**: If the process description mentions a customer/patient/company — they MUST appear in the diagram. Never omit a participant.
 
-6. **OUTPUT STRUCTURAL ANALYSIS FIRST**: Before writing ANY SVG, you must output the structural analysis (participants → pool/lane, data stores, message flows). The SVG must match this analysis.
-
 ## When to Use
 
 - User asks to create a BPMN diagram, process model, or workflow diagram
@@ -30,72 +30,133 @@ These rules are violated most often. You MUST follow every one. No exceptions.
 - User provides a process narrative in any language and wants a BPMN representation
 - User asks to model a process with swim lanes, pools, gateways, or data flows
 
-## Process Analysis — Before Drawing
+---
 
-Before writing any SVG code, analyze the process description to identify:
+# ═══════════════════════════════════════════════════
+# PHASE 1 — STRUCTURAL MODEL (text only, NO SVG)
+# ═══════════════════════════════════════════════════
 
-1. **Participants — CRITICAL (Pool vs Lane)**: Who are the actors? Classify each based on **process control**, not just organizational membership:
-   - If the participant acts **independently** and communicates with the organization from outside (e.g., a customer calling to cancel a subscription, a patient arriving at a clinic, a citizen filing a complaint, an external company like a credit card company or supplier) → **separate pool** with message flows
-   - If the organization **dictates and controls** how the participant performs their activities within its own system (e.g., a customer using the bank's app to make a transaction, a user following a guided online workflow) → **lane** within the organization pool with sequence flows
-   - Internal roles within the same organization → **lanes** within one pool
-   - **The test**: "Does the organization orchestrate this participant's actions, or do they act on their own initiative?" If they act independently → separate pool
-2. **Activities/Tasks**: List every action/task mentioned
-3. **Decision Points**: Identify every conditional branch (if/else, exists/doesn't exist)
-4. **Data**: What information is created, read, updated, or stored?
-5. **Handoffs**: Where does work pass between participants? These become message flows between pools or sequence flows between lanes
-6. **Waiting Points**: Is any participant passively waiting? Use intermediate events, not regular tasks
-7. **Data Persistence — CRITICAL**: Model a Data Store whenever the process involves persistent storage. **Trigger words** that require a data store: "system", "database", "account", "record", "registry". **Action verbs** that imply a data store: "block account", "update record", "generate invoice", "credit account", "register", "log", "store", "look up", "check status". If a task reads from or writes to shared persistent state, it MUST have a data association to a data store. Do NOT substitute a lightweight Data Object when persistent shared storage is implied. A system = a data store. An account = a data store.
-8. **Complete Each Participant's Flow**: Every pool must have its own complete internal sequence flow (start → tasks → end), even for external parties. If the description says "Company X will handle the complaint," model the full handling sequence inside that pool (receive → process → respond → close), not just the first step. Never collapse an external participant's process into a single task or annotation.
-9. **Bidirectional Communication**: When one participant sends something to another, check: does the receiver send something back? Every message flow that triggers a response must have a corresponding return message flow. Model both directions explicitly. Common pairs: request→acknowledgment, notification→confirmation, complaint→response.
-10. **Implied Activities**: Read the description for activities that are described but not explicitly named as "tasks." Phrases like "she can and is expected to be in phone contact" or "will coordinate directly" describe real activities that should be modeled as tasks, NOT as text annotations. Annotations are only for meta-information that clarifies context but isn't an executable step.
+In this phase you analyze the process description and output a structured text model. Do NOT write any HTML, SVG, or code. Only text analysis.
 
-## Mandatory Structural Analysis Output — CRITICAL
+## Step 1.1 — Identify Participants
 
-**Before writing ANY SVG code, you MUST output the following structured analysis as text.** This is non-negotiable — skipping this step is the primary cause of structural modeling errors (wrong pool/lane assignments, missing data stores).
+List every actor/role mentioned in the process. For each one, classify as POOL or LANE:
 
-### Required Output Format:
+- **POOL** (separate, independent): The participant acts on their own initiative and communicates with the organization from outside. Examples: a customer calling to cancel, a patient arriving at a clinic, a citizen filing a complaint, an external company (credit card company, supplier, contractor).
+- **LANE** (within org pool): The participant is an internal role within the organization, OR the organization fully dictates and controls how they perform activities within its system (e.g., customer using the bank's app).
+- **The test**: "Does the organization orchestrate this participant's actions, or do they act independently?" Independent → POOL.
 
-```
-STRUCTURAL ANALYSIS:
+## Step 1.2 — Identify Tasks
+
+List every action/task mentioned in the process description. For each task, specify which lane or pool it belongs to. Also identify implied activities — phrases like "she can and is expected to be in phone contact" or "will coordinate directly" describe real tasks, NOT annotations.
+
+## Step 1.3 — Identify Gateways (with type!)
+
+List every decision point / conditional branch. For each gateway, specify:
+- **Type**: XOR (exclusive — only one path), AND (parallel — all paths), or OR (inclusive — one or more paths)
+- **Question/condition**: What is being decided
+- **Outgoing branches**: The possible outcomes and where each leads
+- **Merge**: Where the branches reconverge (if applicable) — merge gateways must also be listed with their type
+
+## Step 1.4 — Identify Data Stores
+
+Scan all tasks for persistent storage operations. **Trigger words**: "system", "database", "account", "record", "registry". **Action verbs**: "block account", "update record", "generate invoice", "credit account", "register", "log", "store", "look up", "check status".
+
+If ANY task reads from or writes to shared persistent state → Data Store is required. A system = a data store. An account = a data store.
+
+List each data store with a name and which tasks connect to it (read/write).
+
+## Step 1.5 — Identify Data Objects
+
+List specific pieces of data that flow between tasks (e.g., "בקשת ביטול", "חשבונית זיכוי"). These are different from data stores — data objects are transient documents, not persistent systems.
+
+## Step 1.6 — Identify Flows
 
-1. PARTICIPANTS:
-   - [Name] → POOL (acts independently: [reason]) / LANE (org controls: [reason])
-   - ...
+- **Sequence flows** (within a pool/between lanes): List the order of tasks within each pool
+- **Message flows** (between pools): List every communication between separate pools. Check for bidirectional communication — every message that expects a response needs a return message flow.
+- **Data associations**: List connections between tasks and data stores / data objects.
 
-2. DATA STORES:
-   - [Store name] — triggered by: [task X writes/reads/updates ...]
-   - ...
+## Step 1.7 — Identify Events
+
+- **Start events**: One per pool
+- **End events**: One or more per pool (for different outcomes)
+- **Intermediate events**: Use for passive waiting (not tasks). When a participant is waiting for a signal/message from another participant.
+
+## Step 1.8 — Complete Each Participant's Flow
+
+Verify that every pool has a complete internal sequence flow: start → tasks/gateways → end. Even external parties must have their full process modeled (receive → process → respond → close), not just a single task.
+
+## Required Output Format
 
-3. MESSAGE FLOWS (between pools):
-   - [Pool A] ↔ [Pool B]: [what is communicated]
-   - ...
 ```
+STRUCTURAL MODEL:
+
+POOLS:
+- [Pool name] — [reason: acts independently / external company]
+  Tasks: [task1] → [task2] → ...
+  Start: [description]
+  End(s): [description(s)]
+
+ORGANIZATION POOL: [org name]
+  LANE: [lane name]
+    Tasks: [task1] → [task2] → ...
+  LANE: [lane name]
+    Tasks: ...
+  Start: [description]
+  End(s): [description(s)]
+
+GATEWAYS:
+- [G1] Type: XOR | Question: [question] | In: [lane/pool] | Branches: [branch1 → ..., branch2 → ...]
+- [G2] Type: XOR (merge) | In: [lane/pool] | Merges: [branches from G1]
+- ...
+
+DATA STORES:
+- [Store name] — reads: [task X, task Y] | writes: [task Z]
+- ...
+
+DATA OBJECTS:
+- [Object name] — from: [task X] → to: [task Y]
+- ...
+
+MESSAGE FLOWS:
+- [Pool A] → [Pool B]: [what is communicated]
+- [Pool B] → [Pool A]: [response]
+- ...
+```
+
+## ⛔ HARD STOP — DO NOT PROCEED
+
+**STOP HERE.** Present the structural model above to the user. Do NOT write any HTML, SVG, or code yet.
 
-**The SVG diagram MUST match this analysis exactly.** If the analysis says "separate pool," the SVG must have a separate pool. If the analysis identifies a data store, the SVG must include it with data associations.
+Ask the user: "הנה המודל המבני של התהליך. האם לעבור לשלב הבא ולייצר את הדיאגרמה, או שיש שינויים שתרצה לבצע?"
 
-## Architecture & Layout Rules
+Wait for the user to confirm or request changes. If they request changes, revise the model and present it again. Only proceed to Phase 2 after explicit user confirmation.
 
-### Pools and Lanes — CRITICAL
+---
+
+# ═══════════════════════════════════════════════════
+# PHASE 2 — SVG RENDERING (only after Phase 1 approval)
+# ═══════════════════════════════════════════════════
+
+Take the approved structural model from Phase 1 and render it as an 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.
+
+## Architecture & Layout
 
-- **External participants** (e.g., patient, customer, citizen) get their own **pool** at the top of the diagram
-  - Use a distinct color scheme for the external pool header (e.g., brown) to differentiate from the organization pool (dark gray)
+### Pools and Lanes
+
+- **External participant pools** get their own pool rectangle, visually separated from the organization pool
+  - Use a distinct color scheme for external pool headers (e.g., brown) to differentiate from the organization pool (dark gray)
   - External pool tasks use a warm color (e.g., orange `#fff3e0` fill, `#e65100` stroke)
-- **Internal roles** within the organization are modeled as **lanes** within the organization pool
+- **Organization pool** contains internal lanes
   - Each lane gets a labeled sidebar and a subtle background tint
   - Separate lanes with dashed divider lines
 - Pool headers are vertical text bars on the left side of the pool
 
-**Common Mistakes to Avoid:**
-- Putting a customer/patient/citizen as a lane when they act independently — they need a separate pool with message flows, not sequence flows
-- Using sequence flows between independent participants instead of message flows between separate pools
-- Forgetting that external companies (e.g., חברת אשראי, ספק, קבלן) also need their own pool — they are not part of the organization
-- Omitting a participant entirely — if the process description mentions a customer/patient/citizen, they MUST appear in the diagram as a pool with their own flow
-
-### Element Placement — CRITICAL
+### Element Placement
 
-**Every BPMN element (task, gateway, event) must be fully contained within a single lane or pool.** No element may overlap a lane divider line or sit on the boundary between two lanes. If an element belongs to a lane, it must be clearly centered vertically within that lane's area, with visible spacing from the lane borders above and below.
+**Every BPMN element (task, gateway, event) must be fully contained within a single lane or pool.** No element may overlap a lane divider line or sit on the boundary between two lanes. Center elements vertically within their lane with visible spacing from borders.
 
-### Color Scheme by Participant Type
+### Color Scheme
 
 | Element | Fill | Stroke |
 |---------|------|--------|
@@ -108,35 +169,33 @@ STRUCTURAL ANALYSIS:
 | Data objects | `#fff` | `#1565c0` |
 | Data stores | `#fff` | `#2e7d32` |
 
-### Pool Ordering — Optimal Layout
-
-When multiple external pools exist, order pools to **minimize message flow crossing distance**:
+### Pool Ordering
 
-- Place the **primary actor** (the one who initiates and interacts with multiple parties) in the **middle**, not at the top
-- Place pools they interact with **above and below** so message flows go in both directions naturally
-- Rule of thumb: Count message flows between each pair of pools. Adjacent pools should be the pairs with the most message flows between them
-
-Example: If a Resident interacts with both a Delivery Company and a Development Company → place Delivery Company on top, Resident in the middle, Development Company on the bottom.
+When multiple external pools exist, order to **minimize message flow crossing distance**:
+- Place the primary actor (initiates and interacts with multiple parties) in the middle
+- Place pools they interact with above and below
 
 ### Flow Types
 
 - **Sequence flows** (within a pool): Solid lines with filled arrowheads (`#546e7a`)
 - **Message flows** (between pools): Dashed lines (`stroke-dasharray: 10 5`) with open circle at source and filled arrow at target (`#37474f`)
-- **Data associations**: Dashed lines (`stroke-dasharray: 4 3`) with small arrowheads, colored by type:
+- **Data associations**: Dashed lines (`stroke-dasharray: 4 3`) with small arrowheads:
   - Data object associations: `#7986cb`
   - Data store associations: `#4caf50`
 
-## BPMN Element Standards
-
-### Gateways — CRITICAL RULE
+## BPMN Element SVG Templates
 
-**Gateway diamonds must contain ONLY the marker symbol — NEVER text.** No labels, descriptions, or questions inside the diamond shape. Gateway labels go ABOVE or BESIDE the diamond, never inside it.
+### Gateways
 
-- XOR (exclusive): **X** marker inside the diamond
-- AND (parallel): **+** marker inside the diamond
-- OR (inclusive): **O** marker inside the diamond
+**Gateway diamonds contain ONLY the marker symbol — NEVER text.** Labels go ABOVE the diamond.
 
-**Every gateway — both split AND merge/join — MUST display its marker symbol.** Merge gateways are never left as blank diamonds. This is a non-negotiable requirement.
+```svg
+<!-- XOR Gateway (split or merge) — X marker inside -->
+<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</text>
+```
 
 **Anti-pattern — NEVER do this:**
 ```svg
@@ -145,47 +204,25 @@ Example: If a Resident interacts with both a Delivery Company and a Development
 <text x="CX" y="CY">כמה ימים?</text>  <!-- FORBIDDEN -->
 ```
 
-**Correct pattern:**
-```svg
-<!-- RIGHT: X marker inside, label outside -->
-<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">כמה ימים?</text>  <!-- label ABOVE -->
-```
-
-### Intermediate Events (Waiting/Catching)
+### Intermediate Events (BPMN 1.1 style)
 
-Use **BPMN 1.1 style**: plain double circle with NO icon inside. Just two concentric circles.
+Plain double circle with NO icon inside:
 
 ```svg
-<!-- Intermediate event — plain double circle -->
 <circle cx="X" cy="Y" r="16" fill="#fff" stroke="#1565c0" stroke-width="2"/>
 <circle cx="X" cy="Y" r="12" fill="none" stroke="#1565c0" stroke-width="1.2"/>
 ```
 
-Use intermediate events (not tasks) when a participant is passively waiting for a signal, message, or trigger from another participant.
-
-### Data Objects vs Data Stores — MUST DISTINGUISH
-
-These are two different BPMN artifacts and must be visually distinct:
-
-**Data Objects** (folded-corner document icon, blue):
-- Represent a specific piece of data flowing through the process (e.g., "פרטי תינוק", "סיכום ביקור", "הערת מעקב")
-- Drawn as a rectangle with a folded top-right corner
+### Data Objects (folded-corner document, blue)
 
 ```svg
-<!-- Data Object template (w≈34, h≈38) -->
 <path d="M X,Y L X+26,Y L X+34,Y+8 L X+34,Y+38 L X,Y+38 Z" class="data-object-shape"/>
 <path d="M X+26,Y L X+26,Y+8 L X+34,Y+8" class="data-object-fold"/>
 ```
 
-**Data Stores** (cylinder icon, green):
-- Represent persistent storage / databases (e.g., "מאגר כרטיסי תינוקות", "מאגר מדדים")
-- Drawn as a cylinder (two ellipses connected by vertical lines)
+### Data Stores (cylinder, green)
 
 ```svg
-<!-- Data Store template -->
 <ellipse cx="CX" cy="TOP" rx="28" ry="8" class="data-store-body"/>
 <path d="M CX-28,TOP L CX-28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
 <path d="M CX+28,TOP L CX+28,BOTTOM" fill="none" stroke="#2e7d32" stroke-width="1.3"/>
@@ -194,91 +231,96 @@ These are two different BPMN artifacts and must be visually distinct:
 
 ### Data Artifact Placement
 
-- Place data objects **above** or **below** their associated task, never overlapping flow lines
-- Place data objects to the **left** of a task if vertical placement would cross flow paths
-- Data stores typically go below their associated tasks
-- **Never** place data artifacts in a location where their association lines cross or overlap with sequence flow arrows
-
-## Arrow Routing — CRITICAL
-
-The most important visual quality rule: **arrows must never be ambiguous**.
+- Place data objects above or below their associated task, never overlapping flow lines
+- Place data stores typically below their associated tasks
+- Never place data artifacts where association lines cross sequence flow arrows
 
-### Split-Merge Pattern (Two Outcome Paths)
+## Arrow Routing
 
-When a gateway splits into two paths (e.g., "תקין" vs "דורש מעקב") and then merges:
+**Arrows must never be ambiguous.**
 
-1. Place the **YES task** above the gateway's horizontal center line
-2. Place the **NO task** below the gateway's horizontal center line
-3. Place the **merge gateway** clearly to the right of BOTH tasks
-4. Route the YES path: task → **right** → **down** into merge gateway (entering from top)
-5. Route the NO path: task → **right** → **up** into merge gateway (entering from bottom)
-6. From the merge gateway, route a **single clean vertical line down** to the next task
+### Split-Merge Pattern
 
-**The merge area must have clear visual separation between all paths. No path should overlap another.**
+1. YES task above the gateway's horizontal center line
+2. NO task below
+3. Merge gateway clearly to the right of BOTH tasks
+4. YES path: task → right → down into merge (entering from top)
+5. NO path: task → right → up into merge (entering from bottom)
+6. From merge: single clean line to next task
 
 ### General Routing Rules
 
-- Prefer orthogonal (right-angle) routing over diagonal lines
+- Prefer orthogonal (right-angle) routing
 - Leave at least 30px spacing between parallel flow lines
-- When routing a flow from one lane to another, use a clear vertical drop/rise
+- Cross-lane flows use clear vertical drops/rises
 - Label YES/NO (כן/לא) near the gateway, not at the end of the path
-- Flow labels should not overlap with other elements
+- Flow labels must not overlap other elements
 
 ## Modeling Rejection/Retry Loops
 
-When a process includes an approval step where the participant can reject:
+1. Model rejection as an explicit task (not just a gateway output)
+2. After rejection, model the rejecting participant's next state (waiting/action)
+3. Model the response to rejection as a concrete task sequence
+4. Loop-back arrows return to the earliest meaningful re-entry point
 
-1. Model the **rejection action** as an explicit task in the rejecting participant's pool (e.g., "שליחת ביטול סגירה"), not just a gateway output
-2. After rejection, model what the rejecting participant **does next** — typically a waiting intermediate event (e.g., waiting for follow-up contact)
-3. In the receiving pool, model the **response to rejection** as a concrete task sequence (e.g., "contact customer" → "decide next step")
-4. Loop-back arrows should return to the earliest meaningful re-entry point in the process, not to an arbitrary task
-
-## Typography & Hebrew Support
+## Typography & Hebrew
 
 - Use `Noto Sans Hebrew` (imported from Google Fonts) for all text
 - Set `lang="he"` and `dir="rtl"` on the HTML element
-- Task text: 11.5px, font-weight 500, centered in the task box
+- Task text: 11.5px, font-weight 500, centered
 - Gateway labels: 10.5px, font-weight 400, positioned above the diamond
 - Data labels: 9.5px, font-weight 500
-- Flow labels (כן/לא): 10px
+- Flow labels: 10px
 
 ## File Structure
 
 Output a single self-contained HTML file with:
 
 1. **Header bar**: Gradient background with process title in Hebrew + English subtitle. Must say "BPMN 1.1" (NOT 2.0)
-2. **Legend**: Horizontal bar showing all BPMN symbols used in the diagram (start, end, task, XOR gateway, intermediate event, data object, data store, message flow)
+2. **Legend**: Horizontal bar showing all BPMN symbols used (start, end, task, XOR gateway, intermediate event, data object, data store, message flow)
 3. **SVG canvas**: The full BPMN diagram in a scrollable wrapper
 4. **SVG definitions**: Drop shadow filters, arrow markers (sequence, message, data association)
 
 ### SVG Sizing
 
 - Width: 1700–1800px typical (allow overflow scroll)
-- Height: Scale based on number of pools and lanes (~130px per external pool, ~250px per lane, plus spacing for data artifacts)
-- Use `viewBox` matching width/height for proper scaling
+- Height: Scale based on pools and lanes (~130px per external pool, ~250px per lane, plus data artifacts)
+- Use `viewBox` matching width/height
+
+---
 
-## Verification Gate — MANDATORY
+# ═══════════════════════════════════════════════════
+# PHASE 3 — VALIDATION & FIX
+# ═══════════════════════════════════════════════════
 
-**STOP before delivering the diagram. Verify EVERY item below. If any item fails, you MUST fix it before delivering. Do NOT skip this step.**
+**Before delivering the diagram, go through EVERY item below. If ANY item fails, fix the SVG immediately. Do NOT deliver until all pass.**
 
+## Structural Accuracy (cross-reference with Phase 1 model)
+- [ ] Every participant from the Phase 1 model appears in the SVG — none are omitted
+- [ ] External participants are in separate pools with message flows (not lanes with sequence flows)
+- [ ] Every pool has a complete internal flow (start → ... → end)
+- [ ] Every gateway from Phase 1 appears with the correct type marker
+- [ ] Every data store from Phase 1 appears as a cylinder with data associations
+- [ ] Every message flow from Phase 1 appears as a dashed line between pools
+
+## BPMN Compliance
 - [ ] Every gateway (split AND merge) has ONLY an X/+/O marker inside — no text inside the diamond
-- [ ] Gateway labels (questions, conditions) are positioned ABOVE or BESIDE the diamond, never inside
+- [ ] Gateway labels are positioned ABOVE or BESIDE the diamond, never inside
 - [ ] Every element (task, gateway, event) is fully inside a single lane — nothing sits on a lane boundary
-- [ ] No arrow paths overlap or cross ambiguously
-- [ ] Data objects (📄) and data stores (🗄️) use different icons
-- [ ] Every participant mentioned in the process description appears in the diagram — none are omitted
-- [ ] External participants are in separate pools with message flows
 - [ ] Passive waiting uses intermediate events, not regular tasks
+- [ ] Data objects (folded document) and data stores (cylinder) use different icons
+
+## Visual Quality
+- [ ] No arrow paths overlap or cross ambiguously
 - [ ] Flow labels (כן/לא) are clearly positioned near their gateway
 - [ ] The legend includes every symbol type used in the diagram
 - [ ] Data artifacts don't overlap with sequence flow paths
-- [ ] Every pool has a complete internal flow (start → ... → end), not just a single task
-- [ ] A Data Store is modeled for every persistent system (accounts, invoices, records, registrations — see trigger words in Process Analysis step 7)
-- [ ] Every message flow that expects a response has a return message flow
-- [ ] Phone calls, emails, and direct contacts mentioned in the description are modeled as tasks, not annotations
-- [ ] After a rejection/refusal gateway, the rejecting participant's subsequent state (waiting/action) is explicitly modeled
 - [ ] Pool ordering minimizes message flow crossing distance
 
+---
+
+# APPENDIX
+
 ## Example Process Categories
 
 This skill handles processes such as: