979: why links follow the merged platform decisions Decisions 25 and 27 of the platform are merged into decision 5, and 59 into 57. The links point at the entries which hold the text now. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Lxo4MXbp6VPoDkUrTBNXJ1
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
Say what VanillaBP is sized for without "minutes and days apart" The page "What VanillaBP is sized for" now opens with the wording of decision 25: fast or slow workflows are fine, what matters is how many operations they add up to. "Running more than one node" no longer says that slow steps keep an application out of the visibility window. What decides it is whether an operation reaches another node inside that window, and that happens more often the more operations there are. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RVEfP4rFpf8XUVXB9CFuL7
897: an operation on a workflow reads the start row Correlating a message and aggregateChanged read the row written when the workflow started where the election cache has none, so they stay patient after a restart and on another node. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NGP1Z1mjfXKxCgHzecPvuX
docs: the outbox house-keeps in a window at night, and one node does it Both platform pages get a section of their own about it: when the window is, how VanillaBP works out how much fits into it, that only one node house-keeps a store per night, and that a JVM standing on UTC has to name a time zone or it does not start. The three new meters are in the metrics table and in a section which says how to read them together, because the remainder alone says nothing. The page about running more than one node names the housekeeping as the one piece of work a single node does. The paragraph about the cost of a blocked entry is rewritten. The question which payloads are still needed is one statement in the database now, and on a relational outbox it is a lookup over a column rather than a scan of the table - only gruelbox keeps the scan, because it owns its table. The numbers are the ones measured on 2026-09-25. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: the lease is pushed along from the claim, not from the dispatch Both platform pages said the running dispatch pushes the moment along. It has started at the claim for a while, which is what makes an entry waiting for the thread of its aggregate safe: nobody else takes it while it queues. The page about running more than one node carried the same sentence and is pulled along. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0168Fox39crp8dfWkZ9W84Ub
docs: a dispatch holds its outbox entry until it is done A poll used to claim an entry for one attempt-frequency and count an attempt while doing so. A dispatch which took longer lost its entry to the next poll, so the operation was carried out twice, and a slow BPMS spent the attempt budget which block-after-attempts reads. The claim now names the node which took it and how long the claim lasts, and a running dispatch pushes that moment along. The attempts count what ended. Both platform pages say what block-after-attempts counts, what gruelbox does instead, and that reopening a blocked entry clears the claim as well. The page about running more than one node says what happens to an entry whose node disappeared in the middle of dispatching it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RYPiyZ32jQQhqYKx44cw23
docs(outbox): the poll interval is a cap, not a rhythm The poller asks its store when the earliest entry it owes something to is due and sleeps until then, so an entry goes out at its due time whatever the interval says. Both platform pages said the opposite, in the property comment and next to the statement which reopens a blocked entry. What the interval still bounds is work a node wrote down before it went away, which is where the cluster page now says why no node wakes another and why a database notification was not the answer. Observability gains the other half: a sleeping poller takes the heartbeat away, so the page says which number tells a quiet system from a stalled one now, and where to look in a thread dump. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Re2yjHbaFRvnHyW61E3sao
docs: the election cache for Hazelcast is shipped, the SPI stays the contract Both places which said the infrastructure is yours and VanillaBP ships nothing now name hazelcast-shared-election-cache, where the nodes of the application form the cluster themselves and find each other in Kubernetes through a headless service. Writing the bean on Redis or on a table of your own stays the case the SPI was written for, said explicitly in both, and the trap of a node which finds nobody is named where somebody choosing the shipped cache reads it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs: one page for running more than one node What a team needs before it starts a second instance was spread over three pages, and the synthesis was left to the reader. It stands in one place now, and the three pages keep the long explanations and link to it. The correction worth reading twice: a shared election cache is not a requirement for several nodes. Routing never depends on the cache, an entry is a hint, so five nodes cost up to five questions to the BPMS instead of one and nothing else. Where it does bite is the record which says that VanillaBP itself started a workflow, because that is what buys the patience while an eventually consistent BPMS catches up. A node which lacks it does not wait a shorter time, it does not wait at all, and the call raises WorkflowNotFoundException. That needs a remote BPMS, an operation inside its visibility window and a node other than the one which started the workflow, all three at once - which is why the page says who has to care and who does not. Story 197. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XjxJNwTRcKzTmXCwLU7Wi4