@xema/omni-protocol 0.1.116 → 0.1.118

package/guide/voice.md

@@ -262,7 +262,7 @@ provider decides: another IVR, a queue, a survey, or the end of the call. Gated
 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 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
+anyway answers `failed` with `omni.on-hold`, so the agent application can say resume first. 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.
 
 **`terminate-call` ends the whole call.** Every channel on it ends at the provider: the agent's,
@@ -463,114 +463,120 @@ agent's.
 ## Independent task recording
 
 Recording is voice-only. A task can arrive already recording, including while pending, and offer
-no recording controls. The provider publishes only its own current state on
-the provider field of the task’s `recording` state. The agent application publishes its own full scoped view in `HostReport.recordings`.
-A provider task update cannot replace agent application state. Neither a capability nor an accepted command
-establishes recording. Missing state, lost recorder observation, transport loss and expired
-observation mean unknown; they never mean stopped. Paused means a recording remains open without
-capturing. Task hold, task pause and recording pause are independent.
-
-The per-task policy is `Task.capabilities.recording`, with independently optional provider and agent application
-action sets. The outer capability may be locked. Absence grants no permission, and a state may
-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 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, audio mixing, storage or upload.
-
-| Action | Required current recording state | Confirmed outcome |
-| --- | --- | --- |
-| start | inactive | active with a new recording identity |
-| pause | active | paused, preserving recording identity and captured audio |
-| resume | paused | active with the same recording identity |
-| stop | active or paused | inactive; finish and retain captured audio |
-| cancel | active or paused | inactive; abandon and discard captured audio |
-
-Stop finishes the recording and retains captured audio. Cancel abandons the recording and discards
-its captured audio; the task policy offers it with `cancel: true`. There is no configurable cancel
-effect. A recorder that cannot confirm completion must not offer Cancel; it can offer Stop instead.
-Cancel never means cancelling an in-flight start request or deleting arbitrary past recordings.
-Stop can be applied only after finalization/retention succeeds; Cancel only after both cessation
-and completion of this recording's audio succeed under the recorder's storage contract.
-Partial success -- capture stopped but the storage outcome unknown, a start the recorder cannot
-vouch for either way -- is a settled `failed`, under the code `omni.recording-unsettled`: the
-command did not do what it promised, and the state the provider publishes with it is whatever
-capture state is actually known. It is never `applied`, and never an unsettled promise the agent
-application would be left to resync, since the provider knows exactly what it could not settle.
-There is no request identity on a recording command: the outcome is the state, and what the
-agent sees is the state. Retention is not a promise of sample-perfect audio.
-
-Provider commands go exclusively to `Connection.execute`; agent application commands go exclusively to
-`HostRecording.execute`. Both include the assignment and observation identities; all
-non-start commands identify the particular recording. IDs are opaque and scoped by provider login,
-task and recorder owner. They are never inferred from filenames or current agent identity. A
-recording ID survives pause/resume and reassignment only where the same recorder confirms continuity;
-commands always name the current assignment. A later start gets a different ID. Reconnect does not
-create a new recording or fresh evidence. After lost continuity, use unknown until reconciled.
-There is no automatic restart, hand-over to another recorder, or stop on task hold/disconnect.
-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 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.
-
-Each confirmed observation has a fresh opaque observation identity, a canonical UTC millisecond
-observation instant and an exclusive expiry. These times describe current evidence, never historical
-capture boundaries. A trusted observer-domain current time must satisfy observedAt <= now < validUntil.
-Use `effectiveRecordingState` with that explicitly trusted time; an unavailable clock yields unknown.
-Receipt, replay and task publication never extend freshness. Clock discontinuity invalidates evidence;
-consumers using the explicit recording-expiry clock-estimation exception must invalidate that
-estimate and use monotonic aging so clock rollback cannot
-revive expired evidence. The executor compares observation identity and recording identity against
-its latest state atomically before I/O. An intervening observation or assignment change refuses the
-stale command; it never acts on a replacement recorder. Providers lacking trustworthy current-state
-identity or observation time publish unknown and offer no issuable controls.
-
-Use `validateTask` and `validateTaskCommand` for published shape and static permissions.
-Immediately before dispatch, additionally use `validateRecordingRequest` against the full current
-task and explicit observer-domain time. For agent application commands also supply the current agent application declaration,
-full agent application report and softphone context. The same checks must run at the executing boundary;
-client validation alone is not authorization. The executor serializes operations on each recorder
-and compares `observationId` and `recordingId` against its latest evidence before acting: a
-command against superseded evidence is refused, and nothing is retried on the executor's own
-account.
-
-Keep command progress in agent application UI separately from authoritative state. Applied means the requested
-recording transition and any retain/discard effect actually completed; publish the confirming task or agent application report before
-resolving applied. Failed means confirmed no effect. Rejected promise means outcome unknown:
-show the failure, reconcile that path and do not automatically retry or pretend inactive. Authoritative
-updates remain full current task/agent application views, not replayed provider events. These current-state fields
-create no interaction-history entries and infer no actors, durations or historical capture boundaries.
-
-Migration is explicit: replace the old true recording capability with per-path action policies,
-replace untargeted commands with scoped commands, and retain protocol version 1. During pre-release
-development, hosts and adapters must align their recording contracts; negotiation does not detect
-differences between package revisions that share that protocol number. No legacy-shape fallback is provided.
-This change does not publish a package or enable recording in any existing agent application/provider by itself.
-
-`validateRecordingOutcome` checks confirming observations against recording-specific applied/failed
-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.
-
-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 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.
-
-
-Recording dispatch must receive the same known task-validation context as the published task.
-Pass organisation levels and other known restrictions through the optional fourth argument of
-`validateTaskCommand`, and through `taskContext` in `validateRecordingRequest`. This keeps a valid
-custom organisation lock from being rejected against the default ladder, and prevents known
-capability restrictions from disappearing at dispatch. The standalone `validateRecordingCommandState`
-requires an affirmative permission; false, malformed permission declarations and unknown actions grant nothing.
+no recording controls. **Each recorder publishes its own recordings, as a list, whenever one
+changes.** The provider's are the task's `recordings`, restated whole on every publication of the task
+and on every snapshot. The agent application's are on its `HostReport.recordings`, one entry per
+assignment, never on a provider's task. A provider task update cannot replace the agent
+application's recordings, and a command to one recorder has no effect on the other.
+
+```json
+"recordings": [
+  { "id": "rec-7", "follows": "party", "status": "recording" },
+  { "id": "rec-8", "follows": "agent", "status": "paused", "reason": "sensitive-details" },
+  { "id": "rec-3", "follows": "party", "status": "not-recording" }
+]
+```
 
