"use client";
import {
useEffect,
useId,
useMemo,
useRef,
useState,
useCallback,
type CSSProperties,
} from "react";
import { useNotifications } from "@/hooks/useNotifications";
import { useFocusTrap } from "@/hooks/useFocusTrap";
import { useRouter } from "next/navigation";
import { truncateAtWordBoundary } from "@/lib/utils";
import { MAX_MESSAGE_LENGTH } from "./composer/composerConstants";
import { track, lengthBucket } from "@/lib/analytics";
import { getSubdomainSlug, getPortalUrl } from "@/lib/subdomain";
import {
getSession,
getPortalContext,
getPortalSpecialists,
avatarSrc,
ApiError,
type Session,
type ConversationMessageMetadata,
MessageAttachment,
type NativeTranscriptMessage,
uploadChatAttachment,
PortalContext,
PortalSpecialist,
markNotificationRead,
getToken,
rewriteDraft,
ClarifyingCardAnswer,
type RewriteTone,
} from "@/lib/api";
import { ClarifyingCardView } from "./ClarifyingCardView";
import {
ArrowRight,
ChevronDown,
Check,
Copy,
Menu,
ChevronLeft,
ThumbsUp,
ThumbsDown,
Wrench,
} from "lucide-react";
import { toast } from "@/components/shared/Toast";
import { useConfirmDialog } from "@/components/ui/confirm-dialog";
import { ExpertChatOverlay } from "@/components/internal/ExpertChatOverlay";
import { useAuth } from "@/hooks/useAuth";
import { useIsMobile, LANDSCAPE_PHONE_MAX_HEIGHT } from "@/hooks/useIsMobile";
import { useNetworkState, isNetworkError } from "@/hooks/useNetworkState";
import { OfflineBanner } from "./OfflineBanner";
import { MobileThreadSheet } from "./MobileThreadSheet";
import { MobileSpecialistSheet } from "./MobileSpecialistSheet";
import { MobileChatLayout } from "./layout/MobileChatLayout";
import { SidebarCollapseToggle } from "./layout/SidebarCollapseToggle";
import { portalSidebarColumnStyle } from "./layout/portalSidebarStyle";
import { useThreads } from "./hooks/useThreads";
import {
isOptimisticMessage,
messageClientKey,
newestServerMessageAt,
useMessages,
type MessageWithState,
type OptimisticMessage,
type StreamingReply,
} from "./hooks/useMessages";
import { useSpecialistActions } from "./hooks/useSpecialistActions";
export { reconcileFetchedMessages } from "./hooks/useMessages";
import { RelTime, relTimeFull } from "@/lib/relTime";
import { ChatAttachments } from "@/components/shared/ChatAttachments";
import { Sidebar } from "./Sidebar";
import { WorkerAvatar } from "./WorkerAvatar";
import {
activeSpecialist,
specialistRoleLabel,
} from "./specialist-selection";
import { BlockMarkdown } from "@/lib/blockMarkdown";
import { TrialBanner } from "./TrialBanner";
import { OnboardingCallView } from "@/components/client/OnboardingCallView";
import { VideoCallView } from "@/components/client/VideoCallView";
import Avatar from "@/components/ui/avatar";
import Badge from "@/components/ui/badge";
import { skillTagTokens } from "@/lib/skillTagColor";
import {
specialistDisplayName,
specialistTags,
} from "./briefing/specialist-fields";
import { MessageList } from "./MessageList";
import { ComposerArea } from "./ComposerArea";
import { PORTAL_HEADER_HEIGHT } from "./layout/portalHeaderLayout";
import {
MOBILE_THREAD_HEADER_LEFT_INSET,
THREAD_HORIZONTAL_INSET,
} from "./layout/threadLayout";
import { BriefingPanel as ExtractedBriefingPanel } from "./BriefingPanel";
import { getSendErrorMessage } from "./sendErrorMessage";
// ── Helpers ────────────────────────────────────────────────────────────────────
function isClosedClientThread(status: string | null | undefined): boolean {
// `archived` was collapsed into `resolved` (#2002) — `resolved` is the only
// closed state the backend ever returns.
return status === "resolved";
}
// ── Specialist activity / waiting status ───────────────────────────────────────
// #3503: the chat used to render an animated "typing…" dots bubble on the
// specialist side whenever the last client-visible message was from the user,
// and kept it up until a reply landed — sometimes for minutes or hours. That is
// a false signal: no one is actually typing. The platform is HITL-by-default,
// so a reply is queued for an Expert rather than composed live, and there is no
// presence/generation signal saying a specialist is typing right now. Showing
// fake activity erodes trust in every other status indicator in the product.
//
// The fix separates the two states the old bubble conflated:
// • genuine in-flight activity → `TypingIndicator` (animated dots), rendered
// ONLY when a real, transient "specialist is composing now" signal is
// present. No such backend presence signal exists today, so it stays off in
// production; the `specialistTyping` prop keeps the path wired for when one
// lands (and lets the regression test exercise it).
// • idle waiting → `WaitingForSpecialist`: a truthful status line with a
// subtle pulse and no typing dots.
// How long the opening "message received" confirmation shows before it decays
// to the steady "waiting for specialist" line.
const WAITING_CONFIRMATION_MS = 4000;
// ── Waiting-for-specialist status ───────────────────────────────────────────────
// Truthful status shown while the client awaits a reply and nobody is actively
// composing. Opens with a brief "message received" confirmation that decays to
// a steady "waiting" line, giving instant acknowledgement without faking a
// typing animation.
// The caller remounts this via a `key` on the last client message id, so the
// confirmation→waiting decay restarts cleanly each time the client sends again.
function WaitingForSpecialist({
specialistName,
avatarSrc,
}: {
specialistName: string;
avatarSrc?: string | null;
}) {
const [confirming, setConfirming] = useState(true);
useEffect(() => {
const timer = setTimeout(
() => setConfirming(false),
WAITING_CONFIRMATION_MS,
);
return () => clearTimeout(timer);
}, []);
const named = specialistName && specialistName !== "Your specialist";
const text = confirming
? named
? `Message received — ${specialistName} will reply shortly.`
: "Message received — your specialist will reply shortly."
: named
? `Waiting for ${specialistName}…`
: "Waiting for your specialist…";
return (
<>
{text}
);
}
// ── Specialist activity indicator ───────────────────────────────────────────────
// Picks the right specialist-side affordance while the client awaits a reply:
// the animated typing bubble ONLY when a specialist is genuinely composing,
// otherwise the truthful waiting status.
export function SpecialistActivityIndicator({
specialistName,
avatarSrc,
lastUserMessageId,
specialistTyping = false,
}: {
specialistName: string;
avatarSrc?: string | null;
lastUserMessageId?: string;
/** True only while a real, transient "specialist is composing now" signal is
* active. Defaults false — see #3503: we never fabricate typing activity. */
specialistTyping?: boolean;
}) {
if (specialistTyping) {
return (
);
}
// `key` remounts WaitingForSpecialist on each new client message so its
// "message received" → "waiting" decay restarts.
return (
);
}
// ── Typing indicator ───────────────────────────────────────────────────────────
// Animated three-dots bubble. Render this ONLY while a specialist is genuinely
// composing a reply — never to represent "message sent, awaiting a reply"
// (that is `WaitingForSpecialist`'s job). See #3503.
function TypingIndicator({
specialistName,
avatarSrc,
}: {
specialistName: string;
avatarSrc?: string | null;
}) {
return (
<>
{[0, 180, 360].map((delay) => (
))}
);
}
// ── Message bubble ─────────────────────────────────────────────────────────────
const EXPERT_ROLES = ["expert", "account_manager", "superadmin"];
function channelViaLabel(channel: string | null | undefined): string | null {
if (!channel) return null;
const c = channel.toLowerCase();
if (c === "web" || c === "webchat") return null;
const names: Record = {
whatsapp: "WhatsApp",
email: "Email",
slack: "Slack",
telegram: "Telegram",
teams: "Teams",
sms: "SMS",
line: "LINE",
};
return `via ${names[c] ?? channel}`;
}
// Hover-revealed "copy message" affordance sitting just outside the bubble.
// The affordance is positioned in the gap beside the bubble (left/right anchored
// to -hitWidth), which is OUTSIDE the hover container's box. What keeps it
// reliably clickable:
// 1. It stays MOUNTED and only fades via opacity/pointer-events, so the
// click target always exists while the pointer is over it.
// 2. Its hit box spans the FULL HEIGHT of the bubble column (top:0/bottom:0),
// not a 22px sliver at the top. This is the load-bearing part: the button
// is a DOM descendant of the hover container, so as long as the strip it
// occupies is contiguous with the bubble, moving the pointer outward from
// ANY point on the bubble lands directly on the button (a descendant) and
// never crosses container-external empty space — so the container's
// onMouseLeave never fires and `hovered` stays true. A short (22px) hit
// box only bridged the top edge: approaching the chip from the body of a
// normal multi-line bubble left the container first, flipped `hovered`
// false, and the button went pointer-events:none before the click landed
// (the #5038 residual — the chip "still" vanished on approach). The
// visible 22px chip is centred within the full-height hit box.
// 3. The inner edge is always flush at the bubble edge (offset === -width), so
// the box never overlaps the message body. This matters because on mobile
// the box is always interactive — a wider target that reached over the
// text would steal taps (and link taps) from the content. The mobile 44px
// touch target therefore grows OUTWARD into the gutter, not inward.
// 4. Touch devices have no hover, so `hovered` is never true there. The chip
// is shown unconditionally on mobile — otherwise it was permanently
// invisible and untappable despite its 44px touch target.
function CopyMessageButton({
side,
copied,
visible,
isMobile,
onCopy,
}: {
side: "left" | "right";
copied: boolean;
visible: boolean;
isMobile?: boolean;
onCopy: () => void;
}) {
const isLeft = side === "left";
const shown = visible || !!isMobile;
const hitWidth = isMobile ? 44 : 28;
return (
);
}
/**
* Hermes flattens inbound attachment blocks into annotation lines inside the
* SessionDB user record ("[Attached image: x.png]", "URI: file:///…",
* "[screenshot]"). The transcript is read back byte-for-byte by design, so
* the client view strips those runtime annotations at render time — the
* attachment itself is shown as a chip from the receipt metadata.
*/
function stripAttachmentAnnotations(content: string | null | undefined): string {
if (!content) return "";
return content
.split("\n")
.filter(
(line) =>
!/^\[Attached (?:image|file):[^\]]*\]\s*$/.test(line) &&
!/^URI: file:\/\/\/\S+\s*$/.test(line) &&
!/^\[(?:screenshot|image|document|attachment)\]\s*$/.test(line),
)
.join("\n")
.trim();
}
/**
* A single tool step, rendered as its own collapsible activity card
* (Codex/Claude pattern) rather than merged into an assistant bubble. The
* header names the tool and shows its exit signal; expanding reveals the
* raw tool output. Tool `content` is a JSON envelope
* (`{output, exit_code, error}` for terminal, tool-specific otherwise); we
* surface it verbatim in a monospace block, never parsed into prose.
*
* #6097: a client-scoped session read never carries the raw payload — the
* API strips it and maps `toolName` to a plain-English label before the
* response leaves the server (SessionsService.projectTranscriptForClient) —
* so `content` arrives empty here. With nothing to expand into, this
* renders a small centered, non-interactive chip instead of a debug-style
* collapsible "tool" row. Centered (not flush to either side) so it never
* reads as something either party said — this portal renders the
* Specialist's replies on the right and the client's own messages on the
* left, and a plain text label on either side risked being misread as part
* of that party's message. The collapsible raw view below still serves the
* internal ops surfaces that reuse this component (SideChatPanel, agent
* workspace preview), which read the untouched row and still need it for
* debugging.
*/
export function ToolActivityCard({
toolName,
content,
}: {
toolName: string | null;
content: string;
}) {
const [expanded, setExpanded] = useState(false);
const label = toolName || "Tool activity";
if (!content) {
return (
{/* Internal notes are authored by Experts — same block-markdown
* renderer as worker replies so notes with headings/lists
* render consistently. */}
{msg.content}
);
}
// Experts see "Expert" label + purple; clients see specialist persona + handling badge
const senderColor = "var(--brand)";
const senderLabel = senderName || agentName;
const showHandlingBadge = !isExpertViewer;
// #4340 — Specialist avatar on the bubble, clickable → opens the profile.
// Ghost-write safety: a client (and any AI message) always sees the
// Specialist persona avatar; only an Expert viewing an Expert-authored
// message sees the purple "E" identity. The Expert's own avatar is never
// surfaced to a client. The "E" badge is not a Specialist, so it does not
// link to a profile.
const isExpertIdentity = false;
const messageAvatarSrc = isExpertIdentity ? null : (agentAvatarUrl ?? null);
const avatarInitial = isExpertIdentity ? "E" : senderLabel.charAt(0) || "S";
const avatarClickable = !!onAvatarClick && !isExpertIdentity;
return (
setHovered(true)}
onMouseLeave={() => setHovered(false)}
>
{/* #4340 — Specialist avatar beside the bubble. row-reverse puts this
first child on the far right, next to the message. When a profile
handler is wired (and this isn't the Expert identity badge) it's a
real button: keyboard-focusable, Enter/Space activates, screen
readers announce the label, 44px touch target on mobile. */}
{avatarClickable ? (
) : (
)}
{/* Render assistant/expert replies through the same safe inline
* markdown subset used by the Expert draft preview (#1758). */}
{msg.content}
)}
{/* #2686 — incoming (Specialist/Expert) replies can carry image/file
attachments too. Previously only the client's OWN (isUser) bubble
rendered ChatAttachments, so an Expert reply with an image showed
as text-only to the client. Render via the same auth-gated proxy. */}
{Array.isArray(attachments) && attachments.length > 0 && (
)}
{/* Clarifying card (HW_QUESTION): tappable options the client answers
inline. Interactive for the client; read-only for an Expert viewer
reviewing the thread. */}
{clarifyingCard && (
)}
{msg.content && (
)}
{/* P4.4 (R4.7): client 👍/👎 on a Specialist reply. Only the client
* sees it (not the Expert viewer), never on internal notes. Copy
* neutral — never invites rating "the AI" (Q4/D5: persona-safe). */}
{onFeedback && !isExpertViewer && !isInternal && msg.content && (
{(["up", "down"] as const).map((s) => {
const active = feedback === s;
const Icon = s === "up" ? ThumbsUp : ThumbsDown;
return (
);
})}
)}
);
}
if (isUser) {
const viaLabel = channelViaLabel(messageChannel ?? convChannel);
// #4159 — client member identity: show avatar + name on the left
const memberName = senderName ?? null;
const memberInitial = memberName
? memberName.charAt(0).toUpperCase()
: null;
return (
setHovered(true)}
onMouseLeave={() => setHovered(false)}
>
{/* Member avatar — human client identity: generic person glyph, not
the seeded avatar asset (kept consistent with the sidebar footer). */}
{memberName && (
)}
);
}
return null;
}
// ── Briefing panel (no thread selected) ────────────────────────────────────────
// Generic fallback prompts. Only shown when the assigned specialist has no
// catalog profile (legacy rows). For catalog-backed specialists we derive
// role-relevant prompts from their capabilities — see specialistSuggestionPrompts.
const BRIEFING_PROMPTS: string[] = [
"Draft a polite payment chase to a late supplier",
"Pull last month's expense breakdown by vendor",
"Summarize this week's compliance escalations",
"Find duplicate invoices over $1,000 from Q1",
];
/**
* #3496: Build role-relevant starter prompts for the empty-state briefing.
*
* The hardcoded finance prompts (BRIEFING_PROMPTS) were shown to every client
* regardless of their specialist's role — e.g. "payment chase" / "duplicate
* invoices" on a Cold Chain / Shipment Coordinator. Derive the suggestions from
* the assigned specialist's catalog capabilities so what's offered matches what
* the specialist actually does. Capabilities are already imperative phrases
* ("Coordinate outbound and inbound load logistics…"), which read naturally as
* a client's opening ask. Falls back to the generic list for legacy specialists
* with no catalog profile.
*/
interface SuggestionPrompt {
/** What renders on the button. */
label: string;
/** What lands in the composer draft on click — always the full sentence. */
text: string;
}
function specialistSuggestionPrompts(
specialist?: PortalSpecialist | null,
): SuggestionPrompt[] {
const caps = (specialist?.coreCapabilities ?? [])
.map((c) => (typeof c === "string" ? c.trim() : ""))
.filter((c): c is string => c.length > 0);
if (caps.length === 0)
return BRIEFING_PROMPTS.map((prompt) => ({ label: prompt, text: prompt }));
return caps.slice(0, 4).map((cap) => {
// Collapse whitespace and drop trailing punctuation. These buttons are
// full-width and wrap, so the label needs no length cap — it shows the
// same clean, complete sentence that gets sent as the draft. Still
// clamped to the API's message limit as a backstop: catalog capabilities
// are admin-authored and normally well under this, but nothing enforces
// that server-side, and an oversized one would otherwise reach the send
// path unchanged and get rejected there instead.
const clean = cap.replace(/\s+/g, " ").replace(/[.;:,]+$/, "");
const bounded = truncateAtWordBoundary(clean, MAX_MESSAGE_LENGTH);
return { label: bounded, text: bounded };
});
}
function statusGroupOf(
status: string | null | undefined,
): "awaiting" | "open" | "resolved" | "other" {
if (status === "awaiting_client") return "awaiting";
if (status === "pending") return "open";
if (status === "resolved") return "resolved";
return "other";
}
function StatusPill({ status }: { status: string | null | undefined }) {
const group = statusGroupOf(status);
if (group === "other") return null;
const tokens: Record<
"awaiting" | "open" | "resolved",
{ bg: string; fg: string; label: string }
> = {
awaiting: {
bg: "var(--warning-subtle)",
fg: "var(--warning)",
label: "Needs input",
},
open: { bg: "var(--info-subtle)", fg: "var(--info)", label: "In progress" },
resolved: {
bg: "var(--bg-elevated)",
fg: "var(--text-muted)",
label: "Resolved",
},
};
const t = tokens[group];
return (
{t.label}
);
}
function chipStyle(tag: string): CSSProperties {
const { bg, text } = skillTagTokens(tag);
return {
display: "inline-flex",
alignItems: "center",
padding: "3px 9px",
fontSize: 12,
borderRadius: 999,
border: "1px solid transparent",
color: text,
background: bg,
whiteSpace: "nowrap",
maxWidth: "100%",
};
}
// #4581: capabilities are full sentences, so nowrap text must clip inside the
// pill. `inline-block` (not `inline-flex`) — text-overflow doesn't ellipsize a
// flex container's anonymous text child. Pair with a `title` attr for the full
// text when the content can be long.
const plainChipStyle: CSSProperties = {
display: "inline-block",
padding: "3px 9px",
fontSize: 12,
borderRadius: 999,
border: "1px solid var(--border)",
color: "var(--text-secondary)",
background: "var(--bg-elevated)",
whiteSpace: "nowrap",
maxWidth: "100%",
overflow: "hidden",
textOverflow: "ellipsis",
};
const specialistSectionLabelStyle: CSSProperties = {
margin: "0 0 8px",
fontSize: 12,
fontWeight: 600,
color: "var(--text-muted)",
textTransform: "uppercase",
letterSpacing: "0.07em",
};
export function SpecialistDashboardProfile({
specialist,
allSpecialists,
}: {
specialist: PortalSpecialist;
/** Full assigned list, for the Primary/Secondary badge. Omitted → treat `s`
* as the whole team (lone specialist → no badge). #3174 */
allSpecialists?: PortalSpecialist[];
}) {
return (
);
}
/**
* Identity half of the Specialist profile — avatar, online dot, name, the
* Primary/Secondary badge, title and the per-OSA email alias.
*
* Split out of SpecialistDashboardProfile (#4949) so the briefing rail can put
* the Specialist's two actions directly under the identity block and push the
* dossier (SpecialistDetail, via SpecialistAbout) below them. The composed
* SpecialistDashboardProfile renders exactly as before.
*/
export function SpecialistIdentity({
specialist: s,
allSpecialists,
}: {
specialist: PortalSpecialist;
allSpecialists?: PortalSpecialist[];
}) {
const displayName = specialistDisplayName(s) || s.firstName;
// #3174: no Primary/Secondary badge for a lone specialist.
const roleLabel = specialistRoleLabel(s, allSpecialists ?? [s]);
return (
{/* The sheet's largest step. This was `lg` forced to 72px with `!size-[]`
and a hand-drawn dot at #22c55e, which is on no ramp (#5885). */}
{displayName}
{roleLabel && (
{roleLabel}
)}
{s.title && (
{s.title}
)}
{/* #2617: surface the Specialist's contact email in-app so clients
don't have to dig through their onboarding email to find it. */}
{s.emailAlias && (
{s.emailAlias}
)}
{/* #2785: the online status is already shown as a green dot on the
avatar (above); a second inline "● online" indicator here collided
with the email line, so it was removed to avoid the duplicate. */}
);
}
/**
* Dossier half of the Specialist profile — bio, tags, capabilities and the
* integrations they need. Rendered as a fragment so the sections stay direct
* children of SpecialistDashboardProfile's flex column and keep its gap.
*/
export function SpecialistDetail({
specialist: s,
}: {
specialist: PortalSpecialist;
}) {
const tags = specialistTags(s);
return (
<>
{/* #4856: prefer the `bio` column (edited via /ops/specialists) and fall
back to `description` — mirrors the ops view modal. Reading only
`description` silently dropped saved bios and showed the empty state. */}
{s.bio || s.description ? (
{s.bio || s.description}
) : (
No description on file for this Specialist yet.
)}
{tags.length > 0 && (
Tags
{tags.map((tag) => (
{tag}
))}
)}
{s.coreCapabilities.length > 0 && (
What they do
{s.coreCapabilities.map((cap) => (
{cap}
))}
)}
{s.requiredIntegrations.length > 0 && (
What they need access to
{s.requiredIntegrations.map((integration) => (
{integration}
))}
)}
);
}
export function DashboardSpecialistCarousel({
specialists,
activeSpecialistId,
onActiveChange,
profile = "full",
}: {
specialists: PortalSpecialist[];
/** #5444: the Specialist to display, when the parent owns the selection for a
wider surface. It wins over any local pick — the briefing rail's composer
moves the selection too, and a carousel holding its own would show one
Specialist while the rail's actions targeted another. Omit it (or pass
null) to let the carousel own the selection. */
activeSpecialistId?: string | null;
/** #4584: notifies the parent which Specialist profile is currently
displayed, so context-specific actions (the panel's "+ New thread" CTA)
can target them instead of re-asking via the W-1 picker. */
onActiveChange?: (specialistId: string) => void;
/** #4949 — "identity" renders only the identity block, so the briefing rail
* can slot the Specialist's actions between it and the dossier (which the
* rail then renders itself via SpecialistAbout). "full" keeps the original
* identity + dossier profile. */
profile?: "full" | "identity";
}) {
// #2796: null = no manual pick yet, so the default tracks the Primary
// Specialist (resolved below) even if the list loads/reorders after mount.
// A pick via the dropdown pins the choice.
const [pickedSpecialistId, setPickedSpecialistId] = useState(
null,
);
const [open, setOpen] = useState(false);
const menuRef = useRef(null);
const triggerRef = useRef(null);
const firstOptionRef = useRef(null);
const hasPicker = specialists.length > 1;
const menuId = useId();
// Resolve who is on display: the parent's selection when it owns one,
// otherwise the local pick, otherwise the Primary (#2796). Resolving by id
// rather than index also means a selection that outlives a reordered or
// shrunken list falls back to the Primary instead of pointing at whoever
// now holds that slot.
const displayedSpecialist = activeSpecialist(
specialists,
activeSpecialistId ?? pickedSpecialistId,
);
// Close the dropdown on outside click or Escape, returning focus to the
// trigger so keyboard users aren't stranded.
useEffect(() => {
if (!open) return;
const onPointerDown = (event: MouseEvent) => {
if (menuRef.current && !menuRef.current.contains(event.target as Node)) {
setOpen(false);
}
};
const onKeyDown = (event: KeyboardEvent) => {
if (event.key === "Escape") {
setOpen(false);
triggerRef.current?.focus();
}
};
document.addEventListener("mousedown", onPointerDown);
document.addEventListener("keydown", onKeyDown);
return () => {
document.removeEventListener("mousedown", onPointerDown);
document.removeEventListener("keydown", onKeyDown);
};
}, [open]);
// When the menu opens, move focus into it so keyboard users land on the
// currently-selected option.
useEffect(() => {
if (open) firstOptionRef.current?.focus();
}, [open]);
if (!displayedSpecialist) {
return (
No Specialists are assigned to your team yet.
);
}
const activeName =
specialistDisplayName(displayedSpecialist) || displayedSpecialist.firstName;
// #3174: Primary/Secondary by effective-primary rule (no all-Secondary when
// none is flagged); null only for a lone specialist (picker is hidden then).
const activeRole = specialistRoleLabel(displayedSpecialist, specialists);
// #4584: the parent hears every pick, so a surface that owns the selection
// sends it straight back down as `activeSpecialistId`.
const selectSpecialist = (specialistId: string) => {
setPickedSpecialistId(specialistId);
onActiveChange?.(specialistId);
setOpen(false);
};
return (
Your Specialists
{hasPicker && (
{/* Picker trigger — shows the currently selected Specialist */}
{/* Dropdown — every assigned Specialist, immediately accessible.
Rendered as a radiogroup of native buttons (role=radio). Unlike
role=menu/listbox, the radiogroup pattern tolerates Tab-based
navigation, so keyboard semantics match the actual behaviour:
Tab to traverse, Enter/Space to pick, Escape to close. */}
{open && (
)}
{profile === "identity" ? (
) : (
)}
);
}
function BriefingEmpty({
portalContext,
specialists,
onNew,
onSuggestion,
createError,
userFirstName,
}: {
portalContext?: PortalContext | null;
specialists: PortalSpecialist[];
onNew: () => void;
onSuggestion: (text: string) => void;
createError?: string | null;
userFirstName?: string | null;
}) {
// #5444: the carousel selection drives the introduction and the starter
// prompts beside it, the way it drives the populated rail. Resolving the
// Primary here independently let the copy introduce one Specialist while the
// carousel showed another.
const [selectedSpecialistId, setSelectedSpecialistId] = useState<
string | null
>(null);
const displayedSpecialist = activeSpecialist(
specialists,
selectedSpecialistId,
);
const specialistName =
displayedSpecialist?.firstName ?? "your specialist";
const orgName = portalContext?.orgName ?? "your team";
const greetingName = userFirstName?.trim();
// #3496: prompts tailored to the assigned specialist's role, not hardcoded finance.
const suggestionPrompts = specialistSuggestionPrompts(displayedSpecialist);
if (specialists.length === 0) {
return (
{greetingName
? `Hi ${greetingName} — no Specialists are assigned to your team yet.`
: "No Specialists are assigned to your team yet."}
Please contact your Account Manager to get started.
);
}
return (
{/* Specialist carousel - shows all assigned specialists */}
{greetingName
? `Hi ${greetingName} — I'm ${specialistName}, your dedicated specialist for ${orgName}. I'm here to handle your ops work so you don't have to.`
: `I'm ${specialistName}, your dedicated specialist for ${orgName}. I'm here to handle your ops work so you don't have to.`}
What would you like to work on today?
{suggestionPrompts.map((prompt, i) => (
))}
{createError && (
{createError}
)}
);
}
// ── Chat panel ─────────────────────────────────────────────────────────────────
/**
* Placeholder shown while an existing thread's message history is loading.
* Renders a few shimmering bubble outlines so the user sees the chat is
* populating rather than a blank panel or the misleading "ready" empty-state
* (#1737). Alternating alignment mimics user/specialist turns.
*/
function MessageHistorySkeleton() {
// Widths chosen to look like a natural back-and-forth conversation.
const rows: Array<{ align: "flex-start" | "flex-end"; width: number }> = [
{ align: "flex-start", width: 62 },
{ align: "flex-end", width: 48 },
{ align: "flex-start", width: 74 },
{ align: "flex-end", width: 40 },
];
return (
{rows.map((row, i) => (
))}
Loading conversation…
);
}
export function ChatPanel({
conversation,
messages,
messageMetadata,
loadingMessages,
messagesError,
onRetryLoadMessages,
onSend,
onSendNote,
sending,
streamingReply,
onBack,
portalContext,
platformRole,
userId,
onStatusChange,
onArchive,
onAssignToMe,
onUnarchive,
resolvingId,
onRetry,
onFeedback,
onClarifyingCardSubmit,
answeredCardIds,
onOpenThreadSheet,
onOpenSpecialistSheet,
onRequestHuman,
humanRequested,
requestingHuman,
}: {
conversation: Session;
messages: MessageWithState[];
messageMetadata: ConversationMessageMetadata[];
/** True while the message history for this thread is still being fetched.
Distinguishes a genuinely-empty new thread (show the "ready" prompt) from
an existing thread whose messages haven't arrived yet (show a skeleton).
Without this, an existing thread flashes the empty-state — the #1737 bug. */
loadingMessages: boolean;
/** Set when the message fetch for this thread failed (#5442). Passed through
to MessageList so a failed load renders an error state with Try again
instead of the "{Specialist} is ready" empty-thread prompt. */
messagesError?: string | null;
/** Re-runs the failed fetch for this thread. */
onRetryLoadMessages?: () => void;
onSend: (text: string, attachments?: MessageAttachment[]) => void;
onSendNote: (text: string) => void;
sending: boolean;
/** Live agent reply streaming for this thread (ordered text/tool segments), or null. */
streamingReply?: StreamingReply | null;
/** Returns to the briefing view — used as a mobile-friendly back affordance. */
onBack: () => void;
portalContext?: PortalContext | null;
platformRole?: string | null;
userId?: string;
onStatusChange?: (convId: string, status: string) => void;
/** Client-safe resolve handler — PATCH /conversations/:id/resolve. Unlike
onStatusChange (staff-only /status), clients are authorized to call this. */
onArchive?: (convId: string) => void;
onAssignToMe?: (convId: string) => void;
onUnarchive?: (id: string) => void;
/** Conversation ID currently being resolved - disables resolve button to prevent double-clicks */
resolvingId?: string | null;
/** W-2: retry a failed optimistic send (client WebChat only). */
onRetry?: (msg: OptimisticMessage) => void;
/** P4.4 (R4.7): client 👍/👎 on a Specialist reply. */
onFeedback?: (
msg: NativeTranscriptMessage,
sentiment: "up" | "down",
) => void;
/** Client submitted a clarifying card — the parent sends the readable
* summary as a normal message, carrying the structured answer. Resolves to
* `false` when the send failed so the card can offer a retry. */
onClarifyingCardSubmit?: (
answer: ClarifyingCardAnswer,
summaryText: string,
) => void | boolean | Promise;
/** Card ids the client has successfully answered (locks that exact card). */
answeredCardIds?: Set;
/** Opens the mobile thread switcher sheet. */
onOpenThreadSheet?: () => void;
/** Opens the mobile specialist info sheet. */
onOpenSpecialistSheet?: () => void;
/** #4907: "Talk to a human" — sends this thread straight to an Expert. */
onRequestHuman?: () => void;
/** #4907: an ask is already on the record for this thread. */
humanRequested?: boolean;
/** #4907: the request is in flight. */
requestingHuman?: boolean;
}) {
const isExpert = EXPERT_ROLES.includes(platformRole ?? "");
const isMobile = useIsMobile();
const subject =
conversation.customTitle ||
conversation.subject ||
truncateAtWordBoundary(messages[0]?.content || "", 80) ||
"New thread";
const threadSpecialist = conversation.specialistId
? (portalContext?.specialists?.find(
(s) => s.id === conversation.specialistId,
) ?? null)
: null;
// Fallback hierarchy: thread-specific specialist → primary specialist →
// conversation.agentName (ground truth stored at thread creation time) →
// generic. Using conversation.agentName before the generic default ensures
// the composer and send button always reflect the actual specialist for this
// thread even when portalContext hasn't loaded yet or the specialistId no
// longer matches a currently-assigned specialist.
const fallbackSpecialist =
portalContext?.specialists?.find((s) => s.isPrimary) ??
portalContext?.specialists?.[0] ??
null;
const activeSpecialist = threadSpecialist ?? fallbackSpecialist;
const specialistName =
activeSpecialist?.firstName ??
conversation.agentName ??
"Your specialist";
const specialistAvatarUrl = activeSpecialist?.avatarUrl ?? null;
// Capture orgId at render time so it's narrowed to `string` inside the
// onUploadFile callback — TypeScript can't narrow through the closure.
const convOrgId = conversation.orgId;
return (
{/* Thread header — subject + status + channel */}
{/* Thread switcher — mobile only */}
{onOpenThreadSheet && (
)}
}
renderMessage={(msg) => {
const metadata = isOptimisticMessage(msg)
? undefined
: messageMetadata.find(
(entry) =>
entry.locator.sessionId === msg.locator.sessionId &&
entry.locator.messageId === msg.locator.messageId,
);
const clarifyingCard = metadata?.clarifyingCard;
return (
);
}}
renderActivity={(lastVisibleMessage) =>
streamingReply &&
streamingReply.conversationId === conversation.id &&
// A tool-only stream (no text segment yet, or a text segment that's
// still empty/whitespace — the first token or two before real content
// lands) has nothing client-visible to draw — tool activity is a
// debugging aid, logs cover that — so falling into the text-segment
// branch below would render an empty fragment and leave the client
// with no sign the Specialist is still working. Keep the activity
// indicator up until there's actual text to show in its place.
streamingReply.segments.some(
(segment) => segment.type === "text" && segment.content.trim().length > 0,
) ? (
<>
{streamingReply.segments.map((segment, index) =>
segment.type === "tool" ? null : (
),
)}
) : (
)
}
/>
{isClosedClientThread(conversation.status) ? (
This thread is closed.
) : (
uploadChatAttachment(file, {
orgId: convOrgId,
// Specialist-keyed (shared inbound AgentFS namespace): works both
// for existing threads and for the compose view, where no session
// exists until the first message mints one.
specialistId: conversation.specialistId,
})
: undefined
}
onRewrite={
!isExpert
? (text, tone) => rewriteDraft(text, tone, convOrgId ?? undefined)
: undefined
}
/>
)}
);
}
// ── Main PortalChat component ──────────────────────────────────────────────────
function getUserFirstName(): string | null {
if (typeof window === "undefined") return null;
const token = getToken();
if (!token) return null;
try {
const payload = JSON.parse(atob(token.split(".")[1]));
const display =
(typeof payload?.displayName === "string" &&
payload.displayName.trim()) ||
(typeof payload?.name === "string" && payload.name.trim()) ||
"";
if (!display) return null;
return display.split(/[\s._-]+/)[0] || null;
} catch {
return null;
}
}
// W-1: modal that asks which assigned Specialist a new thread should go to.
// Only shown for orgs with >1 Specialist; clicking a Specialist creates the
// thread pinned to them (the API still validates the choice against the org).
function NewThreadSpecialistPicker({
specialists,
onPick,
onClose,
}: {
specialists: PortalSpecialist[];
onPick: (specialistId: string) => void;
onClose: () => void;
}) {
// #4644: restore Escape-to-dismiss (and focus-on-open) for the picker. The
// component only mounts while the dialog is open, so the trap is always
// active here. Matches the pattern in KeyboardShortcutsModal.
const trapRef = useFocusTrap(true);
useEffect(() => {
function onKeyDown(e: KeyboardEvent) {
if (e.key === "Escape") {
e.stopPropagation();
onClose();
}
}
window.addEventListener("keydown", onKeyDown, { capture: true });
return () =>
window.removeEventListener("keydown", onKeyDown, { capture: true });
}, [onClose]);
return (