Setting the file. One moment.
Subchapter 27.10
references/publishing.mdMarkdown4 KBView on GitHub
Publishing is never required for testing. Never publish a workflow as a precondition for running it.
Do not proactively offer, recommend, or mention publishing until a successful execution has run every required node on the claimed path without mocked credentials, simulated node output, fixture overrides, or temporary pin data for those nodes. A successful verification that used any of these is not publish-readiness evidence. If the user explicitly asks to publish before a live execution succeeds, warn that the live path remains untested, then follow the requested publish flow.
publish_workflow enforces this. While the latest verification left
nodes unreached or simulated, the call is refused and returns
verificationDisclosure — the coverage facts, generated from the run. Relay
those facts to the user and offer a live end-to-end test. Publish only if they
still ask, by calling publish again with acknowledgeUnverified: true. Never
set that flag to skip the disclosure. The user also sees the same facts in the
publish approval prompt, so a summary that contradicts them is visible to them.
Execution evidence can come from a run you started or a run the user started. If the user says they ran the workflow manually, call , identify the relevant run, and inspect it with . The user’s statement alone is not execution evidence. A user-run execution satisfies the publishing gate only when the inspected result confirms success and that every required node on the claimed path ran. Do not count it if mocked, simulated, fixture, or pinned output was used. You may offer publishing after that confirmation.
list_executions( workflowId)get_execution( executionId)Only call publish_workflow when the user explicitly asks to
publish. Never publish automatically or proactively offer publishing before
the publish-readiness requirement above is met. A repair of a workflow that
is already published is the exception: you may ask whether to publish the fix
before that requirement is met, as the section below describes. Still publish
it only after the user agrees.
The publishing rules above assume a new workflow. A repair of a workflow that is already published is different. That workflow runs in production right now, and it runs the version published before your fix. Your save creates a draft, and the draft is not live. The published version keeps running, broken, until somebody publishes the fix.
For a repair on a published workflow:
workflow_builder_verify_built_workflow returns claim.liveState. live-stale means the
published version is older than the draft you just verified. The result also
carries liveStateNote. Relay it.get_workflow(workflowId) and compare
versionId (the draft) with activeVersionId (the published version). They
differ while the fix is not live. A null activeVersionId means the workflow
is not published at all.