@whooshbang/contracts 2.2.0 → 2.4.0

package/schemas/whooshbang-v1.schema.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json-schema.org/draft/2020-12/schema",
   "$id": "https://whooshbang.flowxo.com/schemas/whooshbang-v1.schema.json",
-  "x-contract-version": "2.2.0",
+  "x-contract-version": "2.4.0",
   "title": "WhooshBangV1ContractDocument",
   "description": "Public request, resource, summary, and Problem Details models for the WhooshBang V1 REST API.",
   "anyOf": [
@@ -445,7 +445,7 @@
       "type": "integer",
       "minimum": 1,
       "maximum": 50000,
-      "description": "A 1-based page number. Present on a response only when the request addressed the list by page rather than by cursor: a cursor walk cannot know which page it is on. What is bounded is the row a page starts at, not the page number: a request whose first row would be past 50,000 — the deepest row any published list ceiling reaches — is refused as `request_invalid`. Bounding the page number instead would make the last rows of a large list unreachable at a small page size, which is exactly when a person is paging through one."
+      "description": "A 1-based page number. Present on a response only when the request addressed the list by page rather than by cursor: a cursor walk cannot know which page it is on. What is bounded is the row a page starts at, not the page number: a request whose first row would be past 50,000 \u2014 the deepest row any published list ceiling reaches \u2014 is refused as `request_invalid`. Bounding the page number instead would make the last rows of a large list unreachable at a small page size, which is exactly when a person is paging through one."
     },
     "ListPageSize": {
       "type": "integer",
@@ -457,7 +457,7 @@
       "type": "string",
       "minLength": 1,
       "maxLength": 128,
-      "pattern": "^[^\u0000-\u001f-Ÿ

]+$",
+      "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$",
       "description": "An opaque identifier. Its shape, ordering, and embedded content are not public promises."
     },
     "DiagnosticId": {
@@ -1907,7 +1907,7 @@
         "connections:write",
         "connections:read"
       ],
-      "description": "One project-credential capability. Environment authority always comes from the credential record, never a scope or request field. `projects:write` configures the credential's own project and environment; it never creates a project, which remains an organization authority. The project-wide singletons — brand, default locale, logo and recipient copy — are what a live recipient sees, so writing them requires a live credential; a test credential may read them and may write its own environment's policy."
+      "description": "One project-credential capability. Environment authority always comes from the credential record, never a scope or request field. `projects:write` configures the credential's own project and environment; it never creates a project, which remains an organization authority. The project-wide singletons \u2014 brand, default locale, logo and recipient copy \u2014 are what a live recipient sees, so writing them requires a live credential; a test credential may read them and may write its own environment's policy."
     },
     "ApiCredentialScopeSet": {
       "type": "array",
@@ -2123,7 +2123,7 @@
         "connections:write",
         "connections:read"
       ],
