docs: a rule says where its decision is written down The rules of this wiki carry a (why) link now, pointing at the numbered entry of this adapter's decision log which decided them. The form and the reason are the same across all four VanillaBP wikis, and the platform wiki's Home page explains them once. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CvgyhjwTEh834mwbptZZxh
docs: versions in the examples read 2.0 Without a patch digit and without -SNAPSHOT, and Getting started says once what that means for a build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CvgyhjwTEh834mwbptZZxh
docs(configuration): what a subscription asks the engine for Story 99: the adapter stopped subscribing with an empty payload set. New section plus the adapter's first configuration key, fetch-variables, which carries the name and the values it has on Camunda 8. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs: an overdue open task is only reported here VanillaBP measures how long a task left open by a @TaskId handler has been waiting and says so once it passed vanillabp.delivery.max-task-age. The API hands out a task subscription rather than a lock this adapter renews, so there is nothing to stop and no incident to raise instead. Story 89. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Say what this BPMS does with a task whose transaction failed A version conflict on the workflow aggregate is one of the ways a task fails, and story 59 asks every adapter's wiki to say what becomes of such a task here. Points at the platform wiki's new section for the rule itself.
Say what VanillaBP does with the older versions a BPMS holds Story 57: the start looks at the versions still deployed, reports the task definitions of older ones no method serves any more, and offers 'outfaded-versions' to declare a version obsolete. Each adapter page says what its BPMS can answer - Camunda 7 everything with the engine at hand, Camunda 8 only with secondary storage, the Process-Engine-API nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MUj1bzCMbmhZYtg6u7fWD8
Say what a task without a version tag reaches Where the engine supplies no version tag, methods without the version attribute are the only ones a delivery reaches - a task whose every method names versions fails the delivery instead of running one of them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0182ZE1WCkm5p3ogRFxusoKT
Story 51: a task delivered twice runs the handler once
Story 55: trim the wiki to configuration and deviations The wiki now carries only what a user of this adapter needs and the main VanillaBP wiki cannot tell them: how to configure it, how to plug in a real engine, what the BPMN model has to look like, and where the Process-Engine-API does not carry a VanillaBP feature. Workflow-tasks, Message-correlation, Transactional-behavior and Viewing-workflows are gone. Their user-facing parts moved into Configuration, the rest is contributor material which GAPS.md and the README already carry. New page Deviations turns the gaps into one sentence each, linking the GAPS.md entry with the full reasoning. Three of them were missing from the wiki entirely: starts the engine performs itself, the end of a workflow and aggregateChanged.
Story 48: what the Process-Engine-API can tell about versions Only the version tag of the current task, and only where the engine behind the API puts it into the task meta. Everything which has to be placed in the deployment order matches nothing and is reported once.
Make the pages read less like generated text Em dashes in prose replaced by proper punctuation, promotional and filler phrasing removed, boldface reduced to where it aids scanning. Wording only, no statement about the adapter's behavior was changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A name-clash-avoidance mode has to be chosen (story 35) The Process-Engine-API offers no isolation of its own, so VanillaBP's default cannot be served here: - Home: the minimal configuration carries the mode, with the reason the boot fails without one; - Configuration: new section "Keeping workflow modules apart" - the mode table (by-adapter unsupported, use-prefix rewrites the deployed BPMN itself because the API has no model type, none scopes nothing) and the note that prefixing is transparent; - Workflow-tasks: with prefixed task definitions the subscriptions are unique per process, so routing a delivered task no longer depends on the 'bpmnProcessId' meta entry.
Document the payload of completions, correlations and message starts (story 28b) The known gap is closed: every command the adapter sends on behalf of a workflow carries the shared attributes plus the aggregate-ID variable - not only the start commands, but also the completion at the end of a @WorkflowTask (completeTaskByError included), asynchronous task completion and cancellation, user-task completion and message correlation. That is what makes a gateway directly behind a task work; the aggregate is read after the local transaction committed and a failing read still completes the task with the ID variable only. Message correlation keeps the payload doctrine: no message content travels, only the aggregate state.
Document what this adapter shares with its BPMS (story 28) The default of this adapter, what 'shared' means for it, when the data is handed over and which values are written independently of the annotations - the BPMS-specific half of the platform wiki's workflow-aggregate page.
Document convention over configuration (story 34) The minimal configuration becomes 'add the dependency': adapter, workflow modules and the BPMN location are derived from the classpath. What deviates is documented where it belongs - what makes two adapter ids of this type distinct, and (Camunda 7) the new 'table-prefix' plus the rule that several datasources demand an explicit 'data-source-name'.
Document the viewing API (story 26) New page 'Viewing workflows': the three read-only ProcessService methods, the call-activity drill-down via the secondary history context, the opaque (adapter-namespaced) process definition ids and the guiding errors - linked from Home.
Explain why Quarkus needs at least one property per section The startup now reports the behavior itself, so the caveat says what the message says. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Show the minimal, convention-based configuration An adapter id which IS the adapter type needs neither a 'type' property nor a 'prioritized-adapters' list. Home now shows that variant first and the custom-id variant afterwards. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Document the Process-Engine-API adapter Home now explains what the adapter is, how to add it on Spring Boot and Quarkus, the minimal configuration, and links to the BPMN documentation as well as to the VanillaBP wiki. Added the pages Configuration, Workflow tasks, Message correlation and Transactional behavior carrying the BPMS-specific content moved out of the VanillaBP wiki, plus a custom footer with the VanillaBP logo and the license notice. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Initial Home page