⚠️ Read first: the migration is already applied to production

0047 and 0048 were applied by hand on 2026-08-24 (single prod/staging database), in one transaction, verified. Do not re-run them , and a reviewer does not need to. Both use IF NOT EXISTS, so a later drizzle-kit migrate is a harmless no-op, but Drizzle's journal does not know they ran.

This PR also edits 0047_playbook_webhook.sql, which someone else authored. That is deliberate and safe: it had never been applied on any database, because it could not be , see below.

Why this feature never worked

Two independent reasons, which is likely why it was abandoned:

1. Never applied. The playbook_webhook table did not exist in production.
2. Unapplicable. 0047 declared org_id as text against organizations.id (uuid). Postgres refuses that FK: "Key columns "org_id" and "id" are of incompatible types: text and uuid." Proved in a rolled-back transaction. Every other org FK in the schema is uuid.

The unit tests stayed green throughout, because the dispatch test mocked runPlaybookSectionExecution , the only step that could have failed loudly. Five passing tests over a feature that could not run at all. This PR replaces that mock.

What this adds

A webhook row gains a source , what fires it. http is the original behaviour and the default for every existing row. slack_channel is fired by Cedar's own Slack ingest, reaching the same queue, dispatch and blocks. One entrance more, not a second machine; playbook compilation learns nothing about Slack.

Three behaviours worth reviewing closely:

• Fan-out is deliberate. One message fires every registration , three reps who each registered get three executions. Only org scope is singular, enforced by a partial unique index rather than by code.
• Both paths run. A channel that is both linked to a deal and registered as a source keeps its deal timeline and runs its agent. So two executions for one message is expected.
• topLevelOnly defaults on. The self-post filter catches Cedar's bot, not a human replying beneath the agent's own post , which would otherwise re-fire it forever.

Service parity

A webhook could previously only be minted from the playbook editor. Extracting the rules into playbook-webhook-registration.ts is what surfaced the authz hole: ownership was checked in the tRPC route only, so config-write could register a webhook against another user's AOP.

cedar-cli webhook test --id <id> --text "…" fires through the real dispatch path and waits, printing which agents ran. outcome: null means nothing ran, which almost always means no <trigger> block references the row.

Fixes to the pre-existing feature

• No DLQ on PlaybookWebhookQueue , a persistently failing dispatch retried, then vanished.
• 5-minute visibility timeout against an unbounded consumer; a redelivery re-runs the whole agent and posts its output twice. Now 15, matching calendar-sync.
• Org-scope needed no admin role , any member could create an org-wide webhook.
• Duplicate-org-source guard read the wrong error property, so it would have 500'd instead of explaining itself (crm.ts:553 documents this exact trap).

Verified

types 0 errors · deps:check clean, 1535 modules · 758 tests / 44 files passing (services/playbook, services/integrations/slack, skills/account-config).

Constraints were exercised against live Postgres in a rolled-back