-      "description": "One organization-credential capability. `organization:read` is the organization's project directory — listing the organization's projects and reading one — and is the only scope here a project credential can never carry; it authorizes nothing below the organization. Every other name is the project-credential vocabulary unchanged, and is exercised only on the environment-scoped routes, where the project and environment come from the path and the credential's authority is the intersection of these scopes with the project-credential vocabulary. An organization credential is therefore never wider than a project credential would have been for the same project environment."
+      "description": "One organization-credential capability. `organization:read` is the organization's project directory \u2014 listing the organization's projects and reading one \u2014 and is the only scope here a project credential can never carry; it authorizes nothing below the organization. Every other name is the project-credential vocabulary unchanged, and is exercised only on the environment-scoped routes, where the project and environment come from the path and the credential's authority is the intersection of these scopes with the project-credential vocabulary. An organization credential is therefore never wider than a project credential would have been for the same project environment."
     },
     "OrganizationCredentialScopeSet": {
       "type": "array",
@@ -2456,7 +2456,7 @@
                   "type": "string",
                   "minLength": 1,
                   "maxLength": 100,
-                  "pattern": "^[^\u0000-\u001f-Ÿ

]+$"
+                  "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$"
                 },
                 "asserted_at": {
                   "$ref": "#/$defs/Timestamp"
@@ -2542,7 +2542,7 @@
                   "type": "string",
                   "minLength": 1,
                   "maxLength": 100,
-                  "pattern": "^[^\u0000-\u001f-Ÿ

]+$"
+                  "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$"
                 },
                 "asserted_at": {
                   "$ref": "#/$defs/Timestamp"
@@ -2631,7 +2631,7 @@
                   "type": "string",
                   "minLength": 1,
                   "maxLength": 100,
-                  "pattern": "^[^\u0000-\u001f-Ÿ

]+$"
+                  "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$"
                 },
                 "asserted_at": {
                   "$ref": "#/$defs/Timestamp"
@@ -2718,7 +2718,7 @@
                   "type": "string",
                   "minLength": 1,
                   "maxLength": 100,
-                  "pattern": "^[^\u0000-\u001f-Ÿ

]+$"
+                  "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$"
                 },
                 "asserted_at": {
                   "$ref": "#/$defs/Timestamp"
@@ -4356,7 +4356,7 @@
           "$ref": "#/$defs/Metadata"
         },
         "interaction": {
-          "$ref": "interaction-v1.schema.json#/$defs/InteractionRequest"
+          "$ref": "interaction-v1.schema.json#/$defs/InteractionSendRequest"
         },
         "purpose": {
           "enum": ["service", "marketing"],
@@ -4479,6 +4479,10 @@
         },
         "diagnostic_id": {
           "$ref": "#/$defs/DiagnosticId"
+        },
+        "interaction_expires_at": {
+          "$ref": "#/$defs/Timestamp",
+          "description": "Authoritatively resolved answer deadline shared by this broadcast\u2019s interactions, independent of delivery expires_at."
         }
       },
       "additionalProperties": false
@@ -5398,7 +5402,7 @@
           "$ref": "#/$defs/Metadata"
         },
         "interaction": {
-          "$ref": "interaction-v1.schema.json#/$defs/InteractionRequest"
+          "$ref": "interaction-v1.schema.json#/$defs/InteractionSendRequest"
         },
         "purpose": {
           "enum": ["service", "marketing"],
@@ -7025,9 +7029,11 @@
         "billing:write",
         "billing:read",
         "teammates:write",
-        "teammates:read"
+        "teammates:read",
+        "notifications:self",
+        "notifications:team"
       ],
-      "description": "An organization-level capability carried by a human session or an OAuth grant. Teammate scopes reach the organization's people: who is in it, their roles and their projects. Billing scopes grant financial access separately from project configuration. Project and organization API credentials cannot administer billing."
+      "description": "An organization-level capability carried by a human session or an OAuth grant. notifications:self permits only personal operator notifications, own preferences and project discovery. notifications:team additionally permits authorized teammate lookup, direct notifications and predefined operators broadcasts. Notification profiles exclude customer messaging and administration and are requested separately from broader scopes. Teammate scopes reach the organization's people: who is in it, their roles and their projects. Billing scopes grant financial access separately from project configuration. Project and organization API credentials cannot administer billing."
     },
     "OAuthScope": {
       "description": "A scope an OAuth grant may carry. Project-level scopes are the credential vocabulary unchanged; organization-level scopes exist only here and on a human session.",
@@ -7060,7 +7066,7 @@
       "minLength": 5,
       "maxLength": 32,
       "pattern": "^[A-Za-z][A-Za-z0-9_]{1,28}[Bb][Oo][Tt]$",
-      "description": "The @username Telegram's own creation dialog is prefilled with, constrained to Telegram's own rule: 5 to 32 characters, a letter first, letters, digits, and underscores after it, ending in `bot` in any case. The caller proposes it because it is the handle every subscriber sees forever and it cannot be changed once the bot exists — a WhooshBang-generated handle would permanently brand a customer's own bot with our naming, which is the one thing customer-owned modes exist to prevent. It is a suggestion and not a reservation: the administrator can type a different handle into Telegram's dialog, which validates the shape and refuses a handle somebody already holds."
+      "description": "The @username Telegram's own creation dialog is prefilled with, constrained to Telegram's own rule: 5 to 32 characters, a letter first, letters, digits, and underscores after it, ending in `bot` in any case. The caller proposes it because it is the handle every subscriber sees forever and it cannot be changed once the bot exists \u2014 a WhooshBang-generated handle would permanently brand a customer's own bot with our naming, which is the one thing customer-owned modes exist to prevent. It is a suggestion and not a reservation: the administrator can type a different handle into Telegram's dialog, which validates the shape and refuses a handle somebody already holds."
     },
     "ChannelConnectionStatus": {
       "type": "string",
@@ -7076,7 +7082,7 @@
         "failed",
         "expired"
       ],
