Proposed work: distinguish bounty references from GitHub linked issues

[LikeACloud7]

Bounty #649

Problem

MergeWork accepts Bounty #<issue> and Refs #<issue> as bounty reference formats, but GitHub and third-party bot checks can treat them differently. A PR can be valid for MergeWork bounty review with Bounty #646, while a bot's linked-issue check still reports that no GitHub linked issue was found.

That creates a small but recurring triage ambiguity for maintainers and agents: "bounty reference present" and "GitHub linked issue keyword present" are not the same signal. The current docs and local preflight tooling accept both formats, but they do not explicitly separate the two meanings.

Current Evidence

• PR Add docs-agent bounty claimability guardrails #695 includes Bounty #646 in the body and is correctly shaped as a MergeWork bounty submission.
• CodeRabbit's pre-merge output on PR Add docs-agent bounty claimability guardrails #695 shows Linked Issues check as skipped because no linked issues were found, even though the bounty reference is present.
• .github/pull_request_template.md asks for Bounty #N or Refs #N under "Related bounty or issue".
• docs/bounty-rules.md says bounty PR submissions should use Bounty #<issue> or Refs #<issue>, and says to use a closing reference only when the issue should close after that PR.
• docs/agent-guide.md and scripts/submission_quality_gate.py treat Bounty #<issue> / Refs #<issue> as bounty-reference-valid formats.
• scripts/bounty_refs.py intentionally parses bounty, refs, fixes, closes, claims, and related verbs into the same bounty-reference set for MergeWork tooling.

Proposed Work

Add a narrow docs or reporting clarification that distinguishes:

• MergeWork bounty reference present: Bounty #N, /claim #N, or another accepted bounty reference format.
• GitHub linked issue semantics present: Refs #N, Fixes #N, Closes #N, or another GitHub-recognized linking/closing keyword.

One possible implementation is a non-blocking advisory in scripts/submission_quality_gate.py:

• If Bounty #N is present but no GitHub-linking keyword is present, keep bounty_reference passing.
• Add an advisory note that GitHub or bot linked-issue checks may still be skipped because Bounty #N is a MergeWork bounty reference, not a GitHub linked-issue keyword.
• Keep closing keywords optional and do not recommend Fixes / Closes unless the bounty issue should actually close after the PR.

Another acceptable implementation would be docs-only guidance in the PR template, agent guide, or bounty rules if maintainers prefer not to add another quality-gate warning.

Expected Value

This would reduce false triage around bot messages such as "no linked issues found" without changing accepted bounty reference formats, issue-closing behavior, payment rules, proof generation, wallet behavior, or treasury execution.

It also gives contributors clearer guidance: use Bounty #N when they need a MergeWork bounty reference, use Refs #N when they also want GitHub-level linking, and use closing keywords only when closing the issue is intended.

Acceptance / Verification Notes

• A body with only Bounty #646 remains valid for MergeWork bounty-reference validation.
• A body with Refs #646 can be reported as both bounty-reference-valid and GitHub-linking-intent-present.
• A body with Fixes #646 or Closes #646 should not be recommended by default because it may close the issue on merge.
• Tests or docs smoke coverage should verify that the distinction remains documented or reported.

Duplicate Search

Searched existing issues for bounty reference linked issue, Bounty Refs linked issue, Linked Issues check, CodeRabbit, Bounty Pr Focus, and related phrases.

Related but distinct issues found:

• Proposed work: Add bounty-focus false-positive triage guidance #691 covers CodeRabbit Bounty Pr Focus false-positive triage.
• Proposed work: Flag bounty PRs missing the standard quality check #692 covers missing standard quality/readiness workflow signals.
• Proposed work: add review-bounty candidate selection report #693 covers review-bounty candidate selection.
• Proposed work: expose structured submission mode for non-PR bounties #676 covers structured submission mode for PR vs issue/manual/review submissions.
• MRWK bounty: 250 MRWK - flag PRs that reference non-live bounty issues #645 and related non-live-reference work cover stale or non-claimable bounty references.

This proposal is narrower: clarify the semantic difference between a MergeWork bounty reference and GitHub/bot linked-issue detection.

Non-Goals

• No change to bounty acceptance, payout, proof, ledger, wallet, treasury, or admin behavior.
• No requirement to replace Bounty #N with Refs #N.
• No recommendation to use Fixes or Closes unless the issue should close.
• No private security details, secrets, credentials, price, investment, exchange, liquidity, bridge, cash-out, or fabricated payout claims.