feat(orchestrators): add Buzz (block/buzz) orchestrator detection

[rsnodgrass]

What

Adds Buzz (block/buzz) as a RoleOrchestrator, alongside Conductor / OpenClaw / Gas City. Buzz is Block's chat/agent platform whose buzz-acp harness spawns Claude Code / Codex / Goose as sub-agents over ACP. Downstream tools (e.g. ox) need to recognize when they're running under Buzz to tag telemetry/attribution and adapt behavior.

Why a process-ancestry probe (not just env vars)

Buzz sets no fixed "spawned by Buzz" marker on the child it launches (crates/buzz-acp/src/acp.rs AcpClient::spawn() never .env_clear()s and sets no BUZZ_ORCHESTRATOR=1). The one signal that is always present and config-independent is process ancestry — buzz-acp is by construction an ancestor of the agent it spawns. agentx's Environment only exposed env/files/exec/paths, so this PR adds an ancestry probe.

Detection precedence (orchestrators/buzz.go)

#	Signal	Role
1	ORCHESTRATOR_ENV == "buzz"	Generic self-ID hatch (operator/wrapper-set)
2	BUZZ_ACP_AGENT_COMMAND != ""	Best-effort env secondary (present when buzz-acp was configured via env, not the --agent-command flag)
3	buzz-acp in ProcessAncestry()	Reliable primary — spawn-scoped, config-independent
—	BUZZ_RELAY_URL / BUZZ_PRIVATE_KEY	Deliberately rejected — workstation-scoped Quick-Start exports that would false-tag a plain agent session in a Buzz user's shell

Changes

• Environment.ProcessAncestry() ([]string, error) — new interface method returning ancestor executable base names (parent → PID 1).
  • Unix: one ps -A -o pid=,ppid=,comm= snapshot walked in memory — no new dependency (works on macOS/BSD/Linux, doesn't rely on /proc).
  • Windows: stub returning empty (falls back to env-var signals), matching ox's own internal/proc approach; implement via Toolhelp32 if Buzz-on-Windows detection is ever needed.
  • MockEnvironment gains an Ancestry []string field as the test seam.
• orchestrators/buzz.go — full Agent impl, pure orchestrator (nil hook/command/rules managers; Capabilities.MCPServers=true, since MCP forwarding over ACP session/new is Buzz's durable integration surface).
• AgentTypeBuzz added to the enum + SupportedAgents; registered in setup/setup.go.

Tests

• orchestrators/buzz_test.go — table-driven Detect covering all three positive signals (incl. deep-in-chain and prefix ancestry) and, crucially, negative guards that BUZZ_RELAY_URL / BUZZ_PRIVATE_KEY alone do not detect (prevents re-adding the rejected heuristic) and that bare buzz ≠ buzz-acp.
• agent_test.go SupportedAgents count bumped 20 → 21.
• make test green, golangci-lint run → 0 issues.

Real-host validation: a throwaway check of SystemEnvironment.ProcessAncestry() on a live dev host returned [go zsh claude conductor-runtime conductor] — correctly surfacing the actual orchestrator (Conductor) as an ancestor, exactly the mechanism Buzz detection relies on. Under buzz-acp, buzz-acp would occupy that slot.

Release

Cut v0.1.11 after merge so consumers (ox) can bump go.mod.

Note

Commit is unsigned (the signing key's passphrase wasn't available in the automation environment) — re-sign on merge if the repo requires signed commits.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 2 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: ad54e697-fe3e-47e3-afe9-aafcfef3576b

📥 Commits

Reviewing files that changed from the base of the PR and between f633bf3 and fa77255.

📒 Files selected for processing (10)

• CHANGELOG.md
• agent.go
• agent_test.go
• environment.go
• environment_ancestry_unix.go
• environment_ancestry_unix_test.go
• environment_ancestry_windows.go
• orchestrators/buzz.go
• orchestrators/buzz_test.go
• setup/setup.go

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/buzz-orchestrator

---

_{Comment @coderabbitai help to get the list of available commands.}