+**A recording follows one side of the call.** `follows` says whose channel it captures: the
+`party`'s, or the `agent`'s own. The two are separate captures on most platforms, and the agent
+computer needs to know which: a recording that follows the party keeps capturing hold music
+while the agent talks to a colleague, and only one that follows the agent says whether the
+agent's own voice is on it. Each side has at most one recording that is, or may be, capturing at
+once -- `starting`, `recording`, `paused` or `unknown` (`recording.follows.live`) -- and any number
+that have finished.
+
+**Nothing expires.** A recording stands as its recorder last stated it until the recorder says
+otherwise. There is no observation time, no validity window and no clock to compare: everything
+the agent computer shows comes from the wire, and a recording mark that went dark when a recorder
+check ran late, then came back, was a fault reported from the floor. The recorder publishes on
+change and restates the whole list on connect and resume.
+
+| Status | Meaning |
+| --- | --- |
+| `starting` | Asked for and not yet confirmed by the recorder. |
+| `recording` | Capturing. A pause or a stop still in flight stays `recording` until the recorder confirms it: telling the agent they are not recorded when they may be is the one thing this must never say. |
+| `paused` | Open but not capturing, with a `reason`: `requested`, someone asked for it, or `sensitive-details`, the platform paused it while card or account details are taken. |
+| `not-recording` | Finished, or never started on that side; captured audio is kept or discarded as its stop or cancel said. |
+| `unknown` | The recorder cannot say, with a `reason`: `recorder-unreachable`, or `unsettled`, a command whose effect it could not establish either way. Never shown as stopped. |
+
+A mark that is not lit says why: `paused` and `unknown` carry a reason from those closed lists, and
+nothing else carries one (`recording.reason`, `.reason.unexpected`). Task hold, task pause and
+recording pause are independent.
+
+**Permission is per task.** The policy is `Task.capabilities.recording`, with independently
+optional provider and agent application action sets. The outer capability may be locked. Absence
+grants no permission, and a recording may 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
+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, audio mixing, storage
+or upload.
+
+**A command names what it acts on.** A start names the side, `follows`; every other action names
+the recording by its `recordingId`. The recorder mints the id when it accepts the start, before
+the recorder has answered, publishes the recording `starting` under it, and keeps it through pause
+and resume; a later start is a new recording with a new id. The recorder serializes the operations
+on each recording and refuses an action the recording no longer stands for: a pause on a recording
+that is not `recording`, a stop on one already `not-recording`, a start on a side already
+capturing, a recording the task does not carry (`recording.command.state`,
+`.command.recordingId`). Nothing is retried on the recorder's own account.
+
+| Action | The recording before | Confirmed outcome |
+| --- | --- | --- |
+| start | none live on that side | a new recording on that side, `recording` |
+| pause | `recording` | the same recording, `paused`, captured audio kept |
+| resume | `paused` | the same recording, `recording` |
+| stop | `recording` or `paused` | the same recording, `not-recording`; captured audio finished and kept |
+| cancel | `recording` or `paused` | the same recording, `not-recording`; captured audio discarded |
+
+Stop finishes the recording and retains captured audio. Cancel abandons it and discards captured
+audio; the task policy offers it with `cancel: true`, and there is no configurable cancel effect.
+A recorder that cannot confirm completion must not offer Cancel; it can offer Stop instead. Cancel
+never means cancelling an in-flight start or deleting past recordings. Stop is applied only after
+finalization and retention succeed; Cancel only after both cessation and discarding succeed.
+**Applied means confirmed**: the recorder publishes the confirming list before it answers
+`applied`. Failed means confirmed no effect. Partial success -- capture stopped but the storage
+outcome unknown, a start the recorder cannot vouch for either way -- is a settled `failed` under
+`omni.recording-unsettled`, and the recording is published `unknown` with the reason `unsettled`.
+A rejected promise means the outcome is unknown: show the failure, reconcile, and do not retry or
+pretend `not-recording`. There is no request identity on a recording command: the outcome is the
+recording, and what the agent sees is the recording. Retention is not a promise of sample-perfect
+audio.
+
+Provider commands go only to `Connection.execute`; agent application commands go only to
+`HostRecording.execute`. Both name the assignment. Ids are opaque and scoped by provider login,
+task and recorder; they are never inferred from filenames or the current agent. Reconnect creates
+no recording; the recorder restates its list. There is no automatic restart, hand-over to another
+recorder, or stop on task hold or disconnect. Task removal does not prove recording stopped:
+outstanding agent application recordings stay tracked by the agent application until its recorder
+finishes them, with unresolved cleanup failures visible.
+
+Only start and resume need an `in-progress` or `paused` task with started audio. Pause, stop and
+cancel may also finish a recording while the task is `completing`. A pending task may show a
+recording, but agent controls wait until interaction begins.
+
+Use `validateTask` and `validateTaskCommand` for the published shape and static permissions.
+Immediately before dispatch, also use `validateRecordingRequest` against the full current task;
+for agent application commands supply the current declaration, full report and softphone context.
+The same checks run at the recorder; client validation alone is not authorization.
+`validateRecordings` checks one recorder's list, and `validateRecordingOutcome` checks an answer
+against the lists published before and after it: an applied start shows a new recording on its side,
+anything else the same recording in its new status, and a failed one nothing changed there. It
+cannot prove retention or source truth from a status; those remain the recorder's obligations. The
+storage place named on the task is bound when start creates a recording, and later policy cannot
+redirect it.
+
+Recording dispatch receives the same known task-validation context as the published task: pass
+organisation levels and other known restrictions through the optional fourth argument of
+`validateTaskCommand`, and through `taskContext` in `validateRecordingRequest`, so a valid custom
+organisation lock is not rejected against the default ladder. Migration is explicit: the former
+`recording` state with its observation and validity window is refused on a task
+(`recording.task.renamed`), and a command carries no observation id. Protocol version 1 stays;
+there is no legacy-shape fallback.
 
 ### Agent application recording announcements to the caller
 
