Rewrite thirteen shorter pages in plain English
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
docs: a workflow end is canceled, not terminated
Story 360. The kind reported to a `@WorkflowEnded` method is called
`CANCELED` now. The Camunda 8 column also said the kind never arrives there,
which stopped being true with story 370: from the 8.10 release line on the
cluster reports a canceled instance.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RYPiyZ32jQQhqYKx44cw23
docs: the flattening rule links on to what each BPMS makes of it
Every adapter wiki now carries a page "What becomes of a shared value",
answering the same four questions in the same order. This wiki keeps the rule
which is the same everywhere and points at the three pages instead of
repeating them.
Workflow-aggregates: the sharing rule links on to the three pages, and the
serialization-format link of the Camunda 7 adapter follows the chapter which
moved out of its configuration page.
Choosing-a-BPMS gains the row a reader comparing two BPMS was missing, what
becomes of a value the engine has no type of its own for, and BPMS-adapters
names the new page among what an adapter wiki carries.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RYPiyZ32jQQhqYKx44cw23
docs: the Camunda 8 adapter asks for a cluster it can search
Choosing-a-BPMS stops offering the degraded mode: the rows about workflow
awareness, version tags, the viewer's fallback and two ids on one cluster say
what the adapter needs instead of what happens without it, and the paragraph
which called secondary storage the one decision to take is now the requirement
plus the note that a SaaS cluster brings it.
BPMS-migration keeps two guessing adapters, and the second one changes: not a
Camunda 8 cluster without secondary storage any more, but a Camunda 8 adapter
which booted degraded against one, which is the migration away from it and the
one case where accepting the routing by list order is the answer. Workflow-tasks
and the version-1 migration guide lose the old condition.
Two conditions elsewhere were promises of the same degraded mode and read as a
choice a reader still has. Renaming a BPMN process reported the check of the old
versions "where the cluster has its query API", which is now every cluster the
adapter serves. The version check said a BPMS which cannot answer is one whose
query API is unavailable; what is left of that case is a BPMS counting no
versions at all, or a cluster which no longer holds the version being asked
about.
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: Camunda 7 names a delivery where its engine has its own datasource
The two places which state per BPMS what identifies a delivery said Camunda 7 has
none. That holds while the engine shares the application's datasource, where none is
needed, and stops holding for an engine on a datasource of its own: there the
adapter reports the id of the job at hand and a repeated delivery is answered from
the record like on every remote BPMS.
The idempotency row of the comparison follows: on that datasource a handler carries
a repetition only for a user-task notification and for what it does outside its
transaction, which the Camunda 7 wiki describes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XjxJNwTRcKzTmXCwLU7Wi4
docs: what a model has to carry so it correlates, per BPMS
The page described the API and sent the reader to three adapter wikis for the model side, so
whoever took the migration promise literally moved a model from Camunda 7 to Camunda 8 and
found that the correlation needs a different modelling step. One table now says it in one
place: what a correlation id asks of the model per adapter, what it asks without one
(nothing, everywhere), and what the adapter puts into the deployed model itself.
Underneath it, what the call verifies while your transaction is still open, which differs
for a reason worth reading: Camunda 7 fails where nothing waits for the message, Camunda 8
checks the deployed model because its cluster buffers a message for the time-to-live, and
the Process-Engine-API cannot check at all. An application which learned the Camunda 7
behaviour has to unlearn it before it moves.
Choosing-a-BPMS carries a line each and links here.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CvgyhjwTEh834mwbptZZxh
docs: a page for readers who have to pick an engine first
The comparison a newcomer needs existed twice, in the contributor skills and in the review
guide, and neither is published. Choosing-a-BPMS carries it now: one row per property, one
column per adapter, plus what the review found missing - when the shared values reach the
BPMS and what a crash between commit and command leaves behind, what identifies a delivery,
whether the age of an open task is measured at all, and whether the adapter can tell that a
workflow is unknown to it or has to guess. Three of those rows decide how much an
application has to carry itself, so they are repeated below the table in prose.
Underneath it, one short section per question somebody arrives with: a Camunda 7 in
production, a Camunda 8 cluster, or nothing to run an engine on yet.
Home links it from the adapters entry and BPMS-adapters from the top, both in the words a
reader without a BPMS would use.
Home also gets the glossary the wiki was missing. It defines the terms a user meets while
reading it - adapter id, election, the outbox, the delivery log - and stays out of the
contributor vocabulary, which the repositories document.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CvgyhjwTEh834mwbptZZxh