decide: -32000 is DISPATCH_FAILED in the shell and SERVER_ERROR in the contract crate

[MichaelTaylor3d]

Task

-32000 is DISPATCH_FAILED in dig-node-service and SERVER_ERROR in dig-rpc-protocol. Decide
whether the shell adopts the crate's name, and say what a client matching the other one sees.

Split out of #478, which pointed the shell's error
catalogue at dig_rpc_protocol::ErrorCode for every other shared code and deliberately excluded this
one rather than renaming it silently.

Why it was excluded there, measured

-32004 was safe to reconcile because RESOURCE_NOT_AVAILABLE_AT_ROOT had zero producers: every
-32004 frame dig-node emits is minted in dig-node-core and framed from dig_rpc_protocol, so it
already carried RESOURCE_UNAVAILABLE. The long name existed only in the discovery document — a lie
about the wire, fixable without touching the wire.

-32000 is the opposite case:

• DISPATCH_FAILED is on the wire. dig-node-service's rpc_error (src/rpc.rs:67-77) puts
  code.name() into error.data.code, and server.rs mints ErrorCode::DispatchFailed at two sites
  (the spawn join failure, and the Sage wallet HTTP fallback arm).
• dig-node-core mints no -32000 under ServerError — grep returns nothing — so unlike -32004
  there is no second name reaching the same client. The shell's catalogue and the shell's frames agree.

So this is a divergence between two documents, not a lie to a client, and renaming it is a genuine
released-wire-name change of the class SYSTEM.md records the dig-rpc-protocol 0.9.0 yank for.

Scope

Pick one and record it in SPEC.md §error table either way:

1. Keep DISPATCH_FAILED and state in SPEC.md that the shell's -32000 carries a more specific
   name than the crate's generic one, deliberately — a dispatch failure is strictly narrower than
   "server error", and the narrower name is the more useful branch key.
2. Adopt SERVER_ERROR, accepting the break, with the migration a renamed wire string needs.

Note that option 1 is not the status quo by default: it needs the SPEC sentence, because today the
disagreement reads as unexamined drift.

Evidence

crates/dig-node-service/src/meta.rs (code() / name(), both carrying a comment pointing here),
src/rpc.rs:74, src/server.rs, dig-rpc-protocol 0.10.2 src/error.rs:113,267.

Parent: #478

[MichaelTaylor3d]

Decision: SERVER_ERROR is authoritative. Reconcile the shell onto it (2026-09-03)

Measured against origin/main @ 04079d57. Building on PR
#518.

This ticket's premise is FALSE, and that changes the answer

The body says:

dig-node-core mints no -32000 under ServerError -- grep returns nothing -- so unlike
-32004 there is no second name reaching the same client. The shell's catalogue and the shell's
frames agree.

That grep looked for the Rust symbol ServerError. dig-node-core mints -32000 as a numeric
literal, which is resolved to a machine name by lookup at frame time:

• crates/dig-node-core/src/seams/dig_rpc/errors.rs:37-42 -- taxonomy_code scans
  dig_rpc_protocol::ErrorCode::ALL by number; :50-56 error_object returns
  RpcError::of(known, message) on a hit.
• dig-rpc-protocol 0.10.2 src/error.rs:113 ServerError = -32000, :267 => "SERVER_ERROR",
  :373 present in ALL. So taxonomy_code(-32000) == Some(ServerError).
• crates/dig-node-core/src/lib.rs:4576 rpc_err delegates to errors::error_frame, and is
  called with -32000 at 11 sites: lib.rs:3043, 3149, 3307, 3310, 3510, 3513, 3595, 3598, 3685, 3965, 4017.
• crates/dig-node-service/src/server.rs:1336-1344 returns core's frame verbatim on Ok(v);
  :1371 (StatusCode::OK, Json(resp)). Not re-wrapped.

So both names reach the same client, on the same port, at the same number -- 11 producers say
SERVER_ERROR, 2 say DISPATCH_FAILED (server.rs:1342 spawn-join failure, :1402 the Sage
wallet HTTP _ => arm).

The repo already admits this three lines from the code the ticket is about --
crates/dig-node-service/src/meta.rs:794-796 says "which the crate calls SERVER_ERROR. That
name IS on the wire". The measurement that was missing is that the CRATE's name is on this
node's wire too.

So -32000 is NOT in -32004's position

For -32004, the divergent name had zero producers -- a discovery-document lie, fixable
without touching the wire, which is why PR #494 could reconcile it. Here both names are published
AND both are produced, in the same process. That is strictly worse, and it cannot be resolved by
narrowing a SPEC sentence. This ticket's option 1 is therefore not available.

Why SERVER_ERROR wins

The decisive argument is empirical, not charter-based: DISPATCH_FAILED is not a working branch
key today. A client matching it at -32000 fails against 11 of 13 producers on the same
endpoint. Adopting SERVER_ERROR removes a name that never reliably worked; it does not break one
that did.

Consumer sweep across all 92 submodules (git grep, control-tested against a known dig-node
hit): zero consumers branch on the string DISPATCH_FAILED. It occurs in exactly two repos --
dig-node's own docs/catalogue, and dig-node-control-interface. The nearest real consumer,
dig-sdk/test/miss.test.mjs:84, branches on the number and is unaffected.

-32000 also sits in the -32000..-32019 node read/serve band that dig-rpc-protocol owns
(error.rs:71), not a shell-private band.

