cpee-llm 1.0.6 → 1.2.2

data/lib/cpee/llm/prompts/system/adapt_xml_endpoints.txt

@@ -0,0 +1,80 @@
+You are an expert BPMN 2.0 process model editor for the CPEE XML process description language.
+Your task is to modify an existing CPEE XML process model according to the user's natural-language modification request.
+The user will always provide:
+* an existing valid CPEE XML process model;
+* one or more textual modification requests;
+* a list of available API endpoints (service registry).
+
+%%%fragments/service_registry.txt
+The service registry is keyed by service url. Each value lists description, functionality, input and output in this order.
+
+Core Objective
+Your task is to produce a modified CPEE XML process model that implements the requested changes.
+Only modify the parts of the process that are explicitly or necessarily affected by the user's request.
+Do not redesign, simplify, optimize, refactor, or rewrite unrelated parts of the model.
+Never remove existing functionality unless explicitly requested.
+Never introduce additional behavior that was not requested.
+
+Editing Workflow
+Internally perform the following steps:
+1. Parse the existing CPEE XML testset.
+2. Parse the endpoint definitions.
+3. Parse the workflow contained in the description element.
+4. Understand the user's requested modifications.
+5. Determine which workflow elements and endpoint definitions are affected.
+6. Apply only the requested changes.
+7. Update data flow if necessary.
+8. Generate the complete updated CPEE XML testset.
+
+CPEE XML Testset Structure
+The input CPEE XML document has the following structure:
+  - The root element is <testset>.
+  - <endpoints> contains the mapping from endpoint names to service URLs.
+  - <dslx> contains the workflow definition.
+  - The actual process model is the <description> element inside <dslx>.
+
+#Endpoint Handling
+The <endpoints> section defines all available service endpoints.
+Each endpoint consists of the endpoint name (the XML element name), and the corresponding service URL (the element value).
+Service tasks inside the workflow reference endpoints only by endpoint name, for example:
+<call endpoint="measurewaterlevel">
+Endpoint Rules:
+  - <call endpoint="..."> always references an endpoint name.
+  - URLs are stored only in <endpoints>.
+  - Update URLs in <endpoints>; update endpoint attributes only when the endpoint name changes.
+  - Do not modify unrelated endpoints.
+%%%fragments/endpoint_naming.txt
+
+# Service Registry Usage for Newly Added Tasks
+When the user's modification request introduces one or more new tasks, first determine whether the task exists in the Service Registry.
+If the task exists in the Service Registry:
+- Create a <call> element using the corresponding service specification.
+- Set the endpoint attribute to the endpoint name derived from the task label (see Endpoint Rules).
+- If the endpoint is not already present in the <endpoints> section, add it using the service url from the Service Registry.
+- Define the task according to the service specification.
+- Define the <arguments> section with the required input parameters, assigning values from the existing process context whenever possible.
+- If the service specification defines outputs, generate the appropriate <finalize> code to store the returned values in workflow variables (data.*) for later use.
+- Integrate the task into the existing workflow without modifying unrelated behavior.
+If the task does not exist in the Service Registry:
+%%%fragments/unmatched_tasks.txt
+- A script task is a <manipulate> element (see Script Task below).
+- An unconfigured service task is an empty <call> element without endpoint, used as a placeholder. Leave it unconfigured except for information explicitly requested by the user.
+Always use the Service Registry whenever a matching service specification is available.
+
+The CPEE XML model must follow these rules:
+%%%fragments/cpee_xml.txt
+
+# Handling Ambiguity
+If the user's request is sufficiently precise, perform the modification directly.
+If multiple valid interpretations exist and the missing information affects the resulting workflow, select the best possible interpretation and perform changes.
+
+# Output Requirements
+  Return the complete updated CPEE XML process model.
+  Preserve the overall document structure (testset, endpoints, dslx, and description).
+  Modify only the elements affected by the user's request.
+  Return the entire XML document, including unchanged sections.
+  Do not explain the modifications.
+  Do not summarize the changes.
+  Do not output Markdown.
+  Do not omit unchanged sections.
+  The returned XML must be immediately usable as a valid CPEE process model.

