Skip to content

buzz-acp: retire fork after all required behavior ships upstream #776

Description

@jhgaylor

Tracks the temporary fork pin introduced in #775 and when it is safe to undo.

State today (verified 2026-09-13)

  • apps/fountain_buzz/buzz-acp.source = jhgaylor/buzz@5bbad010f234ac71533f1afd120f44b75d9117dd
  • apps/fountain_buzz/buzz-acp.version = 0.5.14-fountain.4.
  • Latest upstream desktop release checked: desktop-v0.5.23, published 2026-09-05. It is not a safe replacement for the fork.

The fork carries five upstream behavior changes. The earlier three-row checklist omitted #6103 and #6104, which were already recorded in this issue's comments.

Upstream PR Verified state Required behavior
#6088 Open, unmerged Channel metadata on session/new, persistent session store and session/load after restart.
#6101 Open, unmerged Owner control commands with rendered mention text.
#6103 Open, unmerged freshSession on rotate.
#6104 Open, unmerged Ignore control commands predating startup.
#6097 Closed, unmerged; upstream uses a replacement design Publish the kind:10100 relay-agent directory entry expected by the fork integration, or prove and adopt a compatible replacement.

The pinned fork comparison contains all five changes. On the checked upstream tag, ACP session creation still lacks channel metadata and freshSession; the session store is absent. The command parser still compares trimmed content exactly, and control handling lacks the pre-startup timestamp guard.

For discovery, the #6097 closure explanation points to #6338, whose merged commit is included in the checked release. Upstream now uses owner kind:30177 and roster kind:39002. That is not evidence that Fountain's kind:10100 behavior can be dropped; verify both owner-provisioned and legacy-agent flows before adopting the replacement.

Safe to undo when

  1. A selected desktop-vX.Y.Z release contains all required behavior above, either through these PRs or verified replacements. A merged PR alone is insufficient; neither #6088 alone nor an "all five PRs merged" rule is the right gate.
  2. On that exact tag, verify channel metadata, restart/session-load continuity, freshSession rotation, rendered owner commands and rejection of pre-startup commands. Update callers in the same PR if an upstream field changed.
  3. Verify directory publication/discovery and Fountain access updates for existing and owner-provisioned agents. If upstream's 30177/39002 design replaces the fork's 10100 publication, implement and test that migration before dropping the fork.
  4. Then remove buzz-acp.source and update the version pin and matching build inputs in one reviewed PR. Build and verify release assets before merging a consumer image change that needs them. Artifact publishing and deployment are separate operator actions.

Until these gates pass, retain the fork. If a required behavior is rejected upstream, keep or rebase that patch until an equivalent released design has been integrated and verified here.

Also gated on #6088 shipping

Desktop agents (Game Maker, philo) still open a fresh conversation per Buzz desktop restart until the desktop ships a buzz-acp with the session store. Hosted harnesses are unaffected — they run our pinned build. Interim for a desktop agent: point its acp_command at a local cargo build --release -p buzz-acp of the fork branch.

Not gated, just noted

Two concurrent first session/new calls for one channel can both create a conversation; the next call resumes the newer one (Conversations.start_or_resume_conversation/2). Fine for buzz-acp, which runs one turn per channel at a time; a client that fans out on a cold channel would need a lock or unique index. Only worth doing if such a client appears.

Refs: #774, #775, #773, #787, #792, block/buzz#6088, #6097, #6101.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Scheduled focus — queued behind P2area:buzzBuzz integration: hosted harness, signer, provider, buzz-acp pinneeds:externalRequires credentials, vendor access, production access, or an upstream change

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions