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

Enable issue-driven Fullsend Code/Fix runs to create ears-manager-compliant PRs

Open
  • Is something wrong?
#292 10 comments 2 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@JohnStrunk is already working on this.

Since Oct 15, 2026.

Assessment

This issue has not been assessed yet.

Description

component:ears-manager enhancement feature infra triaged

Problem

The issue-driven Fullsend /fs-code and /fs-fix agents work in a disconnected sandbox. When a PR includes a proposed change set, the agent needs current default-branch Git state to refresh the change set after main moves. Instructions alone cannot fetch that state.

For example, PR #289's proposed CS-00003 retained an older base_commit after the PR branch included the newer main, so CI rejected it with BASE_COMMIT_STALE (run).

The ears-manager freshness gate is intentional and must not be weakened. This issue addresses the current GitHub issue→PR Code/Fix flow; it is distinct from the future Job Site adapter in #172.

Desired outcome

Fullsend /fs-code and /fs-fix runs can create or update PRs that include governed specification changes using ears-manager, while keeping GitHub credentials and network access outside the sandbox.

Scope

  • Provide repository/Fullsend guidance for both /fs-code and /fs-fix when a task changes registered specification artifacts or proposed change sets: use ears-manager; handle DEFAULT_MOVED and BASE_COMMIT_STALE through the governed refresh and impact-review flow; do not edit manifests or registered artifacts by hand.
  • Configure both the Code and Fix harnesses, and any task-specific skill/tooling needed, to run the repository's ears-manager workflow and shared freshness helpers.
  • Add trusted runner-side helper scripts to fetch the canonical default branch and provide the disconnected sandbox with the necessary local Git refs/history and diagnostics, without exposing credentials or network access to the sandbox. The exact credential-free ref/history handoff is an implementation choice.
  • Keep ordinary code-only PRs working without requiring a change set.

Clarified behavior

Code/Fix refresh and impact review
  • Both /fs-code and /fs-fix use the same governed refresh behavior when a task includes a proposed change set.
  • After refreshing the proposal's base, the Code/Fix agent reruns ears-manager impact, compares the resulting candidates and dispositions with the prior impact assessment, and self-reviews the result. It records the refreshed assessment through ears-manager and surfaces changed dispositions and their rationale in the resulting PR update/summary. This is an agent self-review; a separate human approval is not a prerequisite to PR publication.
  • Registered artifacts and change-set manifests must still be changed only through the governed ears-manager operations.
Trusted publication check and race behavior
  • Immediately before the PR create/update operation, the trusted runner fetches and validates the canonical default-branch state against the candidate change set. If that check cannot establish authoritative state, detects divergence, or finds the proposal stale, it stops the PR operation and gives actionable recovery guidance.
  • The final successful runner check is the freshness decision point. If main advances after that check but before the PR operation, the PR may be created or updated with a stale proposal. The existing CI ears-manager freshness check remains the merge gate and must reject that PR until a later governed refresh and impact self-review makes it current.
  • Do not weaken or remove the CI freshness check. Do not force-push or silently change the previously recorded impact assessment. A PR rejected by CI is not a successful compliant outcome; recovery uses a later Code/Fix run and the governed refresh flow.

Acceptance criteria

  • Both /fs-code and /fs-fix runs that change registered specification artifacts use the governed ears-manager operations and can produce a valid proposed change set.
  • The offline agent has sufficient verified local Git history/state to refresh a stale proposal, update its base, rerun impact analysis, compare and self-review dispositions, and surface changes with their rationale.
  • A trusted runner-side check validates the candidate against the canonical default branch immediately before PR creation or update. If the check sees stale/diverged state or cannot fetch authoritative state, it performs no PR mutation and reports actionable guidance.
  • Tests cover both publication timing cases:
    • If the final trusted check finds that the candidate is stale because main advanced during the run, the helper fails closed and does not create/update the PR.
    • If main advances after the final successful check but before the PR operation, the PR may be created/updated, but the existing ears-manager CI check rejects it; no merge can proceed until a later governed refresh and impact self-review passes.
  • If the remote is unavailable or the candidate is divergent at the final check, the helper fails closed. No credentials or unrestricted network access are added to the sandbox.
  • Code-only PRs remain unaffected, and CI's existing ears-manager checks remain enabled.

Related

  • #205 — allow ears-manager writes and base refresh after commits on a change-set branch.
  • #237 — enforce proposed change-set base freshness in CI.
  • #255 / PR #289 — require registered artifact operations in ears-manager check.
  • #172 — separate Fullsend Job Site adapter work; this issue is for current issue-driven PR automation.

(AI generated)

Dominant language
Go
Stars
6
Forks
8
Avg merge
1d 5h
Merged PRs (30d)
84

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 redhat-et/ProtoBot

All issues in redhat-et/ProtoBot

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.