@xema/omni-protocol 0.1.102 → 0.1.104

package/guide.md

@@ -203,7 +203,7 @@ type Manifest<C extends Channel = Channel> = {
   dialOutcomes?: C extends "voice" ? DialOutcome[] : never;
   phones?: C extends "voice" ? Phone[] : never;
   runningStepReports?: true;
-  completionSettleMs: number;
+  settleMs: number;
 };
 ```
 
@@ -474,11 +474,13 @@ type PreferenceResult =
 type Snapshot = {
   transport: TransportStatus;
   loginId: string;
+  providerTime?: IsoTimestamp;
   break: BreakState;
   tasks: Task[];
   taskCount: number;
   contacts?: Contact[];
   calendar?: ScheduledActivity[];
+  shift?: Shift;
   team?: TeamMembers;
 };
 
@@ -569,8 +571,8 @@ type TaskCapabilities<C extends Channel = Channel> =
         recording?: Lockable<TaskRecordingPolicy>;
       }
     : C extends "chat"
-      ? SharedTaskCapabilities & { decline?: Lockable<true>; hold?: Lockable<true> }
-      : SharedTaskCapabilities & { decline?: Lockable<true> };
+      ? SharedTaskCapabilities & { decline?: Lockable<true>; hold?: Lockable<true>; schedule?: Lockable<true> }
+      : SharedTaskCapabilities & { decline?: Lockable<true>; schedule?: Lockable<true> };
 ```
 
 The channel arms are why `Task<"email">` rejects `hold` at compile time rather than at runtime.
