Lab #3094: Deliver workflow signals through swamp serve

Problem

swamp-club#3093 delivers a signal by creating a write-once outcome record, but only the CLI can signal, and only on a machine with the repository and its datastore. An outside system cannot call in: there is no server form of workflow signal or workflow waits, and no access action a callback identity could be granted.

This issue is the first of four steps. It covers delivery and authority only. Resume stays manual after it; a signalled run is resumed with the existing workflow resume, locally or through serve.

Proposal

One acceptance use case in libswamp (workflowSignal in src/libswamp/workflows/signal.ts), exposed through the CLI, a WebSocket workflow.signal request and an authenticated HTTP POST.
A server form of the waits listing, and --server forms of swamp workflow signal and swamp workflow waits.
A new signal action beside run, read, write, approve and admin. It allows delivering to a wait on a workflow and nothing else. Proposed: a run grant implies signal, as it implies approve, and a signal-only grant suits a callback identity.
A signal names a wait ID and nothing else, so the workflow to authorize against is known only from the wait's registration. An unknown wait ID and an unauthorized caller get the same answer, so a response does not reveal whether a run exists.
Refusals sent to a caller who cannot read the workflow do not name its workflow, run or step, and do not carry an earlier signal's receipt.
Receipt metadata is written by the server: submittedBy is the authenticated principal, never a value from the request. The submitter is an audit actor and is never the identity that executes downstream steps.
Logs and audit events record receipt IDs and outcomes, never the payload.
The waits listing shows a caller only the waits of workflows they may read or signal.

Open decisions

Does a run grant imply signal? Proposed yes, with a serve flag to require an explicit grant, as runImpliesApprove has.
Whether a signal-only grant may list waits, or only deliver to a wait ID it was given.

Acceptance criteria

A caller holding only a signal grant can deliver a signal over HTTP and over WebSocket, and cannot start, approve, resume or read a run with it.
An unknown wait ID and a wait the caller may not signal are answered identically.
A signal delivered through serve is applied by the next resume exactly as one delivered by the CLI.
All serve instances on a datastore must be upgraded before a workflow with a wait is run; an older instance refuses such a run rather than mishandling it (already the case since swamp-club#3093).

Tests

Access tests for the signal action and for the indistinguishable unknown and unauthorized answers.
Handler tests for payload refusal, an already settled wait and an expired wait over both transports.
CLI and HTTP journeys in swamp-uat.

Follow-ups

swamp-club#3108: resume signalled runs automatically (continuation claim and sweep).
swamp-club#3109: settle expired waits from serve, and a serve-configured maximum timeout.
swamp-club#3110: show signal waits to remote clients and the dashboard.

Out of scope

Everything in the follow-ups, plus provider webhooks that resolve a wait, reserving a wait before a request step, capability links, schema-generated forms, wait_until polling, and leases with fencing for executors.

Depends on

swamp-club#3093 (write-once outcome records), merged.

References

The Wait for Signal section of design/primitives/workflows.md, including Mixing builds and Limits of this version.

A nested structural swamp still waits on its run's lock when the lock holder is not a same-host ancestor (cross-host worker, --server into a non-ancestor serve)

A nested structural swamp that outlives the run that started it keeps skipping that run's lock while the holder writes

Show signal waits to remote clients and the dashboard

Settle expired signal waits from swamp serve

Resume signalled workflow runs automatically under swamp serve

Deliver workflow signals through a write-once outcome record instead of writing the run record

Forward held-lock identity over --server so a loopback nested swamp does not wait on its caller's lock

A nested structural swamp on a same-host remote worker waits on its own step's lock held by swamp serve

Fail fast when nested structural commands under parallel runs wait on each other's locks

Docs: remove followUpActions from the MethodResult reference in the extension model manual

signal_test: already-settled test fails by chance when a random UUID spells the sender name

Add a wait_for_signal workflow step that pauses a run for a JSON message

Deliver workflow signals through swamp serve

run doctor through serve interrupts a live run of another serve instance when no heartbeats are recorded

Flaky test: WalSink replayed segments are delivered before events written after replay leaves one WAL segment

Remove followUpActions: no model or extension can produce them

Workflow schedule watcher and workflow edit symlink lookup ignore the managed config workflows dir

main is red: repository_dirty_coverage_test fails for UnifiedData.collectGarbage(orphaned deferred write)

isProcessGone always reports alive on Linux under the test task permissions, failing 9 tests on main

Flaky test: WalSink replayed segments are delivered before events written after replay

serve: relative tls cert-file/key-file and --config resolve against the working directory, not the repository

findBySpec/findByTag lose a workflow step's output after a version is deleted, pruned or rolled back

serve HA: worker enrollment on a replica that lacks the enrollment token's definition may create a second definition (unverified)

serve HA: pull a token's definition on an auth miss so a peer accepts a new token at once

Run tracker keeps some interrupted workflow rows forever: retention waits for markSettled, which several paths never call

run doctor reads every run record on each run to rebuild the run indexes

Serve audit: two sinks with the same name share one emitter cursor, so the second never receives events

Serve audit: a durable sink write that times out is retried while the first call is still pending, so the store can hold duplicate sequences

Flaky test: ModelResolver data accessors for a renamed model return the earlier id's record from findBySpec

data query --limit returns fewer live records than exist and reports limited: false when stale catalog rows fall inside the limit

data get: help example passes --run latest, which is not a recognised run id

workflow reject leaves sibling gates waiting_approval and dependents pending in a failed, retryable run

Show expired approval gates as expired, with a Cancel action in the dashboard

digitalocean codegen leaves an orphaned security_secret.ts model file after its endpoint left the spec

workflow cancel cannot cancel a suspended run whose workflow file was deleted, and cancel --all silently skips it

A job alone in its level starts after the abort, and its unstarted step is recorded as a real failure instead of settledByAbort

workflow approve racing workflow cancel loses the cancel: the run returns to suspended after cancel reported cancelled

data query: does not follow data rename forwarding that data get follows

Unit tests share fixed /tmp catalog paths, so concurrent runs corrupt them and fail every later run

data query: renamed data items are not found by their old name

data query: model lookup by id and orphan recovery parity with data get

workflow approve on a run that is not suspended prints a fatal error with a stack trace

data query: no way to target a workflow's latest run

data query: binary content lacks contentEncoding/base64 parity with data get

data query: no fallback from spec name to data instance name

data query: no definitionHash or garbageCollection fields in query results

A nested structural swamp spawned by swamp serve skips every lock serve holds, including other runs' locks

data query: confirm catalog parity with data get for custom datastores

data query: single-result --json mode for scripts migrating from data get

Docs: document data query --single and fix the stale --limit default in reference/data.md

Relationships

#3094 Deliver workflow signals through swamp serve