#1784 Remote "write-bearing" classification is inferred from data-plane writes, not declared; external side effects can be re-executed on worker disconnect (docs say the opposite)

Summary

reference/remote-execution/failure-semantics says: "The distinction between no-write and write-bearing is declared at the step level in the workflow definition. The orchestrator does not inspect step behavior at runtime — it relies on the declared step metadata." There is no such field in the workflow schema (swamp workflow schema get --json step keys: name, description, task, forEach, dependsOn, weight, concurrency, dataOutputOverrides, allowFailure, target, labels, platform, queueTimeout, guard). In source, src/serve/dispatch_service.ts decides with const hadWrites = this.#writesByDispatch.has(dispatchId) — i.e. whether the dispatch performed a data-plane write through the orchestrator.

Consequence for operators: a step that has already mutated an external system (API call, kubectl apply, SSH command) but had not yet called writeResource when the worker socket dropped is classified "no-write" and re-dispatched from the beginning → double execution of a non-idempotent side effect, which is exactly what the write-then-fail rule is meant to prevent.

Expected

Either (a) add the documented step-level declaration (e.g. writes: true|false / idempotent: false) that forces fail-instead-of-redispatch, defaulting to the conservative choice for mutating method kinds, or (b) correct the documentation to describe the runtime inference and warn that methods must be idempotent at the external system.

Environment

swamp 20260822.011157.0-sha.06b61472 (source 06b61472), manual as of 2026-08-22.