And the precedent is in this repo, on the neighbouring code: meta.rs:669-676 already decided the
identical question for -32004 -- "ONE condition covering BOTH mints, which is why it carries one
name... Which layer answered is carried by data.origin, never by the name." data.origin
already carries shell vs node (rpc.rs:67). The -32000 exclusion is that same rule, not
applied.

It is worse than "one code, two names" -- there are five shapes

#	producer	envelope today
1	dig-node-service DispatchFailed (server.rs:1342, :1402)	data.code = "DISPATCH_FAILED"
2	dig-node-core rpc_err(_, -32000, _), 11 sites	data.code = "SERVER_ERROR"
3	crates/dig-node-core/src/peer.rs:1269	data:{reason} -- no data.code
4	crates/dig-node-core/src/seams/dig_rpc/dispatch.rs:1042	no data at all
5	crates/dig-runtime/src/lib.rs:102 NODE_UNAVAILABLE_JSONRPC	raw literal, no data

All five are in scope for #518. -32000 is a declared code, so SPEC.md:965-970's MUST applies
and its only stated exception is -32001.

A sixth candidate is a vacuity finding, not a producer. content_serve.rs:35
SERVE_UNREADABLE: i64 = -32000 is used only at :995 to set PlaintextOutcome::Unreadable{code, ..}, and its sole sink dig-node-service/src/server.rs:1886 destructures { message, .. } and
returns error_response(StatusCode::BAD_GATEWAY, &message) -- the code field never reaches any
wire. dig-node-core/src/lib.rs:5232's comment calling it a gap in the collision guard is
therefore wrong; there is nothing to enumerate. Being corrected in the same PR.

The guard is fixed by DELETION, not by a new list

crates/dig-node-service/tests/openrpc_drift_guard.rs:~303-305 currently continues past
ErrorCode::DispatchFailed, and its doc comment asserts "the shell mints it and publishes it
under its own name, so shell and wire AGREE there" -- the exact claim refuted above. The loop
already sweeps ErrorCode::all(), which is drawn, not hand-listed, so removing the exclusion
is the whole fix. No enumeration is added.

Pre-checked so nobody trips on it: meta.rs:1318
every_wallet_band_code_dig_node_mints_is_declared_in_the_shared_catalogue is scoped to
BAND = -32049..=-32040 and continues outside it, so it does not go red under this change.

Residue -- filed, not performed here

dig-node-control-interface 0.24.0 (src/error.rs:17,53,123,145,235) independently declares
-32000 -> "DISPATCH_FAILED", inside the node read/serve band dig-rpc-protocol owns. That is a
rival declaration in a foreign band (CLAUDE.md 2.0 centralize-rivals; the survivor is
dig-rpc-protocol). Different repo, different writer -- being filed separately with a cross-link
here. dig-node mints no ControlErrorCode::DispatchFailed, so this lane is not blocked on it.

Nothing is required in dig-rpc-protocol: ServerError is already declared, already in ALL,
already published at 0.10.2. This adopts a shipped name and requests no release.

Parent: #478

[MichaelTaylor3d]

Residue filed, with the cross-link both ways: DIG-Network/dig-node-control-interface#47 — dig-node-control-interface 0.24.0 is a THIRD published declaration of -32000, as DISPATCH_FAILED, inside the band dig-rpc-protocol owns.

Measured before filing so the severity is stated rather than assumed: across all 92 submodules it has zero producers and zero consumers — nothing mints ControlErrorCode::DispatchFailed, and nothing branches on it, including dig-app which depends on the crate. So it is dormant, and its harmlessness is vacuous rather than designed: one call site away from live, in a band whose allocator cannot see it.

dig-node is not blocked on it, which is why #518 proceeds independently.

[MichaelTaylor3d]

Two follow-on measurements, logged as findings rather than filed

The last plausible consumer of DISPATCH_FAILED is closed

dig-app links dig-node-control-interface (19 rlib/rmeta artefacts under
modules/apps/dig-app/target/debug/deps/), so it is a live consumer of the crate that declares
DISPATCH_FAILED at -32000. But a source sweep of dig-app/src and dig-app/crates for
DispatchFailed|DISPATCH_FAILED returns zero hits — it links the declaration and branches on it
nowhere.

Combined with the all-92-submodule sweep already on this ticket, that settles it: no code in the
ecosystem outside dig-node branches on the string DISPATCH_FAILED. Reconciling onto
SERVER_ERROR breaks nothing.

A FOURTH machine name at -32000, in a test harness

modules/apps/dig-app/crates/dig-app-core/src/test_support.rs:1700-1704 mints a fake node reply as:

"code": -32000,
"data": { "code": "UNAUTHORIZED", "origin": "shell" }

UNAUTHORIZED is -32030 in dig-node's control band, not -32000. So this is a fourth spelling of
-32000, and it is one no production path can emit.

Logged here rather than filed as a ticket, deliberately. It is a test harness, never on a wire,
so under CLAUDE.md 1.3c it clears none of the three bars for becoming an issue — not user-visible,
not money/custody/data-loss, not blocking anything in flight. Recording it where the work happened
is the contract's default, and this comment is the record.

It is still worth knowing, because the shape is a known-expensive one here: a harness modelling a
frame production cannot emit is how a fixture stops being able to see the defect it was written
for. Anyone hardening dig-app's node-reply fixtures should fix it in the same pass; it does not
warrant a lane of its own.

Not fixed in #518 — different repo, and single-writer.