feat(surface): trigger namespaces for every relayfile adapter with webhooks

[khaliqgant]

Stacked on #446 (feat/github-trigger-vocabulary); rebase onto main once it merges. Draft until the merge condition below is met.

Why

flow().on(...) could subscribe to Slack and GitHub only. scripts/generate-triggers.mjs read the mapping YAML bundled in @relayfile/adapter-core, and that was the two core fallbacks — while relayfile ingests events from 47 providers (linear 33, gitlab 47, ramp 47, notion 13, cloudflare 8, …).

What

The generator applies three sources per provider, in order:

1. core fallback mappings (mappings/*.mapping.yaml);
2. each adapter's own mapping — mappings/adapters/*.mapping.yaml in the package once relayfile-adapters#280 ships, packages/<adapter>/ in a checkout — superseding the fallback as a whole;
3. the trigger catalog @relayfile/adapter-core/triggers (KNOWN_TRIGGER_CATALOG, fed by every adapter's supportedEvents()) for providers with no webhooks: block.

Mapping-backed providers keep payload-aware signatures (github.pull_request(action?)); catalog-backed ones get (filter?). 47 namespaces, 570 events (catalog events unioned into every provider; a mapping only adds payload shape) — full table in the generated packages/surface/src/triggers/PROVIDERS.md (covered by --check). github/slack are strict supersets of #446's output (6 fallback GitHub events and their signatures unchanged), so flows deploy --on github:events=… is unaffected. Hyphenated ids become identifiers (azure_blob.file_created() lowers to { provider: 'azure-blob', type: 'file.created' }); a reserved-namespace guard refuses a provider named like a surface export (webhook, flow, schedule, …).

flows check's provider-event refusal (provider-trigger-contract.ts) reads providerEventTypes, so it now covers all 47 with no change of its own.

Merge condition

• relayfile-adapters#280 published as @relayfile/adapter-core ≥ 0.5.26, then bump the pin in packages/sdk/package.json, run node scripts/generate-triggers.mjs --check, un-draft.
• Until then --check (and tests/generate-triggers.test.ts "reproduces all checked-in modules") reports drift on github.ts, gitlab.ts, index.ts, PROVIDERS.md only — 45 of 47 providers already generate identically from the catalog 0.5.25 ships.

Tests

• surface: triggers-all-providers.test.ts (≥40 providers present; every registry event has a frozen namespace method lowering to {provider,type}; hyphenated ids; catalog-only signature), triggers-github-events.test.ts relaxed to a superset.
• sdk: generator fixture with a catalog JSON (catalog-only providers added with (filter?), mapping-backed never overridden, PROVIDERS.md generated and drift-checked, reserved namespaces refused); provider-trigger-contract.test.ts accepts one subscription from each of github/slack/linear/notion/gitlab, refuses no.such.event on five providers, and flows check passes a five-provider flow.
• Full SDK suite on a built kernel: 1796 passed, 1 failed (the pin-drift check above), Bun-version skip.

What Cloud still gates (not implemented here)

Local ingress delivers any of these providers today (flows serve-webhook → POST /providers/<name> → providerInboxEvent). Hosted deployments do not: cloud/packages/web/lib/flows/flow-trigger-sources.ts (FLOW_TRIGGER_PROVIDERS = ["github","linear","jira","shortcut","slack"], flowIssueFromEvent → per-provider *IssueFromEvent) and launch-flow-deployment.ts (skipped: "not_a_ticket", inputs: { approver, issue, event }) admit only ticket-shaped events from those five, plus PR events after cloud#3772; prepare-flow-deploy.ts builds watch rules from the same list (buildFlowWatchRules, flowSourceTriggers).

Proposed generalisation: at deploy time, derive the deployment's subscriptions from the flow's declared sources — each .on(<provider>.<event>(filter)) is { provider, eventType, filter } (already what providerDeclaration() extracts in the SDK) — persist them on the deployment record (flow-deployment-store.ts), build one watch rule per (provider, eventType) on that provider's relayfile projection (the rule paths per provider come from each adapter's inbound.ts / path-mapper, not a hand-kept table), and in launch-flow-deployment.ts admit any delivered event whose (provider, eventType) the deployment declared, passing the raw record as inputs.event and dispatching the matching handler body (the #301 handler-dispatch work) — with issue/pullRequest projections kept as conveniences for the five ticket providers. Until #301 lands, the default body runs with inputs.event only.

🤖 Generated with Claude Code

---

Summary by cubic

Adds trigger namespaces for every relayfile adapter provider, so flow().on(...) can subscribe to all 47 providers (570 events) instead of only GitHub and Slack. The generator now merges core fallback mappings, adapter-local mappings, and the trigger catalog, and unions catalog events into every provider so a webhooks: block can no longer hide events ingress actually delivers. Mapping-backed providers keep payload-aware signatures like github.pull_request(action?), while catalog-only events take (filter?); GitHub and Slack are strict supersets, so existing subscriptions keep their signatures.

Details

• Bumps @relayfile/adapter-core to 0.5.26, which bundles adapter-local mappings, and regenerates all trigger modules from the installed tarball; generate-triggers.mjs --check now passes.
• Hyphenated provider ids become identifiers (azure_blob) but keep their upstream spelling when lowered.
• The generated PROVIDERS.md is covered by the generator's drift check, and flows check now admits events from all 47 providers.
• A reserved-namespace guard refuses provider names like webhook, flow, and schedule.
• The GitHub vocabulary gains github.check_run(action?) and github.issue_comment(action?), and flows deploy --on github:events=pull_request now selects PR events for hosted GitHub listeners.
• Action-qualified events like pull_request_edited now take a plain (filter?); only aggregate events (pull_request, check_run, issue_comment) still accept an action, and both spellings stay because two ingresses deliver them.
• Where two upstream names mangle to one identifier (slack publishes both reaction.added and reaction_added), the mapping-declared event owns the method and the other stays in providerEventTypes, subscribable via webhook(...).

Not included

• Hosted Cloud deployments still gate on the existing five providers; local ingress already delivers all 47, but the new namespaces aren't wired into hosted triggers yet.

^{Written for commit 179fb09. Summary will update on new commits.}

---

Note

Medium Risk
Large generated public API surface and expanded providerEventTypes affect flows check and all provider subscriptions; backward compatibility relies on GitHub/Slack remaining supersets of prior exports.

Overview
Expands flow trigger authoring from GitHub and Slack only to 47 providers and 570 events by regenerating @relayflows/surface trigger modules from an upgraded generator and @relayfile/adapter-core 0.5.26.

generate-triggers.mjs now merges three inputs per provider: core fallback mappings, adapter-local mappings (new in adapter-core), and KNOWN_TRIGGER_CATALOG (unioned so catalog events are always present; mapping YAML only shapes signatures for events it declares). It emits per-provider TypeScript namespaces, an expanded providerEventTypes registry, and a drift-checked PROVIDERS.md. Mapping-backed events keep payload-aware APIs (e.g. github.pull_request(action?)); catalog-only events use (filter?). Action-qualified names like pull_request.edited stay filter-only even when the mapping extracts action. Colliding identifiers favor mapping-declared events; registry-only duplicates remain valid via webhook(provider, { provider, type }). Reserved surface names (webhook, flow, schedule, …) are rejected as provider namespaces.

GitHub and Slack are strict supersets of the prior vocabulary (existing six GitHub mapping events and signatures preserved). Tests cover catalog union, drift on PROVIDERS.md, multi-provider flows check, and namespace coverage across providers.

^{Reviewed by Cursor Bugbot for commit 179fb09. Bugbot is set up for automated code reviews on this repo. Configure here.}