HALO workflow-first sourcing decision

Status: converged research decision · 2026-08-29 Scope: multi-persona product architecture, full-SaaS candidates, niche live products, and verified GitHub donors. Client anchor: block/buzz ↗ is selected for the collaboration layer. Boundary: research only. repo/ was not modified and no Convex mutation was run.

The corrected answer

HALO is not “a CRM with some missing pages.” It is a multi-persona agency operating system:

• owners/admins need exceptions, money, decisions, risk, access, and a morning command

centre;

• managers need creator lifecycle, campaigns, shifts, QA, approvals, and handoffs;
• chatters need a fast Discord-like execution workspace with creator-scoped context;
• creators/models need a deliberately restricted portal for onboarding, briefs,

documents, status, statements, and support;

• referral partners and staff need their own narrow records, work, and money views;
• agents need first-class identities, bounded tools, evidence, and human approval.

The earlier hunt underperformed because it searched for replacements for existing screen labels. The new campaign searched the jobs around those screens, whole operating systems, niche creator-agency products, and adjacent production/knowledge/workflow categories.

The recommendation is not one giant replacement and not a loose bag of repositories. It is a coherent composition:

HALO identity + domain core
  creators · staff · permissions · contracts · Drive/content · referrals · money
            |
            | server-side adapter, stable IDs, typed links, outbox/inbox events
            v
Buzz collaboration + agent plane
  channels · threads · DMs · canvases · huddles · media comments · workflows · agents
            |
            +-- bounded specialist rails only where a real workflow proves the need

Buzz is genuinely integrated, but it does not become the CRM or money ledger. That source-of-truth split is the difference between a modular product and six conflicting SaaS products sharing the same customer data.

Operator/community evidence sharpened four non-negotiable product rules: chat is promoted into a structured request/decision/action instead of becoming the record by default; approvals bind a named person to an exact asset version; content and payment have separate state machines; and chatters receive narrow shift/creator context while creators receive a bounded external portal rather than access to staff operations.

What the campaign actually covered

• Local Foundry identity spine: 1,358,200 RepoCards searched as a candidate source.
• Curated repository corpus: 307,180 repositories plus human-curated co-placement.
• GitHub wide funnel: 77 explicit query families, 263 captured raw rows in the fully

visible runs, 18 repositories in 17 promoted rows, and 8 recorded rejects. Every cited repository was refreshed through gh api repos/OWNER/NAME; every NOASSERTION finalist had its license source inspected.

• Live products: 11 system-class families plus 15 bounded products were evaluated

against the eight operator journeys using first-party product/documentation evidence.

• Fixed integration source: Buzz's architecture, event/API surface, identity model,

channels, workflows, agent model, search, audit, and implementation gaps were inspected from a read-only upstream source reference.

GitHub's authenticated search quota reached zero after the wide funnel. Direct repository verification remained available and was completed for everything promoted. This limits further breadth in this snapshot; it does not turn an unverified search hit into a recommendation.

The full-system shortlist

NocoBase, Directus, Airtable Omni, Odoo, Corteza, erxes, Rocket.Chat, Mattermost and Zulip remain valuable comparison systems. None has a cleaner role beside Buzz than the ranked set. In particular, Zulip/Mattermost/Rocket.Chat/Discord no longer compete to be the primary chatter product: Camron selected Buzz.

The niche repository shortlist

These are not “more apps to install.” Each survives because it fills a specific workflow that the whole-system candidates do not solve cleanly.

Buy the commodity trust boundaries

Some important capabilities should not be reconstructed from a repository:

• 1Password Business: move creator/platform secrets out of Convex and the client

bundle; HALO stores references and ownership, not passwords.

• Stripe Connect / Trolley / Deel: payment, payout, tax-form and contractor rails where

the legal model fits. HALO still owns the double-entry liability ledger, approval, statement, dispute and reconciliation history.

• Frame.io or Filestage: professional media/document review if one real content slice

proves HALO should buy rather than build versioned approval.

• MaestroQA: chatter QA/calibration only if a real quality program outgrows HALO's

scorecard needs.

Buzz integration decision

The source-level conclusion is sidecar, not code merge:

• one HALO agency community first;
• staff/chatters and read-only agents first; creator guest rooms later;
• HALO server authority provisions Buzz memberships and resource rooms;
• stable opaque HALO IDs and allowlisted deep links connect creator, shift, campaign,

content-review and exception context;

• an idempotent outbox/inbox adapter exchanges non-financial events;
• Buzz actions create proposals/tasks; HALO re-authorizes and requires a human for money,

contracts, permissions, credentials, Drive or creator-state mutations;

• HALO remains usable during a Buzz outage.

Verified gaps prevent unrestricted production autonomy today: no production rate limiter was found in the inspected implementation; workflow approval runs do not persist/resume; send_dm and set_channel_topic are stubbed; NIP-FI is draft/optional rather than a finished SSO bridge; roles are too coarse for HALO domain authorization; and huddle recording is not built. The full evidence and rollout are in research/sourcing-campaign/buzz-integration.md.

What to test—not merely discuss

1. Trust containment: fix server identity/authorization and remove plaintext secrets

before any sidecar receives live data.

1. Buzz synthetic deployment: exercise upgrade, backup/restore, key recovery,

offboarding, search isolation, ingress rate control, retention, webhook replay and a full Buzz outage.

1. One chatter/manager workflow: provision a creator or shift room, run a handoff,

attach a HALO resource link, use a read-only briefing agent, and measure whether the history is actually easier to retrieve.

1. One relationship workflow: model Creator, Brand, Campaign, Staff and Referral

Partner in Twenty using fake data; test permissions, export, deletion, API behavior and whether dual entry appears.

1. One vertical workflow: compare Influs against a single campaign from roster through

deliverable, approval, portal and payment status. It must beat a focused HALO slice, not win a feature checklist.

1. One memory/content workflow: Vexa or another consented meeting capture writes an

approved action; AFFiNE is tested with sanitized SOPs/briefs; Kitsu/Zou or Frame.io is tested on one immutable asset-version approval.

1. Money last: prove a double-entry creator/referral liability model, payout reversal,

statement and reconciliation before giving ERPNext or any payment rail authority.

Final product position

The strongest HALO direction is:

A creator-agency operating core with Buzz as its human-and-agent collaboration plane, Salesforce-quality relationship and permission patterns, niche creator-agency workflow ergonomics, and bought commodity trust rails.

That preserves the bespoke work Camron has already built while sourcing the areas where the wider software ecosystem is materially better. It also leaves room for different experiences by persona without pretending every user should live in the same dashboard or every module should share the same datastore.