consistency D1: wire canonical dig-rpc-types/dig-rpc into dig-node + rpc.dig.net (orphaned, 0 consumers)

[MichaelTaylor3d]

dig-rpc-types v0.2.0 (method/error/tier) + dig-rpc server are declared canonical in SYSTEM.md:291 but NO Cargo.toml depends on them; dig-node hand-maintains a parallel catalogue (dig-node-service/src/meta.rs). Wire dig-rpc-types in as the real dependency (release-first §4.1), delete the hand-rolled table, reconcile the union: ADD dig-node control.* namespace to dig-rpc-types; drop/adopt dig.health/dig.methods/getMetadata/getModule/getProofStatus; align error machine-strings (D7: -32000 SERVER_ERROR vs DISPATCH_FAILED, -32004 RESOURCE_UNAVAILABLE vs RESOURCE_NOT_AVAILABLE_AT_ROOT). Fixes D1/D6/D7/D8. Root cause of the whole audit.

Orchestrator ticket: https://github.com/DIG-Network/dig_ecosystem/issues/136

Moved from DIG-Network/dig_ecosystem#137 so this repo's own PR can close it with Closes (CLAUDE.md §1.3).
GitHub refuses a private-to-public issue transfer, so the body was copied and comment history
stayed on the original.

[MichaelTaylor3d]

Verification sweep verdict: NOT SATISFIED — leaving open, roughly half done (2026-09-01)

Verified against code on origin/main (aa9ec72). Symbols re-located by name.

First, a naming fact that resolves the ticket's premise

dig-rpc-types no longer exists; dig-rpc-protocol IS the canonical crate under a new name. The
dig-rpc repo's own Cargo.toml (origin/main 6f896f64) says so: "dig-rpc-types was renamed +
superseded by dig-rpc-protocol v0.3 (yanked on crates.io); this crate now depends on the canonical
crates.io release." Corroborated against the index (User-Agent: dig-loop): dig-rpc-types is
unpublished; dig-rpc-protocol latest 0.10.2; dig-rpc latest 0.7.0.

So the ticket's headline — "orphaned, 0 consumers" — is no longer true for the protocol crate.

What IS satisfied

• Real dependency, at latest: crates/dig-node-core/Cargo.toml:192 → dig-rpc-protocol = "0.10.2";
  crates/dig-node-service/Cargo.toml:161 → dig-rpc-protocol = "0.10".
• Partial adoption with real guards: crates/dig-node-core/src/lib.rs:5247 no_local_wire_code_collides_with_a_different_canonical_code cross-checks every local wire code
  against dig_rpc_protocol::ErrorCode::ALL; crates/dig-node-core/src/download.rs:106 now emits
  the owner's number for ContentMissInconclusive rather than a local copy.
• Catalogue drift guards exist: crates/dig-node-service/tests/openrpc_drift_guard.rs:207 and :236.

What is missing

1. The hand-rolled table is not gone. crates/dig-node-service/src/meta.rs is 1,686 lines and
   pub fn methods() -> &'static [MethodInfo] (~meta.rs:69) is still a hand-written
   &[MethodInfo { name: "dig.getContent", … }, …] literal, not derived from
   dig_rpc_protocol::Method. And the drift guard asserts only one direction (crate methods ⊆
   catalogue) — a catalogue entry with no crate counterpart is unconstrained, so the guard cannot
   catch the divergence this ticket is about.

2. dig-rpc (the server framework) is a dependency of nothing. Zero hits for ^\s*dig-rpc\b
   across all six manifests (root, dig-node-core, dig-node-service, dig-runtime, dig-wallet,
   dig-chat-protocol). The service still owns its own axum transport. That half of the ticket has
   not started.