@@ -723,6 +725,7 @@ type Task<C extends Channel = Channel> = {
   party?: Contact;
   phase: TaskPhase;
   acceptance?: AcceptanceMode;
+  expiresInSeconds?: DurationSeconds;
   previewEndsInSeconds?: DurationSeconds;
   atDeadline?: PreviewDeadline;
   reference?: string;
@@ -745,7 +748,7 @@ type TaskOutcome =
   | { type: "completed"; by: "agent" | "provider" }
   | { type: "taken-over"; leadId: UserId }
   | { type: "cancelled"; by: "agent" | "provider" | "party"; reason?: string }
-  | { type: "expired"; phase: "pending" | "confirmed" | "preview" }
+  | { type: "expired"; phase: "pending" | "confirmed" }
   | { type: "failed"; failure: ProtocolFailure };
 ```
 
@@ -768,8 +771,8 @@ const TASK_COMMAND_NAMES = {
     "schedule",
     "complete",
   ],
-  chat: ["accept", "decline", "pause", "resume", "complete"],
-  email: ["accept", "decline", "complete"],
+  chat: ["accept", "decline", "pause", "resume", "schedule", "complete"],
+  email: ["accept", "decline", "schedule", "complete"],
 } as const;
 
 type TaskCommandName<C extends keyof typeof TASK_COMMAND_NAMES> =
@@ -786,7 +789,7 @@ type VoiceTaskCommand =
   | { type: "end-call" }
   | { type: "terminate-call" }
   | { type: "connect-back"; dialId: DialId }
-  | { type: "schedule"; at: IsoTimestamp; note?: string }
+  | ScheduleCommand
   | { type: "lead-assist"; action: "request"; note?: string }
   | { type: "lead-assist"; action: "cancel" }
   | { type: "conference"; action: "add"; dialId: DialId; destinationId: string }
@@ -795,16 +798,20 @@ type VoiceTaskCommand =
   | (RecordingCommand & { source: "provider" })
   | ({ type: "complete" } & OutcomePayload);
 
+type ScheduleCommand = { type: "schedule"; at: IsoTimestamp; note?: string };
+
 type ChatTaskCommand =
   | { type: "accept" }
   | { type: "decline" }
   | { type: "pause" }
   | { type: "resume" }
+  | ScheduleCommand
   | ({ type: "complete" } & OutcomePayload);
 
 type EmailTaskCommand =
   | { type: "accept" }
   | { type: "decline" }
+  | ScheduleCommand
   | ({ type: "complete" } & OutcomePayload);
 
 type CustomTaskCommand = { type: "custom"; name: string; [key: string]: unknown };
@@ -928,7 +935,7 @@ type BreakRequest = {
 
 type ForcedBreak = {
   by: UserId | "provider";
-  expectedDurationMs?: number;
+  expectedEndsInSeconds?: DurationSeconds;
 };
 
 type BreakState = {
@@ -970,8 +977,8 @@ type TeamMember = {
   since?: IsoTimestamp;
   break?: Extract<BreakStatus, "awaiting-approval" | "granted" | "starting-after-task">;
   tasks?: MemberTask[];
-  listening?: MemberListening;
-  shift?: MemberShift;
+  listening?: MemberListening[];
+  shift?: Shift;
   request?: MemberRequest;
 };
 
@@ -1001,6 +1008,7 @@ type MemberTask<C extends Channel = Channel> = {
   : { onCall?: never; leadAssist?: never; takenOver?: never; audio?: never });
 
 type MemberListening = {
+  leadId: UserId;
   assignmentId: AssignmentId;
   mode: ListeningMode;
   since: IsoTimestamp;
@@ -1013,7 +1021,7 @@ type ShiftEvent = {
   kind: ShiftEventKind;
 };
 
-type MemberShift = {
+type Shift = {
   signedInAt: IsoTimestamp;
   signedOutAt?: IsoTimestamp;
   talkSeconds?: DurationSeconds;
@@ -1115,7 +1123,6 @@ type ProviderEvent =
   | {
       type: "task-offered";
       task: Task;
-      expiresInSeconds?: DurationSeconds;
     }
   | { type: "task-updated"; task: Task }
   | { type: "task-audio-started"; assignmentId: AssignmentId }
@@ -1130,7 +1137,8 @@ type ProviderEvent =
   | { type: "team-member-removed"; memberId: UserId }
   | { type: "team-policies-updated"; policies: TeamPolicies }
   | { type: "contacts-updated"; contacts: Contact[] }
-  | { type: "calendar-updated"; calendar: ScheduledActivity[] };
+  | { type: "calendar-updated"; calendar: ScheduledActivity[] }
+  | { type: "shift-updated"; shift: Shift };
 
 type ProviderEventEnvelope = {
   id: string;
@@ -1254,6 +1262,7 @@ const OMNI_FAILURE_CODES = [
   "omni.unavailable",
   "omni.break-already-committed",
   "omni.recording-unsettled",
+  "omni.break-forced-by-provider",
 ] as const;
 type OmniFailureCode = (typeof OMNI_FAILURE_CODES)[number];
 ```
@@ -1586,7 +1595,7 @@ export default defineAdapter({
     channel: "voice",
     supportedProtocolVersions: [OMNI_PROTOCOL_VERSION],
     authenticationMethods: ["browser-sso"],
-    completionSettleMs: 5000,
+    settleMs: 5000,
     idleCapabilities: {
       dial: { destinations: "any-number" },
     },
@@ -1621,10 +1630,10 @@ compile time.
 | `orgLevels` | The organisation's whole ladder as the provider calls it, each level with the label a desk shows for "who decided". Stated outright, `person` included: what it leaves out does not exist. Omitted for the typical four, `DEFAULT_LEVELS`. See **Who decides what an agent may do**. |
 | `phones` | Voice only, and required there: the phones this platform can put an agent on, `softphone` (the call's audio lands in the agent application) and/or `deskPhone` (a handset the platform rings; the agent application shows the call and opens nothing). The agent application picks one per login. See **How the agent hears the call**. |
 | `dialOutcomes` | Voice only. How a dial can end on this platform, as it distinguishes them: `answered` and at least one way of not reaching the destination. Required of a provider that dials at all — an idle dialpad, or tasks that conference or call back — and a `dial-outcome` carries only a declared member. See **Every dial has an outcome**. |
-| `timeCheck` | Optional `true`: implements `checkTime` for fresh provider-clock samples; agent application polling is independently opt-in. |
+| `timeCheck` | `true`: implements `checkTime` and states `providerTime` on every snapshot. Required of a provider that publishes an instant the desk renders as a running duration -- a member's `since`, a lead's `listening.since`, an `onCall.since`, a shift's `signedInAt` -- so every screen counts from the provider's clock (`manifest.timeCheck.required`); agent application polling is independently opt-in. See **Every screen counts from the provider's clock**. |
 | `timestampAuthority` | Optional `"provider"`: provider timestamps are final; agent application instants are advisory. Omission makes no trust promise. |
 | `runningStepReports` | The provider takes running reports of an agent application-performed step — `recordStep` with `seconds` so far and no `ended`. Omitted, the agent application sends exactly two reports per leg, when it began and when it ended, and a running one is refused. See **The agent application records what it performs**. |
-| `completionSettleMs` | Required. How long after an applied `complete` the provider's `task-ended` is owed, a positive whole number of milliseconds (`manifest.completionSettleMs`). Stated per provider, since platforms settle at different speeds. See **`task-ended`**. |
+| `settleMs` | Required. How long after `applied` the wire shows what the provider did: the `task-ended` after a `complete`, the `calendar-updated` after a `schedule`. A positive whole number of milliseconds (`manifest.settleMs`). Stated per provider, since platforms settle at different speeds. See **`task-ended`**. |
 
 ### Authentication methods
 
@@ -2137,11 +2146,13 @@ a capability it agrees with the login: a lead's snapshot carries `team`, nobody
 | --- | --- |
 | `transport` | Current `TransportStatus` — whether this provider's transport can serve the login. Defined under **`transport-status`**. |
 | `loginId` | Identity of this login. It must match the connection context. |
+| `providerTime` | The provider's own instant of this read. Required of a provider that declares `timeCheck` (`snapshot.providerTime`), forbidden of one that does not (`snapshot.providerTime.unexpected`): a clock sample the desk counts durations from, saving it a `checkTime`. |
 | `break` | Complete break state, including status, whether the agent may ask, reasons, retry details, and any forced break. |
 | `tasks` | Complete set of tasks currently offered to or owned by this agent. |
 | `taskCount` | The provider's own count of those tasks, stated rather than inferred, and it must equal `tasks.length`. A snapshot with no work says `taskCount: 0` in so many words — a blank or unanswered state lacks the count and cannot pass as a confirmed empty. |
 | `contacts` | Required complete contact contribution when the manifest declares `contacts`; `[]` clears it. Omitted only when it does not. |
 | `calendar` | Required complete calendar contribution when the manifest declares `calendar`; `[]` clears it. Omitted only when it does not. |
+| `shift` | The agent's own day so far, as the provider counts it -- the same `Shift` their lead sees on the team member list, the same numbers from the same count. Replaced whole by `shift-updated`. Omitted only where the provider cannot say. See **The agent's day is on the wire**. |
 | `team` | Required `TeamMembers` when the login declares `capabilities.lead` and the lead has the team feature on, `members: []` when nobody is in it. Forbidden otherwise — the login is the permission, and a lead who turned the feature off gets nothing of the team. |
 
 ## Live connection
@@ -2318,8 +2329,7 @@ declare const task: Task;
 
 const assignment = {
   type: "task-offered",
-  task: { ...task, phase: "pending", acceptance: "consent" },
-  expiresInSeconds: 30,
+  task: { ...task, phase: "pending", acceptance: "consent", expiresInSeconds: 30 },
 } satisfies Extract<ProviderEvent, { type: "task-offered" }>;
 ```
 
@@ -2337,10 +2347,12 @@ on a desk phone — and is not in question per call. See **How the agent hears t
 
 Automatic acceptance still begins with `task-offered`.
 
-`expiresInSeconds` is how long the offer stands, in whole seconds from this event. Where present,
-Omni counts down from receipt and stops offering **Accept** once it runs out; the provider ends
-the lapsed offer with `task-ended` and an `expired` outcome naming `pending`, since nobody
-cancelled it. **Omit it unless the provider can observe it.** A provider that reports only elapsed
+`expiresInSeconds` is how long the offer has left, in whole seconds from the publication that
+carries it. It rides on the pending task, as `acceptance` does, so a reconnect snapshot restates
+it from what is actually left; it belongs to `pending` alone and is gone once the task is accepted
+(`task.pending.expiresInSeconds`, `.unexpected`). Where present, Omni counts down from receipt and
+stops offering **Accept** once it runs out; the provider ends the lapsed offer with `task-ended`
+and an `expired` outcome naming `pending`, since nobody cancelled it. **Omit it unless the provider can observe it.** A provider that reports only elapsed
 ring time after the fact cannot say how long an offer has left, and a computed value would have
 Omni withdraw **Accept** from a task still pending.
 
@@ -2349,7 +2361,7 @@ different clocks, and a countdown that compares one against the other is a count
 fast or slow by their skew. Seconds from the publication that carries them are the provider's own
 arithmetic, counted down on the desk from the moment they arrive, and the transport delay is the
 only error. Restated on every publication that carries them, so a snapshot after a reconnect
-starts the countdown afresh from what is actually left (`event.taskOffered.expiresInSeconds`,
+starts the countdown afresh from what is actually left (`task.pending.expiresInSeconds`,
 `task.preview.previewEndsInSeconds`: a whole number, zero or more).
 
 A preview's deadline is not on the offer. It travels on the task, as `previewEndsInSeconds` with
@@ -2396,6 +2408,7 @@ time. Runtime conformance checks also require the task channel to match its prov
 | `phase` | Current canonical task phase: `pending`, `confirmed`, `preview`, `in-progress`, `paused`, or `completing`. `preview` is voice only. |
 | `audio` | Voice only. The task's real-time audio as the provider holds it: `started` while audio is attached, `ended` once it ended, omitted while none is. The provider's word — see **`task-audio-started`**. Audio names a task whose work has begun, or whose party the agent application is dialling: on a `pending`, `confirmed` or `preview` task with nobody ringing it is refused (`task.audio.beforeWork`), on a snapshot as on the event, since an agent application opens the microphone on it; with the party ringing by an agent application dial or provider-triggered preview dial, actual ring-back audio may precede answer. |
 | `acceptance` | How this offer is accepted — `no-preference`, `consent`, or `automatic` — stated on the pending task so a reconnect snapshot says it too. Required while `pending` when `autoAcceptTasks` was `true`, forbidden when it was `false`, and absent past `pending`. See **Acceptance modes**. |
+| `expiresInSeconds` | In `pending` only: how long the offer has left, in whole seconds from this publication, restated on every publication that carries it. Absent, the offer stands until the provider says otherwise. See **Pending**. |
 | `previewEndsInSeconds` | Voice only, in `preview`: how long the preparation has left, in whole seconds from this publication, restated on every publication that carries it. Absent, the agent has as long as they need without a preparation countdown. Always with `atDeadline`. See **Preview: the agent presses Call**. |
 | `atDeadline` | Voice only, in `preview`, with `previewEndsInSeconds`: what the system does when it runs out -- `provider-dials` makes the provider initiate dialing, `host-dials` makes the agent application issue Call, `waits` keeps the task in preview awaiting the agent. |
 | `reference` | Optional agent-facing reference such as a case, call, conversation, ticket, or message number. It is distinct from the protocol `id`. |
@@ -2618,18 +2631,26 @@ provider may complete the task without receiving that command.
 **The agent may finish early under either mode.** `complete` is issuable wherever there is a wrap
 to cut short: under `agent-command` it is the end, and under `provider-automatic` it says the agent
 is done before the allowance ran out, and the provider is free to end the task at once. Only a task
-with no wrap at all -- `wrapAllowance: 0` -- has nothing to complete, and the command is refused
-there (`command.complete.wrapAllowance`). An ending the agent asked for says so, `completed` with
-`by: "agent"`, whichever mode the task was under.
+with no wrap at all -- `provider-automatic` with `wrapAllowance: 0` -- has nothing to complete, and
+the command is refused there (`command.complete.wrapAllowance`). An ending the agent asked for says
+so, `completed` with `by: "agent"`, whichever mode the task was under.
 
 **A required outcome is the agent's to give.** A task whose `outcomes` says `required: true` waits
 for a code the agent chooses, so it completes on the agent's command: `provider-automatic` cannot
 wait for it, and the pair is refused (`task.outcomes.required.mode`). Optional outcomes may ride on
 a task the provider completes itself; the agent gives one if in time. And a code is given in wrap,
-so a task with `wrapAllowance: 0` publishes no `outcomes` at all (`task.outcomes.wrapAllowance`).
+so a `provider-automatic` task with `wrapAllowance: 0` publishes no `outcomes` at all
+(`task.outcomes.wrapAllowance`).
+
+**The allowance means one thing per mode.** Under `provider-automatic` it is what the provider
+acts on: the task ends when it runs out. Under `agent-command` it is the expected wrap, stated so
+the agent can see it: the desk counts it down and, past zero, shows how far over they are, and
+nothing acts on it -- the task waits for `complete` however long that takes, with its outcomes
+collected whenever the agent gives them. A provider that would end the task at a time is
+`provider-automatic`.
 
-`wrapAllowance` is independent of that decision. It is fixed, and when it starts depends on
-whether the channel carries real-time audio:
+`wrapAllowance` is fixed, and when it starts depends on whether the channel carries real-time
+audio:
 
 | Channel | Wrap allowance starts at |
 | --- | --- |
@@ -2658,9 +2679,9 @@ const emailCompletion = {
 In this example, the agent has two minutes after sending the email to add notes, select a
 outcome, and complete the task.
 
-`0` means there is no wrap: under `provider-automatic` the provider completes the task at the
-end of the interaction, and under `agent-command` it completes on the interaction's end without
-waiting for `complete`, which has nothing to cut short and is refused.
+`0` means no wrap under `provider-automatic`: the provider completes the task at the end of the
+interaction, and `complete` has nothing to cut short. Under `agent-command` it is an expected wrap
+of nothing -- the desk shows the overrun from the start -- and the task still waits for `complete`.
 
 There is no value meaning "unlimited", because a number that is not a duration would be read as
 one. A provider that imposes no deadline says so by **omitting** `wrapAllowance`, which
@@ -2748,7 +2769,7 @@ The record is the call's, not the task's: most of what it holds happened before
 *Interaction* keeps the one meaning **Terms** gives it, the agent's time on the call, which is why
 the total of earlier agents' time is `interactionSeconds` and the phase rules are
 `command.phase.interaction`. Hosts and providers adopt these names together; no legacy aliases
-are provided. The manifest's `completionSettleMs` bounds final task completion, not entry into
+are provided. The manifest's `settleMs` bounds final task completion, not entry into
 the `completing` wrap-up phase. The `recordStep` method and `complete` command keep their names.
 
 Migration from the earlier spellings:
@@ -2765,7 +2786,7 @@ Migration from the earlier spellings:
 | Task.allocationId, AllocationId, allocationExpiresAt | `Task.assignmentId`, `AssignmentId`, `expiresInSeconds` |
 | Task.id, TaskId, and `taskId` on every event, command, report and lead request | gone: a task is named by `assignmentId` alone, and `assignmentKey(providerId, assignmentId)` scopes it |
 | taskKey, omni.task-not-found, PROVIDER_NAME__TASK_ID__TAB_NAME (ProviderName.TaskId.TabName) | `assignmentKey`, `omni.assignment-not-found`, `PROVIDER_NAME__ASSIGNMENT_ID__TAB_NAME` (`ProviderName.AssignmentId.TabName`) |
-| Manifest.disposalSettleMs | `Manifest.completionSettleMs` |
+| Manifest.disposalSettleMs, Manifest.completionSettleMs | `Manifest.settleMs` (`manifest.settleMs`, `manifest.settleMs.renamed`): the bound after `applied` for `complete` and `schedule` alike |
 | the call command, atDeadline calls and host-calls | `dial`, `"provider-dials"`, `"host-dials"` |
 | media: task-media-started/-ended, team-media-*, Task.media, TaskMediaState, openMedia, OpenMediaRequest/Result, VoiceMediaSession and its session field | audio: `task-audio-started`, `task-audio-ended`, `audio` on the task, `TaskAudioState`, `openAudio`, `OpenAudioRequest`, `OpenAudioResult`, `CallAudio` on the result's `audio`; there is no team audio, the lead's follows `listening` on the member |
 | capabilitySource values ungoverned and undetermined | `nobody`, `not-yet-read` (`capabilitySource.notYetRead`) |
@@ -2777,7 +2798,17 @@ Migration from the earlier spellings:
 | TeamMembers.requests, LeadRequest | `TeamMember.request` (`MemberRequest`): the ask rides on the member (`team.member.request.*`) |
 | team-updated on every change | `team-updated` whole once after the switch and on snapshots; `team-member-updated`, `team-member-removed`, `team-policies-updated` after (`stream.team.baseline`, `stream.teamMember.unknown`) |
 | RecordingCommand.requestId | gone: no request identity; a partial effect is a settled `failed` under `omni.recording-unsettled` |
-| command.complete.mode | `command.complete.wrapAllowance`: `complete` under either mode, refused only with no wrap |
+| command.complete.mode | `command.complete.wrapAllowance`: `complete` under either mode, refused only on `provider-automatic` with no wrap |
+| expiresInSeconds on task-offered | `Task.expiresInSeconds`, in `pending` (`task.pending.expiresInSeconds`, `.unexpected`; `event.taskOffered.expiresInSeconds.unexpected`) |
+| the expired outcome naming preview | gone: nothing expires a preview; withdrawn, it is `cancelled` by the provider |
+| schedule on voice alone | `schedule` on every channel, under a manifest that declares `calendar` (`task.capability.calendar.required`), bounded by `settleMs` (`drive.schedule.unsettled`) |
+| a forced break requesting breaks on the other providers | `setCapacity({ count: 0 })` on every other usable provider (`assertForcedBreakStopsTheRest`) |
+| end-forced-break on a break the platform imposed | refused: `team.command.endForcedBreak.provider`, `omni.break-forced-by-provider` |
+| ForcedBreak.expectedDurationMs | `expectedEndsInSeconds`: seconds left, restated (`break.forced.expectedEndsInSeconds`, `.expectedDurationMs.renamed`); the command keeps `expectedDurationMs` |
+| MemberShift; the day on the lead's list alone | `Shift`, on `Snapshot.shift` and `shift-updated` for the agent, on `TeamMember.shift` for the lead |
+| TeamMember.listening as this lead's one entry | `MemberListening[]`, every lead's, each with `leadId` (`team.member.listening.leadId`, `.unique`, `.empty`, `.entry`, `.heard`) |
+| a member's history trimmed on the lead's list | the record whole, as the member's desk holds it |
+| durations counted from the screen's clock | the provider's: `timeCheck` required of a provider publishing a running instant (`manifest.timeCheck.required`), `Snapshot.providerTime` with it (`snapshot.providerTime`, `.unexpected`) |
 
 Update producers, consumers, saved task snapshots, and validation-rule assertions together.
 History and report rule names use `history` and `historyReport`; assignment rules use
@@ -3377,28 +3408,39 @@ caller to somebody else.
 
 An agent on a call promises to call back on Thursday, or in wrap writes up that the customer wants
 a callback once the refund lands. The follow-up goes on the calendar, and the platform owns the
-calendar: `schedule` asks the provider to put it there.
+calendar: `schedule` asks the provider to put it there. A chat or an email agent promises a
+callback as often, so the control is on every channel.
 
 ```ts
-// From the call, or from its wrap: the time, and a note where the agent wrote one.
+// From the call or the conversation, or from its wrap: the time, and a note where the agent wrote one.
 { type: "schedule", at: "2026-08-28T10:00:00Z", note: "Call back about the refund" }
 ```
 
 `schedule` is gated by the `schedule` capability and issuable in `in-progress`, `paused` or
 `completing` (`command.phase.interaction`): a follow-up is promised on the call and written up in
-wrap alike, and the task names the party it is for. `applied` says the provider has taken it; the
-activity itself arrives on `calendar-updated`, which is the provider's word that it stands, as
-every calendar entry does. The command carries a time and a note and nothing else
+wrap alike, and the task names the party it is for. It lands on the calendar, so a task may offer
+it only under a manifest that declares the `calendar` idle capability
+(`task.capability.calendar.required`), as a control that dials needs `dialOutcomes`; a locked
+`schedule` is still a declared one. The command carries a time and a note and nothing else
 (`command.schedule.at`, `command.schedule.note`, `command.field`): what the platform makes of a
 follow-up -- a campaign record, a reminder, a scheduled dial -- is its own, and the agent sees it
 on the calendar.
 
+**`applied` says the follow-up is on the calendar**, and the `calendar-updated` that shows it
+follows within the manifest's `settleMs`, as a `task-ended` follows an applied `complete`. Past
+the bound the agent application calls `snapshot()`: a calendar carrying an activity at that instant
+clears the wait; one without it shows the follow-up as unsettled -- "Scheduled... the provider has
+not confirmed" -- naming the command. The drive schedules one follow-up where the task offers it,
+at a time it takes from the provider's own publication, and holds the provider to the same bound
+(`drive.schedule.unsettled`).
+
 ### Chat capabilities
 
 | Capability | Omni UI | Contract |
 | --- | --- | --- |
 | `decline` | Pending-task button: Decline | The provider can decline a pending chat offer. Omni shows it only when local policy also permits declining. |
 | `hold` | Primary toggle: Hold | Omni may pause and resume the agent’s interaction in the chat. |
+| `schedule` | Secondary menu item: Schedule | Omni may put a follow-up for this party on the calendar, from the conversation or from its wrap. See **Scheduling a follow-up**. |
 | `outcomes` | Primary button: Complete | Omni may request task completion with a provider outcome and notes. |
 
 ### Email capabilities
@@ -3406,6 +3448,7 @@ on the calendar.
 | Capability | Omni UI | Contract |
 | --- | --- | --- |
 | `decline` | Pending-task button: Decline | The provider can decline a pending email offer. Omni shows it only when local policy also permits declining. |
+| `schedule` | Secondary menu item: Schedule | Omni may put a follow-up for this party on the calendar, from the message or from its wrap. See **Scheduling a follow-up**. |
 | `outcomes` | Primary button: Complete | Omni may request task completion with a provider outcome and notes. |
 
 ### Custom capabilities
@@ -3715,14 +3758,14 @@ The team break command formerly named release is now `end-forced-break`, and its
 `team.break.command.endForcedBreak`. The former release command and the interim end spelling are rejected without aliases.
 The agent’s `endBreak` now applies to forced breaks as well as requested breaks.
 
-`ForcedBreak` names who forced the break and may include an advisory `expectedDurationMs`.
-The agent must explicitly resume when ready. The retired endsAutomatically and endsAt fields
-are rejected, including when an expected duration is also provided.
-
-**Every forced break has a person behind it.** A lead or a manager forced it; there is no such
-thing as a break the platform forced on its own. Where a platform applies one automatically, it is
-executing a preference somebody configured, and that person is the owner of the action — `by` names
-them, not the machinery that carried it out.
+`ForcedBreak` names who forced the break and may say how long it is expected to run yet, as
+`expectedEndsInSeconds`: whole seconds from the publication that carries it, restated on every
+publication, so every screen -- the agent's, reloaded or not, and every lead's -- counts down the
+same number from receipt (`break.forced.expectedEndsInSeconds`). The duration the lead asked for
+travels on the `force-break` command alone; the state says what is left, and drops the field once
+it has run out. The agent must explicitly resume when ready. The retired endsAutomatically and
+endsAt fields are rejected, including when an expectation is also provided. Who forced it is
+`by`, as **A forced break is the provider's act** below sets out.
 
 Omni resolves the name to show with `getUserDetails()`, so a provider sends the identifier and never
 a display name.
@@ -3737,16 +3780,24 @@ For example:
 ```ts
 forced: {
   by: "manager-1042",
-  expectedDurationMs: 600000
+  expectedEndsInSeconds: 600
 }
 ```
 
 The agent application keeps **Resume** available for an agent on a forced break. The agent explicitly chooses
 Resume; the agent application sends `endBreak()` and follows the provider-confirmed state before resuming
-work. An expected duration is a positive finite number of milliseconds, measured from actual
-entry into `on-break`, excluding any `starting-after-task` wait. Omission means no expected
-duration was supplied. Neither duration expiry nor an overdue indication authorizes the agent application
-or provider to end the break, restore availability, or route work to the agent.
+work. The expectation is whole seconds still to run, restated on every publication; omission
+means none was stated, or it has run out. Neither its reaching zero nor an overdue indication
+authorizes the agent application or provider to end the break, restore availability, or route
+work to the agent.
+
+**A forced break is the provider's act.** A lead's `force-break` is a command to the provider,
+which forces the break on the member; `by` names the lead who asked it to. A break the platform
+imposed on its own -- a schedule, a compliance hold -- says `by: "provider"`, and is the platform's
+to lift: a lead's `end-forced-break` on it is refused before it is sent
+(`team.command.endForcedBreak.provider`), and a provider that receives one answers `failed` with
+`omni.break-forced-by-provider`. The desk offers End forced break on a member only where
+`forced.by` names a lead.
 
 **A lead lifting the restriction does not resume the agent.** On an applied
 `end-forced-break`, the provider clears `BreakState.forced` while preserving the current
@@ -3762,18 +3813,25 @@ must correlate resumption to the authenticated agent's action; a state-only orde
 cannot establish the cause of a transition. The usual multi-provider end/reconciliation flow
 still applies, and work resumes only on confirmed provider state.
 
-An agent application may display the expected duration. A countdown requires an evidenced actual start;
-a received snapshot, replay or reconnect is not a new start and cannot restart the duration.
-Without that evidence, show the duration without inventing a start or return time.
-
-A break applies to the **agent**, not to one provider. When a provider forces one, Omni immediately
-requests a break on every other connected provider, or they would keep routing work to somebody who
-is not there. On those providers it is the agent's own request, made through `requestBreak` like
-any other, and the provider grants or denies it as its policy says. **The agent application
-guarantees the agent cannot cancel those requests, or end the breaks they become,** while the
-forced break stands: the agent did not ask for them, and a break one provider imposed is not one
-the agent may lift on another. When the forcing provider ends the forced break, the agent
-application ends the follow-on breaks it made. Providers should expect that follow-on request.
+An agent application counts `expectedEndsInSeconds` down from receipt, on every publication that
+carries it, and shows nothing of it where the provider sends none. It invents no start and no
+return time, and nothing acts on the number reaching zero.
+
+A break applies to the **agent**, not to one provider. When a provider forces one, Omni stops the
+agent everywhere else at once, and not by asking: it states `setCapacity({ count: 0 })` on every
+other usable provider holding capacity, which is taken and never refused, and which their team
+lists show as `elsewhere`. Nobody on those providers can deny it, and the agent cannot cancel it,
+because there is nothing to cancel: a break request on them would be the agent's own to withdraw
+and a lead's to refuse, and a forced break is neither. When the forcing provider ends the forced
+break and the agent resumes there, the agent application restates its capacity on the rest. A
+provider whose login is not usable is left alone, as a break attempt leaves it;
+`assertForcedBreakStopsTheRest` holds an agent application to this set. **The provider keeps its
+shift totals true.** A member held elsewhere is one the provider sees -- `elsewhere` is a state it
+publishes -- and the day's `shift` is its own account of the day, so the time the agent was
+stopped for a break forced on another provider is the provider's to count, as a break of a kind
+its platform has, or introduces, for exactly this. A `breakSeconds` that leaves it out is a total
+the provider knew to be short, and **Never report a value you cannot observe** cuts the other way
+here: the provider observed it.
 
 `ForcedBreak.by` says who forced it: a lead, by user id, or `provider` where the platform itself
 did -- on its own rule, a schedule, a compliance hold. The agent sees who, and `getUserDetails()`
@@ -4163,10 +4221,10 @@ computes nothing. See **`team-updated`** and its companions.
 | `availability` | Required. What the member is doing now. |
 | `since` | Optional. When the current `availability` began — not when they signed in, and not when the team member list was read. |
 | `break` | Present only while the member has an outstanding break request. See **A member waiting for a break**. |
-| `tasks` | The member's open tasks as `MemberTask`s: the same task the member's desk holds, trimmed by the provider. The assignment, title, task type, phase, party, room and audio are what the lead reads; the task's history is carried in the same shape as on the member's desk, as much of it as the provider chooses to send; the workspace — controls, their source, browsers, completion terms — is the member's and travels only if the provider sends it. `[]` when the member holds none; omitted only where the provider cannot see them. |
-| `listening` | Present while this lead's channel is in this member's call — listening, coaching or joined — naming which of the member's calls by `assignmentId`, the `mode` they are heard in, and since when. Its appearance is what the lead's audio opens on. One member's call at a time (`team.listening.single`). |
+| `tasks` | The member's open tasks as `MemberTask`s: the same task the member's desk holds, trimmed by the provider. The assignment, title, task type, phase, party, room and audio are what the lead reads, and the task's record -- `history`, steps and totals -- travels whole, exactly as the member's desk holds it, so the lead's screen and the member's show the same record; only the workspace — controls, their source, browsers, completion terms — is the member's and travels only if the provider sends it. `[]` when the member holds none; omitted only where the provider cannot see them. |
+| `listening` | Every lead on this member's call — listening, coaching or joined — published to every lead alike: each entry names the lead by `leadId`, which of the member's calls by `assignmentId`, the `mode` they are heard in, and since when. The entry naming the signed-in lead is what their own audio opens on. Absent while nobody is on the call, never `[]` (`team.member.listening.*`); a lead is on one member's call at a time (`team.listening.single`), and a lead who is heard is also in the task's `onCall` (`team.member.listening.heard`). |
 | `request` | Present while the member is asking a lead to join one of their calls: which assignment, the note they wrote, since when. The call named is one their `tasks` carry (`team.member.request.assignment`). Absent when they are not asking. See **Lead assist**. |
-| `shift` | The member's own history for the day, about the person rather than any one call: `signedInAt`, `signedOutAt` once it has happened, today's totals as the provider counts them — `talkSeconds`, `holdSeconds`, `breakSeconds`, `tasksHandled`, each present only when the provider knows it — and the day's sign-in, sign-out and break `events`, oldest first. Omitted where the provider cannot say. |
+| `shift` | The member's own history for the day, about the person rather than any one call: `signedInAt`, `signedOutAt` once it has happened, today's totals as the provider counts them — `talkSeconds`, `holdSeconds`, `breakSeconds`, `tasksHandled`, each present only when the provider knows it — and the day's sign-in, sign-out and break `events`, oldest first. The same `Shift` the member's own snapshot carries, the same numbers from the same count. Omitted where the provider cannot say. |
 
 Each availability value means one thing:
 
@@ -4189,11 +4247,19 @@ by it, as a colleague signing in is. `team-member-removed` takes one off. Never
 member, never a task of theirs on its own: a hold on a member's desk is that member republished
 whole on the lead's, and nothing else on the lead's screen moves.
 
+**The agent's day is on the wire.** The lead sees `shift` totals as the provider counts them, and
+the agent sees the same: `Snapshot.shift` and `shift-updated` carry the agent's own day in the same
+shape, from the same count, so "calls today: 12" is one number on both screens. The desk computes
+nothing of the day; `tasksHandled` moves when a task ends and `talkSeconds` when a leg closes, and
+the active call's running time is the screen's own until then, as **Every screen counts from the
+provider's clock** sets out.
+
 **Omit `since` rather than inventing one.** Omni renders it as a duration, so a timestamp
 synthesised from the adapter's own clock at seed time reads as "on task for 0 seconds" for
 everybody — worse than showing nothing, because it looks like data. Send it only when the provider
 knows when the state actually began. It times the current `availability`, so it moves every time
-that value does.
+that value does. And it is counted from the provider's clock, never the screen's, so a provider
+that publishes it declares `timeCheck` -- see **Every screen counts from the provider's clock**.
 
 **The login is the permission.** A team member list goes to a login that declares
 `capabilities.lead`, once the team feature is on, and to nobody else. Omni never decides who
@@ -4241,7 +4307,7 @@ assignment from the member alone.
 | `{ type: "decide-break-request", memberId, decision, reason? }` | Settles one pending request. `decision` is `granted` or `denied`. A grant moves the member to `granted`; a denial ends the request and moves it directly to `not-requested`. |
 | `{ type: "set-break-policy", policy }` | `approval-required`, `automatically-approved`, or `requests-suspended`. |
 | `{ type: "force-break", memberId, reasonId?, reason?, expectedDurationMs? }` | Puts a member on a break they did not ask for. `reasonId` names a published `BreakReason.id` and is required whenever the provider publishes `reasons`; the member's forced break carries it as `activeReasonId`, so its kind is known. Optional `expectedDurationMs` is advisory and is published on the resulting forced break. |
-| `{ type: "end-forced-break", memberId }` | Lifts the forced-break restriction, whoever forced it, by clearing `BreakState.forced`. The committed break continues; only the agent resumes work. |
+| `{ type: "end-forced-break", memberId }` | Asks the provider to lift a forced-break restriction a lead asked for, by clearing `BreakState.forced`; one the platform imposed is its own to lift (`team.command.endForcedBreak.provider`, `omni.break-forced-by-provider`). The committed break continues; only the agent resumes work. |
 | `{ type: "join", memberId, assignmentId? }` | Answers the member's request: the provider bridges the lead's channel into the call. See **Lead assist**. |
 | `{ type: "decline", memberId, assignmentId?, reason? }` | Refuses the member's request. |
 | `{ type: "listen", memberId, assignmentId? }` | The lead's channel joins the member's call unasked, in silence. See **Listening to a call**. |
@@ -4286,9 +4352,10 @@ executeTeam({ command: { type: "decline", memberId: "A-1", reason: "In a call" }
 ```
 
 **On `join` the provider bridges the lead's channel into the call.** The member's task moves to
-`leadAssist: { stage: "joined", leadId }`, the member on the team member list carries
-`listening: { assignmentId, mode: "join-call", since }`, and the lead's audio opens on it as
-**Listening to a call** describes. Nothing is a task on the lead's desk: a join is the lead's act on the team surface, not
+`leadAssist: { stage: "joined", leadId }` and its `onCall` gains the lead as an `agent`, since a
+lead who is heard is in the room; the member on the team member list carries
+`listening: [{ leadId, assignmentId, mode: "join-call", since }]`, and the lead's audio opens on
+it as **Listening to a call** describes. Nothing is a task on the lead's desk: a join is the lead's act on the team surface, not
 work assigned to them.
 
 **A lead is on one member's call at a time.** A `join` from a lead already on a call -- their own
@@ -4356,10 +4423,11 @@ history. The three modes determine who hears the lead:
 All three come with the `lead` flag; a centre reserves none of them per lead.
 
 **There is no team audio.** Audio is the agent's or the lead's, and the lead's audio while
-listening follows the provider's published state exactly as a task's does: `listening` on the
-member is the provider's word that the lead's channel is in the call. When it appears, the
-application opens `openAudio({ assignmentId })` on the lead's connection for the call it names,
-and plays the `CallAudio` returned; when it goes, the application closes it. Nothing else says
+listening follows the provider's published state exactly as a task's does: the entry naming this
+lead in `listening` on the member is the provider's word that the lead's channel is in the call.
+When it appears, the application opens `openAudio({ assignmentId })` on the lead's connection for
+the call it names, and plays the `CallAudio` returned; when it goes, the application closes it.
+Another lead's entry opens nothing: it is shown, and that is all. Nothing else says
 when the lead's audio is up, and a reload reopens it from the snapshot's team member list as a task
 carried with `audio: "started"` is reopened.
 
@@ -4370,13 +4438,15 @@ The flow, end to end:
 // 2. The lead's channel joins it in silence. Conditions: the lead's voice channel is free --
 //    not on a call, not listening elsewhere. Capacity is not involved: nothing is assigned.
 executeTeam({ command: { type: "listen", memberId: "A-1", assignmentId: "alloc-42" } })
-// 3. The provider publishes the member whole on team-member-updated; the member carries
-//    listening: { assignmentId: "alloc-42", mode: "listen", since }
-//    -- the application opens openAudio({ assignmentId: "alloc-42" }) on the lead's connection.
-// 4. The lead changes how they are heard; the member is published again with the new listening.mode. The audio stays open.
+// 3. The provider publishes the member whole on team-member-updated, to every lead; the member carries
+//    listening: [{ leadId: "L-9", assignmentId: "alloc-42", mode: "listen", since }]
+//    -- L-9's application opens openAudio({ assignmentId: "alloc-42" }) on its own connection; every
+//    other lead's shows L-9 on the call and opens nothing.
+// 4. The lead changes how they are heard; the member is published again with the entry's new mode. The audio stays open.
+//    join-call is heard by everyone, so the member's task is also republished with L-9 on onCall as an agent.
 executeTeam({ command: { type: "coach", memberId: "A-1" } })
 executeTeam({ command: { type: "join-call", memberId: "A-1" } })
-// 5. The lead leaves: the provider publishes the member without listening; the application closes the audio.
+// 5. The lead leaves: the provider publishes the member without L-9's entry, and the task without L-9 in the room; the application closes the audio.
 executeTeam({ command: { type: "leave", memberId: "A-1" } })
 // 6. The member's call ends: the same as leave, from the provider's side.
 // 7. The lead takes the call: the member loses listening no later than the offer, the application
@@ -4387,22 +4457,29 @@ executeTeam({ command: { type: "take-over-call", memberId: "A-1" } })
 // 8. A join on the member's request is the same flow entered at step 3 with mode: "join-call",
 //    and the member's task shows leadAssist: joined.
 // 9. A reload of the lead's application: the switch is sent again, the team-updated that follows
-//    still carries listening on the member, so the audio is reopened.
+//    still carries this lead's entry in listening on the member, so the audio is reopened.
 ```
 
-**`listening` on the member is the state**, restated on every change of mode, naming the call so
-the application knows which audio to open (`team.member.listening.assignmentId`, and one the
-member's tasks carry, `team.member.listening.assignment`), and a lead is on one member's call at a
-time (`team.listening.single`).
+**`listening` on the member is the state**, one entry per lead on the call, restated on every
+change of mode, naming the lead (`team.member.listening.leadId`, once per member,
+`team.member.listening.unique`) and the call, so the application knows which audio is its own to
+open (`team.member.listening.assignmentId`, and one the member's tasks carry,
+`team.member.listening.assignment`). Every lead sees every entry: a silent lead is hidden from
+the agent, never from the other leads and managers watching the same member on other screens.
+A lead is on one member's call at a time (`team.listening.single`).
 
 **A lead listens while holding no call of their own.** Omni offers Listen to a lead whose voice
 channel is free, and a provider answers a `listen` from one whose channel is not `failed`. That
 includes a lead on a break: a lead working as lead alone is on a break of a working kind, and
 listens through it.
 
-**Nothing reaches the member.** The member's task carries no trace of a listening lead in any
-mode: not on `onCall`, not in the record. Whether coaching is announced to the agent is the
-platform's business and travels on the audio, not on this wire.
+**A silent lead reaches nobody but the leads.** In `listen` and `coach` the member's task carries
+no trace of the lead: not on `onCall`, not in the record. Whether coaching is announced to the
+agent is the platform's business and travels on the audio, not on this wire. In `join-call`, and
+on a `join` answering a request, the lead is heard by everyone and is in the room: the task's
+`onCall` carries them as an `agent` by user id, on the member's desk and on every lead's copy of
+the task alike, and `leave` takes the entry off as it takes the channel off
+(`team.member.listening.heard`).
 
 ### A member waiting for a break
 
@@ -4756,9 +4833,9 @@ declared:
 | `conference` with `action: "remove"` | The `conference` capability, and somebody else on the call: a remove that would leave the agent alone is `end-call`, and a provider answers it `failed`. |
 | `decline` | The `decline` capability on any channel, **and** Omni local policy permitting it. One word for refusing an offer, whatever the channel. |
 | `dial` | The `preview` phase. A record put in front of an agent is there to be called, so the phase is the gate and there is no capability. It is a dial, with a `dialId` and a `dial-outcome`. |
-| `complete` | A wrap to cut short: any task but one with `wrapAllowance: 0`, under either completion mode (`command.complete.wrapAllowance`). The `outcomes` capability decides whether a code travels with the command, never whether the command exists — a task Omni cannot complete never ends. What travels is what the capability published: a code from its list where it has one (`command.complete.outcome.unknown`), a code at all where it requires one (`.outcome.required`), notes as it said (`.notes.required`, `.notes.unexpected`), and neither where the task declares no outcomes (`.outcome.unexpected`). |
+| `complete` | A wrap to cut short: any task but a `provider-automatic` one with `wrapAllowance: 0`, under either completion mode (`command.complete.wrapAllowance`). The `outcomes` capability decides whether a code travels with the command, never whether the command exists — a task Omni cannot complete never ends. What travels is what the capability published: a code from its list where it has one (`command.complete.outcome.unknown`), a code at all where it requires one (`.outcome.required`), notes as it said (`.notes.required`, `.notes.unexpected`), and neither where the task declares no outcomes (`.outcome.unexpected`). |
 | `connect-back` | The `connectBack` capability **and** the `completing` phase. It exists to reach the party again after the call, so it has no meaning while the call is up. |
-| `schedule` | The `schedule` capability, in `in-progress`, `paused` or `completing`: a follow-up is promised on the call and written up in wrap alike. |
+| `schedule` | The `schedule` capability, on any channel, in `in-progress`, `paused` or `completing`: a follow-up is promised on the call and written up in wrap alike. The manifest declares `calendar` for it to land on. |
 | `lead-assist` with `action: "request"` or `"cancel"` | The `leadAssist` capability. `cancel` needs a request standing -- `Task.leadAssist` with status `requested`. |
 | `conference` with `action: "add"` | Its capability, and a `destinationId` the directory offered: the id Omni sends is the id the provider published (`command.destination.unknown`). |
 | `custom` | A control the task published under `capabilities.custom`, by its `id` (`command.capability.custom`), carrying a non-empty string for each `required` prompt field and strings for any optional fields supplied (`command.custom.prompt`). A toggle carries its target `on` boolean (`command.custom.on`). |
@@ -4884,6 +4961,24 @@ must specify their uncertainty and validity; elapsed time should use monotonic a
 jump invalidates the estimate. The optional check below samples provider time without changing event timestamps. Report
 source-measured durations where required; timestamp subtraction is not a substitute.
 
+#### Every screen counts from the provider's clock
+
+Two screens watching the same agent -- their own desk, their lead's, a manager's on another floor
+-- must show the same numbers. Delay between them is fine; arithmetic that differs is not. So
+nothing the desk shows is its own count, with one exception: the running duration of the active
+task or call, which each screen times from the moment it saw the call begin, and which two screens
+may therefore disagree on, since their clocks differ. Everything else comes from the wire.
+
+Durations off the active call -- how long a member has been `on-break` from their `since`, how
+long a lead has been listening, how long since `signedInAt` -- are counted from the provider's
+clock, never the screen's. The desk keeps the latest provider instant it has received -- a
+snapshot's `providerTime`, an envelope's `occurredAt`, a `checkTime` result -- with the monotonic
+elapsed time since receipt, and renders every such duration from that; a sample older than
+`maxSampleAgeMs` is refreshed with `checkTime`. Without a usable sample the desk shows the instant
+and no count. A provider that publishes any of these instants therefore declares `timeCheck`
+(`manifest.timeCheck.required`) and states `providerTime` on every snapshot
+(`snapshot.providerTime`). Two screens then differ by their delay and nothing else.
+
 #### Optional periodic provider time checks and agent application estimates
 
 A provider may declare `Manifest.timeCheck: true` and implement `Connection.checkTime(request)`.
@@ -5170,7 +5265,7 @@ take-over as it follows an `end-call` -- see **Lead assist**.
 A successful `complete` command does not clear the task. Omni waits for `task-ended`,
 and not for ever: `applied` to a `complete` says the
 provider has completed the task, and its `task-ended` follows within the
-manifest's `completionSettleMs`. A provider never answers `applied` for a completion it has not yet
+manifest's `settleMs`. A provider never answers `applied` for a completion it has not yet
 performed. Past the bound the agent application calls `snapshot()`: a snapshot still carrying the task is a task
 held open by a provider that said it was done, and the desk shows it as unsettled -- "Completing...
 the provider has not confirmed" -- naming the command; a snapshot no longer carrying it clears the
@@ -5269,6 +5364,13 @@ the `contacts` idle capability.
 Replaces this provider's complete scheduled-activity contribution. It is emitted only when the manifest
 declares the `calendar` idle capability.
 
+### `shift-updated`
+
+The agent's own day, whole, replacing `Snapshot.shift`: emitted whenever a total moves -- a task
+ended, a break ended, a sign-out -- and never to say nothing changed. It carries the same `Shift`
+the agent's lead sees for them on the team member list, so the two screens show one day. See
+**The agent's day is on the wire**.
+
 ## Utilities
 
 ### `assignmentKey(providerId, assignmentId)`
@@ -5333,7 +5435,9 @@ carries that agent reports `team.member.self`, on a `team-member-updated` and a
 reports `team.unentitled`, and a team event to such a login reports `event.team.capability`; given
 `leadFeatures: true`, a snapshot without a team reports `team.required`, and given `leadFeatures: false`,
 anything of the team reaching the lead reports `team.unexpected` or `event.team.features`. Without them those rules are not checked, because they cannot be.
-`exerciseAdapter` passes all three, holding the switch off until it has sent it.
+`exerciseAdapter` passes all three, holding the switch off until it has sent it. Given the manifest, a
+snapshot or event that carries an instant the desk renders as a running duration under a manifest
+without `timeCheck` reports `manifest.timeCheck.required`.
 
 `assertNoViolations(violations)` throws `ProtocolConformanceError` — which carries the full
 `violations` array — when the list is non-empty.
@@ -5515,6 +5619,7 @@ cannot be established from TypeScript structure alone.
 | `assertBreakFollowsItsRequests(envelopes, snapshot?)` | A break follows its requests: a commit's states only after a grant, never backwards, and a forced break arriving in effect with `forced`. The harness applies the same rules after the connect snapshot. |
 | `assertAudioFollowsTheTask(envelopes, snapshot?)` | The audio follows the task and never decides it: every task is introduced once, `task-audio-started` and `task-audio-ended` alternate on work that has begun, audio ends only where it arrived, and what follows the audio ending is `completing` or `task-ended`. The harness applies the same rules to every event after the connect snapshot (`stream.*`). A sequence with no audio satisfies it by never testing it — pair it with the assertion that the audio end is present. |
 | `assertBreakAttemptProviders(candidates, asked)` | A break attempt asks every usable provider holding capacity, `refreshing` included, and nothing of a provider whose login is `expired`. |
+| `assertForcedBreakStopsTheRest(forcedOn, candidates, stopped)` | A forced break on one provider stops the agent everywhere else: capacity zero stated on every other usable provider holding capacity, nothing on the forcing one, nothing on a dead login. See **Forced breaks**. |
 | `assertBreakBeginsAfterTask(steps)` | A break asked for on a task is committed as `starting-after-task` while work remains and reaches `on-break` only once nothing is outstanding — never beside a task, never later than the step that has none. |
 | `assertDeniedAndRetriedBreak(states)` | A denial transitions directly to `not-requested`; a later request can still be granted. |
 | `assertWrapTimeout(task, audioEndedAt, deadline, toleranceMs?)` | The wrap deadline equals audio end plus the task allowance, within a tolerance that defaults to 1000ms; a task with no allowance has no deadline, and one observed is the violation. |