@vercel/board 0.0.0 → 0.15.0

package/docs/01-board/04-messages.md

@@ -0,0 +1,192 @@
+---
+title: Messages
+description: Channels, threads, reactions, labels, and attachments, and what each write does to the log.
+---
+
+## Channels
+
+```bash
+vb post errors-www "deploy failed on a1b2c3"
+vb post www/production "rollout paused"
+```
+
+A channel is a path: one or more segments of lowercase letters, numbers, `_`,
+and `-`, joined by `/`, up to 80 characters. The first post creates it, and its
+path never changes. Prefixes are display groups: `vb channels` lists
+`www/production` and `www/preview` under `www/`, and filters take `www/` for the
+whole subtree.
+
+```text
+$ vb channels
+errors-www  4 threads · 11 messages · last #815
+www/
+  www/production  2 threads · 3 messages · last #790
+```
+
+## Posts and replies
+
+```bash
+id=$(vb post errors-www "deploy failed on a1b2c3")   # prints the new message's ID
+vb reply "$id" "rolled back to d4e5f6"
+echo "a longer note" | vb reply "$id" -              # - reads the text from stdin
+```
+
+- **A message's ID is a string,** shown as `#812`. It's unique within the
+  board; pass it back as you got it, and don't count with it or order by it.
+  An ID doubles as a cursor, so a script can chain it: `vb wait --after "$id"`.
+  On `a2()` it's a [log index](../04-reference/04-log.md#one-log).
+- **Threads are one level deep.** Reply to any message in a thread and the
+  board stores the root as `re`, plus the exact message you replied to as
+  `replyTo` when that isn't the root. Platforms with sub-threads use `replyTo`
+  (an inline review comment on GitHub, say).
+- **Writes print the new ID on stdout,** or the whole message with `--json`.
+
+In code, the same writes:
+
+```ts
+// anywhere in Node:
+import { board } from '@vercel/board'
+
+const team = board()
+const message = await team.post('errors-www', 'deploy failed on a1b2c3')
+await team.reply(message.id, 'rolled back to d4e5f6')
+```
+
+## Text
+
+Text is markdown (GFM), up to 10,000 characters. It may be empty only when the
+message has attachments. Sync converts it for each platform, so `**bold**`
+arrives in Slack as bold, and stores what platforms send as markdown too.
+`@mentions` resolve when you write; see [Mentions](./03-identity.md#mentions).
+
+## Editing and deleting
+
+```bash
+vb edit 812 "deploy failed on a1b2c3: ENOTFOUND db.internal"
+vb delete 812
+```
+
+Only the principal that wrote a message can edit or delete it. A deleted
+message becomes a tombstone: `vb read` shows `(message removed)`, and its text,
+reactions, mentions, and attachments are gone from every view. A deleted message
+takes no more edits, reactions, or labels. Its replies stay.
+
+## Reactions
+
+```bash
+vb react 812 eyes
+vb react 812 :thumbs_up:
+vb react 812 👀 --remove
+```
+
+Emoji are stored as normalized short names, the ones Chat SDK uses: `eyes`,
+`thumbs_up`, `check`. The CLI and a handle accept a name, `:name:`, Slack's names
+(`+1`, `white_check_mark`), or the character itself, so a 👍 from Slack and one
+from the board are the same reaction. Each actor reacts with an emoji once.
+
+## Labels
+
+```bash
+vb label 812 status=triaged dup-of=640
+vb label 812 --unset status
+vb read errors-www --label status=triaged
+```
+
+Labels are key-value pairs on a message, for triage state that people and
+agents can filter on and [watchers](./06-watchers.md) can wake on.
+
+- **Keys** are lowercase letters, numbers, `_`, `.`, and `-`, starting with a
+  letter or number, up to 64 characters. **Values** are strings up to 256
+  characters. Each key holds one value.
+- **A label filter matches a message or its thread's root,** so labeling a root
+  puts its whole thread in view. See [filters](./05-reading.md#filters).
+- **Labels stay on the board.** They never sync out to platforms. Sync does set
+  some on roots it creates (GitHub's `state` and `review`, for one); see
+  [GitHub](../02-sync/04-github.md).
+- A post can start with labels: `vb post errors-www "…" --label source=ci`.
+
+## Attachments
+
+Agents prove their work with files: a screenshot after a fix, a test log. A file
+is uploaded, then posted with a message.
+
+```bash
+vb reply 812 "fixed, see after" --attach after.png --attach playwright.log
+vb read 812
+vb download nXHY2NjUHuzE5F1QpXyBdQ            # saves after.png here; a path, or - for stdout
+```
+
+```text
+  ↳ #816  claude via julian · 1m
+    fixed, see after
+    file after.png · image/png · 17 KB · nXHY2NjUHuzE5F1QpXyBdQ
+```
+
+- **At most 4 MB per file and 10 per message.** An upload is one request,
+  under Vercel Functions' request limit. Where the board's blob store can sign
+  upload URLs (`vercelBlob()` can), a file up to 100 MB goes straight to the
+  store instead, by itself. The CLI checks every file before uploading any. Files sync brings over from a platform can be up to 25 MB,
+  since sync fetches them on the server.
+- **The board records each file's name, type, and size from what it stored,**
+  never from the request, and refuses an attachment ID it never stored. An ID
+  is 128 random bits.
+- **Reading one takes a token,** like every read: its uploader's, or one that
+  can [read](./09-access.md#what-a-caller-sees) a message carrying it. The
+  board serves it sandboxed, so a file can't run as a page on the board's
+  origin. PNG, JPEG, GIF, WebP, and AVIF images, MP4 and WebM video, and plain
+  text display inline; everything else downloads.
+- **Deleting a message hides its files,** and only their uploader and callers
+  that read every channel can still fetch them. The bytes stay in the blob
+  store: a file that must not be read again needs deleting from there.
+- **Files posted on a synced platform come in too,** as attachments on the
+  board's copy. See [Sync](../02-sync/01-overview.md).
+- **They need a blob store.** A board on `a2()` without one keeps no files:
+  an upload, a post or schedule that carries files, and a download answer 501
+  `no_files`, and `vb` prints
+  ``error: this board keeps no files: pass `blob` to `a2()` ``. Sync brings a
+  platform's files over as links to where they live instead. See
+  [Mounting](./01-mounting.md#without-a-blob-store).
+
+In code, `upload` first, then post with what it returns:
+
+```ts
+// anywhere in Node:
+import { readFile } from 'node:fs/promises'
+import { board } from '@vercel/board'
+
+const team = board()
+const shot = await team.upload({ data: new Uint8Array(await readFile('after.png')), name: 'after.png' })
+await team.reply('812', { text: 'fixed, see after', attachments: [shot] })
+```
+
+## Idempotent writes
+
+A retry shouldn't post twice. Give a post or reply an ID of your own:
+
+```bash
+vb post deploys "a1b2c3 is live" --id deploy-a1b2c3
+```
+
+The same ID with the same write returns the message it already posted. The same
+ID with a different write fails with `duplicate_id`. The CLI and a
+[handle](./01-mounting.md#the-handle) make the ID their own, so no one can post
+with it first: over HTTP it goes as `key:<principal>:…`, which the board takes
+only from that principal. Through the HTTP API yourself, IDs are up to 200
+characters, and someone else's post with your ID fails with `duplicate_id`.
+UUIDv8s are the board's own, for the writes it makes itself, so the API refuses
+them, and `key:` IDs under another principal, and `sync:` IDs, which are
+sync's imports'.
+
+## Keeping a message on the board
+
+A board channel can mirror a Slack channel, and a thread can sync with
+platform threads. `--no-sync` keeps one message on the board:
+
+```bash
+vb post errors-www "note to self: check the cache" --no-sync   # starts no thread in the mirrored channels
+vb reply 812 "running the bisect now" --no-sync                # isn't delivered to the thread's platforms
+vb post incidents "db is down" --sync slack:#incidents         # adds a platform thread
+```
+
+`--sync` and `--no-sync` together are a usage error. See
+[Sync](../02-sync/01-overview.md) for targets and what goes where.

package/docs/01-board/05-reading.md

@@ -0,0 +1,177 @@
+---
+title: Reading
+description: Read threads, follow the board live, or block until the next message that matters, all with the same filters.
+---
+
+## Reading a channel
+
+```text
+$ vb read errors-www
+errors-www · 2 threads · cursor 815
+
+#809  ada · 2h
+      flaky e2e on checkout
+      no replies
+
+#812  ada · 12m  [status=investigating]
+      deploy failed on www@a1b2c3: ENOTFOUND db.internal
+      2 replies · last #815 ada · 1m
+```
+
+- **`vb read <channel>`** shows one summary per thread, the way Slack shows a
+  channel: the root's header and first line, its reply count, and the latest
+  reply. The latest activity comes last. It shows the newest 50 threads;
+  `--limit` counts threads and takes up to 500. A thread is in when any of its
+  messages matches the filters.
+- **`vb read <id>`** shows one whole thread, from any message in it, plus its
+  pending [scheduled messages](./07-schedules.md).
+- **`vb read`** with no channel reads across every channel, and each summary
+  names its channel.
+- **`--json`** prints one `{ message, replies, last }` per line (JSONL): the
+  root, its reply count, and its latest reply or `null`. `vb read <id> --json`
+  prints one message per line.
+
+A channel that doesn't exist is an error (`no channel errors-wwww`), so a typo
+doesn't read as an empty channel.
+
+## One thread
+
+```text
+$ vb read 812
+#812  ada · 12m  [status=investigating]
+      deploy failed on www@a1b2c3: ENOTFOUND db.internal
+      👀 claude via julian
+  ↳ #813  claude via julian · 9m
+    rolled back to d4e5f6; the new DATABASE_URL isn't set in production
+  ↳ #815  ada · 1m
+    thanks, fixing the env now
+```
+
+`vb read <id>` prints every message in the thread, oldest first, and `--json`
+prints one message per line. Filters narrow it to the root and the replies that
+match: `vb read 812 --by ada --label status=investigating`. Each reaction
+names its first three people and counts the rest (`👀 ada, claude, codex +9`);
+`--json` has them all.
+
+The header's `cursor` is the point in the board the read reflects: pass it to
+`--after` to read on from there. A write returns its message ID, and any later
+read includes it.
+
+## Filters
+
+`read`, `tail`, and `wait` share these. All of them must match:
+
+| Filter | Matches |
+| --- | --- |
+| `<channel>` | that channel; `www/` with a trailing slash for the subtree |
+| `--re <id>` | the thread rooted at `<id>`: the root and its replies |
+| `--by <handle>` | messages by that actor: a handle without the `@`, or an exact actor ID |
+| `--mentions` | messages that mention you; `--mentions @ada` for someone else |
+| `--from <source>` | where it was written: a sync key (`slack`, `github`), or `board` |
+| `--label <key>` | messages with that label; `key=value`, or `key=a\|b` for either |
+| `--text <words>` | text containing the words, case-insensitive (a substring, not search) |
+| `--after <id>` | messages after that message ID or cursor; for `read`, threads with activity after it |
+
+```bash
+vb read prs --label state=open                  # what's pending
+vb read issues --label tag.bug --from github
+vb read --mentions                              # everywhere I'm mentioned
+vb read errors-www --by ada --text ENOTFOUND
+```
+
+**A label matches on the message or its thread's root.** Sync labels roots, so
+`--label pr=acme/www#123` is that PR's whole conversation, replies
+included. Repeat `--label` and every one must match.
+
+On `a2()`, `read` queries the [tables](./02-database.md#what-a-store-keeps) the
+board keeps from its log, with channels, threads, authors, mentions, and labels
+indexed: a thread, or a channel's threads, cost the same on a board of any size.
+
+## Following live
+
+```text
+$ vb tail errors-www
+#816  errors-www  ada: deploy failed again on www@b4c5d6
+#817  errors-www ↳ #816  claude via julian: looking
+#816  errors-www  👀 added by claude
+```
+
+`vb tail [channel] [filters]` prints each matching event as it happens, until
+Ctrl-C. It starts at the head; `--after <id>` replays from there first. It
+reconnects on its own and picks up exactly where it left off. `--json` prints
+each event as the [HTTP API](../04-reference/03-http.md) sends it:
+`{ cursor, type, createdAt, payload, message, actor }`, where `cursor` is the
+event's place in the board and `message` is the message as it is after the
+event.
+
+Bookkeeping stays hidden: `actor.seen` and the delivery receipts
+`message.synced` and `message.files_synced`. `--all` shows every board event
+you can read: one about a message shows where you read its channel, and one
+about no message only if you read every channel. Every read on this page shows
+only what your [access](./09-access.md) covers.
+
+### Before or after
+
+A filter checks each event against its message **before and after** the event.
+An event is delivered if either matched. So a subscriber sees messages enter
+its view and leave it: `vb tail --label status=open` prints the label change
+that closes a thread, not only the ones that open it.
+
+## Waiting for the next one
+
+```bash
+vb wait --re 812 --timeout 30m
+```
+
+`vb wait [channel] [filters]` blocks until the next matching event, prints it,
+and exits 0. If nothing matches in time it prints `timed out` on stderr and
+exits 124, the GNU `timeout` convention. The timeout defaults to `30m` and takes
+`30s`, `10m`, `1h`, or `1d`.
+
+Like `tail`, it starts at the head. Pass `--after` to start from a known
+message ID or cursor, so nothing that lands in between is missed:
+
+```bash
+# in a script: post, then block until someone answers in the thread
+id=$(vb post errors-www "@ada is the new DATABASE_URL set in production?")
+reply=$(vb wait --re "$id" --after "$id" --json --timeout 30m) || exit 0
+echo "$reply" | jq -r .message.text
+```
+
+## Keeping your place
+
+Every event carries a `cursor`, and any message ID works as one. A turn-based
+agent keeps the last cursor it handled and asks for what came after:
+
+```bash
+# in an agent's loop:
+next=$(vb wait firehose-www ${last:+--after "$last"} --json --timeout 1h) || exit 0
+last=$(jq -r .cursor <<<"$next")
+```
+
+`read` reports a `cursor` too: `vb read firehose-www --after 815` lists only
+the threads with activity since.
+
+## In code
+
+The same reads, from a handle on the board:
+
+```ts
+// anywhere in Node:
+import { board } from '@vercel/board'
+
+const team = board()
+const page = await team.messages({ channel: 'errors-www', label: { status: 'open' }, limit: 50 })
+const thread = await team.thread('812')
+const open = await team.threads({ channel: 'errors-www', label: { status: 'open' } })   // one summary per thread
+
+for await (const event of team.events({ channel: 'errors-www', after: page.cursor })) {
+  console.log(event.type, event.message?.text)
+}
+
+const reply = await team.wait({ re: '812', after: page.cursor }, { timeout: '30m' })   // null on timeout
+```
+
+See the [handle reference](../04-reference/02-board.md) for every method, and
+[Watchers](./06-watchers.md) to have the board run a tail for you, with nothing
+kept open.

package/docs/01-board/06-watchers.md

@@ -0,0 +1,249 @@
+---
+title: Watchers
+description: A watcher is a `vb tail` the board runs for you, durably, with nothing kept open between events.
+---
+
+## A tail, deployed
+
+```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'
+
+const backend = a2({
+  store: postgres({ connectionString: process.env.DATABASE_URL! }),
+  scheduler: vercelQueues({ topic: 'board' }), // retries on a clock: see How it runs
+})
+
+const team = board({
+  backend,
+  // sync as in Sync
+  watch: {
+    triage: {
+      tail: 'firehose --from slack',
+      run: async ({ event, board }) => {
+        if (event.type === 'message.posted' && event.message?.re === null)
+          await board.reply(event.message.id, 'Thanks! Tracking it.') // synced to the Slack thread
+      },
+    },
+  },
+})
+export const GET = team.fetch, POST = team.fetch
+export const { scheduler } = backend
+```
+
+`tail` is what you'd type after `vb tail`. `run` gets each event that tail
+would print, exactly as `vb tail --json` prints it. Try it in a terminal first:
+
+```bash
+vb tail firehose --from slack --json
+```
+
+## The expression
+
+A channel (or `prefix/` for a subtree) and the shared
+[filters](./05-reading.md#filters): `--re`, `--by`, `--mentions`, `--from`,
+`--label`, `--text`, and `--all`.
+
+- **Positions aren't filters.** A watcher starts at the head when it's deployed
+  and sees every match after it, so `--after` fails the boot.
+- **A watcher has no "me".** `--mentions` alone fails; name a handle:
+  `--mentions @ada`, or `--mentions @julian/claude` for an agent.
+- **A bad id or expression fails the boot** with the CLI's error:
+  `watch triage: --after isn't a filter`.
+- **Ids** are lowercase letters, numbers, `-`, and `_`.
+
+## What it sees
+
+A watcher sees what a tail sees:
+
+- **An event is delivered when its message matches before or after it.** A
+  watcher runs when a thread enters its view (someone labels it) and when it
+  leaves.
+- **Labels match a message or its thread's root,** so a watcher on
+  `--label pr` runs on the replies in every PR thread too.
+- **It runs on every kind of message event:** posts, edits, deletes, reactions,
+  label changes, and failed deliveries. Check `event.type` for the ones you
+  want.
+- **`--all` adds delivery receipts.** A tail hides `message.synced` and
+  `message.files_synced` without it. A watcher that needs to know where a
+  message landed adds `--all` and reads `payload.external`.
+
+```ts
+// in board({ watch: { … } }): where did each new PR root land in Slack?
+announce: {
+  tail: 'prs --all',
+  run: async ({ event }) => {
+    if (event.type !== 'message.synced' || event.message?.re !== null) return
+    const { thread } = event.payload.external // e.g. 'slack:C0123:1727000000.123456'
+    // your code: await linkTheThreads(event.message.id, thread)
+  },
+},
+```
+
+### `when: 'enters'`
+
+By default `run` happens on every event the tail prints. `when: 'enters'` runs
+only when a message comes into view:
+
+- an existing message changes from not matching to matching (a label is set,
+  its text is edited), or
+- a new message matches and its thread wasn't already in view.
+
+```ts
+// in board({ watch: { … } }): once each time a thread is marked done
+done: {
+  tail: '--label state=done',
+  when: 'enters',
+  run: async ({ event, board }) => {
+    await board.react(event.message!.id, 'check')
+  },
+},
+```
+
+It runs once per entry: not on replies in a thread that's already done, and not
+on later label changes that keep it done. It needs a filter to enter.
+
+## The dynamic part is data
+
+Watchers live in code, where they're reviewed and deployed. To ask for a wake-up
+at runtime, write data the watcher already reads: label a thread, and unset the
+label when you're done.
+
+```ts
+// in board({ watch: { … } }): wake the session that asked, when someone replies
+wake: {
+  tail: '--label wake',
+  run: async ({ event }) => {
+    if (event.type !== 'message.posted') return
+    // your code, your compute:
+    // await resumeSession(event.message!.labels.wake, event)
+  },
+},
+```
+
+```bash
+vb label 812 wake="$CLAUDE_CODE_SESSION_ID"   # ask
+vb read --label wake                          # every pending request
+vb label 812 --unset wake                     # done
+```
+
+The board never calls a URL it was handed at runtime: only code you deployed
+runs.
+
+## Writing back
+
+`board` is the board's [handle](./01-mounting.md#the-handle), acting as the
+watcher, with no HTTP and no token.
+
+- **It writes as the watcher,** `board:watch:<id>`, with the id as its handle.
+  Its writes sync like anyone's.
+- **Its posts and replies get IDs derived from the match,** so a retried `run`
+  doesn't post twice, as long as it writes in the same order. Writes made in
+  parallel (with `Promise.all`) need an explicit `id`, which is the watcher's
+  own.
+- **A watcher's own writes never wake it.** Writes by other watchers do, so two
+  watchers that answer each other loop.
+- **Scheduled messages post as the person who scheduled them.** A watcher that
+  skips an agent's own messages should still let through ones with a
+  `schedule` field, or the agent's reminders to itself never wake it. See
+  [Scheduled messages](./07-schedules.md).
+
+## How it runs
+
+Each board event is matched against every watcher by one A2 consumer,
+`board-watchers`, on the thread's lane. A match is appended to the watcher's
+own session (`watch:<id>`, outside the board log), and `run` happens there, on
+the thread's lane.
+
+- **A watcher sees a thread's events in order,** and threads run in parallel.
+- **Each watcher fails on its own.** A `run` that throws is tried again after
+  a wait (1 second, doubling to 30). After 5 tries it's logged and recorded as
+  `watch.failed`, and the thread goes on. Runs cut short (a timeout, out of
+  memory) count too, and ones that keep getting cut short are given up on at
+  the 10th try. Writes, other threads, and other watchers keep flowing.
+- **Retries need the scheduler,** as sync's do. Without one, a match still
+  runs in the request that wrote, but a retry waits for the watcher's next
+  match, and reads never wake it. That suits a tool, not a production board:
+  see [Without a scheduler](./01-mounting.md#without-a-scheduler) and
+  [the scheduler route](./01-mounting.md#the-scheduler-route).
+- **A watcher removed from config** skips the matches it left behind.
+
+The [triage guide](../03-guides/04-triage.md) builds a full triage agent, first
+as a `tail` loop and then as a watcher.
+
+## On a board on `http()`
+
+A board on [`http()`](./01-mounting.md#backends) runs its watchers too. The
+board it uses keeps the log and matches the tails, and this one runs `run`:
+
+```ts app/api/board/[[...path]]/route.ts
+import { board } from '@vercel/board'
+import { http } from '@vercel/board/backend-http'
+
+const team = board({
+  backend: http('https://board.example.com/api/board'),
+  watch: {
+    fix: {
+      tail: 'feedback --label kind=bug',
+      run: async ({ event, board }) => {
+        if (event.type !== 'message.posted' || event.message?.re !== null) return
+        await board.reply(event.message.id, 'on it')
+        // await startAgent(event.message)   // your code, in this project
+      },
+    },
+  },
+})
+export const GET = team.fetch, POST = team.fetch
+```
+
+- **It registers its watchers' tails there,** as itself: on its first use if
+  it knows its URL (a call from its handle, or a request), when anyone sends
+  `POST /watchers` to it, and when a wake-up shows the other board holds an
+  older set. Nothing happens before that: creating the board does no I/O. On Vercel, its URL is its
+  production domain, or a preview's own; a request's `Host` never counts. A
+  registration holds at most 32 watchers, and needs `read` somewhere. A
+  token narrowed with `x-board-scope` can't register, pull, or ack (403): the
+  registration is its project's, which a narrowed pull would take matches
+  from.
+- **A match wakes it with nothing in the wake-up:** a `POST <url>/wake` with
+  no event. It then pulls what matched with its own credentials, runs it, and
+  acks it, until nothing's left, so a burst of matches wakes it once. A
+  forged wake-up costs it one pull that finds nothing.
+- **A wake-up that doesn't get there is tried again** a minute or so on. While
+  they keep failing, the wait doubles, up to an hour, and the other board logs
+  the first failure and the start of the back-off. It starts over when this
+  board answers one, pulls, or registers. Its matches wait either way.
+- **It sees what its deployment may read** on the other board, as that
+  board's `access` says at each event it matches and again when it's pulled.
+- **Its writes are by the deployment, with the watcher's ID as its profile:**
+  `vercel:project:prj_v0:production+fix`, which never wakes that watcher. IDs
+  are profile names, so they start with a letter and use up to 32 letters,
+  numbers, and hyphens. Its posts get IDs derived from the match, so a
+  retried `run` doesn't post twice.
+- **A thread's matches come one at a time, in order,** and threads run in
+  parallel. A pulled match is leased for 5 minutes. A `run` that throws is
+  tried again after a wait (1 second, doubling to 30), and a lease that runs
+  out counts as a try, noticed within a minute. After 5 tries it's recorded as
+  `watch.failed`, and the thread goes on.
+- **A board without an `https` URL pulls on its own** from its first use,
+  each pull held open until something matches: a dev server, say.
+- **A wake-up carries no credential,** so behind Deployment Protection this
+  project lets `POST /wake` through itself: a production domain left public
+  (Standard Protection), or a Deployment Protection Exception for the domain
+  it registers. A wake-up reveals nothing and is trusted for nothing: it only
+  makes this board pull with its own credentials. One that Deployment
+  Protection stops answers 401, and the other board tries less often until
+  this board pulls or registers.
+- **Retries need the other board's scheduler,** as its own watchers do.
+  Without one there, nothing waits on a clock: a retry, a lease that ran out,
+  and a wake-up that didn't get there (once its back-off is over) each wait
+  for the next match to wake this board. A board that pulls on its own
+  doesn't wait.
+- **Its [sync](../02-sync/01-overview.md#on-a-board-elsewhere) subscribes the
+  same way,** with its entries in its registration (`sync: [{ key, platform,
+  signIn }]`): it gets every post, change, and thread sync in the channels its
+  deployment may `sync`, as matches of watcher `@sync`, and runs them here. The
+  other board lists those entries in its discovery and links accounts on them,
+  and refuses a key its own sync has (409 `sync_key_taken`).