[AUTO-EVLV] Proposal: Add label application verification and retry to `new-issue-creator` #8467

New issue

Closed

opened 2026-04-13 19:26:32 +00:00 by HAL9000 · 2 comments

HAL9000 commented

2026-04-13 19:26:32 +00:00

Owner

Agent Evolution Proposal — Cycle 2

Category: Subtask failures (inconsistent label application)
Severity: Medium — issues without labels are skipped by implementation supervisor
Affected file: .opencode/agents/new-issue-creator.md

Problem

The new-issue-creator agent creates issues and then calls forgejo-label-manager to apply labels. However, label application is sometimes failing silently — issues are created without labels, violating the CONTRIBUTING.md requirement that all issues have at minimum State/Unverified, a Type/ label, and a Priority/ label.

Evidence

Bug hunt worker issues created in the same session (2026-04-13, same SHA 5a9aaa79) show inconsistent label application:

Issue	Title	Labels Applied
#8458	PersonaRegistry.get() raises unhandled exception	✅ Priority/Medium, State/Unverified, Type/Bug
#8462	retry_auto_debug skips backoff sleep	❌ No labels
#8463	_sanitize_error_message defines constant as local variable	❌ No labels
#8464	retry_auto_debug raises generic Exception	❌ No labels

All four issues were created by the same bug-hunt-worker session using new-issue-creator. The inconsistency indicates that forgejo-label-manager calls are sometimes failing without causing the new-issue-creator to retry or report the failure.

Impact: Issues without State/Unverified are invisible to the implementation supervisor, which filters by state labels. These issues will never be worked on unless manually labeled by a human.

Root Cause

The new-issue-creator agent's current workflow:

Create the issue using forgejo_create_issue ✓
Apply labels using forgejo-label-manager ← sometimes fails silently
Return the created issue number

There is no verification step after label application, and no retry logic if forgejo-label-manager fails.

Proposed Change

Add a verification step after label application in new-issue-creator.md:

After calling forgejo-label-manager, verify the labels were actually applied by reading the issue back with forgejo_get_issue_by_index. If the required labels are missing, retry the label application up to 2 more times before reporting failure.

Specifically, add to the ## What You Do section:

4. **Verify labels were applied.** After calling `forgejo-label-manager`, read the issue back
   using `forgejo_get_issue_by_index` and confirm the required labels are present.
   If labels are missing, retry `forgejo-label-manager` up to 2 more times.
   If labels still fail after 3 attempts, log a warning in the issue body noting the label
   application failure, but do NOT fail the entire issue creation.

Also add forgejo_get_issue_by_index to the forgejo permissions (it's already there ✓).

Verification

After the fix, all issues created by new-issue-creator should consistently have the required labels applied. The inconsistency rate (currently ~50% in the observed sample) should drop to near zero.

Please approve this proposal by:

Removing the needs feedback label, OR
Adding the State/Verified label, OR
Leaving a comment with explicit approval

Automated by CleverAgents Bot
Supervisor: Agent Evolution | Agent: agent-evolution-pool-supervisor

## Agent Evolution Proposal — Cycle 2 **Category**: Subtask failures (inconsistent label application) **Severity**: Medium — issues without labels are skipped by implementation supervisor **Affected file**: `.opencode/agents/new-issue-creator.md` --- ## Problem The `new-issue-creator` agent creates issues and then calls `forgejo-label-manager` to apply labels. However, label application is **sometimes failing silently** — issues are created without labels, violating the CONTRIBUTING.md requirement that all issues have at minimum `State/Unverified`, a `Type/` label, and a `Priority/` label. --- ## Evidence Bug hunt worker issues created in the same session (2026-04-13, same SHA `5a9aaa79`) show inconsistent label application: | Issue | Title | Labels Applied | |---|---|---| | #8458 | PersonaRegistry.get() raises unhandled exception | ✅ Priority/Medium, State/Unverified, Type/Bug | | #8462 | retry_auto_debug skips backoff sleep | ❌ No labels | | #8463 | _sanitize_error_message defines constant as local variable | ❌ No labels | | #8464 | retry_auto_debug raises generic Exception | ❌ No labels | All four issues were created by the same `bug-hunt-worker` session using `new-issue-creator`. The inconsistency indicates that `forgejo-label-manager` calls are sometimes failing without causing the `new-issue-creator` to retry or report the failure. **Impact**: Issues without `State/Unverified` are invisible to the implementation supervisor, which filters by state labels. These issues will never be worked on unless manually labeled by a human. --- ## Root Cause The `new-issue-creator` agent's current workflow: 1. Create the issue using `forgejo_create_issue` ✓ 2. Apply labels using `forgejo-label-manager` ← **sometimes fails silently** 3. Return the created issue number There is no verification step after label application, and no retry logic if `forgejo-label-manager` fails. --- ## Proposed Change Add a **verification step** after label application in `new-issue-creator.md`: After calling `forgejo-label-manager`, verify the labels were actually applied by reading the issue back with `forgejo_get_issue_by_index`. If the required labels are missing, retry the label application up to 2 more times before reporting failure. Specifically, add to the `## What You Do` section: ``` 4. **Verify labels were applied.** After calling `forgejo-label-manager`, read the issue back using `forgejo_get_issue_by_index` and confirm the required labels are present. If labels are missing, retry `forgejo-label-manager` up to 2 more times. If labels still fail after 3 attempts, log a warning in the issue body noting the label application failure, but do NOT fail the entire issue creation. ``` Also add `forgejo_get_issue_by_index` to the forgejo permissions (it's already there ✓). --- ## Verification After the fix, all issues created by `new-issue-creator` should consistently have the required labels applied. The inconsistency rate (currently ~50% in the observed sample) should drop to near zero. --- **Please approve this proposal by:** 1. Removing the `needs feedback` label, OR 2. Adding the `State/Verified` label, OR 3. Leaving a comment with explicit approval --- **Automated by CleverAgents Bot** Supervisor: Agent Evolution | Agent: agent-evolution-pool-supervisor

HAL9000 commented

2026-04-13 19:26:56 +00:00

Author

Owner

⚠️ Awaiting Human Approval — This proposal requires human review before implementation.

This issue was created by the Agent Evolution Supervisor (AUTO-EVLV) as a Step 1 Proposal. No code changes have been made yet.

To approve this proposal, please do one of the following:

Remove the needs feedback label from this issue
Add the State/Verified label
Leave a comment with explicit approval (e.g., "approved" or "LGTM")

To reject this proposal, please close this issue or leave a comment explaining why.

The supervisor will check for approval on its next cycle (~30 minutes) and dispatch an implementation worker if approved.

Automated by CleverAgents Bot
Supervisor: Agent Evolution | Agent: agent-evolution-pool-supervisor

⚠️ **Awaiting Human Approval** — This proposal requires human review before implementation. This issue was created by the Agent Evolution Supervisor (AUTO-EVLV) as a **Step 1 Proposal**. No code changes have been made yet. **To approve this proposal**, please do one of the following: 1. Remove the `needs feedback` label from this issue 2. Add the `State/Verified` label 3. Leave a comment with explicit approval (e.g., "approved" or "LGTM") **To reject this proposal**, please close this issue or leave a comment explaining why. The supervisor will check for approval on its next cycle (~30 minutes) and dispatch an implementation worker if approved. --- **Automated by CleverAgents Bot** Supervisor: Agent Evolution | Agent: agent-evolution-pool-supervisor