@xema/omni-protocol 0.1.114 → 0.1.115

package/guide/agent.md

@@ -1,6 +1,6 @@
 # `@xema/omni-protocol`: The agent's work
 
-What an agent does on any channel: the assignment from offer to wrap, the task and its record, the controls a task offers, the commands the desk sends. Part of the contract in `guide.md`, which holds the terms, the shapes and the rules every file here relies on; a reference in bold names the file it points into where that is not this one.
+What an agent does on any channel: the assignment from offer to wrap, the task and its record, the controls a task offers, the commands the agent computer sends. Part of the contract in `guide.md`, which holds the terms, the shapes and the rules every file here relies on; a reference in bold names the file it points into where that is not this one.
 
 ## Task assignment lifecycle
 
@@ -66,7 +66,7 @@ agent's own act — a dialpad call or a connect-back, recognisable by the agent
 `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
+the agent computer shows no **Accept** for a call the agent placed. The local policy governs work the queue
 routes to the agent, and nothing else.
 
 ### Pending
@@ -95,7 +95,7 @@ medium the task arrives on, not a separate decision.
 **Once a task is accepted, the call that comes with it is answered.** Omni has no discretion
 there and the provider is not consulted twice: one decision about the work, and the medium
 follows it. Where the audio lands was settled at sign-in — in Omni on a softphone, on the handset
-on a desk phone — and is not in question per call. See **How the agent hears the call** in `guide/phone.md`.
+on a hardphone — and is not in question per call. See **How the agent hears the call** in `guide/phone.md`.
 
 Automatic acceptance still begins with `task-offered`.
 
@@ -111,7 +111,7 @@ Omni withdraw **Accept** from a task still pending.
 **A deadline is seconds left, never an instant.** The agent application and the provider keep
 different clocks, and a countdown that compares one against the other is a countdown that runs
 fast or slow by their skew. Seconds from the publication that carries them are the provider's own
-arithmetic, counted down on the desk from the moment they arrive, and the transport delay is the
+arithmetic, counted down on the agent computer from the moment they arrive, and the transport delay is the
 only error. Restated on every publication that carries them, so a snapshot after a reconnect
 starts the countdown afresh from what is actually left (`task.pending.expiresInSeconds`,
 `task.preview.previewEndsInSeconds`: a whole number, zero or more).
@@ -166,7 +166,7 @@ time. Runtime conformance checks also require the task channel to match its prov
 | `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, and takes the agent's `complete` as finishing early. A required outcome is the agent's to give, so it needs `agent-command` (`task.outcomes.required.mode`). |
 | `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; stated, it is the expected wrap, shown and never acted on. `0` under `provider-automatic` is no wrap at all, so such a task publishes no `outcomes` (`task.outcomes.wrapAllowance`). |
-| `wrapEndsInSeconds` | In `completing`, wherever `wrapAllowance` is stated: how much of the wrap is left, in whole seconds from this publication, restated on every publication that carries it (`task.completing.wrapEndsInSeconds`, `.required`, `.unexpected`). A reloaded desk and a lead's screen count down the same number. See **Completion timing**. |
+| `wrapEndsInSeconds` | In `completing`, wherever `wrapAllowance` is stated: how much of the wrap is left, in whole seconds from this publication, restated on every publication that carries it (`task.completing.wrapEndsInSeconds`, `.required`, `.unexpected`). A reloaded agent computer and a lead's screen count down the same number. See **Completion timing**. |
 | `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, `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. `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** in `guide/voice.md`. |
@@ -224,7 +224,7 @@ and a re-offer. Everything that names a task after the fact -- a dial outcome, a
 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
-and keeps the mapping, and the desk never learns which. A late event finds the assignment it
+and keeps the mapping, and the agent computer never learns which. A late event finds the assignment it
 belongs to or is refused, and a task-scoped browser session (`PROVIDER_NAME__ASSIGNMENT_ID__TAB_NAME`)
 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
@@ -263,14 +263,14 @@ so a `provider-automatic` task with `wrapAllowance: 0` publishes no `outcomes` a
 
 **The allowance means one thing per mode.** Under `provider-automatic` it is what the provider
 acts on: the task ends when it runs out. Under `agent-command` it is the expected wrap, stated so
-the agent can see it: the desk counts it down and, past zero, shows how far over they are, and
+the agent can see it: the agent computer counts it down and, past zero, shows how far over they are, and
 nothing acts on it -- the task waits for `complete` however long that takes, with its outcomes
 collected whenever the agent gives them. A provider that would end the task at a time is
 `provider-automatic`.
 
 **What is left travels with the task.** The allowance is the length; `wrapEndsInSeconds` is how
 much of it remains, stated on the `completing` task and restated on every publication that
-carries it, as `previewEndsInSeconds` is on a preview. A desk that reloads mid-wrap finds the
+carries it, as `previewEndsInSeconds` is on a preview. An agent computer that reloads mid-wrap finds the
 number on the snapshot; a lead's screen finds it on the member; neither starts a clock of its own,
 and both count down from receipt. Under `provider-automatic` the provider ends the task when it
 reaches zero; under `agent-command` it is the expected wrap left, `0` once overrun, and nothing
@@ -309,7 +309,7 @@ outcome, and complete the task.
 
 `0` means no wrap under `provider-automatic`: the provider completes the task at the end of the
 interaction, and `complete` has nothing to cut short. Under `agent-command` it is an expected wrap
-of nothing -- the desk shows the overrun from the start -- and the task still waits for `complete`.
+of nothing -- the agent computer shows the overrun from the start -- and the task still waits for `complete`.
 
 There is no value meaning "unlimited", because a number that is not a duration would be read as
 one. A provider that imposes no deadline says so by **omitting** `wrapAllowance`, which
