feat: serve dig.getRewardProverStatus at Tier::Control

[MichaelTaylor3d]

DO NOT MERGE — gate round in progress.

Refs #3269

Serves exactly ONE of the ticket's four methods: dig.getRewardProverStatus. The other three (listRewardDistributors, getRewardDistributor, listRewardDistributorCommitments) are blocked on #3249 (dig-rewards-coin chain driver, not yet published) and are intentionally absent — no stub, no todo!().

Work in progress; will update this description as commits land.

[MichaelTaylor3d]

Adversarial leg (loop-decider) — dig_ecosystem#3269 triple gate

Head audited: 6be80c978c208d0ee1d54bea9b33552ed0af3797 (unchanged during the read). Sources read directly: this diff, dig-rewards-coin/SPEC.md at tag v0.1.3 (§2.3, §2.4, §2.6, §7.4), dig-rpc-protocol 0.11.0 types.rs/method.rs, dig_ecosystem#3274, dig-app#403 + origin/main of dig-app.

Verdict: MERGE-WITH-CONDITIONS

Two conditions, both checkable, one before merge and one on the ticket graph. The premise attack does not sink the PR; it does sink the story being told about it.

Why this is not the inert pattern. The "nothing executes yet" argument was retired because money arithmetic in rewards/ was landing that could only be validated against a chain. This PR has no arithmetic and no chain dependency: the handler is reachable over the loopback control surface the moment it ships, and every behaviour it has (tier, enum dispatch, explicit field mapping, u32→u64 widening, per-launcher attribution) is exercised in-process by the tests in lib.rs:9041+. Its correctness does not become more knowable by waiting for #3265. That is the opposite of the #593 situation.

Positions on the five items

1. Registry with no production writer. The orchestrator's reasoning holds, with one correction. {"statuses": []} is true today under SPEC §2.4 clause 1: a funded distributor with no record renders "not distributing", and this node build is in fact not distributing. A hardcoded vec![] would have identical output today and diverge silently the day #3265 lands; the registry read does not. #[cfg_attr(not(test), allow(dead_code))] does not launder anything — the fn is pub(crate), its doc names #3265 as the writer, and the attribute is the only way to keep -D warnings green without a fake caller. Not a reason to hold.

2. Does it reach a user? No — and the urgency premise in the brief is false. dig-app#403 is OPEN and unmerged (head 61321969); dig-app's latest release is v15.4.0, there is no v15.5.0 tag; rewards::pane::rewards_sections() has zero callers outside src/rewards/ on dig-app origin/main (the #403 body itself says the store-row mount is "explicitly NOT shipped"). Clawback additionally needs dig.listRewardDistributorCommitments, which this PR does not serve. Merging #595 unblocks no user-visible function. Report it upward as "the first Control-tier reward read is served; nothing user-facing changes until #3265 (writer) and the commitments method land" — not as progress on the pane.

