Feedback: what should duplicate-load receipts prove for multi-root skills/context?

[caioribeiroclw-pixel]

Market signal this came from: recent Cursor/Claude reports where the same context/skill is discovered through multiple roots or delivery mechanisms (native file, hook/session-start, plugin cache, sibling tool directory). In those cases, "the file exists" is not enough evidence. The useful receipt is: which candidate was selected, which duplicates were suppressed, and why.

I shipped the schema shape in v0.3.23 on GitHub as fidelityReport.targets[].duplicateLoadEvidence:

{
  "contentIdentity": "sha256:...",
  "candidateLoads": [{ "path": "...", "toolOwner": "...", "loadedBy": "...", "discoveryRoot": "..." }],
  "selectedLoad": { "path": "...", "selectionReason": "..." },
  "suppressedLoads": [],
  "crossRootScanMode": "not-inspected",
  "duplicateRisk": "unknown"
}

The important part is the warning: Pluribus can currently name/hash the generated candidate, but it does not yet inspect runtime scanner roots, plugin caches, hooks, or sibling tool skill/rule folders. So duplicateRisk: "unknown" is intentional.

Feedback I want from people using Cursor skills, Claude Code hooks, Codex/AGENTS.md, or multi-tool skill roots:

1. What duplicate source actually causes waste/confusion in your setup?
   • same file via native + hook?
   • same skill under .claude/skills, .codex/skills, .cursor/skills?
   • plugin/cache/vendor directories?
2. What would count as proof that the duplicate was suppressed?
   • content hash?
   • selected root priority?
   • one receipt per session/turn?
   • explicit replace/supplement marker?
3. Should Pluribus next model candidateLoads from filesystem roots, or stay conservative and only document the runtime receipt shape until a tool exposes actual load events?

My current bias: stay conservative until there is a clear fixture, but make the receipt shape visible so compatibility claims stop pretending multi-root scans are automatically safe.