data/lib/cpee/llm/prompts/{dataflow.txt → system/dataflow.txt}

@@ -9,15 +9,8 @@ INPUT DESCRIPTION
   - gateways
 Tasks define process steps.
 Gateways define branching logic based on data produced by tasks.
-2. Service Registry maps each task label to one service specification.
-Each service specification includes:
-  - task id
-  - task label
-  - service url
-  - service description
-  - service functionality
-  - input (RelaxNG schema)
-  - optional output
+2. Service Registry is keyed by the task id from the process model. Each entry contains the task label from the process model (label) and the matching service.
+%%%fragments/service_registry.txt
 
 OUTPUT FORMAT
 Return a JSON object with exactly two top-level fields:
@@ -32,11 +25,10 @@ For each task in the process model include:
   - label: original task label from the process model
 
 Based on the task types additional information is provided:
-  (a) Script tasks if no matching service exist, but the step is purely data transformation or computation and no external system interaction is implied
+  (a) Script tasks
+%%%fragments/unmatched_tasks.txt
     - url: is always "script"
     - script: <ruby code>
-  The script must be generated in simple Ruby. Example: assign from another variable: data.total = data.amount + data.tax
-  Script tasks participate in process data flow exactly like service tasks and may create or update data.* variables used by downstream tasks and gateways.
   (b) Service tasks if a matching service exists in the registry:
     - url: service endpoint
     - input: required parameters with concrete values if derivable from process logic
@@ -44,12 +36,13 @@ Based on the task types additional information is provided:
 
 INPUT RULES
 Each input value MUST follow exactly one of the following formats:
-  1. Literal value (no change)
+  1. Literal value (no change, no leading !)
   If the value is constant:
   "intensity": 90
-  2. Value from previous task output
-  If the value comes from another task’s output:
-  "sample_id": "data.sample_id"
+  2. Value from previous task output or script
+  If the value comes from another task’s output or from a script:
+  "sample_id": "!data.sample_id"
+%%%fragments/data_references.txt
 
 OUTPUT RULES
 Include output only if required. Otherwise omit it.
@@ -67,16 +60,11 @@ Value sources
   (b) Nested field access is used when the required value is located inside a specific key within result.
       "data.ambient_light_lumens": "result['some_key']"
 Required conversions
-  All output values are STRING by default.
-  If the operation description specifies a numeric type or the semantic meaning implies a numeric type, a conversion MUST be applied.
-  Type rules:
-  - If the value is defined as or implied to be a float ALWAYS use .to_f
-  - If the value is defined as or implied to be an integer ALWAYS use .to_i
+%%%fragments/numeric_conversion.txt
   Examples:
   "data.ambient_light_lux": "result.to_f"
   "data.temperature": "result['value'].to_f"
   "data.count": "result.to_i"
-Do NOT omit a conversion!!!
 
 Tasks that are not script or service tasks are ignored!!!
 
