cpee-llm 1.1.0 → 1.2.2

data/cpee-llm.gemspec

@@ -1,13 +1,13 @@
 Gem::Specification.new do |s|
   s.name             = "cpee-llm"
-  s.version          = "1.1.0"
+  s.version          = "1.2.2"
   s.platform         = Gem::Platform::RUBY
-  s.license          = "LGPL-3.0-or-later"
+  s.license          = "GPL-3.0-or-later"
   s.summary          = "CPEE Conversational Agents"
 
   s.description      = "see http://cpee.org"
 
-  s.files            = Dir['{server/*,tools/**/*,lib/**/*}'] + %w(LICENSE Rakefile cpee-llm.gemspec README.md AUTHORS)
+  s.files            = Dir['{server/*,tools/**/*,lib/**/*}'] - Dir['lib/cpee/llm/prompts/legacy{,/**/*}'] + %w(LICENSE Rakefile cpee-llm.gemspec README.md AUTHORS)
   s.require_path     = 'lib'
   s.extra_rdoc_files = ['README.md']
   s.bindir           = 'tools'

data/lib/cpee/llm/dataflow.rb

@@ -1,16 +1,16 @@
 # This file is part of CPEE-LLM.
 #
 # CPEE-LLM is free software: you can redistribute it and/or modify it under the
-# terms of the GNU Lesser General Public License as published by the Free
+# terms of the GNU General Public License as published by the Free
 # Software Foundation, either version 3 of the License, or (at your option) any
 # later version.
 #
 # CPEE-LLM is distributed in the hope that it will be useful, but WITHOUT ANY
 # WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
-# A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more
+# A PARTICULAR PURPOSE. See the GNU General Public License for more
 # details.
 #
-# You should have received a copy of the GNU Lesser General Public License
+# You should have received a copy of the GNU General Public License
 # along with CPEE-LLM (file LICENSE in the main directory). If not, see
 # <http://www.gnu.org/licenses/>.
 

data/lib/cpee/llm/functions.rb

@@ -1,16 +1,16 @@
 # This file is part of CPEE-LLM.
 #
 # CPEE-LLM is free software: you can redistribute it and/or modify it under the
-# terms of the GNU Lesser General Public License as published by the Free
+# terms of the GNU General Public License as published by the Free
 # Software Foundation, either version 3 of the License, or (at your option) any
 # later version.
 #
 # CPEE-LLM is distributed in the hope that it will be useful, but WITHOUT ANY
 # WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
-# A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more
+# A PARTICULAR PURPOSE. See the GNU General Public License for more
 # details.
 #
-# You should have received a copy of the GNU Lesser General Public License
+# You should have received a copy of the GNU General Public License
 # along with CPEE-LLM (file LICENSE in the main directory). If not, see
 # <http://www.gnu.org/licenses/>.
 
@@ -59,8 +59,8 @@ module CPEE
 
       def generate_model(myllm,user_input,temperature,llms) #{{{
         error_handler do
-          system_prompt = build_system_prompt("generate1.txt")
-          user_prompt = build_user_prompt("process_description.txt", user_input:)
+          system_prompt = build_system_prompt("generate_mermaid.txt")
+          user_prompt = build_user_prompt("generate_mermaid.txt", user_input:)
           llm_response = generate_content(myllm,system_prompt,user_prompt,4000,temperature,llms)
           # raise exceptions if response is empty for some reason
           if llm_response.nil? || llm_response.empty?
@@ -75,8 +75,8 @@ module CPEE
         input_cpee = doc.to_s()
         input_mermaid = cpee_to_mermaid(doc.to_s())
         error_handler do
-          system_prompt = build_system_prompt("apply.txt")
-          user_prompt = build_user_prompt("process_model_adapt.txt", user_input:, process_model: input_mermaid)
+          system_prompt = build_system_prompt("adapt_mermaid.txt")
+          user_prompt = build_user_prompt("adapt.txt", user_input:, process_model: input_mermaid)
           llm_response = generate_content(myllm,system_prompt,user_prompt,4000,0,llms)
           # raise exceptions if response is empty for some reason
           if llm_response.nil? || llm_response.empty?
@@ -90,8 +90,8 @@ module CPEE
       def adapt_doccpee_description(myllm,doc,user_input,llms) #{{{
         input_cpee = doc.to_s()
         error_handler do
-          system_prompt = build_system_prompt("adapt_docxml_description.txt")
-          user_prompt = build_user_prompt("process_model_adapt.txt", user_input:, process_model: input_cpee)
+          system_prompt = build_system_prompt("adapt_xml_documentation.txt")
+          user_prompt = build_user_prompt("adapt.txt", user_input:, process_model: input_cpee)
           llm_response = generate_content(myllm,system_prompt,user_prompt,16000,0,llms)
           # raise exceptions if response is empty for some reason
           if llm_response.nil? || llm_response.empty?