3. The error machine-strings still diverge — and are now PINNED BY A TEST.
   meta.rs:784-785 maps DispatchFailed => -32000 and ResourceNotAvailableAtRoot => -32004;
   meta.rs:820-821 names them "DISPATCH_FAILED" / "RESOURCE_NOT_AVAILABLE_AT_ROOT". Canonical
   dig-rpc-protocol-0.10.2/src/error.rs:113,124 = ServerError = -32000, ResourceUnavailable = -32004.
   openrpc_drift_guard.rs:150-152 reconciled_error_codes_are_catalogued_with_correct_origin
   asserts the DIVERGENT name. So D7 is no longer a silent drift — aligning it is now a deliberate
   test edit, and anyone attempting the alignment will hit a red test that looks like a regression.
   Worth knowing before the lane starts.

Adjacent live work — read before opening a lane

PR #494 (loop/478-error-name-drift, DRAFT) — "source the shell error catalogue from
dig-rpc-protocol so -3…" — is working the same seam as item 3. Check it before touching meta.rs or
the drift guard; that is a single-writer collision risk.

Scope caveat, stated rather than hidden: the confirming git grep dig_rpc_protocol -- '*.rs' was
truncated at 40 lines. The verdict above rests on positive findings (the manifests, meta.rs, the
named tests), not on that grep being exhaustive — so treat "adoption is partial" as a floor, not a
ceiling.

[MichaelTaylor3d]

Verdict: NOT SATISFIED, and one of its three items is not buildable as written (2026-09-03)

Measured against origin/main @ 04079d57, in worktree C:/tmp/worktrees/dn-496-239.
This refines the 2026-09-01 sweep verdict above rather than repeating it: that comment established
what was missing, this one measures how big each part is and finds one part blocked on another
repo.

What IS satisfied (unchanged from the last sweep)

dig-rpc-protocol is a real dependency at the latest published version:
crates/dig-node-core/Cargo.toml:192 (= "0.10.2") and crates/dig-node-service/Cargo.toml:168,312
(= "0.10"). Index check with User-Agent: dig-loop: latest is 0.10.2.

Item 1 -- derive methods() from dig_rpc_protocol::Method: NOT BUILDABLE TODAY

This is the finding worth the ticket. The canonical crate declares a strict SUBSET of what
dig-node serves, so deriving the catalogue from it would not tidy the discovery document -- it
would delete most of the node's management surface from it.

set	count
dig_rpc_protocol::Method::ALL (method.rs:285-322)	36
dig-node-service::meta::methods() (meta.rs:69, 65 MethodInfo literals)	64 unique names
served by dig-node, not declared by the crate	29
declared by the crate, not served by dig-node	1 (dig.getProofStatus)

The 29 undeclared, in full -- this is the union the ticket asks to reconcile, now enumerated:

cache.pushCapsule            control.hostedStores.unpin   control.updater.checkNow
chat.poll                    control.pairing.approve      control.updater.pause
chat.send                    control.pairing.list         control.updater.resume
control.cache.clear          control.pairing.revoke       control.updater.setChannel
control.cache.get            control.peers.ping           control.updater.status
control.cache.setCap         control.status               dig.getCollateralEpoch
control.capsule.fetch        control.sync.status          dig.getPublicManifest
control.config.get           control.sync.trigger         pairing.poll
control.config.setUpstream   control.hostedStores.list    pairing.request
control.hostedStores.pin     control.hostedStores.status

The crate declares only six control.* names (peerStatus, subscribe, unsubscribe,
listSubscriptions, peers.connect, peers.disconnect). Everything else in dig-node's control
plane -- pairing, updater, hosted stores, sync, config, and the whole chat.* and pairing.*
surface -- is undeclared upstream.

So the ticket's own instruction, "ADD dig-node control. namespace to dig-rpc-types"*, is the
prerequisite and it is release-first work in the dig-rpc repo, not here (CLAUDE.md 4.1). A
lane that derived methods() from today's Method::ALL would ship a discovery document that omits
29 methods the node answers -- a worse lie than the hand-maintained table, and in the more dangerous
direction, because a client generated from it would never try a method that works.

