Problem
A contributor who authored the linked issue inherits every label on it, bypassing the reward-label
trust gate entirely.
src/review/linked-issue-label-propagation-fetch.ts:207:
if (issueAuthorLogin === prAuthorLogin || assignees.includes(prAuthorLogin)) return { labels: allLabels, inconclusive: false };
const maintainerCheck: MaintainerCheckResult =
relaxableLabels.size > 0 && !!issueAuthorLogin
? await isRepoMaintainerLogin(args.env, args.installationId, args.repoFullName, issueAuthorLogin)
: "not_maintainer";The author/assignee branch returns before relaxableLabels and isRepoMaintainerLogin are consulted.
The trustMaintainerAuthoredIssueForReward flag exists precisely to make reward-label unlocking a
deliberate per-repo operator choice — see its own doc comment. This branch hands out the identical reward
label (gittensor:priority via the additive mapping at
packages/loopover-engine/src/settings/pr-type-label.ts:171-178) with no flag and no maintainer
check.
The codebase already detects this exact shape as self_authored_linked_issue
(src/rules/advisory.ts:966-975) — advisory by default — and the label unlock ignores that finding
entirely.
Trigger
A contributor files issues. The maintainer or the gardening pass labels them gittensor:* per the repo's
own conventions. The contributor then submits PRs closing their own issues and self-awards the highest
multiplier.
Exploitability depends on the repo's issue-labelling workflow — on a repo where contributor-filed issues
routinely get labelled, it is trivial.
Impact
The reward multiplier becomes self-selectable at issue-filing time rather than PR-title time, which
is a longer-lived and less-scrutinised surface.
Dedup
Distinct from #9077, which covers (1) title-regex classification and (2)
trustMaintainerAuthoredIssueForReward applied to a merely-claimed issue. This is a third, unflagged
branch that sits above both and requires no opt-in.
Requirements
- Split the unlock: author/assignee identity may unlock type labels, but any label named by a mapping
with reward semantics must require the …ForReward opt-in and a maintainer-authorship check,
regardless of the author match.
- Consider feeding the existing
self_authored_linked_issue finding into the unlock decision rather than
computing authorship twice with different conclusions.
Test Coverage Requirements
99%+ patch coverage, branch-counted; both arms of author-match with and without reward-semantic labels.
Links & Resources
maintainer-only — reward integrity.
Problem
A contributor who authored the linked issue inherits every label on it, bypassing the reward-label
trust gate entirely.
src/review/linked-issue-label-propagation-fetch.ts:207:The author/assignee branch returns before
relaxableLabelsandisRepoMaintainerLoginare consulted.The
trustMaintainerAuthoredIssueForRewardflag exists precisely to make reward-label unlocking adeliberate per-repo operator choice — see its own doc comment. This branch hands out the identical reward
label (
gittensor:priorityvia the additive mapping atpackages/loopover-engine/src/settings/pr-type-label.ts:171-178) with no flag and no maintainercheck.
The codebase already detects this exact shape as
self_authored_linked_issue(
src/rules/advisory.ts:966-975) — advisory by default — and the label unlock ignores that findingentirely.
Trigger
A contributor files issues. The maintainer or the gardening pass labels them
gittensor:*per the repo'sown conventions. The contributor then submits PRs closing their own issues and self-awards the highest
multiplier.
Exploitability depends on the repo's issue-labelling workflow — on a repo where contributor-filed issues
routinely get labelled, it is trivial.
Impact
The reward multiplier becomes self-selectable at issue-filing time rather than PR-title time, which
is a longer-lived and less-scrutinised surface.
Dedup
Distinct from #9077, which covers (1) title-regex classification and (2)
trustMaintainerAuthoredIssueForRewardapplied to a merely-claimed issue. This is a third, unflaggedbranch that sits above both and requires no opt-in.
Requirements
with reward semantics must require the
…ForRewardopt-in and a maintainer-authorship check,regardless of the author match.
self_authored_linked_issuefinding into the unlock decision rather thancomputing authorship twice with different conclusions.
Test Coverage Requirements
99%+ patch coverage, branch-counted; both arms of author-match with and without reward-semantic labels.
Links & Resources
src/review/linked-issue-label-propagation-fetch.ts~200-212;packages/loopover-engine/src/settings/pr-type-label.ts~153-178;src/rules/advisory.ts~966-975maintainer-only — reward integrity.