@xema/omni-protocol 0.1.98 → 0.1.100

package/guide.md

@@ -23,7 +23,7 @@ are used precisely throughout and mean nothing looser here.
 | **Provider** | One independently connected external system: a voice platform, a chat platform, a mail platform. |
 | **Adapter** | The package implementing this contract for one provider. One adapter is one provider, so the words are often interchangeable; *provider* names the system, *adapter* the code speaking for it. |
 | **Agent** | The person signed in and taking work. On `onCall`, `agent` is a person on the call by user id; transfer destinations may include an agent when the provider publishes that directory item. |
-| **Lead** | An agent whose login declares `capabilities.team`. The provider publishes a `TeamMembers` object to them and to nobody else: **the login is the permission**. |
+| **Lead** | An agent whose login declares `capabilities.lead`. The flag alone turns on the team feature in the agent application: the lead sees their members with their tasks and stats, and acts on them with the authority the flag carries. While the feature is on, the provider publishes a `TeamMembers` object to them and to nobody else: **the login is the permission**. |
 | **Local policy** | Rules configured by the agent application about this agent, outside the provider protocol and never sent to a provider. It gates whether an offer may be rejected, whether the agent goes ready on login, and whether tasks are auto-accepted. Where a capability and local policy disagree, the stricter wins. |
 | **Call** | The caller’s complete phone call, which may continue through IVRs, queues and several agents. The protocol never describes the IVR or the queue; it carries the call's history and details to whichever agent holds it now. |
 | **Assignment** | The call routed to this agent, from the offer until the task ends. It is the one thing that crosses: the provider assigns, names the assignment with `assignmentId`, and that is the only name the desk ever uses back. A call that comes back is a new assignment on the same call, and a declined or lapsed offer is an assignment that became nothing more. What the platform calls its own record, and whether it reuses that name, is the adapter's business and unknown to the desk. |
@@ -41,7 +41,7 @@ are used precisely throughout and mean nothing looser here.
 | **Break** | A reported, supervised state in which the agent is not working — one with a reason, a decision behind it and a return. It covers what a platform may call *not-ready*, including equipment trouble. An agent who is merely at capacity is not on a break. |
 | **Workspace** | What Omni shows the agent. The **task workspace** holds the selected task, its controls and its browsers; the **idle workspace** holds what a provider contributes when no task is selected — dialpad, contacts, calendar, team member list. |
 | **Dial** | One outbound call the agent application asks a provider to place — from the idle dialpad, a cold or warm transfer, a conference add, or a connect-back. Identified by the agent application's `dialId`, accepted as `dialling`, and ended by exactly one `dial-outcome`. See **Every dial has an outcome**. |
-| **Listen** | A lead listening to a member's call unasked, from the team member list: `listen` in silence, `coach` heard by the agent alone, `join-call` heard by everyone. Nothing of it reaches the member's task, and there is no take-over in it. See **Listening to a call**. |
+| **Listen** | A lead's channel in a member's call, unasked, from the team member list: `listen` in silence, `coach` heard by the agent alone, `join-call` heard by everyone. It is a team act naming the member, never a task on the lead's desk; nothing of it reaches the member's task. A lead who wants the call takes it over. See **Listening to a call**. |
 | **On the call** | Who a voice task's audio joins, or is bringing in, as the provider states it on `Task.onCall`: the party, the agents, and anyone consulted or conferenced in from the moment their dial is placed. |
 
 These fields describe state within their containing objects. Both authentication and break
@@ -50,7 +50,7 @@ state use `status`; name the object when discussing them to avoid ambiguity.
 | Word | Belongs to | Values |
 | --- | --- | --- |
 | `phase` | A task | `pending`, `confirmed`, `preview`, `in-progress`, `paused`, `completing` |
-| `media` | A task's audio | `started`, `ended` |
+| `audio` | A task's audio | `started`, `ended` |
 | `transport` | A connection | `connecting`, `active`, `error` |
 | `status` | An authentication session | `signed-out`, `authenticating`, `authenticated`, `refreshing`, `expired` |
 | `status` | The agent’s break lifecycle | `not-requested`, `awaiting-approval`, `granted`, `starting-after-task`, `on-break` |