@@ -590,7 +596,7 @@ cancel, they hear that recording stopped. If pause/resume is supported, say paus
 pause is not presented as a finished recording. Announcements follow actual capture transitions,
 not button clicks, accepted requests or task-policy changes. When attaching to an already-active
 agent application recording, announce that recording is active, without inventing its original start time.
-Repeated observations of the same state do not repeat announcements. Unknown or expired evidence
+Restating the same status does not repeat an announcement. A recording that is `unknown`
 must never produce a stopped announcement.
 
 A local sound, UI indicator, screen-reader message to the agent, or sound leaking through the

package/guide.md

@@ -70,7 +70,7 @@ state use `status`; name the object when discussing them to avoid ambiguity.
 | `phase` | A task | `pending`, `confirmed`, `preview`, `in-progress`, `paused`, `completing` |
 | `audio` | A task's audio | `started`, `ended` |
 | `transport` | A connection | `connecting`, `active`, `error` |
-| `status` | An authentication session | `signed-out`, `authenticating`, `authenticated`, `refreshing`, `expired` |
+| `status` | An authentication session | `signed-out`, `authenticating`, `authenticated`, `refreshing`, `expired`, `terminated` |
 | `status` | The agent’s break lifecycle | `not-requested`, `awaiting-approval`, `granted`, `starting-after-task`, `on-break` |
 | `availability` | A team member | `ready`, `on-task`, `on-break`, `elsewhere`, `signed-out` |
 
@@ -83,7 +83,7 @@ user IDs, returned user details and directory requirements are unchanged.
 
 ### `OMNI_PROTOCOL_VERSION`
 
-The exact protocol version implemented by this package. The current value remains `1` during pre-release development. Recording contract changes do not introduce a new protocol version. Hosts and adapters adopt the current declarations together; this does not provide compatibility mapping for older recording shapes.
+The exact protocol version implemented by this package. The current value remains `1` during pre-release development. Recording contract changes do not introduce a new protocol version. Hosts and adapters adopt the current declarations together; there is no compatibility mapping for older recording shapes.
 
 ### `Manifest.supportedProtocolVersions`
 
@@ -301,7 +301,8 @@ type AuthenticationState =
   | { status: "authenticating" }
   | { status: "authenticated"; identity: User; capabilities: UserCapabilities; expiresAt?: IsoTimestamp }
   | { status: "refreshing"; identity: User; capabilities: UserCapabilities }
-  | { status: "expired"; identity?: User; failure?: AuthenticationFailure };
+  | { status: "expired"; identity?: User; failure?: AuthenticationFailure }
+  | { status: "terminated"; by: UserId | "provider"; identity?: User; failure: AuthenticationFailure & { retryable: false } };
 
 type AuthenticationFailure = {
   code: string;
@@ -342,23 +343,22 @@ interface TaskRecordingPolicy {
   provider?: RecordingActions;
   host?: RecordingActions & { storageId: string };
 }
-type RecordingState =
-  | { status: "unknown"; observationId?: never; observedAt?: never; validUntil?: never; recordingId?: never }
-  | ({ observationId: string; observedAt: IsoTimestamp; validUntil: IsoTimestamp } & (
-      | { status: "inactive"; recordingId?: never }
-      | { status: "active" | "paused"; recordingId: string }
-    ));
-type RecordingCommand = {
-  type: "recording";
-  source: RecordingSource;
-  observationId: string;
-} & (
-  | { action: "start"; recordingId?: never }
-  | { action: "pause" | "resume" | "stop" | "cancel"; recordingId: string }
+type RecordingSide = "party" | "agent";
+type RecordingStatus = "starting" | "recording" | "paused" | "not-recording" | "unknown";
+type RecordingPausedReason = "requested" | "sensitive-details";
+type RecordingUnknownReason = "recorder-unreachable" | "unsettled";
+type Recording = { id: string; follows: RecordingSide } & (
+  | { status: "starting" | "recording" | "not-recording"; reason?: never }
+  | { status: "paused"; reason: RecordingPausedReason }
+  | { status: "unknown"; reason: RecordingUnknownReason }
+);
+type RecordingCommand = { type: "recording"; source: RecordingSource } & (
+  | { action: "start"; follows: RecordingSide; recordingId?: never }
+  | { action: "pause" | "resume" | "stop" | "cancel"; recordingId: string; follows?: never }
 );
 interface HostRecordingReport {
   assignmentId: AssignmentId;
-  state: RecordingState;
+  recordings: Recording[];
 }
 interface HostRecording {
   announcesToCaller?: true;
@@ -693,7 +693,8 @@ type HistoryStep =
   | "muted"
   | "transferred"
   | "conferenced"
-  | "unanswered";
+  | "unanswered"
+  | "callback-requested";
 
 type TaskHistory = {
   steps: TaskHistoryStep[];
@@ -776,8 +777,8 @@ type Task<C extends Channel = Channel> = {
   history?: TaskHistory;
 } & TaskCompletion & (
   C extends "voice"
-    ? { recording?: { provider?: RecordingState }; onCall?: OnCall[]; leadAssist?: TaskLeadAssist; takenOver?: TaskTakenOver; audio?: TaskAudioState }
-    : { recording?: never; onCall?: never; leadAssist?: never; takenOver?: never; audio?: never }
+    ? { recordings?: Recording[]; onCall?: OnCall[]; leadAssist?: TaskLeadAssist; takenOver?: TaskTakenOver; audio?: TaskAudioState }
+    : { recordings?: never; onCall?: never; leadAssist?: never; takenOver?: never; audio?: never }
 );
 
 type PreviewDeadline = "provider-dials" | "host-dials" | "waits";
@@ -1344,6 +1345,7 @@ const OMNI_FAILURE_CODES = [
   "omni.unavailable",
   "omni.break-already-committed",
   "omni.recording-unsettled",
+  "omni.on-hold",
   "omni.break-forced-by-provider",
 ] as const;
 type OmniFailureCode = (typeof OMNI_FAILURE_CODES)[number];
@@ -1991,11 +1993,12 @@ reports later changes.
 
 | Status | Contract |
 | --- | --- |
-| `signed-out` | No usable provider session exists. |
+| `signed-out` | No usable provider session exists, because the agent signed out on this agent computer, or never signed in. Only the agent's own Sign out here leads to it. |
 | `authenticating` | An interactive `browser-sso` or `credentials` flow is active. |
 | `authenticated` | A usable session exists. Includes the provider identity, the login's `capabilities`, and optional token expiry time. |
 | `refreshing` | The adapter is refreshing its session. Existing provider identity and capabilities remain available, unchanged: a change to either is published as `authenticated`. |
-| `expired` | The session cannot currently be used. It may include an identity and typed failure. |
+| `expired` | The session's time ran out, or its refresh is failing. It may include an identity and typed failure. The agent signs in again on the same login, and the workspace stays. |
+| `terminated` | The session was ended from outside this agent computer: by a supervisor, by the agent on another screen, or by the platform itself. `by` says who, a person by `UserId` or `provider` where no person was behind it (`authentication.terminated.by`), and `failure` says why and is never retryable (`authentication.terminated.failure`, `.retryable`). It is never reported as `expired`, which would hide who ended it, nor as `signed-out`, which is the agent's own act. |
 
 Omni calls `connect()` only after authentication reaches `authenticated`. Token refresh remains
 adapter-owned; the adapter publishes `refreshing`, followed by `authenticated` or `expired`.
@@ -2137,16 +2140,50 @@ authorization codes, tokens, or provider responses containing secrets.
 
 ### Sign-out
 
-`signOut()` revokes or invalidates the provider session where supported, deletes stored
-session secrets, and moves state to `signed-out`.
-`close()` stops authentication-state observation but does not sign the agent out.
+`signOut()` is the agent's own Sign out on this agent computer. It tells the provider where
+supported, revoking or invalidating the session, then **deletes the stored session secrets
+whatever happened**, and moves state to `signed-out`. Telling the provider may be retried within a
+short bound the adapter states, and then given up: a provider that cannot be reached never keeps a
+token on the agent's machine. If it was not told, `signOut()` still deletes and still reaches
+`signed-out`, and answers `failed`, so the agent application can show that a session may remain at
+the provider. `close()` stops authentication-state observation but does not sign the agent out.
+
+**The final moments are the agent application's to finish.** Its own steps before signing out --
+stopping capacity, putting tasks down -- may be retried within a short bound it states, and then
+given up; a step that failed never skips `signOut()`. A desk that skipped the adapter's sign-out
+because its own retirement failed left the token behind, and the next reload restored the session.
+
+### How a session's secrets end
+
+A token that can no longer start a session does not outlive it. The adapter deletes the stored
+secrets **before** it publishes the ending, so that nothing is left for a reload to restore:
+
+| Ending | Secrets | The provider |
+| --- | --- | --- |
+| `signed-out` | Deleted, whether or not the provider was told. | Told where supported, as above. |
+| `terminated` | Deleted. | Never told: the session is already over, and a sign-out sent now could end the agent's newer session somewhere else. |
+| `expired` with a failure that says `retryable: true` | Kept, for the retry: a network outage does not sign out a floor. | Retried by the adapter. |
+| `expired` otherwise | Deleted: the provider refused the token, or its time ran out. | Not told. |
+
+**The agent application makes sure after the adapter.** Once a session is `signed-out`,
+`terminated`, or `expired` with anything but a retryable failure, the agent application clears that
+provider's partition of the store, and a sign-in after it always starts a fresh flow and never
+resumes a stored token. The adapter deletes; the agent application makes sure. `testAdapter` holds
+the adapter's half: when a published state ends the session, the store it handed the adapter must
+already be empty (`authentication.secrets.retained`).
 
 ### Secure-storage boundary
 
-Omni provides an OS-backed `SecretStore` scoped to the provider manifest ID. It exposes only
-`get`, `set`, and `delete`; adapters cannot enumerate another provider's secrets. Adapters may store
-refresh tokens or equivalent session material, but never raw submitted credentials. Secrets must
-not appear in manifests, logs, events, snapshots, task attributes, errors, or browser storage.
+The agent application provides the `SecretStore`, scoped to the provider manifest ID. It exposes
+only `get`, `set`, and `delete`; adapters cannot enumerate another provider's secrets. **What backs
+it is the agent application's, and depends on what it is**: a native agent application uses the
+operating system's keychain; a browser agent application has none, and keeps the store in the
+tab's session storage, which survives a reload and ends with the tab. A browser store is readable
+by any script running on its page, so a browser agent application is only as safe as its own page.
+
+Adapters may store refresh tokens or equivalent session material, but never raw submitted
+credentials, and they put a secret nowhere but the `SecretStore`: never in manifests, logs,
+events, snapshots, task attributes, errors, the login's `store`, or browser storage of their own.
 
 ## Connecting to a provider
 
@@ -2379,8 +2416,6 @@ The current exceptions and their reasons are:
 | --- | --- |
 | Agent application display of provider deadlines (`expiresInSeconds`, `previewEndsInSeconds`, `wrapEndsInSeconds`) | Each is seconds from the publication that carried it, counted down on the agent computer from receipt: the provider's own arithmetic, so no clock is compared and the transport delay is the only error. The countdown estimates the display only; it does not establish that the provider acted. Without usable time, show timing uncertainty. |
 | Agent application-triggered preview end | The agent computer counts `previewEndsInSeconds` down from receipt and issues `dial` when it reaches zero: the provider owns the deadline and the agent computer owns the trigger. It does not dial before the countdown has run out, and a reload restarts it from the next publication. |
-| Recording evidence expiry | A bounded observer-domain clock estimate with monotonic aging may assess freshness because observation and expiry belong to the recorder's clock. If time cannot be trusted, recording state is unknown; never renew evidence from receipt or replay. |
-| Unknown recording state | `observedAt` and `validUntil` are absent because there is no confirmed observation. The containing provider event still has its own `occurredAt`; that publication is not a recorder observation. |
 | Direct snapshot reads and method requests/results | These are reads/operations, not event envelopes, and their current types have no general event timestamp. A snapshot event still carries `occurredAt`; embedded source instants remain unchanged. Do not treat a method result or read completion time as an occurrence boundary. |
 | Agent application-provided provider-clock estimate | Best-effort ISO time may be supplied by the agent application for optional comparisons; it is not a source observation or accuracy guarantee. The reason is that the agent application does not own the provider clock. |
 | Provider receipt timestamps | The provider may use its own receipt instant for final records of receipt/processing because agent application timestamps are untrusted advisory input. Receipt must not be presented as an earlier action or capture boundary. |
@@ -2488,14 +2523,13 @@ A provider need not trust or adopt any agent application-supplied timestamp. It
 message using its own clock at receipt and use that for its own processing/accounting. The reason
 for this exception is that agent application clocks and agent application estimates are not authoritative at the provider.
 Receipt time must be described as receipt/observation time, not relabeled as the original agent application
-action, recorder capture boundary, or proof an operation applied. An existing field with a
+action, a recording's start or stop, or proof an operation applied. An existing field with a
 specific occurrence meaning still requires that evidence; this option does not silently redefine
 it. Agent application-only instants remain advisory input; the provider owns its authoritative publication.
 
 This agent application estimate is another explicit timestamp exception: it helps optional displays and
 provider-clock comparisons when the agent application lacks that clock directly. It is not a source occurrence,
-may not replace event/history timestamps, and alone cannot authorize deadline actions or prove
-recording freshness. Uses requiring a trustworthy bound still need independently established
+may not replace event/history timestamps, and alone cannot authorize deadline actions. Uses requiring a trustworthy bound still need independently established
 clock accuracy/drift assumptions. It neither synchronizes the operating-system clock nor changes
 ISO timestamps already published by the provider.
 
@@ -2677,7 +2711,9 @@ snapshots until it ends.
 with `task-ended` and an outcome, whatever became of the call: answered and completed, declined,
 withdrawn, abandoned in the ring, lapsed, taken over. An offer that is simply never mentioned
 again leaves the agent computer holding a task nobody will close, and the test names it
-(`stream.taskOffered.unended`).
+(`stream.taskOffered.unended`). **Every dial is owed its outcome** the same way: a dial the test
+placed and the provider answered `dialling` with no `dial-outcome` by the end of the run is named
+(`stream.dialOutcome.missing`).
 
 ### `task-updated`
 
@@ -3108,6 +3144,7 @@ cannot be established from TypeScript structure alone.
 | `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. |
 | `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. |
+| `assertHistoryAgreesAcrossTasks(earlier, later)` | Two tasks of one call -- a hand-over, a take-over, a callback: the later restates every earlier step in order, with the same step, instant, person, dial and destination, and any duration already stated unchanged. Throws when either carries no history. |
 | `assertBreakAttemptProviders(candidates, asked)` | A break attempt asks every usable provider holding capacity, `refreshing` included, and nothing of a provider whose login is `expired`. |
 | `assertForcedBreakStopsTheRest(forcedOn, candidates, stopped)` | A forced break on one provider stops the agent everywhere else: capacity zero stated on every other usable provider holding capacity, nothing on the forcing one, nothing on a dead login. See **Forced breaks** in `guide/breaks.md`. |
 | `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. |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xema/omni-protocol",
-  "version": "0.1.116",
+  "version": "0.1.118",
   "description": "The Omni protocol: the contract every provider adapter implements",
   "type": "module",
   "license": "MIT",