Keep operation bookkeeping, workload aggregation and payload construction in

existing snapshots and results, rather than repeating enumeration or database work.

| `firstSessionDiscoveryResult` | Node performance time origin until the first provider discovery pass finishes processing its result and synchronously emitting its candidate batches. Also records a processed zero-candidate result when no event is emitted. Does not wait for host registration or imply exhaustive/error-free enumeration. |

| `sessionDiscoveryRegistration` | One received discovery batch's host registration processing: registry snapshots, host filtering, accepted registry writes, catalog synchronization, and existing post-processing. Starts when the batch reaches registration, after its queue wait and any forced migration. Ends after scheduling, **not awaiting**, external-session publication reconciliation. |

| `firstSessionDiscoveryRegistration` | Node performance time origin until the first discovery registration batch completes without an observed registration/post-processing failure or pending catalog synchronization. Includes that batch's counts, independently of operation sampling. Not completion of all batches or all providers. |

The six `session*` operations also emit corresponding `*Start` markers.

The two `firstSessionDiscovery*` milestones are also cumulative, once per

provider, and have no `outcome` field. A provider result can contain only a

subset of its catalog (for example, a truncated Codex scan or Copilot

classification failures). A successful registration is about the received

batch, not the completeness of its source scan. Neither milestone means that

an external row has been published to clients or rendered.

Provider processing and host registration can overlap: Copilot emits multiple

batches during one pass, so the first registration can finish before

`firstSessionDiscoveryResult`. Conversely, a provider can finish emitting all

batches before registration starts. Codex can share an enumeration with

migration, so a discovery result need not have a `sessionDiscoveryScan` marker.

Do not pair scans and registration batches by attempt, proximity, or the latest

successful scan. Only pair each operation with its own `*Start` within the same

host, provider, and attempt.

The result milestone observes the first normally completed processing pass,

including zero candidates after filtering or deduplication. Copilot and Codex

do not emit empty candidate events; their result milestone can therefore exist

without a registration operation. Claude's existing empty event still takes

the existing host path. A deferred/unavailable provider, thrown processing

failure, or shutdown-abandoned result does not record this milestone. Later

readiness/discovery can record it, even after scan sampling stops. Provider

restarts do not reset either first-discovery milestone within the host lifetime.

| `firstSessionDiscoveryResult` | After result processing and candidate emission in [Copilot](node/copilot/copilotAgent.ts), [Claude](node/claude/claudeAgent.ts) and [Codex](node/codex/codexAgent.ts), including normally completed empty results. |

| `sessionDiscoveryRegistrationStart`, `sessionDiscoveryRegistration`, `firstSessionDiscoveryRegistration` | In `_registerDiscoveredChatsWithStartupTelemetry`, wrapping registration after the existing queued migration in [the agent service](node/agentService.ts). |

`firstSessionDiscoveryResult` records `candidateSessionCount` and

`externalSessionCount`: candidates actually emitted by that processing pass,

and the subset the provider classified as external. Copilot aggregates all

of its emitted batches after deduplication. Claude counts its unknown chats;

Codex counts new/changed chats, which can include known internal chats.

These are not catalog totals or host registrations.

Copilot also records `filteredSessionCount` (enumerated entries deliberately

not emitted, including known, suppressed, stale and duplicate entries) and

`failedSessionCount` (entries skipped after a caught classification failure).

Claude records its known-chat filtering count. Codex omits filtering counts

because native-subagent filtering happens inside the shared listing path;

Claude and Codex omit failure counts rather than claiming their lower-level

metadata recovery paths were error-free. Missing counts are unknown, not zero.

A zero-candidate result only describes the observed result, not an empty

provider-wide catalog. In particular, retain Copilot's failed count and Codex's

separately observed scan truncation when interpreting coverage.

`sessionDiscoveryRegistration` and `firstSessionDiscoveryRegistration` use

counts from **one received batch**, not accumulated provider totals:

- `candidateSessionCount`: entries in that event.

- `externalSessionCount`: entries the provider marked external, before host

provenance corrections and visibility filtering.

- `registeredSessionCount`: accepted registry writes, even if later processing

of that entry fails. This does not count published/visible rows.

- `filteredSessionCount`: entries deliberately skipped without a new

registration (already registered, subagent/backing, stale, or tombstoned).

- `failedSessionCount`: entries whose processing threw into the registration

loop's existing per-candidate error handler.

- `incompleteSessionCount`: entries whose catalog synchronization returned

`pending`.

Counts need not partition the batch: an accepted write can precede a failure

or pending synchronization. Batch-level errors do not invent per-candidate

failures, and cancellation only retains progress actually collected.

An observed per-entry failure, pending synchronization, or caught

post-processing write failure yields `partial`, not `success`, even though

product error handling still logs and continues. An escaping batch error

yields `error`; cancellation or a no-longer-current provider yields `cancelled`.

Recovered failures internal to metadata helpers are not an exhaustive error

count. Publication reconciliation can later fail independently of a successful

registration observation.

For first registration latency, use

`firstSessionDiscoveryRegistration.durationMs`, grouped by provider. It includes

the time before that batch, unlike the sampled registration operation duration.

Keep result-only, partial, missing and late observations separate; do not

manufacture an all-providers-complete timestamp or label either boundary

"visible". The first successful batch may itself be empty or entirely filtered.

Additional counting uses only already-loaded registry snapshots and discovery

candidate arrays, for an observed operation or a pending first milestone.

`isPending` checks the same normalized milestone keys without reading a clock;

combine it with `isEnabled` before telemetry-only aggregation. Disabled

completions still consume their milestones without payload aggregation, so they

are not replayed after opt-in. Later listings/scans/registrations do not allocate

timing handles or read the clock once their observations and first milestones

are complete.

`firstSessionList`, `startupSettled`, and `firstSessionDiscoveryRegistration`

still report a later first success. `firstSessionDiscoveryResult` similarly

does not depend on a sampled scan handle.

their existing enumeration and processed-result boundaries; the orchestrator

reports at its existing listing, migration and discovery registration boundaries.

Startup telemetry does not use chat lifecycle