fix(buzz): keep progress messages in thread

[cmyk]

What does this PR do?

Keeps Buzz progress and status messages in the same conversation as the event that triggered the agent run.

Buzz inbound events do not populate source.thread_id. Normal final replies still carry the triggering event ID, but the generic progress-routing helper only synthesized that fallback for Slack and Mattermost. Consequently, enabled progress, heartbeat, and interim status messages were sent without a reply anchor and appeared as unrelated top-level Buzz channel posts.

This change gives Buzz the same triggering-event fallback. The existing Buzz adapter then sends the event ID through --reply-to, while an explicit source thread ID continues to take precedence.

Related Issue

No linked issue. Reproduced against current main and verified on a hosted Buzz gateway.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• gateway/run.py
  • Include Buzz in _resolve_progress_thread_id()'s triggering-event fallback.
• tests/gateway/test_buzz_progress_thread_routing.py
  • Verify a missing Buzz source thread falls back to the triggering event ID.
  • Verify an explicit Buzz source thread remains authoritative.
• website/docs/user-guide/messaging/buzz.md
  • Document progress/status reply anchoring.
• tests/gateway/test_buzz_adapter.py
  • Verify thread_id metadata is translated into the Buzz CLI --reply-to flag.

How to Test

1. Run:

   pytest -q tests/gateway/test_buzz_progress_thread_routing.py tests/gateway/test_buzz_adapter.py tests/gateway/test_mattermost.py tests/gateway/relay/test_relay_slack_prompt_dm_root.py

2. Confirm all 74 tests pass.
3. Enable Buzz progress/interim feedback, trigger a long-running agent turn from a Buzz thread, and confirm progress/status events contain a reply anchor and remain in that thread.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Ubuntu 26.04 LTS (x86_64)

The focused cross-platform progress-routing and Buzz adapter suites pass: 74 passed. The full repository suite was not run for this focused four-file change.

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — updated the canonical Buzz guide
• I've updated cli-config.yaml.example if I added/changed config keys — N/A; no configuration keys changed
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A; no architecture or contributor workflow changed
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — the change is platform-key routing with no OS-specific APIs
• I've updated tool descriptions/schemas if I changed tool behavior — N/A; no model tool changed

Screenshots / Logs

74 passed in 1.75s
All checks passed!

Live verification on a hosted Buzz gateway confirmed that progress and interim feedback remained in the originating thread after deployment and restart.

[teknium1]

Thanks for the focused fix. The current-main premise is confirmed: gateway/run.py:687 synthesizes an event anchor only for Slack and Mattermost, while Buzz inbound dispatch creates a source without thread_id at plugins/platforms/buzz/adapter.py:1227-1239. That leaves progress/status metadata unset through gateway/run.py:23854-23869 and gateway/run.py:23982-23992. Adding buzz to the fallback set produces the thread_id that Buzz translates to buzz messages send --reply-to at plugins/platforms/buzz/adapter.py:612-614.

Suggested changes

• Consider adding an adapter-level assertion that metadata={"thread_id": ...} produces --reply-to; the new tests correctly pin resolver behavior, but this would cover the final metadata-to-CLI boundary as well.

Automated hermes-sweeper review.

[cmyk]

Implemented the suggested adapter-level coverage. The new regression test verifies that thread_id metadata is translated into the Buzz CLI --reply-to argument. The focused suite now passes 74 tests. Thanks for the suggestion!