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
- 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.
- 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.
- 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.
- 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.
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@5bbad010f234ac71533f1afd120f44b75d9117ddapps/fountain_buzz/buzz-acp.version=0.5.14-fountain.4.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.
session/new, persistent session store andsession/loadafter restart.freshSessionon rotate.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
desktop-vX.Y.Zrelease 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.freshSessionrotation, rendered owner commands and rejection of pre-startup commands. Update callers in the same PR if an upstream field changed.buzz-acp.sourceand 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_commandat a localcargo build --release -p buzz-acpof the fork branch.Not gated, just noted
Two concurrent first
session/newcalls 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.