Skip to content

audit(nc-12): 15 doc-comment-only NC-12 claims in seams/dig_peer — measure which are tested and which are merely asserted #356

Description

@MichaelTaylor3d

Task

Audit the 15 NC-12 claims in seams/dig_peer/ that exist only as doc comments, and determine for each
whether it is TESTED or merely ASSERTED.

Scoped by the review gate on dig-node PR #353 (dffb2645):

file claims
module_transport.rs 4
forwarded_ask.rs 3
module_reshare.rs 3
module_relay.rs 2
ask_routing.rs 1
holder_cache.rs 1
module_serve.rs 1

That is an upper bound, not a defect list — several in module_reshare sit next to real coverage. The
audit's job is to say which is which.

Why this is worth a lane

PR #353 closed one of these — module_relay's NC-1 exclusion, which gives a hop (store_id, root)
and never a retrieval key. The measurement that justified it:

A one-line mutation — let root_hex = params.get("retrieval_key")…unwrap_or(root_hex) — turns the
courier of opaque capsule bytes into one that can carry a recipient-addressed payload. 988
pre-existing tests stayed green, including the shipped relay gate test.
Only the new guard failed.

Independently reproduced by the gate, mutation asserted applied and asserted removed. So one
prose-only exclusion was one line from being violated with nothing noticing — and there are fourteen
more claims of the same kind sitting in the same directory.

The sharpest candidate, per the gate

forwarded_ask.rs:78 — a wire budget clamped from an UNTRUSTED peer.

That is exactly the shape where a rival implementation disagreeing on failure direction is already on
record
: dig-node coerced an unreadable hop budget to the most permissive value while dig-sex
refused. Start there.

What each verdict must say

For every claim: TESTED (cite the test), or ASSERTED-ONLY — and for the latter, what a
one-line mutation of the claimed property would do to the suite.
"No test covers it" is a weaker
statement than "here is the mutation that survives"; the second is what justifies a guard.

Do not write fifteen guards. Rank by what a violation would cost — a claim about what a hop cannot
see
(NC-1 confidentiality) or what an untrusted peer cannot steer (NC-12) outranks one about
ordering or performance. Write guards for the top of that ranking and report the rest with their
mutations, so the next lane starts from evidence.

Two fixture lessons from #353 — reuse them

wire_relay_hop (lib.rs:7260) is a genuinely good relay harness and was underused — one caller
before #353, two after. Start there rather than building parallel fixtures.

And beware the single-value false green. #353's fixture needed two different retrieval keys,
because with one value there is nothing for a threaded key to select differentlyignoring and
threading are indistinguishable. The inequality is assert_ne!d so a later edit cannot silently
collapse it, and the gate confirmed that assertion fires first, ahead of every other. Any guard here
that distinguishes "used X" from "ignored X" needs two distinguishable values and a pinned inequality.

Evidence

  • Every ASSERTED-ONLY verdict carries its surviving mutation, with the patch asserted applied and
    asserted removed
    afterwards (git status --porcelain empty before the restored run).
  • A new guard must fail for the RIGHT reason — name the firing assertion, not just the red.
  • Read passed-counts, never ok; parse the test result: line, never stderr. One cargo process
    at a time
    in your own worktree off origin/main.
  • The shared dig-node checkout is several minors behind origin/main and carries unrelated
    uncommitted modifications — read via git show origin/main: and never write there.

Provenance

Scoped by the review gate on DIG-Network/dig-node PR #353 (eco#3128), which closed the first of these
claims. Non-gating there, filed here so the remaining fourteen are measured rather than assumed.

Parent: https://github.com/DIG-Network/dig_ecosystem/issues/3128
Related: https://github.com/DIG-Network/dig_ecosystem/issues/2790 (NC-12; its gap 2 is vacuously
satisfied — a clause that holds because its subject does not exist)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions