Replace /reset-worker workflow with TriggerComment-based retrigger

[gjkim42]

Summary

The /reset-worker GitHub Actions workflow (.github/workflows/reset-kelos-worker.yaml) can be replaced by the spawner's TriggerComment retrigger feature (#432), but there's a blocker: the kelos/needs-input excludeLabel prevents the spawner from even discovering issues that need retriggering.

Current flow

1. Spawner discovers issue (no kelos/needs-input) → creates task
2. Agent finishes → adds kelos/needs-input label
3. Human posts /reset-worker → workflow removes label + deletes task via kubectl
4. Next poll cycle → spawner rediscovers the issue and creates a new task

Problem

TriggerComment retrigger (#432) can delete completed tasks and recreate them, but excludeLabels: [kelos/needs-input] filters out the issue at the GitHub API level before the spawner ever sees it. The trigger comment is never evaluated.

Proposal

Teach the spawner to remove the kelos/needs-input label (or a configurable excludeLabel) when it retriggers a completed task. This would let TriggerComment fully replace the /reset-worker workflow:

1. Human posts trigger comment (e.g., /kelos pick-up)
2. Spawner discovers the issue (label no longer blocks discovery for retrigger)
3. Spawner deletes the completed task, removes the excludeLabel, and creates a new task

Considerations

• The kelos/needs-input label is also used by kelos-triage.yaml — changes should not break that flow
• /reset-worker also resets running tasks; TriggerComment only handles completed ones
• Admin-only access control on /reset-worker would be lost unless replicated

[kelos-bot]

🤖 Kelos Agent @gjkim42

Kelos Triage Report

Kind: kind/feature
Priority: priority/important-longterm — Valuable workflow simplification but /reset-worker remains functional; not blocking adoption
Actor: needs human — Requires architectural decisions on excludeLabel bypass semantics, triage flow interaction, running-task reset parity, and access control replication

Status: STILL VALID

Evidence:

• The blocker described in this issue is confirmed in the current codebase. GitHubSource.filterItems() (internal/source/github.go:240-274) removes issues with any excludeLabel before comments are evaluated, so TriggerComment retrigger (Support immediate re-triggering of completed tasks before TTL cleanup #432, fixed by PR Support immediate re-triggering of completed tasks via TriggerComment #452) can never fire for issues labeled kelos/needs-input.
• The /reset-worker workflow (.github/workflows/reset-kelos-worker.yaml) is still present and operational — it removes the label and deletes the task via kubectl with admin-only access control.
• Both kelos-workers and kelos-triage TaskSpawners (self-development/) use excludeLabels: [kelos/needs-input], confirming the label is load-bearing in the current workflow.
• PR Support immediate re-triggering of completed tasks via TriggerComment #452 (merged 2026-02-27) implemented TriggerComment retrigger for completed tasks but did not address the excludeLabel interaction described here.

Duplicates found: None found. Issue #432 (closed) addressed general retrigger of completed tasks but did not cover the excludeLabel blocker. #369 (auto-retrigger on CI failure) is a different scope.

Recommendation: KEEP OPEN — The issue correctly identifies a real gap between TriggerComment retrigger and excludeLabel filtering. Multiple design decisions need human input before implementation: (1) should the spawner bypass excludeLabel filtering when checking for retrigger comments, or remove the label as a side effect; (2) how to avoid breaking the triage flow which also uses kelos/needs-input; (3) whether to replicate the admin-only access control from /reset-worker; (4) how to handle running tasks, which TriggerComment currently does not cover.