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: an inherited @WorkflowService, and the handler methods nobody sees
Workflow-tasks says which class is the workflow service when the annotation sits on a
base class, and names the two ways of writing a handler method which is right there in
the source and never runs. Workflow-modules-in-Quarkus says that a library shipping an
annotated base class does not pull an application's workflow services into the library's
module.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Dsxz15VNs7PoEA7VgBPXHL
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 dependency example carries the version you can paste
The rule is about prose: a version named in a sentence reads 2.0, the release line without a
patch digit. A Maven or Gradle coordinate is not prose - it is copied into a build, where 2.0
resolves to nothing - so the examples carry 2.0.0 again, and the Camunda 8 ones 2.0.0-8.9,
with the suffix naming the cluster minor the artifact was built against.
The sentence which told the reader to fill in a patch himself is gone with it; where it is
useful to know which patches exist, the pages link Maven Central instead.
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
docs: the resolver bean of a multi-instance parameter is an ordinary bean
Says that VanillaBP looks it up while the task runs and that nothing else is needed
on either platform - on Quarkus the build keeps such a bean although nothing injects
it, and says while building when the class is no bean at all. Adds resolvers to the
classes a workflow module's Jandex index has to make visible.
Story 71.
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.
Clarify Jandex index scope in Quarkus (module detection works without index); update versions
Improve documentation and fix wrong information
Loading of workflow module property files from additional classpath locations
Updated Workflow modules in Quarkus (markdown)
Updated Workflow modules in Quarkus (markdown)
Updated Workflow modules in Quarkus (markdown)
Updated Workflow modules in Quarkus (markdown)
Updated Workflow modules in Quarkus (markdown)
Updated Workflow modules in Quarkus (markdown)
Updated Workflow modules in Quarkus (markdown)
Updated Workflow modules in Quarkus (markdown)
Updated Workflow modules in Quarkus (markdown)
Updated Workflow modules in Quarkus (markdown)