Say that a read of the viewer API reads the start row A second node, or a node after a restart, now finds a young workflow for the viewer too: the read uses the row written when the workflow started, like an operation does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
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: 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: what a viewer sees right after the start Viewing-workflows gets the case which used to fail: a viewer opened by the application which just started the workflow. Camunda 8 answers from a read model an exporter feeds, so it honestly reports the workflow as unknown for a moment, and VanillaBP waits that moment out where it knows which BPMS holds the workflow. Without that knowledge a wrong id still fails at once, and where the window passes the error names the BPMS which was expected to answer. BPMS-migration says the same in one sentence next to the paragraph about the waiting which happens at the dispatch: a read has nothing to plan and nobody repeats it, so it waits itself. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Story 55: point at what an adapter wiki still carries An adapter wiki is now configuration plus deviations, so the pages delegating BPMS specifics have to name the page which answers them: the wiring conventions and correlation mechanics sit on the adapter's Configuration page, what a BPMS cannot serve on its Deviations page. "What is documented in the adapter's wiki?" listed six kinds of content, four of which the adapters no longer keep. Also says that Camunda 7's table-prefix does not start an engine, where the version-1 migration table offers it as the successor of camunda.bpm.*.
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 the viewing API (story 26) New page 'Viewing workflows': the three read-only ProcessService methods, the call-activity drill-down via the secondary history context, the opaque (adapter-namespaced) process definition ids and the guiding errors - linked from Home.