3. The all-zero launcher_id omission is the dangerous branch. Condition A: remove it. Facts: rewards/cycle.rs:121's idle_status([0;32], …) is inside #[cfg(test)] mod tests (cycle.rs:115-116); no production code constructs a zero-id record — the filter defends against nothing that exists. If #3265 ever does register one, that is a real defect and this filter turns it into "no record" → dig-app renders "Not distributing" — exactly the silence §2.4 clause 1 forbids. It also violates §2.6's contract that the method returns "the §2.3 record" (the handler is silently editing the set, the same class of handler-side correction the orchestrator correctly refused for #3274). It is asymmetric (zero store_id/root pass through). Remedy: delete the .filter(|s| s.launcher_id != [0u8; 32]) at dispatch.rs and the test get_reward_prover_status_omits_an_all_zero_launcher_id; if a guard is wanted, put it at the writer (register_reward_prover_status refusing/panicking on a zero id, which is #3265's concern) — never as a silent read-side drop. Checkable: grep -n '\[0u8; 32\]' crates/dig-node-core/src/seams/dig_rpc/dispatch.rs returns nothing.

4. Subject of the money numbers. The attribution test proves each figure travels under its own launcher_id and neither sum nor swap appears — that is the strongest thing this boundary can prove. It cannot stop the 250x class: the wire carries no subject, and the 0.11.0 wire docs (types.rs:1505-1507) say only "the distributor's reserve" / "over the loop's lifetime". The consumer-side fix (label as the distributor's totals, never the operator's) belongs in dig-app#403's gate, not here. Sufficient at this boundary; not a merge blocker.

5. #3274 does not block this merge; filing is sufficient, conditional on linkage. Condition B. With no production writer the counters are never non-zero, so the restart-reset cannot manifest until #3265 spawns a loop. The defect lives in the record (#3250's file set) and §2.4 rightly forbids this handler correcting it. Note two things for whoever owns it: the 0.11.0 wire doc already says "over the loop's lifetime", which leans toward #3274's option 2 (since-process-start) and makes a SPEC/wire alignment cheaper than persistence; and #3265's body currently does not reference #3274 (grep on its body for 3274/persist/restart returns nothing). Condition B: #3274 is recorded as a hard blocker on #3265 (a "Blocked by #3274" line in #3265's body or a pinned comment) before #3265 registers any production writer. Checkable by reading #3265.

One further note, not a condition

The launcher_id filter path returns [] for a malformed (non-64-hex) param instead of a JSON-RPC invalid-params error. Under §2.4 clause 1 an empty list reads as "not distributing", so a typo in a caller's id silently reads as a state claim. Worth a follow-up ticket for whoever next touches dispatch.rs; not blocking because the only consumer is Control-tier and dig-app currently sends no filter.

Failure direction of the wrong call

Holding this PR until #3265 lands would gate a chain-free, fully-testable boundary on chain-dependent work — reintroducing the coupling the inert-pattern rule was meant to break. Merging with the zero-id filter in place ships a silent read-side data drop on a money surface that the driver has now seen bite three times.

[MichaelTaylor3d]

Security audit — CHANGES-REQUIRED

Head SHA audited: 6be80c978c208d0ee1d54bea9b33552ed0af3797 (matches gh pr view 595 --json headRefOid)

Scope

crates/dig-node-core/src/{lib.rs, seams/dig_rpc/dispatch.rs, peer.rs}, crates/dig-node-core/Cargo.toml, crates/dig-node-service/Cargo.toml, Cargo.lock, tests/{dependency_tree.rs, reward_methods_tier_guard.rs}, plus the vendored dig-rpc-protocol 0.11.0 source (method.rs, types.rs) read from the local cargo registry cache to verify tier/reachability at the crate that actually defines them.

1. Peer reachability — CLEAR, verified independently, not just by the new tests

• dispatch.rs:285 — Method::from_name(method) is the only place Some(Method::GetRewardProverStatus) is matched (added at dispatch.rs:732). The string pre-match block above it (dispatch.rs:236-268: chat.send, chat.poll, cache.pushCapsule, dig.getPublicManifest) ends in _ => {} and does not name the reward method — confirmed by reading the block directly, not inferring from the comment.
• dig-rpc-protocol 0.11.0 method.rs::tier() (read from ~/.cargo/registry/src/.../dig-rpc-protocol-0.11.0/src/method.rs:184-228) is an exhaustive match with no wildcard arm over Method's variants — GetRewardProverStatus sits in the Tier::Control arm alongside the other three reward methods. Because the match has no _, a fifth reward-named variant added later without an explicit tier arm fails to compile, and if given the wrong tier deliberately, reward_methods_tier_guard.rs::every_reward_method_is_tier_control catches it at the crate's own enumeration (Method::ALL), independent of naming. Answer to the brief's fifth-method question: yes, it would be caught — at compile time if omitted, at test time if mistiered.
• method.rs::is_peer_reachable() (lines 239-253) is likewise a closed matches! allowlist (12 named methods, none reward-named); adding a reward method there is impossible without editing this function, which the ecosystem does not control (crates.io pin).
• peer.rs:1353-1382 (is_peer_reachable_method, node-local wrapper): read in full. The two pre-existing local special-cases (dig.getProviderSnapshot, dig.resolveCapsule) and the conditional one (cache.pushCapsule) are unchanged by this diff; the reward method is not named anywhere in this function, so it falls through to dig_rpc_protocol::Method::from_name(method).is_some_and(|m| m.is_peer_reachable()) -> false. The diff adds only the test (peer.rs:5636+), confirmed by diff — no allowlist line was touched.
• peer.rs:1519-1525 — the actual inbound-peer gate (NodeResponder's JSON-RPC entry) calls is_peer_reachable_method(method) and returns -32601 before any call reaches dispatch/handle_rpc. This gate is untouched by the PR; the new tests prove the reward method fails it.
• Verdict on item 1: no live path exists for a peer to reach dig.getRewardProverStatus. CLEAR.

2. Subject-attribution — CLEAR

reward_prover_status_to_wire (dispatch.rs:152-196) passes reserve_base_units/total_paid_out_base_units through unmodified and unaggregated, one call per registered StatusHandle, no cross-record fold anywhere in dispatch.rs or rewards/*.rs (grepped for sum(/fold(/+= near the handler — the only sum() hit in the crate is an unrelated challenge byte-length total in challenge.rs:131). The added test get_reward_prover_status_attributes_payout_figures_to_their_own_distributor (lib.rs) uses two distributors with deliberately non-additive, distinguishable totals (999,000 and 7) and asserts neither the sum nor a swap appears — a stronger proof than a same-value fixture would give. CLEAR.

3. All-zero launcher_id/store_id/root — LIVE FINDING, CHANGES-REQUIRED

dispatch.rs, the new Method::GetRewardProverStatus arm:

.filter(|s| s.launcher_id != [0u8; 32])

This filters only launcher_id. RewardProverStatus (rewards/state.rs:50-53) has three independently-uninitializable [u8; 32] fields — launcher_id, store_id, root — and nothing in state.rs, StatusHandle::new, or the dispatch filter checks store_id/root.

Concrete exploit / defect scenario: once #3265 lands and registers a real StatusHandle per distributor, any bug in that registration path (e.g. the manager identifies the distributor before it has resolved the store's current root, or before a store binding is confirmed) that leaves store_id or root at [0; 32] while launcher_id is already the real, non-zero distributor id will sail through this filter untouched. The RPC caller (an operator's own tooling, or a future dig-app pane per the brief's dig-app#403 precedent) receives a dig.getRewardProverStatus record with a plausible non-zero launcher_id and a store_id/root of "0000...0000" — 64 hex characters, indistinguishable in shape from a real id to any consumer that doesn't specifically check for the all-zero pattern (the brief states shipped dig-app 15.5.0 does not). That reads as "this distributor is bound to store 0000...0000" — a fabricated-looking but not obviously-wrong binding — rather than surfacing the uninitialised-registration bug it actually is.

This is the same shape the brief names from the dig-rewards-coin driver's adversarial history (a zero manager_singleton_launcher_id accepted unchecked), just on a sibling field the PR's own fix didn't cover. The PR's remedy (omission) is also the wrong shape here even where it's complete: silently dropping a record whose launcher_id is zero destroys the evidence that a registration went wrong. If a real prover loop ever registers a zero-anything record, the operator gets {"statuses": []} or a shortened list with no signal that something is wrong — the exact "reads fine and costs money" pattern (here, "reads as if that distributor doesn't exist" rather than "reads as a healthy default").

Recommendation: validate store_id, root alongside launcher_id (a record with any required id field at [0; 32] is not a valid distributor status), and prefer refusing/flagging over silent omission — e.g. surface a distinguishable prover_state or log/metric on filtering, so a zero-anything registration is visible to whoever owns #3265's registration path rather than swallowed. Silent omission is also inconsistent with SPEC §2.4's stated honesty stance the rest of this PR takes seriously (no field a stalled/buggy writer can quietly make look fine).

4. Section 2.4 honesty (no health boolean / no precomputed staleness) — CLEAR

rewards/state.rs:50-68 (RewardProverStatus) carries no alive/healthy/ok/up/running/staleness field; observed_at is the only timestamp signal, and is_wedged (cycle.rs:110-113) is explicitly reader-side, comparing the reader's own clock. The added test get_reward_prover_status_answers_a_real_request_with_real_values (lib.rs) asserts this on the serialized JSON key set (BTreeSet<&str> from s.as_object().keys()), banning alive/healthy/ok/up/running/stale/seconds_since_last_run by key membership, not contains() substring — correctly immune to the superstring false-pass this class of check is normally vulnerable to. CLEAR.

5. Registry reachability / lifecycle — CLEAR

register_reward_prover_status (lib.rs, new) is pub(crate), #[cfg_attr(not(test), allow(dead_code))], and has no call site in this diff outside #[cfg(test)] modules — confirmed by grep; no RPC method, FFI export, or peer frame handler calls it. Nothing untrusted (a peer, a remote RPC caller) can reach it; only an in-crate production caller landing in #3265 will be able to, and that is out of scope here as stated. The read path (reward_prover_status_snapshots, lib.rs) takes a std::sync::RwLock::read() and immediately .iter().map(..).collect()s synchronously with no .await inside the locked scope — no lock is held across an await point, so no caller can stall the node by holding this read. CLEAR.

6. EligiblePayoutHash staleness — CLEAR, confirmed independently

Grepped rewards/{state,mod,port}.rs, lib.rs, and seams/dig_rpc/dispatch.rs for Eligible|verdict|payout_hash|PayoutHash (case-sensitive substrings) across the full PR diff and the current tree at this SHA: zero matches. This handler surfaces no verdict type and cannot leak a stale payout-eligibility judgment. Confirmed: no such path exists.

Other notes (not gating)

• tests/dependency_tree.rs's updated doc comment describes the 0.11 resolution as "known-red... stays red until... a separate, already-dispatched lane [republishes]" — but this same PR's Cargo.toml/Cargo.lock diff already bumps dig-peer to 0.14.0 and dig-download to 0.23.0, i.e., the cascade this comment says is still pending is bundled in this very PR. Stale doc text, not a security defect — flagging for the correctness gate / follow-up tweak, not gating here.
• Dependency bumps' own correctness (dig-peer/dig-download/dig-peer-selector) are out of scope per the brief; not independently re-audited here beyond confirming the resolved dig-rpc-protocol tier/reachability tables above.
• I did not re-derive or re-audit rewards/** internals beyond the two structs (RewardProverStatus, StatusHandle) and the one call site (cycle.rs:121, confirmed #[cfg(test)]-only, not production) this handler's diff touches.

Note on tooling

Two WebFetch calls against docs.rs pages for dig-rpc-protocol 0.11.0 each returned content containing an embedded prompt-injection fragment (garbled directive-like text appended after the legitimate source). Both were identified and ignored; findings above were re-verified by reading the actual crate source directly from the local cargo registry cache (~/.cargo/registry/src/.../dig-rpc-protocol-0.11.0/src/method.rs, types.rs) rather than trusted from the fetched pages.

Verdict: CHANGES-REQUIRED

One live finding (item 3: all-zero store_id/root unfiltered, and omission-as-remedy swallows evidence of a bad registration). Every other numbered item in the brief is CLEAR with file:line evidence above. No peer-reachable path to any *Reward* method exists.

[MichaelTaylor3d]

Verdict: PASS

Head SHA 6be80c978c208d0ee1d54bea9b33552ed0af3797 (confirmed unmoved throughout review).

CI final state (all green)

Analyze (actions), Analyze (javascript-typescript), Analyze (rust), Clippy, CodeQL, Lint commit messages, Release-script tests, Rustfmt, build .deb (linux-amd64), build .deb (linux-arm64), build .msi (windows-x64), build .pkg (macos-universal), Test + coverage — all pass. Coverage TOTAL 89.99% lines (gated >=80%). Test + coverage ran 3293 tests, 3293 passed (4 skipped), including all 7 named reward tests plus the 3 reward_methods_tier_guard tests and the peer::tests::reward_methods_are_absent_from_the_node_peer_allowlist test — verified from the job's own nextest log, not asserted from the green checkmark alone.

The six items

1. No health boolean / staleness (SPEC §2.4). Confirmed. get_reward_prover_status_answers_a_real_request_with_real_values asserts on the serialized JSON's key set (BTreeSet<&str> from s.as_object().keys()), checking absence of alive/healthy/ok/up/running/stale/seconds_since_last_run — not a substring check, so it isn't satisfiable by an unrelated superstring. dig-rpc-protocol 0.11.0's RewardProverStatus/ProverCounters carry no such field either.

2. Money-figure subject. Confirmed. reward_prover_status_to_wire's doc comment states explicitly: this distributor's own reserve, the total this distributor has paid out to ALL of its mirrors combined, neither being the querying node's own earnings, referencing the dig-app#403 250x overstatement by name. get_reward_prover_status_attributes_payout_figures_to_their_own_distributor registers two distributors with distinguishable totals (999,000 vs 7), asserts each stays under its own launcher_id, and explicitly asserts against the summed (999,007) and swapped values. This genuinely pins the property, not just the wire round-trip.

3. Wire casing / widening. Confirmed against the shipped 0.11.0 source: RewardProverStatus/ProverCounters/GetRewardProverStatusResult carry no rename_all; only ProverState has #[serde(rename_all = "camelCase")] (types.rs:1464). The internal rewards::state::RewardProverStatus IS #[serde(rename_all = "camelCase")] (state.rs:49), so reward_prover_status_to_wire constructing the wire struct field-by-field (never serializing the internal type) is load-bearing, not stylistic. entry_count is internal u32 (state.rs:41) widened via u64::from(...) explicitly; the test sets 3_000_000_000 (> u32::MAX/2, so a truncating re-narrowing would visibly fail) and asserts json!(3_000_000_000u64).

4. Real read, not a shortcut. Confirmed. reward_prover_status_snapshots() reads self.reward_prover_statuses (an Arc<RwLock<Vec<StatusHandle>>> field on Node) and the dispatch arm calls it — never a literal vec![]. register_reward_prover_status is #[cfg_attr(not(test), allow(dead_code))] today (no #3265 caller yet), exactly as described.

5. All-zero launcher_id omission. The .filter(|s| s.launcher_id != [0u8; 32]) is defensible as implemented — the internal record type gives no way today to distinguish "never assigned" from a filled slot, and a real launcher_id is a singleton coin ID (probability of a genuine zero is negligible), so surfacing it would misrepresent a code bug as a real distributor with a spendable-looking 64-hex ID, which is a worse failure mode for a money-adjacent read than silence. That said: omission with only a source comment and no tracing::warn! means the one condition this filter exists to catch — a registration bug — currently produces zero observable signal anywhere, which sits close to the "silent cap on a globally writable set" pattern this codebase has been burned by before. Since register_reward_prover_status has no production caller yet, this is not a merge blocker, but a log line (or metric) alongside #3265's registration call site would close the gap so an operator or on-call sees it the day this can actually happen. Non-blocking suggestion, not a defect in this diff.

6. Tier::Control routing via the enum, not the string pre-match. Confirmed by reading dispatch.rs's pre-Method::from_name string match (lines ~232-275): it only special-cases chat.send, chat.poll, cache.pushCapsule, and dig.getPublicManifest — dig.getRewardProverStatus is absent from it, so it can only be reached through the enum match. get_reward_prover_status_is_served_via_the_method_enum_not_the_string_prematch asserts Method::from_name(...) == Some(Method::GetRewardProverStatus) and .tier() == Tier::Control, which is a real (if indirect) proof given the pre-match's absence — a reviewer has to read the pre-match block itself to know the test's premise holds, which this review did.

Also checked

• #3261 guards non-vacuous: reward_methods_are_absent_from_the_node_peer_allowlist (peer.rs) asserts Method::ALL contains at least one Reward-named method before checking allowlist absence; reward_methods_tier_guard.rs's reward_methods_exist_and_are_found_by_the_prefix_scan does the same. Neither is weakened from what the PR diff shows created fresh.
• dependency_tree.rs: the_workspace_carries_exactly_one_module_wire_crate asserts versions[0].starts_with("0.11.") — exact line, not a range/set (matches the #836/#1576 rule). However, the doc comment added above it says the test "stays red until the dig-peer 0.14.0 / dig-download 0.23.0 cascade... republishes" — this is stale/wrong as merged: the same PR's Cargo.toml diffs bump dig-node-core's own dig-peer to 0.14 and dig-download to 0.23, Cargo.lock resolves exactly one dig-rpc-protocol (0.11.0) and one dig-peer (0.14.0), and CI's Test + coverage job shows this exact test PASSING (( 1224/3293) dig-node-core::dependency_tree the_workspace_carries_exactly_one_module_wire_crate PASS). The "known-red" paragraph describes a pre-bump intermediate state that never shipped in this diff. Non-blocking (comment-only, doesn't affect behavior or the assertion's correctness) but worth a follow-up doc fix so a future reader doesn't chase a redness that isn't there.
• Dependency cascade / Cargo.lock: confirmed exactly one dig-rpc-protocol (0.11.0) and one dig-peer (0.14.0) resolve workspace-wide.
• Real entry point: handle_rpc -> handle_rpc_as -> RpcDispatch::dispatch confirmed as the actual delegation chain in lib.rs (not a helper beside it); the trait doc states dig-node-service/dig-runtime/the peer-RPC server all go through the free-function entry points, which thinly delegate to the same trait method the new arm lives in.
• Out-of-scope reward methods: ListRewardDistributors, GetRewardDistributor, ListRewardDistributorCommitments have no arm anywhere in dispatch.rs — they fall through to the _ => -32601 method not found default. No stub, todo!(), or empty-list arm to flag.
• dig-rewards-coin SPEC.md 0.1.3 §2.3/§2.4 cross-checked against the wire types and doc comments above; consistent on the closed nine-state set, the no-health-boolean rule, and the distributor-not-operator attribution of the payout figures.

Findings

No blocking findings. One non-blocking note (item 5, logging suggestion) and one non-blocking doc-accuracy note (dependency_tree.rs's stale "known-red" comment) — both left as PR-body prose per this review's own read, not inline threads, since neither is a defect in the shipped behavior or test correctness and there is nothing to drive to zero.

🤖 Generated with Claude Code

[MichaelTaylor3d]

Adversarial leg (loop-decider) — re-judgement of my MERGE-WITH-CONDITIONS (dig_ecosystem#3269)

Head audited: 3a9538bd982776c86ba4291165471dc7bf2529b5. Read: the 6be80c97..3a9538bd diff (dispatch.rs, lib.rs test, tests/dependency_tree.rs), the new handler body at dispatch.rs:767-806, capture_sync_logs at lib.rs:7725.

Verdict: MERGE-WITH-CONDITIONS (one mechanical condition, then MERGE)

Condition A — satisfied in substance, and I accept the override. My objection was that the filter turned a hypothetical registration defect into silence (§2.4 cl.1) and edited the §2.6 record set where nobody could see it. At 3a9538bd the drop is preceded by a tracing::warn! that names the zeroed field(s) and all three hex ids, and the test asserts one warning per bad record plus selectivity over a valid record. The silence is gone. The store_id/root gap security named was real and my remedy (delete) would have left it open once #3265 registers a writer; the L1's pick dominates mine. I do not hold that a logging handler-side guard is wrong per se — a guard here is a detector of a writer bug, and with #3274 now a hard blocker on #3265 the writer-side guard is committed, so this one is a documented, relocatable stopgap rather than the design. No two-leg disagreement to carry upward.

Did non-silence introduce a worse problem? Log volume: the warn fires on every dig.getRewardProverStatus call for every zeroed record, so a persistently bad registration under a polling UI produces one warn per poll for as long as the bug lives. I judge this acceptable and not worse than silence: it is proportional to the defect, warn-level is the operator channel journald/stdout already rate-limit, and dedup state (warn-once-per-record) would be machinery for a writer that does not exist. Surfacing it in the response is the wrong channel — the wire struct is fixed at dig-rpc-protocol 0.11.0 and a UI cannot act on it. Revisit only if #3265's writer can produce a zeroed record on a non-bug path (it must not; that is #3274's job).

Condition B — met (#3265 comment linking #3274 as hard blocker).

The one remaining condition (before merge; haiku tweak)

crates/dig-node-core/src/seams/dig_rpc/dispatch.rs:156 — the new zeroed_identity_fields doc comment says the zero id reads as valid to "every consumer including shipped dig-app 15.5.0". There is no dig-app 15.5.0 (latest tag v15.4.0; dig-app#403 is open). This is the exact false urgency premise the L1 already retracted, now written into source in the same commit that documents the guard. Replace with "…including the dig-app consumer in dig-app#403 (unmerged)". Check: grep -n '15\.5' dispatch.rs returns nothing. Then MERGE on green CI (Test + coverage, Clippy, Analyze (rust) were still pending at the time of this read).

Non-blocking, carried forward

A malformed or 0x-prefixed launcher_id param at dispatch.rs:769-772 can never match and returns {"statuses": []}, which a caller reads as "not distributing" rather than "you sent garbage". Does not block: the only consumer is unmerged, the surface is loopback control, and the fix (validate 64-hex, return -32602) is a wire-contract question to settle alongside #3265. File it as a follow-up ticket linked to #3265; do not fold it into this PR.

Unchanged from 6be80c97

Tier::Control, withdrawal_share_bps echoed not recomputed, base units, dependency_tree.rs exact-one/0.11 (the Known-red comment correction is accurate as of the cascade landing). rewards/** untouched.

[MichaelTaylor3d]

Security gate: PASS

Head audited: 134864a9d2dd3b73e89efd13aac3b17308f005ad

Scope: 6be80c97..134864a9 — 3 files (crates/dig-node-core/src/lib.rs, tests-only; crates/dig-node-core/src/seams/dig_rpc/dispatch.rs; crates/dig-node-core/tests/dependency_tree.rs), read from git objects. Re-audit of the prior round's single finding plus a disturbance check on the areas previously cleared.

1. Is the prior finding closed? — Yes

dispatch.rs:162-186 zeroed_identity_fields() checks all three identity fields (launcher_id, store_id, root) against [0u8; 32] and returns the names of those that are zero. The dispatch arm at dispatch.rs:786-798 calls it and emits tracing::warn! naming zeroed_fields plus all three hex ids before returning zeroed.is_empty() as the filter predicate. The drop is no longer silent and no longer launcher_id-only. Verified from code, not from the PR description.

2. Did the fix introduce a worse problem? — No; flag-then-exclude is accepted here

Polarity is not inverted. .filter(|s| ... zeroed.is_empty()) keeps a record when no field is zero. That is the intended sense, and the new test pins it from the outside: the fully-valid 0xaa… record is returned while both bad records are not. The "a condition's fix inverts the defect it closed" shape does not apply.

Who loses what. The excluded record is by construction one whose identity is unassigned — a caller (dig-app#403, unmerged) has nothing it can key on, render or attribute, so it loses no actionable information. The party who needs the evidence is the operator, and the operator now gets it at warn level with all three hex ids, which is enough to locate the bad registration. dig-rpc-protocol 0.11.0's GetRewardProverStatusResult (types.rs:1573-1576) carries only statuses: Vec<RewardProverStatus> — no total or count field — so exclusion cannot create a length-vs-declared-total mismatch, which is the honesty hole a silent filter usually opens. Flag-then-exclude is the right call at this boundary; the SPEC §2.4 clause-1 concern (the remedy destroying the evidence) is answered.

3. Is the log safe? — Yes; one defence-in-depth item

• Injection: clear. Every interpolated value is hex::encode(&[u8; 32]), i.e. [0-9a-f]{64} — no newline, no control byte, no field separator can be smuggled in. zeroed_fields is a Vec<&'static str> built from three source literals. The message is a static literal. There is no attacker-controlled path into the log line's structure.
• Sensitivity: clear. launcher_id, store_id and root are public on-chain identifiers, and Tier::Control is loopback / first-party and not peer-reachable, so this is strictly narrower exposure than the wire response already carries for a valid record.
• Volume — defence-in-depth, NOT gating. The warn fires once per bad record per request, with no dedupe and no rate limit. A caller looping dig.getRewardProverStatus against a registry holding N zeroed records writes N lines per call to the operator's disk. It requires local Control-tier access and is unreachable today (below), so it is not a live vulnerability. Recommend a ticket alongside #3265: dedupe per record identity, or fire once per registration at the writer rather than once per read.

The severity limiter for all of the above: git grep register_reward_prover_status at this SHA returns one definition (lib.rs:592, pub(crate)) and zero non-test callers — every call site is inside mod tests. reward_prover_status_snapshots (lib.rs:602) is likewise pub(crate). In production at this SHA the registry cannot be populated at all, so the warn cannot fire, the flood cannot be triggered, and no figure can be rendered. The guard is a forward-looking detector for #3265's writer, which is where its own doc comment says it belongs.

4. Does the new test prove what it claims? — Yes, on the strength of two of its three log assertions

capture_sync_logs (lib.rs:7678-7691) installs a real tracing_subscriber::fmt at Level::TRACE with with_ansi(false), so the assertions read the formatted event text including field values — a genuine capture, not a stub.

• Would fail if the warn were removed: yes. All three log assertions read logs, which would contain no such line.
• Would fail if the guard reverted to launcher_id-only: yes — case 2 (valid 0xcc… launcher, zeroed store_id) would survive the filter, making statuses.len() == 2 and failing the first assertion. This is a real regression test for the exact gap named, asserted above the decision (at the RPC response), not below it.
• Fire-count is real, not incidental: logs.matches("all-zero identity field").count() >= 2 over a fixture with exactly 2 bad and 1 good record. It cannot pass unless both warns fired.
• One weak conjunct (non-gating). assert!(logs.contains("all-zero identity field") && logs.contains("launcher_id"), …) — the contains("launcher_id") half is satisfied by the field key launcher_id=…, which is emitted on every warn regardless of which field was zero. It therefore does not prove that case 1's zeroed launcher_id was named as zeroed; this is the contains("HOME") passes on "XDG_DATA_HOME" shape. The proof is not lost — assertion 2 pins case 2 by its distinctive cccc… hex and assertion 3 pins the count — but the intended assertion is logs.contains("zeroed_fields=[\"launcher_id\"]") or equivalent. Worth tightening; not a gate.

5. Untouched invariants — all confirmed

The delta touches only the three files above, so peer.rs (both #3261 guards, the node-local wrapper at :1353, the -32601 pre-dispatch gate at :1519), is_peer_reachable_method, rewards/** and module_transport.rs are byte-identical to 6be80c97. Filtering the dependency_tree.rs diff to non-comment lines yields nothing — the change is comment-only, and the_workspace_carries_exactly_one_module_wire_crate still asserts versions.len() == 1 and versions[0].starts_with("0.11."), never widened to accept a set. The comment's new "cascade closed" claim is not a born-false doc claim: the test executed and passed in this run, which is the claim's own evidence.

The previously-cleared areas (peer reachability, §2.4 key-set honesty, registry lifecycle, subject attribution) were checked for disturbance rather than re-derived, per scope.

Thesis A — a number correctly typed and still false about whose money it is

get_reward_prover_status_attributes_payout_figures_to_their_own_distributor (lib.rs:9348-9400) is a genuine test of this class at this boundary: two distributors with deliberately asymmetric figures, each located by its own launcher_id, asserting each figure equals its own owner's value, plus explicit assert_ne! against the sum (999_007) and against a swap. It closes the mapping half — reward_prover_status_to_wire cannot sum, fold or cross-attribute without going red.

It does not close the producer half, and cannot from here. rewards/state.rs:43 declares pub total_paid_out_base_units: u64 with no doc comment defining whose payouts it counts — precisely the ambiguity that let the sibling repo render a funder-scoped total as one operator's earnings at up to 250x. Nothing at this SHA can populate it (zero non-test writers), so there is no live misstatement. The subject has to be established at #3265's writer, and that is where a gate must ask "whose money is this field about". Recommend it as an explicit acceptance item on #3265 rather than leaving it to the next reader of an undocumented u64.

Thesis B — EligiblePayoutHash

Checked: no. git grep -E "EligiblePayout|payout_hash" at this SHA over crates/ returns two hits, both unrelated test names (rewards/admission.rs:225, rewards/writes.rs:500); the type EligiblePayoutHash appears nowhere. git grep -i eligible over rewards/{state,mod,port}.rs returns nothing. No eligibility verdict is minted, persisted or re-read across a restart on any path this PR touches, so the "a persisted type re-asserts a verdict it cannot re-earn" concern has no subject here.

CI evidence (executed, not the checkmark)

Test + coverage, job 102656148850, log read directly:

Summary [551.153s] 3293 tests run: 3293 passed (3 slow), 4 skipped
TOTAL   151734   15181   89.99%

Identical to the 6be80c97 run, consistent with the delta renaming one test rather than adding one. Both reward tests are present in the executed set — get_reward_prover_status_logs_and_excludes_a_zeroed_identity_field and get_reward_prover_status_attributes_payout_figures_to_their_own_distributor — and the_workspace_carries_exactly_one_module_wire_crate also executed. Check set: 13 green, 0 failing, 0 pending, 1 skipping (Attach packages to the release).

Non-gating findings

1. dispatch.rs:146-161 — doc comment misattribution. The new /// block for zeroed_identity_fields was inserted immediately after the existing block for reward_prover_status_to_wire with no blank line between them, so the two merge into one contiguous doc comment attached to zeroed_identity_fields, and reward_prover_status_to_wire (:177) is left with none. The orphaned text still reads "every non-identical field below is called out rather than assumed" — now attached to a function that maps no fields, while the function that actually performs the money-shaped wire mapping, and whose 24x-fee-ceiling / 2x-eviction-count history that sentence exists to warn about, is undocumented. Fix: one blank line before /// Names which of a reward-prover status record's identity fields.
2. lib.rs:9258-9261 — weak assertion conjunct. See item 4.
3. Log-volume dedupe and the total_paid_out_base_units subject definition — both belong on #3265; see item 3 and Thesis A.

Not covered

The producer side of the registry (#3265, unlanded), the dig-app consumer (dig-app#403, unmerged), and anything outside the three files in this delta. Areas cleared in the prior round were checked for disturbance only, not re-derived.

No shared checkout was mutated: this audit read exclusively from git objects (git show / git grep <sha>) plus the local cargo registry cache for dig-rpc-protocol 0.11.0. docs.rs was not fetched — a prior instance recorded prompt-injection fragments embedded in those pages.

[MichaelTaylor3d]

CHANGES-REQUIRED — correctness re-check of 6be80c97..134864a9

Head reviewed: 134864a9d2dd3b73e89efd13aac3b17308f005ad. This is a delta-only re-check; the prior PASS on 6be80c97 stands and was not re-derived (wire mapping field-by-field, entry_count widening, the real registry read, the Method::from_name routing, the §2.4 no-health-boolean key-set assertion, the per-distributor attribution test).

Two blocking findings, both one-edit fixes. The behaviour of the new guard is correct; what fails is (a) a doc comment that is false of the item it attaches to, and (b) an assertion that cannot fail under the defect it claims to catch.

Blocking

1. crates/dig-node-core/src/seams/dig_rpc/dispatch.rs:152 — the new helper's doc block is spliced onto the end of reward_prover_status_to_wire's doc block with no blank line, so lines 146-161 are one comment attached to zeroed_identity_fields (line 162). The wire-mapping paragraph now documents a boolean helper ("every non-identical field below is called out" points at nothing of the kind), and reward_prover_status_to_wire (line 176) is left undocumented — losing the exact rationale a prior gate cited as its evidence. Third born-false doc claim in this delta's own lineage, and rustdoc/clippy are silent on it.

2. crates/dig-node-core/src/lib.rs:9257 — logs.contains("launcher_id") is satisfied unconditionally, because the warn emits launcher_id = <hex> as a structured field on every fire. Delete zeroed_fields = ?zeroed from dispatch.rs:793 and this test stays green while the log stops naming which of three fields was zero — i.e. the one property this delta was pushed to add is untested. The fixture makes the real assertion exact (store_id: [0x22; 32], root: [0x33; 32], so case 1 → ["launcher_id"], case 2 → ["store_id"]).

Non-gating (posted and resolved by me)

3. dispatch.rs:170 — root == 0 is treated as proof of a bad registration, but root is an observed value, not an identity: a registered-but-not-yet-cycled prover plausibly has no root, and #3265's writer will most likely express that as a zeroed array. Unreachable today (nothing writes the registry outside tests); recorded as a constraint on #3265, where this guard is meant to move.
4. dispatch.rs:789 — the warn is inside the filter, so a persistent bad registration re-logs on every poll of a UI-polled endpoint rather than alarming once. §2.4's evidence requirement is met either way.

Answers to the five questions asked

1. Does the new test prove what it claims? Partly. It does prove the widened guard: with a launcher_id-only filter the zeroed-store_id record is returned and statuses.len() == 1 fails — the gap nothing previously covered is now genuinely closed. It does prove the drop is not silent: logs.contains("all-zero identity field") is a distinctive phrase from the warn message with no superstring hazard (the doc comments are not in the log stream), so removing the tracing::warn! reddens it; capture_sync_logs (lib.rs:7725) installs a real TRACE-level subscriber over the awaited future, so the capture is genuine, not a stub. The fire-count assertion is real — the closure runs once per record, two bad records, count() >= 2 (== 2 would be tighter and would also catch a double-log; not gating). What it does not prove is the field-naming, per finding 2.

2. Is the guard correct and selective? Yes. All three identity fields are checked (dispatch.rs:164/167/170); the predicate is zeroed.is_empty(), so a record with all-valid ids is unaffected and passes through to the existing filter_launcher_id arm unchanged; no record with any zeroed field reaches reward_prover_status_to_wire. The test's fully-valid 0xaa… record proves selectivity rather than an empty registry. No stub, no todo!(), no unimplemented!() anywhere in the delta; the other three reward methods still have no arm and still fall through to -32601.

3. Did the delta disturb anything the prior pass covered? No. git diff --name-only 6be80c97..134864a9 is exactly three files: lib.rs, dispatch.rs, tests/dependency_tree.rs. is_peer_reachable_method does not appear anywhere in the delta (zero matches) and is unwidened. The two #3261 guards and the §2.4 key-set assertion are untouched — the lib.rs delta is confined to the single replaced test. rewards/** and module_transport.rs are untouched. In dependency_tree.rs only the doc comment changed; the asserts in the_workspace_carries_exactly_one_module_wire_crate are byte-identical, still exactly-one/0.11, never widened to a set.

4. Are both corrected comments true as merged?

• dependency_tree.rs "Cascade closed (#3269)": true. Cargo.lock at this SHA contains exactly one dig-rpc-protocol entry, 0.11.0, and the three versions the comment names are the ones locked — dig-peer 0.14.0, dig-download 0.23.0, dig-peer-selector 0.12.0. The test is green in this run, so the assertion is no longer known-red, as the old text claimed.
• dispatch.rs dig-app reference: true. dig-app#403 is OPEN, mergedAt: null; dig-app's latest release is v15.4.0 and no v15.5.0 exists. Sweep of crates/ + tests/ for 15\.5|shipped dig-app at this SHA returns one hit only — crates/dig-wallet/src/ui.html:187, a CSS font-size:15.5px, unrelated and outside this diff. No other occurrence survives.
• Caveat: the placement of the replacement text is finding 1 — the sentence is true of the wire mapping but is now attached to the helper.

5. Executed evidence at this SHA (CI run 34408143846, job Test + coverage 102656148850, log read — not the checkmark):

• Summary [551.153s] 3293 tests run: 3293 passed (3 slow), 4 skipped
• TOTAL … 89.99% lines (gate ≥80%), 86.94% branch/region, 90.64% functions
• Seven reward tests present and PASS, including the replacement: PASS [0.021s] (1085/3293) dig-node-core tests::get_reward_prover_status_logs_and_excludes_a_zeroed_identity_field and PASS [0.007s] (1084/3293) …_is_served_via_the_method_enum_not_the_string_prematch, alongside …_answers_a_real_request_with_real_values, …_attributes_payout_figures_to_their_own_distributor, …_filters_by_launcher_id_when_given, …_is_not_peer_reachable, …_with_no_registered_handle_is_explicit_empty. Test count is unchanged at 3293, consistent with a 1:1 replacement rather than a net addition.

What I did not run

No local build, test or coverage run — all executed evidence above is from the CI job log at this SHA. I did not re-verify the base PR (6be80c97 and earlier), the dependency bumps (separately gated), rewards/**, module_transport.rs, or dig-app#403's consumer code. I did not read docs.rs for dig-rpc-protocol 0.11.0; version facts come from Cargo.lock at this SHA.

[MichaelTaylor3d]

loop-security RE-VERDICT: CHANGES-REQUIRED

Head audited: 080be3df10ca3e5b73a16c68099243e21fb70014
Scope: 134864a9..080be3df (2 files, +109/-52): crates/dig-node-core/src/lib.rs, crates/dig-node-core/src/seams/dig_rpc/dispatch.rs. Read-only, read from git objects; no checkout mutated.

Supersedes the prior PASS at 134864a9.

Finding 1 (LIVE for the property the prior PASS was conditioned on) — the warn no longer names WHICH field was zero

crates/dig-node-core/src/seams/dig_rpc/dispatch.rs:812-818

The delta removed the zeroed_fields = ?zeroed structured field from the tracing::warn! while keeping the detection. Exact greps on the head blob: zeroed_fields = ?zeroed occurs 0 times in dispatch.rs; the 4 surviving zeroed_fields occurrences are the fn definition (:163), two doc references (:177, :792) and the local binding (:809). No tracing field, in any macro, carries it.

The message literal was simultaneously changed from "has an all-zero identity field; excluding it" to "has an all-zero field; excluding it if the zeroed field is an identity field". So the emitted line is now byte-identical for all three cases and states a conditional it does not resolve. An operator reading it cannot tell:

• a healthy, never-cycled prover (zeroed root only — returned), from
• a registration bug that zeroed store_id beside a real launcher_id (excluded), from
• a fully-unassigned slot (excluded).

To distinguish them the operator must hand-decode three 64-hex fields per line and compare against 64 zeros. That is precisely the §2.4-clause-1 property the first version of this filter violated and that the prior PASS was granted because the warn resolved: "a tracing::warn! fires naming which field(s) were zero". After the narrowing, exclusion is no longer silent but it is now unattributed, and the narrowing is what makes that fatal — before, every warned record was dropped, so one bit sufficed; now the same line means two opposite outcomes.

The delta's own doc block still promises the removed behaviour: dispatch.rs:155-157 ("the same detection drives both the exclusion decision ... and the tracing::warn!"), and lib.rs:9192-9195 ("a tracing::warn! fires naming the SPECIFIC zeroed field(s)"). Both are false at this SHA.

Fix: restore zeroed_fields = ?zeroed to the warn, and make the message state the outcome that actually occurred (two branches, or an excluded = %is_missing_identity(&zeroed) field). One line.

Finding 2 (LIVE, blocks CI) — the new test asserts on a string the log can no longer contain

crates/dig-node-core/src/lib.rs:9287, :9291, :9295 assert, respectively, that the captured logs contain the literals zeroed_fields=["launcher_id"], zeroed_fields=["store_id"] and zeroed_fields=["root"].

tracing's fmt layer emits only the fields passed to the macro. zeroed_fields is not one of them (Finding 1), so all three assertions are unconditionally false and get_reward_prover_status_logs_and_excludes_a_zeroed_identity_field cannot pass at this SHA. The replacement of the tautological logs.contains("launcher_id") was the right correction; it landed against a log line that no longer emits the value.

Note the fourth assertion (logs.matches("all-zero field").count() == 3) does match the new message, so the test fails on the field assertions only — the failure names a missing log field, which is the honest signal.

CI evidence — no executed count exists at this head

Per the brief I read the job, not the checkmark. At 080be3df the CI run (34425335592) was cancelled: Rustfmt success, Clippy success, Test + coverage cancelled, Release-script tests success. There is therefore no reward-test pass count and no coverage figure at this SHA; the expected 3294 is unverified. The only counts on record (3293 passed, 89.99%) belong to 134864a9, which does not contain these assertions. A re-run is pending (34425540451, Analyze jobs only so far). I predict Test + coverage fails on the three assertions above.

---

Answers to the five questions

1. Does narrowing the exclusion set reopen the original finding? Partly — and the wire already carries the honest marker.

A returned record with real launcher_id, real store_id and all-zero root is not a money-honesty hole on its own, and I can ground that in the wire rather than in preference. dig-rpc-protocol 0.11.0 types::RewardProverStatus (registry source, src/types.rs:1529-1551) declares root: HexId (non-optional) but also last_cycle_started_at: Option<u64>, last_cycle_completed_at: Option<u64>, last_entry_write_at: Option<u64>. A prover that has never cycled has last_cycle_completed_at: null, and reward_prover_status_to_wire copies all three through unchanged in this delta. So the consumer can distinguish "no root observed yet" from "a real root that happens to be zero-valued" — root == 64 zeros && last_cycle_completed_at == null is the honest reading, and a real store root being exactly 32 zero bytes is not reachable.

The concrete consequence of the narrowing is therefore bounded: a consumer that renders root without consulting last_cycle_completed_at shows 64 zeros as a generation root. That is a display defect in the consumer (dig-app#403, unmerged), not an unattributable money record — the record names its distributor, and nothing about it is spent against. Your ordered narrowing is the right call: excluding the record would have made a healthy prover invisible, which is the strictly worse failure and is not recoverable by any consumer-side logic, whereas this one is.

The residual risk is a correlation risk and belongs on #3265, not here: if that writer zero-inits root and stamps last_cycle_completed_at: Some(...), the distinguishing signal collapses and the 64-zeros-as-a-root shape becomes genuinely unattributable. Defence-in-depth — file a ticket against #3265's writer: a zeroed root must imply last_cycle_completed_at == None. Do not gate this PR on it.

2. Is warn-only sufficient observability for the returned case? Yes for the wire, no for the log — and the wire is not the limitation you assumed.

The wire is not unable to express it. root itself cannot be marked absent (HexId, non-optional, fixed at 0.11.0 — so no per-field nullability without a protocol bump), but the correlated absence signal already exists and is already emitted (see answer 1). §2.4 needs no new vocabulary and no wire bump. "No wire can feed it" is not the answer here; the honest marker shipped in 0.11.0.

The insufficiency is in the log, and it is Finding 1: warn-only would be sufficient observability if the warn resolved which field and which outcome. It does not, at this SHA.

3. Log safety re-checked.

Injection-free: still holds, and is strictly stronger than before. Every interpolated value is hex::encode of a [u8; 32], whose codomain is [0-9a-f]{64} — no newline, no =, no quote, no control byte, so no forged field and no forged line. The message is a &'static str literal. Removing zeroed_fields = ?zeroed removed the only non-hex-valued field; that field was itself safe (a Vec<&'static str> of three literals), so the property was already sound and restoring it per Finding 1 does not weaken it.

Placement: the warn is still inside the .filter(|s| { ... }) closure (dispatch.rs:808-820) — i.e. once per registry record per dispatch, ahead of the filter_launcher_id narrowing, so a caller filtering to one launcher still pays the full-registry log cost.

Volume: the returned-but-warned case makes it materially worse. Before, a warned record was always a bug and always dropped, so steady-state warn volume was zero. Now a zeroed root is an expected, legitimate state for every registered-but-not-yet-cycled prover, and it warns on every poll. On a polled endpoint that is (uncycled provers) x (poll rate) warn lines, each ~220 bytes of message plus three 64-char hex fields — and each one indistinguishable from a genuine identity bug (Finding 1). The genuine signal gets buried in expected noise: classic alarm fatigue, plus a modest log-amplification / disk-cost asymmetry driven by a caller-controlled poll rate at Tier::Control.

Not gating, because of answer 5, but it is the reason Finding 1 must be fixed rather than deferred: the moment #3265 lands, the noise arrives with it. Recommend (defence-in-depth, ticketable): warn on identity-missing unconditionally; for a root-only zero either drop to debug! or rate-limit/dedupe per launcher, so the returned-and-benign case does not compete with the excluded-and-broken case.

4. Untouched invariants — all confirmed.

git diff --name-only 134864a9..080be3df returns exactly the two named files, so dependency_tree.rs, rewards/** and module_transport.rs are untouched in this delta by construction. Within the two files: is_peer_reachable_method appears 0 times in the dispatch.rs diff — unwidened. The lib.rs hunks are confined to the one test's doc block and body (:9190-9305); both #3261 guards and the §2.4 key-set assertion are outside every hunk and unmodified, and remain non-vacuous. The dispatch.rs hunks are the doc reorganisation, the zeroed_identity_fields to zeroed_fields rename, the new is_missing_identity, and the filter closure. Nothing else.

Doc reorganisation confirmed correct: the wire-mapping doc block now sits immediately above fn reward_prover_status_to_wire (:181-186) instead of above zeroed_fields, which was the prior non-gating note.

5. Severity limiter — still holds.

git grep register_reward_prover_status 080be3df -- crates returns the pub(crate) definition at lib.rs:592, one doc reference at :576, and nine call sites, all inside mod tests (:9100, :9227, :9236, :9246, :9253, :9347, :9350, :9401, :9402). Zero non-test callers. The registry cannot be populated in production at this SHA, so no finding here is exploitable by a live caller today. Both findings are gated on correctness and on the observability contract this PR asserts in its own docs and test, not on a live exploit — Finding 2 additionally reds CI.

---

SPEC §12.5 clause 7 — your reading CONFIRMED from code

The response cannot express the forbidden "never admitted" vs "evicted after settlement" split. Grepping the body of reward_prover_status_to_wire (42 lines, dispatch.rs:187-228) for peer|mirror_id|entry_list|admitted|evicted returns zero lines. Cross-checked against the wire type in the local registry cache: types::RewardProverStatus (0.11.0, src/types.rs:1529+) carries no peer identity, no per-mirror entry list, and no admission/eviction discriminator. entries_added/entries_removed are per-distributor lifetime aggregates that attribute nothing to any peer, while the forbidden split is strictly per-peer — an aggregate cannot be inverted to a per-peer admission history. Absence of fields does not help a consumer either: there is no per-peer element whose presence or absence could be read as admitted-vs-evicted.

So the dig-app locale copy displaying that distinction is not fed by this wire. Not a defect in this PR; the copy defect stands on its own against whatever does feed it.

---

What I did not cover

The pre-existing 134864a9 surface (authz for Tier::Control, the full wire mapping's per-field correctness, dig-rewards-coin internals) — covered by the prior PASS and unchanged here. I did not execute the test suite: no shared checkout was mutated and no build was run, so Finding 2 rests on source analysis of tracing's field emission plus the cancelled-job record, not on a local red run. The pending re-run at this head will settle it. Per the brief, docs.rs was treated as untrusted and not fetched; the wire type was read from ~/.cargo/registry/src/index.crates.io-*/dig-rpc-protocol-0.11.0/src/types.rs.

Verdict

CHANGES-REQUIRED at 080be3df10ca3e5b73a16c68099243e21fb70014. Two changes, both small and both in dispatch.rs/lib.rs: restore zeroed_fields = ?zeroed to the warn and make the message resolve the outcome (Finding 1), which also makes the three new assertions pass (Finding 2). Re-run Test + coverage and report the executed reward-test count from the job log — no count exists at this SHA. The narrowing itself is sound and I do not ask for it to be reversed.

[MichaelTaylor3d]

Re-verdict — PASS at f657f2cb, and CHANGES-REQUIRED at the briefed head 080be3df

The head moved during this review. I was briefed to re-verdict 080be3df10ca3e5b73a16c68099243e21fb70014. I audited it, found the delta's central mechanism broken, and while I was running the proof the branch advanced to f657f2cb8d283799c84b006b3b4d4fccf68747b7 with a one-line fix for exactly that defect. Both verdicts are recorded here, because a green tick at f657f2cb alone would hide what 080be3df was.

080be3df — CHANGES-REQUIRED (executed proof, not inference)

The commit that fixed the two prior blocking findings dropped zeroed_fields = ?zeroed from the tracing::warn! while simultaneously rewriting the test to assert on that field's value. grep -rn zeroed_fields crates/ at 080be3df returns the three test assertions and no emitter. The result is the fifth born-false claim in this epic, in the commit that fixed the fourth: dispatch.rs:799 read "a tracing::warn! fires naming which field(s) were zero" over a warn that named nothing.

That is not a doc nit — the test was RED. Executed locally at 080be3df (cargo test -p dig-node-core --lib get_reward_prover_status):

test result: FAILED. 6 passed; 1 failed
panicked at crates/dig-node-core/src/lib.rs:9286:9:
expected a warning naming exactly launcher_id as zeroed, got: ... launcher_id=0000... store_id=2222... root=3333...

CI never showed this: the Test + coverage run for 080be3df (job 102709258821) was cancelled by the superseding push, so there was no green tick to be wrong — but there was also no evidence. This is the "a compile is not evidence" case in its sharpest form; the delta's one new property was unimplemented, and the only thing that would have caught it was the assertion the previous round demanded.

f657f2cb — PASS

git diff 080be3df f657f2cb is exactly + zeroed_fields = ?zeroed, at dispatch.rs:815. Re-run at that SHA: 7 passed, 0 failed.

Prior finding 1 (doc attached to the wrong item) — fixed, resolving the thread. dispatch.rs:146-162 now documents zeroed_fields (renamed from zeroed_identity_fields, correctly — it no longer names only identity fields); :177-180 documents the new is_missing_identity; and :186-191 carries the field-by-field wire-mapping rationale back above reward_prover_status_to_wire at :192, which is where it belongs and where it had no doc at all. Each block now sits above the item it describes.

Prior finding 2 (tautological log assertion) — fixed, resolving the thread. The assertions are now on the zeroed_fields=[...] value, and the fixture makes the three cases exact and disjoint (store_id: [0x22;32], root: [0x33;32]), so each case yields a single-element list. Verified by the nearest-wrong-implementation rather than by reading: deleting zeroed_fields = ?zeroed turns the test RED — that is not a thought experiment, it is literally what 080be3df was, with the panic quoted above. The count assertion also tightened from >= 2 to == 3, so a warn that fires twice for one record now fails too.

The third change (root as an observation, not an identity) — correct, and non-vacuous. All four parts are present: is_missing_identity covers launcher_id || store_id only (:181-183); the filter returns on !is_missing_identity(&zeroed) while still warning whenever !zeroed.is_empty() (:809-818); the rationale is stated at :802-807 and in both helper docs; and the fourth test case (launcher_id = [0xbb;32], store_id valid, root zeroed) asserts both that the record is returned and that zeroed_fields=["root"] appears. I probed the acceptance criterion by mutation in my own worktree — adding || zeroed.contains(&"root") to is_missing_identity:

assertion `left == right` failed: the fully-valid entry AND the zeroed-root-only entry are both returned
  left: 1
 right: 2

The security gate's want survives the split: a zeroed root still fires the warn and still names root in zeroed_fields, so all three fields remain observable — the record is now returned and logged rather than dropped and logged, which strictly increases what an operator can see. Your judgement to promote this above non-gating was right: under the old predicate a #3265 writer that zero-inits root would have made every registered-but-not-yet-cycled prover invisible, which is a worse failure than the one the guard was built for.

SPEC §12.5 clause 7 — your reading CONFIRMED from code

Clause 7 forbids distinguishing "never admitted" from "evicted after settlement" from an absent slot, and forbids building or displaying a heuristic that guesses. This wire cannot express the distinction, and the reason is structural rather than incidental: the split clause 7 protects is per-peer, and this response has no peer axis at all. reward_prover_status_to_wire (dispatch.rs:192-231) emits only the §2.3 per-distributor fields, and a grep of the mapping body for peer|mirror_id|entry_list|admitted|evicted returns zero — there is no peer identity, no per-mirror entry list, and no per-peer entry state on the wire, so no consumer has anything to key a guess on. entries_added / entries_removed / mirrors_seen are this distributor's lifetime aggregates: they say how many entry writes and removals happened in total, attributing none of them to any peer, and even entries_added - entries_removed against entry_count yields aggregate churn, never "this peer was never admitted" versus "this peer was evicted". The dig-app copy the sibling gate found in 14 locales is inventing the distinction downstream, not rendering one this wire handed it. No defect to fix here, and nothing to file against this wire.

Scope, and what I checked one by one

The 134864a9..f657f2cb delta touches only crates/dig-node-core/src/{lib.rs, seams/dig_rpc/dispatch.rs}, which settles most of the scope questions mechanically. is_peer_reachable_method is unwidened — peer.rs's only change across the whole PR is an added test that asserts every Reward-named method is absent from the local allowlist, and it guards its own vacuity by asserting the scan found at least one such method first. Both #3261 guards in tests/reward_methods_tier_guard.rs are untouched and non-vacuous the same way (reward_methods_exist_and_are_found_by_the_prefix_scan asserts the prefix scan is non-empty before the other two iterate it). dependency_tree.rs is unchanged in this delta; its the_workspace_carries_exactly_one_module_wire_crate still asserts versions.len() == 1 and versions[0].starts_with("0.11."), deliberately not widened to a set. rewards/** and module_transport.rs are untouched across the entire PR. No stub was added for the other three reward methods — dispatch.rs has exactly one Some(Method::GetRewardProverStatus) arm, so the rest still fall through to the catalogued -32601, which is what reward_methods_tier_guard and the peer-allowlist test pin from the other side.

Every comment in the delta is true as merged at f657f2cb. I read each one against the item it lands on: the dispatch.rs:799 claim that the warn names the zeroed fields is true again once zeroed_fields is emitted, and the zeroed_fields doc's promise that an operator benefits from seeing the field named is likewise satisfied.

Executed evidence at f657f2cb

From the Test + coverage job log (job 102709962014), not the checkmark:

Summary [932.425s] 3293 tests run: 3293 passed (17 slow), 4 skipped
TOTAL  151762  15178  90.00%   (lines; gated at >= 80%)

All seven reward tests PASS in that run — get_reward_prover_status_{answers_a_real_request_with_real_values, attributes_payout_figures_to_their_own_distributor, filters_by_launcher_id_when_given, is_not_peer_reachable, is_served_via_the_method_enum_not_the_string_prematch, logs_and_excludes_a_zeroed_identity_field, with_no_registered_handle_is_explicit_empty} (1080-1086/3293), plus peer::tests::reward_methods_are_absent_from_the_node_peer_allowlist (234/3293), the three reward_methods_tier_guard tests (1287-1289/3293) and dependency_tree::the_workspace_carries_exactly_one_module_wire_crate (1224/3293).

The count is 3293, not the 3294 predicted — correctly so, and worth stating rather than letting it read as a stale log: the root case is a fourth case inside an existing #[test], not a new test function, so the total is unchanged from 134864a9. Coverage moved 89.99% to 90.00%.

One non-gating note, recorded here rather than as a thread

For the root-only case the warn's message text reads "excluding it ... if the zeroed field is an identity field", which is conditional and therefore true, but it makes an operator read the zeroed_fields value to learn whether this particular record was actually dropped. That is acceptable as merged — the structured field disambiguates it — and it is not worth another round.

Verdict

PASS at f657f2cb8d283799c84b006b3b4d4fccf68747b7. Both prior blocking threads are resolved. This PR is still a draft; marking it ready is the orchestrator's call, not mine.

I did not run the .msi / .deb / .pkg packaging jobs (pending at review time and unrelated to this delta), did not audit rewards/**, module_transport.rs, the dependency bumps or dig-app#403, and did not exercise the endpoint against a live #3265 writer, which does not exist yet.

[MichaelTaylor3d]

Security gate (loop-security) — IN PROGRESS, not the verdict

Re-audit anchored at head 0ae5f30a74fdbc927a812c2512af6ece545998d4, not at the f657f2cb I was
briefed on. The head moved under the brief: 0ae5f30a ("split zeroed-field logging by level") is a
new commit that lands the warn!/debug! split. I am auditing the real head; the volume ruling I
was asked for is moot because the fix shipped.

Both prior findings are closed.

1. zeroed_fields = ?zeroed is present in both emitters
   (crates/dig-node-core/src/seams/dig_rpc/dispatch.rs:814-828) — the warn! for a missing
   identity field and the debug! for a zeroed root each carry it. Read from the blob at
   0ae5f30a, not from a description.
2. The assertions are satisfiable. capture_sync_logs
   (crates/dig-node-core/src/lib.rs:7725) installs the capture subscriber with
   .with_max_level(tracing::Level::TRACE), so the new debug! line reaches the buffer; and
   .with_ansi(false) means the rendered level token really is the bare string DEBUG /WARN
   the assertions match on.

Volume: the ordinary case is back to zero warn-level lines. Both emitters remain inside the
.filter(|s| …) closure on the reward_prover_status_snapshots() iterator, so the log fires
per-record per-request exactly as before — but a record whose only zeroed field is root now takes
the else if arm and emits at debug!. Steady-state warn! volume for the pre-first-cycle case is
zero. is_missing_identity gates both the level choice and the exclusion from one expression, so
the two can no longer disagree: the arm that warns is textually the arm that excludes
(!is_missing_identity(&zeroed) is the closure's return).

One new finding, defence-in-depth (not a gate).

crates/dig-node-core/src/lib.rs:9298-9303 — the level assertion is not anchored to the line it
is about:

logs.contains("DEBUG") && logs.contains(r#"zeroed_fields=["root"]"#)

logs is the whole captured buffer. The two conjuncts are independent: the first says some DEBUG
line exists anywhere in the buffer, the second says some line names root as the sole zeroed
field. Nothing ties them to the same line. Consider the mutation the doc says this test defends
against — flipping the root branch back to warn!:

• logs.contains(r#"zeroed_fields=["root"]"#) — still true (the field is still emitted).
• logs.matches("zeroed root").count() == 1 — still true; that message text is unchanged by a
  level flip, so it counts the same either way.
• logs.matches("missing an identity field").count() == 2 — still true; the identity branch's
  message is untouched.
• logs.contains("DEBUG") — the only level-sensitive conjunct, and it fails only if no other
  DEBUG line exists anywhere in the handle_rpc call under capture.

So the test goes red on that mutation only incidentally: dispatch.rs today contains exactly one
debug! (the new one) and no trace!, and the GetRewardProverStatus arm does little else. The
day anyone adds a debug! or trace! anywhere in the dispatch path — the tier check, the rate
limiter, the registry read — contains("DEBUG") becomes unconditionally true and the level half of
this test goes vacuous silently, while its doc block keeps claiming (entry 5) that it catches
"a fix that returns the zeroed-root record but logs it at the SAME level". At that point the level
split is undefended and the doc is the sixth born-false claim in this epic.

This is defence-in-depth, not a live vulnerability: the code at this SHA is correct, and
register_reward_prover_status still has zero non-test callers (pub(crate), ten references,
all inside mod tests — verified at this SHA), so the registry has no production writer and the
volume surface is zero until #3265 lands. Recommend a ticket, or a one-line strengthening: scan
logs.lines() and assert the single line containing zeroed_fields=["root"] starts with DEBUG
and no line containing it starts with WARN. I did not prove the mutation by execution — a
cold dig-node-core compile was outside this gate's budget — so treat "incidentally red today" as
a structural reading, not a measured one.

Doc truth at 0ae5f30a. Every touched comment checks out against the code beneath it, with the
one exception above:

• dispatch.rs:152-160 — the level-split claim on zeroed_fields' doc matches both arms.
• dispatch.rs:799-812 — now says the identity case warns and is excluded (the 080be3df
  version claimed the warn "names which field(s) were zero" over an emitter that named nothing;
  fixed at f657f2cb and still true here), and the root case is debug! with the record still
  returned. Both true.
• lib.rs:9201-9221 — the failure-mode list's new entry 5 is the one claim that overstates, per
  the finding above; entries 1-4 and 6 are accurate.
• lib.rs:9245 — "a DEBUG (never WARN) still fires naming root" is true of the code.

Returned zeroed-root record is not an honesty hole. The wire mapping
(dispatch.rs:196-230) passes prover_state, prover_state_since, last_cycle_started_at,
last_cycle_completed_at and observed_at through, so a consumer receiving root as 64 zeros has
independent fields telling it no cycle has completed. Returning the record does not force a
consumer to read an all-zero root as a real root.

Untouched invariants re-confirmed at this SHA. is_peer_reachable_method is unwidened — the
whole peer.rs delta against base d562aad8 is a test addition
(reward_methods_are_absent_from_the_node_peer_allowlist), no change to the function.
dependency_tree.rs is unchanged in the f657f2cb..0ae5f30a delta (which is exactly lib.rs +
dispatch.rs) and still carries versions.len() == 1 plus versions[0].starts_with("0.11."),
never widened to a set. rewards/** and module_transport.rs are untouched across the entire PR
(base..head touches 8 files: Cargo.lock, two Cargo.toml, lib.rs, peer.rs, dispatch.rs,
tests/dependency_tree.rs, tests/reward_methods_tier_guard.rs).

§12.5 clause 7 stays settled — the forbidden split is per-peer, the response has no peer axis.

Verdict follows once the Test + coverage job at 0ae5f30a reaches a terminal state. I will not
carry the 3293 passed count from f657f2cb forward; the level-split assertions are new here and
only an executed run at this SHA is evidence about them.

[MichaelTaylor3d]

Security gate (loop-security) — PASS

Head SHA audited: 0ae5f30a74fdbc927a812c2512af6ece545998d4

Not the f657f2cb8d283799c84b006b3b4d4fccf68747b7 in my brief — the head moved while I was being
briefed, and 0ae5f30a is the commit that lands the warn!/debug! level split. I re-anchored and
audited the real head; every statement below is read from blobs at 0ae5f30a. Detail is in my
in-progress comment above; this is the verdict.

Both prior findings closed. zeroed_fields = ?zeroed is present in both emitters
(crates/dig-node-core/src/seams/dig_rpc/dispatch.rs:814-828), and the assertions are satisfiable
because capture_sync_logs (crates/dig-node-core/src/lib.rs:7725) captures at
Level::TRACE with .with_ansi(false).

The volume ruling I was asked for is moot — the fix shipped. A record whose only zeroed field is
root now takes the else if arm at debug!, so steady-state warn! volume for the ordinary
pre-first-cycle case is zero rather than (uncycled provers) x (poll rate). is_missing_identity
drives the level choice, the exclusion, and the closure's return value from one expression, so the
arm that warns is textually the arm that excludes. Had the split not landed I would have ruled it
non-blocking and carried it to #3265 (no production writer, so no volume today) — but that is no
longer the question.

One finding, defence-in-depth, NOT gating. crates/dig-node-core/src/lib.rs:9298-9303 asserts
the level over the whole log buffer, unanchored to the line it is about:
logs.contains("DEBUG") && logs.contains(r#"zeroed_fields=["root"]"#). The conjuncts are
independent. Flipping the root branch back to warn! leaves the "zeroed root" count, the
"missing an identity field" count and the zeroed_fields=["root"] substring all satisfied; only
contains("DEBUG") can fail, and only because dispatch.rs happens to contain exactly one
debug! and no trace! today. Add a debug! anywhere in the dispatch path — tier check, rate
limiter, registry read — and the level half of this test goes vacuous silently while the doc block's
new failure-mode entry 5 keeps claiming it catches exactly that mutation. Fix is one line: scan
logs.lines(), assert the single line containing zeroed_fields=["root"] starts with DEBUG and
that no line containing it starts with WARN. I did not prove the mutation by execution (a cold
dig-node-core compile was outside this gate's budget), so "incidentally red today" is structural,
not measured. Recommend a ticket on #3265 alongside the other acceptance items.

Severity limiter holds: register_reward_prover_status is pub(crate) with zero non-test
callers at this SHA — ten references, all inside mod tests. The registry has no production
writer, so nothing above is reachable in a shipped node until #3265 lands.

Doc truth. Every touched comment is true against the code beneath it —
dispatch.rs:152-160, dispatch.rs:799-812 (the 080be3df born-false claim is gone and stayed
gone), lib.rs:9245 — with the single exception of failure-mode entry 5 at lib.rs:9201-9221,
which claims strength the assertion does not have. That is the finding above, not a separate one.

Returned zeroed-root record is not an honesty hole. The wire mapping (dispatch.rs:196-230)
passes prover_state, prover_state_since, last_cycle_started_at, last_cycle_completed_at and
observed_at through, so a consumer seeing root as 64 zeros has independent fields telling it no
cycle has completed.

Untouched invariants, re-confirmed at 0ae5f30a. is_peer_reachable_method unwidened — the
entire peer.rs delta against base d562aad8 is one added test. dependency_tree.rs unchanged in
the f657f2cb..0ae5f30a delta (which is exactly lib.rs + dispatch.rs) and still holds
versions.len() == 1 plus versions[0].starts_with("0.11."), never widened to a set. rewards/**
and module_transport.rs untouched across the whole PR (base..head = 8 files: Cargo.lock, two
Cargo.toml, lib.rs, peer.rs, dispatch.rs, tests/dependency_tree.rs,
tests/reward_methods_tier_guard.rs). §12.5 clause 7 stays settled.

CI evidence, executed at this SHA — run 34426912937, job 102713997021, not carried forward
from f657f2cb: Summary [926.029s] 3293 tests run: 3293 passed, coverage TOTAL 89.98% (line
90.63%, region 89.98%, function 86.94%). Named: (1085/3293)
get_reward_prover_status_logs_and_excludes_a_zeroed_identity_field PASS — the test carrying the new
level assertions; (234/3293) reward_methods_are_absent_from_the_node_peer_allowlist PASS;
(1224/3293) the_workspace_carries_exactly_one_module_wire_crate PASS. All 14 checks SUCCESS
including Clippy, Rustfmt, CodeQL and the three Analyze jobs.

Two discrepancies against my brief, both benign and both explained. (1) The total is 3293
here, the same as at f657f2cb, because 0ae5f30a added assertions inside the existing #[test]
rather than a new test fn — so a green count identical to the previous SHA's is expected, not
evidence the new assertions did not run; the per-test PASS line at (1085/3293) is that evidence.
(2) Coverage reads 89.98%, not the 90.00% in my brief; the job's own >=80% gate passes and the
delta is two hundredths on a different SHA.

Scope audited: f657f2cb..0ae5f30a in full (55/28 across lib.rs, dispatch.rs), plus
d562aad8..0ae5f30a for the untouched-invariant re-confirmation, all from git objects. Not
covered: execution of the level mutation probe; the Cargo.lock/Cargo.toml dependency delta
beyond the single-dig-rpc-protocol-line assertion, which earlier rounds covered. Shared
checkout: I read only from git objects in D:\worktrees\dig-node-595 and ran one git fetch
there; no checkout, branch or working tree was modified, nothing to restore.

Merge is not blocked by security. Carry the lib.rs:9298-9303 assertion strengthening as an
acceptance item on #3265.

[MichaelTaylor3d]

Re-verdict — PASS at 0ae5f30a74fdbc927a812c2512af6ece545998d4

Third head this PR has had under review (080be3df CHANGES-REQUIRED, f657f2cb PASS, now 0ae5f30a). The f657f2cb..0ae5f30a delta is 55 insertions / 28 deletions across crates/dig-node-core/src/{lib.rs, seams/dig_rpc/dispatch.rs} and it implements the log-level split. My PASS at f657f2cb did not carry over, and this one is re-derived from the code at this SHA.

1. The level split holds, and it is non-vacuous — proven by mutation, not inspection

The implementation at dispatch.rs:813-830 is a clean two-branch split on the same detection:

let zeroed = zeroed_fields(s);
if is_missing_identity(&zeroed) {
    tracing::warn!(..., zeroed_fields = ?zeroed, "... is missing an identity field; excluding it ...");
} else if !zeroed.is_empty() {
    tracing::debug!(..., zeroed_fields = ?zeroed, "... has a zeroed root; likely no cycle observed yet, returning it anyway");
}
!is_missing_identity(&zeroed)

Since root is the only non-identity member of zeroed_fields, the else if branch can only ever be reached with zeroed == ["root"], so the DEBUG line's message is true by construction rather than by coincidence. A record with both a zeroed launcher_id and a zeroed root takes the WARN branch once and carries zeroed_fields=["launcher_id","root"] — no double-logging, and the more serious level wins, which is the right precedence.

The level is genuinely asserted. I reverted the debug! to warn! in a scratch worktree, keeping the message identical (the nearest wrong implementation — the fix that "reverts the level and nothing else"), committed it, and ran the test:

test result: FAILED. 0 passed; 1 failed
panicked at crates/dig-node-core/src/lib.rs:9303:9:
expected a DEBUG line naming exactly root as zeroed, distinct from the WARN level used for a
missing identity field, even though the record is still returned:
  WARN ... is missing an identity field ... zeroed_fields=["launcher_id"]
  WARN ... is missing an identity field ... zeroed_fields=["store_id"]
  WARN ... has a zeroed root; likely no cycle observed yet, returning it anyway ... zeroed_fields=["root"]

So failure mode (5) — "returns the zeroed-root record but logs it at the SAME level" — is a claim the test actually enforces, not a claim about itself. Baseline at this SHA is 7/7 green, so the RED is attributable to the mutation.

Worth recording precisely which assertion caught it, because it is only one of them. logs.matches("missing an identity field").count() == 2 did not fire (the mutation left that message untouched), and neither did logs.matches("zeroed root").count() == 1. The entire level property rests on the logs.contains("DEBUG") conjunct in the third assertion. That conjunct is a real discriminator today — I confirmed from the captured output that the getRewardProverStatus dispatch under capture_sync_logs (a TRACE-level scoped subscriber, lib.rs:7723-7737) emits no other DEBUG or TRACE line, so "DEBUG" appears in the buffer only when this branch puts it there.

2. Doc truth at this SHA

Every touched claim read against the code beneath it, since this is the epic that has shipped a born-false doc claim in the commit fixing the previous one four times over:

• lib.rs:9204-9210 — "logged at DEBUG, never WARN, and never causes exclusion on its own; see the third case below". True, and the cross-reference is now right: the case is labelled // Case 3 at lib.rs:9245, where the previous revision said "fourth case" for the same case. That off-by-one was fixed here rather than propagated.
• lib.rs:9216-9218, failure mode (5) — true, and proven true by the mutation above rather than asserted.
• lib.rs:9219-9224, failure mode (6) — the old (5), renumbered and extended to "the zeroed_fields=[...] value AND the level". Accurate description of what the assertions now do.
• dispatch.rs:152-158 — the zeroed_fields doc now states the split and its reasoning, and its cross-reference changed from "reward_prover_status_to_wire's call site" to "the GetRewardProverStatus filter below". The second is the correct target and it is genuinely below (:163 vs :813); the first was subtly wrong, since the filter is not that function's call site. Another latent doc error fixed rather than carried.
• dispatch.rs:799-802 — "a tracing::warn! fires naming which field(s) were zero, making a bad registration observable, and the record is excluded". True on both halves.
• dispatch.rs:806-812 — "So this case is tracing::debug!, not warn! ... kept out of warn!-level volume". True.

The reworded WARN message also retires the one non-gating note I left at f657f2cb: it previously read "excluding it ... if the zeroed field is an identity field", which was conditional and made an operator read zeroed_fields to learn whether the record was actually dropped. It now reads "is missing an identity field; excluding it ... rather than presenting it as a real distributor", which is unconditional and true on the only branch that emits it.

One wording nit, not a defect and not worth a round. The dispatch.rs:812 sentence "The record is still returned either way" closes a paragraph about the root-only case, so "either way" reads naturally as "at either log level" — true. It can also be misread as "in both branches", which is false for the identity branch. The preceding paragraph says that record "is excluded" three lines up, so a reader is not actually left with the wrong belief. Flagging it only because this epic's failure mode is exactly a sentence that reads fine and is not true.

3. Nothing else disturbed

git diff --name-only f657f2cb 0ae5f30a is exactly the two files, which settles most of this mechanically. Checked individually anyway:

• is_peer_reachable_method unwidened — peer.rs is not in the delta; its only change across the whole PR remains the added test asserting every Reward-named method is absent from the local allowlist, vacuity-guarded by asserting the scan is non-empty first.
• Both #3261 guards untouched and still non-vacuous — tests/reward_methods_tier_guard.rs is not in the delta, and reward_methods_exist_and_are_found_by_the_prefix_scan still asserts the prefix scan found something before the other two iterate it.
• §2.4 key-set assertion untouched — it lives at lib.rs:9144-9163 and every delta hunk in that file starts at 9204 or later (git diff -U0 hunk headers: @@ -9204 @@, -9213, -9242, -9287, -9291, -9293, -9295, -9300). It still bans by KEY SET over {alive, healthy, ok, up, running, stale, seconds_since_last_run}, not by substring.
• dependency_tree.rs unchanged in the delta; the_workspace_carries_exactly_one_module_wire_crate still asserts versions.len() == 1 and versions[0].starts_with("0.11."), not widened to a set.
• rewards/** and module_transport.rs untouched across the entire PR.
• No stub for the other three reward methods — grep -n 'Some(Method::GetReward' returns exactly one arm, dispatch.rs:784, so the rest still fall through to the catalogued -32601.

4. Executed evidence at THIS SHA

Test + coverage finished after your last look. From job 102713997021's log, not the checkmark:

Summary [926.029s] 3293 tests run: 3293 passed (17 slow), 4 skipped
TOTAL  151777  15201  89.98%   (lines; gated at >= 80%)

3293 as you predicted — the level split changed assertions inside an existing #[test] and added no new test function, so the total is unchanged from f657f2cb. Coverage moved 90.00% -> 89.98% on 15 more countable lines, comfortably above the 80% gate.

All eleven reward-surface tests PASS in that run: the seven get_reward_prover_status_* (1080-1086/3293, including logs_and_excludes_a_zeroed_identity_field at 1085), peer::tests::reward_methods_are_absent_from_the_node_peer_allowlist (234/3293), the three reward_methods_tier_guard tests (1287-1289/3293), plus dependency_tree::the_workspace_carries_exactly_one_module_wire_crate (1224/3293). Locally at this SHA: 7 passed, 0 failed.

Every other required check is green at 0ae5f30a — Clippy, Rustfmt, CodeQL, all three Analyze jobs, Release-script tests, and all four packaging builds (.msi, both .deb, .pkg), which were pending at the previous head and have now completed successfully.

5. Threads

All four prior threads remain resolved; open count is 0. I have opened none this round — the level split is correct, non-vacuous and truthfully documented, and the two observations above (the single-conjunct level assertion, the "either way" wording) are robustness notes recorded here rather than defects to fix, so a thread would only cost a round.

Verdict

PASS at 0ae5f30a74fdbc927a812c2512af6ece545998d4. Zero open threads. Settled and not re-derived: SPEC §12.5 clause 7 (the forbidden split is per-peer and this response has no peer axis) and the exclusion-set narrowing itself.

The PR stays DRAFT; marking it ready and merging are the orchestrator's.

I did not re-audit rewards/**, module_transport.rs, the dependency bumps or dig-app#403, and did not exercise the endpoint against a live #3265 writer, which still does not exist.