cpee-llm 1.1.0 → 1.2.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/LICENSE +668 -159
- data/cpee-llm.gemspec +3 -3
- data/lib/cpee/llm/dataflow.rb +3 -3
- data/lib/cpee/llm/functions.rb +16 -16
- data/lib/cpee/llm/implementation.rb +4 -4
- data/lib/cpee/llm/implementation.xml +7 -6
- data/lib/cpee/llm/prompts/system/adapt_mermaid.txt +12 -0
- data/lib/cpee/llm/prompts/system/{adapt_docxml_description.txt → adapt_xml_documentation.txt} +11 -11
- data/lib/cpee/llm/prompts/system/adapt_xml_endpoints.txt +10 -12
- data/lib/cpee/llm/prompts/system/dataflow.txt +13 -25
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/arguments.txt +8 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/color_palette.txt +10 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/description.txt +3 -0
- data/lib/cpee/llm/prompts/system/{cpee_xml_documentation_modelling.txt → fragments/cpee_xml/documentation.txt} +1 -1
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/exclusive_gateway.txt +7 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/finalize.txt +2 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/inclusive_gateway.txt +2 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/loop.txt +7 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/method.txt +6 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/parallel_gateway.txt +6 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/pause.txt +4 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/pause_insertion.txt +3 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/script_task.txt +5 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/sequence.txt +2 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/service_task.txt +20 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml/variables.txt +3 -0
- data/lib/cpee/llm/prompts/system/fragments/cpee_xml.txt +15 -0
- data/lib/cpee/llm/prompts/system/fragments/data_references.txt +14 -0
- data/lib/cpee/llm/prompts/system/fragments/endpoint_naming.txt +1 -0
- data/lib/cpee/llm/prompts/system/fragments/mermaid/structure_rules.txt +29 -0
- data/lib/cpee/llm/prompts/system/fragments/mermaid/syntax.txt +22 -0
- data/lib/cpee/llm/prompts/system/fragments/numeric_conversion.txt +5 -0
- data/lib/cpee/llm/prompts/system/fragments/service_registry.txt +6 -0
- data/lib/cpee/llm/prompts/system/fragments/unmatched_tasks.txt +4 -0
- data/lib/cpee/llm/prompts/system/generate_mermaid.txt +40 -0
- data/lib/cpee/llm/prompts/system/generate_mermaid_endpoints.txt +82 -0
- data/lib/cpee/llm/prompts/system/intent.txt +3 -3
- data/lib/cpee/llm/prompts/system/validate_xml.txt +15 -0
- data/lib/cpee/llm/prompts/user/describe_text.txt +4 -0
- data/lib/cpee/llm/prompts/user/intent.txt +3 -3
- data/lib/cpee/llm/prompts/user/validate_xml.txt +5 -0
- data/lib/cpee/llm/rubyllm_requests.rb +13 -9
- data/server/{cpee-llm → llm} +4 -3
- data/tools/cpee-llm +3 -3
- data/tools/cpee-llm-tool +3 -3
- metadata +39 -23
- data/lib/cpee/llm/prompts/system/apply.txt +0 -32
- data/lib/cpee/llm/prompts/system/cpee_xml.txt +0 -99
- data/lib/cpee/llm/prompts/system/derive.txt +0 -28
- data/lib/cpee/llm/prompts/system/gemini-request.json +0 -18
- data/lib/cpee/llm/prompts/system/generate1.txt +0 -90
- data/lib/cpee/llm/prompts/system/generate_enpoints.txt +0 -132
- data/lib/cpee/llm/prompts/system/generate_enpoints1.txt +0 -155
- data/lib/cpee/llm/prompts/system/identify.txt +0 -25
- data/lib/cpee/llm/prompts/system/validate_mermaid.xml +0 -74
- data/lib/cpee/llm/prompts/user/cpee_repair.txt +0 -5
- data/lib/cpee/llm/prompts/user/process_model_text.txt +0 -4
- data/lib/cpee/llm/prompts/user/repair.txt +0 -5
- /data/lib/cpee/llm/prompts/system/{describe.txt → describe_text.txt} +0 -0
- /data/lib/cpee/llm/prompts/user/{process_model_adapt.txt → adapt.txt} +0 -0
- /data/lib/cpee/llm/prompts/user/{process_model_adapt_api.txt → adapt_xml_endpoints.txt} +0 -0
- /data/lib/cpee/llm/prompts/user/{process_description.txt → generate_mermaid.txt} +0 -0
- /data/lib/cpee/llm/prompts/user/{process_description_endpoints.txt → generate_mermaid_endpoints.txt} +0 -0
- /data/server/{cpee-llm.conf → llm.conf} +0 -0
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
You are an expert in BPMN modeling, specifically in Mermaid.js format.
|
|
2
|
+
As an input you will receive a textual description of a business process.
|
|
3
|
+
|
|
4
|
+
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.
|
|
5
|
+
|
|
6
|
+
Generation procedure is as follows:
|
|
7
|
+
1. First, define all nodes with unique identifiers and labels.
|
|
8
|
+
2. Then, create edges between the nodes using predefined syntax.
|
|
9
|
+
3. All paths must start from the start event and eventually lead to the end event.
|
|
10
|
+
|
|
11
|
+
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.
|
|
12
|
+
%%%fragments/mermaid/syntax.txt
|
|
13
|
+
|
|
14
|
+
%%%fragments/mermaid/structure_rules.txt
|
|
15
|
+
|
|
16
|
+
Correctness always takes priority over completeness.
|
|
17
|
+
|
|
18
|
+
Validation Checklist (must be passed before output):
|
|
19
|
+
1) Diagram is valid Mermaid.js syntax and renders without errors.
|
|
20
|
+
2) Each split gateway has a matching merge of the same type.
|
|
21
|
+
3) No branch ends without joining a merge.
|
|
22
|
+
4) No empty tasks exist.
|
|
23
|
+
5) Each path must start from the start event and eventually lead to the end event.
|
|
24
|
+
|
|
25
|
+
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.
|
|
26
|
+
Return only Mermaid.js code as plain text, without markdown formatting or explanation.
|
|
27
|
+
|
|
28
|
+
Here is a small example:
|
|
29
|
+
* Textual process description as input:
|
|
30
|
+
First, the order is validated. Then, if the order is valid, it is processed. Otherwise, the order is rejected.
|
|
31
|
+
|
|
32
|
+
* Output process model in mermaid.js:
|
|
33
|
+
graph LR
|
|
34
|
+
0:startevent:((startevent)) --> 1:task:(Validate Order)
|
|
35
|
+
1:task:(Validate Order) --> 2:exclusivegateway:{x}
|
|
36
|
+
2:exclusivegateway:{x} --> |Valid| 3:task:(Process Order)
|
|
37
|
+
2:exclusivegateway:{x} --> |Invalid| 4:task:(Reject Order)
|
|
38
|
+
3:task:(Process Order) --> 5:exclusivegateway:{x}
|
|
39
|
+
4:task:(Reject Order) --> 5:exclusivegateway:{x}
|
|
40
|
+
5:exclusivegateway:{x} --> 6:endevent:(((endevent)))
|
|
@@ -0,0 +1,82 @@
|
|
|
1
|
+
You are an expert in BPMN modeling, Mermaid.js syntax, and endpoint-based process orchestration.
|
|
2
|
+
You receive:
|
|
3
|
+
(a) A textual business process description.
|
|
4
|
+
(b) A service registry containing available API endpoints.
|
|
5
|
+
|
|
6
|
+
%%%fragments/service_registry.txt
|
|
7
|
+
The service registry is keyed by service url. Each value lists description, functionality, input and output in this order.
|
|
8
|
+
|
|
9
|
+
Core Objective
|
|
10
|
+
Generate a syntactically correct and semantically accurate BPMN 2.0 process model in Mermaid.js that most faithfully represents the user's business process.
|
|
11
|
+
The business process description is the primary source of truth.
|
|
12
|
+
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.
|
|
13
|
+
|
|
14
|
+
Endpoint Integration Rules
|
|
15
|
+
- Identify activities from the business process description (not from the registry).
|
|
16
|
+
- Whenever an activity can naturally be implemented by an existing endpoint, use one of that endpoint’s task labels (from its description).
|
|
17
|
+
- If multiple endpoints together implement one activity more precisely, you may decompose that activity into multiple endpoint-backed tasks.
|
|
18
|
+
- If no suitable endpoint exists, create a new task representing the activity.
|
|
19
|
+
- 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.
|
|
20
|
+
- Do not modify business logic to increase endpoint usage.
|
|
21
|
+
- Ignore irrelevant endpoints.
|
|
22
|
+
|
|
23
|
+
%%%fragments/mermaid/syntax.txt
|
|
24
|
+
|
|
25
|
+
%%%fragments/mermaid/structure_rules.txt
|
|
26
|
+
|
|
27
|
+
Generation Procedure
|
|
28
|
+
1. Extract activities from the business process description.
|
|
29
|
+
2. Build BPMN structure based only on those activities.
|
|
30
|
+
3. Match activities to endpoints when appropriate.
|
|
31
|
+
4. Replace or refine tasks using endpoint-backed implementations where possible.
|
|
32
|
+
5. Decompose activities only when it improves faithful endpoint usage without changing meaning.
|
|
33
|
+
6. Add gateways only when required by the process logic.
|
|
34
|
+
7. Ensure all paths lead from start to end.
|
|
35
|
+
|
|
36
|
+
Mandatory Validation Before Output
|
|
37
|
+
The model is valid only if all conditions are met:
|
|
38
|
+
1) Valid Mermaid.js syntax
|
|
39
|
+
2) BPMN flow is complete from start to end
|
|
40
|
+
3) Every endpoint-backed task corresponds to a provided endpoint
|
|
41
|
+
4) Any non-endpoint task exists only when no suitable endpoint exists
|
|
42
|
+
5) No endpoint URLs appear in the diagram
|
|
43
|
+
6) Every split gateway has a matching merge gateway of the same type
|
|
44
|
+
7) No implicit merges exist
|
|
45
|
+
8) The diagram is a valid executable BPMN flow
|
|
46
|
+
|
|
47
|
+
If invalid, restructure or simplify until valid.
|
|
48
|
+
Output Rule
|
|
49
|
+
Return only Mermaid.js code. No explanations, comments, or markdown.
|
|
50
|
+
|
|
51
|
+
Example:
|
|
52
|
+
Process Description:
|
|
53
|
+
When a request arrives, validate it. If it is valid, store it and wait 2 seconds.
|
|
54
|
+
|
|
55
|
+
Available Endpoints
|
|
56
|
+
{
|
|
57
|
+
"https-post://system/validate" =>
|
|
58
|
+
["Validate request",
|
|
59
|
+
"Checks whether a request is valid.",
|
|
60
|
+
"request",
|
|
61
|
+
"validity result (valid/invalid)"],
|
|
62
|
+
"https-post://system/store" =>
|
|
63
|
+
["Store request; Save data",
|
|
64
|
+
"Stores a validated request.",
|
|
65
|
+
"validated request",
|
|
66
|
+
"record id"],
|
|
67
|
+
"https-post://system/timeout" =>
|
|
68
|
+
["Wait; Timeout",
|
|
69
|
+
"Wait for a given duration in seconds.",
|
|
70
|
+
"duration (float)",
|
|
71
|
+
"completion event"]
|
|
72
|
+
}
|
|
73
|
+
|
|
74
|
+
Generated BPMN Model
|
|
75
|
+
graph LR
|
|
76
|
+
0:startevent:((startevent)) --> 1:task:(Validate request)
|
|
77
|
+
1:task:(Validate request) --> 2:exclusivegateway:{x}
|
|
78
|
+
2:exclusivegateway:{x} --> |valid| 3:task:(Store request)
|
|
79
|
+
2:exclusivegateway:{x} --> |invalid| 4:exclusivegateway:{x}
|
|
80
|
+
3:task:(Store request) --> 5:task:(Wait)
|
|
81
|
+
5:task:(Wait) --> 4:exclusivegateway:{x}
|
|
82
|
+
4:exclusivegateway:{x} --> 6:endevent:(((endevent)))
|
|
@@ -7,9 +7,9 @@ Plugins are defined as json, e.g.:
|
|
|
7
7
|
|
|
8
8
|
{ "id": 1, "priority": 2, "url": "https://cpee.org/llm/plugins/aaa", "description": "Description what the plugin does", ... }
|
|
9
9
|
|
|
10
|
-
If one of the plugins is
|
|
11
|
-
as json {
|
|
12
|
-
lowest priority. If one the plugins is only partially suitable, remove that
|
|
10
|
+
If one of the plugins is matching (according to its description), return its id
|
|
11
|
+
as json { "id": 12345 }. If multiple plugins match, choose the one with the
|
|
12
|
+
lowest priority. If one of the plugins is only partially suitable, remove that
|
|
13
13
|
part of the text that the plugin requires as input, and replace it with %%%.
|
|
14
14
|
Write the text into a key "input". Replacing the whole input with %%% is fine.
|
|
15
15
|
Replacing a part is also fine, depending on the user input.
|
|
@@ -27,6 +27,21 @@ A model is considered executable only if:
|
|
|
27
27
|
- Variables used in conditions or code are available before use.
|
|
28
28
|
- Control flow can be executed without structural deadlocks caused by invalid model constructs.
|
|
29
29
|
- Loops and termination logic are executable.
|
|
30
|
+
- 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).
|
|
31
|
+
|
|
32
|
+
CPEE XML reference:
|
|
33
|
+
%%%fragments/cpee_xml/description.txt
|
|
34
|
+
%%%fragments/cpee_xml/sequence.txt
|
|
35
|
+
%%%fragments/cpee_xml/service_task.txt
|
|
36
|
+
%%%fragments/cpee_xml/arguments.txt
|
|
37
|
+
%%%fragments/cpee_xml/finalize.txt
|
|
38
|
+
%%%fragments/cpee_xml/script_task.txt
|
|
39
|
+
%%%fragments/cpee_xml/exclusive_gateway.txt
|
|
40
|
+
%%%fragments/cpee_xml/inclusive_gateway.txt
|
|
41
|
+
%%%fragments/cpee_xml/loop.txt
|
|
42
|
+
%%%fragments/cpee_xml/parallel_gateway.txt
|
|
43
|
+
%%%fragments/cpee_xml/pause.txt
|
|
44
|
+
%%%fragments/cpee_xml/variables.txt
|
|
30
45
|
|
|
31
46
|
Output rules:
|
|
32
47
|
* If the model is already executable and no repair is required, output exactly: PERFECT
|
|
@@ -2,12 +2,12 @@ Consider the following user input:
|
|
|
2
2
|
|
|
3
3
|
%%%user_input
|
|
4
4
|
|
|
5
|
-
Consider the
|
|
5
|
+
Consider the following list of plugins
|
|
6
6
|
|
|
7
7
|
%%%plugins
|
|
8
8
|
|
|
9
|
-
If appropriate, select a plugin, and return its id as json, e.g., {
|
|
10
|
-
If a plugin is appropriate for a part of the text, replace the text with %%% and return it as part of the json, e.g., { "id": 123, "
|
|
9
|
+
If appropriate, select a plugin, and return its id as json, e.g., { "id": 123 }.
|
|
10
|
+
If a plugin is appropriate for a part of the text, replace the text with %%% and return it as part of the json, e.g., { "id": 123, "input": "Some text. %%%. Some more text." }.
|
|
11
11
|
If nothing seems suitable return "null". This includes cases where the user input
|
|
12
12
|
does not convey any intent about creating, adding to, or modifying a process
|
|
13
13
|
model at all, e.g. "what is the weather today", "2+2", or "12".
|
|
@@ -1,16 +1,16 @@
|
|
|
1
1
|
# This file is part of CPEE-LLM.
|
|
2
2
|
#
|
|
3
3
|
# CPEE-LLM is free software: you can redistribute it and/or modify it under the
|
|
4
|
-
# terms of the GNU
|
|
4
|
+
# terms of the GNU General Public License as published by the Free
|
|
5
5
|
# Software Foundation, either version 3 of the License, or (at your option) any
|
|
6
6
|
# later version.
|
|
7
7
|
#
|
|
8
8
|
# CPEE-LLM is distributed in the hope that it will be useful, but WITHOUT ANY
|
|
9
9
|
# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
|
|
10
|
-
# A PARTICULAR PURPOSE. See the GNU
|
|
10
|
+
# A PARTICULAR PURPOSE. See the GNU General Public License for more
|
|
11
11
|
# details.
|
|
12
12
|
#
|
|
13
|
-
# You should have received a copy of the GNU
|
|
13
|
+
# You should have received a copy of the GNU General Public License
|
|
14
14
|
# along with CPEE-LLM (file LICENSE in the main directory). If not, see
|
|
15
15
|
# <http://www.gnu.org/licenses/>.
|
|
16
16
|
|
|
@@ -55,18 +55,22 @@ module CPEE
|
|
|
55
55
|
end #}}}
|
|
56
56
|
|
|
57
57
|
def build_system_prompt(name) #{{{
|
|
58
|
-
|
|
59
|
-
|
|
58
|
+
expand_system_includes(File.read(File.join(__dir__,"prompts","system",name)),[name])
|
|
59
|
+
end #}}}
|
|
60
|
+
|
|
61
|
+
# replaces %%%file lines recursively, seen guards against include cycles
|
|
62
|
+
def expand_system_includes(sp,seen) #{{{
|
|
63
|
+
sp.gsub(/(^|\n)[\t ]*%%%([^\n]+)(\n|$)/) do |e|
|
|
60
64
|
b = $1
|
|
61
|
-
m = $2
|
|
65
|
+
m = $2.strip
|
|
62
66
|
a = $3
|
|
63
|
-
|
|
64
|
-
|
|
67
|
+
f = File.join(__dir__,"prompts","system",m)
|
|
68
|
+
if File.exist?(f) && !seen.include?(m)
|
|
69
|
+
"#{a}#{expand_system_includes(File.read(f),seen + [m])}#{b}"
|
|
65
70
|
else
|
|
66
71
|
"#{a}#{b}"
|
|
67
72
|
end
|
|
68
73
|
end
|
|
69
|
-
sp
|
|
70
74
|
end #}}}
|
|
71
75
|
|
|
72
76
|
def build_user_prompt(name,opts) #{{{
|
data/server/{cpee-llm → llm}
RENAMED
|
@@ -3,16 +3,16 @@
|
|
|
3
3
|
# This file is part of CPEE-LLM.
|
|
4
4
|
#
|
|
5
5
|
# CPEE-LLM is free software: you can redistribute it and/or modify it under the
|
|
6
|
-
# terms of the GNU
|
|
6
|
+
# terms of the GNU General Public License as published by the Free
|
|
7
7
|
# Software Foundation, either version 3 of the License, or (at your option) any
|
|
8
8
|
# later version.
|
|
9
9
|
#
|
|
10
10
|
# CPEE-LLM is distributed in the hope that it will be useful, but WITHOUT ANY
|
|
11
11
|
# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
|
|
12
|
-
# A PARTICULAR PURPOSE. See the GNU
|
|
12
|
+
# A PARTICULAR PURPOSE. See the GNU General Public License for more
|
|
13
13
|
# details.
|
|
14
14
|
#
|
|
15
|
-
# You should have received a copy of the GNU
|
|
15
|
+
# You should have received a copy of the GNU General Public License
|
|
16
16
|
# along with CPEE-LLM (file LICENSE in the main directory). If not, see
|
|
17
17
|
# <http://www.gnu.org/licenses/>.
|
|
18
18
|
|
|
@@ -38,6 +38,7 @@ Riddl::Server.new(CPEE::LLM::SERVER, options) do
|
|
|
38
38
|
@riddl_opts[:llms][:connectors].each do |k,v|
|
|
39
39
|
@riddl_opts[:llms][:connectors][k] = File.read(v)
|
|
40
40
|
end
|
|
41
|
+
@riddl_opts[:plugins] = File.join(__dir__,'plugins.json')
|
|
41
42
|
|
|
42
43
|
use CPEE::LLM::implementation(@riddl_opts)
|
|
43
44
|
end.loop!
|
data/tools/cpee-llm
CHANGED
|
@@ -3,16 +3,16 @@
|
|
|
3
3
|
# This file is part of CPEE-LLM.
|
|
4
4
|
#
|
|
5
5
|
# CPEE-LLM is free software: you can redistribute it and/or modify it under the
|
|
6
|
-
# terms of the GNU
|
|
6
|
+
# terms of the GNU General Public License as published by the Free
|
|
7
7
|
# Software Foundation, either version 3 of the License, or (at your option) any
|
|
8
8
|
# later version.
|
|
9
9
|
#
|
|
10
10
|
# CPEE-LLM is distributed in the hope that it will be useful, but WITHOUT ANY
|
|
11
11
|
# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
|
|
12
|
-
# A PARTICULAR PURPOSE. See the GNU
|
|
12
|
+
# A PARTICULAR PURPOSE. See the GNU General Public License for more
|
|
13
13
|
# details.
|
|
14
14
|
#
|
|
15
|
-
# You should have received a copy of the GNU
|
|
15
|
+
# You should have received a copy of the GNU General Public License
|
|
16
16
|
# along with CPEE-LLM (file LICENSE in the main directory). If not, see
|
|
17
17
|
# <http://www.gnu.org/licenses/>.
|
|
18
18
|
|
data/tools/cpee-llm-tool
CHANGED
|
@@ -3,16 +3,16 @@
|
|
|
3
3
|
# This file is part of CPEE-LLM.
|
|
4
4
|
#
|
|
5
5
|
# CPEE-LLM is free software: you can redistribute it and/or modify it under the
|
|
6
|
-
# terms of the GNU
|
|
6
|
+
# terms of the GNU General Public License as published by the Free
|
|
7
7
|
# Software Foundation, either version 3 of the License, or (at your option) any
|
|
8
8
|
# later version.
|
|
9
9
|
#
|
|
10
10
|
# CPEE-LLM is distributed in the hope that it will be useful, but WITHOUT ANY
|
|
11
11
|
# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
|
|
12
|
-
# A PARTICULAR PURPOSE. See the GNU
|
|
12
|
+
# A PARTICULAR PURPOSE. See the GNU General Public License for more
|
|
13
13
|
# details.
|
|
14
14
|
#
|
|
15
|
-
# You should have received a copy of the GNU
|
|
15
|
+
# You should have received a copy of the GNU General Public License
|
|
16
16
|
# along with CPEE-LLM (file LICENSE in the main directory). If not, see
|
|
17
17
|
# <http://www.gnu.org/licenses/>.
|
|
18
18
|
|
metadata
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: cpee-llm
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version: 1.
|
|
4
|
+
version: 1.2.2
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- Nataliia Klievtsova
|
|
@@ -126,43 +126,59 @@ files:
|
|
|
126
126
|
- lib/cpee/llm/functions.rb
|
|
127
127
|
- lib/cpee/llm/implementation.rb
|
|
128
128
|
- lib/cpee/llm/implementation.xml
|
|
129
|
-
- lib/cpee/llm/prompts/system/
|
|
129
|
+
- lib/cpee/llm/prompts/system/adapt_mermaid.txt
|
|
130
|
+
- lib/cpee/llm/prompts/system/adapt_xml_documentation.txt
|
|
130
131
|
- lib/cpee/llm/prompts/system/adapt_xml_endpoints.txt
|
|
131
|
-
- lib/cpee/llm/prompts/system/apply.txt
|
|
132
|
-
- lib/cpee/llm/prompts/system/cpee_xml.txt
|
|
133
|
-
- lib/cpee/llm/prompts/system/cpee_xml_documentation_modelling.txt
|
|
134
132
|
- lib/cpee/llm/prompts/system/dataflow.txt
|
|
135
|
-
- lib/cpee/llm/prompts/system/
|
|
136
|
-
- lib/cpee/llm/prompts/system/
|
|
137
|
-
- lib/cpee/llm/prompts/system/
|
|
138
|
-
- lib/cpee/llm/prompts/system/
|
|
139
|
-
- lib/cpee/llm/prompts/system/
|
|
140
|
-
- lib/cpee/llm/prompts/system/
|
|
141
|
-
- lib/cpee/llm/prompts/system/
|
|
133
|
+
- lib/cpee/llm/prompts/system/describe_text.txt
|
|
134
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml.txt
|
|
135
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/arguments.txt
|
|
136
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/color_palette.txt
|
|
137
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/description.txt
|
|
138
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/documentation.txt
|
|
139
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/exclusive_gateway.txt
|
|
140
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/finalize.txt
|
|
141
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/inclusive_gateway.txt
|
|
142
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/loop.txt
|
|
143
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/method.txt
|
|
144
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/parallel_gateway.txt
|
|
145
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/pause.txt
|
|
146
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/pause_insertion.txt
|
|
147
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/script_task.txt
|
|
148
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/sequence.txt
|
|
149
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/service_task.txt
|
|
150
|
+
- lib/cpee/llm/prompts/system/fragments/cpee_xml/variables.txt
|
|
151
|
+
- lib/cpee/llm/prompts/system/fragments/data_references.txt
|
|
152
|
+
- lib/cpee/llm/prompts/system/fragments/endpoint_naming.txt
|
|
153
|
+
- lib/cpee/llm/prompts/system/fragments/mermaid/structure_rules.txt
|
|
154
|
+
- lib/cpee/llm/prompts/system/fragments/mermaid/syntax.txt
|
|
155
|
+
- lib/cpee/llm/prompts/system/fragments/numeric_conversion.txt
|
|
156
|
+
- lib/cpee/llm/prompts/system/fragments/service_registry.txt
|
|
157
|
+
- lib/cpee/llm/prompts/system/fragments/unmatched_tasks.txt
|
|
158
|
+
- lib/cpee/llm/prompts/system/generate_mermaid.txt
|
|
159
|
+
- lib/cpee/llm/prompts/system/generate_mermaid_endpoints.txt
|
|
142
160
|
- lib/cpee/llm/prompts/system/intent.txt
|
|
143
|
-
- lib/cpee/llm/prompts/system/validate_mermaid.xml
|
|
144
161
|
- lib/cpee/llm/prompts/system/validate_xml.txt
|
|
145
|
-
- lib/cpee/llm/prompts/user/
|
|
162
|
+
- lib/cpee/llm/prompts/user/adapt.txt
|
|
163
|
+
- lib/cpee/llm/prompts/user/adapt_xml_endpoints.txt
|
|
146
164
|
- lib/cpee/llm/prompts/user/dataflow.txt
|
|
165
|
+
- lib/cpee/llm/prompts/user/describe_text.txt
|
|
166
|
+
- lib/cpee/llm/prompts/user/generate_mermaid.txt
|
|
167
|
+
- lib/cpee/llm/prompts/user/generate_mermaid_endpoints.txt
|
|
147
168
|
- lib/cpee/llm/prompts/user/intent.txt
|
|
148
|
-
- lib/cpee/llm/prompts/user/
|
|
149
|
-
- lib/cpee/llm/prompts/user/process_description_endpoints.txt
|
|
150
|
-
- lib/cpee/llm/prompts/user/process_model_adapt.txt
|
|
151
|
-
- lib/cpee/llm/prompts/user/process_model_adapt_api.txt
|
|
152
|
-
- lib/cpee/llm/prompts/user/process_model_text.txt
|
|
153
|
-
- lib/cpee/llm/prompts/user/repair.txt
|
|
169
|
+
- lib/cpee/llm/prompts/user/validate_xml.txt
|
|
154
170
|
- lib/cpee/llm/rubyllm_requests.rb
|
|
155
171
|
- server/connect_gemini
|
|
156
172
|
- server/connect_gpt
|
|
157
173
|
- server/connect_morpheus
|
|
158
|
-
- server/
|
|
159
|
-
- server/
|
|
174
|
+
- server/llm
|
|
175
|
+
- server/llm.conf
|
|
160
176
|
- server/plugins.json
|
|
161
177
|
- tools/cpee-llm
|
|
162
178
|
- tools/cpee-llm-tool
|
|
163
179
|
homepage: http://github.com/etm/cpee-llm/
|
|
164
180
|
licenses:
|
|
165
|
-
-
|
|
181
|
+
- GPL-3.0-or-later
|
|
166
182
|
metadata: {}
|
|
167
183
|
rdoc_options: []
|
|
168
184
|
require_paths:
|
|
@@ -1,32 +0,0 @@
|
|
|
1
|
-
You are an expert in BPMN modeling, specifically in Mermaid.js format.
|
|
2
|
-
Your task is to validate and transform BPMN models based on user-provided modifications, ensuring compliance with BPMN rules and Mermaid.js syntax.
|
|
3
|
-
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.
|
|
4
|
-
The Mermaid.js syntax for BPMN models is described as follows:
|
|
5
|
-
The graph must use the LR (Left to Right) direction.
|
|
6
|
-
Each mermaid js node must have the following structure:
|
|
7
|
-
id:type:shape and text
|
|
8
|
-
id - it is a unique identifier. Id can be only an integer from 0 to n. Each node has a unique identifier
|
|
9
|
-
type - defines the type of the element regarding to BPMN 2.0 notation.
|
|
10
|
-
possible types are: start event, end event, task, subprocess, exclusive, inclusive and parallel gateway.
|
|
11
|
-
Based on the type of the node following shapes and texts are to be used:
|
|
12
|
-
startevent: ((startevent)) i.e., id:startevent:((startevent))
|
|
13
|
-
endevent: (((endevent))) i.e., id:endevent:(((endevent)))
|
|
14
|
-
task: (task label) i.e., id:task:(task label)
|
|
15
|
-
subprocess: (subprocess label) i.e., id:subprocess:(subprocess label)
|
|
16
|
-
exclusivegateway: {x} i.e., id:exclusivegateway:{x}
|
|
17
|
-
parallelgateway: {AND} i.e., id:parallelgateway:{AND}
|
|
18
|
-
inclusivegateway: {O} i.e., id:inclusivegateway:{O}
|
|
19
|
-
|
|
20
|
-
All gateways must have both a split and a merge point.
|
|
21
|
-
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).
|
|
22
|
-
|
|
23
|
-
All nodes that have occurred more than once should have following structure: id:type: (i.e., 2:task: ) by futher occurrence.
|
|
24
|
-
It is strictly prohibited to use only id (i.e. 2) as a reference.
|
|
25
|
-
|
|
26
|
-
All elements are connected with each other with the help of the direction.
|
|
27
|
-
direction: -->
|
|
28
|
-
If there are some conditions or annotations it is necessary to use text on links (i.e., edge labels)
|
|
29
|
-
edge label: |condition or annotation|
|
|
30
|
-
Edge label is always located between 2 nodes: id:exclusivegateway:{x} --> |condition or annotation|id:task:(task label)
|
|
31
|
-
|
|
32
|
-
Return only mermaid.js as text without any additional information! Give me just the raw Mermaid.js code without markdown formatting.
|
|
@@ -1,99 +0,0 @@
|
|
|
1
|
-
# CPEE XML Process Model Structure
|
|
2
|
-
The process model itself is contained entirely inside the <description color=""> element. Interpret the XML inside <description> using the following mapping.
|
|
3
|
-
The color attribute controls the color of the whole process model. Individual service task colors can be set (see below). For the color attribute the same color palette as described in the section Service Task applies.
|
|
4
|
-
|
|
5
|
-
## Sequential Flow
|
|
6
|
-
Sequential execution is represented by sibling XML elements appearing in order inside the same parent element.
|
|
7
|
-
|
|
8
|
-
## Service Task
|
|
9
|
-
A BPMN Service Task is represented by a `<call id="..." endpoint="...">` element.
|
|
10
|
-
The endpoint of the service is stored in the **endpoint attribute**.
|
|
11
|
-
<call endpoint="measurelightingconditions">
|
|
12
|
-
The following child elements may appear inside `<call>`:
|
|
13
|
-
├── parameters
|
|
14
|
-
│ ├── label
|
|
15
|
-
│ ├── color
|
|
16
|
-
│ ├── method
|
|
17
|
-
│ └── arguments
|
|
18
|
-
├── code
|
|
19
|
-
│ ├── signal
|
|
20
|
-
│ ├── prepare
|
|
21
|
-
│ ├── finalize
|
|
22
|
-
│ ├── update
|
|
23
|
-
│ └── rescue
|
|
24
|
-
├── annotations
|
|
25
|
-
└── documentation
|
|
26
|
-
|
|
27
|
-
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.
|
|
28
|
-
Use only the following color palette:
|
|
29
|
-
* White — #ffffff
|
|
30
|
-
* Blue — #d4e1f1
|
|
31
|
-
* Green — #d8f0dd
|
|
32
|
-
* Yellow — #ffffcc
|
|
33
|
-
* Purple — #e4c3e4
|
|
34
|
-
* Pink — #f8a8c6
|
|
35
|
-
* Brown — #ded0c5
|
|
36
|
-
* Gray — #deddda
|
|
37
|
-
|
|
38
|
-
The <method> field must strictly follow the Service Registry specification.
|
|
39
|
-
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>).
|
|
40
|
-
Never invent, infer, or assume a method value that is not explicitly defined in the service specification:
|
|
41
|
-
<method/>
|
|
42
|
-
|
|
43
|
-
Service input parameters are stored inside arguments. Each argument is represented by its own child element.
|
|
44
|
-
<arguments>
|
|
45
|
-
<min>1</min>
|
|
46
|
-
<max>100</max>
|
|
47
|
-
</arguments>
|
|
48
|
-
If an argument depends on a previously computed or returned value, it must be provided using the !data.some_value syntax.
|
|
49
|
-
<arguments>
|
|
50
|
-
<step>!data.current_step</step>
|
|
51
|
-
</arguments>
|
|
52
|
-
|
|
53
|
-
Returned service values are processed inside finalize: <finalize output="result">, where result is the variable containing the service response. Assign values from result (for example, result["start"] or result["end"]) to workflow variables (for example, data.start or data.end) to store them for later use in the process.
|
|
54
|
-
<finalize output="result"> data.temperature = result["temperature"].to_f; data.type = result["celsius"];</finalize>
|
|
55
|
-
|
|
56
|
-
## Script TaskA BPMN Script Task is represented by <manipulate id="..." label="..." color="...">. The executable Ruby code is stored inside the <code> child element:
|
|
57
|
-
<manipulate><code id="a1">data.counter += 1</code></manipulate>
|
|
58
|
-
The label of the BPMN Script Task is stored in an attribute label in the <manipulate>.
|
|
59
|
-
The color of the BPMN Script Task is stored in an attribute color in the <manipulate>. Use the same color palette as for Service Tasks.
|
|
60
|
-
|
|
61
|
-
## Exclusive Gateway
|
|
62
|
-
An Exclusive Gateway is represented by <choose eid="..." mode="exclusive">
|
|
63
|
-
Each outgoing branch is represented by <alternative condition="..." eid="e.."> child.
|
|
64
|
-
The branch condition is stored in the **condition attribute**.
|
|
65
|
-
<alternative condition="data.temperature > 30" eid="e1">
|
|
66
|
-
Conditions must be valid Ruby expressions.
|
|
67
|
-
Default branch has no conditions. <otherwise eid="..."/>.
|
|
68
|
-
|
|
69
|
-
## Inclusive Gateway
|
|
70
|
-
The only differ from Inclusive Gateway by the attribute mode="inclusive".
|
|
71
|
-
|
|
72
|
-
## Loop
|
|
73
|
-
A BPMN loop is represented by <loop eid="e.." mode="..." condition="...">
|
|
74
|
-
The loop condition is stored in the **condition attribute**. The loop execution mode is stored in the **mode attribute**.
|
|
75
|
-
pre_test is used for head controlled loops.
|
|
76
|
-
post_test is used for tail controlled loops.
|
|
77
|
-
<loop eid="e1" mode="pre_test" condition="data.counter < 10">
|
|
78
|
-
Loop conditions must be valid Ruby expressions.
|
|
79
|
-
|
|
80
|
-
## Parallel Gateway
|
|
81
|
-
Parallel execution is represented by <parallel eid="e.." wait="-1" cancel="last">
|
|
82
|
-
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".
|
|
83
|
-
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").
|
|
84
|
-
An event-based gateway (which is a special case of a parallel) has always wait="1" cancel="last".
|
|
85
|
-
Each concurrent branch is represented by <parallel_branch eid="e..">
|
|
86
|
-
|
|
87
|
-
##Pause Task
|
|
88
|
-
A pause is represented by a <stop id="a.."> element.
|
|
89
|
-
A <stop> pauses the execution of the process (until it is manually resumed). It does not terminate the process.
|
|
90
|
-
<stop id="a5"/>
|
|
91
|
-
When the user requests to pause, hold, or stop the process, insert a <stop> element.
|
|
92
|
-
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.
|
|
93
|
-
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.
|
|
94
|
-
|
|
95
|
-
## Variables
|
|
96
|
-
Variables are referenced as: data.variable_name
|
|
97
|
-
Service outputs are returned as strings unless otherwise specified.
|
|
98
|
-
Whenever a value represents a numeric type (integer or floating-point), convert it to a numeric value before assigning it to a workflow variable by using Ruby's .to_f method:
|
|
99
|
-
data.temperature = result["temperature"].to_f
|
|
@@ -1,28 +0,0 @@
|
|
|
1
|
-
You are an expert in BPMN (Business Process Model and Notation) modeling. Your task is to evaluate and interpret user-provided modifications to a BPMN process model.
|
|
2
|
-
Your responsibilities include:
|
|
3
|
-
(a) Validating whether the provided modification contains sufficient and unambiguous information to be applied.
|
|
4
|
-
(b) Mapping each modification to a predefined change pattern (see list below).
|
|
5
|
-
(c) Deriving the actual meaning of the modification based on BPMN semantics and the intent of the change pattern.
|
|
6
|
-
(d) Ensuring compliance with BPMN modeling rules and the structure of the existing process.
|
|
7
|
-
Final output have to contain only the actual meaning of the user input in natural language without ambiguity and without any additional information. If there is not enough information to perform changes return "NA".
|
|
8
|
-
Use the following classification of change patterns to interpret user modifications:
|
|
9
|
-
{
|
|
10
|
-
"cp1":"Insert Process Fragment. Adds a new process fragments between two directly succeeding activities",
|
|
11
|
-
"cp2":"Delete Process Fragment. Removes an existing process fragment and consequently flatten the hierarchy if necessary",
|
|
12
|
-
"cp3":"Move Process Fragment. Shifts an existing process fragment from its current position to a new one",
|
|
13
|
-
"cp4":"Replace Process Fragment. Replaces Process Fragment & replace an existing process fragment with by a new one",
|
|
14
|
-
"cp5":"Swap Process Fragments. Swaps an existing process fragment with another existing process fragment",
|
|
15
|
-
"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",
|
|
16
|
-
"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",
|
|
17
|
-
"cp9":"Parallelize Process Fragments. Parallelization of existing process fragments which were confined to be executed in sequence",
|
|
18
|
-
"cp10":"Embed Process Fragment in Conditional Branch. An existing process fragment is embedded in a conditional branch",
|
|
19
|
-
"cp14":"Copy Process Fragment. Copies an existing process fragment and paste it to a new position",
|
|
20
|
-
"cp6":"Extract Sub Process. Extracts an existing process fragment to encapsulate it in a separate sub process",
|
|
21
|
-
"cp7":"Inline Sub Process. Inlines a sub process into the parent process, and consequently flatten the hierarchy of the overall process",
|
|
22
|
-
"cp13":"Update Condition. Updates transition conditions in a process",
|
|
23
|
-
"cp19":"Replace Gateways. Replaces existing gateways (both splitting and merging) in specified fragment simultaneously with the gateways of the other type",
|
|
24
|
-
"cp15":"Split Process Fragment. Splits an existing process fragment into a sequence of multiple separate new process fragments",
|
|
25
|
-
"cp16":"Merge Process Fragment. Merges multiple existing separate process fragments into one new process fragment",
|
|
26
|
-
"cp17":"Delete Entire Branch. Removes single entire branch inside selected gateways and consequently flatten the hierarchy if necessary",
|
|
27
|
-
"cp18":"Leave Single Branch. Replace existing gateways (both splitting and merging) in specified fragment simultaneously with the gateways of the other type"
|
|
28
|
-
}
|
|
@@ -1,18 +0,0 @@
|
|
|
1
|
-
{
|
|
2
|
-
"system_instruction": {
|
|
3
|
-
"parts": [
|
|
4
|
-
{ "text": "You are a cat. Your name is Neko." }
|
|
5
|
-
]
|
|
6
|
-
},
|
|
7
|
-
"generationConfig": {
|
|
8
|
-
"temperature": 0.0,
|
|
9
|
-
"maxOutputTokens": 4000
|
|
10
|
-
},
|
|
11
|
-
"contents": [
|
|
12
|
-
{
|
|
13
|
-
"parts": [
|
|
14
|
-
{ "text": "Hello there" }
|
|
15
|
-
]
|
|
16
|
-
}
|
|
17
|
-
]
|
|
18
|
-
}
|