dig.getProofStatus is a genuine, defensible divergence rather than a gap: dig-node deliberately
does not implement it (crates/dig-node-core/src/seams/dig_rpc/dispatch.rs:791,
crates/dig-node-core/src/lib.rs:13156 -- "polls an execution-proof JOB; this node runs none").
-32601 is the truthful answer for a declared method a given node does not serve, and a node is not
required to implement every name in the taxonomy.

Item 2 -- adopt the dig-rpc server framework: unstarted, and NOT blocked on semver

Still zero consumers: no manifest in this repo names dig-rpc (checked all six --
root, dig-node-core, dig-node-service, dig-runtime, dig-wallet, dig-chat-protocol; only
dig-rpc-protocol appears). The service still owns its own axum transport.

Correcting a hypothesis before someone acts on it: the obvious worry is that adopting dig-rpc
would drag a second, older line of dig-rpc-protocol into the tree -- the internally-split defect
CLAUDE.md 2.4b records. Measured against the index, that is true of dig-rpc 0.6.0 (requires
dig-rpc-protocol ^0.7) and false of 0.7.0, which requires ^0.10 and so matches dig-node's
0.10.2 exactly:

0.4.1 -> ^0.4     0.6.0 -> ^0.7
0.5.0 -> ^0.5     0.7.0 -> ^0.10

So item 2 is a large unstarted transport migration, not a blocked one. Pin 0.7.0 or later if it is
ever taken; 0.6.0 would split the line.

Item 3 -- the error machine strings: that is #496, and its premise is false

Being worked now on PR #518.
The short version, because it changes what #496 is: -32000 is not a divergence between two
documents. dig-node-core mints -32000 at ~11 sites as a numeric literal, which
seams/dig_rpc/errors.rs::error_object resolves to SERVER_ERROR from
dig_rpc_protocol::ErrorCode::ALL at frame time; dig-node-service mints the same number as
DISPATCH_FAILED; and server.rs returns core's frame verbatim on the success path. Both names
reach the same client, on the same port, at the same number. Detail on #496 and #518.

Why this ticket is currently unclosable, and what would fix that

As written -- "wire canonical dig-rpc-types/dig-rpc into dig-node + rpc.dig.net" -- it spans two
repos, an unbuilt upstream declaration set, and a transport migration, with no finite done
condition. That is CLAUDE.md 1.3c rule zero. It should be BOUNDED into a named checklist rather
than closed, and the measurement above is what makes the checklist writable:

1. dig-rpc repo (release-first, blocks 2): declare the 29 names above, or a decided subset,
   in dig_rpc_protocol::Method. The decision of which of the 29 are genuinely canonical
   node<->node/controller surface versus dig-node-local is the real work; enumerating them is done.
2. dig-node: derive meta::methods() from Method::ALL once (1) lands, keeping any
   deliberately-local name as an explicit, commented addition rather than a silent one. Note the
   existing drift guard asserts only one direction (crate methods subset of catalogue), so a
   catalogue entry with no crate counterpart is unconstrained -- deriving is what closes that.
3. dig-node: adopt dig-rpc >= 0.7.0 as the transport, replacing the hand-owned axum server.
   Independent of (1) and (2); sizeable.
4. rpc.dig.net: the ticket names it and nothing above measured it. Stated as unmeasured rather
   than assumed done.

This lane does not open those children (CLAUDE.md 1.3c rule 4 -- a lane must not open more issues
than it closes); it records the measurement so whoever does can write them without re-deriving it.

Scope caveat, stated rather than hidden: the 64-name catalogue set was extracted by pattern from
meta.rs and cross-checked against the 65 MethodInfo literals it contains, so one literal is
either a duplicate name or lives in a test. That one-name uncertainty does not move any conclusion
above; the 29-name difference is far outside it.

Parent: https://github.com/DIG-Network/dig_ecosystem/issues/136

[MichaelTaylor3d]

Verdict: the ticket's premise is now partly stale — closing as answered

Re-measured against origin/main (8bac8242) rather than trusting the title.