@@ -375,16 +375,19 @@ Migration from the earlier spellings:
 | ForcedBreak.expectedDurationMs | `expectedEndsInSeconds`: seconds left, restated (`break.forced.expectedEndsInSeconds`, `.expectedDurationMs.renamed`); the command keeps `expectedDurationMs` |
 | MemberShift; the day on the lead's list alone | `Shift`, on `Snapshot.shift` and `shift-updated` for the agent, on `TeamMember.shift` for the lead |
 | TeamMember.listening as this lead's one entry | `MemberListening[]`, every lead's, each with `leadId` (`team.member.listening.leadId`, `.unique`, `.empty`, `.entry`, `.heard`) |
-| a member's history trimmed on the lead's list | the record whole, as the member's desk holds it |
+| a member's history trimmed on the lead's list | the record whole, as the member's computer holds it |
 | durations counted from the screen's clock | the provider's: `timeCheck` required of a provider publishing a running instant (`manifest.timeCheck.required`), `Snapshot.providerTime` with it (`snapshot.providerTime`, `.unexpected`) |
-| a wrap the desk timed from an event's receipt | `Task.wrapEndsInSeconds` in `completing`, restated (`task.completing.wrapEndsInSeconds`, `.required`, `.unexpected`) |
+| a wrap the agent computer timed from an event's receipt | `Task.wrapEndsInSeconds` in `completing`, restated (`task.completing.wrapEndsInSeconds`, `.required`, `.unexpected`) |
 | MemberTask.capabilities, capabilitySource, browsers | gone: the workspace never travels to a lead (`team.member.task.workspace`); the record and the completion terms do |
 | a member republished on a hold, a mute, a take-over | on every publication of the member's task to the member |
 | two clients on one login | the later wins; the first is ended with `recovery: "displaced"` |
 | the phone unspoken | `PhoneState` -- the device, its mute, its channels -- on `Snapshot.phone`, `phone-updated` and `TeamMember.phone`, from a manifest declaring `phoneStatus` (`snapshot.phone.required`, `.unexpected`, `phone.*`, `phone.channel.*`, `event.phone.capability`) |
 | the agent's readiness for the next call read into setCapacity | the agent's own queue: `capabilities.nextCall`, `requestNextCall`/`cancelNextCall`/`releaseLinedUp`, `Snapshot.nextCall` and `linedUp`, the `next-call` and `lined-up` events (`snapshot.nextCall.idle`, `nextCall.*`, `linedUp.*`) |
 | a harness that exercised an adapter, drove a call and evaluated rules | the harness reads as a test: `testAdapter`, `withCall`, `timeoutMs`, `notTested`, `rulesTested`, rules `test.*` (`test.timeout`, `test.offer.expired`, `test.preview.deadline`, ...) |
-| an `end-call` while the caller was on hold | refused: a `paused` task is resumed first (`command.endCall.held`), the desk shows End call disabled on hold, the provider answers `failed`, and the test names an adapter that ends from hold (`test.command.held`); `terminate-call` is not gated, it ends the caller's channel too |
+| an `end-call` while the caller was on hold | refused: a `paused` task is resumed first (`command.endCall.held`), the agent computer shows End call disabled on hold, the provider answers `failed`, and the test names an adapter that ends from hold (`test.command.held`); `terminate-call` is not gated, it ends the caller's channel too |
+| the handset spelled by its place on a desk | `hardphone`, on the manifest's `phones` and the login's `phone`; the former spelling is refused |
+| the desk | the agent computer, in the guide's prose |
+| the agent application's Mute on hold | unavailable while the task is `paused`, promised at login by a softphone login's agent application (`host.guarantees.muteUnavailableOnHold`, required there and refused of a hardphone login); a host mute beginning on a paused task is refused (`historyReport.muted.held`) and the test names an adapter that records one (`test.recordStep.held`) |
 
 Update producers, consumers, saved task snapshots, and validation-rule assertions together.
 History and report rule names use `history` and `historyReport`; assignment rules use
@@ -428,7 +431,7 @@ 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 audio is up, so a `held` entry without `seconds` on a task that is not paused, or a
+only while its audio is up and the agent application's own never begins on hold (`historyReport.muted.held`), 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
@@ -485,7 +488,7 @@ or combine them: report the representation conflict. No ambiguous event is silen
 **Interaction 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 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
+duration is the `held` entry's `seconds`, and an agent computer that restarts its counter on resume is
 counting the wrong thing.
 
 `muted` is there because the mute is the agent application's and never the provider's — see **The station is
@@ -541,10 +544,10 @@ different claim — it says the task has had none.
 
 **What the record adds up to is stated, not summed.** A call that has changed hands arrives
 carrying what others already used of it, and the agent reads that before they say hello: the
-totals are the provider's own — never a desk summing instants that may be rounded or skewed, for
+totals are the provider's own — never an agent computer summing instants that may be rounded or skewed, for
 the same reason `seconds` is reported and not derived — and each is present when the provider
 knows it and absent when it does not, never a plausible nought. A fresh call from the queue has
-`steps` with no prior `answered` and no totals to state, and a desk shows nothing rather than
+`steps` with no prior `answered` and no totals to state, and an agent computer shows nothing rather than
 zeros. The record is restated with the task on every `task-updated` and snapshot, so an entry
 that arrives late corrects the sums. These four are what every platform reports; more will be
 added here as a need is shown, not invented ahead of one.
