Add native Devin ACP community distribution

[fenner888]

Purpose

This is the full community-fork integration for builders who want to exercise
Cognition's official Devin CLI in Buzz before the focused upstream preset
merges.

The upstream-compatible contribution is intentionally kept separate and small:
block/buzz#3225. This fork PR also
contains community policy, compatibility handling, distribution isolation,
release tooling, and detailed validation records that do not belong in that
upstream proposal.

What changed

• add the official devin acp CLI as a catalog-driven native ACP runtime
• keep KnownAcpRuntime as the single source of runtime capability facts
• distinguish CLI missing, unauthenticated, ready, and ACP startup-failure states
• add Devin authentication guidance, the white-background Devin mark, and
  catalog-projected frontend metadata
• preserve default-model behavior and owner-only invocation
• keep permission decisions explicit and fail closed
• prevent duplicate visible publication and retry behavior
• harden managed-process restart and descendant cleanup
• isolate the fork's application identity, Keychain service, Nest directory,
  deep-link scheme, and CLI link
• add a source-first macOS, Linux, and Windows builder preview
• document installation, rollback, uninstall, security boundaries, live
  acceptance, and upstream patch boundaries

Security and product boundaries

• Buzz does not redistribute or modify the Devin CLI.
• Each builder installs and authenticates Cognition's official CLI with their
  own account.
• No credentials or Devin configuration are copied, inspected, or modified.
• No bypass or persistent auto-approval mode is enabled.
• New agents remain one-worker and owner-only by default.
• This does not claim model switching, Fusion, fan-out, Outposts, cloud handoff,
  or cloud Devin parity.
• The source preview has no updater and uses no signing credentials.

Validation

• complete local just ci gate passes
• focused runtime catalog, normalization, readiness, discovery, permission,
  publication, restart, and regression tests pass
• desktop frontend production build and Tauri native test suite pass
• Apple Silicon source preparation and isolated package lifecycle pass
• live Apple Silicon Devin ACP DM and channel publication pass
• two separate macOS user contexts prove isolated identities, authenticated
  runtimes, owner-only invocation, allowlist behavior, revocation denial, and
  process cleanup

The current GitHub Actions matrix for the latest commit is:
https://github.com/fenner888/BuzzforDevin/actions/runs/30313919465

Distribution status

This remains a draft because it is the full fork review surface, not the small
upstream merge proposal.

The public testing path is an immutable source-only technical alpha. There
is no unsigned downloadable application. Apple Silicon has completed live
acceptance. Intel macOS, Linux, and Windows are experimental until a real
builder completes the documented Devin ACP acceptance on each host.

Start with
docs/buzz-for-devin-builders.md.

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🔍 Relay-agent directory switched from kind:10100 to kind:30177 drops channel_ids, affecting "anyone"-mode discovery

list_relay_agents now queries KIND_MANAGED_AGENT (30177) via managed_agents_from_events instead of kind:10100 via agents_from_events (desktop/src-tauri/src/commands/agent_discovery.rs:1070-1081). The old agents_from_events (desktop/src-tauri/src/nostr_convert.rs:472-477) preserved channel_ids from the event content, whereas the new managed_agents_from_events (desktop/src-tauri/src/nostr_convert/managed_agents.rs:62-72) hardcodes "channel_ids": [] and "status": "offline".

This is the intended enabler for allowlist-based discovery (the projection now carries respond_to/respond_to_allowlist, and relayAgentIsSharedWithUser's allowlist branch at desktop/src/features/agents/lib/agentAutocompleteEligibility.ts:21-25 does not need channel IDs). However, the "anyone"-mode branch (agentAutocompleteEligibility.ts:27-30) relies on agent.channelIds intersecting shared channels. With channel_ids now always empty, an anyone-mode relay agent that was previously discoverable via a shared channel will no longer be added to the mentionable set, and any relay agent that publishes only 10100 (not 30177) disappears from the directory entirely. The stale comment at agentAutocompleteEligibility.ts:87 still refers to "kind:10100". The fork docs emphasize the allowlist path but do not appear to address this "anyone"/channel-membership discovery change — worth confirming it is intended and covered.

---

Was this helpful? React with 👍 or 👎 to provide feedback.