@@ -120,7 +120,7 @@ module CPEE
 
         error_handler do
           system_prompt = build_system_prompt("adapt_xml_endpoints.txt")
-          user_prompt = build_user_prompt("process_model_adapt_api.txt", user_input:, process_model: testset, api_specification: endpoints)
+          user_prompt = build_user_prompt("adapt_xml_endpoints.txt", user_input:, process_model: testset, api_specification: endpoints)
           llm_response = generate_content(myllm,system_prompt,user_prompt,15000,0,llms)
           # raise exceptions if response is empty for some reason
           if llm_response.nil? || llm_response.empty?
@@ -144,8 +144,8 @@ module CPEE
         input_cpee = doc.to_s()
         input_mermaid = cpee_to_mermaid(doc.to_s())
         error_handler do
-          system_prompt = build_system_prompt("describe.txt")
-          user_prompt = build_user_prompt("process_model_text.txt", user_input: input_mermaid)
+          system_prompt = build_system_prompt("describe_text.txt")
+          user_prompt = build_user_prompt("describe_text.txt", user_input: input_mermaid)
           llm_response = generate_content(myllm,system_prompt,user_prompt,4000,0,llms)
           # raise exceptions if response is empty for some reason
           if llm_response.nil? || llm_response.empty?
@@ -195,8 +195,8 @@ module CPEE
 
       def generate_endpoint_model(myllm,user_input,endpoints,llms) #{{{
         error_handler do
-          system_prompt = build_system_prompt("generate_enpoints.txt")
-          user_prompt = build_user_prompt("process_description_endpoints.txt", user_input:, endpoints:)
+          system_prompt = build_system_prompt("generate_mermaid_endpoints.txt")
+          user_prompt = build_user_prompt("generate_mermaid_endpoints.txt", user_input:, endpoints:)
           llm_response = generate_content(myllm,system_prompt,user_prompt,4000,0.1,llms)
           # raise exceptions if response is empty for some reason
           if llm_response.nil? || llm_response.empty?
@@ -210,7 +210,7 @@ module CPEE
       def validate_cpee_model(myllm,cpee_model,llms) #{{{
         error_handler do
           system_prompt = build_system_prompt("validate_xml.txt")
-          user_prompt = build_user_prompt("cpee_repair.txt", cpee_model:)
+          user_prompt = build_user_prompt("validate_xml.txt", cpee_model:)
           llm_response = generate_content(myllm,system_prompt,user_prompt,0,0.1,llms)
           if llm_response.nil? || llm_response.empty?
             raise LLMError.new("Something went wrong and your content was not generated!", 500)
@@ -224,7 +224,7 @@ module CPEE
             begin
               XML::Smart.string(llm_response)
             rescue Nokogiri::XML::SyntaxError => e
-              raise LLMError.new("Something went wrong and llm was not able to generate valid xml model", llm_response)
+              raise LLMError.new("Something went wrong and llm was not able to generate valid xml model", 500)
             end
             return llm_response
           end

data/lib/cpee/llm/implementation.rb

@@ -1,16 +1,16 @@
 # This file is part of CPEE-LLM.
 #
 # CPEE-LLM is free software: you can redistribute it and/or modify it under the
-# terms of the GNU Lesser General Public License as published by the Free
+# terms of the GNU General Public License as published by the Free
 # Software Foundation, either version 3 of the License, or (at your option) any
 # later version.
 #
 # CPEE-LLM is distributed in the hope that it will be useful, but WITHOUT ANY
 # WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
-# A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more
+# A PARTICULAR PURPOSE. See the GNU General Public License for more
 # details.
 #
-# You should have received a copy of the GNU Lesser General Public License
+# You should have received a copy of the GNU General Public License
 # along with CPEE-LLM (file LICENSE in the main directory). If not, see
 # <http://www.gnu.org/licenses/>.
 
@@ -199,7 +199,7 @@ module CPEE
           llm_response = validate_cpee_model(myllm,input_cpee,llms)
         rescue LLMError => e
           @status = e.http_response
-          return Riddl::Parameter::Complex.new("generic_out","application/json",{:error => e.message}.to_json())
+          return Riddl::Parameter::Complex.new("llm_out","application/json",{:error => e.message}.to_json())
         end
 
         return(Riddl::Parameter::Complex.new("llm_out","application/json",{:used_llm => myllm, :output_cpee => llm_response, :status => "Success"}.to_json()))

data/lib/cpee/llm/implementation.xml

@@ -2,16 +2,17 @@
   This file is part of CPEE-LLM.
 
   CPEE-LLM is free software: you can redistribute it and/or modify it under the
