Make the wiki say what the code does Fix counts, an anchor, an example which did not match its Java code, a stale sentence about Camunda 8.10, and the gap of the election cache which the start row already closes in most cases. 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
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
736: the wiki names the expression check and accept-expressions-in-the-model Workflow aggregates gets the rule next to the getter example, the multi-instance exception where the path stands, and the line which accepts a process. Workflow modules lists the three levels of the key. Migrating from version 1 gets the user side of the UPGRADE.md entry. 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
VanillaBP owns four tables, and decision 16 says so (446) The housekeeping table came with the night window, so Home and the migration page count four now. Observability drops the number. The two links to decision 16 follow its new heading. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RVEfP4rFpf8XUVXB9CFuL7
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
A message starts only the process of its own ProcessService The page on message correlation says what startWorkflowByMessage refuses, quotes the exception and the sentence of the start for an adapter which cannot be checked, and says which adapter decides during a migration. The migration page lists it among the behaviours which differ from version 1. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NGP1Z1mjfXKxCgHzecPvuX
882: version 1 had no outbox, so the paragraph about its table goes "Migrating from version 1" told a reader that version 1 already kept its phase-two calls in the gruelbox table TXNO_OUTBOX. It never did: Stephan confirmed on 2026-10-02 that version 1 had no outbox at all and completed the Camunda 8 job from a listener which ran after the commit. The paragraph goes, and the outbox section says what version 1 did instead and that there is nothing to drain. "Spring Boot integration" keeps the description of the store which used to be here, because the bridge in the platform is real. What changes is the audience it names: an application which ran a 2.0 snapshot, not a version-1 one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017T37nXyH8Gc8d3bcyitce2
385: what the upgrade costs under load The migration page had no section about cost at all and did not link to a sizing page. It gets one now, at the end of "Behaviors that differ", in rows, transactions and threads and without a millisecond. A start costs one outbox entry and your transaction still commits once. On Camunda 7 that count is what version 1 had, because version 1 wrote a job of its own engine in the caller's transaction; what moved is the table and the thread. Answering a message, completing a task and cancelling one are where an application on Camunda 7 pays, because version 1 did that work inside the caller's transaction. Every task delivery costs one record, written in the handler's transaction. The threads are what to size. Version 1 on Camunda 7 used the engine's job executor, three threads growing to ten with Camunda's Spring Boot starter, and version 1 on Camunda 8 used the thread which committed. Version 2 dispatches on four, and on Camunda 7 that is a second pool beside the job executor rather than a replacement. "What VanillaBP is sized for" gets the paragraph which belongs to it: the only threads VanillaBP brings of its own are the outbox lanes, and they hold a connection while they work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017T37nXyH8Gc8d3bcyitce2
780: a wired process with an unserved user task ends the boot Step 0 of the migration said that a user task modelled the way version 1 modelled it is not served and that an open task can no longer be completed. The Camunda 8 adapter now refuses a BPMN process which a @WorkflowService class claims and which carries such an element, so the application does not start until the model is changed. The step says that too. 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/755-the-two-causes-of-a-404-on-an-open-task'
docs: the two causes of a 404 on a user task which was open A user task the Business Cockpit shows as active while a check about it answers 404 is the case Stephan has in operation, under version 1. The page now names it and separates the two causes: version 1 asked the index, which is behind the engine, and the user task shape it served up to 1.6.3 has no user-task record in the cluster at all. Measured on 2026-09-28 against 8.8.39, 8.9.21 and 8.10.0-rc1, counting from the creating listener job: the index answered 404 for 1667 ms, 649 ms and 219 ms, while version 2 asks the engine and got 204 after 12 ms, 21 ms and 13 ms. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
The key belongs to the artifact which reads it The coordinate is the plain 'io.vanillabp:gruelbox-phase-two-outbox', and the one reference to that store says what the key does: with the artifact, 'false' hands the entries back to VanillaBP's own store, and without the artifact the line reads as nothing at all. VanillaBP does not comment on a key it does not own. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
The gruelbox store is named once, and it is named where it lives The store left adapter-platform-integration, so its documentation goes with it. What stays on the Spring Boot page is one section: what gruelbox was, where the artifact is now, and that an application which keeps it changes no configuration. The rows and paragraphs which described how that store differs from the ones VanillaBP writes itself are documented in its own repository. The migration page says the same thing from the version-1 side: entries move to VanillaBP's own table, and what is left in TXNO_OUTBOX is counted at every start. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: the application names the workflow it did not start Starting workflows described the state before stories 504 and 653. It said VanillaBP builds the aggregate of a workflow the BPMS started, that the process instance key or the trigger time becomes its id, and that a workflow can arrive with a business key of somebody else's choosing. None of that is true any more. The page now says what the code does. A @WorkflowStartedByBpms method returns the workflow aggregate, and that aggregate names the workflow. The BPMS holds the name afterwards: Camunda 7 as the business key, Camunda 8 and the Process-Engine-API as the process variable named after the id attribute. Every start is then read from the state of the workflow: a name with an aggregate is our own start, no name is a start past VanillaBP, and a name no aggregate carries is refused. The trigger carries no time, and the section which recommended taking one is gone. The method is required where the BPMS fires a start event by itself; a plain or message start event is judged when somebody uses it, not at boot. Timers and Migrating from version 1 said the same old thing in one sentence each and follow along, the first one also to the renamed section. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: the migration page keeps the rule it asks the reader to recheck Story 530 turned the sentence about the adapter list into a pointer, which is right on a page somebody reads once. This page is read by somebody coming from version 1 with a written configuration in front of them, and the behaviour they have to recheck is exactly that a workflow's list replaces the module's instead of merging with it. The sentence stands here again, with the pointer behind it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: the adapter order stands on the ladder of levels too vanillabp.prioritized-adapters knows the application, a workflow module and a workflow, and no task below them. The section which explains the levels never mentioned it, while four pages explained it themselves. The levels section now carries it, including the two ways it differs from every other setting: a list replaces the list above it, and a level which names nothing keeps out. The platform pages, the migration page and the version-1 page point there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: the last extension on the migration page says adapter
docs: the migration page says adapter in two more places The table of contents for the Business Cockpit chapter and the note about models which stay as they are now use the word a reader of this page knows. The glossary in Home.md already puts both words side by side, so nobody loses the core's term. Quarkus keeps its own meaning of the word, so the four places saying "Quarkus extension" stay as they are. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RYPiyZ32jQQhqYKx44cw23
docs: one word for the reader, and eight places for a setting The glossary now names both words for the same thing: the core calls it an extension, its own documentation calls it an adapter sitting next to the BPMS adapter. The migration page says adapter and points at the glossary. The configuration paragraph said two places. There are eight: four levels, each of them again for one adapter. Checked against MigrationAdapterProperties#resolveForExtension, migration-adapter/README.md and decision 53. It also says now that the core reads from the general towards the specific, and that an extension without a section of its own has nothing to do for it, which leaves the Business Cockpit's own section as the exception it is. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RYPiyZ32jQQhqYKx44cw23
docs: there are three tables VanillaBP owns The payload table came with the outbox, so the count on four pages was one short. Home, Quarkus-integration and Observability only count the tables, so they now count three. Migrating-from-version-1 names them, so it names the payload table as well. The Quarkus outbox section named the outbox table alone while the Spring Boot one names both, so a reader of that page could find only two of the three names. It now names the payload table too. The heading of decision 16 carries the same wrong number and is not touched here, because the links to its anchor would break with it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RYPiyZ32jQQhqYKx44cw23
docs: the Camunda 8 steps are owned by the adapter, and named here Five things a Camunda 8 application has to do lived on this page alone. They are in the adapter's UPGRADE.md now, so each of the five places keeps the sentence which says what to do and links to the step: the user task models, the hexadecimal task ids, the missing cancelUserTask command, the two old tables, and the wait before the service task in front of an end event goes. One correction on the way: cancelUserTask is served by no cluster up to 8.9, not only by 8.8. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RYPiyZ32jQQhqYKx44cw23
docs: the Camunda 7 fallback will go, and no version says when The upgrade page promised that version 2.1 removes the live read of the aggregate. Nobody can hold that promise today, so the page points at what a reader can check: the adapter says once an hour how many workflows the fallback served since the application started, and that number falls as those workflows reach their next sync point. Whoever needs a date asks the VanillaBP team. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RYPiyZ32jQQhqYKx44cw23
docs(aggregates): an aggregate which shares everything has to say so Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Say that the Business Cockpit's keys stayed where version 1 had them The migration page told applications that every cockpit key had moved into the extension section. It did not stay that way: the cockpit reads `vanillabp.cockpit.*` and the `cockpit` sections of a workflow module, of a single workflow and of one of its user tasks, which is where version 1 read them, so an upgrade is a dependency and not a rewritten configuration file. The page about extensions gains what makes that possible. The two locations the core reserves are still the ones an extension uses by default, and an extension which owns a section outside them binds that section itself, with the same overlay a BPMS adapter uses for keys of its own. VanillaBP neither reads those keys nor knows them, and on Quarkus the overlay is what keeps a key below `vanillabp` from ending the startup. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YU73krA4jKHuWYB155np2X
Document extensions and the Business Cockpit upgrade The extensions section of the BPMS adapter page now says what an extension does from an application's point of view: when it joins the deployment, that it may bring annotations of its own, that its reports travel through the outbox, and the two configuration locations the core reserves for it. The Business Cockpit is named as the extension to look at, with its three BPMS repositories and the platform-neutral half in the cockpit's own repository. The migration page gains a Business Cockpit section: the renamed artifacts, the keys moving into the extension's section, the refused version attribute, reports arriving after the commit, and the two things which differ per BPMS - a new process version on Camunda 8 and a history level on Camunda 7. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YU73krA4jKHuWYB155np2X
docs(migration): allow-connectors has a successor, and it is Camunda 8 only The row for vanillabp.allow-connectors stops saying that the key is not in version 2. It names vanillabp.adapters.<id>.allow-connectors, says that the key moved under the adapter because connectors are a Camunda 8 concept, that the three levels are the ones version 1 had, that a more specific level may now switch it off as well as on, that a user task built from an element template stays wired, and that every boot with it on writes a warning. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017jAAVCZuSra6VzaVeUHt1d