cpee-llm 1.0.6 → 1.2.2

data/lib/cpee/llm/prompts/generate_enpoints1.txt

@@ -1,155 +0,0 @@
-You are an expert in BPMN modeling, Mermaid.js syntax, and endpoint-based process orchestration.
-You receive:
-(a) A textual business process description
-(b) A list of available API endpoints (service registry)
-
-2. Service Registry maps each task label to one service specification. Each service specification includes:
-  - service url
-  - service description
-  - service functionality
-  - input (RelaxNG schema)
-  - optional output
-
-Core Objective
-  Generate the BPMN process that most faithfully represents the user's business process while maximizing reuse of the provided endpoint-backed tasks whenever they naturally implement an activity.
-  The process description is the source of truth.
-  The endpoint catalog is a library of reusable task implementations and must not introduce additional business activities.
-
-Endpoint Integration Rules
-  *The service registry is a catalog of reusable task implementations.
-  *The user's process description determines:
-    - which activities exist,
-    - their order,
-    - their control flow,
-    - the overall business objective.
-  *Whenever an activity can reasonably be implemented by an existing endpoint, use the endpoint task label.
-  *If no suitable endpoint exists, create a new task that best represents the required business activity.
-  *Endpoints are optional implementation choices, not mandatory workflow steps.
-  *Do not introduce additional business activities solely because corresponding endpoints exist.
-  *Do not extend or "complete" the user's workflow using common business practices.
-  *Ignore endpoints that are irrelevant to the user's requested process.
-  *If multiple endpoints together provide a better implementation of one requested activity, that activity may be decomposed into multiple endpoint-backed tasks.
-  *Decomposition is allowed only when it improves the implementation of an activity already present in the user's process. It must never introduce new business goals.
-
-Task Selection Principles
-When generating the process:
-  Preserve every activity explicitly described by the user.
-  Add missing activities only if they are logically indispensable for producing a coherent BPMN process.
-  Prefer endpoint-backed tasks whenever they appropriately realize an activity.
-  Create new task labels whenever no suitable endpoint exists.
-  Never introduce activities that do not contribute directly to the user's requested objective.
-
-Decision Logic
-Create gateways only when they are explicitly implied by the process description, or they are necessary for correct process execution.
-Do not introduce unnecessary branching simply because endpoint outputs could support decisions.
-
-Internal Process-Control Tasks
-Some process descriptions imply internal process-control logic that is not explicitly stated in the text (e.g., loop counters, variable initialization, value calculations, threshold computations, or other data transformations required for routing and execution).
-When necessary to create a complete, executable, and logically consistent process model, additional tasks may be introduced to generate, initialize, update, or transform process data required by gateways, loops, routing decisions, or downstream activities.
-Such tasks represent internal workflow logic rather than business actions. They are allowed only when required to support process execution and data flow. Any variable referenced by a gateway condition or required by a downstream task must have a clear origin in a preceding task.
-Ensure that all decision conditions can be interpreted from preceding tasks. Timer-based conditions (e.g. wait, timeout) may be used directly without additional data derivation steps.
-
-Mermaid BPMN Syntax Specification
-Each Mermaid.js node must have the following structure:
-  id:type:shape and label
-  id: a unique integer from 0 to n.
-  type: BPMN element type → startevent, endevent, task, subprocess, exclusivegateway, inclusivegateway, parallelgateway.
-  Shapes and labels:
-    Start event → id:startevent:((startevent))
-    End event → id:endevent:(((endevent)))
-    Task → id:task:(Task Label)
-    Subprocess → id:subprocess:(Subprocess Label)
-    Exclusive gateway → id:exclusivegateway:{x}
-    Parallel gateway → id:parallelgateway:{AND}
-    Inclusive gateway → id:inclusivegateway:{O}
-
-Hard Structural Rules:
-Tasks:
-  No empty tasks are allowed: every task node must have a descriptive label.
-  “Default branches” between gateways are allowed — i.e., edges that go directly from one gateway to another without any task in between. These represent “nothing happens”.
-
-Gateways:
-  Every split gateway must be matched with a corresponding merge gateway of the same type.
-  No implicit merges are allowed — merges must always be explicit.
-  No split gateway is permitted without a matching merge.
-
-Loop Abstraction:
-  If a process contains repetitive behavior, it MUST NOT be unrolled into repeated tasks.
-  Instead, it MUST be modeled as a loop using an exclusive gateway for loop control.
-  The gateway branches either back to the loop body or to the exit path.
-  For time-based loops, timer or wait tasks may directly provide the loop termination condition. Explicit initialization and update tasks are required only when the process description implies them.
-
-Parallel Logic:
-  Create a parallel gateway when two or more activities must occur concurrently or when one activity controls the duration of another. One branch may establish the termination condition while the other performs the repeated work. Merge parallel branches with a matching parallel gateway.
-
-Flow correctness:
-  Each path/branch must start from the start event and lead to the end event.
-  Each incoming node must have its own separate edge to the target node.
-
-Reused nodes:
-  If a node occurs more than once, reference it by repeating the full node declaration like this - id:type:shape and label (e.g., 2:task:(do something)).
-  It is strictly prohibited to use only the ID (e.g., 2) without type and to use other short versions like id:type (e.g.,2:task).
-
-Edges:
-  All nodes must be connected with -->.
-  Edge labels (for conditions/annotations) must be written as |text| between nodes.
-  Edge label is always located between 2 nodes: id:exclusivegateway:{x} --> |condition or annotation|id:task:(task label)
-
-Simplification Rule:
-  If you cannot generate a model that fully meets all requirements due to the complexity of the description, you must simplify the model until it fully satisfies every requirement.
-
-Generation Procedure
-1. Extract activities from the process description.
-2. Match activities against endpoint capabilities.
-3. Maximize reuse of endpoint-backed tasks by decomposing activities only when appropriate.
-4. Add gateways only when required by the business logic.
-5. Ensure all paths begin at the start event and terminate at the end event.
-
-Mandatory Validation Before Output
-The model is valid only if all of the following are true:
-1) Valid Mermaid.js syntax
-2) Every endpoint-backed task corresponds to one provided endpoint.
-3) Any non-endpoint task exists only because no suitable endpoint is available.
-3) No invented task labels exist for endpoint-backed tasks
-5) No endpoint URLs appear in the diagram
-6) Every split gateway has a matching merge gateway of the same type
-7) No implicit merges exist
-8) Every branch reaches an end path
-9) The process can be interpreted as an executable orchestration over the supplied endpoint catalog
-
-If any validation fails, simplify or restructure the model until all conditions are satisfied.
-Correctness takes precedence over completeness.
-Return only Mermaid.js code. Do not provide explanations, comments, markdown, or additional text.
-
-Example:
-Process Description:
-When a request arrives, validate it. If it is valid, store it and wait 2 seconds.
-
-Available Endpoints
-{
-"https-post://system/validate" =>
-["Validate request",
-"Checks whether a request is valid.",
-"request",
-"validity result (valid/invalid)"],
-"https-post://system/store" =>
-["Store request; Save data",
-"Stores a validated request.",
-"validated request",
-"record id"],
-"https-post://system/timeout" =>
-["Wait; Timeout",
-"Wait for a given duration in seconds.",
-"duration (float)",
-"completion event"]
-}
-
-Generated BPMN Model
-graph LR
-0:startevent:((startevent)) --> 1:task:(Validate request)
-1:task:(Validate request) --> 2:exclusivegateway:{x}
-2:exclusivegateway:{x} --> |valid| 3:task:(Store request)
-2:exclusivegateway:{x} --> |invalid| 4:exclusivegateway:{x}
-3:task:(Store request) --> 5:task:(Wait)
-5:task:(Wait) --> 4:exclusivegateway:{x}
-4:exclusivegateway:{x} --> 6:endevent:(((endevent)))

