Configuration Alignment: label workflow adds issue-only needs labels to generated PRs

[kelos-bot]

🤖 Kelos Self-Update Agent @gjkim42

Area: Configuration Alignment

Summary

.github/workflows/label.yaml currently applies the issue-triage needs-* synchronization rules to pull requests as well as issues. As a result, generated PRs that already satisfy the PR template contract still accumulate needs-triage, needs-priority, and needs-actor labels even though the PR rules only require a /kind label and a release-note state.

This is configuration drift between:

• AGENTS.md / .github/PULL_REQUEST_TEMPLATE.md, which define PR requirements as exactly one /kind plus a release-note block
• .github/workflows/label.yaml, whose PR check only blocks needs-kind and needs-release-note
• the same workflow's sync-labels job, which still adds issue-only needs-triage, needs-priority, and needs-actor labels to PRs

Evidence from the codebase

AGENTS.md says PRs must follow .github/PULL_REQUEST_TEMPLATE.md, choose exactly one /kind, and fill the release-note block. It does not require priority, actor, or triage labels for PRs.

.github/PULL_REQUEST_TEMPLATE.md only contains /kind guidance and the release-note block. It has no /priority, /actor, or /triage-accepted section.

.github/workflows/label.yaml has one sync-labels rule list for both issues and PRs:

{ prefix: null, match: 'triage-accepted', needs: 'needs-triage' },
{ prefix: 'kind/', match: null, needs: 'needs-kind' },
{ prefix: 'priority/', match: null, needs: 'needs-priority' },
{ prefix: 'actor/', match: null, needs: 'needs-actor' },

But the same workflow's PR gate only treats these as blocking:

const blocking = ['needs-kind', 'needs-release-note'];

self-development/kelos-triage.yaml also confirms that needs-triage, needs-priority, and needs-actor are issue-triage lifecycle labels: the triage TaskSpawner only listens to issues events and removes those labels from issues after posting a triage report.

Evidence from recent generated activity

Open generated PRs show the drift is broad, not theoretical:

gh pr list --state open --label generated-by-kelos --json number,title,labels --limit 100 \
  --jq '[.[] | {number,title,labels:[.labels[].name]}] | {total:length, withNeedsTriage: map(select(.labels|index("needs-triage")))|length, withNeedsPriority: map(select(.labels|index("needs-priority")))|length, withNeedsActor: map(select(.labels|index("needs-actor")))|length, withNeedsKind: map(select(.labels|index("needs-kind")))|length, withNeedsReleaseNote: map(select(.labels|index("needs-release-note")))|length}'

Current result:

{"total":34,"withNeedsActor":34,"withNeedsKind":7,"withNeedsPriority":32,"withNeedsReleaseNote":1,"withNeedsTriage":32}

All 34 open generated PRs have needs-actor, and 32/34 have needs-triage and needs-priority, even though most already have valid kind/* and release-note or release-note-none labels. Across all open PRs, the same query shows 52/52 have needs-actor, 47/52 have needs-priority, and 46/52 have needs-triage.

Examples from current generated PRs:

• PR Update opencode image to 1.16.2 #1309 Update opencode image to 1.16.2: has kind/feature and release-note, but also needs-triage, needs-priority, and needs-actor.
• PR self-development: add review-derived agent conventions #1249 self-development: add stream-forwarding, trigger-filter, and handler-error conventions from recent reviews: has kind/cleanup and release-note-none, but also needs-triage, needs-priority, and needs-actor.

Impact

The labels make generated PRs look under-triaged even when they satisfy the actual PR checks. That adds noise to PR lists, hides the one real blocking state (needs-kind or needs-release-note), and creates a lifecycle label state that no TaskSpawner currently clears for PRs.

Proposed minimal fix

Update .github/workflows/label.yaml so PRs and issues use separate needs-* synchronization rules:

1. For issues, keep the current triage lifecycle rules: needs-triage, needs-kind, needs-priority, and needs-actor.
2. For PRs, sync only PR-relevant blocking labels: needs-kind and the existing release-note labels.
3. When the workflow runs on a PR, remove stale issue-only labels (needs-triage, needs-priority, needs-actor) if present, but do not require priority/actor/triage labels going forward.
4. Keep the existing check-pr-labels gate aligned with this behavior: PRs should fail only on needs-kind or needs-release-note.

This is a small workflow-only configuration cleanup. It does not change the self-development TaskSpawners or the PR template contract.

Duplicate check

I reviewed the current open generated issues and searched for existing reports mentioning needs-priority, needs-actor, PR labels, and the label workflow. I did not find an existing issue covering issue-triage needs-* labels being synced onto PRs.

[kelos-bot]

🤖 Kelos Task Status

Task kelos-triage-issues-476268f436f3 has succeeded. ✅

[kelos-bot]

🤖 Kelos Agent @gjkim42

Kelos Triage Report

Kind: kind/bug
Priority: priority/important-longterm — Broad PR-label noise and workflow drift, but it does not block builds or core user workflows.
Actor: actor/kelos — Concrete workflow-only configuration cleanup with objective label/check behavior and no API design required.

Status: STILL VALID

Evidence:

• No merged PRs referencing Configuration Alignment: label workflow adds issue-only needs labels to generated PRs #1314 were found with gh pr list --state merged --search "1314", and recent commit searches for 1314 plus the label-workflow/needs-label terms returned no hits.
• .github/workflows/label.yaml:201 still defines one shared rules list for issues and PRs that syncs needs-triage, needs-kind, needs-priority, and needs-actor.
• .github/workflows/label.yaml:240 handles PR release-note labels separately, while .github/workflows/label.yaml:305 only blocks PRs on needs-kind and needs-release-note, confirming the issue-only labels are not part of the PR gate.
• .github/PULL_REQUEST_TEMPLATE.md:1 only asks for one /kind and a release-note block; self-development/kelos-triage.yaml:5 listens only to issues webhook events for triage lifecycle handling.

Duplicates found: None found

Recommendation: KEEP OPEN