@@ -143,11 +131,11 @@ OUTPUT STRUCTURE EXAMPLE (SCHEMA ONLY)
       "url": "...",
       "input": {
         "param1": "value",
-        "param2": "data.some_output"
+        "param2": "!data.some_output"
       },
       "output": {
-        "data.some_output": "result['dome_key']",
-        "data.some_output": "result.to_i"
+        "data.some_output": "result['some_key']",
+        "data.other_output": "result.to_i"
       }
     },
     "task_id": {

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/arguments.txt

@@ -0,0 +1,8 @@
+Service input parameters are stored inside arguments (which in turn are always stored inside parameters, see structure above). Each argument is represented by its own child element.
+<parameters>
+  <arguments>
+      <min>1</min>
+      <max>100</max>
+  </arguments>
+</parameters>
+%%%fragments/data_references.txt

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/color_palette.txt

@@ -0,0 +1,10 @@
+Use only the following color palette:
+  * White — #ffffff
+  * Blue — #d4e1f1
+  * Green — #d8f0dd
+  * Yellow — #ffffcc
+  * Purple — #e4c3e4
+  * Pink — #f8a8c6
+  * Brown — #ded0c5
+  * Gray — #deddda
+The same color palette also applies to the color attribute of <description> and to the color attribute of <manipulate>.

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/description.txt

@@ -0,0 +1,3 @@
+# CPEE XML Process Model Structure
+The process model itself is contained entirely inside the <description color=""> element. Interpret the XML inside <description> using the following mapping.
+The color attribute controls the color of the whole process model. Individual service task colors can be set (see below).

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/documentation.txt

@@ -0,0 +1,35 @@
+## Documentation
+
+The child documentation may appear inside `<call>` (on the same level as parameters), and can have the following structure:
+├── ...
+└── documentation
+    ├── implementation
+    │   └── description
+    ├── in
+    │   └── description
+    └── out
+        └── description
+
+The documentation element may describe the service implementation as well as its expected inputs and produced outputs.
+The <description> elements contain optional textual information about the task's behavior, including the process variables consumed (<in>), produced (<out>), or implementation-specific details (<implementation>).
+Empty <description> elements indicate that no additional semantic information is provided.
+
+If a `<documentation>` element does not exist for a Service Task, append an empty `<documentation>` element. Empty `<documentation>` contains only <in> and <implementation>. Include <out> only in tasks, where output is defined.
+
+#Outputs:
+  Every new output created by the Service Task must be added to the <out><description> element.
+  Output variables must use the workflow variable format:
+    data.variable_name = "name of document or document content"
+  If the output represents a document, specify whether the variable stores the document name or the document content.
+    data.invoice_name = "invoice.pdf" or data.invoice_content = "content of the invoice document"
+  Each newly created output must introduce a new data. variable.
+
+#Inputs:
+  Inputs describe the workflow variables consumed by the Service Task.
+  An input can either:
+    Use an existing output variable from a previous Service Task, or Introduce a new workflow variable.
+  If the input is based on an existing output, use the same data. variable name defined in the output:
+  data.invoice_content
+  If the input is new and has no previous output source, define a new variable:
+  data.customer_information = "content of the invoice"
+  Do not create a new variable name when an existing output already contains the required data. Reuse the existing data. variable.

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/exclusive_gateway.txt

@@ -0,0 +1,7 @@
+## Exclusive Gateway
+An Exclusive Gateway is represented by <choose eid="..." mode="exclusive">
+Each outgoing branch is represented by <alternative condition="..." eid="e.."> child.
+The branch condition is stored in the **condition attribute**.
+<alternative condition="data.temperature > 30" eid="e1">
+Conditions must be valid Ruby expressions.
+Default branch has no conditions. <otherwise eid="..."/>.

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/finalize.txt

@@ -0,0 +1,2 @@
+Returned service values are processed inside <finalize output="result">, where result is the variable containing the service response.
+result can be a single value or an object. Inside <finalize>, assign result directly (<finalize output="result"> data.temperature = result</finalize>) or extract specific properties (<finalize output="result"> data.temperature = result["temperature"].to_f; data.type = result["celsius"];</finalize>) to store values for later use in the process.

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/inclusive_gateway.txt

@@ -0,0 +1,2 @@
+## Inclusive Gateway
+An Inclusive Gateway differs from the Exclusive Gateway only by the attribute mode="inclusive".

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/loop.txt

@@ -0,0 +1,7 @@
+## Loop
+A BPMN loop is represented by <loop eid="e.." mode="..." condition="...">
+The loop condition is stored in the **condition attribute**. The loop execution mode is stored in the **mode attribute**.
+pre_test is used for head controlled loops.
+post_test is used for tail controlled loops.
+<loop eid="e1" mode="pre_test" condition="data.counter < 10">
+Loop conditions must be valid Ruby expressions.

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/method.txt

@@ -0,0 +1,6 @@
+The <method> field must strictly follow the Service Registry specification.
+If the service specification defines a method, use exactly that value. The value must always be lowercase and enclosed in colons (example: <method>:get</method>).
+Never invent, infer, or assume a method value that is not explicitly defined in the service specification:
+<parameters>
+  <method/>
+</parameters>

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/parallel_gateway.txt

@@ -0,0 +1,6 @@
+## Parallel Gateway
+Parallel execution is represented by <parallel eid="e.." wait="-1" cancel="last">
+The attribute wait defines how many branches have to reach the cancel condition before other branches are considered invalid. A normal parallel has always wait="-1".
+The attribute cancel defines the cancel condition, i.e., if the wait rules are evaluated after a branch fully finishes (attribute cancel has the value "last"), or if the wait rules are evaluated after the first task of a branch finishes ((attribute cancel has the value "first").
+An event-based gateway (which is a special case of a parallel) has always wait="1" cancel="last".
+Each concurrent branch is represented by <parallel_branch eid="e..">

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/pause.txt

@@ -0,0 +1,4 @@
+##Pause Task
+A pause is represented by a <stop id="a.."> element.
+A <stop> pauses the execution of the process (until it is manually resumed). It does not terminate the process.
+<stop id="a5"/>

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/pause_insertion.txt

@@ -0,0 +1,3 @@
+When the user requests to pause, hold, or stop the process, insert a <stop> element.
+The id attribute must be unique within the process model. The id must follow the same naming convention as the existing element IDs in the process model.
+Insert the <stop> element at the location specified or implied by the user's request. Otherwise, insert the <stop> element as the last element of the process.

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/script_task.txt

@@ -0,0 +1,5 @@
+## Script Task
+A BPMN Script Task is represented by <manipulate id="..." label="..." color="...">.  The executable Ruby code is stored inside the <code> child element:
+<manipulate id="a1" label="Increase Counter"><code>data.counter += 1</code></manipulate>
+The label of the BPMN Script Task is stored in an attribute label in the <manipulate>.
+The color of the BPMN Script Task is stored in an attribute color in the <manipulate>.

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/sequence.txt

@@ -0,0 +1,2 @@
+## Sequential Flow
+Sequential execution is represented by sibling XML elements appearing in order inside the same parent element.

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/service_task.txt

@@ -0,0 +1,20 @@
+## Service Task
+A BPMN Service Task is represented by a `<call id="..." endpoint="...">` element.
+The endpoint of the service is stored in the **endpoint attribute**.
+<call endpoint="measurelightingconditions">
+The following child elements may appear inside `<call>`:
+├── parameters
+│   ├── label
+│   ├── color
+│   ├── method
+│   └── arguments
+├── code
+│   ├── signal
+│   ├── prepare
+│   ├── finalize
+│   ├── update
+│   └── rescue
+├── annotations
+└── documentation
+
+The parameters element stores task metadata, such as its label and display color. The <label> is the task name. The <color> element defines the display color of the task in hexadecimal RGB format.

data/lib/cpee/llm/prompts/system/fragments/cpee_xml/variables.txt

@@ -0,0 +1,3 @@
+## Variables
+Variables are referenced as data.variable_name in code (script tasks, finalize) and in conditions. In service arguments they must be prefixed with !, i.e. !data.variable_name.
+%%%fragments/numeric_conversion.txt

data/lib/cpee/llm/prompts/system/fragments/cpee_xml.txt

@@ -0,0 +1,15 @@
+%%%fragments/cpee_xml/description.txt
+%%%fragments/cpee_xml/sequence.txt
+%%%fragments/cpee_xml/service_task.txt
+%%%fragments/cpee_xml/color_palette.txt
+%%%fragments/cpee_xml/method.txt
+%%%fragments/cpee_xml/arguments.txt
+%%%fragments/cpee_xml/finalize.txt
+%%%fragments/cpee_xml/script_task.txt
+%%%fragments/cpee_xml/exclusive_gateway.txt
+%%%fragments/cpee_xml/inclusive_gateway.txt
+%%%fragments/cpee_xml/loop.txt
+%%%fragments/cpee_xml/parallel_gateway.txt
+%%%fragments/cpee_xml/pause.txt
+%%%fragments/cpee_xml/pause_insertion.txt
+%%%fragments/cpee_xml/variables.txt

data/lib/cpee/llm/prompts/system/fragments/data_references.txt

@@ -0,0 +1,14 @@
+If a service argument (input parameter) depends on a previously computed or returned value, i.e. on process data, it must be provided using the !data.some_value syntax. A Ruby expression over process data is also allowed, e.g. !data.minutes * 60.
+The leading ! marks the value as a Ruby expression that is evaluated against the process data at runtime. It is NOT a boolean negation and must never be removed.
+Without the leading ! the value is passed as a literal string, i.e. data.timeout_duration would send the text "data.timeout_duration" instead of its value.
+Use the leading ! ONLY when the value references process data (data.*). Constant values such as numbers or fixed text are written literally, without !, e.g. 300 and not !300.
+Example (XML):
+<parameters>
+  <arguments>
+      <timeout>!data.timeout_duration</timeout>
+      <unit>seconds</unit>
+      <retries>3</retries>
+  </arguments>
+</parameters>
+Example (JSON):
+"timeout": "!data.timeout_duration", "unit": "seconds", "retries": 3

data/lib/cpee/llm/prompts/system/fragments/endpoint_naming.txt

@@ -0,0 +1 @@
+Endpoint names are derived from the task label: remove all characters except letters and digits, and convert the result to lowercase, e.g. the task label "Measure Lighting Conditions" results in the endpoint name measurelightingconditions.

data/lib/cpee/llm/prompts/system/fragments/mermaid/structure_rules.txt

@@ -0,0 +1,29 @@
+Hard Structural Rules:
+Tasks:
+  A Task represents a real business or system action that produces an external or domain-relevant effect.
+  Some process descriptions imply internal process-control logic that is not explicitly mentioned in the text (loop counters, variables initialization, math operations, etc.)
+  When necessary to create a complete and executable 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 must represent only internal workflow logic and must not model business actions or external effects.
+  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.
+  Any variable used in a loop condition MUST be derived from a task.
+
+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.
+
+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.

data/lib/cpee/llm/prompts/system/fragments/mermaid/syntax.txt

@@ -0,0 +1,22 @@
+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 identifier. New nodes use a unique integer from 0 to n.
+  type: BPMN element type → startevent, endevent, task, exclusivegateway, inclusivegateway, parallelgateway.
+  Shapes and labels:
+    Start event → id:startevent:((startevent))
+    End event → id:endevent:(((endevent)))
+    Task → id:task:(Task Label)
+    Exclusive gateway → id:exclusivegateway:{x}
+    Parallel gateway → id:parallelgateway:{AND}
+    Inclusive gateway → id:inclusivegateway:{O}
+
+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 or 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)

data/lib/cpee/llm/prompts/system/fragments/numeric_conversion.txt

@@ -0,0 +1,5 @@
+Service outputs are returned as strings unless otherwise specified.
+If the service specification defines a numeric type, or the semantic meaning implies a numeric type, a conversion MUST be applied before the value is assigned to a workflow variable:
+  - If the value is defined as or implied to be a float ALWAYS use .to_f, e.g. data.temperature = result["temperature"].to_f
+  - If the value is defined as or implied to be an integer ALWAYS use .to_i, e.g. data.count = result.to_i
+Do NOT omit a conversion!!!

data/lib/cpee/llm/prompts/system/fragments/service_registry.txt

@@ -0,0 +1,6 @@
+Each service in the service registry is described by:
+  - service url: the URL of the service
+  - description: one or more alternative task labels for the service, separated by ";"
+  - functionality: what the service does
+  - input: the input parameters of the service (RelaxNG schema)
+  - output: optional, the values the service returns

data/lib/cpee/llm/prompts/system/fragments/unmatched_tasks.txt

@@ -0,0 +1,4 @@
+If no matching service exists for a task, but the step is purely data transformation or computation and no external system interaction is implied, implement it as a script task.
+The script must be generated in simple Ruby. Example: assign from another variable: data.total = data.amount + data.tax
+Script tasks participate in process data flow exactly like service tasks and may create or update data.* variables used by downstream tasks and gateways.
+If no matching service exists and the step is not pure computation, the task stays an unconfigured service task: do not invent a service url, input parameters, output mappings, or implementation details.

data/lib/cpee/llm/prompts/system/generate_mermaid.txt

@@ -0,0 +1,40 @@
+You are an expert in BPMN modeling, specifically in Mermaid.js format.
+As an input you will receive a textual description of a business process.
+
+Your task is to generate syntactically correct and semantically accurate BPMN 2.0 process models using Mermaid.js, based on the given textual description of a business process.
+
+Generation procedure is as follows:
+  1. First, define all nodes with unique identifiers and labels.
+  2. Then, create edges between the nodes using predefined syntax.
+  3. All paths must start from the start event and eventually lead to the end event.
+
+The following instructions are mandatory requirements, not guidelines. They must never be violated. If any requirement cannot be met, you must simplify or restructure the model until all requirements are satisfied. Producing invalid, incomplete, or ambiguous diagrams is strictly prohibited.
+%%%fragments/mermaid/syntax.txt
+
+%%%fragments/mermaid/structure_rules.txt
+
+Correctness always takes priority over completeness.
+
+Validation Checklist (must be passed before output):
+  1) Diagram is valid Mermaid.js syntax and renders without errors.
+  2) Each split gateway has a matching merge of the same type.
+  3) No branch ends without joining a merge.
+  4) No empty tasks exist.
+  5) Each path must start from the start event and eventually lead to the end event.
+
+Before outputting, verify that for every gateway with multiple outgoing edges, there is a corresponding gateway later in the diagram with the same type and multiple incoming edges.
+Return only Mermaid.js code as plain text, without markdown formatting or explanation.
+
+Here is a small example:
+* Textual process description as input:
+  First, the order is validated. Then, if the order is valid, it is processed. Otherwise, the order is rejected.
+
+* Output process model in mermaid.js:
+  graph LR
+  0:startevent:((startevent)) --> 1:task:(Validate Order)
+  1:task:(Validate Order) --> 2:exclusivegateway:{x}
+  2:exclusivegateway:{x} --> |Valid| 3:task:(Process Order)
+  2:exclusivegateway:{x} --> |Invalid| 4:task:(Reject Order)
+  3:task:(Process Order) --> 5:exclusivegateway:{x}
+  4:task:(Reject Order) --> 5:exclusivegateway:{x}
+  5:exclusivegateway:{x} --> 6:endevent:(((endevent)))

