Switchbordswitchbord
Sign inGet started
All releases
v0.16.26

v0.16.26

gb-agent connector human_review drafts now render a review-only handoff preview card in the inbox, and Meta post referrals now surface as operator-visible Meta attribution.

What's new


  • gb-agent handoff preview: drafts whose route is human_review now surface their connector evidence and proposed-review actions in a restrained amber card in the existing pending-draft area. No Accept/Send button, no side-effect buttons, no customer-visible body — review-only by construction.
  • Feature flag: rendering is gated by inbox.gbAgentHandoffPreview (default OFF, env override NEXT_PUBLIC_FLAG_INBOX_GB_AGENT_HANDOFF_PREVIEW=1). When OFF, the existing thin "Human review" badge behavior is preserved exactly.
  • Pure mapper: apps/app/lib/connector-draft-preview.ts normalizes message_drafts.metadata into a render-ready preview shape. Drops side-effect-only fields, non-https/userinfo evidence URLs, and any connector-secret-sensitive fields. Throw-safe on malformed metadata.
  • Docs: new /platform/gb-agent-connector page documents the connector at a high level, the two card variants, and the dry-run boundary that guarantees no autosend, no CRM writes, and no queue/unread mutations from the connector itself.
  • Meta post referrals: inbound WhatsApp referrals from Meta/Facebook posts (source_type=post) now create first-touch attribution rows, carry the same Meta indicator in the inbox list, and render the orange operator-only attribution card as "Post Meta" with the original headline/source URL/image context.

Why


The connector worker already persists GBCA connector_draft_run_response_v1 payloads into message_drafts.metadata and responder_runs.metadata. For draft_reply runs the operator gets the existing AI draft card. For human_review runs there is no sendable body, only evidence and proposed actions — and until now the inbox showed a thin "Human review" badge with no preview content. This slice gives the operator something to look at without introducing any side-effect buttons or autosend paths.


Meta post referrals are the same operator workflow as CTWA ad referrals: the customer entered WhatsApp through a Meta surface and then refers to "l'offerta di cui sopra". They should be visible in the inbox even when the source is a post rather than a Marketing API ad.


Privacy and safety notes


  • Post referral source_id values are not treated as Marketing API ad IDs, so the worker does not call Meta Graph ad endpoints for posts.
  • Existing Meta CDN image allow-listing remains in place for referral previews.
  • Backfill queries remain workspace-scoped through existing message and conversation attribution rows.

Out of scope


  • No API contract changes (connector_draft_run_response_v1 untouched).
  • No new realtime channels (reuses the existing message_drafts subscription).
  • No mobile inbox layout changes.
  • No per-action buttons (mark unread, assign queue, create operator task) — those would be live effects and ownership is still being coordinated.
  • Meta post referrals are not enriched through Marketing API ad endpoints.

Verification


  • pnpm --filter @repo/database exec vitest run src/adapters/__tests__/webhook-button-consent.test.ts src/adapters/__tests__/read-ctwa-attribution-from-messages.test.ts src/adapters/ctwa-attribution-enrichment.test.ts
  • pnpm --filter app exec vitest run components/inbox-conversation-list-row.test.tsx components/inbox/ctwa-attribution-card.test.tsx
  • pnpm release:hygiene
  • pnpm --filter @repo/database typecheck
  • pnpm --filter app typecheck
  • pnpm --filter app build
Older← v0.16.27Newerv0.16.25 →