data/lib/cpee/llm/prompts/identify.txt

@@ -1,25 +0,0 @@
-Consider following predefined change patterns for business process model redesign:
-{
-"cp1":"Insert Process Fragment. Adds a new process fragments between two directly succeeding activities",
-"cp2":"Delete Process Fragment. Removes an existing process fragment and consequently flatten the hierarchy if necessary",
-"cp3":"Move Process Fragment. Shifts an existing process fragment from its current position to a new one",
-"cp4":"Replace Process Fragment. Replaces Process Fragment & replace an existing process fragment with by a new one",
-"cp5":"Swap Process Fragments. Swaps an existing process fragment with another existing process fragment",
-"cp8.1":"Embed Process Fragment in Pre-Conditional Loop. An existing process fragment is embedded in a loop to allow for a repeated execution between 0 and N times",
-"cp8.2":"Embed Process Fragment in Post-Conditional Loop. An existing process fragment is embedded in a loop to allow for a repeated execution between 1 and N times",
-"cp9":"Parallelize Process Fragments. Parallelization of existing process fragments which were confined to be executed in sequence",
-"cp10":"Embed Process Fragment in Conditional Branch. An existing process fragment is embedded in a conditional branch",
-"cp14":"Copy Process Fragment. Copies an existing process fragment and paste it to a new position",
-"cp6":"Extract Sub Process. Extracts an existing process fragment to encapsulate it in a separate sub process",
-"cp7":"Inline Sub Process. Inlines a sub process into the parent process, and consequently flatten the hierarchy of the overall process",
-"cp13":"Update Condition. Updates transition conditions in a process",
-"cp19":"Replace Gateways. Replaces existing gateways (both splitting and merging) in specified fragment simultaneously with the gateways of the other type",
-"cp15":"Split Process Fragment. Splits an existing process fragment into a sequence of multiple separate new process fragments",
-"cp16":"Merge Process Fragment. Merges multiple existing separate process fragments into one new process fragment",
-"cp17":"Delete Entire Branch. Removes single entire branch inside selected gateways and consequently flatten the hierarchy if necessary",
-"cp18":"Leave Single Branch. Replace existing gateways (both splitting and merging) in specified fragment simultaneously with the gateways of the other type"
-}
-
-Classify the user input into one of the predefined change patterns, if a matching pattern exists.
-If a match is found, return only the pattern ID. Only one pattern can be matched.
-If no match is found, return NA. No other information is allowed to be returned!!!

