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

[DEL-A5] Ledger-backed Single-Agent Context Handoff and Memory MVP Validation

Open
  • Is something wrong?
#333 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
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
ai-infra-agents

Research direction

Start with the existing context path in src/autoforge/read_context.py and the producer gate in src/autoforge/engine.py; review dependencies #316 and #317 for the supported Memory interfaces. Implement and validate the end-to-end handoff across the listed retry, REVIEW → FIX, and resume scenarios, then run deterministic fake-agent tests for the acceptance criteria. Done means the supported phases, crash/replay behavior, candidate binding, redaction, bounds, and feature-off behavior are evidenced, with docs and doctor reporting support honestly.

Written by the indexing model from the issue text.

Description

Parent: EPIC #315 · Stage M1 (native Issue Working Memory) · Size L · Created 2026-10-25 (UTC) by the Memory-first reconciliation of #315, against main at f04db5f (state protocol 12).

Objective

Integrate #317's MemoryStore into the existing single-agent workflow before any multi-agent coordinator exists, and prove that it works end to end. This is the first user-visible Memory MVP milestone. #317 on its own does not prove that Memory is useful in a running AutoForge workflow.

Separate invocations that gain memory:

  • ANALYZE_EXECUTE, where #316's first supported scope includes it;
  • a validation failure and its retry (the existing producer gate, _gate_producer, src/autoforge/engine.py:6276);
  • the REVIEW → FIX handoff;
  • a crash and resume.

A phase the first implementation does not support is named as unsupported in the docs and in doctor; parity is never claimed silently.

Behaviour

Before an agent invocation, the controller:

  1. loads the authoritative run and candidate state;
  2. reads the relevant current Issue Memory;
  3. filters records by scope, freshness, status and candidate compatibility;
  4. produces a bounded, redacted context projection;
  5. delivers it through the existing safe context path: the per-launch read-context files that src/autoforge/read_context.py renders, fenced as untrusted data and never read back as evidence.

After an invocation, the controller:

  1. observes the actual execution result;
  2. validates any proposed Memory updates against the typed schema and policy;
  3. binds accepted facts to their evidence and candidate identity;
  4. persists accepted Memory events under #317's lifecycle;
  5. keeps authoritative controller state and effects separate from Memory.

No raw transcript and no hidden model reasoning is ever ingested. How an agent proposes a Memory update (for example a bounded optional field the parser validates) is decided by #316. It must not change the required CONTROL_RESULT fields of any phase.

Non-goals

  • Manager/Worker orchestration.
  • A generic RAG system, or FTS5.
  • Cross-issue knowledge sharing.
  • Model-driven task acceptance.
  • A new GitHub effect kind.
  • An independent verifier.
  • Provider session reuse.

Dependencies

  • Hard (native): #316, #317.
  • Blocks (native): #319. The first integrated multi-agent MVP consumes this validated handoff path.
  • Coordination: #318 (the no-memory baseline and the first comparison). No dependency on #332 (DEL-A4), #319 or #324.

Acceptance criteria

  • End-to-end memory handoff with deterministic fake agents, across a validation-failure retry and a REVIEW → FIX handoff (or the subset #316 supports, with the rest declared unsupported).
  • Feature-off regression tests: with Memory disabled, state files, prompts and behaviour are unchanged.
  • A controlled scenario: a failed approach is recorded, a hypothesis is corrected, the run is interrupted and resumed, and the next invocation sees the correction and not the retracted hypothesis.
  • Crash/replay proof on both sides of every Memory write and every launch.
  • Every projection is bound to the current candidate; a fact bound to an older candidate is absent or labelled stale.
  • No secret reaches Memory, a projection, a log or state (seeded-secret tests).
  • Projections stay within their size and token bounds, and every cut is an explicit omission marker.
  • No stale or retracted fact appears in any handoff.
  • Docs and doctor report the supported phases, modes and providers honestly.
  • A live demonstration against a disposable repository runs only if the owner separately approves it. Otherwise the issue records "not run" and closes on offline evidence. A skipped live run is never reported as a pass.
Dominant language
Python
Stars
0
Forks
0
Avg merge
5h 57m
Merged PRs (30d)
71

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.