ui-react: design safe production evidence capture for unavailable Send

Read ROADMAP.md, docs/decisions/provider-history.md, and docs/decisions/agent-observability.md first, then inspect the cited canSend logic in packages/ui-react/src/components/chat/composer.tsx, useSessionProfile in packages/ui-react/src/hooks/use-session-profile.ts, and DiagnosticReview in packages/ui-react/src/components/report/diagnostic-review.tsx. Compare bounded capture options against the stated privacy, overhead, retrieval, and failure constraints; deliver a documented recommendation with alternatives, verification plan, and smallest implementation brief, without implementing or enabling collection.

Out of scope

No production instrumentation deployment, production fault injection, automatic telemetry upload, new monitoring service/provider seam, general performance profiler or speculative Send/admission fix. Do not change authentication, draft/profile readiness, recovery, send/queue/retry behavior, deadlines or provider-facing history. This issue produces a design, not a claim that the test failure occurs in production or that starvation is proven.

Context

#2202 retains an intermittent actual-Send readiness timeout observed in a local full preflight: the draft remains and the first question never sends. Later isolated and ordered controls pass without explaining that occurrence. Test-only diagnostic PR #2288 captures profile requests/responses, visible composer state and frames; its payload is not automatically suitable for production.

Working assumption (maintainer, 2026-10-17): treat the blocked-Send observations as resource starvation during testing for now. This is a working hypothesis, not a demonstrated causal diagnosis. It is unclear whether the same condition occurs in production or what its production effect would be. Design a way to capture useful evidence if it does occur there, without adversely affecting production.

Source inspected at 8c4d191e761bec31f3267d3b612a77712692f54a:

• canSend, packages/ui-react/src/components/chat/composer.tsx:695, combines draft presence, connection, pending send, restoration and profile readiness; the visible profile/restoration reasons start at :803.
• useSessionProfile, packages/ui-react/src/hooks/use-session-profile.ts:8-60, owns profile fetch/save and the awaitingDraftFacts admission condition. Observe these facts without reading draft or response contents.
• DiagnosticReview, packages/ui-react/src/components/report/diagnostic-review.tsx:81-140, provides the existing reviewed-copy/report interaction; assess reuse rather than inventing another disclosure flow. Related #1720 owns the connection-report design and remains separate, not a prerequisite assumed here.

Read ROADMAP.md's binding rules, docs/decisions/provider-history.md and docs/decisions/agent-observability.md, especially the rule that observability must not break the observed work. Brain-kit owns generic behavior; no real deployment configuration or incident details belong in this public issue.

Scope

Evaluate a minimal way to retain and retrieve a bounded, privacy-safe sequence around an unexpectedly prolonged unavailable-Send condition. Distinguish normal unavailable states, slow progress, a failed prerequisite and missing observations. Examine reuse of existing state transitions and diagnostic reports. Compare low-overhead approaches and specify a concrete recommended design, including any limitations that prevent a production conclusion.

Acceptance criteria

• Define the trigger and reset rules without treating an empty draft, intentional restoration, offline state, profile change or background/frozen tab as an incident. Report unknown observations honestly; elapsed wall time alone is not proof of resource starvation.
• Specify an allowlisted event schema sufficient to identify which Send predicate remains false, prerequisite request start/settlement/status categories and relative timing. Consider bounded event-loop delay and host pressure evidence only where obtainable cheaply; distinguish client versus host evidence and unavailable measurements. No request/response bodies, prompt/draft text, credentials, raw URLs/paths, personal data or provider payloads.
• Compare disabled and enabled overhead on the normal path and during sustained starvation, many transitions, hidden/frozen/resumed tabs and multiple clients. Set explicit measurable CPU/time, allocation/memory, event-count/byte, retention and any I/O budgets before selecting an implementation. Document measurement limits instead of promising mathematically zero overhead.
• Require passive, bounded, best-effort capture: no synchronous storage/network work, blocking locks, expensive serialization or per-frame polling on the send/render/request paths; no unbounded queues or diagnostic retry storms. Exhaustion, capture exceptions, missing APIs and failed persistence/export must drop evidence rather than delay or prevent normal work. The design must not worsen the resource pressure being investigated.
• Define access, isolation, expiry and explicit reviewed retrieval using existing product boundaries where possible. No automatic external upload. Diagnostics remain internal and never enter model/provider history. Explain evidence loss on crashes/reloads and the tradeoff of memory-only versus bounded deferred persistence without selecting persistence by assumption.
• Provide a concrete offline verification plan for an eventual implementation: delayed/failed profile facts, delayed restoration, event-loop contention, background suspension, normal slow readiness and diagnostic failure/cap exhaustion. Compare instrumentation disabled/enabled and assert unchanged send/admission, recovery and auth outcomes. Identify meaningful fault/mutation controls and measurable overhead acceptance, without causing production incidents.
• Deliver a design recommendation with alternatives, trigger/schema/bounds, retrieval UX, risks and the smallest implementation brief. A documented recommendation to defer because safe useful capture is infeasible is a valid result. Record it on this issue or in an appropriate decision record; do not implement or enable collection as part of the spike.

Verification

Review each proposed observation against the cited source and the existing connection/report work. Use keyless, offline Odysseus fixtures for any feasibility prototype; preserve browser/network guards and restore temporary changes. Source inspection or a passing replay must not be presented as proof of production incidence, a starvation diagnosis or zero overhead. Design-only work has no runtime pass claim; any prototype records its actual source, measurements and limitations.

Contract impact

No production change is selected by this design spike. Classify any proposed new route, wire frame, supported SDK export, configuration or retained schema before implementation, and specify the applicable contract updates and changesets for a separately scoped implementation. No new extension seam is authorized.