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
docs: a rename keeps its messages and its BPMS-initiated starts Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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: both engines serve a renamed process now, and what each of them cannot reach The table of the second way said Camunda 7 does not serve the workflows of a renamed id at all and left Camunda 8 with a condition to read between the lines. Both adapters serve them now, and the page says how far each of them reaches: Camunda 7 reads the models its engine still holds, Camunda 8 opens a worker per task definition of the declared id where a job type carries the process id. Two cases on Camunda 8 stay out, both because a worker there subscribes to a name it has to compose. A method wired to a BPMN element id names no task definition, and a multi-instance task of the old model has no iteration context. For those the first way is still the one to take, which is now what the first way is recommended for. The start reports what an adapter wired for a declared id, so the list of lines to read after a rename names it.
docs: renaming a BPMN process, end to end A rename is ordinary refactoring everywhere except in the BPMS, where the old id stays with every version ever deployed under it and with the workflows still running on them. The new page carries the recipe: declare the old id as a secondary process, keep the methods which serve it, and read what the start says afterwards. Two things the page insists on, because both cost a working rename. The versions of the old id and of the new one are counted separately, so a numeric range belongs to the declaration it stands on and outfaded-versions belongs under the old id at the workflow level. And whether the workflows under the old id are SERVED differs per BPMS, which the page names rather than promises: a Camunda 8 worker asks for a task definition and reaches them as long as that name does not carry the process id, while Camunda 7 wires the tasks of the models it deploys and does not reach the old id yet. The way which asks nothing of any BPMS is to keep both models deployed until the old workflows have ended, and that is where the page starts. Workflow-tasks links to it from the versioning chapter, where the reader of a version range is already standing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>