Problem/Motivation
docs/distributed.md describes enabling orchestra_client as rebinding the contract so that the same caller code now runs against the remote site, and says the local and remote halves are symmetric. That holds for OrchestraClientInterface, which OrchestraClientServiceProvider::alter() rebinds, and for nothing else.
ProcessControlInterface is never rebound. It is aliased to orchestra.engine, whose only implementation is the local WorkflowEngine, so code that depends on the engine rather than on the client keeps driving the local engine on a consumer site.
orchestra_content is one of those. An attachment holds its instance as an entity reference to orchestra_instance, a local entity, so a binding can only ever name a local run, and AttachmentManager::startForEntity() starts one on the local engine. A site builder who reads the symmetry paragraph and enables orchestra_client alongside orchestra_content gets a local start where they expected a remote one, which surfaces as a workflow that does not exist when the workflows live on the server.
Proposed resolution
Scope the symmetry statement in docs/distributed.md to the client contract, and say which submodules need a local engine and why, so the split is visible before a site is built on it.
While in the same area: docs/actions.md describes the action task's variable target neutrally, as the entity whose ID is held in the named process variable. The node settings form warns there that the action then runs on whichever entity the variable names, with full privilege and no further check, and that it should not be pointed at a variable an untrusted party can set. Someone designing a model from the documentation never sees that; only the person in the form does. The same sentence belongs on the page.
Remaining tasks
Edit the two pages.
AI-Generated: Yes (Claude Code was used to help find this and to draft the issue summary. I reviewed it before posting; there is no code on this issue yet.)
Issue fork orchestra-3622733
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
mably commentedComment #5
mably commented