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 differently — ignoring 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)
Task
Audit the 15 NC-12 claims in
seams/dig_peer/that exist only as doc comments, and determine for eachwhether it is TESTED or merely ASSERTED.
Scoped by the review gate on dig-node PR #353 (
dffb2645):module_transport.rsforwarded_ask.rsmodule_reshare.rsmodule_relay.rsask_routing.rsholder_cache.rsmodule_serve.rsThat is an upper bound, not a defect list — several in
module_resharesit next to real coverage. Theaudit'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:
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-sexrefused. 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 callerbefore #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 differently — ignoring and
threading are indistinguishable. The inequality is
assert_ne!d so a later edit cannot silentlycollapse 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
asserted removed afterwards (
git status --porcelainempty before the restored run).ok; parse thetest result:line, never stderr. One cargo processat a time in your own worktree off
origin/main.dig-nodecheckout is several minors behindorigin/mainand carries unrelateduncommitted modifications — read via
git show origin/main:and never write there.Provenance
Scoped by the review gate on
DIG-Network/dig-nodePR #353 (eco#3128), which closed the first of theseclaims. 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)