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 five pages in plain English Observability, Extensions, Workflow modules in Quarkus and in Spring Boot, Renaming a BPMN process. 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
docs(modules): both platforms read the same four places, and one file uses one of them Quarkus reads a config directory now, the way Spring Boot always did, so the four places are the same on both platforms. They are styles and none ranks above another, so the same file may lie in exactly one of them and a module which ships it twice ends the boot. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs(modules): a config directory is read on Spring Boot and nowhere on Quarkus Spring Boot searches config/<module-id>.yaml and <module-id>/config/<module-id>.yaml for a workflow module, the way it searches a config directory for application.yaml. Quarkus searches neither. Both pages say so now, and both name the place such a file belongs at, which is the same path one directory up. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs(modules): a profile file needs the file without the profile next to it Quarkus reads <module-id>-<profile>.yaml only where <module-id>.yaml lies in the same place. Spring Boot reads it either way. Both pages say so now, and both name the empty file which makes such a module work on either platform. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit 67be40136fa4d08d53dc432922af90bda07a00c4)
docs: what a version your BPMS still holds says about starts and about forks The concurrent-token report and the check of a `@WorkflowStartedByBpms` method now read the versions the BPMS still holds, not only the model of this boot. Spring Boot names the class which carries `@WorkflowService` without being a bean, and Quarkus meets that case while building. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017jAAVCZuSra6VzaVeUHt1d
docs: a process in the file which nothing serves does not stop the application Workflow-tasks gets a section of its own for the case: a BPMN file is deployed as a whole, so a process modelled next to the one the application asked for is deployed with it, and nothing serves it. The application starts now and the deployment writes one WARN per workflow module naming those processes, their file and what such a process costs, so the page says what a reader meets in the log and what the two ways out are. The Spring Boot page said the boot ends in the wiring validation when nothing scanned a module. It does not any more: the module's processes are reported instead, and the sentence now points at the new section for what that costs.
docs: every page opens with what to do and carries a table of contents A reader who has never used VanillaBP met the reasoning for a rule before the rule itself, and had no way of telling how far to read before writing a first workflow. The pages now start with the sentence somebody can act on and keep the background where it belongs, further down. Nothing was deleted; what explains a rule moved behind it. Every page gained a numbered table of contents in the shape Home and the Spring Boot page already used, so a reader sees the sections and what each of them answers before scrolling. Where a first heading only repeated the title GitHub shows above the page, it is gone and the page starts with its first sentence. Home is now ordered the way a newcomer needs it, and what VanillaBP is sized for became a page of its own: it answers a question somebody asks before they start, not one they trip over in the middle of the introduction. The architecture picture from the repository's diagrams folder is embedded there, linking to its Excalidraw source. The horizontal rules of the workflow-module pages are gone, the heading is the separator everywhere else. Hints are written as sentences rather than marked with a label, headings sit at one depth per page, and the paragraphs written by hand over the last months were brought to the tone of the rest without changing a single statement they make. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs: a rule says where its decision is written down Five decision logs hold 61 entries, the wikis linked none of them, and 22 of the 42 objections an outside review raised were already answered in one. A reader who wondered why a rule is what it is had no way there short of reading source repositories. So a rule carries a (why) link now, pointing at the numbered entry which decided it. Home says once what the links are and where the logs live, and the form is the same on every page of every wiki: an inline link at the end of the sentence stating the rule. Numbers are handed out once and never reused, so the links keep resolving. The rules the review named are linked first - the outbox on Camunda 7, probing per operation, the two retentions, sharing aggregate values, the Camunda 8 correlation key - and the remaining entries follow wherever a page states their rule. BPMS-adapters also says in one sentence what the module migration-adapter is, which it linked without explaining. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CvgyhjwTEh834mwbptZZxh
docs: the pages follow the decisions taken since 2026-08-11 Camunda 7 progresses a workflow after the caller's commit, through the outbox, since story 63. Three pages still described the model before it: correlating a message, broadcasting a signal and pushing a changed aggregate all said an embedded BPMS does the work inside the caller's transaction. They now say what every adapter does, with the reason in one sentence - a command which loses a concurrency conflict leaves the caller's transaction rollback-only, so it cannot be repeated there. The ordering paragraph of Workflow-aggregates loses its embedded exception for the same reason: an embedded BPMS is dispatched by the same outbox and promises no order either. A workflow module's configuration file carries defaults again (2026-08-21), so the Spring Boot and Quarkus pages stop promising it higher priority than the application's own files. Workflow-modules-in-Spring-Boot no longer says VanillaBP scans the classpath for workflow services: they are found among the bean definitions since 2026-08-26, which changes what a module nobody scanned looks like at startup. The migration guide's property table said retry-backoff is "not yet in version 2". It is back on the Camunda 8 adapter, PT10S by default and resolvable down to a single task, so the row now points there instead of asking readers to report it. Versions read 2.0 everywhere, without a patch digit and without -SNAPSHOT, and the pages which introduce the BOM say once what that means for a build. Two anchors were dead, workflow-visibility-timeout on the Camunda 8 Configuration page and a section about the aggregate's ID which does not exist on Workflow-aggregates. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CvgyhjwTEh834mwbptZZxh
docs: a workflow module's configuration is a default Story 101. The precedence was nowhere written down, and both platforms answered it differently until now. Said as a list from strongest to weakest on Workflow-modules, spelled out per platform (Spring Boot: the position in the environment; Quarkus: the full ordinal table with the new 235/230), with both examples from practice on either page - a placeholder in a module file resolved against the application, and the application overriding a key the module shipped. Migrating-from-version-1 says this is how version 1 behaved and what to undo if you worked around the snapshot behaviour. Also named on both pages: adapter properties answer a different question. The more specific key wins whichever file it stands in, so precedence and level resolution do not collide.
docs: how a workflow module is published, on both platforms Story 83. Written from what building the blueprint module-multi ran into: the auto-configuration recipe and its registration file, the symptoms when it is missing, the four kinds of names which collide once two modules meet in one application, and the fallback an application is left with. The other platform page gets the section it needs, which is shorter, and the platform-independent page points at both. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ds8wjecxWYszNdKxZX7xtL
docs: where the BPMN of a workflow module under test is looked for Where the application is the workflow module, both the module's own location and the application's root are searched, the module's own one first - a module tested inside its own Maven module is the main artifact of that test while its files sit below the module id. Same rule the module's configuration files follow. Also says that a module none of its adapters found files for is reported as an error. Story 68. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jss55UjjvxYcLQPVFUFe25
Unify the wording of all pages Two passes over the wiki: 1. The pages written earlier (workflow modules, workflow aggregates, the platform integration intros) were aligned with the wording of the newer ones: grammar and typo fixes, consistent terminology (process = the BPMN model, workflow = one execution; message names instead of event names) and active voice instead of impersonal constructions. 2. All pages were revised to read less like generated text: em dashes in prose replaced by proper punctuation, promotional phrasing and filler removed, boldface and inline-header lists reduced to where they aid scanning. Two corrections found on the way: the Quarkus workflow-module page pointed at the "main Spring Boot application module", and the property precedence lists of the two platform pages are sorted in opposite directions, which is now stated (Spring Boot: highest first, Quarkus: lowest first, matching the config source ordinals 250/251/255/256). No configuration key, behavior or example was changed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Document convention over configuration (story 34) Both platform pages lead with the zero-configuration case (one adapter dependency + one workflow module = no vanillabp.* property) followed by 'prioritized-adapters' alone for several BPMS. 'Workflow modules' gains the resources-location convention table - the page a developer looks at when their BPMN is not found - linked from both platform-specific module pages.
Document profile limitation of workflow-module config files in Spring Boot
Loading of workflow module property files from additional classpath locations
Updated Workflow modules in Spring Boot (markdown)
Created Workflow modules in Spring Boot (markdown)