@@ -579,7 +582,7 @@ did ask for them forwards upstream, and how often, is its own business. The step
 `recordStep` is required of every softphone login's connection, since every call on a softphone
 can be muted by the agent application, and answers `recorded` with the canonical history `at`. A `muted` report says whose the silence was,
 `mutedBy: "host"` or `"station"`, and no other report has the word (`historyReport.mutedBy`,
-`.mutedBy.unexpected`). On a desk phone the microphone is the phone's:
+`.mutedBy.unexpected`). On a hardphone the microphone is the phone's:
 the agent application mutes nothing and records nothing.
 
 **The record is a record.** The microphone is the agent application's, and nothing in the
@@ -816,7 +819,7 @@ until the queue's terms arrive, and that the controls may change when they do --
 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: `nobody` is silence, `not-yet-read` is a
+words are close in English and far apart on the agent computer: `nobody` is silence, `not-yet-read` is a
 standing notice.
 
 One consequence for whoever builds the agent application: because a conformance run fails on `not-yet-read`, a
@@ -1089,7 +1092,7 @@ react rather than only display the message:
 | `omni.not-authenticated` | The provider session is no longer usable. The adapter has published `expired` at or before this answer — the state is what Omni surfaces reauthentication from; the code says why this action failed, and is never the only signal. |
 | `omni.capability-not-enabled` | The action targets a capability this task, manifest, or login did not declare — including a lead command from a login whose `capabilities` no longer carry it. |
 | `omni.assignment-not-found` | The assignment named is not one the provider holds, typically after the task already ended. |
-| `omni.phone-not-permitted` | The agent application declared a `phone` the platform does not permit for this agent -- a softphone for an agent configured for a desk phone, or the reverse. The login is refused at authentication, and the provider never reconfigures the agent to make the declaration true. See **How the agent hears the call** in `guide/phone.md`. |
+| `omni.phone-not-permitted` | The agent application declared a `phone` the platform does not permit for this agent -- a softphone for an agent configured for a hardphone, or the reverse. The login is refused at authentication, and the provider never reconfigures the agent to make the declaration true. See **How the agent hears the call** in `guide/phone.md`. |
 | `omni.destination-not-permitted` | The dialled number, or the `destinationId` named, is not one the provider offers this agent. |
 | `omni.rate-limited` | The action was throttled. Pair with `retryAfterMs`. |
 | `omni.unavailable` | The provider is temporarily unable to serve the action, including any command sent while `transport-status` is not `active`. |

package/guide/breaks.md

@@ -140,7 +140,7 @@ which forces the break on the member; `by` names the lead who asked it to. A bre
 imposed on its own -- a schedule, a compliance hold -- says `by: "provider"`, and is the platform's
 to lift: a lead's `end-forced-break` on it is refused before it is sent
 (`team.command.endForcedBreak.provider`), and a provider that receives one answers `failed` with
-`omni.break-forced-by-provider`. The desk offers End forced break on a member only where
+`omni.break-forced-by-provider`. The agent computer offers End forced break on a member only where
 `forced.by` names a lead.
 
 **A lead lifting the restriction does not resume the agent.** On an applied
@@ -250,7 +250,7 @@ against it (`stream.taskOffered.overCapacity`).
 idle dialpad arrives through `task-offered` like any other task, and a full agent does not forbid
 it: the ceiling binds assignment, not the agent's own hand.
 
-**Capacity is not the agent's readiness.** It is the desk's division of one person across
+**Capacity is not the agent's readiness.** It is the agent computer's division of one person across
 providers, a ceiling on assignments at once, and it says nothing about the moment. An agent who
 is about to finish a call and wants the next one lined up has a different thing to say, and says
 it as **The agent's own queue** in `guide/queue.md` sets out; the ceiling stands unchanged while they do,

package/guide/lead.md

@@ -7,7 +7,7 @@ The lead's own surface: the team member list, the lead's commands, lead assist,
 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
+with the authority the flag carries. Nothing the lead does here is a task on their agent computer. 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.
 
@@ -29,11 +29,11 @@ computes nothing. See **`team-updated`** in `guide.md` and its companions.
 | `availability` | Required. What the member is doing now. |
 | `since` | Optional. When the current `availability` began — not when they signed in, and not when the team member list was read. |
 | `break` | Present only while the member has an outstanding break request. See **A member waiting for a break**. |
-| `tasks` | The member's open tasks as `MemberTask`s: the same task the member's desk holds, less the workspace. The assignment, title, task type, phase, party, room, audio and completion terms -- `completionMode`, `wrapAllowance`, `wrapEndsInSeconds` -- are what the lead reads, and the task's record -- `history`, steps and totals -- travels whole, exactly as the member's desk holds it, so the lead's screen and the member's show the same record. The workspace -- `capabilities`, `capabilitySource`, `browsers` and their URLs -- is the member's desk's alone and never travels (`team.member.task.workspace`). The party's number and email are shown to leads or locked as the provider decides for leads, apart from what it decides for the member -- see **What the queue locks is locked on the whole task**. `[]` when the member holds none; omitted only where the provider cannot see them. |
+| `tasks` | The member's open tasks as `MemberTask`s: the same task the member's computer holds, less the workspace. The assignment, title, task type, phase, party, room, audio and completion terms -- `completionMode`, `wrapAllowance`, `wrapEndsInSeconds` -- are what the lead reads, and the task's record -- `history`, steps and totals -- travels whole, exactly as the member's computer holds it, so the lead's screen and the member's show the same record. The workspace -- `capabilities`, `capabilitySource`, `browsers` and their URLs -- is the member's computer's alone and never travels (`team.member.task.workspace`). The party's number and email are shown to leads or locked as the provider decides for leads, apart from what it decides for the member -- see **What the queue locks is locked on the whole task**. `[]` when the member holds none; omitted only where the provider cannot see them. |
 | `listening` | Every lead on this member's call — listening, coaching or joined — published to every lead alike: each entry names the lead by `leadId`, which of the member's calls by `assignmentId`, the `mode` they are heard in, and since when. The entry naming the signed-in lead is what their own audio opens on. Absent while nobody is on the call, never `[]` (`team.member.listening.*`); a lead is on one member's call at a time (`team.listening.single`), and a lead who is heard is also in the task's `onCall` (`team.member.listening.heard`). |
 | `request` | Present while the member is asking a lead to join one of their calls: which assignment, the note they wrote, since when. The call named is one their `tasks` carry (`team.member.request.assignment`). Absent when they are not asking. See **Lead assist**. |
 | `nextCall`, `linedUp` | The member's own queue as their own snapshot carries it: their standing ask for the next call, and the call lined up for them. See **The agent's own queue** in `guide/queue.md`. |
