979: the fetch-variables link points at decision 19 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
239: the wiki in plain English Shorter sentences, one thought each, and common words, as the section "How we write" of AGENTS.md asks. The meaning, the headings and every link target stay as they were. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
943: a subscription asks for what the extensions read Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
938: the key fetch-variables is gone The table row goes. "What a subscription asks for" says that no key asks for more, that a value no @TaskParam declares is read from the workflow aggregate, and that a start which still sets the removed key ends. The paragraph about an unclaimed process now says it gets no subscription. 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 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
docs: what happens when a task of another application reaches yours A task subscription of this API matches a task type across the whole engine and there is no tenant, so two applications which deploy a BPMN process of the same name take each other's tasks. The Configuration page said how to keep them apart and nothing about what it costs when they are not. The new section says what the refusal is for, what the message names, and why a service task and a user task are answered differently: the service task is failed with a retry count of zero, while UserTaskCompletionApi has no way to refuse at all, so a user task ends in a log line and stays untouched. It also names the counter which answers how often this happens, and says why no delivery record is written. The Deviations entry about isolation points at it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: say where this engine keeps the name of a workflow The page said the aggregate's id travels in every payload but not who chooses it. The application does, and the engine only keeps it, so the entry to look a workflow up by is the one the application knows. A foreign name cannot arrive at a start here, because this API reports no start of its own, and such a workflow shows itself at its first task. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: what becomes of a shared value, on a page of its own The question "what happens to the values my aggregate shares" is now answered by one page per adapter wiki, with the same four questions in the same order, so two BPMS can be read side by side. This adapter said nothing so far, which let a reader assume it behaves like Camunda 7. The answer here is short and it is an admission: the Process-Engine-API carries a payload as a map and says nothing about how an engine behind it keeps one, so this adapter cannot tell you and cannot warn you either. What is pinned down is the in-memory mock, which hands back the objects it was given. The page ends with the measurement to run against the engine you really use. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RYPiyZ32jQQhqYKx44cw23
docs: what the adapter remembers about your models Story 230 lets an extension ask the adapter for a deployed process by user task element id or by form reference, and it gave the meta of a delivered task one vocabulary instead of literals in two handlers. Neither was written down anywhere a reader would look. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Re2yjHbaFRvnHyW61E3sao
docs: who remembers the ids a module took VanillaBP keeps the memory now, so the sentence about the adapter handing over every module of the startup was wrong, and the message it quoted has been reworded. The page also says where the startup stops, because the first of the two modules is already in the engine by then. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Re2yjHbaFRvnHyW61E3sao
docs: what one process id in two modules costs Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Re2yjHbaFRvnHyW61E3sao
docs: what a name clash check can see here The engine behind the API cannot be asked which identifiers it already holds, for any kind. What is new is the check which needs no engine: the names a module's models declare, compared against the other modules of the same application. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Re2yjHbaFRvnHyW61E3sao
docs: an id-less correlation and where the records live Correlating without a correlation id names the aggregate alone, so every occurrence of that message name waiting in the workflow is a candidate and the engine behind the API decides which one receives the message. That was written nowhere. The delivery records live in the application's database, and the engine behind the API can be replaced while the adapter id stays: task IDs start over then, so a record written before the replacement can answer a delivery made after it. The step which prevents that is the same one every rebuilt backend needs and stays on the platform wiki rather than being written a second time here. Stories 196 and 199. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XjxJNwTRcKzTmXCwLU7Wi4
docs: the configuration page starts where a newcomer starts The properties and the shape of the BPMN model are what somebody needs who has just added this adapter, so both come first now. Which engine sits behind the API, how the workflow modules are kept apart and what a subscription asks for follow behind them. Nothing was removed; the sections changed places. Every page carries a numbered table of contents. On the configuration page and on Home each entry says what its section answers; on the deviations page it does not, because every heading there is already that sentence. Where a first heading only repeated the page title GitHub prints above the page, it is gone and the page begins with its first sentence. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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(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>
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.
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.
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.
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>