-      "description": "How far a guided setup has reached, which is the only thing a caller can act on while a connection is still `pending`. `awaiting_handoff` waits for the administrator to open the link on the Telegram account that will own the bot; `awaiting_creation` means that Telegram account is bound and the bot does not exist yet; `provisioning` means the bot exists and WhooshBang is installing delivery on it. `failed` and `expired` end the attempt without ending the connection — another attempt can be started on the same `pending` connection — and neither withdraws a bot Telegram has already created, because no provider API can delete one."
+      "description": "How far a guided setup has reached, which is the only thing a caller can act on while a connection is still `pending`. `awaiting_handoff` waits for the administrator to open the link on the Telegram account that will own the bot; `awaiting_creation` means that Telegram account is bound and the bot does not exist yet; `provisioning` means the bot exists and WhooshBang is installing delivery on it. `failed` and `expired` end the attempt without ending the connection \u2014 another attempt can be started on the same `pending` connection \u2014 and neither withdraws a bot Telegram has already created, because no provider API can delete one."
     },
     "HostedChannelConnectionSetupStatus": {
       "type": "string",
@@ -7293,7 +7299,7 @@
     },
     "ChannelConnectionSetup": {
       "type": "object",
-      "description": "The unfinished half of a customer-managed connection: what the administrator still has to do, and by when. It is deliberately incapable of carrying a secret. The new bot's token travels from Telegram to WhooshBang server to server, so nothing here is credential material and nothing here references any — which is what makes this object safe to poll, render in a dashboard, or hand to whoever is doing the setup.",
+      "description": "The unfinished half of a customer-managed connection: what the administrator still has to do, and by when. It is deliberately incapable of carrying a secret. The new bot's token travels from Telegram to WhooshBang server to server, so nothing here is credential material and nothing here references any \u2014 which is what makes this object safe to poll, render in a dashboard, or hand to whoever is doing the setup.",
       "required": [
         "status",
         "handoff_url",
@@ -7419,7 +7425,7 @@
     },
     "CustomerApplicationConnectionSetup": {
       "type": "object",
-      "description": "The unfinished half of a connection through an application the customer creates and owns: what the owner still has to do at the provider, and by when.\n\nIt is deliberately incapable of carrying a secret. The creation link contains configuration and nothing else, the secrets the owner supplies are write-only and have no field here or on the connection, and the installation grant never travels through a browser at all — WhooshBang obtains it from the provider's own installation exchange. Everything here is therefore safe to poll, render, and hand to whoever is doing the setup.",
+      "description": "The unfinished half of a connection through an application the customer creates and owns: what the owner still has to do at the provider, and by when.\n\nIt is deliberately incapable of carrying a secret. The creation link contains configuration and nothing else, the secrets the owner supplies are write-only and have no field here or on the connection, and the installation grant never travels through a browser at all \u2014 WhooshBang obtains it from the provider's own installation exchange. Everything here is therefore safe to poll, render, and hand to whoever is doing the setup.",
       "required": [
         "status",
         "creation_url",
@@ -7505,7 +7511,7 @@
       "type": "string",
       "minLength": 1,
       "maxLength": 100,
-      "pattern": "^[^\u0000-\u001f-Ÿ

]+$",
+      "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$",
       "description": "A sender display name without control characters. It is encoded safely as a structured address field and never accepted as a raw header."
     },
     "EmailSubjectPolicy": {
@@ -7585,7 +7591,7 @@
               "type": "string",
               "minLength": 1,
               "maxLength": 100,
-              "pattern": "^[^\u0000-\u001f-Ÿ

]+$",
+              "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$",
               "description": "A bounded customer description of where consent was collected. The authenticated asserting actor is recorded by the service, never accepted from this object."
             },
             "asserted_at": {
@@ -7677,13 +7683,13 @@
               "type": "string",
               "minLength": 1,
               "maxLength": 253,
-              "pattern": "^[^\u0000-\u001f-Ÿ

]+$"
+              "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$"
             },
             "value": {
               "type": "string",
               "minLength": 1,
               "maxLength": 2048,
-              "pattern": "^[^\u0000-\u001f-Ÿ

]+$"
+              "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$"
             },
             "priority": {
               "type": "integer",
@@ -7713,13 +7719,13 @@
               "type": "string",
               "minLength": 1,
               "maxLength": 253,
-              "pattern": "^[^\u0000-\u001f-Ÿ

]+$"
+              "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$"
             },
             "value": {
               "type": "string",
               "minLength": 1,
               "maxLength": 2048,
-              "pattern": "^[^\u0000-\u001f-Ÿ

]+$"
+              "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$"
             },
             "status": {
               "enum": [
@@ -7752,7 +7758,7 @@
           "type": "string",
           "minLength": 1,
           "maxLength": 100,
-          "pattern": "^[^\u0000-\u001f-Ÿ

]+$"
+          "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$"
         },
         "instructions_url": {
           "type": "string",
@@ -8190,7 +8196,7 @@
         "handle": {
           "type": "string",
           "minLength": 1,
-          "description": "The visible provider handle without a provider-specific sigil — a bot username, a workspace or app display name, a sender address. Never a credential, installation identifier or provider-native identity reference."
+          "description": "The visible provider handle without a provider-specific sigil \u2014 a bot username, a workspace or app display name, a sender address. Never a credential, installation identifier or provider-native identity reference."
         }
       },
       "allOf": [
@@ -8312,7 +8318,7 @@
     },
     "HostedChannelConnection": {
       "type": "object",
-      "description": "A WhooshBang-owned application installed at one provider authority — a workspace, a tenant, a server — and referenced by one exact environment connection.",
+      "description": "A WhooshBang-owned application installed at one provider authority \u2014 a workspace, a tenant, a server \u2014 and referenced by one exact environment connection.",
       "required": [
         "id",
         "project_id",
@@ -8804,7 +8810,7 @@
       "additionalProperties": false
     },
     "CreateChannelConnectionRequest": {
-      "description": "Selects the provider identity this environment will send through, discriminated on `mode`, and naming the provider it is for. The two customer-owned modes differ only in where the bot comes from: `customer_byok` connects one the customer already has, and `customer_managed` has Telegram create a new one on the administrator's own Telegram account. Neither supersedes the other, because a bot that already exists can never be adopted into managed mode — the manager that may act for a bot is fixed when the bot is created.",
+      "description": "Selects the provider identity this environment will send through, discriminated on `mode`, and naming the provider it is for. The two customer-owned modes differ only in where the bot comes from: `customer_byok` connects one the customer already has, and `customer_managed` has Telegram create a new one on the administrator's own Telegram account. Neither supersedes the other, because a bot that already exists can never be adopted into managed mode \u2014 the manager that may act for a bot is fixed when the bot is created.",
       "oneOf": [
         {
           "type": "object",
@@ -8819,7 +8825,7 @@
               "type": "string",
               "const": "telegram",
               "default": "telegram",
-              "description": "This established setup arm is Telegram-only. Omitted means telegram. A provider whose setup is structurally different — an OAuth install rather than a credential — has its own arm of this union rather than bending this one."
+              "description": "This established setup arm is Telegram-only. Omitted means telegram. A provider whose setup is structurally different \u2014 an OAuth install rather than a credential \u2014 has its own arm of this union rather than bending this one."
             },
             "display_name": {
               "type": "string",
@@ -8834,7 +8840,7 @@
         },
         {
           "type": "object",
-          "description": "Connects a provider identity the customer already owns by supplying its credential.\n\nThis arm carries no identity field, and the absence is deliberate. `provider_identity_digest` is unique across every tenant, so an endpoint that digested a client-supplied identity would answer \"already claimed\" for a bot the caller does not own — an oracle for whether any given bot is connected to WhooshBang by anyone. The identity is derived server-side from a provider-validated `getMe` on the submitted credential, which no caller can forge without holding the credential itself.",
+          "description": "Connects a provider identity the customer already owns by supplying its credential.\n\nThis arm carries no identity field, and the absence is deliberate. `provider_identity_digest` is unique across every tenant, so an endpoint that digested a client-supplied identity would answer \"already claimed\" for a bot the caller does not own \u2014 an oracle for whether any given bot is connected to WhooshBang by anyone. The identity is derived server-side from a provider-validated `getMe` on the submitted credential, which no caller can forge without holding the credential itself.",
           "required": ["mode", "display_name", "credential"],
           "properties": {
             "mode": {
@@ -8845,7 +8851,7 @@
               "type": "string",
               "const": "telegram",
               "default": "telegram",
-              "description": "This established setup arm is Telegram-only. Omitted means telegram. A provider whose setup is structurally different — an OAuth install rather than a credential — has its own arm of this union rather than bending this one."
+              "description": "This established setup arm is Telegram-only. Omitted means telegram. A provider whose setup is structurally different \u2014 an OAuth install rather than a credential \u2014 has its own arm of this union rather than bending this one."
             },
             "display_name": {
               "type": "string",
@@ -8879,7 +8885,7 @@
               "type": "string",
               "const": "telegram",
               "default": "telegram",
-              "description": "This established setup arm is Telegram-only. Omitted means telegram. A provider whose setup is structurally different — an OAuth install rather than a credential — has its own arm of this union rather than bending this one."
+              "description": "This established setup arm is Telegram-only. Omitted means telegram. A provider whose setup is structurally different \u2014 an OAuth install rather than a credential \u2014 has its own arm of this union rather than bending this one."
             },
             "display_name": {
               "type": "string",
@@ -8893,14 +8899,14 @@
               "type": "string",
               "minLength": 1,
               "maxLength": 64,
-              "description": "The display name prefilled in the same dialog — what a subscriber reads at the top of the chat, as opposed to the @username they address. Unlike the username this one can be changed afterwards, so it is a convenience rather than a commitment. Omit it and Telegram's dialog opens with no name suggested."
+              "description": "The display name prefilled in the same dialog \u2014 what a subscriber reads at the top of the chat, as opposed to the @username they address. Unlike the username this one can be changed afterwards, so it is a convenience rather than a commitment. Omit it and Telegram's dialog opens with no name suggested."
             }
           },
           "additionalProperties": false
         },
         {
           "type": "object",
-          "description": "Starts a guided setup in which the customer creates and owns their own application at the provider. The connection comes back `pending` with an `app_setup` carrying the provider's own creation link, already filled in with this application's configuration where the provider allows it.\n\nThis arm carries no credential field, because at this point no credential exists: the provider issues the application's secrets when the owner creates it. They arrive later through the write-only rotation boundary, and the installation grant never arrives from the caller at all — WhooshBang obtains it from the provider's installation exchange. The three names here are what the owner's own recipients will see, which is why the caller chooses them rather than WhooshBang: a generated name would permanently brand a customer's own application with ours, and that is the one thing customer-owned modes exist to prevent.\n\nA provider that does not set a connection up this way refuses the request as an unavailable setup mode. Each provider may also refuse a name its own rules do not allow, within the bounds stated here.",
+          "description": "Starts a guided setup in which the customer creates and owns their own application at the provider. The connection comes back `pending` with an `app_setup` carrying the provider's own creation link, already filled in with this application's configuration where the provider allows it.\n\nThis arm carries no credential field, because at this point no credential exists: the provider issues the application's secrets when the owner creates it. They arrive later through the write-only rotation boundary, and the installation grant never arrives from the caller at all \u2014 WhooshBang obtains it from the provider's installation exchange. The three names here are what the owner's own recipients will see, which is why the caller chooses them rather than WhooshBang: a generated name would permanently brand a customer's own application with ours, and that is the one thing customer-owned modes exist to prevent.\n\nA provider that does not set a connection up this way refuses the request as an unavailable setup mode. Each provider may also refuse a name its own rules do not allow, within the bounds stated here.",
           "required": [
             "mode",
             "provider",
@@ -8933,7 +8939,7 @@
               "type": "string",
               "minLength": 1,
               "maxLength": 80,
-              "description": "The bot display name in the same flow — what a recipient reads at the top of the conversation."
+              "description": "The bot display name in the same flow \u2014 what a recipient reads at the top of the conversation."
             },
             "app_description": {
               "type": "string",
@@ -9033,11 +9039,11 @@
       ]
     },
     "RotateChannelConnectionCredentialRequest": {
-      "description": "Replaces the secret behind a connection, discriminated by where a replacement can come from at all. A customer-owned bot has one only its owner can produce and therefore sends it; a managed bot has one only Telegram can issue and therefore sends nothing. An application the customer owns has separate authorities and names each one it hands over. Either way the connection keeps its provider identity, so a subscriber stays bound to the identity it consented to and only the secret changes.\n\nThe first submission during setup uses this same boundary. Handing a secret over and replacing it are the same operation — a write that never reads the old value back — and giving initial setup its own endpoint would have meant two ways to do one thing, differing only in what the connection's status happened to be.",
+      "description": "Replaces the secret behind a connection, discriminated by where a replacement can come from at all. A customer-owned bot has one only its owner can produce and therefore sends it; a managed bot has one only Telegram can issue and therefore sends nothing. An application the customer owns has separate authorities and names each one it hands over. Either way the connection keeps its provider identity, so a subscriber stays bound to the identity it consented to and only the secret changes.\n\nThe first submission during setup uses this same boundary. Handing a secret over and replacing it are the same operation \u2014 a write that never reads the old value back \u2014 and giving initial setup its own endpoint would have meant two ways to do one thing, differing only in what the connection's status happened to be.",
       "oneOf": [
         {
           "type": "object",
-          "description": "Supplies or replaces the application-specific authorities of an application the customer owns. Every authority that provider's application takes is sent together, both for the first submission during setup and for every later replacement.\n\nSending only the one that changed would read as the kinder API, and it is the wrong shape: the authorities are sealed as one versioned set, so replacing one alone would mean decrypting the others and writing them back — reading secrets at a boundary whose whole purpose is that nothing reads them.\n\n`application_identity` is safe metadata; the secrets are write-only and are never readable afterwards by any surface. `ingress_secret` is optional in shape because not every provider signs inbound requests with a secret the owner holds; a provider whose application does have one refuses a request that leaves it out, and refuses an `application_identity` that is not in its own format.\n\nThere is no bot-token field here, and the absence is the point: WhooshBang obtains the installation grant from the provider's installation exchange, so it never passes through a browser, a clipboard, this request, or any response.",
+          "description": "Supplies or replaces the application-specific authorities of an application the customer owns. Every authority that provider's application takes is sent together, both for the first submission during setup and for every later replacement.\n\nSending only the one that changed would read as the kinder API, and it is the wrong shape: the authorities are sealed as one versioned set, so replacing one alone would mean decrypting the others and writing them back \u2014 reading secrets at a boundary whose whole purpose is that nothing reads them.\n\n`application_identity` is safe metadata; the secrets are write-only and are never readable afterwards by any surface. `ingress_secret` is optional in shape because not every provider signs inbound requests with a secret the owner holds; a provider whose application does have one refuses a request that leaves it out, and refuses an `application_identity` that is not in its own format.\n\nThere is no bot-token field here, and the absence is the point: WhooshBang obtains the installation grant from the provider's installation exchange, so it never passes through a browser, a clipboard, this request, or any response.",
           "required": [
             "provider",
             "application_identity",
@@ -9052,21 +9058,21 @@
               "minLength": 1,
               "maxLength": 128,
               "pattern": "^[\\x21-\\x7e]+$",
-              "description": "The identifier the provider issued for the application — for Slack, its Client ID. Safe application metadata rather than an authority: it identifies the application in an authorization redirect the provider's users can already see."
+              "description": "The identifier the provider issued for the application \u2014 for Slack, its Client ID. Safe application metadata rather than an authority: it identifies the application in an authorization redirect the provider's users can already see."
             },
             "application_secret": {
               "type": "string",
               "minLength": 1,
               "maxLength": 512,
               "writeOnly": true,
-              "description": "The secret the application authenticates to the provider with — for Slack, its Client Secret. Write-only: sealed on arrival, never echoed here or by any later read, and reachable only by the exchanges that need it."
+              "description": "The secret the application authenticates to the provider with \u2014 for Slack, its Client Secret. Write-only: sealed on arrival, never echoed here or by any later read, and reachable only by the exchanges that need it."
             },
             "ingress_secret": {
               "type": "string",
               "minLength": 1,
               "maxLength": 512,
               "writeOnly": true,
-              "description": "The secret that verifies an inbound request really came from the provider — for Slack, its Signing Secret. Write-only on the same terms, and reachable only by ingress verification."
+              "description": "The secret that verifies an inbound request really came from the provider \u2014 for Slack, its Signing Secret. Write-only on the same terms, and reachable only by ingress verification."
             }
           },
           "additionalProperties": false
@@ -9088,7 +9094,7 @@
         },
         {
           "type": "object",
-          "description": "Rotates a `customer_managed` connection, whose replacement only Telegram can issue. Asked to rotate, Telegram revokes the bot's current token and returns the successor to the manager that created it, so there is no customer-supplied credential to send and no field here to send one in — a caller able to supply one would be describing a bot this mode never handed it. The identity is untouched: the same bot keeps the same @username and the same subscribers, and only the secret behind it is new.",
+          "description": "Rotates a `customer_managed` connection, whose replacement only Telegram can issue. Asked to rotate, Telegram revokes the bot's current token and returns the successor to the manager that created it, so there is no customer-supplied credential to send and no field here to send one in \u2014 a caller able to supply one would be describing a bot this mode never handed it. The identity is untouched: the same bot keeps the same @username and the same subscribers, and only the secret behind it is new.",
           "required": ["source"],
           "properties": {
             "source": {
@@ -9161,7 +9167,7 @@
         "check_request_url",
         "contact_support"
       ],
-      "description": "The exact safe next action for one test result, in product vocabulary.\n\nIt is a different vocabulary from a connection's own recovery action because the actions genuinely differ: a test that nothing answered is fixed by checking the request URL the provider was given, and a request that arrived and did not verify is fixed by re-entering the app's secrets — neither of which is a lifecycle transition on the connection.\n\n`check_request_url` is also the honest answer when nobody simply pressed the button: the window closed with nothing arriving, and that has exactly two causes."
+      "description": "The exact safe next action for one test result, in product vocabulary.\n\nIt is a different vocabulary from a connection's own recovery action because the actions genuinely differ: a test that nothing answered is fixed by checking the request URL the provider was given, and a request that arrived and did not verify is fixed by re-entering the app's secrets \u2014 neither of which is a lifecycle transition on the connection.\n\n`check_request_url` is also the honest answer when nobody simply pressed the button: the window closed with nothing arriving, and that has exactly two causes."
     },
     "ConnectionTestEvidence": {
       "type": "object",
@@ -9171,7 +9177,7 @@
           "type": "string",
           "minLength": 1,
           "maxLength": 128,
-          "description": "The visible handle the test went out as — the same identity a subscriber would see."
+          "description": "The visible handle the test went out as \u2014 the same identity a subscriber would see."
         },
         "workspace_display_name": {
           "type": "string",
@@ -9322,7 +9328,7 @@
           "$ref": "#/$defs/MessageContent"
         },
         "interaction": {
-          "$ref": "interaction-v1.schema.json#/$defs/InteractionRequest"
+          "$ref": "interaction-v1.schema.json#/$defs/InteractionSendRequest"
         }
       },
       "allOf": [
@@ -9371,7 +9377,7 @@
     },
     "CustomerApplicationManifest": {
       "type": "object",
-      "description": "The exact configuration an application the customer creates and owns is created from, as data rather than as a URL-encoded blob.\n\nIt exists so the owner can read what they are about to approve, and so a reviewer can check it, without opening the provider. It is built by the provider that owns the format, so `manifest` is that provider's own document and `provider` says whose. It carries configuration only: no organization, project, or environment, no credential, and no provider-native identifier. Any opaque handle inside the request URLs selects candidate setup state and authorizes nothing — a request still has to carry the provider's own proof over the untouched body before anything inside it is believed.",
+      "description": "The exact configuration an application the customer creates and owns is created from, as data rather than as a URL-encoded blob.\n\nIt exists so the owner can read what they are about to approve, and so a reviewer can check it, without opening the provider. It is built by the provider that owns the format, so `manifest` is that provider's own document and `provider` says whose. It carries configuration only: no organization, project, or environment, no credential, and no provider-native identifier. Any opaque handle inside the request URLs selects candidate setup state and authorizes nothing \u2014 a request still has to carry the provider's own proof over the untouched body before anything inside it is believed.",
       "required": [
         "provider",
         "creation_url",
@@ -9627,7 +9633,7 @@
               "type": "string",
               "minLength": 1,
               "maxLength": 100,
-              "pattern": "^[^\u0000-\u001f-Ÿ

]+$",
+              "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$",
               "description": "A bounded customer description of where consent was collected. The authenticated asserting actor is recorded by the service, never accepted from this object."
             }
           },
@@ -9666,7 +9672,7 @@
               "type": "string",
               "minLength": 1,
               "maxLength": 100,
-              "pattern": "^[^\u0000-\u001f-Ÿ

]+$",
+              "pattern": "^[^\u0000-\u001f-Ÿ

\u007f-\u009f\u2028\u2029]+$",
               "description": "A bounded customer description of the service relationship. The authenticated asserting actor is recorded by the service, never accepted from this object."
             },
             "basis": {
@@ -9733,7 +9739,7 @@
     },
     "SharedEmailStatus": {
       "type": "object",
-      "description": "Safe state of the exact shared sender generation and this organization’s domain hold. It conveys no recipient consent and never authorizes fallback.",
+      "description": "Safe state of the exact shared sender generation and this organization\u2019s domain hold. It conveys no recipient consent and never authorizes fallback.",
       "required": [
         "sender_generation",
         "sender_state",
@@ -11641,7 +11647,7 @@
           "$ref": "#/$defs/Metadata"
         },
         "interaction": {
-          "$ref": "interaction-v1.schema.json#/$defs/InteractionRequest"
+          "$ref": "interaction-v1.schema.json#/$defs/InteractionSendRequest"
         },
         "purpose": {
           "enum": ["service", "marketing"],
@@ -11732,7 +11738,7 @@
     },
     "OperatorPreferences": {
       "type": "object",
-      "description": "The authenticated person’s own destinations and preferred channel in this project. Shared credentials cannot manage a human’s preferences.",
+      "description": "The authenticated person\u2019s own destinations and preferred channel in this project. Shared credentials cannot manage a human\u2019s preferences.",
       "required": ["operator", "settings", "connections"],
       "properties": {
         "operator": {
@@ -11768,7 +11774,7 @@
     },
     "OperatorConnectRequest": {
       "type": "object",
-      "description": "Connect the signed-in person’s own destination through a configured channel. This never changes another person’s channels.",
+      "description": "Connect the signed-in person\u2019s own destination through a configured channel. This never changes another person\u2019s channels.",
       "required": ["connection_id", "channel"],
       "properties": {
         "connection_id": {