data/lib/cpee/llm/prompts/validate_mermaid.xml

@@ -1,74 +0,0 @@
-Given the relevant the Mermaid.js BPMN model, and the provided Mermaid.js BPMN syntax and structural rules, perform the validation.
-mermaid model: .
-
-Mermaid.js BPMN Syntax:
-- The graph must use the LR (Left to Right) direction.
-- Each Mermaid.js node must have the following structure:
-  id:type:shape and label
-  - id: a unique integer from 0 to n.
-  - type: BPMN element type → startevent, endevent, task, subprocess, exclusivegateway, inclusivegateway, parallelgateway.
-  - Shapes and labels:
-    - Start event → id:startevent:((startevent))
-    - End event → id:endevent:(((endevent)))
-    - Task → id:task:(Task Label)
-    - Subprocess → id:subprocess:(Subprocess Label)
-    - Exclusive gateway → id:exclusivegateway:{x}
-    - Parallel gateway → id:parallelgateway:{AND}
-    - Inclusive gateway → id:inclusivegateway:{O}
-
-Hard Structural Rules:
-- Tasks:
-  - No empty tasks are allowed: every task node must have a descriptive label.
-  - “Default branches” between gateways are allowed — edges that go directly from one gateway to another without any task in between.
-- Gateways:
-  - Every split gateway must be matched with a corresponding merge gateway of the same type.
-  - No implicit merges are allowed — merges must always be explicit.
-  - No split gateway is permitted without a matching merge.
-- Flow correctness:
-  - Each path/branch must start from the start event and lead to the end event.
-  - Each incoming node must have its own separate edge to the target node.
-- Reused nodes:
-  - If a node occurs more than once, reference it by repeating the full node declaration like this - id:type:shape and label (e.g., 2:task:(do something)).
-  - It is strictly prohibited to use only the ID (e.g., 2) without type and to use other short versions like id:type (e.g.,2:task).
-- Edges:
-  - All nodes must be connected with -->.
-  - Edge labels (for conditions/annotations) must be written as |text| between nodes.
-- Simplification Rule:
-  - If you cannot generate a model that fully meets all requirements due to the complexity of the description, you must simplify the model until it fully satisfies every requirement.
-
-### Validation Procedure Summary:
-When validating a Mermaid BPMN graph against the above rules, apply these steps systematically:
-
-1. **Basic Syntax Validation**
-   - Confirm the graph uses LR direction.
-   - Verify all nodes follow the `id:type:shape and label` format with unique integer IDs.
-   - Check every task and subprocess node has a non-empty descriptive label.
-   - Ensure node types are valid BPMN types.
-
-2. **Connectivity Validation**
-   - Confirm all edges use `-->` syntax and connect valid existing nodes.
-   - Ensure exactly one start event and at least one end event exist.
-   - Verify the graph is connected: all nodes are reachable from start and lead to an end event.
-
-3. **Gateway Structural Validation**
-   - Identify all gateways as splits (≥2 outgoing edges) or merges (≥2 incoming edges).
-   - Confirm every split gateway has a corresponding matching merge gateway of the same type.
-   - Ensure no implicit merges (e.g., branches merging into a gateway of a different type without an explicit merge).
-   - Verify all gateways are connected (no isolated gateways).
-
-4. **Task and Subprocess Rules**
-   - Verify no empty task or subprocess nodes.
-   - Confirm tasks are not orphaned: they have both incoming and outgoing edges unless start/end tasks.
-
-5. **Flow Semantics**
-   - Exclusive gateways must have at least two outgoing branches.
-   - Parallel gateways’ splits must be followed by matching merges before continuing.
-   - All paths must start at the start event and lead to an end event.
-
-6. **Reused Nodes Validation**
-   - Each reused node must be fully re-declared (with id:type:shape and label), never referenced by ID only or shorthand.
-
-7. **Simplification Rule**
-   - If any rule above fails, simplify the model by removing redundant gateways or tasks, adding missing merges, or merging sequential gateways until the model fully satisfies all rules.
-
-Return only Mermaid.js code as plain text, without markdown formatting or explanation.