-| `phone` | The member's phone as the platform sees it: the same `PhoneState` the member's own snapshot carries, so a lead sees a desk phone that is down, or a call on it that is no task, as the member does. Present where the provider declares `phoneStatus`. See **The phone's own view** in `guide/phone.md`. |
+| `phone` | The member's phone as the platform sees it: the same `PhoneState` the member's own snapshot carries, so a lead sees a hardphone that is down, or a call on it that is no task, as the member does. Present where the provider declares `phoneStatus`. See **The phone's own view** in `guide/phone.md`. |
 | `shift` | The member's own history for the day, about the person rather than any one call: `signedInAt`, `signedOutAt` once it has happened, today's totals as the provider counts them — `talkSeconds`, `holdSeconds`, `breakSeconds`, `tasksHandled`, each present only when the provider knows it — and the day's sign-in, sign-out and break `events`, oldest first. The same `Shift` the member's own snapshot carries, the same numbers from the same count. Omitted where the provider cannot say. |
 
 Each availability value means one thing:
@@ -54,10 +54,10 @@ member at a time on `team-member-updated`, carrying the member whole: their avai
 tasks, their listening, their shift, their request, as they now stand. Applying the same member
 twice changes nothing, so a redelivery is harmless, and a member the team never carried is added
 by it, as a colleague signing in is. `team-member-removed` takes one off. Never a field of a
-member, never a task of theirs on its own: a hold on a member's desk is that member republished
+member, never a task of theirs on its own: a hold on a member's computer is that member republished
 whole on the lead's, and nothing else on the lead's screen moves.
 
-**Whatever the member's desk hears of a task, every lead hears of the member.** The trigger is
+**Whatever the member's computer hears of a task, every lead hears of the member.** The trigger is
 not a list of changes but the publication itself: each `task-offered`, `task-updated`,
 `task-audio-started`, `task-audio-ended` and `task-ended` the provider sends to the member is
 matched by a `team-member-updated` to every lead with the feature on, carrying the member whole
@@ -68,7 +68,7 @@ part for longer than the delay between them.
 
 **The agent's day is on the wire.** The lead sees `shift` totals as the provider counts them, and
 the agent sees the same: `Snapshot.shift` and `shift-updated` carry the agent's own day in the same
-shape, from the same count, so "calls today: 12" is one number on both screens. The desk computes
+shape, from the same count, so "calls today: 12" is one number on both screens. The agent computer computes
 nothing of the day; `tasksHandled` moves when a task ends and `talkSeconds` when a leg closes, and
 the active call's running time is the screen's own until then, as **Every screen counts from the
 provider's clock** sets out.
