ab-ecosystem-cpass 1.0.0 → 1.0.6

package/docs/inbox/media.md

@@ -0,0 +1,202 @@
+# Inbox — media
+
+Images, video, audio, voice notes, stickers and documents in a live chat.
+
+Uploads do not pass through the API. A client describes the file, gets a presigned
+URL, and sends the bytes **straight to object storage** — so a 90 MB document
+costs the gateway a signature rather than 90 MB of transfer, and a stalled upload
+holds the browser's connection rather than one of ours.
+
+Storage is Wasabi, S3-compatible.
+
+## The short version
+
+```ts
+const link = await crm.inboxMedia.upload(file, { kind: 'image' });
+
+await inbox.messages.sendMedia({
+  channel: channelId,
+  contact: { id: chatId, identifier: '919000000000' },
+  kind: 'image',
+  link,
+  caption: 'Your order has shipped',
+});
+```
+
+Or in one call, if the `Inbox` was given an uploader:
+
+```ts
+const inbox = new Inbox({
+  url, clientId, token,
+  uploadMedia: crm.inboxMedia.upload.bind(crm.inboxMedia),
+});
+
+await inbox.messages.sendMedia({ channel, contact, kind: 'image', file, caption: 'Your order' });
+```
+
+A socket cannot presign — the ticket comes from the REST API — so `uploadMedia`
+is the seam between the two. It is a function rather than a client, so an app that
+only ever sends an already-uploaded `link` pulls in none of the REST surface.
+
+## What may be sent
+
+| Kind | Limit | Accepts |
+|---|---|---|
+| `image` | 5 MB | `image/jpeg` `image/png` `image/webp` |
+| `video` | 16 MB | `video/mp4` `video/3gpp` `video/quicktime` |
+| `audio` | 16 MB | `audio/aac` `audio/mp4` `audio/mpeg` `audio/amr` `audio/ogg` |
+| `voice` | 16 MB | same as `audio` |
+| `sticker` | 100 KB | `image/webp` |
+| `document` | 100 MB | anything a browser will not execute |
+
+These are WhatsApp's ceilings, checked when the upload is **requested** rather
+than when the message is sent. That is the only point where the answer is still
+useful: a file rejected here is one the agent can swap, while one that passes and
+then fails at the provider has already been uploaded, already drawn on screen, and
+comes back as a provider error against a bubble that looks sent.
+
+`text/html`, `image/svg+xml` and the JavaScript types are refused for every kind,
+`document` included. They would be served as live pages from the bucket's own
+origin.
+
+## upload
+
+```ts
+upload(file: Blob | UploadMediaSource, options: UploadMediaOptions): Promise<string>
+```
+
+Three steps in one call — ask for a ticket, `PUT` the bytes, return the link.
+
+| Option | Type | Required | Notes |
+|---|---|---|---|
+| `kind` | `MediaKind` | yes | Decides the size and type limits. |
+| `filename` | `string` | for a bare `Blob` | Overrides a `File`'s own name. |
+| `contentType` | `string` | for a bare `Blob` | Overrides a `File`'s own type. |
+| `signal` | `AbortSignal` | no | Cancels the transfer. |
+
+In Node there is no `File`, so describe the bytes:
+
+```ts
+const bytes = await readFile('invoice.pdf');
+
+const link = await crm.inboxMedia.upload(
+  { body: bytes, filename: 'invoice.pdf', contentType: 'application/pdf', size: bytes.byteLength },
+  { kind: 'document' },
+);
+```
+
+`size` must be the real byte length. It is signed into the URL, so a mismatch
+fails the upload rather than being silently corrected.
+
+### The returned link is permanent
+
+Only `upload_url` expires, and only if it is never used. The link itself does not,
+which is what lets a thread still render its media months later.
+
+Objects are `public-read` with an unguessable UUID key — the provider fetches the
+media by URL when the message is sent, and the inbox renders it from the stored
+link for the life of the conversation. **Anyone holding the URL can read the
+object**, so treat the link as the secret it is.
+
+## createUpload
+
+```ts
+createUpload(payload: CreateMediaUploadPayload): Promise<MediaUpload>
+```
+
+`POST /v1/audience/inbox/media/upload-url` — the ticket on its own, no bytes.
+Reach for this when you need the `key`, or when something other than this SDK
+performs the upload.
+
+| Field | Type | Notes |
+|---|---|---|
+| `kind` | `MediaKind` | |
+| `filename` | `string` | Only its extension and display name survive. |
+| `content_type` | `string` | Signed. Becomes the object's stored type. |
+| `size` | `number` | Signed. Exact byte length. |
+
+Answers:
+
+| Field | Notes |
+|---|---|
+| `upload_url` | `PUT` here. Expires in 15 minutes. |
+| `headers` | Send **exactly** these. One extra or missing header fails the signature. |
+| `link` | Where the object will be readable. Permanent. |
+| `key` | Path in the bucket: `inbox/<ownerId>/<yyyy>/<mm>/<uuid><ext>` |
+| `expires_at` / `expires_in` | When `upload_url` stops working. |
+
+Doing the `PUT` yourself:
+
+```ts
+const ticket = await crm.inboxMedia.createUpload({
+  kind: 'image', filename: 'order.jpg', content_type: 'image/jpeg', size: file.size,
+});
+
+await fetch(ticket.upload_url, { method: 'PUT', headers: ticket.headers, body: file });
+// ticket.link is now live
+```
+
+Send **no** authorization header on that `PUT`. The signature is the
+authorisation, and an extra header breaks it — besides handing your bearer token
+to a third party.
+
+### Your filename never becomes the key
+
+The key is always a UUID. Two agents sending `photo.jpg` would otherwise collide,
+with the second silently replacing the first inside a live conversation, and a
+name like `../../other` would escape the account's prefix. The name you gave is
+kept as the object's `Content-Disposition`, so a download still offers it.
+
+The owner id in the key comes from the verified token, never from the payload.
+
+## sendMedia
+
+```ts
+sendMedia(payload: SendMediaPayload): Promise<Message>
+```
+
+`message.send` · scope `messages:write`
+
+Assembles the content and sends it. Everything `send()` does applies — the reply
+is an optimistic echo with a queue id, and sending by hand pauses the chat's bot.
+See [messages.md](https://github.com/udghatan-dev/crm-sdk/blob/main/packages/sdk-js/docs/inbox/messages.md).
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `channel` | `string` | yes | |
+| `contact` | `{id, identifier}` | yes | |
+| `kind` | `MediaKind` | yes | |
+| `link` | `string` | one of | Already uploaded. Takes precedence over `file`. |
+| `file` | `MediaFile` | one of | Uploaded first. Needs `uploadMedia` on the Inbox. |
+| `caption` | `string` | no | Shown under the media. Ignored for a `sticker`. |
+| `filename` | `string` | no | What the recipient sees for a `document`. |
+| `context` | `JsonObject` | no | `{ message_id }` to reply to a specific message. |
+| `agent` | `string` | no | Needs `live_chat.send.AS_OTHER`. |
+
+What goes on the wire:
+
+```ts
+{ type: 'image',    image:    { link, caption } }
+{ type: 'document', document: { link, caption, filename } }
+{ type: 'sticker',  sticker:  { link } }
+```
+
+A caption belongs on the media object rather than beside it, and a sticker takes
+neither a caption nor a name — both are dropped rather than rejected.
+
+Set `filename` on a document: it is what the recipient sees in their chat, where a
+bare UUID would otherwise appear.
+
+## Errors
+
+| Status | Code | Means |
+|---|---|---|
+| 422 | `validation_failed` | Too large, or the type is not allowed for the kind. `details` names the field. |
+| 503 | `media_unavailable` | The deployment has no storage configured. Every other inbox action still works. |
+| — | `media_upload_failed` | The `PUT` to storage failed. Almost always the bytes not matching the declared `size` or `content_type`. |
+
+## Inbound media
+
+Media a contact sends arrives already downloaded, with a `link` under the content
+key. When that first download failed, `messages.retryDownload()` re-fetches it —
+inbound only, since an outbound attachment was ours to begin with.

package/docs/inbox/messages.md

@@ -0,0 +1,338 @@
+# Inbox — messages
+
+`inbox.messages.*` · see [connection.md](https://github.com/udghatan-dev/crm-sdk/blob/main/packages/sdk-js/docs/inbox/connection.md) first
+
+| Action | Event | Scope |
+|---|---|---|
+| `list` | `message.list` | `messages:read` |
+| `get` | `message.fetch` | `messages:read` |
+| `send` | `message.send` | `messages:write` |
+| `delete` | `message.delete` | `messages:write` |
+| `retryDownload` | `message.retry_download` | `messages:write` |
+
+## The message shape
+
+```ts
+interface Message<C extends MessageContent = MessageContent, X = JsonObject> {
+  id: string;
+  contact: string;
+  channel: string;              // id only: channels live in another service
+  content: C;                   // open; see below
+  context: X;                   // replied-to id, forwarding, CTWA referral
+  identifier: string;           // the contact's identity on this channel
+  message_id: string;           // the provider's id, unique per account
+  status: 'received' | 'sent' | 'delivered' | 'read' | 'failed';
+  timestamp: number;            // unix seconds, as the provider reported it
+  direction: 'inbound' | 'outbound';
+  source: 'contact' | 'agent' | 'bot' | 'campaign' | 'api' | 'business_app';
+  sent_by_api: boolean;
+  sent_by_biz_app: boolean;
+  sent_by_campaign: boolean;
+  sent_by_bot: boolean;
+  agent: string | null;
+  receipts: { sent; read; failed; replied; received; delivered };  // unix seconds, 0 = not yet
+  meta: { bookmarked: boolean; hide: boolean };
+  campaign: { id: string | null; cmid: number };
+  bot: { id: string | null; node: string };
+  error: string;
+  createdAt: string;
+  updatedAt: string;
+}
+```
+
+### direction and source are derived
+
+The stored document has no direction field: `received` is the only inbound state,
+and the sender is encoded as four booleans where an agent send is the *absence*
+of all of them. `direction` and `source` are computed for you so no consumer has
+to re-derive that. The raw flags are still there if you need them.
+
+| `status` | `sent_by_*` | `direction` | `source` |
+|---|---|---|---|
+| `received` | — | `inbound` | `contact` |
+| anything else | `sent_by_campaign` | `outbound` | `campaign` |
+| | `sent_by_bot` | `outbound` | `bot` |
+| | `sent_by_api` | `outbound` | `api` |
+| | `sent_by_biz_app` | `outbound` | `business_app` |
+| | none set | `outbound` | `agent` |
+
+### receipts are timestamps, not counts
+
+Each is the unix second at which the message reached that state, and `0` means it
+never did. `receipts.read` is the "seen at 10:42" a chat window renders.
+
+### content is open, on purpose
+
+This is a multi-channel platform. A WhatsApp interactive reply, an email part
+tree and an RCS card share no structure worth forcing into one schema, so
+`content` is whatever the channel says it is.
+
+One thing is promised: **`content.type` is always present**, and by convention the
+body for that kind sits under a key of the same name.
+
+```ts
+{ type: 'text',  text: { body: 'Hello' } }
+{ type: 'image', image: { id: '123', link: 'https://...', caption: 'Invoice' } }
+{ type: 'interactive', interactive: { type: 'button_reply', button_reply: { id, title } } }
+```
+
+That single field is what makes previews, renderer selection, filtering and
+narrowing possible. Everything else is yours.
+
+Narrow it where you know the channel:
+
+```ts
+type WhatsAppText = { type: 'text'; text: { body: string } };
+type WhatsAppImage = { type: 'image'; image: { id: string; link?: string; caption?: string } };
+
+const page = await inbox.messages.list<WhatsAppText | WhatsAppImage>(chatId);
+
+for (const message of page) {
+  if (message.content.type === 'text') render(message.content.text.body);
+}
+```
+
+Observed shapes are per channel kind and not normative — they are whatever the
+provider sent. Treat an unrecognised `content.type` as something to skip, not as
+an error.
+
+## list
+
+```ts
+const page = await inbox.messages.list(chatId, { limit: 20 });
+```
+
+`message.list` · scope `messages:read`
+
+| Field | Type | Required | Default | Notes |
+|---|---|---|---|---|
+| `id` | `string` | yes | — | Contact whose thread to read. |
+| `limit` | `number` | no | `20` | Max 100. |
+| `last_message_id` | `string` | no | — | The `id` of the oldest message you hold. |
+
+Returns **oldest-first**, ready to prepend above what you already have.
+
+Also **subscribes to the thread**: whatever arrives next lands on this socket
+without asking again.
+
+### Walking back through history
+
+```ts
+let oldest: string | undefined;
+const thread: Message[] = [];
+
+for (;;) {
+  const page = await inbox.messages.list(chatId, { limit: 50, last_message_id: oldest });
+  if (!page.length) break;
+
+  thread.unshift(...page);
+  oldest = page[0].id;      // oldest-first, so the first element is the cursor
+}
+```
+
+Paging is keyset on `(timestamp, id)`, which matches the ordering exactly. A
+message that arrives out of order — a redelivered webhook, a backdated provider
+timestamp — cannot be skipped or served twice.
+
+## get
+
+```ts
+const message = await inbox.messages.get('wamid.HBgM...');
+```
+
+`message.fetch` · scope `messages:read` · `404` if no such message for this account
+
+Takes the **provider id**, not the document id — that is what a webhook or a
+delivery receipt quotes.
+
+## send
+
+```ts
+const echo = await inbox.messages.send({
+  channel: channelId,
+  contact: { id: chatId, identifier: '919000000000' },
+  content: { type: 'text', text: { body: 'On it, checking now.' } },
+});
+```
+
+`message.send` · scope `messages:write`
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `channel` | `string` | yes | Channel to send over. |
+| `contact.id` | `string` | yes | |
+| `contact.identifier` | `string` | yes | The contact's identity on that channel. |
+| `content` | `MessageContent` | yes | Must carry `type`. Otherwise passed through. |
+| `context` | `JsonObject` | no | `{ message_id }` to reply to a specific message. |
+| `agent` | `string` | no | Attribute to another member. Needs `live_chat.send.AS_OTHER`, else `403`. |
+
+### What comes back is not the stored message
+
+The reply is an **echo** for drawing the bubble immediately. Its `message_id` is
+a queue id, not a provider id, and nothing has been written yet.
+
+The real row arrives moments later as a `message.received` push, carrying the
+provider's id. **Correlate on the queue id you got back here** — the final
+`message_id` is different by design:
+
+```ts
+const echo = await inbox.messages.send({ /* ... */ });
+draw(echo, { pending: true });
+
+const off = inbox.on('message.received', (message) => {
+  if (message.contact === chatId) replacePending(echo.id, message);
+});
+```
+
+Why: the provider's id is uniquely indexed, and it is not known until the
+provider answers. Writing a placeholder row first would mean a null id that the
+index refuses for every concurrent send.
+
+The echo goes to the sender only. Other agents see the message when the stored
+row is pushed, so nobody is shown a bubble that is about to be replaced.
+
+### The full lifecycle of one send
+
+| Step | What happens | What you can observe |
+|---|---|---|
+| 1 | `send()` validates, checks `AS_OTHER`, records the send | the echo, with a queue id |
+| 2 | The chat comes off its bot | `chat.action` / `pause_automation`, account-wide |
+| 3 | The send is handed to the service that holds provider credentials | — |
+| 4 | That service calls the provider and writes the row | `message.received` with the provider's `message_id` |
+| 5 | The provider reports delivery | `message.status`, once per state change |
+| 6 | The pause expires | `chat.action` / `resume_automation` |
+
+Step 3 is durable: the send is recorded before it is handed over, so a broker
+that is briefly away delays a message rather than losing it. A send is never
+dropped silently.
+
+### Delivery ticks
+
+`message.status` is a separate push from `message.received` so you can update the
+ticks in place without re-rendering the bubble:
+
+```ts
+inbox.on('message.status', (update) => {
+  setTicks(update.message_id, update.status);
+  if (update.status === 'failed') showError(update.message_id, update.error);
+});
+```
+
+| Field | Type | Notes |
+|---|---|---|
+| `message_id` | `string` | The provider's id — what the echo's queue id became. |
+| `status` | `MessageStatus` | `sent` `delivered` `read` `failed` `received` |
+| `receipts` | `Partial<MessageReceipts>` | Unix second each state was reached. |
+| `error` | `string` | Provider text, when `status` is `failed`. |
+
+### Sending takes the chat off its bot
+
+An agent replying by hand pauses automation. That arrives as a `chat.action` with
+`action: 'pause_automation'`, broadcast to the whole account — the automation
+badge has to change on every open inbox, not just the sender's.
+
+An already-paused chat keeps its original pause: re-stamping on every message
+would push the resume out indefinitely while an agent types.
+
+The pause lifts itself after `chat_metadata.pause_duration` seconds (an hour
+unless the chat says otherwise), and arrives as the matching
+`chat.action` / `resume_automation` — the same name and shape, so one handler
+covers both directions:
+
+```ts
+inbox.on('chat.action', ({ action, chat }) => {
+  if (action === 'pause_automation' || action === 'resume_automation') {
+    setAutomationBadge(chat.id, chat.bot?.pause === true);
+  }
+});
+```
+
+You do not have to call `resumeAutomation()` to end an agent-reply pause; that
+method is for lifting one early.
+
+### Media
+
+Use `sendMedia()` rather than assembling the content yourself — it uploads the
+file if you hand it one, and puts the caption and filename where the provider
+expects them. See
+[media.md](https://github.com/udghatan-dev/crm-sdk/blob/main/packages/sdk-js/docs/inbox/media.md).
+
+```ts
+const link = await crm.inboxMedia.upload(file, { kind: 'image' });
+await inbox.messages.sendMedia({ channel, contact, kind: 'image', link, caption: 'Your order' });
+```
+
+### Templates
+
+A template send carries parameters, not prose. Pass the approved definition
+alongside them and the echo comes back rendered — header and body variables
+substituted, dynamic button urls filled in:
+
+```ts
+await inbox.messages.send({
+  channel: channelId,
+  contact: { id: chatId, identifier: '919000000000' },
+  content: {
+    type: 'template',
+    template: {
+      name: 'order_update',
+      language: { code: 'en' },
+      components: [{ type: 'body', parameters: [{ text: 'Asha' }, { text: '4821' }] }],
+    },
+    json: approvedTemplate,    // from channels.templates.get()
+  },
+});
+```
+
+`json` (or `components`) is the approved template. Without it the echo carries the
+parameters unrendered — the send itself still works.
+
+Three fields are stripped from `template` before the provider sees it: `json`,
+`order`, and `isOrder`. They belong to the composer, not the message. Your own
+payload object is left untouched, so you can reuse it.
+
+## delete
+
+```ts
+await inbox.messages.delete(chatId, messageId);
+```
+
+`message.delete` · scope `messages:write` · `404` if not in that thread
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `id` | `string` | yes | Contact whose thread the message belongs to. |
+| `message_id` | `string` | yes | Either the document id or the provider id. |
+
+A **hard delete** — the row is gone. `meta.hide` exists for messages the UI
+should skip, and is not what this sets.
+
+Broadcast to everyone with the thread open: a message still rendered after it is
+gone is worse than a missing one.
+
+## retryDownload
+
+```ts
+const message = await inbox.messages.retryDownload(messageId);
+```
+
+`message.retry_download` · scope `messages:write`
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `message_id` | `string` | yes | The **document** id — a retry targets a stored row. |
+
+Re-fetches media whose first download failed, through the channels service, which
+owns the provider credentials. On success the stored link is replaced at
+`content.<type>.link` and the updated message is returned and broadcast to the
+thread.
+
+| Condition | Result |
+|---|---|
+| `content.type` not one of `image` `video` `audio` `document` `voice` `sticker` | `422` |
+| `status` is not `received` | `422` — an outbound attachment was ours to begin with |
+| no `content.<type>.id` | `422` — no provider media id to fetch |
+| the re-fetch declines | the message comes back unchanged, no error |
+
+A failed re-fetch is an outcome, not an error: the message keeps its broken link
+and the agent can ask again.

package/docs/inbox/referrals.md

@@ -0,0 +1,72 @@
+# Inbox — referrals (click-to-WhatsApp)
+
+Where a lead came from. When a contact opens a conversation by tapping a
+click-to-WhatsApp ad, the provider attaches the ad's referral payload to that
+first inbound message, and it is stored as a row of its own — one per contact per
+channel.
+
+`inbox.referrals(...)` · see [connection.md](https://github.com/udghatan-dev/crm-sdk/blob/main/packages/sdk-js/docs/inbox/connection.md) first
+
+| Action | Event | Scope |
+|---|---|---|
+| `referrals` | `ctwa.list` | `contacts:read` |
+
+## The shape
+
+```ts
+interface CtwaReferral {
+  id: string;
+  contact: string;
+  channel: string | null;
+  /** The provider's referral object, carried through untouched. */
+  payload: JsonObject;
+  createdAt: string;
+  updatedAt: string;
+}
+```
+
+`payload` is whatever the provider sent, unmodified. For WhatsApp that typically
+carries `source_id` (the ad id), `source_type`, `source_url`, `headline`, `body`,
+`media_type` and a thumbnail or video url. It is **not** normalised: read it
+defensively, and treat a missing key as a referral that did not include it.
+
+`payload.source_id` is the one key the platform itself relies on — it is what the
+`REFERRAL_ID` filter field matches against.
+
+## referrals
+
+```ts
+const referrals = await inbox.referrals(chatId);
+
+for (const { payload } of referrals) {
+  console.log(payload.headline, payload.source_url);
+}
+```
+
+`ctwa.list` · scope `contacts:read`
+
+| Field | Type | Required | Default | Notes |
+|---|---|---|---|---|
+| `id` | `string` | yes | — | Contact whose referrals to read. |
+| `limit` | `number` | no | `50` | Max 100. |
+
+Newest first. An empty array means the contact did not arrive through an ad, which
+is the normal case — not an error.
+
+## Filtering chats by ad
+
+`REFERRAL_ID` is a filter field available on the inbox chat list and **not** on
+the REST contact list: it resolves through this collection, which only the inbox
+reads.
+
+```ts
+const { contacts } = await inbox.chats.list({
+  conditions: [
+    { field_id: 'REFERRAL_ID', field_type: 'string', condition: 'equal to', value: '120210000000', operator: null },
+  ],
+});
+```
+
+The condition is membership, whatever comparison you name: a row holds exactly
+one `source_id`, so there is nothing to compare but whether a contact came from
+that ad.

package/docs/inbox/sessions.md

@@ -0,0 +1,74 @@
+# Inbox — chat sessions
+
+Whether you can still reply freely.
+
+Providers only allow unprompted messages inside a window from the contact's last
+inbound message — 24 hours for WhatsApp. Outside it, a free-form message is
+refused and the conversation has to restart from an approved template.
+
+A contact reachable on several channels has **one window per channel**, which is
+why these are rows of their own rather than the single `last_seen` the chat
+carries.
+
+`inbox.sessions(...)` · see [connection.md](https://github.com/udghatan-dev/crm-sdk/blob/main/packages/sdk-js/docs/inbox/connection.md) first
+
+| Action | Event | Scope |
+|---|---|---|
+| `sessions` | `chat_session.list` | `contacts:read` |
+
+## The shape
+
+```ts
+interface ChatSession {
+  id: string;
+  channel: string;
+  /** Unix seconds of the last inbound message on this channel. */
+  last_seen: number;
+}
+```
+
+## sessions
+
+```ts
+const sessions = await inbox.sessions(chatId);
+```
+
+`chat_session.list` · scope `contacts:read`
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| `id` | `string` | yes | Contact whose sessions to read. |
+| `channel` | `string` | no | Narrow to one channel. Omitted, every channel the contact has used. |
+
+Ordered by `last_seen` descending, so the channel the contact used most recently
+comes first. A channel with no row has never had an inbound message — its window
+was never open.
+
+## Working out whether a window is open
+
+```ts
+const WINDOW = 24 * 60 * 60;  // seconds
+
+const sessions = await inbox.sessions(chatId);
+const now = Math.floor(Date.now() / 1000);
+
+const open = sessions.filter((session) => now - session.last_seen < WINDOW);
+
+if (!open.length) {
+  // every window has lapsed: send a template, not free text
+}
+```
+
+The same window drives the chat list's `session` filter, so
+`chats.list({ filter: { session: 'active' } })` is the set of chats you can reply
+to right now:
+
+```ts
+const { contacts } = await inbox.chats.list({
+  filter: { session: 'active', assignment: 'me' },
+});
+```
+
+Note that filter reads the chat's own `last_seen` — the most recent inbound
+message across every channel — so it answers "is any window open". Read the
+sessions themselves when you need to know *which* channel is still replyable.