Context
Global's linkedIssueLabelPropagation mapping for gittensor:priority (private VPS config) sets removeOtherTypeLabels: true with no trustMaintainerAuthoredIssueForReward key. All 3 live repos instead set removeOtherTypeLabels: false + trustMaintainerAuthoredIssueForReward: true — matching the codebase's own bundled canonical example (src/config/gittensory-repo-focus-manifest.ts:~83-87), which documents priority as intentionally additive ("an issue is routinely both gittensor:feature AND gittensor:priority at once"). The functional consequence, traced in src/settings/pr-type-label.ts:163-169: an earlier exclusive match (e.g. bug) fully discards a later exclusive-mode gittensor:priority match — not merged, not applied — in exactly this routine dual-label case.
Zero live impact today (array-valued keys replace wholesale, and all 3 repos fully override the mappings array) — this is a latent bug in the fallback default that would silently and completely break priority-reward labeling for the next repo onboarded to the gate fleet without its own override, with no error surfaced anywhere.
Requirements
- Direct edit to the private dedicated-server config, not a GitHub PR.
Deliverables
Expected Outcome
A future repo onboarded to the fleet without its own label-propagation override gets correct, additive priority-reward labeling by default instead of a silent total breakage.
Links & Resources
- Evidence:
global.gittensory.yml:94-96; jsonbored__gittensory.gittensory.yml:77-80 (same shape at metagraphed:87-90, awesome-claude:53-56); src/config/gittensory-repo-focus-manifest.ts:~83-87; src/review/linked-issue-label-propagation.ts:66-74; src/selfhost/private-config.ts:165-172 (wholesale array replace)
Part of #5270 (roadmap epic).
Context
Global's
linkedIssueLabelPropagationmapping forgittensor:priority(private VPS config) setsremoveOtherTypeLabels: truewith notrustMaintainerAuthoredIssueForRewardkey. All 3 live repos instead setremoveOtherTypeLabels: false+trustMaintainerAuthoredIssueForReward: true— matching the codebase's own bundled canonical example (src/config/gittensory-repo-focus-manifest.ts:~83-87), which documents priority as intentionally additive ("an issue is routinely bothgittensor:featureANDgittensor:priorityat once"). The functional consequence, traced insrc/settings/pr-type-label.ts:163-169: an earlier exclusive match (e.g.bug) fully discards a later exclusive-modegittensor:prioritymatch — not merged, not applied — in exactly this routine dual-label case.Zero live impact today (array-valued keys replace wholesale, and all 3 repos fully override the
mappingsarray) — this is a latent bug in the fallback default that would silently and completely break priority-reward labeling for the next repo onboarded to the gate fleet without its own override, with no error surfaced anywhere.Requirements
Deliverables
global.gittensory.yml'sgittensor:prioritymapping entry toremoveOtherTypeLabels: false+trustMaintainerAuthoredIssueForReward: true, matching all 3 per-repo overrides and the bundled canonical example.Expected Outcome
A future repo onboarded to the fleet without its own label-propagation override gets correct, additive priority-reward labeling by default instead of a silent total breakage.
Links & Resources
global.gittensory.yml:94-96;jsonbored__gittensory.gittensory.yml:77-80(same shape at metagraphed:87-90, awesome-claude:53-56);src/config/gittensory-repo-focus-manifest.ts:~83-87;src/review/linked-issue-label-propagation.ts:66-74;src/selfhost/private-config.ts:165-172(wholesale array replace)Part of #5270 (roadmap epic).