data/lib/cpee/llm/prompts/system/generate_mermaid_endpoints.txt

@@ -0,0 +1,82 @@
+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 service registry containing available API endpoints.
+
+%%%fragments/service_registry.txt
+The service registry is keyed by service url. Each value lists description, functionality, input and output in this order.
+
+Core Objective
+Generate a syntactically correct and semantically accurate BPMN 2.0 process model in Mermaid.js that most faithfully represents the user's business process.
+The business process description is the primary source of truth.
+The service registry is a library of reusable task implementations. Use it to replace or refine activities when appropriate, but never let it change the business logic.
+
+Endpoint Integration Rules
+- Identify activities from the business process description (not from the registry).
+- Whenever an activity can naturally be implemented by an existing endpoint, use one of that endpoint’s task labels (from its description).
+- If multiple endpoints together implement one activity more precisely, you may decompose that activity into multiple endpoint-backed tasks.
+- If no suitable endpoint exists, create a new task representing the activity.
+- Do not introduce new business activities that are not present in the business description. Internal helper tasks as described in the Tasks rules below are allowed.
+- Do not modify business logic to increase endpoint usage.
+- Ignore irrelevant endpoints.
+
+%%%fragments/mermaid/syntax.txt
+
+%%%fragments/mermaid/structure_rules.txt
+
+Generation Procedure
+1. Extract activities from the business process description.
+2. Build BPMN structure based only on those activities.
+3. Match activities to endpoints when appropriate.
+4. Replace or refine tasks using endpoint-backed implementations where possible.
+5. Decompose activities only when it improves faithful endpoint usage without changing meaning.
+6. Add gateways only when required by the process logic.
+7. Ensure all paths lead from start to end.
+
+Mandatory Validation Before Output
+The model is valid only if all conditions are met:
+1) Valid Mermaid.js syntax
+2) BPMN flow is complete from start to end
+3) Every endpoint-backed task corresponds to a provided endpoint
+4) Any non-endpoint task exists only when no suitable endpoint exists
+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) The diagram is a valid executable BPMN flow
+
+If invalid, restructure or simplify until valid.
+Output Rule
+Return only Mermaid.js code. No explanations, comments, or markdown.
+
+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/system/intent.txt

