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

[DEL-B1] Fresh-context scoped Worker handoff using the existing AgentProvider boundary

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
python
Domain
ai-infra-agents

Research direction

Begin by reading EPIC #315 and its hard dependencies #316 and #317 to understand the existing AgentProvider boundary and Controller. Review ADR 0004 and the current single-agent path tests to learn the authorized Git workspace and sandbox. Work is done when the opt-in coordinator meets the acceptance criteria with regression tests and no new orchestration daemon. Do not start before #316 and #317 land.

Written by the indexing model from the issue text.

Description

enhancement

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

Objective / deliverable

Add opt-in issue-local coordinator calling existing Claude Code, OpenCode 2.x and Pi providers as fresh scoped workers, with sanitized task description, curated Ledger, current candidate and minimal trusted repo context. Manager provides proposed next task; Controller validates bounds and decides launch. Agent edits use the existing authorized Git workspace, sandbox and private auth; one mutating Worker at a time. No provider assumptions about session reset: capability-check fresh session and refuse unsupported modes. Keep prompts provider-neutral, evidence- and candidate-bound.

Dependencies

  • Hard: #316 (DEL-A1)
  • Hard: #317 (DEL-A2)
  • 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

  • Fresh Worker does not inherit previous transcript/permissions/secrets or unrelated issue context
  • No second controller/scheduler; Git mutations and provider invocations respect L0/L2/L1 and sandbox required mode
  • Candidate SHA/run context checked at every handoff and worker completion; stale results cannot overwrite verified work
  • Crash, timeout, canceled, repeated tool/permission requests and SDK/CLI unsupported modes are typed fail-closed
  • Legacy single-agent workflows unaffected when feature disabled
  • 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.

MemCurrent-inspired bounded context catalog and on-demand recall (2026-10-25)

  • Each new Worker may receive a compact, Controller-rendered Memory Catalog (topic labels, counts, scope, generation, watermark/freshness, query instructions), never the whole Corpus, automatically selected only when memory feature is explicitly enabled.
  • When #324 is available, offer typed Controller-mediated search_memory (bounded candidate list) and fetch_memory (bounded verified item + evidence) capability; no arbitrary gh, host command, MCP plugin, extension or unscoped path. Without #324, preserve existing #317 curated Issue Ledger-only handoff.
  • Treat catalog and hits as untrusted inert context; strong controller-side permissions, current MemoryStore check, token budget, SHA/applicability and correction tombstones apply at both search and fetch. A tool call may never mutate MemoryStore, issue state or GitHub.
  • Benchmarks prove lower-or-bounded prompt/context overhead relative to stuffing all prior notes, and report empty, stale, unavailable-index and provider-not-supported behavior; no hidden fallback to extra model APIs.
Dominant language
Python
Stars
0
Forks
0
Avg merge
5h 51m
Merged PRs (30d)
66

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.