-  terms of the GNU General Public License as published by the Free Software
-  Foundation, either version 3 of the License, or (at your option) any later
-  version.
+  terms of the GNU General Public License as published by the Free
+  Software Foundation, either version 3 of the License, or (at your option) any
+  later version.
 
   CPEE-LLM is distributed in the hope that it will be useful, but WITHOUT ANY
   WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
-  A PARTICULAR PURPOSE.  See the GNU General Public License for more details.
+  A PARTICULAR PURPOSE. See the GNU General Public License for more
+  details.
 
-  You should have received a copy of the GNU General Public License along with
-  CPEE-LLM (file LICENSE in the main directory). If not, see
+  You should have received a copy of the GNU General Public License
+  along with CPEE-LLM (file LICENSE in the main directory). If not, see
   <http://www.gnu.org/licenses/>.
 -->
 

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

@@ -0,0 +1,12 @@
+You are an expert in BPMN modeling, specifically in Mermaid.js format.
+Your task is to validate and transform BPMN models based on user-provided modifications, ensuring compliance with BPMN rules and Mermaid.js syntax.
+You are allowed to adjust only those parts of the process model mentioned in the user-provided modification. Other parts of the model have to stay unchanged.
+
+%%%fragments/mermaid/syntax.txt
+
+The provided process model may contain nodes whose ids are not integers (e.g., a1, g0s) and nodes of type script (e.g., a3:script:(Compute Total)). Keep these ids and types unchanged. Only new nodes get new unique integer ids.
+
+All gateways must have both a split and a merge point.
+Each gateway that initiates a split must be properly closed by a merge gateway of the same type (e.g., an exclusive gateway must be merged by another exclusive gateway).
+
+Return only mermaid.js as text without any additional information! Give me just the raw Mermaid.js code without markdown formatting.

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

@@ -14,17 +14,17 @@ Never introduce additional behavior that was not requested.
 Editing Workflow
 Internally perform the following steps:
 1. Parse the existing CPEE XML description.
-3. Parse the workflow contained in the description element.
-4. Understand the user's requested modifications.
-5. Determine which workflow elements are affected.
-6. Apply only the requested changes.
-7. Update documentation flow if necessary.
-8. Generate the complete updated CPEE XML description.
+2. Parse the workflow contained in the description element.
+3. Understand the user's requested modifications.
+4. Determine which workflow elements are affected.
+5. Apply only the requested changes.
+6. Update documentation flow if necessary.
+7. Generate the complete updated CPEE XML description.
 
-%%%cpee_xml.txt
-%%%cpee_xml_documentation_modelling.txt
+%%%fragments/cpee_xml.txt
+%%%fragments/cpee_xml/documentation.txt
 
-For the purpose of modelling, arguments can be ignored and dont have to cary anny values. Code also can be left empty.
+For the purpose of modelling, arguments can be ignored and don't have to carry any values. Code also can be left empty. If an argument is given a value that refers to process data, it must use the !data.some_value syntax described above.
 
 # Handling Ambiguity
 If the user's request is sufficiently precise, perform the modification directly.
@@ -34,8 +34,8 @@ If multiple valid interpretations exist and the missing information affects the
 If user deletes a single task in a branch, remove task but leave the branch. Use default branch.
 eid attributes are IDs. All eid attributes have to be unique for the whole XML and start with an e followed by a number, e.g., "e1".
 id attributes are IDs. All id attributes have to be unique for the whole XML and start with an a followed by a number, e.g., "a1".
-Don't change ANY existing id's or eid's. Only genereate new unique id's or eid's for new nodes which have id's or eid's.
-Don't change existing nodes, even when you move them. For example dont add documentation if it is not there.
+Don't change ANY existing id's or eid's. Only generate new unique id's or eid's for new nodes which have id's or eid's.
+Don't change existing nodes, even when you move them. For example don't add documentation if it is not there.
 
 # Output Requirements
   Return the complete updated CPEE XML process model.

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

@@ -5,12 +5,8 @@ The user will always provide:
 * one or more textual modification requests;
 * a list of available API endpoints (service registry).
 
-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
+%%%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.
@@ -47,24 +43,26 @@ Endpoint Rules:
   - 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 defined for the service.
-- If the endpoint is not already present in the <endpoints> section, add it using the URL from the Service Registry.
+- 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:
-- Create an empty <call> element as a placeholder.
-- Do not invent an endpoint, service URL, input parameters, output mappings, or implementation details.
-- Leave the task unconfigured except for information explicitly requested by the user.
+%%%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.
 
-%%%cpee_xml.txt
+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.

data/lib/cpee/llm/prompts/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/{cpee_xml_documentation_modelling.txt → fragments/cpee_xml/documentation.txt}

@@ -14,7 +14,7 @@ The documentation element may describe the service implementation as well as its
 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>` conmtains only <in> and <implementation>. Include <out> only in tasks, where output is defined.
+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.

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.