Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[DEL-B2] Evidence-driven task recovery, retry authorization and bounded strategy change

Open
  • Is something wrong?
#320 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
15/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
python
Domain
backend

Research direction

Begin from EPIC #315 and hard deps #317/#319 to grasp Manager/Controller split. Reuse loop_guard from #194/#199 and existing candidate validation/sandbox modules; see ADR 0004 for controller effects. Use deterministic fake provider and CLI integration tests; 'done' meets all acceptance criteria with regression fixtures.

Written by the indexing model from the issue text.

Description

enhancement

Parent: EPIC #315 · Stage M3 (adaptive coordination) · Size L · Reconciled 2026-10-25 (UTC) against main at f04db5f (state protocol 12). "Current scope" is authoritative. The earlier planning text follows verbatim and still applies where it does not conflict.

Current scope (reconciled 2026-10-25)

Controller-owned, task-level progress and recovery decisions, built on the existing candidate verifier (_producer_gate / _gate_producer, src/autoforge/engine.py:6224, :6276) and its retry foundation. The controller decides:

  • whether validation failed;
  • whether an outcome is inconclusive;
  • whether an attempt may be retried;
  • whether a strategy change is permitted;
  • whether budget remains;
  • whether a candidate transition is legal;
  • whether execution must stop.

Agents may propose alternative approaches. They cannot authorize their own extra attempts or bypass verification.

Add no second verifier, and do not duplicate the existing loop detection: loop_detect.py (#194, #199) inside a launch, loop_guard.py and workflow.stagnation_* across rounds. Extend their signals where needed.

Dependencies
  • Hard (native): #317, #319.
  • Blocks (native): #322, #323.
Acceptance criteria (added 2026-10-25)
  • A negative verdict vetoes any model-declared completion.
  • Missing validation (no commands configured) is distinguished from passed validation and never counted as success.
  • Genuine progress (a new passing check, a changed failure, a changed candidate) is told apart from repeated failure by objective deltas, never by repeated task text alone.
  • Candidate transitions are atomic, leaving one authoritative SHA and its recovery receipts.
  • Retry authorization is a deterministic function of recorded state and budgets.
  • Budget exhaustion stops safely with the candidate preserved.
  • Existing Review, CI and merge guarantees are unchanged.

Earlier planning text (verbatim)

Superseded where it conflicts with "Current scope" above. In particular, the decisions are the controller's, made through the reducer (#332) over recorded evidence. A Manager's next-task proposal is input to them, only in the optional adaptive mode.

Parent: EPIC #315 · Wave B · Size L · Planning baseline f4fd5ef (2026-10-25 UTC). Research: GVS5H, not an implementation dependency.

Objective / deliverable

Integrate scoped verifier verdicts (existing candidate validation and sandboxed test execution) into the intra-issue Manager's next-task proposal, without weakening existing independent REVIEW/FIX/certification gates. Record failed tests/first bounded counterexample, candidate SHA, run identity; Controller vetoes model done after a definitive negative. Detect no-progress from objective diffs, tests, candidate/evidence changes; reuse #194/#199/loop_guard rather than duplicating provider action detection. Switch to alternate approach after bounded stagnation; a clean sample is evidence, not completion authority.

Dependencies

  • Hard: #317 (DEL-A2)
  • Hard: #319 (DEL-B1)
  • Coordination only: #147 SDK providers / #126 interactions, #154 usage, #176 scheduler and #266 sandbox. Do not add blanket cross-EPIC hard blockers without evidence.

Acceptance criteria

  • Negative objective verdict cannot be overridden by model done; missing/inconclusive verdict is not success
  • Verifier executes in existing policy-selected sandbox, not on untrusted host command path
  • No progress guards use test/diff/evidence deltas, not repeated task string alone
  • Candidate switch or rollback is atomic, only one authoritative SHA and proper recovery receipts remain
  • Regression fixtures cover multiple failures, an actual correction, false positives and review/CI gates unchanged
  • Regression tests preserve original single-agent path, ADR 0004 controller-owned effects, exact candidate validation, ReviewCertificate and merge safety; provider credentials remain isolated.
  • Docs/doctor/config compatibility updated where behavior changes; skipped real-runtime evidence never reported as pass.

Invariants / exclusions

The LLM Manager is advisory. Controller exclusively owns done acceptance, typed GitHub effects, state transitions, candidate identities and merge. Inner tasks are not GitHub native sub-issues and do not modify EPIC graph. Neither Agent nor verifier may execute repository-controlled commands outside the existing sandbox. No unbounded raw transcript/reasoning recording or ambient credentials. Feature remains opt-in; no Public Alpha #255 gate. Coordinate persisted schema on #23 before migration. Do not copy GVS5H's arbitrary subprocess verifier or its text-hash scratchpad and call it production recovery.

Verification hints

Use deterministic fake provider plus real existing CLI integration where available; include redacted bounded evidence, attack cases, failure/cancel/resume, explicit run/issue/candidate SHA. No new orchestration daemon or scheduler.

Dominant language
Python
Stars
0
Forks
0
Avg merge
6h
Merged PRs (30d)
78

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from iceboundrock/AutoForge

All issues in iceboundrock/AutoForge

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.