"dig-rpc-types" no longer exists under that name and its replacement IS wired in. dig-rpc-types 0.1.0/0.2.1 are both YANKED on crates.io — the crate was renamed to dig-rpc-protocol. That renamed crate is a real, non-git dependency of BOTH dig-node crates today: crates/dig-node-core/Cargo.toml:192 (dig-rpc-protocol = "0.10.2") and crates/dig-node-service/Cargo.toml:161 (dig-rpc-protocol = "0.10"), consumed at crates/dig-node-core/src/seams/dig_rpc/errors.rs:32 (use dig_rpc_protocol::{ErrorCode, RpcError}) for the shared -320xx machine names and numbers. PR #518 (merged today) is the most recent instance of this reconciliation, and closes D7 (-32000 SERVER_ERROR vs DISPATCH_FAILED) specifically — one of the four defects (D1/D6/D7/D8) this ticket cites. The parent epic, dig_ecosystem#136, is itself CLOSED.

meta.rs:656's pub enum ErrorCode is not a rival of the canonical taxonomy — it is a documented superset. Every variant that IS canonical cross-references it in its own doc comment (e.g. Unauthorized / -32030: "Canonical dig-rpc-types §10 code"). The rest — WalletNoChainSource (-32040), WalletRateLimited (-32043), PeerPingRefused (-32060), the cache-push codes, etc. — are node-local extension codes with no canonical equivalent, and SYSTEM.md:159's own band table confirms it: -32040..-32049 is "consumer-held, NOT yet declared canonically" and -32050..-32059 (chat) is "its own band... still undeclared and reserved-by-occupancy." A hand-maintained enum that documents dozens of codes the canonical crate doesn't yet own isn't a duplicate table — it's the only place those codes are recorded at all.

What genuinely has zero consumers is dig-rpc (the SERVER FRAMEWORK crate), and adopting it is not a small wiring job. Confirmed via grep — no dig-rpc = ... line anywhere in dig-node. Its own README states the design constraint plainly: RpcHandler::handle(method: dig_rpc_protocol::Method, params) -> Result<Value, RpcError> — ONE match over a closed enum. dig-rpc-protocol::Method (src/method.rs) declares 35 variants. dig-node's actual served surface is a strict superset — control.wallet.*, control.peers.ping, control.mirror.bondStates, chat.send/chat.poll, control.updater.*, the pairing surface, etc. — most of which SYSTEM.md's own error-band table records as not yet part of the canonical taxonomy. Adopting dig-rpc as dig-node's literal transport would require first expanding that closed enum in the separate dig-rpc-protocol repo to cover dig-node's whole method surface — a large, cross-repo, release-first protocol redesign, not something this ticket's "wire it in" framing describes and not achievable "in as little code as possible" inside one dig-node PR.

Disposition

• D7 — done (PR fix(rpc): reconcile the two machine names dig-node emits at -32000 #518).
• D1 (canonical-crate wiring) — done for the error taxonomy; the crate is a real dependency, not orphaned, and the "0 consumers" premise no longer holds for dig-rpc-protocol.
• The literal remaining ask (adopt the dig-rpc server-framework crate wholesale) is a genuine "cannot express" finding: dig-rpc-protocol::Method cannot represent dig-node's actual surface today. That is a separate, large, cross-repo shape decision (expand the canonical Method enum first, in dig-rpc-protocol, release-first) — worth its own ticket if the ecosystem still wants dig-node's transport layer unified onto dig-rpc, but it is not this ticket's "wire in the crate" framing and not something to attempt inside a single dig-node PR without that prerequisite settled first.

Closing as answered — D7 shipped, the crate-wiring half of D1 is done and verified, and the residual (full server-framework adoption) is named with its real blocker rather than left as a stale "orphaned, 0 consumers" title. Reopen, or file a new ticket scoped to "expand dig-rpc-protocol::Method to cover dig-node's control/wallet/chat surface," if that larger redesign is wanted.