SPEC 6.2 mandates a store-granularity announce without stating that such a record is unbondable by construction

[MichaelTaylor3d]

Task

dig-node-core/SPEC.md §6.2 mandates announcing two records per held capsule — store
granularity and capsule granularity — and says nothing about the fact that one of those two can
never be collateral-verified. State it, so a later reader does not measure it and file it as a
defect.

The structural fact

• §6.2 (crates/dig-node-core/SPEC.md:659-662): "the node announce_providers it at store
  granularity (ContentId::store(store_id)) AND capsule granularity
  (ContentId::capsule(store_id, root)) — two records per held capsule."
• crates/dig-node-service/src/mirror/pointers.rs:113:
  if dig_dht::ContentId::capsule(store, root) != *content { return None; }

So a ContentId::Store record never carries an unverified_mirror_coin_id, and structurally
never could: ContentId::Store { store_id } names no root, while a mirror coin bonds
(store, root, owner, epoch).

Why this needs writing down

Roughly half of all provider records ecosystem-wide are pointer-less by construction, published
by fully current software — not by old nodes, and not transiently. Anyone measuring collateral
coverage without this fact concludes the pointer mechanism is half broken. It is not; the store
record is a discovery aid and the capsule record is the one that carries a bond.

This is the fact that refuted the original vacuity argument on the parent ticket, and it is
currently written in neither SPEC.

Scope

One paragraph in crates/dig-node-core/SPEC.md §6.2. Normative text only — no behaviour change,
no announce change. The two-record announce is correct and stays.

The mirror image of this statement lands in dig-dht's SPEC §6.9 under
DIG-Network/dig-dht#28; the two must agree (§4.1/§4.2 layering: SPEC.md
<-> SYSTEM.md <-> docs must not contradict).

Acceptance

§6.2 states that the store-granularity record is unbondable by construction, why, and that this is
correct rather than a gap. A reader measuring pointer coverage can tell the expected number from the
spec alone.

Links (both directions, per the no-orphans rule)

• Parent: Nothing binds a mirror coin's owner to a DHT peer id — verification cannot name a claimant #473
• Sibling (the dig-dht half): The mirror-pointer doc prescribes a hint-scan fallback no consumer can perform, and calls it slower rather than weaker dig-dht#28
• Epic: https://github.com/DIG-Network/dig_ecosystem/issues/3166
• The verifier this fact governs: feat(mirror): activate bond promotion on the coin's own peer declaration #501

[MichaelTaylor3d]

Scope grows: the same false claim is in FIVE places in dig-node, not just the missing SPEC paragraph

The dig-dht half of this family (DIG-Network/dig-dht#28, PR #29) went through a review gate that found
a seventh site in a file the implementing lane had already edited. That prompted a control-tested
sweep of dig-node, and the claim is here too — five times, all on origin/main:

site	text
crates/dig-node-core/src/lib.rs:567	"announces exactly as it always did, and the verifier's fallback is the hint scan"
crates/dig-node-core/src/mirror_bond.rs:114	the MirrorBondVerifier seam doc — an implementation "may fall back to dig-mirror-coin's hint scan"
crates/dig-node-core/src/peer.rs:3146	"announces exactly as before, and a verifier falls back to the hint scan"
crates/dig-node-core/src/seams/dig_peer/dht.rs:442	"announces exactly as before; the verifier's fallback is the hint scan"
crates/dig-node-service/src/mirror/pointers.rs:125	"answering None degrades discovery to the hint scan, which is the same fully supported state"

mirror_bond.rs:114 is the worst of the five, because it is not a passing remark — it is the
stated justification for the seam's shape. It explains why claimed_coin_id is an Option: so an
implementation "that can establish a holder's owner puzzle hash by some other route may fall back to
the hint scan without a change to this seam." There is no such route, and there cannot be one from a
ProviderRecord: dig_mirror_coin::discover and list both require an owner_puzzle_hash
(query.rs:351, :269), and a provider record carries no owner (dig-dht/src/record.rs:379-433).

So the trait's own contract documents a fallback that no implementation can ever provide. The
Option is still correct — absence is normal — but its reason is false.

Revised scope for this ticket

1. The original paragraph in crates/dig-node-core/SPEC.md §6.2 (store-granularity records are
   unbondable by construction).
2. Correct all five sites above. mirror_bond.rs:114 should say why the Option really exists:
   absence is normal and a verifier withholds credit rather than demoting — not that a scan will
   cover it.

Doc/SPEC text only, no behaviour change. Match the wording landing in dig-dht PR #29 so the two
crates do not disagree (§4.2 layering).

Sweep discipline that found this

rg is not installed on this machine, so the pattern was git grep on the ref, control-tested
against a known hit before any zero was trusted. Patterns worth re-running on any future pass:
hint scan · scanning by hint · scan by hint · fall back to the hint · falls straight back ·
slower, not weaker.

[MichaelTaylor3d]

Lane complete, handed back to the gate. PR: #524 (DRAFT), head 9816c789, version 0.252.12, closingIssuesReferences.totalCount = 1 -> #520.

All five sites corrected plus the SPEC §6.2 paragraph. mirror_bond.rs rewritten rather than phrase-swapped: the Option's stated reason was the false fallback, and it now gives the real one (absence is ordinary; a verifier answers BondVerdict::Unverified, withholding credit rather than demoting).

Control-tested sweep found no sixth site. Wording matches dig-dht PR #29 so the two crates do not disagree.

Not done, deliberately: dig-mirror-coin is declared 0.7 in dig-node-service while 0.9.0 is published — a semver-incompatible uplift on the collateral path that dwarfs a text-only diff (§2.4b), reported rather than started.

[MichaelTaylor3d]

CORRECTION — I propagated a false quantity into four places, and a gate caught it

Earlier in this family I wrote that "roughly half of all provider records are pointer-less by
construction." That is wrong, and it is the same copy-propagated-false-claim defect this whole
family exists to fix. Correcting it everywhere I said it.

What is actually true. inventory_content_ids
(crates/dig-node-core/src/seams/dig_peer/dht.rs:376-392) deduplicates the store id through a
BTreeSet — if seen_stores.insert(store) at :387 — so the store-granularity ContentId is
emitted once per store, while a capsule ContentId is emitted per capsule.

So a node holding N capsules across S distinct stores publishes S pointer-less records and N
that may carry a pointer. The pointer-less share is S/(S+N), which approaches half only in the
degenerate case of one capsule per store, and is small for a node holding many capsules per store.

What this does and does not change.

• It does not change the verdict. The hint-scan fallback is still bounded out on three
  independent grounds, none of which depends on population size: discover cannot be called at all,
  a fallback would be unsound before dig-node#501 lands, and an owner-less scan's "not found" is not
  a negative a verifier may act on.
• It does not restore the vacuity argument I originally used and then withdrew. The population is
  smaller than I said but is still non-empty and non-transient — every distinct store held yields
  one pointer-less record, forever, on current software. The corrected rationale stands: withholding
  credit from that population is already the specified, harmless behaviour under credit-only ranking.
• It does mean any measurement of collateral coverage should expect S uncollateralisable
  records, not N.

How it happened, since that is the reusable part. An adversarial pass supplied both the mechanism
(the two-granularity announce) and the quantity ("about half"). I verified the mechanism at source and
accepted the quantity without checking inventory_content_ids. A verified mechanism does not
verify the number attached to it. The dedup is four lines away from the announce I did read.