Lab #3078: Remove followUpActions: no model or extension can produce them

Description

Found while triaging swamp-club#2929. followUpActions (a method result asking the executor to call another method on the same definition, with delayMs, maxRetries and continueCondition) has had no producer since February 2026, and no extension can reach it. Remove the feature rather than keep maintaining it.

Why it is unreachable

Its only producer, the built-in AWS::EC2::Instance CloudControl model, was deleted in c07cd86a (2026-02-12). No built-in model returns follow-ups today.
Extension models cannot return them: wrapUserExecute in src/domain/extensions/model_kind_adapter.ts returns only { dataHandles }, at both places a user method is converted (new model and extension of an existing model). This has been the case since 7e79e070 (2026-02-10).
Those are the only two ways a model definition is registered (model_kind_adapter.ts and the built-in registration in model.ts), and a worker executes the same wrapped methods, so the remote path cannot produce them either.
Confirmed with the installed binary: an extension method returning followUpActions with delayMs: 2000, maxRetries: 8 completed in 17 ms and the follow-up method never ran.
It is not documented for extension authors. The only mentions are in design/enablers/remote-execution.md.

Cost of keeping it

The retry loop ignores the run's abort signal (swamp-club#2929) and is exercised only by its own unit tests.
The remote-execution work carried the plumbing across the worker boundary, with a documented known divergence (continueCondition is dropped on the wire).

What to remove

FollowUpAction and MethodResult.followUpActions in src/domain/models/model.ts
processFollowUpActions, delay, DEFAULT_MAX_FOLLOW_UP_DEPTH and the call site in src/domain/models/method_execution_service.ts, plus their unit tests
The pass-through in src/domain/models/in_process_executor.ts and src/domain/models/execution_envelope.ts
The remote plumbing: src/domain/remote/protocol.ts, src/domain/remote/remote_dispatch.ts, src/serve/dispatch_service.ts, and serializeFollowUpActions in src/worker/exec_dispatch.ts
The two followUpActions passages in design/enablers/remote-execution.md

To check during triage

Wire compatibility: followUpActions is an optional field on the dispatch result schema, so an orchestrator and worker on different versions must still interoperate once it is gone.
Whether any published extension returns followUpActions expecting it to work. It would already be silently ignored, so removal changes nothing for it at runtime.

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)

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

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

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

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

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

data get --workflow silently returns an arbitrary step's data when several steps share a data name

swamp doctor workflows misses nested and .yml extension workflows that the loader reads

auth whoami says the stored API key is no longer valid when auth.json only holds an env-key identity cache

Docs: swamp skill says cancelling a parent run cancels its nested child runs; the child is left suspended

Namespace advice in the slow-lock warning is wrong for a single repo on a local datastore

Method-run records left running by a dead owner are never reaped

Flaky: usecase_sync_characterization_data_test 'data gc (serve)' asserts markDirty order that varies under parallel load

Worker dispatch rebuilds the definition with Definition.create, so a legacy-named model cannot run on a worker

A cancelled workflow exits before its steps stop, leaving their method-run records at running

Nested swamp structural command in a shell step times out on its parent's per-model lock (SWAMP_LOCK_HOLDER_PID is stripped)

Auth gate blocks nested swamp in workflow shell steps when the credential is in SWAMP_API_KEY

Relationships

#3078 Remove followUpActions: no model or extension can produce them

Description

Why it is unreachable

Cost of keeping it

What to remove

To check during triage

Shipped