@@ -174,7 +174,7 @@ executeTeam({ command: { type: "decline", memberId: "A-1", reason: "In a call" }
 `leadAssist: { stage: "joined", leadId }` and its `onCall` gains the lead as an `agent`, since a
 lead who is heard is in the room; the member on the team member list carries
 `listening: [{ leadId, assignmentId, mode: "join-call", since }]`, and the lead's audio opens on
-it as **Listening to a call** describes. Nothing is a task on the lead's desk: a join is the lead's act on the team surface, not
+it as **Listening to a call** describes. Nothing is a task on the lead's computer: 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
@@ -193,7 +193,7 @@ else changes; the agent is still on the call.
 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 member's task | The lead's desk |
+| | The member's task | The lead's computer |
 | --- | --- | --- |
 | 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`). The member loses this lead's `listening` entry on the team member list no later than the offer, and the lead's listening audio closes. | An ordinary assignment arrives: `task-offered` with `acceptance: "automatic"`, carrying the call's history and `takenOver: { memberId, since }`, within the lead's capacity. |
 | 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. |
@@ -201,7 +201,7 @@ listening unasked -- and one act at the end of either. What follows is the same
 **The taken-over call is offered whatever break the lead is on, and counted like any other.** 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 a call landing on the lead's desk, so it counts against their capacity as
+nothing else). It is a call landing on the lead's computer, so it counts against their capacity as
 every call does, with no exemption: a lead at capacity cannot take over, and the provider answers
 `failed`. The other 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
@@ -229,7 +229,7 @@ Lead and member alike are `UserId`s of this provider, so an adapter publishing t
 ### Listening to a call
 
 A lead may listen to a member's call without being asked -- to coach, to check quality, to step in
-when it goes wrong. It is a team act naming the member, and no task on the lead's desk carries it:
+when it goes wrong. It is a team act naming the member, and no task on the lead's computer 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:
 
@@ -296,7 +296,7 @@ listens through it.
 no trace of the lead: not on `onCall`, not in the record. Whether coaching is announced to the
 agent is the platform's business and travels on the audio, not on this wire. In `join-call`, and
 on a `join` answering a request, the lead is heard by everyone and is in the room: the task's
-`onCall` carries them as an `agent` by user id, on the member's desk and on every lead's copy of
+`onCall` carries them as an `agent` by user id, on the member's computer and on every lead's copy of
 the task alike, and `leave` takes the entry off as it takes the channel off
 (`team.member.listening.heard`).
 

package/guide/phone.md

@@ -1,12 +1,12 @@
 # `@xema/omni-protocol`: The phone
 
-How the agent hears the call: softphone and desk phone, the station and its headset, opening the audio, the microphone and the record. Part of the contract in `guide.md`, which holds the terms, the shapes and the rules every file here relies on; a reference in bold names the file it points into where that is not this one.
+How the agent hears the call: softphone and hardphone, the station and its headset, opening the audio, the microphone and the record. Part of the contract in `guide.md`, which holds the terms, the shapes and the rules every file here relies on; a reference in bold names the file it points into where that is not this one.
 
 ## Real-time audio
 
 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
+`phones`. On a softphone, audio lands in Omni; on a hardphone, it lands on the handset and Omni
 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`).
 
@@ -34,7 +34,7 @@ what failed, and reports. It never decides for the adapter what a missing microp
 **The agent application also guarantees, and a promise the provider cannot see is not one it can rely on.**
 Two of this contract's obligations fall on the agent application rather than the provider — honouring a task
 browser's `urlVisibility`, and taking a `consent` offer only on the person's own press — and more
-than one desk speaks this contract: a browser and a native application differ in what they can
+than one agent computer speaks this contract: a browser and a native application differ in what they can
 reach, and a provider never branches on which it is talking to, only on what it has declared —
 here, and in `host.mute` (see **The station is the agent application's**). So `ConnectContext.host.guarantees` says which promises the
 connected agent application makes, declared once per connection, presence being the guarantee exactly as it is
@@ -44,6 +44,7 @@ the permission everywhere else:
 | --- | --- |
 | `browserUrlVisibility` | Every task browser's `urlVisibility` is honoured in this agent application's chrome, tab by tab. A provider that would send a caller's number in a URL checks this first and tokenises where the promise is absent. |
 | `personConsent` | A `consent` offer is accepted only by the person's own explicit act, never on their behalf. A provider whose work may only be taken by a human checks this first and does not offer it where the promise is absent. |
+| `muteUnavailableOnHold` | The agent application's Mute is its own control on any call and is never offered while the task is `paused`: a mute standing when a hold begins stands through it, and the agent lifts it after resume. Held to the login's phone at connect: required of a softphone login's agent application, whose microphone it is (`host.guarantee.muteUnavailableOnHold.required`), and refused of a hardphone login's, whose mute is the handset's (`.unexpected`). So an agent application that cannot control its mute fails at login, not on a call. |
 
 A guarantee the agent application does not make is an absent key, never `false` — `validateHostGuarantees`
 refuses a false one, as it refuses a name this contract does not list.
@@ -64,7 +65,7 @@ is the one that knows whether an agent without a microphone, or without a speake
 The agent application's own obligations here — asking at connect, never publishing `not-asked` when it does,
 publishing a state and not a flicker — are Omni's tests' to hold. `testAdapter` holds the
 other side: it validates the shape of whatever agent application a test hands the adapter, requires `audio` on
-a softphone login and none elsewhere -- not on a desk phone, not off voice
+a softphone login and none elsewhere -- not on a hardphone, not off voice
 (`context.host.audio.required` / `.unexpected`), holds `host.mute` to the same line (`host.mute.required`
 / `.unexpected`, `host.mute` for a third word) -- and refuses a voice adapter that never asked the
 agent application anything (`connection.host.consulted`), and one that subscribed to nothing will never hear of a
@@ -105,14 +106,14 @@ a return.
 ### How the agent hears the call
 
 A voice platform can put an agent on a **softphone**, where the call's audio lands in the agent application
-and Omni owns the microphone and the playback, or on a **desk phone**, a handset on the platform's
+and Omni owns the microphone and the playback, or on a **hardphone**, a handset on the platform's
 switch that the platform rings, where the agent application owns no audio and only shows the call. Which of
 these a platform can do is a fact about the platform, and which one a login is on is a choice the
 agent application makes for that agent -- so the manifest declares and the agent application chooses.
 
 ```ts
 // Manifest: what the platform can do
-phones: ["softphone", "deskPhone"]
+phones: ["softphone", "hardphone"]
 // The agent application, at authentication and again at connect: which one this login is on
 { phone: "softphone" }
 ```
@@ -122,37 +123,37 @@ A voice manifest lists its `phones` and any other channel lists none (`manifest.
 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 `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 `openAudio`; one that lists `softphone` always does.
+hardphone the agent application reports no audio, opens nothing, and `task-audio-started` still marks the
+moment the call is live so the agent computer shows it, with the sound on the handset. A platform that lists
+`hardphone` 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.
 The provider knows whether that station can carry a call right now -- whether a handset is
 registered -- which an agent application in a browser cannot see. So the agent application's `phone` selects the branch, and
 the provider's own knowledge of the device decides readiness within it. A provider never overrides
-the agent application's declaration from its device record: treating a desk-phone login as a softphone because
+the agent application's declaration from its device record: treating a hardphone login as a softphone because
 the handset is momentarily unregistered, and demanding a microphone of it, is the reading this
 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 `openAudio`.** There is no stream to hand over and
+**On a hardphone 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 `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
+**Which handset a hardphone 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
 asks on surfaces of its own is its own decision.
 
 **A declared phone the platform does not permit for this agent is a login that cannot be
 established.** The manifest says what the platform can do; the agent's record, kept by an
 administrator, says what this agent is configured for, and the two can disagree with the agent application's
-declaration -- a softphone declared for an agent whose record says desk phone. Honouring that
+declaration -- a softphone declared for an agent whose record says hardphone. Honouring that
 declaration on a switch that allows one registration per endpoint would evict the handset: the
 agent's phone stops ringing and their calls land in a tab, and nobody is told. So the provider
 refuses the login at authentication, with `omni.phone-not-permitted` and a message the agent application shows
--- "this agent is configured for a desk phone" -- and refusing is correct, not an override of the
+-- "this agent is configured for a hardphone" -- and refusing is correct, not an override of the
 agent application. It is a refusal, never a negotiation afterwards and never a quiet substitution, and it is
 never retryable: trying again does not reconfigure the agent, and an agent application validating the answer
 (`validateAuthenticationResult`) refuses a phone refusal marked otherwise
@@ -218,7 +219,7 @@ changes, and every softphone agent application can do it. A *station* mute silen
 the operating system: every application on the machine goes quiet, the system shows it, and a
 headset that follows the system follows it. Only a native agent application can do it. `Host.mute` says which
 this agent application does -- `stream` or `station` -- stated on a softphone login, where the agent application holds the
-microphone, and absent on a desk phone and off voice (`host.mute.required` / `.unexpected`). A
+microphone, and absent on a hardphone and off voice (`host.mute.required` / `.unexpected`). A
 browser says `stream`. A native agent application says whichever it does. Nothing on the wire says what kind of
 application the agent application is; a provider reads only what the agent application declared.
 
@@ -232,7 +233,15 @@ mute through the capture track's muted state, read-only, and cannot lift it; a n
 the endpoint and can clear an operating-system mute. A hardware slider is nobody's to clear.
 
 **The record carries the same word.** A `muted` interaction leg is a period the agent could not be
-heard, and the record exists so that period is not a hole. The agent application reports every such period
+heard, and the record exists so that period is not a hole. **The Mute waits for resume.** On a
+softphone the agent application's own Mute is unavailable while the task is `paused`, as it
+promised at login (`muteUnavailableOnHold`): mute then hold is ordinary, and the muted leg runs on
+across the held one; hold then mute is not, and a `muted` leg with `mutedBy: "host"` beginning on a
+paused task is held back by the agent application (`historyReport.muted.held`) and refused by a
+provider that receives one anyway. The test sends one past the validator while the task is held
+and names an adapter that records it (`test.recordStep.held`). A station mute the agent
+application observes on hold -- the headset's slider, the operating system -- is a fact, reported
+with `mutedBy: "station"`, and stands. The agent application reports every such period
 through `recordStep` -- its own Mute, and a station mute it observed during a call -- with
 `mutedBy` saying whose the silence was, and the provider writes the word into the entry
 (`task.history.mutedBy`). The report names no agent because the agent application has exactly one, and
@@ -257,7 +266,7 @@ as by a click. What a call-control headset sends, and what becomes of it:
 | --- | --- | --- | --- |
 | Mute button | The headset, on the HID Telephony usage page: a Phone Mute report on the press, a Mute LED the agent application writes back | A press of the agent application's Mute, performed the agent application's way; the LED follows the agent application's state, so button, light and control are one state with one owner | The `muted` leg, `mutedBy: "host"` |
 | Hook switch | The headset, HID Telephony | A press of the agent application's Answer or End call, only where the task is in a phase that has one; the off-hook and ring lights follow the task | The existing `answer` and `end-call` commands |
-| Flash, redial, speed dial | Older headsets and desk-phone style devices | Flash is Hold and Resume where the task offers `hold`; redial and speed dial map to nothing on a desk that never redials, and are ignored | Nothing new |
+| Flash, redial, speed dial | Older headsets and hardphone style devices | Flash is Hold and Resume where the task offers `hold`; redial and speed dial map to nothing on an agent computer that never redials, and are ignored | Nothing new |
 | Volume up and down | The headset's own amplifier, or the operating system through the consumer-control keys | Nothing: the device and the system handle it | Nothing, except that a speaker at nought is `audio.output.flowing: false` where the agent application can know it |
 | Microphone gain and level | The operating system, the headset's own boost | A level meter, so the agent can see they are heard | Nothing: a level is a flicker, not a state |
 | Hardware or operating-system mute | A slider on the headset, the system's input mute | Observes it, publishes `flowing: false, mutedBy: "station"`, records the leg during a call, and tells the agent which it is where it knows -- headset or system -- and what to do; an agent application whose mute is `station` clears a system mute itself, a browser can only say so | The report and the leg |
@@ -279,7 +288,7 @@ There are two views of a call, and the contract carries both. The task side says
 the agent's work and where each stands: the phase, the audio, the room. The phone side is the
 device: whether it can take a call at all, its own mute, and the calls on it, which exist whether
 or not a task is behind them -- an internal call on the extension, a lead's listening leg, a call
-the platform put on the phone that the desk never saw as a task. The host's report covers neither:
+the platform put on the phone that the agent computer never saw as a task. The host's report covers neither:
 it says what the station has, a microphone and a speaker, and cannot say whether the phone is
 registered. The platform sees the phone, so this is the provider's to publish, as `Snapshot.phone`
 and `phone-updated`, from a manifest that declares `phoneStatus` (`snapshot.phone.required`,
@@ -287,14 +296,14 @@ and `phone-updated`, from a manifest that declares `phoneStatus` (`snapshot.phon
 
 ```ts
 // a conference in progress on alloc-42 -- one channel, since the bridge mixes -- with alloc-43 parked
-const busy: PhoneState = { phone: "deskPhone", status: "ready", muted: true, channels: [
+const busy: PhoneState = { phone: "hardphone", status: "ready", muted: true, channels: [
   { state: "active", since: "2026-09-12T10:30:04Z", assignmentId: "alloc-42" },
   { state: "held", since: "2026-09-12T10:35:20Z", assignmentId: "alloc-43" },
 ] };
-// an internal call on the extension the desk never saw as a task
-const internal: PhoneState = { phone: "deskPhone", status: "ready", channels: [{ state: "active", since: "2026-09-12T11:02:00Z" }] };
-// a desk phone the platform lost
-const down: PhoneState = { phone: "deskPhone", status: "unregistered", since: "2026-09-12T10:41:00Z", channels: [] };
+// an internal call on the extension the agent computer never saw as a task
+const internal: PhoneState = { phone: "hardphone", status: "ready", channels: [{ state: "active", since: "2026-09-12T11:02:00Z" }] };
+// a hardphone the platform lost
+const down: PhoneState = { phone: "hardphone", status: "unregistered", since: "2026-09-12T10:41:00Z", channels: [] };
 ```
 
 **The device.** `status` is the phone itself: `ready` is registered and usable, idle or busy, and
@@ -320,12 +329,12 @@ members are on the task's `onCall`, never repeated here. Each channel is `ringin
 the two views agree** (`phone.channel.task`): `active` with the task at work and its audio
 started, `held` with the task `paused`, `ringing` with the task `pending` or its party ringing on
 `onCall`; and a task with its audio started has a channel (`phone.channel.missing`), since the
-phone carries every call the desk is on. A channel naming no task is the phone's alone, and the
-desk shows it as a call it cannot act on.
+phone carries every call the agent computer is on. A channel naming no task is the phone's alone, and the
+agent computer shows it as a call it cannot act on.
 
 **The mute is the phone's, and it silences whatever is active.** It is one flag on the phone, not
 a property of a channel: whichever channel is active is silent while it is set, and the held
-channels are unaffected. Who owns it follows the phone. On a desk phone the mute button is the
+channels are unaffected. Who owns it follows the phone. On a hardphone the mute button is the
 handset's, and the platform observes it or does not: `muted: true` where it does, absent where it
 does not, never invented. On a softphone the microphone is the host's, its mute is the host's
 report as **The station is the agent application's** sets out, and nothing the provider publishes
@@ -334,6 +343,6 @@ moves it: `muted` on a softphone's state is the platform echoing the host, and i
 never the live flag.
 
 **The lead sees the member's phone as the member does.** The member on the team member list
-carries the same `PhoneState`, republished with the member on every change, so a desk phone that
+carries the same `PhoneState`, republished with the member on every change, so a hardphone that
 is down, or a call on it that is no task, shows the same on both screens, and neither derives it
 from anything else.

package/guide/queue.md

@@ -14,7 +14,7 @@ the lined-up call, and the release.
 // the login declares it, as it declares breaks
 { status: "authenticated", identity: {...}, capabilities: { breaks: true, nextCall: true } }
 
-// 1. The ask. The agent presses Next call during the call or the wrap; the desk offers the button
+// 1. The ask. The agent presses Next call during the call or the wrap; the agent computer offers the button
 //    when it sees fit -- past the midpoint of the handling time is one way.
 await connection.requestNextCall()
 // -> { status: "requested" }: the provider holds the ask; nothing is promised
@@ -41,7 +41,7 @@ await connection.releaseLinedUp()
 **The ask lives only as long as its purpose.** It needs an assignment at work to be next after,
 so an idle agent has nothing to press (`snapshot.nextCall.idle`), and the provider clears it on
 its own when that assignment ends, when a call is lined up to meet it, and when the agent
-withdraws it with `cancelNextCall()`. The desk never keeps it past any of those. `requested` says
+withdraws it with `cancelNextCall()`. The agent computer never keeps it past any of those. `requested` says
 the provider holds the ask, not that a call will come: a queue may be empty.
 
 **The queue lives within capacity, and never beside a break.** The ask and the lined-up call are
@@ -50,13 +50,13 @@ promises to assign, and a promise the provider can no longer keep goes:
 - **Told `count: 0`**, host-stopped, the provider assigns nothing, so it clears the ask and lets the
   lined-up call go back to the queue for anyone; an entry published after that is refused
   (`stream.nextCall.stopped`, `stream.linedUp.stopped`). The queue is per provider, as the ask
-  was made on that provider's call, and the desk's division of capacity is what it was.
+  was made on that provider's call, and the agent computer's division of capacity is what it was.
 - **A break wins.** An agent who has asked for a break, been granted one starting after this
   task, or been put on one has said the opposite of "line up my next call", and the two never
   stand together: while a break is in flight or in effect -- any status but `not-requested` --
   `requestNextCall()` is refused with `omni.unavailable`, and a break arriving after a
   call was lined up drops the call, the caller going back to the queue for anyone
-  (`snapshot.nextCall.break`, `snapshot.linedUp.break`). The desk shows Next call or the break
+  (`snapshot.nextCall.break`, `snapshot.linedUp.break`). The agent computer shows Next call or the break
   controls, never both.
 - **A lined-up call needs an agent at work** as the ask does: a call lined up for an agent with
   nothing at work is an offer that has not been made, and travels as `task-offered`
@@ -65,7 +65,7 @@ promises to assign, and a promise the provider can no longer keep goes:
 **The lined-up call is not a task, and rides no task event.** Until the offer there is no
 assignment and nothing to accept, so it has no phase, no capabilities and no history, and it
 rings nothing: the caller is still in the platform's queue, the phone has no channel for it, and
-the desk shows "next for you" and nothing to act on but the release. It becomes a task by the
+the agent computer shows "next for you" and nothing to act on but the release. It becomes a task by the
 ordinary `task-offered`, with `acceptance: "automatic"` since the agent asked, and counts against
 capacity from that moment as any assignment does; the `queued` step in its history carries the
 caller's whole wait. One at a time: the phone only ever takes the next one, so `linedUp` is an
@@ -79,7 +79,7 @@ the platform's routing: releasing one call, or withdrawing the ask, ends nothing
 and the provider may line a repeat caller up again.
 
 **Letting go is the provider's say.** `release: true` on the lined-up call grants the agent Let
-go; absent, the platform means them to take the call and the desk offers nothing
+go; absent, the platform means them to take the call and the agent computer offers nothing
 (`linedUp.release`). `releaseLinedUp()` against an entry without it is refused with
 `omni.capability-not-enabled`, as any control the provider did not grant. `cancelNextCall()`
 withdraws the ask alone: once a call is lined up the ask is met, and what happens to that call is

package/guide/voice.md

@@ -37,7 +37,7 @@ is work, not a cancellation. A `preview` task therefore needs a manifest that sa
 
 **Preparation and trigger ownership are per task.** Unlimited preparation omits both
 `previewEndsInSeconds` and `atDeadline`: only an agent pressing Call starts dialing. Fixed
-preparation carries the seconds the provider says are left, counted down on the desk from the
+preparation carries the seconds the provider says are left, counted down on the agent computer from the
 publication that carried them and restated on every later one, and exactly one trigger owner:
 
 | Declaration | At preparation end |
@@ -82,7 +82,7 @@ Unsupported source correlation/outcome/audio evidence remains an integration blo
 
 **Drop both fields when the phase moves.** A provider that builds the `in-progress` task by
 spreading the `preview` one carries `previewEndsInSeconds` and `atDeadline` with it, and the agent application refuses
-the update (`task.preview.deadline.unexpected`): the desk keeps the task as it last stood, and the
+the update (`task.preview.deadline.unexpected`): the agent computer keeps the task as it last stood, and the
 provider is told through `refused` exactly which rule, so the state that looked right on its side
 is named on its side. The task past preview has no deadline to wait for, so it carries neither
 field.
@@ -224,7 +224,7 @@ capabilities: {
 
 | Field | Contract |
 | --- | --- |
-| `destinations` | The items the control offers, at least one, with unique `id` values. Each is a button or a menu item on the desk. |
+| `destinations` | The items the control offers, at least one, with unique `id` values. Each is a button or a menu item on the agent computer. |
 | `id` | What Omni sends as `destinationId` on a `conference` command, and what the provider executes. |
 | `label` | What the agent reads. |
 
@@ -260,7 +260,7 @@ provider decides: another IVR, a queue, a survey, or the end of the call. Gated
 
 **Never from hold.** An `end-call` while the task is `paused` would leave the caller in the hold
 with nobody coming back to them, and the provider's path for a caller who continues never begins.
-So the caller is taken off hold first: the desk holds the command back while the task is `paused`
+So the caller is taken off hold first: the agent computer holds the command back while the task is `paused`
 (`command.endCall.held`) and shows End call disabled on hold, and a provider that receives it
 anyway answers `failed`. Resume, then end. `terminate-call` needs no such gate: it ends the
 caller's channel with the rest, held or not, and nobody is left waiting.
@@ -270,7 +270,7 @@ the caller's, any colleague the agent added, and anyone else on the call. Nobody
 line. 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
+Both are commands to the provider through `execute`, and nothing happens on the agent computer 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
@@ -362,7 +362,7 @@ those named here: a statement about the switch, sent instead of the nearest caus
 `reason` is the switch's own words, optional, and shown to the agent attributed to the switch rather
 than to Omni. The two are different things and may travel together: a switch can say "could not
 create dialog" in words and still name no cause a code would carry, so `unexplained` with a
-`reason` is a dial the switch described but did not classify, and a desk renders the words without
+`reason` is a dial the switch described but did not classify, and an agent computer renders the words without
 inventing the class.
 
 **`assignmentId` is the task the dial was placed on**, resolved from the dial's own identity and never from
@@ -378,7 +378,7 @@ idle dialpad call, which has no task yet -- or whose entry has already left the
 outcome for a dial nobody placed and no task mentions is what `stream.dialOutcome.unknown` refuses.
 
 **`answered` says what happened to the dial; `onCall` says who is in the room.** They are two
-claims, and both are true at once when a leg answers and never joins. A desk shows `answered` as the
+claims, and both are true at once when a leg answers and never joins. An agent computer shows `answered` as the
 dial's conclusion and says "on the call" only when the person appears on `Task.onCall`; the obvious
 reading of `answered` -- that they are on the line -- is the one it does not make.
 
@@ -455,7 +455,7 @@ cannot tell ringing from joined says it contains someone who may never arrive. N
 held (`task.onCall.held.ringing`). A colleague who never answers is a dial that ended: the
 provider restates the room without the entry, and the agent is back with the customer.
 
-The desk shows a dial as placed on `dialling`, never as reached; shows the person in the room when
+The agent computer shows a dial as placed on `dialling`, never as reached; shows the person in the room when
 they appear on `onCall`; and shows the outcome, with the switch's reason, against the call it
 belonged to -- with no retry, since a wrong number is not worth redialling and the decision is the
 agent's.