@bpmnkit/camunda-docspack 0.0.0

package/.llms/chunks/components.modeler.bpmn.escalation-events.escalation-events.md

@@ -0,0 +1,18 @@
+# Escalation events
+
+Escalation events are used to escalate part of process execution to a higher flow scope.
+
+Escalation events are events which reference a named escalation, and are used to communicate to a higher flow scope.
+Unlike an error, an escalation event is non-critical and execution continues at the location of throwing.
+
+![The process reached an escalation event. The escalation gets caught in a higher flow scope. As the escalation throw event is non-critical, the outgoing sequence flow of this event is taken.](assets/escalation-events.png)
+
+The example above shows the execution of an escalation event:
+
+1. The process reaches the `Throw` event.
+2. This throws an escalation to a higher flow scope.
+3. The escalation is caught by the `Catch` event.
+4. As escalation events are non-critical, the outgoing sequence flows of `Throw` and `Catch` are both taken.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/escalation-events/escalation-events

package/.llms/chunks/components.modeler.bpmn.escalation-events.escalation-events.throwing-the-escalation.md

@@ -0,0 +1,22 @@
+# Escalation events — Throwing the escalation
+
+An escalation can be thrown by an escalation end event, or by an intermediate escalation throw event. Escalation events
+are non-critical. This means that if the throwing event has any outgoing sequence flows, they will be taken.
+
+
+## Catching the escalation
+
+An escalation can be caught using a boundary event, or using an event subprocess. It is caught by one catch event at most, and this will be the catch event in the nearest parent flow scope.
+
+It is not possible to define multiple escalation catch events with the same `escalationCode` in a single scope. It is also not permitted to have multiple escalation catch-all events in a single scope. However, it is possible to define both an escalation catch event referencing an escalation with a particular `escalationCode` and an escalation catch-all event within the same scope. When this happens, the escalation catch event
+that matches the `escalationCode` is prioritized.
+
+If there are no escalation catch events that match the `escalationCode`, the escalation will not be caught. Unlike with
+[error events](https://docs.camunda.io/docs/next/components/modeler/bpmn/error-events/error-events), no incident is raised. The process will continue without escalating.
+
+Even though escalations are non-critical, it is still possible make escalation catch events interrupting. This will
+behave the same as other interrupting events. The catch event will terminate the scope it is attached to. In this case,
+the outgoing sequence flows of the throwing escalation event are not taken.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/escalation-events/escalation-events

package/.llms/chunks/components.modeler.bpmn.event-based-gateways.event-based-gateways.additional-resources.md

@@ -0,0 +1,36 @@
+# Event-based gateway — Additional resources
+
+### XML representation
+
+An event-based gateway with two outgoing sequence flows:
+
+```xml
+<bpmn:eventBasedGateway id="gateway" />
+
+<bpmn:sequenceFlow id="s1" sourceRef="gateway" targetRef="payment-details-updated" />
+
+<bpmn:intermediateCatchEvent id="payment-details-updated"
+  name="Payment Details Updated">
+  <bpmn:messageEventDefinition messageRef="message-payment-details-updated" />
+</bpmn:intermediateCatchEvent>
+
+<bpmn:sequenceFlow id="s2" sourceRef="gateway" targetRef="wait-one-hour" />
+
+<bpmn:intermediateCatchEvent id="wait-one-hour" name="1 hour">
+  <bpmn:timerEventDefinition>
+    <bpmn:timeDuration>PT1H</bpmn:timeDuration>
+  </bpmn:timerEventDefinition>
+</bpmn:intermediateCatchEvent>
+
+<bpmn:intermediateCatchEvent id="payment-canceled" name="Payment canceled">
+  <bpmn:signalEventDefinition signalRef="signal-payment-canceled" />
+</bpmn:intermediateCatchEvent>
+```
+
+### References
+
+- [Timer events](https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events)
+- [Message events](https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/event-based-gateways/event-based-gateways

package/.llms/chunks/components.modeler.bpmn.event-based-gateways.event-based-gateways.md

@@ -0,0 +1,16 @@
+# Event-based gateway
+
+An event-based gateway allows you to make a decision based on events.
+
+An event-based gateway allows you to make a decision based on events.
+
+![process](assets/event-based-gateway.png)
+
+An event-based gateway must have at least **two** outgoing sequence flows. Each sequence flow must be connected to
+an intermediate catch event of type [timer](https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events),
+[message](https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events) or [signal](https://docs.camunda.io/docs/next/components/modeler/bpmn/signal-events/signal-events).
+
+When an event-based gateway is entered, the process instance waits at the gateway until one of the events is triggered. When the first event is triggered, the outgoing sequence flow of this event is taken. No other events of the gateway can be triggered afterward.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/event-based-gateways/event-based-gateways

package/.llms/chunks/components.modeler.bpmn.event-subprocesses.event-subprocesses.additional-resources.md

@@ -0,0 +1,23 @@
+# Event subprocess — Additional resources
+
+### XML representation
+
+An event subprocess with an interrupting timer start event:
+
+```xml
+<bpmn:subProcess id="compensate-subprocess" triggeredByEvent="true">
+  <bpmn:startEvent id="cancel-order" isInterrupting="true">
+    <bpmn:timerEventDefinition>
+      <bpmn:timeDuration>PT5M</bpmn:timeDuration>
+    </bpmn:timerEventDefinition>
+  ... other elements
+</bpmn:subProcess>
+```
+
+### References
+
+- [Embedded subprocess](https://docs.camunda.io/docs/next/components/modeler/bpmn/embedded-subprocesses/embedded-subprocesses)
+- [Variable scopes](https://docs.camunda.io/docs/next/components/concepts/variables#variable-scopes)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/event-subprocesses/event-subprocesses

package/.llms/chunks/components.modeler.bpmn.event-subprocesses.event-subprocesses.md

@@ -0,0 +1,26 @@
+# Event subprocess
+
+An event subprocess is a subprocess triggered by an event.
+
+An event subprocess is a subprocess triggered by an event. This can be added globally to the process, or locally inside an embedded subprocess.
+
+![event-subprocess](assets/event-subprocess.png)
+
+An event subprocess must have exactly **one** start event of one of the following types:
+
+- [Timer](https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events)
+- [Message](https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events)
+- [Error](https://docs.camunda.io/docs/next/components/modeler/bpmn/error-events/error-events)
+- [Signal](https://docs.camunda.io/docs/next/components/modeler/bpmn/signal-events/signal-events)
+- [Escalation](https://docs.camunda.io/docs/next/components/modeler/bpmn/escalation-events/escalation-events)
+
+An event subprocess behaves like a boundary event, but is inside the scope instead of attached to the scope. Like a boundary event, the event subprocess can be interrupting or non-interrupting (indicated in BPMN by a solid or dashed border of the start event). The start event of the event subprocess can be triggered when its containing scope is activated.
+
+A non-interrupting event subprocess can be triggered multiple times. An interrupting event subprocess can be triggered only once.
+
+When an interrupting event subprocess is triggered, all active instances of its containing scope are terminated, including instances of other non-interrupting event subprocesses.
+
+If an event subprocess is triggered, its containing scope is not completed until the triggered instance is completed.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/event-subprocesses/event-subprocesses

package/.llms/chunks/components.modeler.bpmn.event-subprocesses.event-subprocesses.variables.md

@@ -0,0 +1,10 @@
+# Event subprocess — Variables
+
+Unlike a boundary event, an event subprocess is inside the scope. Therefore, it can access and modify all local variables of its containing scope. This is not possible with a boundary event because a boundary event is outside of the scope.
+
+Input mappings can be used to create new local variables in the scope of the event subprocess. These variables are only visible within the event subprocess. If no input mappings are defined, the [default behavior](https://docs.camunda.io/docs/next/components/concepts/variables#variable-scopes) is applied to the variables alongside the event.
+
+By default, the local variables of the event subprocess are not propagated (i.e. removed with the scope). This behavior can be customized by defining output mappings at the event subprocess. The output mappings are applied on completion of the event subprocess.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/event-subprocesses/event-subprocesses

package/.llms/chunks/components.modeler.bpmn.events.events-in-general.md

@@ -0,0 +1,14 @@
+# Overview — Events in general
+
+Events in BPMN can be **thrown** (i.e. sent) or **caught** (i.e. received), respectively referred to as **throw** or **catch** events (e.g. `message throw event`, `timer catch event`). The distinction is about which side of the event the process is on: a throw event is something the process itself actively does as part of its own execution (for example, sending a message or raising an escalation); a catch event is something the process passively waits for, coming from outside the process (for example, a message arriving, or a timer elapsing).
+
+Additionally, a distinction is made between start, intermediate, and end events:
+
+- **Start events** (always catch events) react to something external to begin the process or subprocess — a process can't start itself.
+- **End events** (always throw events) are the process's own final action, such as sending a message or signaling that an error occurred, and denote the end of a particular sequence flow.
+- **Intermediate events** can go either way: an intermediate throw event performs an action as part of the process's execution, while an intermediate catch event pauses the process and waits to react to something external.
+
+Intermediate catch events can be inserted into your process in two different contexts: normal flow, or attached to an activity, and are called boundary events.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/events

package/.llms/chunks/components.modeler.bpmn.events.intermediate-events.md

@@ -0,0 +1,21 @@
+# Overview — Intermediate events
+
+Diagram (BPMN):
+  start "..." → intermediate throw event "Send message A (intermediate throw event)" → intermediate catch event "Wait for msg. B (intermediate catch event)" → end "..."
+
+**(1)**
+
+**(2)**
+
+
+## Boundary events
+
+Boundary events provide a way to model what should happen if an event occurs while an activity is active. For example, if a process is waiting on a user task to happen which is taking too long, an intermediate timer catch event can be attached to the task, with an outgoing sequence flow to notification task, allowing the modeler to automate and sending a reminder email to the user.
+
+Diagram (BPMN):
+  start "..." → user task "Do something" → end "..."
+
+**(1)**
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/events

package/.llms/chunks/components.modeler.bpmn.events.md

@@ -0,0 +1,25 @@
+# Overview
+
+This document outlines an overview of general events, intermediate events, and boundary events.
+
+**Events** in BPMN represent things that _happen_. A process can react to events (_catching_ event) as well as emit events (_throwing_ event). For example, a catching message event makes the token continue as soon as a message is received. The XML representation of the process contains the criteria for which kind of message triggers continuation.
+
+Events can be added to the process in various ways. Not only can they be used to make a token wait at a certain point, but also for interrupting a token's progress.
+
+Currently supported events:
+
+- [None events](https://docs.camunda.io/docs/next/components/modeler/bpmn/none-events/none-events)
+- [Message events](https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events)
+- [Timer events](https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events)
+- [Error events](https://docs.camunda.io/docs/next/components/modeler/bpmn/error-events/error-events)
+- [Escalation events](https://docs.camunda.io/docs/next/components/modeler/bpmn/escalation-events/escalation-events)
+- [Terminate events](https://docs.camunda.io/docs/next/components/modeler/bpmn/terminate-events/terminate-events)
+- [Link events](https://docs.camunda.io/docs/next/components/modeler/bpmn/link-events/link-events)
+- [Signal events](https://docs.camunda.io/docs/next/components/modeler/bpmn/signal-events/signal-events)
+- [Compensation events](https://docs.camunda.io/docs/next/components/modeler/bpmn/compensation-events/compensation-events)
+
+**Note**
+Not all the events are supported yet. For a complete overview of supported events, refer to the [BPMN coverage](https://docs.camunda.io/docs/next/components/modeler/bpmn/bpmn-coverage#events).
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/events

package/.llms/chunks/components.modeler.bpmn.exclusive-gateways.exclusive-gateways.conditions.md

@@ -0,0 +1,46 @@
+# Exclusive gateway — Conditions
+
+A `conditionExpression` defines when a flow is taken. It is a [boolean expression](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-boolean-expressions) that can access the process variables and compare them with literals or other variables. The condition is fulfilled when the expression returns `true`.
+
+Multiple boolean values or comparisons can be combined as disjunction (`or`) or conjunction (`and`).
+
+For example:
+
+```feel
+= totalPrice > 100
+
+= order.customer = "Paul"
+
+= orderCount > 15 or totalPrice > 50
+
+= valid and orderCount > 0
+```
+
+
+## Additional resources
+
+### XML representation
+
+An exclusive gateway with two outgoing sequence flows:
+
+```xml
+<bpmn:exclusiveGateway id="exclusiveGateway" default="else" />
+
+<bpmn:sequenceFlow id="priceGreaterThan100" name="totalPrice &#62; 100"
+  sourceRef="exclusiveGateway" targetRef="shipParcelWithInsurance">
+  <bpmn:conditionExpression xsi:type="bpmn:tFormalExpression">
+    = totalPrice &gt; 100
+  </bpmn:conditionExpression>
+</bpmn:sequenceFlow>
+
+<bpmn:sequenceFlow id="else" name="else"
+  sourceRef="exclusiveGateway" targetRef="shipParcel" />
+```
+
+### References
+
+- [Expressions](https://docs.camunda.io/docs/next/components/concepts/expressions)
+- [Incidents](https://docs.camunda.io/docs/next/components/concepts/incidents)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/exclusive-gateways/exclusive-gateways

package/.llms/chunks/components.modeler.bpmn.exclusive-gateways.exclusive-gateways.md

@@ -0,0 +1,23 @@
+# Exclusive gateway
+
+Learn more about exclusive gateways (or XOR-gateways) and their conditions, which allow you to make a decision based on data such as process variables.
+
+An exclusive gateway (or XOR-gateway) selects one outgoing sequence flow based on data such as process variables.
+
+![process](assets/exclusive-gateway.png)
+
+For an exclusive gateway with multiple outgoing sequence flows:
+
+- All but one sequence flow must have a `conditionExpression`.
+- The remaining sequence flow can omit the `conditionExpression`, but the gateway must define it as the default flow.
+- Leaving the `conditionExpression` empty does not automatically make a sequence flow the default flow. In Modeler, set the exclusive gateway's default flow in the gateway properties by selecting the outgoing sequence flow to use as the default.
+- When a process instance reaches the gateway, the system evaluates the `conditionExpression` values in BPMN XML order and takes the first sequence flow whose condition is fulfilled.
+  - If no condition is fulfilled, the process instance takes the **default flow**. The default flow should not have a condition, so the system does not evaluate it.
+  - If no condition is fulfilled and the gateway has no default flow, an [incident](https://docs.camunda.io/docs/next/components/concepts/incidents) is created.
+
+For example, if one sequence flow uses the condition `= totalPrice > 100`, you can set another outgoing sequence flow as the gateway's default flow to handle all remaining cases where `totalPrice <= 100`.
+
+An exclusive gateway can also join multiple incoming flows to improve BPMN readability. A joining gateway has pass-through semantics and does not merge incoming concurrent flows like a parallel gateway.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/exclusive-gateways/exclusive-gateways

package/.llms/chunks/components.modeler.bpmn.gateways.md

@@ -0,0 +1,17 @@
+# Overview
+
+This document outlines an overview of currently supported gateways.
+
+Gateways are elements that route tokens in more complex patterns than plain sequence flow.
+
+BPMN's **exclusive gateway** chooses one sequence flow out of many based on data, whereas BPMN's **parallel gateway** generates new tokens by activating multiple sequence flows in parallel, for example.
+
+Currently supported elements:
+
+- [Exclusive gateways](https://docs.camunda.io/docs/next/components/modeler/bpmn/exclusive-gateways/exclusive-gateways)
+- [Parallel gateways](https://docs.camunda.io/docs/next/components/modeler/bpmn/parallel-gateways/parallel-gateways)
+- [Event-based gateways](https://docs.camunda.io/docs/next/components/modeler/bpmn/event-based-gateways/event-based-gateways)
+- [Inclusive gateways](https://docs.camunda.io/docs/next/components/modeler/bpmn/inclusive-gateways/inclusive-gateways)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/gateways

package/.llms/chunks/components.modeler.bpmn.inclusive-gateways.inclusive-gateways.additional-resources.md

@@ -0,0 +1,36 @@
+# Inclusive gateway — Additional resources
+
+### XML representation
+
+An inclusive gateway with three outgoing sequence flows and the default sequence flow is `Salad`:
+
+```xml
+<bpmn:inclusiveGateway id="Gateway_1dj8ts6" name="Courses selected?" default="Flow_05d0jjq">
+      <bpmn:incoming>Flow_0mfam08</bpmn:incoming>
+      <bpmn:outgoing>Flow_0d3xogt</bpmn:outgoing>
+      <bpmn:outgoing>Flow_1le3l31</bpmn:outgoing>
+      <bpmn:outgoing>Flow_05d0jjq</bpmn:outgoing>
+</bpmn:inclusiveGateway>
+<bpmn:sequenceFlow id="Flow_0d3xogt" name="Pasta"
+    sourceRef="Gateway_1dj8ts6" targetRef="Activity_1orhxob">
+    <bpmn:conditionExpression xsi:type="bpmn:tFormalExpression">
+       = list contains(courses, "pasta")
+    </bpmn:conditionExpression>
+</bpmn:sequenceFlow>
+<bpmn:sequenceFlow id="Flow_1le3l31" name="Steak"
+    sourceRef="Gateway_1dj8ts6" targetRef="Activity_0rygy6z">
+    <bpmn:conditionExpression xsi:type="bpmn:tFormalExpression">
+      = list contains(courses, "steak")
+    </bpmn:conditionExpression>
+</bpmn:sequenceFlow>
+<bpmn:sequenceFlow id="Flow_05d0jjq" name="Salad"
+    sourceRef="Gateway_1dj8ts6" targetRef="Activity_06yrt1e" />
+```
+
+### References
+
+- [Conditions](https://docs.camunda.io/docs/next/components/modeler/bpmn/inclusive-gateways/inclusive-gateways#conditions)
+- [Incidents](https://docs.camunda.io/docs/next/components/concepts/incidents)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/inclusive-gateways/inclusive-gateways

package/.llms/chunks/components.modeler.bpmn.inclusive-gateways.inclusive-gateways.conditions.md

@@ -0,0 +1,22 @@
+# Inclusive gateway — Conditions
+
+A `conditionExpression` defines when a flow is taken. It is a [boolean expression](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-boolean-expressions) that can access the process variables and compare them with literals or other variables. The condition is fulfilled when the expression returns `true`.
+
+Multiple boolean values or comparisons can be combined as disjunction (`and`) or conjunction (`or`).
+
+For example:
+
+```feel
+= totalPrice > 100
+
+= order.customer = "Paul"
+
+= orderCount > 15 or totalPrice > 50
+
+= valid and orderCount > 0
+
+= list contains(courses, "salad")
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/inclusive-gateways/inclusive-gateways

package/.llms/chunks/components.modeler.bpmn.inclusive-gateways.inclusive-gateways.md

@@ -0,0 +1,39 @@
+# Inclusive gateway
+
+Learn more about inclusive gateways, which allow for making multiple decisions based on data or process variables, and can be diverging or converging.
+
+The inclusive gateway (or OR-gateway) allows for making multiple decisions based on data or process variables. Inclusive gateways can be diverging (a sequence flow is split into multiple paths) or converging (split paths are merged before continuing).
+
+![A process model to prepare lunch at lunchtime can use an inclusive gateway to decide which steps to take to prepare the different lunch components, e.g. cook pasta,stir-fry steak, prepare salad, or any combination of these.](assets/inclusive-gateway.png)
+
+If an inclusive gateway has multiple outgoing sequence flows, all sequence flows must have a condition to define when the flow is taken. If the inclusive gateway only has one outgoing sequence flow, then it does not need to have a condition.
+
+Optionally, one of the sequence flows can be marked as the default flow. This sequence flow should not have a condition, because its behavior depends on the other conditions.
+
+When an inclusive gateway is entered, the conditions are evaluated. The process instance takes all sequence flows where the condition is fulfilled.
+
+For example: Courses selected include `pasta` and `salad`.
+
+![An inclusive gateway has decided to take the steps to cook pasta and prepare salad, but not stir-fry steak.](assets/inclusive-gateway-1.png)
+
+For example: Courses selected include `steak`, `pasta` and `salad`.
+
+![An inclusive gateway has decided to take the steps to cook pasta, stir-fry steak, and prepare salad.](assets/inclusive-gateway-2.png)
+
+If no condition is fulfilled, it takes the **default flow** of the gateway. Note that the default flow is not expected to have a condition, and is therefore not evaluated. If no condition is fulfilled and the gateway has no default flow, an [incident](https://docs.camunda.io/docs/next/components/concepts/incidents) is created.
+
+For example: No courses selected then the default flow is taken.
+
+![An inclusive gateway has decided to take the step to prepare salad as the default because none of the conditions were fulfilled.](assets/inclusive-gateway-default.png)
+
+A converging inclusive gateway (also known as a merging or joining inclusive gateway) merges incoming paths before the sequence flow continues. A converging gateway is completed and merges incoming sequence flows if one of the following conditions is met:
+
+- All incoming sequence flows have been taken at least once.
+- No path exists from any active flow node to the inclusive gateway (excluding incoming paths to the inclusive gateway that have already been taken).
+
+For example: Once all selected courses are complete, the table can be cleared.
+
+![An inclusive converging gateway waits until all incoming, executed sequence flows are completed before cleaning the table.](assets/inclusive-gateway-join.png)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/inclusive-gateways/inclusive-gateways

package/.llms/chunks/components.modeler.bpmn.link-events.link-events.additional-resources.md

@@ -0,0 +1,23 @@
+# Link events — Additional resources
+
+### XML representation
+
+A manual task:
+
+```xml
+<bpmn:intermediateThrowEvent id="Throw_Link_Event_A" name="A">
+  <bpmn:linkEventDefinition id="ThrowLinkEventDefinition" name="A" />
+</bpmn:intermediateThrowEvent>
+<bpmn:intermediateCatchEvent id="Catch_Link_Event_A" name="A">
+  <bpmn:linkEventDefinition id="CatchLinkEventDefinition" name="A" />
+</bpmn:intermediateCatchEvent>
+```
+
+### References
+
+- [Intermediate none events]
+
+[intermediate none events]: ../none-events/none-events.md#intermediate-none-events-throwing
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/link-events/link-events

package/.llms/chunks/components.modeler.bpmn.link-events.link-events.md

@@ -0,0 +1,36 @@
+# Link events
+
+Link events are intermediate events that connect two sections of a process.
+
+Link events are intermediate events that connect two sections of a process.
+
+They have no significance related to content, but facilitate the diagram-creation process.
+
+**Tip**
+You can use link events to create loops, to skip sections of a process, or to simplify the sequence flow lines in the diagram.
+
+Link events have a throwing link event as the "exit point", and a catching link event as the "re-entrance point".
+They are linked together by their link name.
+Multiple throwing link events can link to the same catching link event.
+A throwing link event cannot link to multiple catching link events.
+
+In practice, two paired link events function the same as two [intermediate none events] connected via a sequence flow.
+
+![A pair of link events is equivalent to a pair of intermediate none events connected via a sequence flow](./assets/link-events-example.png)
+
+Link events can be very useful if you draw comprehensive process diagrams with many sequence flows.
+Links help avoid what otherwise might look like a “spaghetti” diagram.
+In the example below, a retry loop is created using the link events pair `A`.
+
+![A pair of link events is used to form a retry loop](./assets/link-events-example-in-practice.png)
+
+**Info: Link events are limited to a single scope**
+Link events can only be used to link sections of a process within the same scope.
+I.e., they can only exist together on the root process level or within the same subprocess.
+
+Similarly, a sequence flow cannot be drawn between flow nodes at different scopes.
+For example, a task in the root process level cannot connect to another task in a subprocess using a sequence flow.
+Link events have the same limitation.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/link-events/link-events

package/.llms/chunks/components.modeler.bpmn.manual-tasks.manual-tasks.md

@@ -0,0 +1,24 @@
+# Manual tasks
+
+A manual task defines a task that is external to the workflow engine.
+
+A manual task defines a task that requires human interaction but no external tooling or UI interface. For example, a user reviewing a document or completing a physical task.
+
+![task](assets/manual-task.png)
+
+Manual tasks are part of [human task orchestration](https://docs.camunda.io/docs/next/guides/getting-started-orchestrate-human-tasks), but differ from [user tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/user-tasks) which define an actionable task assisted by a workflow engine or software application.
+
+Within the engine and BPMN model, a manual task is handled as a pass-through activity, automatically continuing the process at the moment the process instance arrives.
+
+Manual tasks provide insights into the tasks performed outside the process engine, aiding in modeling a process, though no linked automation process is utilized.
+
+### XML representation
+
+A manual task:
+
+```xml
+<bpmn:manualTask id="manual-task" name="Manual task" />
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/manual-tasks/manual-tasks

package/.llms/chunks/components.modeler.bpmn.markers.md

@@ -0,0 +1,18 @@
+# Overview
+
+This document outlines an overview of supported markers.
+
+You might want to execute some tasks for every element of a list, like the `for each` construct in programming languages. Refer to [Workflow Pattern 14: Multiple Instances with a priori Run-Time Knowledge](http://www.workflowpatterns.com/patterns/control/new/wcp14.php): "Multiple instances of a task can be created. The required number of instances may depend on a number of runtime factors, but is known before the task instances must be created. Once initiated, these instances are independent of each other and run concurrently. It is necessary to synchronize the instances at completion before any subsequent tasks can be triggered."
+
+In BPMN, this is implemented using [multiple instance activities](https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance):
+
+Parallel multiple instance markers define that a subprocess is executed multiple times - once for each element of a given collection (like a `for each` loop in a programming language).
+
+Currently supported markers:
+
+- [Multi-instance](https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance)
+- [Compensation](https://docs.camunda.io/docs/next/components/modeler/bpmn/compensation-handler/compensation-handler)
+- [Ad-hoc](https://docs.camunda.io/docs/next/components/modeler/bpmn/ad-hoc-subprocesses/ad-hoc-subprocesses)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/markers

package/.llms/chunks/components.modeler.bpmn.message-events.message-events.intermediate-message-catch-events.md

@@ -0,0 +1,11 @@
+# Message events — Intermediate message catch events
+
+When an intermediate message catch event is entered, a corresponding message subscription is created. The process instance stops at this point and waits until the message is correlated. When a message is correlated, the catch event is completed and the process instance continues.
+
+Inside an [ad-hoc sub-process](https://docs.camunda.io/docs/next/components/modeler/bpmn/ad-hoc-subprocesses/ad-hoc-subprocesses), an intermediate message catch event can also serve as an [AI agent](https://docs.camunda.io/docs/next/reference/glossary#ai-agent) tool, for example to model a step where the agent sends a message and waits for a reply. See [message catch events as tools](https://docs.camunda.io/docs/next/components/connectors/out-of-the-box-connectors/agentic-ai-aiagent-tool-definitions#message-catch-events-as-tools) for the unique-correlation-key requirement that pattern needs.
+
+**Note**
+An alternative to intermediate message catch events is a [receive task](https://docs.camunda.io/docs/next/components/modeler/bpmn/receive-tasks/receive-tasks), which behaves the same but can be used together with boundary events.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events

package/.llms/chunks/components.modeler.bpmn.message-events.message-events.md

@@ -0,0 +1,16 @@
+# Message events
+
+Message events are events which reference a message; they are used to wait until a proper message is received.
+
+Message events are events which reference a message; they are used to wait until a proper message is received.
+
+![process](assets/message-events.png)
+
+Message events are used if a single process instance needs to wait for a message from a secondary process or an external system. This is a single sender to a single recipient relationship (1:1), as the message cannot have more than one recipient.
+
+These differ from [signal events](https://docs.camunda.io/docs/next/components/modeler/bpmn/signal-events/signal-events), which are used if you want to communicate with multiple listeners. For intermediate events, a signal will trigger all process instances with a token waiting at a corresponding catch event, even across different processes. For start events, a signal will start one instance per process that has a corresponding signal start. Unlike message events, signal events form a single sender to several-recipient relationship (1:N).
+
+Both event types are methods of collaboration within BPMN.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events

package/.llms/chunks/components.modeler.bpmn.message-events.message-events.message-boundary-events.md

@@ -0,0 +1,13 @@
+# Message events — Message boundary events
+
+An activity can have one or more message boundary events. Each of the message events must have a unique message name.
+
+When the activity is entered, it creates a corresponding message subscription for each boundary message event. If a non-interrupting boundary event is triggered, the activity is not terminated and multiple messages can be correlated.
+
+The `correlationKey` expression of a message boundary event is evaluated in the activity's own (element instance) scope, consistent with the timer duration, message name, and signal name expressions of boundary events. This means the expression can access variables introduced by input mappings on the activity the boundary event is attached to. If the expression fails to evaluate, the resulting incident is raised on the activity itself, not on its flow scope. This behavior is controlled by the `camunda.processing.evaluate-boundary-event-correlation-key-in-activity-scope` property, which requires a broker restart to take effect. It defaults to `true` in Camunda 8.10 and later. It's also available since Camunda 8.9, where it defaults to `false`.
+
+**Note**
+Set `camunda.processing.evaluate-boundary-event-correlation-key-in-activity-scope` to `false` to restore the previous behavior, where the expression is evaluated in the flow scope instead. The legacy `zeebe.broker.experimental.features.evaluateBoundaryEventCorrelationKeyInActivityScope` property (or its environment variable equivalents `CAMUNDA_PROCESSING_EVALUATEBOUNDARYEVENTCORRELATIONKEYINACTIVITYSCOPE` and `ZEEBE_BROKER_EXPERIMENTAL_FEATURES_EVALUATEBOUNDARYEVENTCORRELATIONKEYINACTIVITYSCOPE`) has the same effect.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events

package/.llms/chunks/components.modeler.bpmn.message-events.message-events.message-start-events.md

@@ -0,0 +1,29 @@
+# Message events — Message start events
+
+A process can have one or more message start events (besides other types of start events). Each of the message events must have a unique message name.
+
+When a process is deployed, it creates a message subscription for each message start event. Message subscriptions of the previous version of the process (based on the BPMN process ID) are closed.
+
+### Message correlation
+
+When the message subscription is created, a message can be correlated to the start event if the message name matches. On correlating the message, a new process instance is created and the corresponding message start event is activated.
+
+Messages are **not** correlated if they were published before the process was deployed or if a new version of the process is deployed without a proper start event.
+
+The `correlationKey` of a published message can be used to control the process instance creation.
+
+- If an instance of this process is active (independently from its version) and it was triggered by a message with the same `correlationKey`, the message is **not** correlated and no new instance is created. If the message has a time-to-live (TTL) > 0, it is buffered.
+- When the active process instance is completed or terminated and a message with the same `correlationKey` and a matching message name is buffered (that is, TTL > 0), this message is correlated and a new instance of the latest version of the process is created.
+
+If the `correlationKey` of a message is empty, it creates a new process instance and does not check if an instance is already active.
+
+**Note**
+
+You do not specify a `correlationKey` for a message start event in the BPMN model when designing a process.
+
+- When an application sends a message that is caught by a message start event, the application can specify a `correlationKey` in the message.
+- If a message caught by a start event contains a `correlationKey` value, the `correlationKey` is used to ensure only one process instance is active per key (idempotency). The `correlationKey` is not stored as a tag on the process instance, and the `tags` field remains empty.
+- Follow-up messages are then checked against this `correlationKey` value (that is, is there an active process instance that was started by a message with the same `correlationKey`?).
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events