979: why links follow the merged adapter decisions Decision 26 of the Camunda 7 adapter is merged into its decision 20, and decision 33 of the Camunda 8 adapter into its decision 27. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
979: the why link of version ranges points at spi decision 8 Decision 5 of spi-for-java is superseded by decision 8, which carries both rules of 5 today. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
Rewrite Workflow tasks, Workflow aggregates and Migrating from version 1 in plain English Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
954: extensions join the check of the deployed version Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
953: link the rule to decision 126 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
953: the version a start deploys needs a method for every task Workflow-tasks gets the section 'The version your start deploys', and Migrating-from-version-1 names the case among the consequences of version. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
952: a BPMN process belongs to one workflow aggregate Workflow tasks gets a section on the rule and on how to decide what a process is: a workflow of its own (a call activity may still call it, the mappings of the call activity in the BPMS set up its data, messages are usually better) or a step of one workflow. Starting workflows and Migrating from version 1 point at it: version 1 logged a warning, version 2 stops the start. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
948: the process at the top may find the same method, with the wrong version The first version of the paragraphs said the id of the process at the top finds none of the methods of a called process. A class serves every process it declares, so it finds the same method. What it gets wrong is the version, which belongs to the called process. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
948: a task in a called process is bound by its own process Extensions.md and Workflow-tasks.md now say which BPMN process an element of a called process belongs to: the called one, not the process at the top. Methods are found under the id of the called process, which secondaryBpmnProcesses declares. The process at the top only names the workflow the aggregate is. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
937: a process nobody claims can be marked as somebody else's A deployed process no @WorkflowService claims ends the start unless the line implemented-externally=true at the process marks it. Such a process is deployed with its file and left alone; a process somebody else deployed is not touched at all. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
834: a served listener keeps its method on a marked element Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
834: a line above the task covers only the tasks without a method Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
834: a task something else serves is marked with implemented-externally Every task of a claimed process needs a @WorkflowTask method or the line implemented-externally=true, user tasks and listeners included, as version 1 asked for the method. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
Name the Camunda 8 adapter in the community hub The Camunda 8 adapter lives in camunda-community-hub/vanillabp-camunda8-adapter, so the links point there. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RVEfP4rFpf8XUVXB9CFuL7
Name the Camunda 7 adapter in the community hub The Camunda 7 adapter lives in camunda-community-hub/vanillabp-camunda7-adapter. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RVEfP4rFpf8XUVXB9CFuL7
892: every row of the delivery log carries the version of its process PROCESS_VERSION is written for a delivery and for the start of a workflow, wherever the adapter names it. Extensions read it with the id through workflowStartOf, and versionsAreReported says whether an empty version may still come. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NGP1Z1mjfXKxCgHzecPvuX
889: the delivery log also says where a workflow runs A row of VANILLABP_TASK_DELIVERY is a processed delivery or the start of a workflow, and RECORD_KIND says which. The start row carries the aggregate and the id that workflow has in the BPMS, which is what saves the question "which of my configured BPMS holds this workflow" - asked of every one of them today, and answered by none of them in the first seconds after a start on a BPMS which reads from an exporter. With it the second period: vanillabp.delivery.workflow-start-retention, thirty days from the start, and the end of the workflow does not take the row. Changes to an aggregate keep arriving after its workflow ended. Where a period is the wrong shape, keep-workflow-start-while-aggregate-exists asks the aggregate instead. Extensions get workflowIdOf, which answers the id and elects nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JEc3zVEgrqjMp2xsPnw1Wy
Story 303: a @TaskParam the BPMS may hand back as something else The section about what a @TaskParam may be declared as now says which two declarations the startup names, and points at the rule. `@TaskParam Object` is the second of them: Camunda 7 answers it with a BigDecimal and Camunda 8 with a Double. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
Merge remote-tracking branch 'origin/wiki/wave-77-compensation-and-states' # Conflicts: # Home.md
docs: cancel means two different things Separates our cancel from BPMN's. WorkflowEnd.Kind.CANCELED and cancelTask keep their meaning and now say what they are not, and each adapter says what it does with a transaction sub-process, which is nothing. Camunda 7 runs the construct, measured against the pinned engine 7.24.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: an error nobody catches BPMN leaves this case to the engine, and the engines differ. Measured Camunda 7: no incident, no log line, the workflow ends at the task and the history calls it completed. Camunda 8 raises an incident, and behind the Process-Engine-API the answer belongs to whatever engine is wired there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: an escalation which leaves no trace Says on the platform page that no API raises a BPMN escalation and that a model can still throw one. Camunda 8 loses an uncaught escalation without an incident, and Camunda 7 does the same, measured against the pinned engine 7.24.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: how far a bpmn error travels Says on the page which explains TaskException where that error ends up: the nearest enclosing boundary event which matches, nothing in between, and an error end event clearing out its subprocess. Names what VanillaBP does not do, which is read the model for it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: eleven states in the specification, two events in the SPI The reason for keeping TaskEvent.Event at two values stood in two decision logs and argued from the two engines alone. It now stands where a reader asks the question, and it names what BPMN asks for. Story 470. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: an error which leaves a called process Nowhere did we say where a TaskException goes when nothing in the called process catches its code. It reaches the call activity and an error boundary event drawn there, which was measured on a Camunda 8 cluster. Compensation is the one construct which does not travel that way on Camunda 8. Story 468. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: what a start says about itself A start collects what it notices and says it once, at its end, as one block between two rulers. Observability describes what the block looks like, how to read its headings and counts, what a start which has to be refused does, and that an application with nothing to notice gets nothing at all. Workflow-modules says what the two delivery keys really read, because vanillabp.delivery.retention was described as having no levels while a line below the application now ends the startup, and it points at the block. Workflow-tasks adds the two questions a held version now answers: a message or signal name no model of this deployment declares any more, and an iteration which names no item although a method serving that version reads it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: the task page says why the delivery records need two prefixes The section named vanillabp.outbox.create-schema and vanillabp.delivery.retention in one breath, which reads like a typo until somebody tells you that the outbox settings own the store and the delivery settings own the period. It says so now. The platform pages already carry that sentence, and no other page makes the jump: the workflow module page and the clustering page name the retention alone. Story 602. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: two stores must not carry one name The pages describe the keys which name the outbox table, the payload table and the table of delivered tasks, and they never said that two of them must not name the same place. The startup has refused it for a while, so the rule now stands where somebody reads the keys, together with the way the names are compared: tables in capitals, collections as they were written. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: the levels are explained once, and the task page shows what they mean there The rule about the levels a setting is written at stood twice: once on the workflow-modules page with its examples, and once on the task page with the job timeout. Two copies of one rule drift apart as soon as one of them is touched, so the task page now keeps the part which is about tasks and points at the page which explains the rule. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: the delivery log's collection has a name you can set The outbox collection and the payload collection carry a name of their own, the log of processed task deliveries did not. Now it does: `vanillabp.outbox.mongo.delivery-collection`, in the same section, because the store settings of that log are the outbox' ones. Both platform pages show the key in their outbox block and say it next to the collection, and `Workflow-tasks` points at it where it names the collection. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RYPiyZ32jQQhqYKx44cw23