@@ -252,17 +252,10 @@ type AuthenticationContext = {
 
 type ListeningMode = "listen" | "coach" | "join-call";
 
-type TeamCapabilities = {
-  breakControl?: true;
-  leadAssistControl?: true;
-  listeningControl?: ListeningMode[];
-  policyControl?: true;
-};
-
 type UserCapabilities = {
   breaks?: true;
   preferences?: AgentPreference[];
-  team?: TeamCapabilities;
+  lead?: true;
 };
 
 type AuthenticationState =
@@ -309,7 +302,7 @@ interface RecordingActions {
 }
 interface TaskRecordingPolicy {
   provider?: RecordingActions;
-  host?: RecordingActions & { destinationId: string };
+  host?: RecordingActions & { storageId: string };
 }
 type RecordingState =
   | { status: "unknown"; observationId?: never; observedAt?: never; validUntil?: never; recordingId?: never }
@@ -333,7 +326,7 @@ interface HostRecordingReport {
 interface HostRecording {
   announcesToCaller?: true;
   actions: RecordingAction[];
-  destinationIds: string[];
+  storageIds: string[];
   execute(request: HostRecordingRequest): Promise<RecordingCommandResult>;
 }
 type RecordingCommandResult = Exclude<TaskCommandResult, { status: "dialling" }>;
@@ -486,7 +479,7 @@ type Snapshot = {
   tasks: Task[];
   taskCount: number;
   contacts?: Contact[];
-  scheduledActivities?: ScheduledActivity[];
+  calendar?: ScheduledActivity[];
   team?: TeamMembers;
 };
 
@@ -569,6 +562,7 @@ type TaskCapabilities<C extends Channel = Channel> =
         decline?: Lockable<true>;
         hold?: Lockable<true>;
         endCall?: Lockable<true>;
+        terminateCall?: Lockable<true>;
         connectBack?: Lockable<true>;
         coldTransfer?: Lockable<DestinationDirectory>;
         warmTransfer?: Lockable<DestinationDirectory>;
@@ -697,17 +691,8 @@ type TaskLeadAssist = { note?: string; since: IsoTimestamp } & (
   | { stage: "joined"; leadId: UserId }
 );
 
-type TaskAssisting = {
+type TaskTakenOver = {
   memberId: UserId;
-  assignmentId: AssignmentId;
-  note?: string;
-  since: IsoTimestamp;
-};
-
-type TaskListening = {
-  memberId: UserId;
-  assignmentId: AssignmentId;
-  mode: ListeningMode;
   since: IsoTimestamp;
 };
 
@@ -725,9 +710,9 @@ type Locked = {
 
 type Lockable<T> = T | Locked;
 
-type TaskMediaState = "started" | "ended";
+type TaskAudioState = "started" | "ended";
 
-type CapabilitySource = "queue" | "ungoverned" | "undetermined";
+type CapabilitySource = "queue" | "nobody" | "not-yet-read";
 
 type Task<C extends Channel = Channel> = {
   assignmentId: AssignmentId;
@@ -747,11 +732,11 @@ type Task<C extends Channel = Channel> = {
   history?: TaskHistory;
 } & TaskCompletion & (
   C extends "voice"
-    ? { recording?: { provider?: RecordingState }; onCall?: OnCall[]; leadAssist?: TaskLeadAssist; assisting?: TaskAssisting; listening?: TaskListening; media?: TaskMediaState }
-    : { recording?: never; onCall?: never; leadAssist?: never; assisting?: never; listening?: never; media?: never }
+    ? { recording?: { provider?: RecordingState }; onCall?: OnCall[]; leadAssist?: TaskLeadAssist; takenOver?: TaskTakenOver; audio?: TaskAudioState }
+    : { recording?: never; onCall?: never; leadAssist?: never; takenOver?: never; audio?: never }
 );
 
-type PreviewDeadline = "calls" | "host-calls" | "waits";
+type PreviewDeadline = "provider-dials" | "host-dials" | "waits";
 
 type AcceptanceMode =
   | "no-preference"
@@ -764,7 +749,6 @@ type TaskOutcome =
   | { type: "taken-over"; leadId: UserId }
   | { type: "cancelled"; by: "agent" | "provider" | "party"; reason?: string }
   | { type: "expired"; phase: "pending" | "confirmed" | "preview" }
-  | { type: "left" }
   | { type: "failed"; failure: ProtocolFailure };
 ```
 
@@ -775,10 +759,11 @@ const TASK_COMMAND_NAMES = {
   voice: [
     "answer",
     "decline",
-    "call",
+    "dial",
     "hold",
     "resume",
     "end-call",
+    "terminate-call",
     "connect-back",
     "transfer",
     "lead-assist",
@@ -798,10 +783,11 @@ type OutcomePayload = { outcome?: string; notes?: string };
 type VoiceTaskCommand =
   | { type: "answer" }
   | { type: "decline" }
-  | { type: "call"; dialId: DialId }
+  | { type: "dial"; dialId: DialId }
   | { type: "hold" }
   | { type: "resume" }
   | { type: "end-call" }
+  | { type: "terminate-call" }
   | { type: "connect-back"; dialId: DialId }
   | { type: "transfer"; action: "cold"; dialId: DialId; destinationId: string }
   | { type: "transfer"; action: "warm"; dialId: DialId; destinationId: string }
@@ -809,8 +795,6 @@ type VoiceTaskCommand =
   | { type: "transfer"; action: "cancel" }
   | { type: "lead-assist"; action: "request"; note?: string }
   | { type: "lead-assist"; action: "cancel" }
-  | { type: "lead-assist"; action: "take-over-call" }
-  | { type: "lead-assist"; action: "leave" }
   | { type: "conference"; action: "add"; dialId: DialId; destinationId: string }
   | { type: "conference"; action: "remove"; destinationId: string; party?: never }
   | { type: "conference"; action: "remove"; party: true; destinationId?: never }
@@ -901,12 +885,12 @@ pass. An agent application never has the value and never asks. A name is not loc
 controls — is content, and is never locked.
 
 **A lead sets the team's policy from their team member list.** A login that declares
-`capabilities.team.policyControl` may `executeTeamPolicy({ type: "set", capability, setting })`
+`capabilities.lead` may `executeTeam({ command: { type: "set-policy", capability, setting } })`, where the provider offers policy control and says so by publishing `policies`,
 with `on`, `off`, or `person`, for any task control, `dial`, or a skill — and only `hold`
 and skills may be `person`; connect back and new call are the team's, on or off, within what the queue
 allows. The team member list carries `policies` for such a login: every policy as it stands, who set it, and
 `lockedBy` where a level above the team made it theirs to keep, which the lead sees and cannot
-change — `executeTeamPolicy` on it answers `failed` with `omni.capability-not-enabled`.
+change — `set-policy` on it answers `failed` with `omni.capability-not-enabled`.
 
 **What the team left to the person is the person's, and the provider keeps it.** The login's
 `capabilities.preferences` lists every preference the person may hold — `hold`, a skill —
@@ -984,26 +968,51 @@ type BreakEndResult =
 ### Team
 
 ```ts
-type TeamMemberAvailability = "ready" | "on-task" | "on-break" | "reserved" | "signed-out";
+type TeamMemberAvailability = "ready" | "on-task" | "on-break" | "elsewhere" | "signed-out";
 
 type TeamMember = {
   id: UserId;
   availability: TeamMemberAvailability;
   since?: IsoTimestamp;
   break?: Extract<BreakStatus, "awaiting-approval" | "granted" | "starting-after-task">;
+  tasks?: MemberTask[];
+  listening?: MemberListening;
 };
 
 type LeadRequest = {
-  id: string;
   memberId: UserId;
   assignmentId: AssignmentId;
   note?: string;
   since: IsoTimestamp;
 };
 
+type MemberTask<C extends Channel = Channel> = {
+  assignmentId: AssignmentId;
+  title: string;
+  channel: C;
+  taskType: string;
+  phase: TaskPhase;
+  party?: Contact;
+  reference?: string;
+  attributes?: TaskAttribute[];
+  history?: TaskHistory;
+  capabilities?: TaskCapabilities<C>;
+  capabilitySource?: CapabilitySource;
+  browsers?: TaskBrowser[];
+  completionMode?: CompletionMode;
+  wrapAllowance?: DurationSeconds;
+} & (C extends "voice"
+  ? { onCall?: OnCall[]; leadAssist?: TaskLeadAssist; takenOver?: TaskTakenOver; audio?: TaskAudioState }
+  : { onCall?: never; leadAssist?: never; takenOver?: never; audio?: never });
+
+type MemberListening = {
+  mode: ListeningMode;
+  since: IsoTimestamp;
+};
+
 type TeamMembers = {
   members: TeamMember[];
-  requests?: LeadRequest[];
+  requests: LeadRequest[];
   policies?: TeamPolicies;
 };
 
@@ -1022,15 +1031,18 @@ type TeamPolicy = Resolved & {
 
 type TeamPolicies = Partial<Record<PolicyKey, TeamPolicy>>;
 
-type TeamPolicyCommand = { type: "set"; capability: PolicyKey; setting: TeamPolicySetting };
+type TeamPolicyCommand = { type: "set-policy"; capability: PolicyKey; setting: TeamPolicySetting };
 
-type TeamPolicyCommandRequest = {
-  command: TeamPolicyCommand;
-};
+type TeamFeatureCommand = { type: "lead-features"; enabled: boolean };
 
-type TeamLeadAssistCommand =
-  | { type: "join"; requestId: string }
-  | { type: "decline"; requestId: string; reason?: string };
+type TeamCallCommand =
+  | { type: "join"; memberId: UserId; assignmentId?: AssignmentId }
+  | { type: "decline"; memberId: UserId; assignmentId?: AssignmentId; reason?: string }
+  | { type: "listen"; memberId: UserId; assignmentId?: AssignmentId }
+  | { type: "coach"; memberId: UserId; assignmentId?: AssignmentId }
+  | { type: "join-call"; memberId: UserId; assignmentId?: AssignmentId }
+  | { type: "leave"; memberId: UserId; assignmentId?: AssignmentId }
+  | { type: "take-over-call"; memberId: UserId; assignmentId?: AssignmentId };
 
 type TeamBreakCommand =
   | { type: "decide-break-request"; memberId: UserId; decision: "granted" | "denied"; reason?: string }
@@ -1038,22 +1050,10 @@ type TeamBreakCommand =
   | { type: "force-break"; memberId: UserId; reasonId?: string; reason?: string; expectedDurationMs?: number }
   | { type: "end-forced-break"; memberId: UserId };
 
-type TeamBreakCommandRequest = {
-  command: TeamBreakCommand;
-};
+type TeamCommand = TeamFeatureCommand | TeamBreakCommand | TeamCallCommand | TeamPolicyCommand;
 
-type TeamLeadAssistCommandRequest = {
-  command: TeamLeadAssistCommand;
-};
-
-type TeamListenCommand =
-  | { type: "listen"; memberId: UserId }
-  | { type: "coach" }
-  | { type: "join-call" }
-  | { type: "leave" };
-
-type TeamListenCommandRequest = {
-  command: TeamListenCommand;
+type TeamCommandRequest = {
+  command: TeamCommand;
 };
 
 type TeamCommandResult =
@@ -1061,20 +1061,20 @@ type TeamCommandResult =
   | { status: "failed"; failure: ProtocolFailure };
 ```
 
-### Media
+### Audio
 
 ```ts
-type VoiceMediaSession = {
+type CallAudio = {
   remoteAudio: MediaStream;
   setMuted(muted: boolean): void;
   close(): void;
 };
 
-type OpenMediaResult =
-  | { status: "opened"; session: VoiceMediaSession }
+type OpenAudioResult =
+  | { status: "opened"; audio: CallAudio }
   | { status: "unavailable"; failure: ProtocolFailure };
 
-type OpenMediaRequest = {
+type OpenAudioRequest = {
   assignmentId: AssignmentId;
   localAudio?: MediaStream;
 };
@@ -1106,8 +1106,10 @@ type ProviderEvent =
       assignmentExpiresAt?: IsoTimestamp;
     }
   | { type: "task-updated"; task: Task }
-  | { type: "task-media-started"; assignmentId: AssignmentId }
-  | { type: "task-media-ended"; assignmentId: AssignmentId }
+  | { type: "task-audio-started"; assignmentId: AssignmentId }
+  | { type: "task-audio-ended"; assignmentId: AssignmentId }
+  | { type: "team-audio-started"; memberId: UserId; assignmentId: AssignmentId }
+  | { type: "team-audio-ended"; memberId: UserId; assignmentId: AssignmentId }
   | { type: "task-ended"; assignmentId: AssignmentId; outcome: TaskOutcome }
   | { type: "dial-outcome"; dialId: DialId; outcome: DialOutcome; assignmentId?: AssignmentId; destinationId?: string; reason?: string }
   | { type: "announcement"; text: string; html?: string; announcedAt: IsoTimestamp; expiresAt?: IsoTimestamp }
@@ -1115,7 +1117,7 @@ type ProviderEvent =
   | { type: "diagnostic"; expected: string; observed: string; assignmentId?: AssignmentId }
   | { type: "team-updated"; team: TeamMembers }
   | { type: "contacts-updated"; contacts: Contact[] }
-  | { type: "calendar-updated"; scheduledActivities: ScheduledActivity[] };
+  | { type: "calendar-updated"; calendar: ScheduledActivity[] };
 
 type ProviderEventEnvelope = {
   id: string;
@@ -1169,13 +1171,10 @@ type Connection<C extends Channel = Channel> = {
   cancelBreak?(): Promise<BreakCancelResult>;
   endBreak?(): Promise<BreakEndResult>;
 
-  executeTeamBreak?(request: TeamBreakCommandRequest): Promise<TeamCommandResult>;
-  executeTeamLeadAssist?(request: TeamLeadAssistCommandRequest): Promise<TeamCommandResult>;
-  executeTeamListen?(request: TeamListenCommandRequest): Promise<TeamCommandResult>;
-  openMedia?(request: OpenMediaRequest): Promise<OpenMediaResult>;
+  executeTeam?(request: TeamCommandRequest): Promise<TeamCommandResult>;
+  openAudio?(request: OpenAudioRequest): Promise<OpenAudioResult>;
   setPreference?(request: SetPreferenceRequest): Promise<PreferenceResult>;
   recordStep?(report: HistoryReport): Promise<HistoryReportResult>;
-  executeTeamPolicy?(request: TeamPolicyCommandRequest): Promise<TeamCommandResult>;
 };
 
 type Adapter<C extends Channel = Channel> = {
@@ -1532,7 +1531,7 @@ Request/response polling does not have those properties and is not a transport f
 
 Everything an adapter publishes about a task is derived from what the platform states, or kept in
 the login's store where the platform cannot hold it. Per offer, the `assignmentId` comes from what
-the offer itself states; per call, the media follows `task-media-started` and `task-media-ended`,
+the offer itself states; per call, the audio follows `task-audio-started` and `task-audio-ended`,
 never a flag set when the audio was opened; per session, the phone the agent holds is what the
 platform restates on activation, not a mapping read once over HTTP. What the platform cannot hold
 -- an agent application's muted leg -- goes in `ConnectContext.store`, keyed by the task and gone with it.
@@ -1540,11 +1539,11 @@ platform restates on activation, not a mapping read once over HTTP. What the pla
 A fact read once over a connection and kept in the adapter object dies with the client. An agent application
 reload is the first client dying and a second coming up for the same login, and the second
 publishes the same truth about the same task as the first did, or the first was publishing
-something it made up: an assignment minted for the connection, media remembered as a boolean, a
+something it made up: an assignment minted for the connection, audio remembered as a boolean, a
 phone the second never read. Three pieces of exactly that state were found in one adapter in an
 afternoon, and none of it was visible until the adapter was built twice. The drive's `rebuild` is the test of this
 principle: given a way to build the adapter again, the run hands the login over and holds the
-second to what the first published (`drive.reload.snapshot`, `.history`, `.openMedia`, and the
+second to what the first published (`drive.reload.snapshot`, `.history`, `.openAudio`, and the
 stream's own rules across the resync). An adapter that cannot be built twice against its platform
 and publish the same task is not a conformant adapter yet, whatever a single run says.
 
@@ -1611,7 +1610,7 @@ compile time.
 | `timeCheck` | Optional `true`: implements `checkTime` for fresh provider-clock samples; agent application polling is independently opt-in. |
 | `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 completion -- `complete`, or a lead's `take-over-call` -- the provider's `task-ended` is owed, a positive whole number of milliseconds (`manifest.completionSettleMs`). A warm transfer's `complete` is not final task completion: the agent's wrap runs after it. Stated per provider, since platforms settle at different speeds. See **`task-ended`**. |
+| `completionSettleMs` | Required. How long after an applied `complete` the provider's `task-ended` is owed, a positive whole number of milliseconds (`manifest.completionSettleMs`). A warm transfer's `complete` is not final task completion: the agent's wrap runs after it. Stated per provider, since platforms settle at different speeds. See **`task-ended`**. |
 
 ### Authentication methods
 
@@ -1754,7 +1753,7 @@ contributions from active providers into one agent-facing calendar while retaini
 provider identity for each activity.
 
 When declared, the provider publishes its authoritative list through
-`Snapshot.scheduledActivities` and replaces it with a `calendar-updated` event when it
+`Snapshot.calendar` and replaces it with a `calendar-updated` event when it
 changes.
 
 | Field | Contract |
@@ -1912,20 +1911,15 @@ replaces the login" describes is a new `AuthenticationSession` under a new `logi
 ### What the login may do
 
 `capabilities` declares provider actions available to this login rather than to one task: whether
-the agent may ask for a break, and whether they lead a team — and if so, whether they decide its
-breaks and whether they may join a member's call. It is declared by presence, like every capability
-in this contract, and it travels with the identity because it is part of who the agent is on this
-provider: the provider knows the roles, and says so at sign-in rather than leaving Omni to infer
-them from what arrives later.
+the agent may ask for a break, and whether they lead a team. It is declared by presence, like every
+capability in this contract, and it travels with the identity because it is part of who the agent
+is on this provider: the provider knows the roles, and says so at sign-in rather than leaving Omni
+to infer them from what arrives later.
 
 | Field | Contract |
 | --- | --- |
 | `breaks` | This login may request a break. Requires the four break methods on the connection. |
-| `team` | This login leads a team. The provider publishes a `TeamMembers` object to it on every snapshot — `members: []` when nobody is in it — and to nobody else. |
-| `team.breakControl` | This lead may act on their team's breaks through `executeTeamBreak` — force-break, end-forced-break, decide-break-request, set-break-policy — as far as the provider supports; a command it lacks answers `omni.capability-not-enabled`. Omni asks for a decision only against a member whose `break` is `awaiting-approval`, so a provider that grants on request is never asked to decide. Requires `executeTeamBreak`. |
-| `team.leadAssistControl` | This lead may join a member's call on request. Requires `executeTeamLeadAssist`. |
-| `team.listeningControl` | This lead may listen to a member's call unasked, in the listed modes and no others: `listen`, `coach`, `join-call`. The list always includes `listen`, since the other two begin from one. Requires `executeTeamListen`. See **Listening to a call**. |
-| `team.policyControl` | This lead sets the team's policy per capability — on, off, or the person's — within what the queue allows. Requires `executeTeamPolicy`; the team member list carries `policies`. |
+| `lead` | This login leads a team. The flag alone turns on the team feature in the agent application, and every lead act comes with it; there is no per-action permission beside it. While the lead has the feature on, the provider publishes a `TeamMembers` object to them on every snapshot — `members: []` when nobody is in it — and to nobody else. Requires `executeTeam`. See **Team leads**. |
 | `preferences` | What the team left to this person, with where each stands and who set it. Omitted when nothing was. Requires `setPreference`. See **Who decides what an agent may do**. |
 
 A session action is available only when both the capability and Omni local policy permit it.
@@ -2133,13 +2127,13 @@ a capability it agrees with the login: a lead's snapshot carries `team`, nobody
 | `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. |
-| `scheduledActivities` | Required complete calendar contribution when the manifest declares `calendar`; `[]` clears it. Omitted only when it does not. |
-| `team` | Required `TeamMembers` when the login declares `capabilities.team`, `members: []` when nobody is in it. Forbidden otherwise — the login is the permission. |
+| `calendar` | Required complete calendar contribution when the manifest declares `calendar`; `[]` clears it. Omitted only when it does not. |
+| `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
 
 `Connection` is what `connect()` returns. Its methods are documented in the sections that follow
-and under **Breaks**, **Team leads**, **Real-time media** and **Task commands**; this is the whole
+and under **Breaks**, **Team leads**, **Real-time audio** and **Task commands**; this is the whole
 surface in one place, and what obliges an adapter to implement each one.
 
 | Method | Implement it when |
@@ -2157,13 +2151,10 @@ surface in one place, and what obliges an adapter to implement each one.
 | `commitBreak()` | The login declares `capabilities.breaks`. Commit and cancel are not optional halves of it. |
 | `cancelBreak()` | The login declares `capabilities.breaks`. |
 | `endBreak()` | The login declares `capabilities.breaks`. |
-| `executeTeamBreak(command)` | The login declares `capabilities.team.breakControl`. |
-| `executeTeamLeadAssist(command)` | The login declares `capabilities.team.leadAssistControl`. |
-| `executeTeamListen(command)` | The login declares `capabilities.team.listeningControl`. |
+| `executeTeam(request)` | The login declares `capabilities.lead`: every lead act, on the team surface and nowhere else. See **Lead commands**. |
 | `setPreference(request)` | The login declares `capabilities.preferences`: the person's choice has to have somewhere to go. |
 | `recordStep(report)` | The manifest lists `softphone` among its `phones`. On a softphone the agent application mutes its own microphone on any call, and the provider's record has to have somewhere to take that leg; a desk phone's microphone is the phone's. See **The agent application records what it performs**. |
-| `executeTeamPolicy(command)` | The login declares `capabilities.team.policyControl`. |
-| `openMedia(request)` | The manifest lists `softphone` among its `phones`. On a softphone the call's audio lands in Omni, so the adapter has to open it; a platform of desk phones alone never does. |
+| `openAudio(request)` | The manifest lists `softphone` among its `phones`. On a softphone the call's audio lands in Omni, so the adapter has to open it; a platform of desk phones alone never does. |
 
 **The four break methods stand or fall together.** Declaring `capabilities.breaks` at login and then
 implementing `requestBreak` without `commitBreak` leaves an agent granted a break that can never
@@ -2177,7 +2168,7 @@ Returns the provider's complete authoritative state at one point in time.
 - Omni registers `subscribe()` before awaiting the initial snapshot. An event delivered while the
   snapshot is read is held until it lands, and what happens to it then depends on what it is. A
   snapshot restates state, so an event of a state-replacing kind -- `task-offered`, `task-updated`,
-  `task-ended`, `task-media-started`, `task-media-ended`, `break-state`, `team-updated`,
+  `task-ended`, `task-audio-started`, `task-audio-ended`, `break-state`, `team-updated`,
   `contacts-updated`, `calendar-updated`, `transport-status`, `snapshot` -- is dropped, because the
   snapshot accounts for it. An event that reports a transaction no snapshot carries --
   `dial-outcome`, `diagnostic`, `announcement`, `queue-summary` -- is applied after the snapshot,
@@ -2233,7 +2224,7 @@ Stops the connection and releases adapter-owned resources.
 
 - Must be safe after partial startup and safe to call once during normal shutdown.
 - Must stop automatic reconnect.
-- Must remove event handlers and release media resources owned by the adapter.
+- Must remove event handlers and release audio resources owned by the adapter.
 - Does not imply that active tasks were completed or removed.
 
 ## Task assignment lifecycle
@@ -2295,7 +2286,7 @@ An automatically accepted task still arrives through `task-offered`.
 
 **Work the agent originated is accepted by the command that created it.** A task born of the
 agent's own act — a dialpad call or a connect-back, recognisable by the agent application's `dialId` on
-`onCall`; a lead's join, carrying `assisting`; a lead's listen, carrying `listening` — arrives
+`onCall`; a call a lead took over, carrying `takenOver` — arrives
 through `task-offered` with `acceptance: "automatic"` whatever `autoAcceptTasks` says, and the
 validator holds it there under either local policy and under none (`task.acceptance.originated`):
 the desk shows no **Accept** for a call the agent placed. The local policy governs work the queue
@@ -2319,7 +2310,7 @@ const assignment = {
 ```
 
 The rule the phase exists to express: **nothing is acquired on the agent's behalf while a task
-is pending.** An agent application that carries media must not open the microphone until the task is
+is pending.** An agent application that carries audio must not open the microphone until the task is
 accepted. Omni does not open the task's browsers either — a task that rings out costs nothing.
 
 When consent is required, Omni offers the agent an **Accept** control. The call is the
@@ -2371,28 +2362,27 @@ time. Runtime conformance checks also require the task channel to match its prov
 
 | Field | Contract |
 | --- | --- |
-| `assignmentId` | Required `AssignmentId`: the assignment this task is the record of, and its one identity. Issued by the provider, unique within the provider, never reused. Every event, command and report that names a task names it by this, so a late dial outcome or a late history report for one customer never lands on the next. The stream refuses an assignment introduced twice (`stream.taskOffered.duplicate`) and a media or ending event naming one that has ended or that nobody has seen (`stream.assignment.ended`, `.unknown`); a `dial-outcome` may name an ended assignment, since a dial placed late routinely outlives its call, and the agent application routes it there. See **A task's life on the wire**. |
+| `assignmentId` | Required `AssignmentId`: the assignment this task is the record of, and its one identity. Issued by the provider, unique within the provider, never reused. Every event, command and report that names a task names it by this, so a late dial outcome or a late history report for one customer never lands on the next. The stream refuses an assignment introduced twice (`stream.taskOffered.duplicate`) and an audio or ending event naming one that has ended or that nobody has seen (`stream.assignment.ended`, `.unknown`); a `dial-outcome` may name an ended assignment, since a dial placed late routinely outlives its call, and the agent application routes it there. See **A task's life on the wire**. |
 | `title` | Agent-facing task title. |
 | `channel` | Channel used for this task. It must equal the source provider's manifest channel. |
 | `taskType` | Required provider-defined source or category of work, such as a voice `Queue Name`, `Mailbox Folder`, `Chat Source`, `Support`, `Billing`, or `Returns`. |
 | `capabilities` | Controls and workspace features available for this specific task. |
-| `capabilitySource` | Required. Who chose the capabilities: `queue` when somebody configured these terms, `ungoverned` when nothing handed the work over -- an agent's own outbound -- and `undetermined` when a queue was named and its terms could not be read, in which case `capabilities` is what the provider will honour, not what the platform permits. An agent application shows `undetermined` where the agent works. See **Task capabilities**. |
+| `capabilitySource` | Required. Who chose the capabilities: `queue` when somebody configured these terms, `nobody` when nothing handed the work over -- an agent's own outbound -- and `not-yet-read` when a queue was named and its terms could not be read, in which case `capabilities` is what the provider will honour, not what the platform permits. An agent application shows `not-yet-read` where the agent works. See **Task capabilities**. |
 | `browsers` | Named browser definitions for the task workspace: at least one when the task declares the `browsers` capability, empty when it does not. |
 | `party` | The person or entity on the other end of this task, as a `Contact`: often a name and one address; a withheld caller ID may leave nothing to send at all. Optional. The party is who the task is *with*; `contacts` is the directory. |
 | `phase` | Current canonical task phase: `pending`, `confirmed`, `preview`, `in-progress`, `paused`, or `completing`. `preview` is voice only. |
-| `media` | 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-media-started`**. Media 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.media.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 media may precede answer. |
+| `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**. |
 | `previewEndsAt` | Voice only, in `preview`: the preparation target instant. 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 `previewEndsAt`: what the system does at the deadline -- `calls` makes the provider initiate dialing, `host-calls` makes the agent application issue Call, `waits` keeps the task in preview awaiting the agent. |
+| `atDeadline` | Voice only, in `preview`, with `previewEndsAt`: what the system does at the deadline -- `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`. |
 | `completionMode` | `agent-command` waits for the channel's `complete` command; `provider-automatic` completes without one. |
-| `wrapAllowance` | Fixed time allowed to complete the task after primary interaction ends. For real-time media, it begins after `task-media-ended`. Required under `provider-automatic`, where the provider acts on it. Optional under `agent-command`: omitted says the provider imposes no deadline, and Omni counts nothing down. |
+| `wrapAllowance` | Fixed time allowed to complete the task after primary interaction ends. For real-time audio, it begins after `task-audio-ended`. Required under `provider-automatic`, where the provider acts on it. Optional under `agent-command`: omitted says the provider imposes no deadline, and Omni counts nothing down. |
 | `attributes` | Optional ordered, typed `TaskAttribute` entries with keys unique within the task. Each contact or timestamp is a separate array item; new attribute shapes require new union members. |
 | `history` | The call record: `steps` — the ordered interaction history of this open task, one entry per occurrence, oldest first — and what they add up to before this agent, `interactionSeconds`, `holdSeconds`, `queueSeconds`, `transfers`, each present when the provider knows it. Live task data restated with the task, not a permanent archive. See **Interaction history**. |
 | `onCall` | Voice only. Who is on the call, or being brought onto it, as the provider states it, replaced whole with the task: `party` is the customer -- carrying a `stage` while being dialled again on the same task, a connect-back with the agent application's `dialId` or a platform's callback without, ringing from the moment the dial is placed and joined on its answered outcome --, `agent` a person by user id, `consulted` and `conferenced` somebody a dial is bringing in, listed from the moment the dial is placed -- with the `destinationId` dialled, the `dialId` where an agent application placed it, the `stage` reached (`ringing` until answered, `joined` after), and `held: true` on anyone joined and parked. A `consulted` entry is what makes `transfer` `complete` and `cancel` issuable. `label` names a destination -- a person, a queue -- not a phrase; the agent application supplies the verb. Present when the provider knows the room, absent when it does not. See **Every dial has an outcome**. |
 | `leadAssist` | Voice only. Present from the agent's request for a lead until the lead leaves or the request ends: `requested` while nobody has joined, `joined` with the lead's `leadId` once somebody has. See **Lead assist**. |
-| `assisting` | Voice only, on the lead's own task for a call they joined: which member asked, the member's `assignmentId`, and their note. The lead's task has an assignment of its own, so the member's is named, or the copy no longer says which call it joined. Its presence is what makes `lead-assist` `take-over-call` and `leave` issuable. See **Lead assist**. |
-| `listening` | Voice only, on the lead's own task while they listen to a member's call: whose call, which call, and the `mode` they are heard in, restated on every change. Never on the member's task, and never together with `assisting`. See **Listening to a call**. |
+| `takenOver` | Voice only, on a task that reached this agent by a lead's take-over: which member the call was taken from, and when. It is an ordinary assignment with the call's history, offered whatever break the lead is on and counted against no capacity. See **Lead assist**. |
 
 `TaskAttribute` entries carry typed detail alongside the task:
 
@@ -2424,7 +2414,7 @@ The canonical task transitions are:
 | `pending` | Task is accepted | `confirmed` |
 | `confirmed` | The customer's record is put in front of the agent before any call goes out (voice) | `preview` |
 | `confirmed` | Work begins | `in-progress` |
-| `preview` | Agent presses Call (`call`) and the customer answers, or the deadline `calls` and they answer | `in-progress` |
+| `preview` | Agent presses Call (`dial`) and the customer answers, or the deadline `provider-dials` and they answer | `in-progress` |
 | `preview` | The call goes out and nobody answers | `completing` |
 | `preview` | The preparation target passes with `atDeadline: "waits"` | Remains `preview`, waiting for the agent to press Call |
 | `pending` | Provider withdraws the assignment, the agent declines, or the party abandons the ring | Removed by `task-ended` with `cancelled` outcome, `by` saying which |
@@ -2443,7 +2433,7 @@ The canonical task transitions are:
 A task has one name, the assignment it is the record of, and the provider issues it. Platforms
 reuse their own handles: a closed one is retired minutes later, a requeue takes seconds, and on
 one platform a call was offered twice, thirteen seconds apart, under one handle, through a close
-and a re-offer. Everything that names a task after the fact -- a dial outcome, a media event, an
+and a re-offer. Everything that names a task after the fact -- a dial outcome, an audio event, an
 ending, a history report, a command -- would land on whichever assignment is open when it arrives.
 So the assignment id is unique within the provider and never reused: where the platform's handle
 never comes back, the adapter passes it through; where it does, the adapter mints the assignment id
@@ -2452,7 +2442,7 @@ belongs to or is refused, and a task-scoped browser session (`PROVIDER_NAME__ASS
 lives one assignment, never the next customer's cookies. A dial the agent application placed was
 already safe, since its outcome is placed by the agent application's own `dialId`; where the
 assignment earns its place is everything the agent application does not mint --
-`task-media-started`, `task-media-ended`, `task-ended`, a `recordStep` naming a task -- any of which
+`task-audio-started`, `task-audio-ended`, `task-ended`, a `recordStep` naming a task -- any of which
 would otherwise find the next customer under a reused handle and act on them. A minted id is part
 of the task the adapter keeps, not a field held in memory beside it: it lives in the login's
 `store` with the task, or is derived from a platform handle that itself never reuses, so a rebuilt
@@ -2479,19 +2469,19 @@ const previewed = {
   phase: "preview",
   party: { name: "Maya Rao", number: "+919876543210" },
   previewEndsAt: "2026-08-25T10:40:37.000Z",
-  atDeadline: "calls",
+  atDeadline: "provider-dials",
 } satisfies Pick<Task<"voice">, "channel" | "capabilities" | "phase" | "party" | "previewEndsAt" | "atDeadline">;
 
 // The agent presses Call. It is a dial like any other.
-const pressed: TaskCommand<"voice"> = { type: "call", dialId: "dial-7f2" };
+const pressed: TaskCommand<"voice"> = { type: "dial", dialId: "dial-7f2" };
 ```
 
 **Call is a dial.** It carries the agent application's `dialId`, is answered `dialling`, and ends in exactly one
 `dial-outcome`; the phase is its gate and there is no capability, since a record put in front of an
-agent is there to be called. Its media starts on `dialling`, as every agent application-placed dial's does --
-ring-back is audio the agent hears -- so `task-media-started` arrives on the `preview` task with
-its party ringing. On `answered` the task is `in-progress`; on any other outcome the media ends,
-`task-media-ended` starts the wrap clock as on every voice task, and the task goes to
+agent is there to be called. Its audio starts on `dialling`, as every agent application-placed dial's does --
+ring-back is audio the agent hears -- so `task-audio-started` arrives on the `preview` task with
+its party ringing. On `answered` the task is `in-progress`; on any other outcome the audio ends,
+`task-audio-ended` starts the wrap clock as on every voice task, and the task goes to
 `completing`, so the agent records the
 no-answer as the outcome it is -- in a campaign that is the commonest outcome there is, and it
 is work, not a cancellation. A `preview` task therefore needs a manifest that says how a dial ends
@@ -2503,8 +2493,8 @@ carries the provider's authoritative preparation-end instant and exactly one tri
 
 | Declaration | At preparation end |
 | --- | --- |
-| `atDeadline: "calls"` | The provider initiates dialing. The agent application never sends a timer-triggered Call. |
-| `atDeadline: "host-calls"` | The agent application sends the ordinary `call` command with a fresh agent application `dialId`. The provider does not independently auto-dial this task. |
+| `atDeadline: "provider-dials"` | The provider initiates dialing. The agent application never sends a timer-triggered Call. |
+| `atDeadline: "host-dials"` | The agent application sends the ordinary `dial` command with a fresh agent application `dialId`. The provider does not independently auto-dial this task. |
 | `atDeadline: "waits"` | Neither side auto-dials. The task remains in preview until the agent presses Call. |
 
 The agent may press Call early in either fixed-preparation dialing mode, or at any time in
@@ -2512,7 +2502,7 @@ The agent may press Call early in either fixed-preparation dialing mode, or at a
 zero the UI says "Waiting for agent" and keeps Call available. There is no automatic task-ended,
 completion, dialing or phase change. No repeating timer action occurs on later snapshots. This differs
 from unlimited preparation only by displaying a preparation target. The former `expires` deadline
-value is not supported; elapsed preparation must not withdraw the task. For `calls` and `host-calls`, the deadline ends
+value is not supported; elapsed preparation must not withdraw the task. For `provider-dials` and `host-dials`, the deadline ends
 preparation and triggers initiation; it does not promise ringing, playable audio or customer
 answer at that exact instant. Scheduling/dispatch delay must remain visible, and a failed or
 prevented initiation must be reported rather than leaving a silently expired countdown.
@@ -2523,7 +2513,7 @@ time; clock estimation is allowed only under the explicit agent application-trig
 Without usable provider-domain time
 it cannot safely auto-trigger and must expose the uncertainty and reconcile. No zero-duration,
 receipt-time or local-default deadline is inferred. Neither elapsed time nor submission changes
-the task phase: subsequent authoritative events state ringing, answer, media and completion.
+the task phase: subsequent authoritative events state ringing, answer, audio and completion.
 
 An agent application must serialize manual clicks and its timer under the exact provider/login/task/assignment
 scope, allowing at most one unresolved submission. Recheck the current phase, deadline owner,
@@ -2537,11 +2527,11 @@ command as ownership of an already-running independent attempt.
 Agent application-triggered automatic dialing is an ordinary agent application dial: its result is `dialling` with the same
 agent application `dialId`, followed by exactly one correlated terminal `dial-outcome`. A provider-triggered
 dial has no invented agent application ID or agent application dial outcome. It reports source-evidenced party ringing,
-actual media and customer answer separately. In preview with `atDeadline: "calls"`, a ringing
-party without an agent application ID may carry actual pre-answer media; the deadline alone permits no media.
-Media is still introduced/ended by the corresponding events and must not imply customer answer.
+actual audio and customer answer separately. In preview with `atDeadline: "provider-dials"`, a ringing
+party without an agent application ID may carry actual pre-answer audio; the deadline alone permits no audio.
+Audio is still introduced/ended by the corresponding events and must not imply customer answer.
 Submission acceptance is never an answered outcome or permission to publish `in-progress` early.
-Unsupported source correlation/outcome/media evidence remains an integration blocker.
+Unsupported source correlation/outcome/audio evidence remains an integration blocker.
 
 **Drop both fields when the phase moves.** A provider that builds the `in-progress` task by
 spreading the `preview` one carries `previewEndsAt` and `atDeadline` with it, and the agent application refuses
@@ -2559,7 +2549,7 @@ recording contract; this distinction does not remove it or move provider call op
 
 A caller journey may revisit the same agent while an earlier interaction still wraps. Each is its
 own assignment, and two open at once carry two assignment ids. Restore them unchanged on
-reconnect. Commands, media, endings and history reports name the exact assignment; never retarget
+reconnect. Commands, audio, endings and history reports name the exact assignment; never retarget
 an old command to the newest interaction of a journey. `validateTaskCommandRequest` checks the
 request's assignment against the supplied published task and then its command prerequisites. The
 caller must select that task within the correct provider/login and recheck at the provider; the
@@ -2569,33 +2559,33 @@ portion must not be cleared because this task ended. Snapshot counts include all
 and active interactions; task completion is not caller hangup.
 
 **Voice describes the agent's interaction within the wider call.** The task defines that agent's
-workspace, tools, permissions, media participation and completion work. The caller's channel may
+workspace, tools, permissions, audio participation and completion work. The caller's channel may
 continue through IVR, queues, other agents, holds or conferences while this interaction ends or wraps.
 Completing this task ends this interaction responsibility; it is not evidence that the caller's channel
-or journey ended. Task media describes this agent's attachment, not the lifetime of every party's
+or journey ended. Task audio describes this agent's attachment, not the lifetime of every party's
 connection. Commands retain their explicit targets and effects; task completion must not silently
 become a caller-disconnect operation.
 
 **A task is never its audio.** A voice task represents the agent’s interaction: the call is offered when it is
 routed to the agent and accepted as its `acceptance` dictates, and its presence and phase follow
 the provider's reports about the work — never the audio. Wherever audio moves — an offer, a hold, a
-consult, a conference leg joining or leaving, a transfer, a connect-back — the media follows
-separately, arriving on `task-media-started`, attaching through `openMedia` and ending with
-`task-media-ended`. Omni does not ring,
+consult, a conference leg joining or leaving, a transfer, a connect-back — the audio follows
+separately, arriving on `task-audio-started`, attaching through `openAudio` and ending with
+`task-audio-ended`. Omni does not ring,
 bridge, or hold a line. How the phone rings, whether it rings at all, and where legs join and leave
 are the adapter's and the platform's, transient, and decide neither when a task exists nor what
 phase it is in.
 
-The line runs between the provider's word and Omni's own senses. `task-media-ended` is the
+The line runs between the provider's word and Omni's own senses. `task-audio-ended` is the
 provider's report that primary interaction ended — a fact about the work, which is why the completion
 allowance starts on it and the Connect back control appears on it — and Omni follows that report as it
-follows any other. What Omni never does is derive a task's state from its own media session: a
+follows any other. What Omni never does is derive a task's state from its own audio session: a
 stream that drops, a track that ends, a transport that disconnects, a microphone that fails, an
 endpoint re-registering change nothing about the task until the provider says so. Structurally:
-`task-media-started` and `task-media-ended` alternate on a task whose work has begun, media ends
-only where it arrived, what follows the media ending is `completing` or `task-ended`, and every
+`task-audio-started` and `task-audio-ended` alternate on a task whose work has begun, audio ends
+only where it arrived, what follows the audio ending is `completing` or `task-ended`, and every
 task is introduced once — `exerciseAdapter` holds the stream to that from the connect snapshot on,
-and `assertMediaFollowsTheTask` holds any sequence.
+and `assertAudioFollowsTheTask` holds any sequence.
 
 #### Completion timing
 
@@ -2604,16 +2594,16 @@ the task open until Omni sends the channel's `complete` command. With `provider-
 provider may complete the task without receiving that command.
 
 `wrapAllowance` is independent of that decision. It is fixed, and when it starts depends on
-whether the channel carries real-time media:
+whether the channel carries real-time audio:
 
 | Channel | Wrap allowance starts at |
 | --- | --- |
-| Voice and any channel with real-time media | The `task-media-ended` event |
+| Voice and any channel with real-time audio | The `task-audio-ended` event |
 | Chat | The `task-updated` that moves the task to `completing`: the provider's word that the conversation is closed on its side, the allowance running from that publication's `occurredAt` |
 | Email | The `task-updated` that moves the task to `completing`: the provider's word that the platform has accepted the outgoing message, the allowance running from that publication's `occurredAt` |
-| Other non-media channels | The `task-updated` that moves the task to `completing` |
+| Other non-audio channels | The `task-updated` that moves the task to `completing` |
 
-**Off voice, `completing` is the provider's word that interaction ended.** There is no media event to
+**Off voice, `completing` is the provider's word that interaction ended.** There is no audio event to
 carry it, so the phase does; an agent application starts the wrap clock at that publication and nowhere else. It
 is optional: a conversation with nothing to wrap moves from `in-progress` to `task-ended` and
 `completing` is never published. Under `provider-automatic` with a non-zero `wrapAllowance` it is
@@ -2648,9 +2638,9 @@ const untimedWrap = {
 } satisfies Pick<Task<"voice">, "completionMode" | "wrapAllowance">;
 ```
 
-Here the customer has hung up, `task-media-ended` has been sent on time, the task is `completing`,
+Here the customer has hung up, `task-audio-ended` has been sent on time, the task is `completing`,
 and the agent takes as long as the work needs. Moving the task to `completing` late to avoid a
-deadline is not an alternative on a media channel: the clock starts at a real event, and delaying
+deadline is not an alternative on an audio channel: the clock starts at a real event, and delaying
 that event would falsify the phase and everything timed from it.
 
 #### Connecting back during completion
@@ -2665,9 +2655,9 @@ is; the command carries no destination, and it is a dial like any other, so it c
 
 On `dialling` the provider is placing the call and the task returns to `in-progress`: the agent is
 working again, and the wrap allowance is **discarded, not paused**. From there the call is
-reported as any call is -- `paused`, `in-progress`, and when its media ends, `task-media-ended`
+reported as any call is -- `paused`, `in-progress`, and when its audio ends, `task-audio-ended`
 again, which starts a fresh allowance from that instant. A party who does not answer is a dial
-whose outcome says so and a call whose media ended: the task returns to `completing` through the
+whose outcome says so and a call whose audio ended: the task returns to `completing` through the
 same event and the clock starts again from there. At no point is an agent dialling against a
 deadline.
 
@@ -2703,7 +2693,7 @@ const connectBackCapable = {
 With ten seconds of the thirty left, the agent presses Connect back: `execute({ command: { type:
 "connect-back", dialId } })` returns `dialling`, the task is `in-progress`, and the thirty seconds
 are gone.
-The second call ends: `task-media-ended`, the task is `completing`, and a new thirty seconds runs
+The second call ends: `task-audio-ended`, the task is `completing`, and a new thirty seconds runs
 from that instant.
 
 ```ts
@@ -2739,6 +2729,12 @@ Migration from the earlier spellings:
 | 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` |
+| 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`, `team-audio-started`, `team-audio-ended`, `audio` on the task, `TaskAudioState`, `openAudio`, `OpenAudioRequest`, `OpenAudioResult`, `CallAudio` on the result's `audio` |
+| capabilitySource values ungoverned and undetermined | `nobody`, `not-yet-read` (`capabilitySource.notYetRead`) |
+| Snapshot.scheduledActivities, and scheduledActivities on calendar-updated | `calendar` in both |
+| availability reserved | `elsewhere` |
+| recording destinationId, HostRecording.destinationIds | `storageId`, `storageIds` (`recording.storage`, `recording.host.storage`) |
 
 Update producers, consumers, saved task snapshots, and validation-rule assertions together.
 History and report rule names use `history` and `historyReport`; assignment rules use
@@ -2782,16 +2778,16 @@ Steps are `queued`, `offered`, `answered`, `held`, `muted`, `transferred`, `conf
 when it began, `seconds` once it ended and omitted while it runs — and a second hold is a second
 entry after the first, never a revision of it. A leg that has ended states its duration, and the
 task says whether a leg can still be running: a hold runs only while the task is `paused`, a mute
-only while its media is up, so a `held` entry without `seconds` on a task that is not paused, or a
+only while its audio is up, so a `held` entry without `seconds` on a task that is not paused, or a
 `muted` one on a call that is over, is a leg nobody closed and reads exactly like a leg running now
 (`task.history.held.open`, `.muted.open`). Whoever performs the leg closes it — the
 provider whose platform parks the caller, the agent application whose microphone it is — by restating the entry
 with its duration, and **an entry that cannot be closed is not written**: open for ever is a
-plausible nought one level down from a total. **A leg still open when the media ends is closed by
-the provider**, at that instant, in the same publication that says the media ended: the provider
+plausible nought one level down from a total. **A leg still open when the audio ends is closed by
+the provider**, at that instant, in the same publication that says the audio ended: the provider
 is the one that knows the instant, and the agent application can only learn of it afterwards. Agents end calls
-muted, so the agent application's leg is routinely open at media end; the provider closes it with the duration
-from the leg's `at` to the media's end, and the agent application's own closing report for that leg, which
+muted, so the agent application's leg is routinely open at audio end; the provider closes it with the duration
+from the leg's `at` to the audio's end, and the agent application's own closing report for that leg, which
 follows what it hears, is answered `recorded` and changes nothing, the entry standing as the
 provider closed it. One publisher of the closed leg, and no order between them to get right. There is no resumed step; a resume is the end of a
 hold, at the entry's `at` plus its `seconds`, and nothing is lost by not naming it twice. The same goes for every step: two mutes are two
@@ -2838,7 +2834,7 @@ or combine them: report the representation conflict. No ambiguous event is silen
 
 **Handle time is anchored, not restarted.** It runs from the
 `answered` step's `at` — from the task's first `in-progress` where the provider reports no
-history — until the task's media ends, and a hold neither pauses nor resets it: the hold's own
+history — until the task's audio ends, and a hold neither pauses nor resets it: the hold's own
 duration is the `held` entry's `seconds`, and a desk that restarts its counter on resume is
 counting the wrong thing.
 
@@ -2938,7 +2934,7 @@ the agent application mutes nothing and records nothing.
 **The provider's confirmed end is decisive.** The agent application keeps local state for interaction and
 reporting, but follows the provider's authoritative state. When the provider publishes the end
 of the current mute leg, the agent application ends that local mute and releases its agent application-controlled mute
-on the matching task's media. It does not wait for its own timer, reopen the leg, replace the
+on the matching task's audio. It does not wait for its own timer, reopen the leg, replace the
 provider timestamp, or overwrite the provider's final duration with a later agent application report.
 A later agent mute is a new leg, never a reopening of the ended one.
 
@@ -2950,7 +2946,7 @@ retain the current provider view and apply the matching closure once correlation
 never guess a match from arrival order or nearest timestamp. Failure to release an agent application-controlled
 mute is reported visibly; local device reports still describe the actual device state.
 
-At a provider-confirmed task/media end, the agent application also stops the associated local mute and reports
+At a provider-confirmed task/audio end, the agent application also stops the associated local mute and reports
 its observed ending where the report is still accepted. An agent application closing report repeats its original
 key and may include its measured duration, but cannot reverse an already confirmed provider end.
 The provider acknowledges a known closed leg without rewriting its final record; after the task
@@ -3078,7 +3074,7 @@ from no other source -- not the queue the task came from, not the login, not its
 about this task, and a client with two sources and a rule for choosing between them is the shape
 that produces two consumers disagreeing about one fact. The task is the one source, and the
 provider puts on the task what the platform permits for it -- and says, in `capabilitySource`, who
-chose those terms. `queue` says somebody configured them. `ungoverned` says nothing handed the work
+chose those terms. `queue` says somebody configured them. `nobody` says nothing handed the work
 over: an agent's own outbound call has no queue behind it, and the provider states what it permits
 for such a call. Neither changes where an agent application reads the capabilities from, which is the task; the
 source is one more published fact about them, and the one that lets an agent application tell a fact from a fault
@@ -3116,15 +3112,15 @@ direction: the task as offered and as republished, and one command that was issu
 first and is refused under the last for want of the capability withdrawn -- and nothing else.
 
 **An empty capability set is a statement, not a shrug.** `capabilities: {}` under `queue` or
-`ungoverned` says the platform permits nothing capability-gated on this task, and an agent application draws
+`nobody` says the platform permits nothing capability-gated on this task, and an agent application draws
 nothing beyond what the phase and `completionMode` require. A provider that has not yet learned
 what the platform permits -- a queue's configuration that has not reached it -- knows nothing of
 the kind, and must not publish the task as if it did, neither as `{}` nor as every control it has.
-It publishes the task under `capabilitySource: "undetermined"`, with the capabilities it will
+It publishes the task under `capabilitySource: "not-yet-read"`, with the capabilities it will
 honour until it knows, and an agent application shows that where the agent works, beside the controls it draws
 from them: "no queue governs this call" is a fact, "the configuration has not arrived" is a fault,
 and the set alone cannot tell them apart, so the provider says which. What a provider honours
-under undetermined terms is its own call -- a floor that would rather an agent briefly hold a
+under not-yet-read terms is its own call -- a floor that would rather an agent briefly hold a
 control the platform might not have granted than lose hold or hang-up mid-call over a slow
 configuration read publishes those -- and the protocol chooses no default set for it. The fault is
 also reported as a `diagnostic` naming the task, one per occurrence, so an operator counts it. When
@@ -3132,12 +3128,12 @@ the terms arrive, the task is republished under `queue` with the set as it now s
 republish as any other permission that changed while the task was open. The move goes one way.
 Terms once read stay read: a re-read that fails mid-task is not a new fact about the task, so the
 last statement stands and the failure is a `diagnostic`, and a task that was published under
-`queue` or `ungoverned` never returns to `undetermined`, on an update (`stream.taskUpdated.capabilitySource`)
+`queue` or `nobody` never returns to `not-yet-read`, on an update (`stream.taskUpdated.capabilitySource`)
 or on a resync snapshot (`stream.snapshot.capabilitySource`); a record once read never loses an
 entry the same two ways (`stream.taskUpdated.history`, `stream.snapshot.history`);
-a snapshot carrying a task still at work does not forget the audio the stream held up, since media
-ends on `task-media-ended` and the call moves on (`stream.snapshot.media`); a voice task ends after
-its audio ends, never around it, whatever the outcome (`stream.taskEnded.mediaOpen`); and a task does not go
+a snapshot carrying a task still at work does not forget the audio the stream held up, since audio
+ends on `task-audio-ended` and the call moves on (`stream.snapshot.audio`); a voice task ends after
+its audio ends, never around it, whatever the outcome (`stream.taskEnded.audioOpen`); and a task does not go
 backwards, on an update or on a resync (`stream.taskUpdated.phase`, `stream.snapshot.phase`): the
 stream sees publications, not
 transitions, and a task may pass through a phase between two, so `pending` to `in-progress` stands
@@ -3146,32 +3142,32 @@ the transition table -- back to `pending`, back to `confirmed` or `preview` once
 `completing` except by the party being dialled again, a connect-back or a platform's callback,
 which the update itself shows: the party ringing, or joined by a dial whose answered outcome the
 stream saw in this life. A completing task republished as `in-progress` from a stale copy carries
-no such stage, and that is the ending the agent never saw. Audio arrives only on a task at work: `task-media-started` on a `completing` task
-is refused as it is on a pending one (`stream.taskMediaStarted.beforeWork`), since a connect-back
-returns the task to `in-progress` before any media. And a task completes after its audio ends,
-never around it: an update moving a task to `completing` while the stream holds its media as
-started is refused (`stream.taskUpdated.mediaOpen`), whoever caused the ending, and a task stating
-`completing` with `media: "started"` contradicts itself on any snapshot or update
-(`task.media.completing`). The consequence the rule exists for is concrete: the customer's audio
+no such stage, and that is the ending the agent never saw. Audio arrives only on a task at work: `task-audio-started` on a `completing` task
+is refused as it is on a pending one (`stream.taskAudioStarted.beforeWork`), since a connect-back
+returns the task to `in-progress` before any audio. And a task completes after its audio ends,
+never around it: an update moving a task to `completing` while the stream holds its audio as
+started is refused (`stream.taskUpdated.audioOpen`), whoever caused the ending, and a task stating
+`completing` with `audio: "started"` contradicts itself on any snapshot or update
+(`task.audio.completing`). The consequence the rule exists for is concrete: the customer's audio
 keeps playing through the agent's wrap-up.
 
 What the agent is told differs by source, and only one source tells them anything. Under `queue`
-and `ungoverned` the agent sees controls and nothing about where they came from: both are facts,
+and `nobody` the agent sees controls and nothing about where they came from: both are facts,
 and an agent working a call has no use for the name of the rule behind its buttons. Under
-`undetermined` the agent is told, beside the controls, that these are what the provider will honour
+`not-yet-read` the agent is told, beside the controls, that these are what the provider will honour
 until the queue's terms arrive, and that the controls may change when they do -- a statement about
 the buttons in front of them now, not about the provider, because that is what changes when the
 republish lands. It stays for as long as the set is provisional, beside the controls it qualifies;
 a message that shows and clears has said nothing about the buttons still on the screen. The two
-words are close in English and far apart on the desk: `ungoverned` is silence, `undetermined` is a
+words are close in English and far apart on the desk: `nobody` is silence, `not-yet-read` is a
 standing notice.
 
-One consequence for whoever builds the agent application: because a conformance run fails on `undetermined`, a
-conformant adapter never shows an agent application `undetermined` under test, and a clean `exerciseAdapter`
+One consequence for whoever builds the agent application: because a conformance run fails on `not-yet-read`, a
+conformant adapter never shows an agent application `not-yet-read` under test, and a clean `exerciseAdapter`
 result says nothing about how the agent application renders it. That rendering is tested against a fixture --
-a task published under `undetermined` shows the notice, the same task under `queue` shows none --
+a task published under `not-yet-read` shows the notice, the same task under `queue` shows none --
 and never against an adapter, even in principle. `exerciseAdapter` treats a
-task published under `undetermined` as a violation (`capabilitySource.undetermined`), as it treats
+task published under `not-yet-read` as a violation (`capabilitySource.notYetRead`), as it treats
 a diagnostic: a conformance run against a platform that cannot say what it permits fails loudly
 rather than passing with a note.
 
@@ -3197,7 +3193,8 @@ See **Which commands need a capability**.
 | --- | --- | --- |
 | `decline` | Pending-task button: Decline | The provider can decline a pending voice offer. Omni shows it only when local policy also permits declining. |
 | `hold` | Primary toggle: Hold | Omni may issue voice-task `hold` and `resume` commands. |
-| `endCall` | Primary button: End call | The provider ends the caller connection and all owned/inherited agent-added channels; wrap/completion remain separate. See **Ending a call, and removing one person from it**. |
+| `endCall` | Primary button: End call | The provider ends the agent's channel and every channel the agent added; the caller continues on the provider's path. The task goes to its wrap. See **Ending a call, and removing one person from it**. |
+| `terminateCall` | Primary button: Terminate call | The provider ends the caller channel. The task goes to its wrap. See **Ending a call, and removing one person from it**. |
 | `connectBack` | Completing-task button: Connect back | Omni may have the provider connect the agent back to the task's party while the task is `completing`, returning it to `in-progress` on the same task. Not offered where there is no `completing` window: `provider-automatic` with a zero allowance completes the task at provider end. See **Connecting back during completion**. |
 | `coldTransfer` | Secondary menu item: Cold transfer | Omni may hand the customer straight to a destination, with nobody spoken to first. |
 | `warmTransfer` | Secondary menu item: Warm transfer | Omni may park the customer and call a destination first, then hand the customer over or cancel back. See **Warm transfer**. |
@@ -3292,50 +3289,41 @@ end the caller journey; a later assignment to the same agent is a new interactio
 
 #### Ending a call, and removing one person from it
 
-A call has everyone on `Task.onCall`, and two commands take people off it, both performed by the
-provider.
+A call has everyone on `Task.onCall`, and three commands take people off it, all performed by the
+provider. Two of them end the agent's part; they differ in what happens to the caller.
 
 ```ts
-{ type: "end-call" }                                             // provider ends caller and owned/inherited agent-added channels; wrap/completion are separate
+{ type: "end-call" }                                             // the agent's channel and the channels the agent added end; the caller continues
+{ type: "terminate-call" }                                       // the caller channel ends
 { type: "conference", action: "remove", party: true }            // the customer leaves; the agent stays with the colleague
 { type: "conference", action: "remove", destinationId: "tier2" } // the conferenced person leaves; ringing, this calls the dial off
 ```
 
-The agent application sends the ordinary task-scoped `execute` request with `command: { type: "end-call" }`.
-The provider knows the caller and agent-added channel bindings; no channel list or owner details
-are sent by the agent application. The task's `endCall` capability is permission, not an executor selection.
-`validateTaskCommandRequest` checks the exact interaction/assignment and delegates the command's
-policy/phase checks. The provider rechecks current ownership atomically; no client validator can
-prove that its view is fresh. The agent application does not implement agent end-call; low-level removal of individual channels is not
-this agent action. There is no agent application end-call execution API or fallback route.
-
-`end-call` is gated by `endCall` on the current interaction. It ends the caller connection and
-all agent-added channels owned by that interaction, including channels originally added by previous
-agents and inherited through transfer or takeover. Ownership is not inferred from who originally
-dialed, the current UI selection, or a person's label. The provider maintains that authority
-and checks the exact interaction/assignment when acting. Agent-added channels are not left behind
-merely because another agent added them.
-
-On a successful transfer or takeover, ownership of those channels passes to the receiving
-interaction (lead or another agent), not just ownership of the caller leg. The outgoing interaction may
-still have its allowed wrap work, but cannot disconnect channels it no longer owns. A pending or
-unknown handover is not a confirmed ownership change: retain source reservations and reconcile.
-The provider must serialize handover and end-call so a delayed outgoing command cannot tear down
-the recipient's call. No public channel-owner field or guessed identity is introduced here;
-the source must provide authoritative ownership and command fencing before declaring permission.
-
-The resulting end of this agent's media is published as `task-media-ended`. Any wrap remains
-until its own completion; `end-call` is not `task-ended`, and `complete` is not an implicit
-caller/channel disconnect. Other agents' independent tasks end or wrap only on their own source
-transitions. Neither completion nor transfer itself ends the continuing caller journey.
-
-`conference` `remove` remains a person-specific provider operation, gated by `conference`.
-It does not implicitly complete any other interaction. Its person/consultation prerequisites
-remain separate from the permission to disconnect the caller. A remove that would leave the
-agent alone is not a remove but an `end-call`, and the provider answers it `failed`.
-The consulted destination of a warm transfer is not removed this way:
-`transfer` `cancel` is its own step, which returns the agent to the parked customer, and a remove
-never promises that.
+**`end-call` ends my part.** The agent's channel and every channel the agent added -- a
+conferenced colleague, a consulted destination -- end, and the caller continues on the path the
+provider decides: another IVR, a queue, a survey, or the end of the call. Gated by `endCall`.
+
+**`terminate-call` ends the caller channel.** The call is over for the caller. Gated by
+`terminateCall`, a separate permission, since ending a customer's call is a different thing from
+putting my own side down.
+
+Both are commands to the provider through `execute`, and nothing happens on the desk until the
+provider reports it: the agent's audio ends on `task-audio-ended`, the task moves to `completing`,
+any wrap allowance runs, and the agent completes. Neither is `task-ended`, and `complete` is
+neither of them. Both capabilities are the queue's to grant and a level's to lock, and both may
+change while the task is open: the provider republishes the task at the moment a permission
+changes, and a command that arrives after its capability was withdrawn is refused, as **Task
+capabilities** sets out. The provider knows which channels are the agent's and which were added;
+the agent application sends the command and no channel list, and the provider rechecks ownership
+when it acts.
+
+`conference` `remove` takes one person off, named as the room names them, and the call goes on
+for the rest; it is gated by `conference`, since it only means something with a third person on
+the line. Removing the party leaves the agent with the colleague, a warm hand-over in reverse. A
+remove that would leave the agent alone is not a remove but an `end-call`, and a provider answers
+it `failed`. The consulted destination of a warm transfer is not removed this way: `transfer`
+`cancel` is its own step, which returns the agent to the parked customer, and a remove never
+promises that.
 
 #### Warm transfer
 
@@ -3370,7 +3358,7 @@ that offers `warmTransfer` implements all three.
 
 `applied` on `complete` says the provider is bridging the customer to the destination and
 dropping the agent's leg. What follows is what follows any call the agent leaves: the agent's
-media ends and the provider reports `task-media-ended`, the task moves to `completing`, any wrap
+audio ends and the provider reports `task-audio-ended`, the task moves to `completing`, any wrap
 allowance runs, and the task ends `completed` as any call does. A warm complete is not a completion:
 the agent has a wrap to do, so nothing is owed within `completionSettleMs`. `transferred` names a
 cold transfer alone, where the agent had no wrap. `applied` on `cancel` says the destination is
@@ -3456,7 +3444,7 @@ inside Omni.
 
 ## Every dial has an outcome
 
-Five commands place a call: `dial` from the idle dialpad, `call` from preview, a cold or warm `transfer`, a
+Five commands place a call: `dial()` from the idle dialpad, the `dial` command from preview, a cold or warm `transfer`, a
 `conference` `add`, and `connect-back`. Each is accepted or refused at once, and each then ends later
 and apart from its answer -- the destination picks up, is busy, or never does -- and a dial placed
 late in a call routinely outlives the call. Nothing in between is reported: the wire says
@@ -3562,7 +3550,7 @@ never saw.
 
 **`onCall` describes this agent's current interaction.** When the caller disconnects but the agent
 and added channels remain connected, the remaining room is still valid. When this interaction's
-media ends or the task enters `completing`, clear its `onCall` view; absence is used only by a
+audio ends or the task enters `completing`, clear its `onCall` view; absence is used only by a
 provider that never publishes the room. This does not assert that the caller, bridge or other
 agents' channels ended. A published room receives a final empty view for this interaction, and the
 task may remain open for wrap. Completion is a separate task action, not the caller's disconnect.
@@ -3587,10 +3575,10 @@ still-ringing `destinationId` calls that dial off, with `cancelled` as its outco
 
 **The entry says where it stands.** A dialled entry carries `stage`: `ringing` until its dial is
 answered, `joined` after. The `dial-outcome` is the transition and the stage is the state, the same
-pairing as `task-media-started` and `media`: an `answered` outcome and the task restated with the
+pairing as `task-audio-started` and `audio`: an `answered` outcome and the task restated with the
 entry `joined` say one thing twice, and any other outcome removes the entry. The outcome comes
 first: a `task-updated` that itself moves an entry from `ringing` to `joined` before an `answered`
-outcome for its dial is refused (`stream.taskUpdated.stage`), as an update that moves `media` is.
+outcome for its dial is refused (`stream.taskUpdated.stage`), as an update that moves `audio` is.
 The rule keys on the entry's `dialId`, so an entry the platform added itself, with none, is one
 whose move the stream cannot hold to an outcome: a clean stream proves nothing about ordering there. It is stated rather
 than left to whoever placed the dial because that knowledge lives in one process: after a reload,
@@ -3632,7 +3620,7 @@ rendering one as the other tells an agent to wait for somebody who is never comi
 | `awaiting-approval` | A person has to decide. The agent is waiting on somebody. |
 | `granted` | A person decided yes. Omni may now tell this provider to stop the agent; until it does, work continues normally, and this says nothing about why Omni has not. |
 | `starting-after-task` | Omni has told the provider to stop; the break begins when the current task ends. No new work arrives meanwhile, and nobody needs to act. It waits on a task, so beside no task it is refused (`break.starting-after-task.tasks`): a committed break with nothing outstanding is `on-break`. |
-| `on-break` | The agent is on the break now. It holds no task: a break begins when the work ends, so a snapshot reporting `on-break` beside a task is refused as `break.on-break.tasks`. The one exception is a lead's listening task during a `coaching`, `administrative` or `training` break -- see **Listening to a call**. |
+| `on-break` | The agent is on the break now. It holds no task: a break begins when the work ends, so a snapshot reporting `on-break` beside a task is refused as `break.on-break.tasks`. The one exception is a call a lead took over, which the provider assigns whatever break the lead is on -- see **Lead assist**. |
 
 A denial is a decision, not a standing approval state. The provider transitions the request directly
 to `not-requested`; Omni returns the agent to idle and never asks again on their behalf. They saw the
@@ -3807,7 +3795,7 @@ Your own tasks are the only ones you count. What the agent holds at other provid
 concern — Omni set `count` knowing it, and this is how: the agent is one person on several
 providers, and the agent application divides their capacity among them rather than telling each the whole. A
 provider that has none of it for now is told **`count: 0`, agent application-stopped**: assign nothing, show
-the member as `reserved` on the team member list -- signed in here, capacity held by the agent application for elsewhere,
+the member as `elsewhere` on the team member list -- signed in here, capacity held by the agent application for elsewhere,
 a fact this provider holds, where `on-task` would assert work it cannot see -- and take the next
 count as any other when the agent application has capacity for this provider again. Zero is the one restatement
 that follows work rather than local policy.
@@ -3843,12 +3831,15 @@ request object only to the request method, and undefined to the other three.
 | `cancelBreak` | `awaiting-approval` or `granted`. A concurrent commit winning still answers `omni.break-already-committed` and requires recovery. |
 | `endBreak` | `on-break` or `starting-after-task` during reconciliation; the agent may explicitly end a requested or forced break. |
 
-Use `validateTeamBreakCommand(request, context)` for lead decisions, forcing a break, ending a forced break and
-policy commands. It requires the live lead capability and active transport, a current target
-team member list for member commands, and the target's complete break state for forcing/ending a break.
-Approve/deny requires an awaiting decision; forcing a break uses the target's reason codes; ending a forced break
-requires a forced committed break. The context's target state must belong to the named member;
-that association and backend authorization are provider responsibilities.
+Use `validateTeamCommand(request, context)` before every lead act: the team feature switch, break
+decisions, forcing and ending a forced break, policy, and every act on a member's call. It requires
+the live `lead` flag and active transport, a current team member list for any command naming a
+member, and the target's complete break state for forcing/ending a break. Approve/deny requires an
+awaiting decision; forcing a break uses the target's reason codes; ending a forced break requires a
+forced committed break; join and decline need the member's request on the list; coach, join-call
+and leave need the lead already on that member's call; an assignment named must be one the list
+shows the member holding. The context's target state must belong to the named member; that
+association and backend authorization are provider responsibilities.
 
 Use `validateBreakStatus(state, tasks)` on the complete retained task view after each transaction,
 as well as `validateBreakTransition` for event ordering. Snapshot validation shares the status
@@ -4116,22 +4107,23 @@ so there is nothing on it to resume.
 
 ## Team leads
 
-A lead who also takes calls sees their team on the idle dashboard. `Snapshot.team` carries a
-`TeamMembers` object, replaced whole by `team-updated`.
-
-Migration: TeamRoster is now `TeamMembers`, and validateTeamRoster is now
-`validateTeamMembers`. Update type imports and validator calls; no legacy export aliases exist.
-The object still contains `members` and the permitted `requests` and `policies`; it is not a
-bare array. `Snapshot.team`, the `team-updated` event and its `team` payload, login permissions,
-and `team.*` validation rules keep their names and semantics. An empty team has `members: []`;
-an absent `team` still means the login is not entitled to that contribution.
+The team feature is the lead's own surface, beside the agent's and never mixed with it. The
+login's `lead` flag turns it on in the agent application; the lead retrieves their members and
+sees, for each, their assignments as they stand and the full history of each, and acts on them
+with the authority the flag carries. Nothing the lead does here is a task on their desk. A lead
+who also takes calls is an agent like any other on the agent side, and a lead who does not want
+the agent role for now places themself on a break of a working kind and keeps the team feature on.
 
+`Snapshot.team` carries a `TeamMembers` object, replaced whole by `team-updated`, and the provider
+keeps it current: when a member is offered a call, answers, holds, mutes or is transferred, the
+list is republished, so the lead's screen moves when the member's does. The agent application asks
+for nothing and computes nothing.
 
 | Field | Contract |
 | --- | --- |
-| `members` | Every member of this lead's team, whatever their state. `[]` says the lead has a team with nobody in it; omitting the team member list says something else entirely — see **The login is the permission** below. |
-| `requests` | The members currently asking this lead to join a call, each with the task and the note. Required when the login declares `team.leadAssistControl`, `[]` when nobody is asking; omitted when it does not. See **Lead assist**. |
-| `policies` | The team's policy per capability as it stands — the setting, who set it, and `lockedBy` where a level above the team made it theirs to keep. Required when the login declares `team.policyControl`; omitted when it does not. See **Who decides what an agent may do**. |
+| `members` | Every member of this lead's team, whatever their state, each with their open tasks. `[]` says the lead has a team with nobody in it; omitting the team member list says something else entirely — see **The login is the permission** below. |
+| `requests` | The members currently asking a lead to join their call, each naming the member, the assignment and the note. Always carried, `[]` when nobody is asking. See **Lead assist**. |
+| `policies` | The team's policy per capability as it stands — the setting, who set it, and `lockedBy` where a level above the team made it theirs to keep. Present where the provider offers policy control; absent where it does not. See **Who decides what an agent may do**. |
 
 | `TeamMember` field | Contract |
 | --- | --- |
@@ -4139,6 +4131,8 @@ an absent `team` still means the login is not entitled to that contribution.
 | `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, audio and the full history are what the lead reads; 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 — with the `mode` they are heard in and since when. One member's call at a time (`team.listening.single`). |
 
 Each availability value means one thing:
 
@@ -4147,13 +4141,14 @@ Each availability value means one thing:
 | `ready` | Signed in, able to take work, none assigned. |
 | `on-task` | Working on at least one task. It says nothing about how many, and nothing about whether more will fit. |
 | `on-break` | Stopped and not taking work, whether they asked or somebody stopped them. The reason lives on their own `BreakState`, not here. |
-| `reserved` | Signed in here, and the agent application holds this agent's capacity for another provider (`count: 0`, agent application-stopped): not receiving this provider's work, and not on a break. See **Capacity**. |
+| `elsewhere` | Signed in here, and the agent application holds this agent's capacity for another provider (`count: 0`, agent application-stopped): not receiving this provider's work, and not on a break. See **Capacity**. |
 | `signed-out` | Known to this team but not signed in to this provider. |
 
 **Always publish the complete team member list, never a change to it.** Team presence typically reaches an
 adapter over a best-effort channel with no ordering and no delivery guarantee, so a stream of deltas
 cannot be trusted to reconstruct the truth. The adapter reconciles against its own authoritative
-read and publishes the result.
+read and publishes the result. That includes the members' tasks: a hold on a member's desk is a
+republished list on the lead's.
 
 **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
@@ -4161,11 +4156,20 @@ everybody — worse than showing nothing, because it looks like data. Send it on
 knows when the state actually began. It times the current `availability`, so it moves every time
 that value does.
 
-**The login is the permission.** A team member list goes to a login that declares `capabilities.team`, on
-every snapshot, and to nobody else. Omni never decides who leads a team: the provider said so at
-sign-in, and the team member list agrees with it — present, `[]` included, for a lead; absent for everybody
-else, which is the correct rendering for an agent who leads nobody. What the lead may do with the
-team member list is on the login too, `team.breakControl` and `team.leadAssistControl`, never on the team member list.
+**The login is the permission.** A team member list goes to a login that declares
+`capabilities.lead`, on every snapshot while the team feature is on, and to nobody else. Omni never
+decides who leads a team: the provider said so at sign-in, and the team member list agrees with it
+— present, `members: []` included, for a lead; absent for everybody else, which is the correct
+rendering for an agent who leads nobody (`team.required`, `team.unentitled`). What the lead may do
+with it comes with the flag: there is no per-action permission on the login or on the list.
+
+**The lead switches the feature on and off, and the provider is told.** A lead may work as an
+agent alone, as agent and lead, or as lead alone, and moves between them on the fly. The
+agent application says which with `{ type: "lead-features", enabled }`: while it is on, the
+provider sends team events scoped to the lead's team and the lead may act; while it is off, the
+lead is an ordinary agent, no team member list is owed or expected (`team.unexpected`,
+`event.team.features`), and no lead act is possible, since the lead learns their members'
+assignments only from the list. It is on from sign-in for a lead until the lead turns it off.
 
 **The team member list never carries the agent it is published to — not in `members`, and not in
 `requests`.** A lead does not report to themself: their own break request and their own ask for a
@@ -4173,24 +4177,36 @@ lead go up to whoever leads them and appear on *that* person's team member list,
 only their own `BreakState` and their task's `leadAssist` move. An adapter whose platform lists the lead
 among their own members filters the signed-in identity out before publishing. **Being a lead is a
 role the provider knows, never inferred from who is listed:** it is declared at sign-in, a lead
-with nobody in their team publishes `[]`, an agent with no such role publishes nothing, and no
+with nobody in their team publishes `members: []`, an agent with no such role publishes nothing, and no
 member count can tell those two apart.
 
 ### Lead commands
 
-One method, `executeTeamBreak`, taking a discriminated command exactly as `execute` takes a
-`TaskCommand`:
+One method, `executeTeam`, taking a discriminated command exactly as `execute` takes a
+`TaskCommand`. Every act on a member's call names the member, `memberId`, and may name the
+assignment, `assignmentId`, where the lead has it; the provider resolves the member's current
+assignment from the member alone.
 
 | Command | Effect |
 | --- | --- |
-| `{ type: "decide-break-request", memberId: UserId, 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: "lead-features", enabled }` | The team feature on or off. See **The lead switches the feature on and off** above. |
+| `{ 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: UserId, 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: UserId }` | Lifts the forced-break restriction, whoever forced it, by clearing `BreakState.forced`. The committed break continues; only the agent resumes work. |
+| `{ 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: "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**. |
+| `{ type: "coach", memberId, assignmentId? }` | The lead is heard by the member alone. Needs the lead on that member's call. |
+| `{ type: "join-call", memberId, assignmentId? }` | The lead is heard by everyone on the call. Needs the lead on that member's call. |
+| `{ type: "leave", memberId, assignmentId? }` | The lead's channel leaves the member's call, however it got there. The member's call goes on. |
+| `{ type: "take-over-call", memberId, assignmentId? }` | The provider moves the call to the lead as its new agent, from a joined call or a listened one alike. See **Lead assist**. |
+| `{ type: "set-policy", capability, setting }` | Sets the team's policy for one capability: `on`, `off`, or `person`. See **Who decides what an agent may do**. |
 
 `memberId` is this provider's own identifier for the member, as published on its team member list. It is
 never an identifier from another provider, and Omni does not translate between them; names come
-from `getUserDetails()`.
+from `getUserDetails()`. `validateTeamCommand` holds each command to the team member list as it
+stands -- see **Runtime break prerequisite checks**.
 
 `requests-suspended` means requests are **rejected outright** rather than left pending — nobody is coming to
 approve them. A provider that suspends break requests must also publish `canRequestBreak: false` to the team's
@@ -4204,71 +4220,56 @@ never expressed here.
 
 An agent on a call may ask a lead to join it -- a dispute that needs approval, a customer who
 asks for a manager, a moment the agent wants a second pair of ears. A call centre calls this
-assistance or escalation, and the name says who assists: the capability is `leadAssist` on the task; the lead's side is the team member list, which is already the lead's view of the
-team, and a second lead method beside `executeTeamBreak`:
-
-```ts
-executeTeamLeadAssist({ command: TeamLeadAssistCommand }): Promise<TeamCommandResult>
-```
-
-Required when the login declares `capabilities.team.leadAssistControl`, and gated by it exactly as
-`executeTeamBreak` is by `team.breakControl`. The flow, in order:
+assistance or escalation, and the name says who assists: the capability is `leadAssist` on the
+task; the lead's side is the team member list, which is already the lead's view of the team. The
+flow, in order:
 
 ```ts
 // 1. The agent asks, with a small note. Their task carries `leadAssist` from here on.
 execute({ assignmentId: "alloc-42", command: { type: "lead-assist", action: "request", note: "Refund dispute, needs approval" } })
 //    task.leadAssist = { stage: "requested", note: "Refund dispute, needs approval", since }
 
-// 2. Every lead entitled to it sees the request on their team member list.
-//    team-updated: requests: [{ id: "req-7", memberId: "A-1", assignmentId: "alloc-42", note, since }]
+// 2. Every lead with the team feature on sees the request on their team member list.
+//    team-updated: requests: [{ memberId: "A-1", assignmentId: "alloc-42", note, since }]
 
 // 3. A lead joins, or declines.
-executeTeamLeadAssist({ command: { type: "join", requestId: "req-7" } })
-executeTeamLeadAssist({ command: { type: "decline", requestId: "req-7", reason: "In a call" } })
+executeTeam({ command: { type: "join", memberId: "A-1", assignmentId: "alloc-42" } })
+executeTeam({ command: { type: "decline", memberId: "A-1", reason: "In a call" } })
 ```
 
-**On `join` the provider bridges three parties and the lead is on a task of their own**, an
-assignment of its own, arriving on the lead's connection as `task-offered` with `automatic`
--- the way a call an agent placed themselves arrives -- and carrying `assisting`, which names the
-member and the member's assignment. The agent's task
-moves to `leadAssist: { stage: "joined", leadId }`. A join is the lead's own act, so capacity does not
-trigger it; but from then on it is an outstanding task the provider counts against the lead's
-stated ceiling like any other, nothing more is assigned to the lead while it stands, and a
-provider whose lead is already at the ceiling answers the join `failed`.
-
-**A lead assists one call at a time.** A `join` from a lead already on a call -- their own or one
-they joined -- is answered `failed`, whatever their ceiling; the request stands for another lead,
-or until it is withdrawn or declined.
-
-**A lead on a break does not join.** A break is a reported state in which the agent is not working,
-and a join is work. Omni offers Join to a lead only while their own `BreakState.status` is neither
-`starting-after-task` nor `on-break` -- a committed break waiting for the lead's current work to
-finish is not given more -- and a provider answers a `join` from a lead on such a break `failed`.
-The request stands for another lead, as it does when this one is already on 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: { mode: "join-call", since }`, and the lead's audio arrives 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
+or a member's -- is answered `failed`; the request stands for another lead, or until it is
+withdrawn or declined. A join is work, so Omni offers Join only to a lead whose voice channel is
+free, and a provider answers a `join` from one whose channel is not `failed`.
 
 **On `decline`, or a request the agent withdraws with `{ type: "lead-assist", action: "cancel" }`, the
 provider clears `leadAssist` from the agent's task** and drops the request from every team member list. Nothing
 else changes; the agent is still on the call.
 
-**Take over call** uses `{ type: "lead-assist", action: "take-over-call" }`.
-The lead assumes the agent’s interaction; the caller’s wider journey continues.
-Migration: replace the former take-over action literal with `take-over-call` in hosts and
-providers together. The former spelling is rejected, with no compatibility alias.
-The `taken-over` task outcome and existing completion behavior remain unchanged.
-This action is distinct from `join-call`, which lets everyone hear a lead listening to a call.
+**On `leave`, the lead's channel drops and the call goes on**: the member's task loses its
+`leadAssist`, the member loses `listening`, and the lead is free. Nothing ended for the member.
 
-The lead then has two commands on their copy, gated by `assisting` being present, and a third
-choice that is no command at all:
+**On `take-over-call`, the provider moves the call from the member to the lead**, and the lead is
+its new agent. There are two paths to it -- the agent asked and the lead joined, or the lead was
+listening unasked -- and one act at the end of either. What follows is the same on both:
 
-| The lead | The agent's task | The lead's task |
+| | The member's task | The lead's desk |
 | --- | --- | --- |
-| `{ type: "lead-assist", action: "take-over-call" }` | `task-media-ended`, then `task-ended` with `{ type: "taken-over", leadId }`: **no `completing` window**, the agent is idle at once. The audio ends first, as before every voice ending (`stream.taskEnded.mediaOpen`), and the lead is named by user id, since a lead is not a directory item | Continues alone, and ends as any call does |
-| `{ type: "lead-assist", action: "leave" }` | Continues; `leadAssist` is cleared | `task-media-ended`, then `task-ended` with `{ type: "left" }` -- the call goes on without them |
-| Stays until the customer hangs up | `task-media-ended`, `completing`, its own outcome | The same, independently: **both have the completion window** |
+| Take-over | `task-audio-ended`, then `completing`: the member's interaction is over and their wrap runs, exactly as after `end-call`. The audio ends first, as before every voice ending (`stream.taskEnded.audioOpen`). | An ordinary assignment arrives: `task-offered` with `acceptance: "automatic"`, carrying the call's history and `takenOver: { memberId, since }`. |
+| The member completes | `task-ended` with `{ type: "taken-over", leadId }`, at the member's own completion. The lead is named by user id, since a lead is not a directory item. | The lead works the call as any agent would, and ends it as any call ends. |
 
-`left` is the one outcome that ends a task without ending the call: this agent left a call that
-continues without them. It reads as neither a completion nor a cancellation, because it is
-neither.
+**The taken-over call is offered whatever break the lead is on.** A lead working as lead alone is
+on a break of a working kind, and the provider assigns the call regardless: it is the one task a
+break in effect may hold (`break.on-break.tasks` allows it, and nothing else). It is the lead's own
+act, so it counts against no capacity, like the agent's own dial; the only conditions are that the
+lead is not already on another call and their voice channel is free. A lead with the team feature
+off cannot take over, since they have no member's assignment to name.
 
 ```ts
 const leadAssistCapable = {
@@ -4277,6 +4278,13 @@ const leadAssistCapable = {
   phase: "in-progress",
   leadAssist: { stage: "joined", leadId: "L-9", note: "Refund dispute, needs approval", since: "2026-08-21T09:04:00Z" },
 } satisfies Pick<Task<"voice">, "channel" | "capabilities" | "phase" | "leadAssist">;
+
+const takenOver = {
+  channel: "voice",
+  capabilities: { hold: true, endCall: true, outcomes: true },
+  phase: "in-progress",
+  takenOver: { memberId: "A-1", since: "2026-08-21T09:06:00Z" },
+} satisfies Pick<Task<"voice">, "channel" | "capabilities" | "phase" | "takenOver">;
 ```
 
 Lead and member alike are `UserId`s of this provider, so an adapter publishing them implements
@@ -4284,44 +4292,10 @@ Lead and member alike are `UserId`s of this provider, so an adapter publishing t
 
 ### Listening to a call
 
-**Listen** lets the lead hear the call without being heard. The modes are `listen`, `coach`
-(agent-only lead audio), and `join-call` (lead audio heard by everyone).
-
-| Former API | Current API |
-| --- | --- |
-| MonitorMode / MONITOR_MODES | `ListeningMode` / `LISTENING_MODES` |
-| TeamMonitorCommand / TeamMonitorCommandRequest | `TeamListenCommand` / `TeamListenCommandRequest` |
-| executeTeamMonitor | `executeTeamListen` |
-| team.monitorControl | `team.listeningControl` |
-| TaskMonitoring / task.monitoring | `TaskListening` / the task’s `listening` field |
-| MONITORING_BREAK_KINDS / breakKindAllowsMonitoring | `LISTENING_BREAK_KINDS` / `breakKindAllowsListening` |
-| monitor action and mode | `listen` action and mode |
-
-Update command dispatch, allowed modes, task snapshots, imports and diagnostics together.
-The former names are not aliases. Old task and permission fields are rejected even alongside
-new fields. Validation rule segments now use `listening`, `listeningControl`, and `listen`.
-The existing login permissions, single-call limits, allowed break kinds and audio effects
-remain unchanged. Listening includes its coach/join-call modes and does not imply takeover.
-
-
-**Coach** lets the lead speak privately to the agent; the caller cannot hear the lead.
-The command and listening mode are `coach`. Migration: replace the former whisper literal
-in `TeamListenCommand`, `ListeningMode`, `team.listeningControl`, and the task’s `listening.mode`.
-`LISTENING_MODES` exports `coach`; update command producers, permissions and retained snapshots
-together. No legacy alias is accepted. The lead must already be listening and permitted to
-coach. This mode does not join the audible caller conversation or take over the task.
-
-The user-facing action is **Join call**. The command and listening mode are `join-call`.
-Migration: replace the former barge literal in `TeamListenCommand`, `ListeningMode`,
-`team.listeningControl`, and the task’s `listening.mode`. `LISTENING_MODES` exports the new literal;
-no legacy alias is accepted. Update commands, capability declarations and retained snapshots
-together. The lead must already be listening and permitted to use this mode. Everyone on the
-call hears the lead; this does not transfer ownership or invoke lead-assist takeover.
-
 A lead may listen to a member's call without being asked -- to coach, to check quality, to step in
-when it goes wrong. This is not lead assist: nobody requested it, the member's task says nothing
-about it, and there is no take-over in it. A lead who wants the call itself uses lead assist. The
-three modes determine who hears the lead:
+when it goes wrong. It is a team act naming the member, and no task on the lead's desk carries it:
+the lead's view of the call is the member's task on the team member list, with its room and its
+history. The three modes determine who hears the lead:
 
 | Mode | Who hears the lead |
 | --- | --- |
@@ -4329,61 +4303,44 @@ three modes determine who hears the lead:
 | `coach` | The agent alone. The customer hears nothing. |
 | `join-call` | Everyone on the call. |
 
-The login says which modes this lead has, as a list on `team.listeningControl`, and it always
-includes `listen`, because coach and join-call begin from one
-(`authentication.capability.team.listeningControl.listen`). A centre that lets every lead listen but
-reserves joining the call declares `["listen", "coach"]`, and Omni offers no Join call to that lead. The
-declaration requires `executeTeamListen`, gated exactly as `executeTeamLeadAssist` is by
-`team.leadAssistControl`.
+All three come with the `lead` flag; a centre reserves none of them per lead. The flow:
 
 ```ts
 // 1. The lead picks a member from the team member list and starts silent.
-executeTeamListen({ command: { type: "listen", memberId: "A-1" } })
+executeTeam({ command: { type: "listen", memberId: "A-1" } })
+//    team-updated: the member carries listening: { mode: "listen", since }
+//    team-audio-started: { memberId: "A-1", assignmentId: "alloc-42" } -- the lead's audio attaches
 
-// 2. The lead's own task arrives -- task-offered with `automatic`, as a joined call does -- and
-//    carries `listening`; the assignment is the lead's own, the member's is named inside it.
-//    listening: { memberId: "A-1", assignmentId: "alloc-42", mode: "listen", since }
+// 2. The lead changes how they are heard; the provider restates the member with the new mode.
+executeTeam({ command: { type: "coach", memberId: "A-1" } })
+executeTeam({ command: { type: "join-call", memberId: "A-1" } })
 
-// 3. The lead changes how they are heard; the provider restates the task with the new mode.
-executeTeamListen({ command: { type: "coach" } })
-executeTeamListen({ command: { type: "join-call" } })
-
-// 4. The lead leaves; their task ends with `{ type: "left" }`. The member's call goes on.
-executeTeamListen({ command: { type: "leave" } })
+// 3. The lead leaves, or takes the call.
+executeTeam({ command: { type: "leave", memberId: "A-1" } })
+executeTeam({ command: { type: "take-over-call", memberId: "A-1" } })
 ```
 
-**The lead's task is what gives them audio**: Omni opens media on it as on any voice task, and the
-provider bridges the lead's leg into the member's call in the mode stated. `listening.mode` is
-the state, restated on every change, and a `coach` or `join-call` the login's list does not include
-is answered `failed`. **A lead listens to one call at a time** (`snapshot.listening.single`), and
-a task carries lead assistance or listening, never both (`task.listening.assisting`).
-The `join-call` mode still belongs to listening; it does not create `assisting`. The member's
-call ending ends the lead's task as it ends the member's, with `left`, since the lead was never
-working on it.
-
-**A lead listens only while holding no work of their own.** A listening task is the lead's only
-task, and a snapshot carrying one beside any other is refused (`snapshot.listening.alone`); Omni
-offers Listen to a lead with no task. That includes a lead on a break -- unlike joining, which a
-break forbids -- but only a break that is work of another sort: `coaching`, `administrative` or
-`training`, the kinds in `LISTENING_BREAK_KINDS`, and never a meal or a rest. A break in effect
-otherwise holds no task; the listening task is its one exception, and a snapshot carrying one
-during a break whose active reason is of any other kind, or of no stated kind, is refused
-(`snapshot.listening.break`). The kind decides, not the reason's name: a centre that wants leads
-listening during a break declares that break `coaching`, `administrative` or `training`.
+**The lead's audio arrives through team audio.** While the lead's channel is in a member's call
+-- listening, coaching or joined on request -- the lead's connection receives `team-audio-started`
+naming the member and the member's assignment, and on a softphone the agent application opens
+`openAudio` on that assignment as it does for a task; `team-audio-ended` closes it. Voice only, and
+to a login that declares `lead` (`event.teamAudio.*`). The member's own audio events are the
+member's and never reach the lead.
+
+**`listening` on the member is the state**, restated on every change of mode, and a lead is on
+one member's call at a time (`team.listening.single`). The member's call ending ends the lead's
+listening with it: the provider republishes the member without `listening` and sends
+`team-audio-ended`.
+
+**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.
 
-```ts
-const listeningLead = {
-  channel: "voice",
-  capabilities: {},
-  phase: "in-progress",
-  listening: { memberId: "A-1", assignmentId: "alloc-42", mode: "coach", since: "2026-08-21T09:04:00Z" },
-} satisfies Pick<Task<"voice">, "channel" | "capabilities" | "phase" | "listening">;
-```
-
 ### A member waiting for a break
 
 A member who has asked for a break **keeps working** until Omni commits it, so asking is not an
@@ -4411,27 +4368,27 @@ whole and replaced whole, and a provider that cannot say omits it.
 
 **An agent is not waiting on one person.** Authority is held by several, everyone who holds it
 sees the request on their own console, and **any one of them settles it**. Omni offers the
-decision to every login that declares `team.breakControl` — which is how the provider already
+decision to every login that declares `lead` and has the team feature on — which is how the provider already
 says who may decide — and does not try to work out whose turn it is.
 
 A request needing *more than one* approval is not something this contract describes. There is
 no partial state to report and no progress to display: a request is either still owed a
 decision or it is not.
 
-## Real-time media
+## Real-time audio
 
-Every voice provider has media: `channel: "voice"` says audio exists. Where the agent hears it
+Every voice provider has audio: `channel: "voice"` says audio exists. Where the agent hears it
 depends on the `phone` the agent application selected at authentication and connect from the manifest's
 `phones`. On a softphone, audio lands in Omni; on a desk phone, it lands on the handset and Omni
-opens no audio. See **How the agent hears the call**. Media transitions are voice-only;
-chat and email publish none (`event.media.channel`, `stream.taskMedia.channel`).
+opens no audio. See **How the agent hears the call**. Audio transitions are voice-only;
+chat and email publish none (`event.audio.channel`, `stream.taskAudio.channel`).
 
 The provider owns signalling and the platform's endpoint configuration. The agent application selects the
 declared phone mode; it does not enumerate or reconfigure the platform's devices. The selected
 mode stays with the login rather than being inferred from a snapshot or a device failure.
 
 Nor does the audio ever stand in for the task: a task's presence and
-phase follow the provider's reports about the work, and the media — attaching, moving through a
+phase follow the provider's reports about the work, and the audio — attaching, moving through a
 hold, a consult, a conference or a transfer, and ending — is transient beside it. See **A task is
 never its audio** under **Task assignment lifecycle**.
 
@@ -4468,7 +4425,7 @@ refuses a false one, as it refuses a name this contract does not list.
 | --- | --- |
 | `online` | Whether the agent application has a network interface up. Not a claim that anything is reachable — the adapter knows whether it can reach its own platform far better than the agent application does — so `false` is a reason not to go ready and `true` is not a reason to. |
 | `audio` | Present on a voice connection, absent where there is no audio. |
-| `audio.input` | `available` with `localAudio` — the microphone as captured, the same stream `openMedia` receives — and `flowing`, false while no audio moves through it, when `mutedBy` says who stopped it: `host`, the agent application's own Mute on an agent application that mutes the station, or `station`, a slider on the headset or the operating system, which the agent application observed and did not do. An adapter treats `host` as the agent's act on a call and `station` as a condition of the station. `unavailable` with `reason`, since each wants a different fix from the agent: `no-device`; `denied`; `not-asked`, which an agent application that asks at connect never publishes; `in-use`, a device present and permitted that another application holds — on an agent desktop the commonest of all; `lost`, a capture that ended. An agent application decides the reason from the devices before the error name: a browser can report a permission error on a machine with no microphone at all, and "grant permission" is the wrong instruction for an agent who needs to plug one in. `failure` carries the words Omni showed them. |
+| `audio.input` | `available` with `localAudio` — the microphone as captured, the same stream `openAudio` receives — and `flowing`, false while no audio moves through it, when `mutedBy` says who stopped it: `host`, the agent application's own Mute on an agent application that mutes the station, or `station`, a slider on the headset or the operating system, which the agent application observed and did not do. An adapter treats `host` as the agent's act on a call and `station` as a condition of the station. `unavailable` with `reason`, since each wants a different fix from the agent: `no-device`; `denied`; `not-asked`, which an agent application that asks at connect never publishes; `in-use`, a device present and permitted that another application holds — on an agent desktop the commonest of all; `lost`, a capture that ended. An agent application decides the reason from the devices before the error name: a browser can report a permission error on a machine with no microphone at all, and "grant permission" is the wrong instruction for an agent who needs to plug one in. `failure` carries the words Omni showed them. |
 | `audio.output` | `available`, with `flowing` where the agent application can know whether audio reaches the speaker — a browser mostly cannot, and omits it; a native agent application reads the endpoint — false while it is silenced, when `mutedBy` says who did it, as on input. Or `unavailable` with `reason` — `no-device`, or `lost` for one removed — and `failure`: an agent who cannot hear is as unable to take a call as one who cannot speak. |
 
 Omni republishes the report whenever it changes — a permission granted late, a headset unplugged,
@@ -4537,10 +4494,10 @@ A voice manifest lists its `phones` and any other channel lists none (`manifest.
 `manifest.phones.channel`). The agent application's `phone` is required on a voice login, absent on any other,
 and one the manifest listed (`context.phone.required`, `.unexpected`, `.unsupported`). Everything
 about audio then follows the phone rather than the channel: on a softphone the agent application reports its
-audio, the adapter implements `openMedia`, and `task-media-started` is the word to open it; on a
-desk phone the agent application reports no audio, opens nothing, and `task-media-started` still marks the
+audio, the adapter implements `openAudio`, and `task-audio-started` is the word to open it; on a
+desk phone the agent application reports no audio, opens nothing, and `task-audio-started` still marks the
 moment the call is live so the desk shows it, with the sound on the handset. A platform that lists
-`deskPhone` alone never implements `openMedia`; one that lists `softphone` always does.
+`deskPhone` alone never implements `openAudio`; one that lists `softphone` always does.
 
 **The mode comes from the agent application; the status comes from the provider.** The agent application knows which kind
 of station the agent signed in at, because the person chose it, and nothing else can know that.
@@ -4552,10 +4509,10 @@ the handset is momentarily unregistered, and demanding a microphone of it, is th
 sentence exists to refuse. What the provider does when the handset is not registered is what it
 does for any station that cannot take a call -- hold the agent not-ready and say why.
 
-**On a desk-phone login the agent application never calls `openMedia`.** There is no stream to hand over and
+**On a desk-phone login the agent application never calls `openAudio`.** There is no stream to hand over and
 no audio to attach; an agent application that calls it anyway is in error, and an adapter that receives the call
 answers `unavailable` with a non-retryable failure, since waiting changes nothing about a station
-that is a telephone. The harness requires no `openMedia` of such an adapter and never calls it.
+that is a telephone. The harness requires no `openAudio` of such an adapter and never calls it.
 
 **Which handset a desk-phone login rings is the platform's configuration for that agent**, and
 this wire never asks the agent for it: an agent application declares `phone` and nothing more. What a platform
@@ -4578,11 +4535,11 @@ is the administrator's, and a login is not a request to reconfigure an agent.
 
 ### Opening the audio
 
-`openMedia` hands Omni the remote audio for one task. Every adapter whose manifest lists
+`openAudio` hands Omni the remote audio for one task. Every adapter whose manifest lists
 `softphone` implements it, because on a softphone the call's audio lands in Omni:
 
 ```ts
-openMedia({ assignmentId, localAudio }): Promise<OpenMediaResult>
+openAudio({ assignmentId, localAudio }): Promise<OpenAudioResult>
 // { status: "opened", session } | { status: "unavailable", failure }
 ```
 
@@ -4605,8 +4562,8 @@ carries as `audio.input.localAudio`, and absent while that input is `unavailable
 bridges audio without an application-side input may ignore it; one that needs it and finds it absent
 answers `unavailable` with a failure Omni shows the agent.
 
-**When to ask is the provider's word, not Omni's guess.** On a softphone login, Omni opens media on `task-media-started`,
-and on a task arriving with `media: "started"` on a snapshot; it closes on `task-media-ended` and
+**When to ask is the provider's word, not Omni's guess.** On a softphone login, Omni opens audio on `task-audio-started`,
+and on a task arriving with `audio: "started"` on a snapshot; it closes on `task-audio-ended` and
 when the task ends. Between those words, nothing Omni's own senses report — a stream that drops, a
 track that ends — moves the task or its audio.
 
@@ -4619,7 +4576,7 @@ platform is the adapter's business.
 ## Task commands
 
 Command names follow the channel's operational vocabulary, and each channel's command is a union
-discriminated by `type` — the same discriminant `executeTeamBreak` and `custom` already use. The
+discriminated by `type` — the same discriminant `executeTeam` and `custom` already use. The
 unions are declared under **Shapes**.
 
 `assignmentId` is not repeated on the command. It travels on the `TaskCommandRequest` around it.
@@ -4656,8 +4613,8 @@ agent application's. So mute is not a capability a provider declares, not a cont
 locks, not a preference the person keeps with the provider, and not a command: nothing about the
 station crosses to the provider except two things -- the station's condition, in the agent application report,
 and the record of when the agent could not be heard, through `recordStep`. An agent application offers Mute on
-every voice task with media open, under its own local policy, in `in-progress` and `paused`
-alone, and performs it through `VoiceMediaSession.setMuted()`. A task carrying
+every voice task with audio open, under its own local policy, in `in-progress` and `paused`
+alone, and performs it through `CallAudio.setMuted()`. A task carrying
 `capabilities.mute` is refused (`task.capability.unknown`), and so is a `mute` command
 (`command.type`), a `mute` preference (`preference.id`) and a `mute` policy (`team.policy.key`).
 
@@ -4693,9 +4650,9 @@ forty seconds" and "the agent's headset was muted for forty seconds" as the diff
 are. See **The agent application records what it performs**.
 
 **Mute has a lifecycle, and none of it is inferred.** A call that starts while the station is
-already muted begins a `muted` leg the moment its media starts, `mutedBy: "station"`. Media that
+already muted begins a `muted` leg the moment its audio starts, `mutedBy: "station"`. Audio that
 ends while any leg is open ends the leg at that instant, as every agent application-performed leg ends. And the
-agent application's own Mute starts off on every call, which is every `task-media-started` -- a connect-back
+agent application's own Mute starts off on every call, which is every `task-audio-started` -- a connect-back
 opens a second call on the same task with no offer -- so an agent is never muted by the call before.
 
 **Every press on a headset is the agent's own press**, performed the agent application's way, and the lights
@@ -4731,22 +4688,22 @@ declared:
 | Command | What makes it available |
 | --- | --- |
 | `answer`, `accept` | Nothing. A task that was offered can be accepted, or offering it meant nothing. |
-| `end-call` | The `endCall` capability. |
+| `end-call` | The `endCall` capability: ends my part, the caller continues. |
+| `terminate-call` | The `terminateCall` capability: ends the caller channel. |
 | `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. |
-| `call` | 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`. |
+| `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` | `completionMode: "agent-command"`. 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. |
 | `transfer` with `action: "warm"` | The `warmTransfer` capability. `action: "cold"` is gated by `coldTransfer`; the two are declared and offered separately. |
 | `transfer` with `action: "complete"` or `"cancel"` | A consultation in progress -- a `consulted` entry on `Task.onCall`. Without one there is nothing to complete or cancel, and a provider that receives either answers `failed`. |
 | `lead-assist` with `action: "request"` or `"cancel"` | The `leadAssist` capability. `cancel` needs a request standing -- `Task.leadAssist` with status `requested`. |
-| `lead-assist` with `action: "take-over-call"` or `"leave"` | The lead's own task, on a call they joined -- `Task.assisting` present. An agent's task never has it, and a provider that receives either without it answers `failed`. |
 | `transfer` with a destination, `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`). |
 | Everything else | Its own named capability. |
 
 **A control on the contact belongs to the interaction phases**, `in-progress` and `paused`:
-`hold`, `resume` and `pause`, `end-call`, every `transfer` and `conference` action, and
+`hold`, `resume` and `pause`, `end-call` and `terminate-call`, every `transfer` and `conference` action, and
 every `lead-assist` action. These controls act within this agent's current interaction.
 In `completing`, that interaction has ended and its wrap work remains. The caller may still be in
 an IVR, queue or another agent's interaction, and other channels may remain connected. Completion
@@ -4755,7 +4712,7 @@ declared while the task remains open; the phase prevents this task from controll
 it no longer owns. Omni shows these controls only in the two interaction phases, and
 `validateTaskCommand` refuses them outside those phases (`command.phase.interaction`).
 The commands with a phase of their own -- `answer`, `accept` and `decline` in `pending`,
-`call` in `preview`, `connect-back` in `completing`, `complete` in any -- are not among them.
+`dial` in `preview`, `connect-back` in `completing`, `complete` in any -- are not among them.
 
 `validateTaskCommand(command, task)` holds a command to this table at runtime, both ways: the
 capability it needs, the phase it belongs to, and the state that has to stand. The task it wants
@@ -5104,30 +5061,30 @@ snapshots until it ends.
 Replaces the current representation of one provider-local task. It is a full task value, not a
 partial patch.
 
-### `task-media-started`
+### `task-audio-started`
 
-The provider's word that the task's audio should now attach. Omni calls `openMedia` on it — and on
-a task carried with `media: "started"`, which is how a reconnect snapshot reattaches audio an
+The provider's word that the task's audio should now attach. Omni calls `openAudio` on it — and on
+a task carried with `audio: "started"`, which is how a reconnect snapshot reattaches audio an
 earlier event brought — and renders the call as live from that word, never from its own senses. It
-precedes `openMedia` and is never a reply to it: a provider whose media state comes from the
+precedes `openAudio` and is never a reply to it: a provider whose audio state comes from the
 platform, a station going in use the moment a call is answered, sends it then, before any agent application has
-opened anything, and `openMedia` has its own answer for what the agent application did. It
-names a task whose work has begun, and it alternates with `task-media-ended`: media that never
+opened anything, and `openAudio` has its own answer for what the agent application did. It
+names a task whose work has begun, and it alternates with `task-audio-ended`: audio that never
 started cannot end, so a live call whose provider says nothing about its audio is a provider in
 breach, not a state a desk fills in from its own devices.
 
-The event is the transition and the task's `media` field is the state. A `task-updated` re-states
-the media its task already holds — republishing `started` on a hold is a statement, not a second
+The event is the transition and the task's `audio` field is the state. A `task-updated` re-states
+the audio its task already holds — republishing `started` on a hold is a statement, not a second
 arrival — but it does not move it: an update that itself flips the field is refused
-(`stream.taskUpdated.media`), and the pairing at the moment audio arrives is the phase change
+(`stream.taskUpdated.audio`), and the pairing at the moment audio arrives is the phase change
 without the field, then the event. Releasing `ended` is the one move an update may make, since
 wrapped audio has nothing left to end.
 
-### `task-media-ended`
+### `task-audio-ended`
 
-Signals that a task's real-time media ended. For voice and similar channels, this starts the fixed
-completion timer. It does not remove the task, and it ends only audio that `task-media-started` — or
-a task carried with `media: "started"` — attached.
+Signals that a task's real-time audio ended. For voice and similar channels, this starts the fixed
+completion timer. It does not remove the task, and it ends only audio that `task-audio-started` — or
+a task carried with `audio: "started"` — attached.
 
 ### `task-ended`
 
@@ -5135,22 +5092,22 @@ Every outcome ends the task for this agent. On `task-ended`, Omni:
 
 - removes the task from its current provider view;
 - clears the task workspace when it is selected;
-- stops task timers and media;
+- stops task timers and audio;
 - releases task-scoped resources; and
 - selects another task or returns to the idle workspace.
 
-A `left` outcome ends the task for this agent alone: the call continues without them, as it does
-when a lead who joined it leaves -- see **Lead assist**.
+A `taken-over` outcome arrives at the member's own completion, after the wrap that follows a
+take-over as it follows an `end-call` -- see **Lead assist**.
 
 A successful `complete` or `transfer` command does not clear the task. Omni waits for `task-ended`,
-and not for ever: `applied` to a completion -- `complete`, or a lead's `take-over-call` -- says the
+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
 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
 task, since the ending was owed and lost. The drive holds a provider to the same bound
-(`drive.completion.unsettled`). The `task-media-ended` event and the `completing` phase are likewise
+(`drive.completion.unsettled`). The `task-audio-ended` event and the `completing` phase are likewise
 non-terminal. A replacement
 snapshot that no longer contains the task also clears it. Repeated `task-ended` delivery with the
 same envelope ID is harmless, and a `task-ended` naming an assignment that has already ended is
@@ -5184,8 +5141,8 @@ console is the silence problem one layer up. One event per occurrence; the agent
 provider does not batch. `exerciseAdapter` treats a diagnostic delivered during a run as a
 violation (`diagnostic.raised`): a conformance run against a platform that is breaking its rules
 fails loudly rather than passing with a note. A task published under `capabilitySource:
-"undetermined"` is the same kind of fact, stated on the task instead, and fails a run the same way
-(`capabilitySource.undetermined`); see **Task capabilities**.
+"not-yet-read"` is the same kind of fact, stated on the task instead, and fails a run the same way
+(`capabilitySource.notYetRead`); see **Task capabilities**.
 
 | Field | Contract |
 | --- | --- |
@@ -5211,7 +5168,7 @@ each connected provider.
 Replaces this provider's complete `TeamMembers`. It is emitted only for an agent the provider
 publishes a team member list to, and it carries the whole team every time — never a change to it, for the
 reason set out under **Team leads**. A lead's snapshot always carries the team member list; it goes only when
-a republished `authenticated` no longer declares `capabilities.team`.
+a republished `authenticated` no longer declares `capabilities.lead`, or the lead turns the team feature off (`event.team.features`).
 
 ### `contacts-updated`
 
@@ -5285,9 +5242,9 @@ Some rules need to know who is reading. `validateTeamMembers`, `validateSnapshot
 `AuthenticationState.identity.id` and their login's `capabilities`. Given `self`, a team member list that
 carries that agent reports `team.member.self` or `team.request.self`. Given `capabilities`, a lead's
 snapshot without a team member list reports `team.required`, a team member list published to a login that does not lead
-reports `team.unentitled`, `requests` on a team member list whose login lacks `team.leadAssistControl` reports
-`team.requests.capability`, and a team member list without them on a login that declares it reports
-`team.requests.required`. Without them those rules are not checked, because they cannot be.
+reports `team.unentitled`, and a `team-updated` to such a login reports `event.team.capability`; given
+`leadFeatures: false`, a team member list reaching a lead who turned the feature off reports
+`team.unexpected` or `event.team.features`. Without them those rules are not checked, because they cannot be.
 `exerciseAdapter` always passes both.
 
 `assertNoViolations(violations)` throws `ProtocolConformanceError` — which carries the full
@@ -5355,10 +5312,10 @@ Nothing there is a violation: an adapter with no team has nothing to exercise. B
 no tasks exercises no task rule, and a pass over it reads as coverage it is not.
 
 **A static run never answers a call.** It states a capacity and disconnects, so everything
-downstream of `answer` -- the room, the stage, media, every phase past `pending`, every dial
+downstream of `answer` -- the room, the stage, audio, every phase past `pending`, every dial
 outcome -- stays in `notExercised` for every adapter, and a rule about a live call is enforced only
 in each adopter's own tests. `{ drive: true }` closes that: the exercise takes the first task the
-provider offers through one ordinary lifecycle -- accept it, wait for its media and open it on a
+provider offers through one ordinary lifecycle -- accept it, wait for its audio and open it on a
 softphone, hold and resume where the task offers `hold`, end the call where it offers `endCall`,
 complete it with an outcome where the agent completes -- and holds every step to the rules a
 agent application holds a provider to. Each command is validated against the task as published
@@ -5373,17 +5330,17 @@ nothing (`getUserDetails.user.*`, `getUserDetails.unasked`, `connection.getUserD
 the second adapter a `rebuild` gives comes up signed in as the same login from the secrets alone
 before it reads anything (`drive.reload.login`), and is then held to everything the first was on
 connect: the methods its declarations call for, the agent application's report, a capacity stated to it, its
-snapshot read as the connect snapshot was, and its media opened afresh on a task carried with
-`media: "started"`, since the first client's session died with it. The result also says which rules the
+snapshot read as the connect snapshot was, and its audio opened afresh on a task carried with
+`audio: "started"`, since the first client's session died with it. The result also says which rules the
 run evaluated, pass or fail, in `rulesEvaluated`: the validators' as each was applied, the stream's
 as each case was considered, so a test that needs a rule to have run asserts it there rather than
 inferring it from an empty `violations`, and a rule absent from it was never looked at, which is a
 gap and not a pass. With the audio open on a softphone,
 the drive mutes it for one second and reports the leg through `recordStep`, begun and then ended,
 expecting each report `recorded` with the provider-selected history `at` (`drive.recordStep.failed`, `.rejected`, `result.recordStep.at`); then it mutes again and
-ends the call muted, as agents do, so the leg is open when the media ends, the provider closes it
+ends the call muted, as agents do, so the leg is open when the audio ends, the provider closes it
 in the completing publication or the open entry is refused (`task.history.muted.open`),
-and the drive's closing report after the media ended is expected `recorded` and to change nothing:
+and the drive's closing report after the audio ended is expected `recorded` and to change nothing:
 a record restated afterwards with that leg's duration altered is named (`drive.recordStep.overwritten`).
 Where the provider restates the task's record afterwards, each leg is in it or the hole is named
 (`drive.recordStep.history`). Given `rebuild`, a way to build the adapter again as an agent application reload
@@ -5396,7 +5353,7 @@ the record in memory has nothing and is named (`drive.reload.snapshot`, `drive.r
 `.rejected`). The second adapter's snapshot is taken as any resync is: held to what the stream knew
 before it replaces it, so a phase gone backwards, a record that shrank or audio forgotten on a task
 still at work is named by the stream's own rules (`stream.snapshot.phase`, `.history`,
-`.media`) and a reload is a place those rules keep working, not one where they stop. The second
+`.audio`) and a reload is a place those rules keep working, not one where they stop. The second
 adapter is held to what the first was: the same provider
 (`drive.reload.manifest`), a snapshot that stands as any snapshot must, and a record that lost none
 of the entries the first had published -- a record once read is not unread across a reload either.
@@ -5423,15 +5380,15 @@ completed from wherever it stands once the drive has nothing left to do on it --
 after an `end-call`, or from `in-progress` where there is no call to end, which is every chat and
 email and a voice task offering no `endCall` -- so a conversation reaches its end as a call does.
 The drive stops where the task offers no way on and says nothing about what it could not reach. A
-softphone adapter written for a browser needs its media APIs supplied by whatever runs the
-harness: the drive opens media outside a browser, and a provider that quietly stopped carrying audio
+softphone adapter written for a browser needs its audio APIs supplied by whatever runs the
+harness: the drive opens audio outside a browser, and a provider that quietly stopped carrying audio
 where `AudioContext` was missing would be lying about the one thing the channel is for. It is off by default because it issues
 commands against whatever platform the adapter is connected to: turn it on against a test backend.
 
 ```ts
 const driven = await exerciseAdapter(adapter, context, { collectOnly: true, drive: true });
 expect(driven.violations).toEqual([]);
-assertReached(driven, ["task.onCall", "task.media", "event.task-ended"]);
+assertReached(driven, ["task.onCall", "task.audio", "event.task-ended"]);
 ```
 `assertReached(result, subjects)` is the paired assertion: it throws naming every subject the run
 never met, so a test that meant to check a team member list cannot pass on a fixture that never produced one.
@@ -5459,7 +5416,7 @@ cannot be established from TypeScript structure alone.
 
 | Helper | Contract checked |
 | --- | --- |
-| `assertCapabilityWithdrawal(states, snapshot, manifest)` | A capability withdrawn by a later `authenticated` state is gone from the next snapshot: no team member list for a login that no longer leads, no requests for one that may no longer join. Every state is validated on the way, `refreshing` must carry the login over, and the sequence passes only through usable states. |
+| `assertCapabilityWithdrawal(states, snapshot, manifest)` | A capability withdrawn by a later `authenticated` state is gone from the next snapshot: no team member list for a login that no longer leads. Every state is validated on the way, `refreshing` must carry the login over, and the sequence passes only through usable states. |
 | `assertTaskCapabilityWithdrawal(tasks, manifest, command)` | A capability withdrawn by a republish of the task is gone from the task: every task in the sequence is validated, all carry the offer's id, at least one capability the offer declared is absent at the end (a locked control is present, not withdrawn), and `command` is clean against the first task and refused against the last for want of a withdrawn capability and nothing else. Pair it with `assertCommandRefusedAfterWithdrawal` on the provider's answer. |
 | `assertCommandRefusedAfterWithdrawal(result)` | A command that arrives after its capability was withdrawn fails with `omni.capability-not-enabled`, named by the provider. The same assertion serves a command the provider never supported under a capability it declares. |
 | `assertReached(result, subjects)` | The exercise met every subject named; throws listing those it did not. Pair it with a clean `exerciseAdapter` result. |
@@ -5468,11 +5425,11 @@ cannot be established from TypeScript structure alone.
 | `stillHost(report?, guarantees?, mute?)` | An agent application that reports one thing and never changes, for a test context: `{ online: true }` by default, a report with audio for a softphone voice adapter, and never for a desk phone. |
 | `TaskStream`, `BreakStream` | The cross-event models the harness applies after the connect snapshot, exported for an agent application that wants the same rules at its boundary: `seed(snapshot)`, then `apply(envelope)` returns the violations. |
 | `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. |
-| `assertMediaFollowsTheTask(envelopes, snapshot?)` | The media follows the task and never decides it: every task is introduced once, `task-media-started` and `task-media-ended` alternate on work that has begun, media ends only where it arrived, and what follows the media ending is `completing` or `task-ended`. The harness applies the same rules to every event after the connect snapshot (`stream.*`). A sequence with no media satisfies it by never testing it — pair it with the assertion that the media end is present. |
+| `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`. |
 | `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, mediaEndedAt, deadline, toleranceMs?)` | The wrap deadline equals media 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. |
+| `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. |
 | `assertBrowserSessionIsolation(left, right, expected)` | Browser reuse follows only the declared isolation scheme. |
 | `assertNoBrowserSessionKeyCollisions(scenarios)` | No two distinct scenarios derive the same session key. Feed it adversarial names. |
 
@@ -5505,11 +5462,11 @@ action sets. The outer capability may be locked. Absence grants no permission, a
 exist without any permission. A provider may offer only stop for a recording started automatically,
 or withdraw a control on a later task update. There is no global recording mode and no automatic
 start from a capability declaration. Agent application support is declared on `ConnectContext.host.recording`,
-not the provider-owned manifest. The task chooses an explicitly provisioned agent application destination;
-unknown destinations or unsupported actions are refused visibly, never redirected to provider
-recording or a default upload location. Initial agent application support requires voice softphone media and
+not the provider-owned manifest. The task names one of the storage places the agent application provisioned, by `storageId`;
+an unknown storage place or an unsupported action is refused visibly, never redirected to provider
+recording or a default upload location. Initial agent application support requires voice softphone audio and
 capture of both local and remote audio; an agent application unable to capture either must refuse start/resume.
-This package declares that contract; it supplies no recorder, media mixing, storage or upload.
+This package declares that contract; it supplies no recorder, audio mixing, storage or upload.
 
 | Action | Required current recording state | Confirmed outcome |
 | --- | --- | --- |
@@ -5540,7 +5497,7 @@ There is no automatic restart, transfer to another recorder, or stop on task hol
 Task removal does not prove recording stopped: outstanding agent application recorders remain tracked by the
 agent application until its executor reconciles/finishes them, with visible unresolved cleanup failures.
 
-Only start/resume require an in-progress or paused task with started media. Pause/stop/cancel may
+Only start/resume require an in-progress or paused task with started audio. Pause/stop/cancel may
 also finish an independently observed recorder while the task is completing. A pending task may
 show active recording, but agent controls wait until interaction begins. The two recording paths may
 both be active. A command to either path has no implied effect on the other.
@@ -5583,9 +5540,9 @@ This change does not publish a package or enable recording in any existing agent
 semantics, including pause/resume identity and rejection of a dialling result. It cannot prove audio
 retention/completion or source truth from a status flag; those remain executor obligations.
 
-Agent application destination selection binds storage when start actually creates a recording. Existing recordings
+The storage place named on the task is bound when start actually creates a recording. Existing recordings
 keep that binding through pause/resume/stop/cancel; a later policy cannot redirect their stored audio.
-The executor rejects a mismatched destination rather than moving or discarding another binding.
+The executor rejects a mismatched storage place rather than moving or discarding another binding.
 Action permission does not authorize unattended invocation: agent application controls require the agent's explicit
 act, and provider authorization remains enforced at its authenticated command boundary.