Problem
src/review/content-lane/registry-logic.ts:276-315's computeGrounding doc comment says "the caller supplies the fetched evidence and uses strong to gate a merge." src/review/content-lane/netuid-verification.ts:1-18's header says the TAOSTATS-optional path "returns null... so the merge gate falls back to the page-mention + registry-identity grounding signals." Both are extensively unit-tested (12+ cases). But computeGrounding has zero callers anywhere except its own test file, and the actually-wired live path (assessSurfaceEntry at lines 476-536 -> runSurfaceReview in orchestrator.ts:207-291) never fetches or checks source_url's content at all -- it only validates that source_url/url are safe, well-formed public HTTPS/WSS URLs via isSafeHttpUrl/isSafeEndpointUrl. Nothing in the live merge decision confirms the URL's content actually corroborates the claimed netuid/owner/host, despite this being the core "prove the subnet publishes it" requirement the surface-submission model depends on.
Proposal
Fetch source_url content in runSurfaceReview (or a wrapping caller) and feed it plus the fetched target page into computeGrounding, gating merge on a minimum strong score -- or, if this is deliberately deferred pending the "GitHub/D1 I/O orchestrators" mentioned in content-lane/index.ts's own header, confirm that and file the concrete follow-up explicitly once ready.
Deliverables
Links & Resources
src/review/content-lane/registry-logic.ts:276-315,476-536src/review/content-lane/netuid-verification.ts:1-18src/review/content-lane/orchestrator.ts:207-291src/review/content-lane/content-lane-wire.ts:222
Boundaries
This changes what evidence is required before a subnet-registry surface auto-merges -- exactly the kind of gate-authority change that needs a design review, not a drive-by contributor PR. Do not unlock for contributors without an explicit maintainer decision on the fetch/gating design first.
Problem
src/review/content-lane/registry-logic.ts:276-315'scomputeGroundingdoc comment says "the caller supplies the fetched evidence and usesstrongto gate a merge."src/review/content-lane/netuid-verification.ts:1-18's header says the TAOSTATS-optional path "returns null... so the merge gate falls back to the page-mention + registry-identity grounding signals." Both are extensively unit-tested (12+ cases). ButcomputeGroundinghas zero callers anywhere except its own test file, and the actually-wired live path (assessSurfaceEntryat lines 476-536 ->runSurfaceReviewinorchestrator.ts:207-291) never fetches or checkssource_url's content at all -- it only validates thatsource_url/urlare safe, well-formed public HTTPS/WSS URLs viaisSafeHttpUrl/isSafeEndpointUrl. Nothing in the live merge decision confirms the URL's content actually corroborates the claimed netuid/owner/host, despite this being the core "prove the subnet publishes it" requirement the surface-submission model depends on.Proposal
Fetch
source_urlcontent inrunSurfaceReview(or a wrapping caller) and feed it plus the fetched target page intocomputeGrounding, gating merge on a minimumstrongscore -- or, if this is deliberately deferred pending the "GitHub/D1 I/O orchestrators" mentioned incontent-lane/index.ts's own header, confirm that and file the concrete follow-up explicitly once ready.Deliverables
strong-threshold gates mergeLinks & Resources
src/review/content-lane/registry-logic.ts:276-315,476-536src/review/content-lane/netuid-verification.ts:1-18src/review/content-lane/orchestrator.ts:207-291src/review/content-lane/content-lane-wire.ts:222Boundaries
This changes what evidence is required before a subnet-registry surface auto-merges -- exactly the kind of gate-authority change that needs a design review, not a drive-by contributor PR. Do not unlock for contributors without an explicit maintainer decision on the fetch/gating design first.