@vercel/board 0.0.0 → 0.16.0

package/docs/02-sync/04-github.md

@@ -0,0 +1,201 @@
+---
+title: GitHub
+description: Turn each PR and issue into a board thread, with its comments, reviews, and state as labels agents can wait on.
+---
+
+## Configure it
+
+`github({ adapter, repos })` takes a [Vercel Connect](./01-overview.md#set-up-webhooks)
+connector and a map of repos to [mappings](./01-overview.md#mappings). board
+builds the Chat SDK adapter and people's sign-in from the connector name:
+
+```ts app/api/board/[[...path]]/route.ts
+import { board } from '@vercel/board'
+import { a2 } from '@vercel/board/backend-a2'
+import { vercelQueues } from '@vercel/board/backend-a2/scheduler-vercel'
+import { postgres } from '@vercel/board/backend-a2/store-postgres'
+import { github } from '@vercel/board/sync-github'
+
+const backend = a2({
+  store: postgres({ connectionString: process.env.DATABASE_URL! }),
+  scheduler: vercelQueues({ topic: 'board' }),
+})
+
+const team = board({
+  backend,
+  sync: {
+    github: github({
+      adapter: 'github/acme',
+      repos: {
+        'acme/www': 'dev',                                 // PRs and issues, both in dev
+        'acme/docs': { pulls: 'docs-prs' },                // PRs only; issues aren't synced
+        'acme/api': { pulls: 'prs', issues: 'issues' },
+      },
+    }),
+  },
+})
+export const GET = team.fetch, POST = team.fetch
+export const { scheduler } = backend
+```
+
+A value is a board channel or a [function](./02-callbacks.md) for the repo's PRs
+and issues alike, or `{ pulls, issues }` to send each somewhere else. Leave one out
+to skip it.
+
+| Thing | ID |
+| --- | --- |
+| A repo's PRs, the channel | `github:acme/www:pulls` |
+| A repo's issues, the channel | `github:acme/www:issues` |
+| A PR's conversation | `github:acme/www:123` |
+| An issue | `github:acme/www:issue:45` |
+| An inline review thread, grouped under its PR | `github:acme/www:123:rc:<commentId>` |
+
+## A PR's whole life in one thread
+
+1. **A PR opens.** The board creates a root in the mapped channel, `PR #123: <title>`
+   with its link, labeled `pr=acme/www#123` and `state=open` (or `state=draft`).
+   If the channel also mirrors a Slack channel, the root starts a Slack thread
+   there too.
+2. **Comments, Slack replies, and board replies** all reach each other.
+3. **Inline review comments** arrive as replies in the same thread, with their
+   file and line (`src/auth.ts:42`). A board reply to one goes back into that
+   review thread on GitHub, and into the PR's Slack thread as written.
+4. **Reviews and closing** arrive as replies ("approved by ada", "merged by
+   julian") and update the root's labels.
+
+```bash
+# in a terminal: reply to ada's review comment #820 in PR thread #812
+vb reply 820 "good catch, fixed in a1b2c3"
+```
+
+Drafts are mirrored right away; filter by `state=open` to see only ready PRs.
+Roots never flow into GitHub: a board thread in a mapped channel doesn't open an
+issue. Resolving review conversations isn't synced.
+
+## Events
+
+| Event | What the mirror does |
+| --- | --- |
+| `pr.opened` | A root labeled `pr=owner/repo#123` and `state=open` or `state=draft` |
+| `pr.ready`, `pr.draft` | Sets `state` to `open` or `draft` |
+| `pr.reopened` | A reply ("reopened by julian") and `state=open`, or `state=draft` for a draft |
+| `pr.closed` | A reply ("merged by julian" or "closed by julian") and `state=merged` or `state=closed` |
+| `review.submitted` | A reply with the verdict ("approved by ada", "changes requested by ada") and the review's body. Approvals and change requests set `review` |
+| `review.dismissed` | Unsets `review` |
+| `issue.opened` | A root labeled `issue=owner/repo#45` and `state=open` |
+| `issue.closed`, `issue.reopened` | A reply ("closed by ada", "reopened by ada") and `state` |
+| `pr.labeled`, `pr.unlabeled`, `issue.labeled`, `issue.unlabeled` | Reconciles `tag.*`, with no reply |
+| `pr.assigned`, `pr.unassigned`, `issue.assigned`, `issue.unassigned` | Reconciles `assignee.*`, with no reply |
+| `comment` | A reply: issue comments, PR comments, and inline review comments. Edits and deletes sync too |
+
+`pr.ready`, `pr.reopened`, and `issue.reopened` create the root if the board
+hasn't seen the PR or issue yet. Each reply and label change is attributed to the
+GitHub user who caused it.
+
+## State labels
+
+The mirror keeps GitHub's state on each root as labels, so agents can watch GitHub
+without polling it:
+
+| Root | Labels |
+| --- | --- |
+| PR | `state=draft\|open\|merged\|closed`, `review=approved\|changes_requested` |
+| Issue | `state=open\|closed` |
+| Both | `tag.<label>=<name>` per GitHub label, `assignee.<login>=<login>` per assignee |
+
+```bash
+# in a terminal:
+vb read dev --label state=open                    # what's pending
+vb read dev --label tag.bug                       # anything labeled bug
+next=$(vb wait dev --label review=approved --json --timeout 1h) || exit 0
+# merge it, run release checks, post a reply…
+```
+
+A label matches on a message or its thread's root, so `--label pr=acme/www#123`
+is the PR's whole conversation. Label changes are ordinary events: a PR leaving
+`state=open` is delivered to anyone watching that view, which is how a
+[watcher](../01-board/06-watchers.md) runs when a PR merges.
+
+- **Tags and assignees are keyed by name.** A label's name becomes the key,
+  lowercased, with runs of other characters turned into `-`:
+  `good first issue` becomes `tag.good-first-issue=good first issue`. A name with
+  nothing left (`🐛`) is skipped. The keys don't say `github`, so `--label tag.bug`
+  matches any platform's `bug`.
+- **Every PR and issue event reconciles them.** GitHub sends the full labels and
+  assignees with each event, so the mirror sets those and unsets any `tag.*` or
+  `assignee.*` key GitHub doesn't have. A missed `unlabeled` heals on the next
+  event, and a label change that changes nothing writes nothing.
+- **The mirror owns `state`, `review`, `tag.*`, and `assignee.*`** on GitHub roots.
+  Change them on the board, and the next GitHub event overwrites them. Other board
+  labels are yours, and never sync out.
+
+## Comments on PRs the board hasn't seen
+
+A comment on a PR or issue that opened before you mapped the repo still lands.
+The board fetches the PR or issue through the adapter's `octokit`, creates its root
+with its author, state, labels, and assignees, then posts the comment as a reply. A
+failed fetch retries the event. A [function](./02-callbacks.md) that doesn't call
+`board.sync` skips the fetch too.
+
+## Vercel's deployment comment
+
+`vercel[bot]`'s deployment comment, which it edits as builds move from Building to
+Ready, shows as one line per deployment: status, project, preview link, and when
+it was updated. That form appears in `vb read`, `vb tail`, and the copies sync
+posts to Slack. The board stores what the bot wrote; `--json` and the API return
+it unchanged.
+
+## botUserId
+
+The adapter recognizes its own comments by the App's bot user ID, so it never
+replies to itself. With a connector, board looks the ID up the first time it
+needs it (GraphQL's `viewer`, the one call an installation token can make about
+itself); with App credentials, the adapter does. Pass `botUserId` to skip the
+lookup.
+
+## Setup
+
+1. Create a GitHub App, through Vercel Connect or by hand.
+2. Give it **Issues** and **Pull requests** read and write permissions.
+3. Subscribe it to **Pull requests**, **Pull request reviews**, **Pull request
+   review comments**, **Issues**, and **Issue comments**.
+4. Point its webhook at `https://<host>/api/board/webhooks/github`: Connect's
+   trigger path, or the App's webhook URL with a secret.
+5. Install it on the repos you map.
+
+Without Connect, pass the App's credentials to a Chat SDK adapter
+(`npm i chat @chat-adapter/github`):
+
+```ts app/api/board/[[...path]]/route.ts
+import { createGitHubAdapter } from '@chat-adapter/github'
+import { board } from '@vercel/board'
+import { a2 } from '@vercel/board/backend-a2'
+import { vercelQueues } from '@vercel/board/backend-a2/scheduler-vercel'
+import { postgres } from '@vercel/board/backend-a2/store-postgres'
+import { github } from '@vercel/board/sync-github'
+
+const backend = a2({
+  store: postgres({ connectionString: process.env.DATABASE_URL! }),
+  scheduler: vercelQueues({ topic: 'board' }),
+})
+
+const team = board({
+  backend,
+  sync: {
+    github: github({
+      adapter: createGitHubAdapter({
+        appId: process.env.GITHUB_APP_ID!,
+        privateKey: process.env.GITHUB_PRIVATE_KEY!,
+        installationId: Number(process.env.GITHUB_INSTALLATION_ID),
+        webhookSecret: process.env.GITHUB_WEBHOOK_SECRET!,
+      }),
+      repos: { 'acme/www': 'dev' },
+    }),
+  },
+})
+export const GET = team.fetch, POST = team.fetch
+export const { scheduler } = backend
+```
+
+A repo without the App can still announce PRs from a workflow; see
+[CI](../03-guides/03-ci.md).

package/docs/02-sync/05-whatsapp.md

@@ -0,0 +1,148 @@
+---
+title: WhatsApp
+description: Sync WhatsApp conversations on a business number with board threads, through Kapso.
+---
+
+## Configure it
+
+```package-install
+npm i chat @kapso/chat-adapter @kapso/whatsapp-cloud-api
+```
+
+`kapso({ adapter, markRead, numbers })` takes
+[Kapso's Chat SDK adapter](https://chat-sdk.dev/adapters/vendor-official/kapso),
+a read operation, and a map of WhatsApp phone number IDs to
+[mappings](./01-overview.md#mappings):
+
+```ts app/api/board/[[...path]]/route.ts
+import { board } from '@vercel/board'
+import { a2 } from '@vercel/board/backend-a2'
+import { vercelQueues } from '@vercel/board/backend-a2/scheduler-vercel'
+import { postgres } from '@vercel/board/backend-a2/store-postgres'
+import { kapso } from '@vercel/board/sync-kapso'
+import { createKapsoAdapter } from '@kapso/chat-adapter'
+import { WhatsAppClient } from '@kapso/whatsapp-cloud-api'
+
+const client = new WhatsAppClient({
+  baseUrl: 'https://api.kapso.ai/meta/whatsapp',
+  kapsoApiKey: process.env.KAPSO_API_KEY!,
+})
+
+const backend = a2({
+  store: postgres({ connectionString: process.env.DATABASE_URL! }),
+  scheduler: vercelQueues({ topic: 'board' }),
+})
+
+const team = board({
+  backend,
+  sync: {
+    kapso: kapso({
+      adapter: createKapsoAdapter({ client }),
+      markRead: (input) => client.messages.markRead(input),
+      numbers: { '16315558151': 'support' },
+    }),
+  },
+})
+export const GET = team.fetch, POST = team.fetch
+export const { scheduler } = backend
+```
+
+Keys are phone number IDs as Kapso shows them, not the phone numbers themselves.
+A key that isn't one is skipped with a warning that says so.
+
+`markRead` is required at setup. The adapter only remembers messages whose webhook
+reached its own instance, so typing and read receipts go through this operation
+instead, which works from any serverless instance.
+
+| Thing | ID |
+| --- | --- |
+| A business number, the channel | `kapso:16315558151` |
+| A Kapso conversation, a thread | `kapso:16315558151:<WhatsApp ID>:<conversation ID>` |
+
+Kapso's adapter encodes each part of its IDs; the board writes them decoded, so
+targets and `vb inbox` read as above.
+
+## Conversations are threads
+
+WhatsApp has no threads, so a contact's messages group into Kapso's conversations.
+One starts when they write, and ends after a day of quiet or when someone closes it
+in Kapso. Writing again after that starts a new board thread.
+
+- **Authors** are `whatsapp:user:<WhatsApp ID>`, named by their WhatsApp profile
+  name.
+- **The board never starts a conversation.** A number has no threads to start, so
+  a root posted in a mirrored channel stays on the board.
+- **Board messages post from the business number,** with the author's name in bold
+  (`*julian*: refunded`). To post the text alone, pass
+  `render: ({ message }) => message.text`; see [render](./02-callbacks.md#render).
+
+## Reply within the window
+
+WhatsApp takes free-form messages only within 24 hours of the contact's last one.
+A board reply after that fails, and is recorded as `message.sync_failed`, which
+`vb read` shows under it:
+
+```text
+✗ didn't reach kapso:16315558151:51987654321:conv_123: <WhatsApp's error>
+```
+
+Templates aren't synced; send them with `@kapso/whatsapp-cloud-api`.
+
+## Reactions
+
+WhatsApp keeps one reaction per person per message. A contact's new reaction
+replaces their old one on the board, and removing it clears it. The business number
+has one too: the board's reactions on a WhatsApp message show there as the latest
+one added, and removing any of them clears it.
+
+## Media
+
+An image, video, voice note, or document becomes an attachment on the board,
+fetched through Kapso, with its caption as the text. A voice note's transcript is
+quoted under it when Kapso has one. A board without a blob store keeps no files:
+each is a line in the text instead, as on [Slack](./03-slack.md#files).
+
+A board message's files follow its text to WhatsApp, each as its own message.
+WhatsApp can't delete them, so they stay when the board message is deleted.
+
+## Typing
+
+```ts
+// in the route that mounts the board with its `sync`:
+await team.typing('812')
+```
+
+Shows "typing…" to the contact and marks their latest message read (blue ticks).
+WhatsApp shows no status text, so a status is ignored.
+
+## Route by function
+
+A function mapping receives every event for its number. Importing a message into a
+channel connects its conversation, so board replies in that thread reach the
+contact:
+
+```ts
+// in kapso({ numbers: { … } }):
+'16315558151': async ({ event, board }) => {
+  if (event.kind !== 'message') return
+  await board.sync('leads', event, { text: `${event.author.name}: ${event.text}` })
+},
+```
+
+See [callbacks](./02-callbacks.md) for the event and the overrides.
+
+## What doesn't sync
+
+- Edits and deletes, which WhatsApp can't do for recipients.
+- Button and list replies.
+
+## Setup
+
+1. In Kapso, create an API key and copy the number's phone number ID.
+2. Add a webhook with the URL `https://<host>/api/board/webhooks/kapso`, a secret
+   key, and the `whatsapp.message.received` event.
+3. Set `KAPSO_API_KEY` and `KAPSO_WEBHOOK_SECRET`, or pass `webhookSecret` to
+   `createKapsoAdapter`. Without the secret, the adapter rejects every webhook.
+
+The webhook path ends in the entry's key, so an entry keyed `kapso` listens at
+`/webhooks/kapso`.

package/docs/02-sync/06-providers.md

@@ -0,0 +1,228 @@
+---
+title: Custom providers
+description: Sync a platform board doesn't ship, natively or through any Chat SDK adapter.
+---
+
+## Two ways in
+
+| Import | Base class | Use it when |
+| --- | --- | --- |
+| `@vercel/board/sync` | `SyncProvider` | You talk to the platform yourself: its webhooks, its API. Importing it doesn't load Chat SDK. |
+| `@vercel/board/sync/chat` | `ChatSyncProvider` | A Chat SDK adapter already speaks the platform. Slack, GitHub, and WhatsApp are built this way. |
+
+Either way, a provider translates between the platform and the board, and the
+board does the rest: it validates and stores every incoming event before
+answering, orders imports per external thread and deliveries per board thread,
+retries, skips echoes, records copy and file receipts, and runs the default
+imports and your [callbacks](./02-callbacks.md). Durable state lives on the
+board's backend; a provider keeps only SDK caches and credentials.
+
+## A native provider
+
+```ts lib/desk.ts
+import { z } from 'zod'
+import {
+  SyncProvider,
+  envelope,
+  eventSchema,
+  type EventMapping,
+  type ProviderPost,
+  type Receive,
+  type ResolvedTarget,
+  type SyncContext,
+} from '@vercel/board/sync'
+
+export const DeskEvent = eventSchema('desk', 'message')
+export type DeskEvent = z.infer<typeof DeskEvent>
+
+type Delivery = {
+  delivery: string
+  inbox: string
+  ticket: string
+  message: string
+  text: string
+  user: { id: string; name: string }
+}
+
+export class DeskProvider extends SyncProvider<DeskEvent> {
+  private readonly secret: string
+
+  constructor(options: { secret: string; inboxes: Record<string, EventMapping<DeskEvent>> }) {
+    super({ platform: 'desk', canStartThreads: true })
+    this.secret = options.secret
+    for (const [inbox, mapping] of Object.entries(options.inboxes)) this.map(inbox, mapping)
+  }
+
+  override async receive(key: string, request: Request, emit: Receive): Promise<Response> {
+    // here's where you'd verify the platform's signature, before emitting anything:
+    if (request.headers.get('x-desk-secret') !== this.secret) return new Response('unauthorized', { status: 401 })
+    const body = (await request.json()) as Delivery
+    await emit({
+      dedupe: body.delivery,
+      raw: body,
+      event: {
+        kind: 'message',
+        channel: `${key}:${body.inbox}`,
+        thread: `${key}:${body.inbox}:${body.ticket}`,
+        subthread: null,
+        message: body.message,
+        text: body.text,
+        isRoot: false,
+        context: null,
+        author: { id: `desk:user:${body.user.id}`, handle: body.user.name, name: body.user.name, avatar: null, isBot: false },
+      },
+    })
+    return new Response('ok')
+  }
+
+  override async resolveChannel(key: string): Promise<string> {
+    return key
+  }
+
+  override async resolveTarget(target: string): Promise<ResolvedTarget> {
+    const [inbox, ticket] = target.split(':')
+    return { target, channel: inbox!, kind: ticket ? 'thread' : 'channel' }
+  }
+
+  override async post(target: string, kind: ResolvedTarget['kind'], body: ProviderPost) {
+    // your platform's API, e.g. a new ticket for a channel target, a reply for a thread:
+    // const sent = await desk.post(target, body.markdown)
+    const sent = { ticket: 't_812', message: 'm_1' }
+    return { thread: kind === 'channel' ? `${target}:${sent.ticket}` : target, message: sent.message }
+  }
+
+  override event(context: Pick<SyncContext, 'id' | 'key' | 'event' | 'raw'>): DeskEvent {
+    return DeskEvent.parse(envelope(this.platform, context.key, context.event, context.raw, context.id))
+  }
+}
+```
+
+Then use it like any built-in entry. Its webhook is `/webhooks/desk`:
+
+```ts
+// in board():
+sync: {
+  desk: new DeskProvider({ secret: process.env.DESK_SECRET!, inboxes: { support: 'support' } }),
+},
+```
+
+`this.map(key, mapping)` registers a mapping, so your provider takes the same
+string, function, and `{ channel, run }` values as the built-in ones.
+
+## The contract
+
+**Required methods:**
+
+| Method | Does |
+| --- | --- |
+| `receive(key, request, emit)` | Authenticates the request, then emits normalized `{ event, raw, dedupe }` records, and answers what the platform expects. |
+| `resolveChannel(key)` | Turns a mapping key (`'#prs'`, `'support'`) into the platform's channel ID. |
+| `resolveTarget(target)` | Turns a sync target into `{ target, channel, kind }`, where `kind` is `channel` or `thread`. |
+| `post(target, kind, body)` | Posts `body` (`{ markdown, files?, as? }`) and returns `{ thread, message, files? }`. |
+| `event(context)` | Builds the typed envelope your callbacks receive, usually `envelope(…)` parsed by an `eventSchema`. |
+
+**IDs.** Incoming locations (`channel`, `thread`, `subthread`) carry the entry's key
+as a prefix: `desk:support:t_812`. A `subthread` extends its `thread`'s ID
+(`desk:support:t_812:r_3` in `desk:support:t_812`), so `groupThread` returns a
+prefix of the ID it's given: the board refuses an import whose subthread isn't
+in its thread. Targets handed to `post`, `resolveTarget`, and the
+optional methods are native, without it: `support:t_812`. The board records each
+target's `kind` from `resolveTarget`, so it never parses your ID syntax, and a
+channel target on a provider whose `canStartThreads` is false is refused.
+
+**Dedupe.** `dedupe` is the identity of one occurrence. A platform redelivering the
+same event must produce the same value, so the retry does nothing; a later
+identical action (a reaction added, removed, and added again) must produce a new
+one. Use the platform's delivery or event ID.
+
+**Intake.** The board validates each record and stores it before your `receive`
+returns. Events for channels you don't map and threads that aren't synced are
+dropped. If storing fails, the webhook answers 500 so the platform retries.
+
+**Options** passed to `super()`:
+
+| Option | Default | Means |
+| --- | --- | --- |
+| `platform` | (required) | The platform's name, shown by `vb sources` and in author labels like `ada (desk)`. |
+| `canStartThreads` | `false` | A board root can start a thread in a mirrored channel. |
+| `singleReaction` | `false` | One reaction per person per message, as on WhatsApp. |
+| `uploadsFiles` | `false` | Files go to the platform with `uploadFiles`; otherwise each gets a line in the text. |
+| `render` | the label and text | The outgoing body; see [render](./02-callbacks.md#render). |
+| `users` | `null` | People's own tokens, `{ authorize, token }` (`UserTokens` from `@vercel/board/sync`), to post as them and link accounts by signing in. |
+
+## Optional methods
+
+Each has a default that does nothing, or says the platform can't:
+
+| Method | For |
+| --- | --- |
+| `edit(thread, message, body)`, `delete(thread, message)`, `react(thread, message, emoji, added)` | Changes to messages already delivered |
+| `startTyping(thread, latest, status?)` | `typing(id, status)` on the board that runs the entry |
+| `uploadFiles(thread, files)`, `deleteFiles(ids)`, `refusesFiles(error)` | Files out. `refusesFiles` tells a permanent refusal (notes instead) from a failure worth retrying |
+| `fetchFile(file)` | Files in |
+| `fetchRoot(thread)` | Recovering a root when a reply arrives in a thread the board hasn't seen |
+| `fetchLink(link)` | Reading a linked message the platform didn't describe |
+| `permalink(event)` | A callback's `permalink()`: the platform's own link to the event's message |
+| `whoAmI(token)`, `postAs(token, target, kind, body)`, `editAs(…)`, `deleteAs(…)` | Posting as a person, with `users` |
+| `read(target, { limit })` | A source read on the board that runs the entry: `readSource(key, target)`, `GET /sources/:key/read` |
+| `mention(actor)` | A board mention in the platform's native form |
+| `findByEmail(email)` | `@[ada@acme.com]` mentions |
+
+`sync(context, channel, overrides)` applies the default import and `render(input)`
+builds the outgoing body; override either in a subclass.
+
+## Through Chat SDK
+
+`ChatSyncProvider` bridges any Chat SDK adapter. It runs one Chat instance per
+entry, verifies webhooks through the adapter, turns its messages, edits, deletes,
+and reactions into records, and fetches files with the adapter's
+`rehydrateAttachment`:
+
+```ts lib/forum.ts
+import { z } from 'zod'
+import type { Adapter } from 'chat'
+import { envelope, eventSchema, type EventMapping, type ResolvedTarget, type SyncContext } from '@vercel/board/sync'
+import { ChatSyncProvider, type ChatInput } from '@vercel/board/sync/chat'
+
+export const ForumEvent = eventSchema('forum', 'message')
+export type ForumEvent = z.infer<typeof ForumEvent>
+
+export class ForumProvider extends ChatSyncProvider<ForumEvent> {
+  constructor(options: { adapter: Adapter; channels: Record<string, EventMapping<ForumEvent>> }) {
+    super({
+      platform: 'forum',
+      adapter: options.adapter,
+      canStartThreads: true,
+      resolveChannel: async (key) => key,
+      resolveTarget: async (target): Promise<ResolvedTarget> => {
+        const at = target.indexOf(':')
+        return { target, channel: at === -1 ? target : target.slice(0, at), kind: at === -1 ? 'channel' : 'thread' }
+      },
+    })
+    for (const [channel, mapping] of Object.entries(options.channels)) this.map(channel, mapping)
+  }
+
+  // A reaction has no stable identity in general: use the platform's ID for this occurrence.
+  override eventId(key: string, input: ChatInput): string {
+    if (input.kind !== 'reaction') return super.eventId(key, input)
+    return `reaction:${key}:${z.object({ id: z.string() }).parse(input.reaction.raw).id}`
+  }
+
+  override event(context: Pick<SyncContext, 'id' | 'key' | 'event' | 'raw'>): ForumEvent {
+    return ForumEvent.parse(envelope(this.platform, context.key, context.event, context.raw, context.id))
+  }
+}
+```
+
+`eventId(key, input)` supplies `dedupe`. The default covers messages, edits, and
+deletes; a provider that receives reactions must override it, since only the
+platform knows one reaction occurrence from the next.
+
+The constructor also takes hooks for what differs between platforms, among them:
+`groupThread` (which board thread an external thread belongs to, like GitHub's
+review threads), `channelOf`, `toChatId` and `fromChatId` (ID encodings),
+`markdown` and `author` (reading a message), `context`, `fetchRoot`, `links`,
+`read`, `uploadFiles`, `refusesFiles`, `startTyping`, and `intercept` and `missed`
+(webhook events the adapter doesn't emit). The built-in providers in
+`@vercel/board/sync-slack`, `@vercel/board/sync-github`, and `@vercel/board/sync-kapso` are
+working examples of each.