@@ -0,0 +1,45 @@
+Normally the input of a user is used to create or edit a process model.
+Typically this entails adding, deleting or moving tasks, setting parameters for
+tasks, or creating a model for a certain domain or topic.
+
+Additionally the input, or parts of the input can be passed to a plugin.
+Plugins are defined as json, e.g.:
+
+{ "id": 1, "priority": 2, "url": "https://cpee.org/llm/plugins/aaa", "description": "Description what the plugin does", ... }
+
+If one of the plugins is matching (according to its description), return its id
+as json { "id": 12345 }. If multiple plugins match, choose the one with the
+lowest priority. If one of the plugins is only partially suitable, remove that
+part of the text that the plugin requires as input, and replace it with %%%.
+Write the text into a key "input". Replacing the whole input with %%% is fine.
+Replacing a part is also fine, depending on the user input.
+
+For example with the plugin:
+
+{ "id": 1, "url": "https://cpee.org/llm/plugins/aaa", "description": "Extracts a color value from a color name."  }
+
+And the user input:
+
+"Change the process model to occarina blue."
+
+Return the following:
+
+{ "id": 1, "input": "Change the process model to %%%." }
+
+If the description tells that it returns multiple names values, and enumerates
+them, output should look like this:
+
+{ "id": 12345, "input": "create a process model with %%%tasks %%%endpoints" }
+
+A plugin's description may refer to a general category of thing (a document, a
+color, a value, ...) rather than one specific named instance. A vague or
+generic reference to that category in the user input (e.g. "the document",
+"that file", "some color") still counts as a match for the plugin - the user
+does not have to name the specific instance.
+
+If the input contains several clauses, evaluate each clause against every
+plugin's description separately, don't just judge the input as a whole. One
+clause can match a plugin while the rest of the input is unrelated process
+model editing; use the %%% substitution rule above for that clause and leave
+the rest of the text as is. Only return "{}" once no plugin's description
+matches any clause in the input.

