D1: an unhonoured worker: promises users an error at 6.0.0, and the design doc says the flip was dropped #798

Summary

Two records of the same decision disagree, and the one users act on is the code.

src/nodus/orchestration/task_graph.py has printed this since 5.3.0, on
every worker: declaration with no registered dispatcher:

warning: step declares worker 'remote', but no worker dispatcher is registered,
so it runs in this process with no isolation. Run under `nodus serve` with a
registered worker, or pass `worker_dispatcher=` to NodusRuntime.
This becomes an error in 6.0.0.

The comment above it commits to the same thing: "6.0.0 makes it an error,
matching how the concurrent-write conflict was staged (#547)."

docs/design/v6/00-record-equality.md says the opposite:

(Corrected 2026-08-26: this line also named #492 (worker:), which closed
during the 5.4.0 cycle and is not part of the cohort.)

Closing #492 did not retract the promise. The warning still ships, still
names 6.0.0, and had no open tracker until this issue — which is how it came to
be absent from every register of the cohort except the code.

Reproduced at 5.11.0:

step a with { worker: "remote" } { return "a" }

→ the warning above, then the step runs in-process, exit 0.

Why it matters more than a stale comment

A worker: declaration is an isolation intent. Running in-process and
reporting success is the worst available answer — the same reasoning that made
this a warning rather than a silent no-op in the first place. Whichever way the
decision goes, the current state is the one option nobody chose: a promise in
front of users that no plan owns.

The decision

Exactly one of these, and it is docs/governance/V6_0_PLAN.md D1:

(a) It is in the cohort. Then it flips with the rest: the warning becomes
vm.runtime_error(...), this issue tracks it, and COMPATIBILITY.md keeps its
entry. The signal has aged since 5.3.0 — the longest of the five, so nothing
about notice is a blocker.

(b) It is not. Then the promise has to come out of the warning text now,
because it is a commitment being made to users on every run. The warning itself
stays — it is correct and useful — minus the sentence about 6.0.0. And
COMPATIBILITY.md's entry comes back out.

Recommendation

(a). The reasoning in task_graph.py still holds and nothing has changed
about it; the staging was explicitly modelled on #547, which is going ahead; and
the signal is the oldest in the cohort. Option (b) means telling users for eight
minors that something would become an error and then quietly not doing it,
which costs more credibility than the flip costs anyone in breakage — an
unhonoured worker: is already a program that is not doing what it says.

But this is a decision, not a defect with an obvious fix, so it is filed rather
than taken.

What to do

• Decide (a) or (b).
• If (a): change the site in report_* from a stderr warning to a runtime
  error at 6.0.0; keep both remedies in the message (nodus serve with a
  registered worker, or worker_dispatcher=).
• If (b): drop the last sentence of the warning, remove the
  COMPATIBILITY.md entry, and close this.
• Either way, correct docs/design/v6/00-record-equality.md, which
  currently flags the contradiction rather than resolving it.

Affected versions

5.3.0 onward.