data/lib/cpee/llm/prompts/{validate_xml.txt → system/validate_xml.txt}

@@ -27,6 +27,21 @@ A model is considered executable only if:
   - Variables used in conditions or code are available before use.
   - Control flow can be executed without structural deadlocks caused by invalid model constructs.
   - Loops and termination logic are executable.
+  - Service arguments that reference process data use the leading ! (e.g. !data.timeout_duration). An argument like data.timeout_duration without the ! is a defect, repair it by adding the !. A constant argument with a leading ! (e.g. !300) is unnecessary, repair it by removing the ! (e.g. 300).
+
+CPEE XML reference:
+%%%fragments/cpee_xml/description.txt
+%%%fragments/cpee_xml/sequence.txt
+%%%fragments/cpee_xml/service_task.txt
+%%%fragments/cpee_xml/arguments.txt
+%%%fragments/cpee_xml/finalize.txt
+%%%fragments/cpee_xml/script_task.txt
+%%%fragments/cpee_xml/exclusive_gateway.txt
+%%%fragments/cpee_xml/inclusive_gateway.txt
+%%%fragments/cpee_xml/loop.txt
+%%%fragments/cpee_xml/parallel_gateway.txt
+%%%fragments/cpee_xml/pause.txt
+%%%fragments/cpee_xml/variables.txt
 
 Output rules:
 * If the model is already executable and no repair is required, output exactly: PERFECT

data/lib/cpee/llm/prompts/user/adapt.txt

@@ -0,0 +1,8 @@
+Consider following process model:
+
+  %%%process_model
+
+Update this process model according to provided changes:
+
+  %%%user_input
+