@kortix/ui 0.0.0-stage → 0.14.4

package/dist/session/panel/easy/plan-card.js

@@ -0,0 +1,108 @@
+'use client';
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import { useTranslations } from '../../../i18n/index.js';
+/**
+ * `PlanPanelCard` — the plan, as the Easy panel's fourth card.
+ *
+ * The panel already answers three questions about a session, each from one
+ * live singleton: what did it make (Outputs), what does it know (Context),
+ * what is it running (Preview). "What is it doing" was the missing fourth, and
+ * it lived in the transcript instead — pinned under whichever user message
+ * `plan-anchor.ts` judged to own it.
+ *
+ * That placement fought the data. The plan is ONE mutable list on ONE query
+ * key for the whole session, so drawing it at a fixed point in a scrolling
+ * history meant: an anchor that has to be guessed, an anchor that jumps
+ * forward every time the agent re-plans, a fallback for when compaction eats
+ * the `todowrite` parts that would have identified it — and, once the user
+ * scrolled, a live checklist they could no longer see. Here it is none of
+ * those things. It is a card that reads the key.
+ *
+ * It draws last, under Preview. The column reads finished → known → running →
+ * planned, and the plan sits closest to the composer, which is where the eye
+ * already is while an agent works.
+ *
+ * THIS IS THE PLAN'S ONLY HOME ON DESKTOP. Collapsing the column (Cmd/Ctrl+I)
+ * or covering it with a detail panel hides the plan; it does not send it back
+ * to the transcript. That is deliberate — see `planBelongsToChat`, which also
+ * says why not to re-add a visibility branch. The chat keeps the plan on
+ * mobile only, where no panel column exists at all. `usePlanInChat`
+ * (`plan-surface.ts`) makes that call once and both surfaces read it, so
+ * exactly one is ever mounted. See `turn/plan-card.tsx`, which owns the ring
+ * and the step rows both surfaces draw.
+ */
+import { useRuntimeSessionTodo } from '@kortix/sdk/react';
+import { useMemo } from 'react';
+import { parseTodos } from '../../tool/shared/todo-helpers.js';
+import { keyTodos, planListTodos, PlanRing, PlanSteps, planSummary, } from '../../turn/plan-card.js';
+import { cn } from '../../../lib/utils.js';
+import { PanelCard } from './panel-card.js';
+/**
+ * The card's size, in the slot every sibling puts its count badge.
+ *
+ * A plan's size is a fraction, so it is stated twice — the dial for the
+ * glance, the figures for the answer. That is the same redundancy the ring
+ * itself is built on (ticks are exact but need counting, the pie is instant
+ * but coarse), carried one level up.
+ *
+ * `size-4` matches the rail the steps below use, so the header's dial and the
+ * list's status glyphs are one drawing at one size. `tabular-nums` keeps
+ * "3 of 6" from reflowing into "10 of 12" as the agent advances.
+ */
+function PlanProgress({ done, total, running }) {
+    const tI18nComplete = useTranslations('hardcodedUi.i18nComplete');
+    return (_jsxs("span", { className: "flex items-center gap-1.5", children: [_jsx(PlanRing, { done: done, total: total, running: running, className: "size-4 shrink-0" }), _jsxs("span", { className: "text-muted-foreground text-xs tabular-nums", children: [done, " ", tI18nComplete.raw('text28391d3bc64e'), " ", total] })] }));
+}
+/**
+ * The rows the card lists — the plan minus the row its subtitle already heads.
+ *
+ * `planListTodos` drops the running step because the header is showing it, and
+ * printing the same sentence twice was the reason that filter exists. But a
+ * ONE-step plan filters to nothing, and a chevron that rewards a click with an
+ * empty box is a worse lie than a line repeated. Fall back to the whole list
+ * in exactly that case — which is exactly the case where "twice" costs a
+ * single row.
+ *
+ * Pure, so both branches are testable without mounting anything.
+ */
+export function planPanelRows(todos) {
+    // Keyed first, filtered second — see `planListTodos`: keying first is what
+    // keeps React's row state attached as the agent advances past a step.
+    const keyed = keyTodos(todos);
+    const listed = planListTodos(keyed);
+    return listed.length > 0 ? listed : keyed;
+}
+export function PlanPanelCard({ sessionId }) {
+    const tI18nComplete = useTranslations('hardcodedUi.i18nComplete');
+    const { data } = useRuntimeSessionTodo(sessionId);
+    const todos = useMemo(() => parseTodos(data), [data]);
+    const rows = useMemo(() => planPanelRows(todos), [todos]);
+    const { done, total, current, label, complete } = planSummary(todos);
+    // No plan, no card — the same rule the chat surface has always used.
+    //
+    // Outputs and Context earn their permanent empty "promise" state because
+    // almost every session fills them. Plenty of sessions never call
+    // `todowrite`, so an always-mounted Plan row would be a title bar that stays
+    // inert for the whole session: a filler widget. The column already has a
+    // conditional card (Preview) to follow instead.
+    if (total === 0)
+        return null;
+    return (_jsx(PanelCard, { title: tI18nComplete.raw('textfa8ed0bdabdd'), 
+        // Never the promise state — the card does not exist without a plan.
+        isEmpty: false, 
+        // No `count`. `indicator` stands in its slot with the fraction, which is
+        // what "how big is this card" means for a plan.
+        indicator: _jsx(PlanProgress, { done: done, total: total, running: Boolean(current) }), 
+        // The live step, always visible — the panel's one advantage over the
+        // transcript is that it does not scroll away, and this is the line that
+        // makes that worth something. Undefined before the plan starts is
+        // deliberate: the dial and "0 of 6" already say so, and a filler line
+        // would only make the header taller (see `planSummary`).
+        subtitle: label ? (_jsx("span", { className: cn(
+            // `block`, not a bare span: `truncate` needs a block box to
+            // clip against, and the header column already caps the width.
+            'block truncate text-xs', complete ? 'text-muted-foreground' : 'text-foreground/70'), children: label })) : undefined, 
+        // `px-3.5` matches the header's own inset, so a step's glyph sits on the
+        // same left edge as the title above it.
+        contentClassName: "border-border border-t px-3.5 py-3", defaultExpanded: true, children: _jsx(PlanSteps, { rows: rows }) }));
+}

package/dist/session/panel/easy/preview-load.d.ts

@@ -0,0 +1,193 @@
+import type { PreviewPortProbe } from '@kortix/sdk';
+/**
+ * Whether `AppPreview`'s port watch should be armed — the fix for the false
+ * positive where a healthy app got declared dead. The iframe has no `src` (and
+ * therefore no way to ever fire `onLoad`/`onError`) until the auth-token fetch
+ * resolves; arming the clock before then just counts down the fetch itself, so
+ * a slow token (not a slow app) trips the error. Requiring `hasPreview` —
+ * `previewUrl` gone non-null — means the watch starts only once the iframe
+ * actually has something to load.
+ */
+export declare function shouldArmLoadTimeout(input: {
+    isLoading: boolean;
+    noApp: boolean;
+    hasPreview: boolean;
+}): boolean;
+/**
+ * `AppPreview`'s load/error state after an iframe `onLoad` fires — the fix
+ * for a late success leaving the "Couldn't load" card over a working app.
+ *
+ * The `shouldArmLoadTimeout` deadline reaches its "couldn't load" verdict on
+ * SILENCE: no `onLoad`/`onError` within 5s. That verdict is a guess, not
+ * proof, and the error card it sets is `absolute inset-0 z-10` — sitting on
+ * top of the iframe. An `onLoad` that fires after the guess was made is
+ * positive evidence the guess was wrong, so it must retract `hasError` too,
+ * not just clear the spinner — otherwise the card keeps covering a loaded,
+ * working app until a manual Retry. `onError` is untouched by this: a real
+ * error event is its own positive evidence of failure, so it still sets
+ * `hasError` on its own.
+ */
+export declare function previewLoadSuccessState(): {
+    isLoading: boolean;
+    hasError: boolean;
+};
+/**
+ * What the runtime poll currently knows about the session's sandbox — three
+ * values, because "not alive" and "dead" are different states and only one of
+ * them is evidence.
+ *
+ * `useRuntimeConnectionStore` starts every session at
+ * `status: 'connecting', healthy: null`, so a boolean "alive" is FALSE for the
+ * entire boot. `AppPreview` already computes that boolean and uses it to pick
+ * the error wording; using the same boolean to decide whether an error
+ * happened would fail every preview at mount.
+ *
+ * `unreachable` is the only value that means dead, and it is not a single
+ * missed probe: `useRuntimeReconnect` only writes it after its own failure
+ * threshold (`FAIL_THRESHOLD_RECONNECT` / `FAIL_THRESHOLD_FIRST`), or on an
+ * HTTP status that says outright that nothing is home. By the time the store
+ * says `unreachable`, the sandbox has already been probed and re-probed.
+ *
+ * `initialCheckDone` gates `dead` for a reason that is easy to miss: the store
+ * is a process-wide singleton with no per-session key, so opening a preview
+ * carries whatever verdict the PREVIOUSLY viewed session left behind until the
+ * poll's first check lands. Without this gate a stale `unreachable` flashes the
+ * error card at mount on a perfectly healthy sandbox. `alive` needs no such
+ * gate: it can only be reached by a check that has already resolved.
+ */
+export type SandboxHealth = 'alive' | 'dead' | 'unknown';
+export declare function runtimeSandboxHealth(runtime: {
+    status: 'connecting' | 'connected' | 'unreachable';
+    healthy: boolean | null;
+    /** Whether the runtime poll has completed a check for THIS mount. */
+    initialCheckDone: boolean;
+}): SandboxHealth;
+/** How often `AppPreview` re-probes the port while it waits, ms.
+ *
+ *  Sized against the port-BIND race, which is the only thing a faster or slower
+ *  cadence changes: the agent starts a dev server and the preview opens before
+ *  the process has bound its socket. Two seconds means the continuity window
+ *  below rests on five samples rather than one, and the loop that spends them
+ *  is short-lived — see {@link shouldKeepProbingPort}. */
+export declare const PREVIEW_PROBE_INTERVAL_MS = 2000;
+/** How long the port must be CONTINUOUSLY unreachable before that counts as a
+ *  failure, ms.
+ *
+ *  A single 502 is the proxy saying "nothing answered right now", which is the
+ *  normal state of a port for the first moments after the agent starts a
+ *  server. Ten seconds is five consecutive misses at
+ *  {@link PREVIEW_PROBE_INTERVAL_MS} — the same count `useRuntimeReconnect`
+ *  requires (`FAIL_THRESHOLD_FIRST = 5`) before it will call a never-yet-seen
+ *  endpoint unreachable, so the product has one answer to "how many misses
+ *  mean it is really not there". Any answering probe resets it. */
+export declare const PREVIEW_UNREACHABLE_WINDOW_MS = 10000;
+/** The hard ceiling on waiting, ms — reached only when NO probe ever produced
+ *  a verdict (blocked by CORS, an expired preview cookie, an offline browser)
+ *  and the frame never fired `onLoad`.
+ *
+ *  It has to clear the slowest legitimate cold start or it re-creates the exact
+ *  bug this replaced, just at a bigger number: `CLAUDE.md` records 30-60s for a
+ *  first hit on a cold Next.js route. 90s is that documented worst case plus a
+ *  50% margin. It is a last resort, not the normal path — with a working probe
+ *  a dead port resolves in ~{@link PREVIEW_UNREACHABLE_WINDOW_MS}. */
+export declare const PREVIEW_MAX_WAIT_MS = 90000;
+/** One probe's verdict about the port. Aliased from the SDK's own type rather
+ *  than restated, so the two can never drift apart. */
+export type PreviewProbe = PreviewPortProbe;
+/**
+ * Whether `AppPreview` should keep waiting or show "Couldn't load".
+ *
+ * The bug this replaces: the verdict came from a stopwatch. Five seconds of
+ * iframe silence WAS the failure, and iframe silence is not evidence of
+ * anything — a cold dev-server compile is routinely 30-60s (`CLAUDE.md`), so
+ * healthy apps were being declared dead mid-build. `sandboxAlive` was computed
+ * right next to it and used only to pick the error's wording, never to decide
+ * whether there was an error at all.
+ *
+ * Now the verdict needs evidence, in this order:
+ *
+ * 1. **The sandbox is known dead.** The runtime poll has already probed,
+ *    re-probed and given up. Nothing behind this port can be reachable, and
+ *    `AppPreview`'s copy has the stopped-workspace wording for exactly this.
+ * 2. **The port has been continuously unreachable for the whole window.** The
+ *    proxy answers `502/503/504` itself when it cannot open a connection, so
+ *    this is the port saying nothing is listening — repeatedly, over
+ *    {@link PREVIEW_UNREACHABLE_WINDOW_MS}, with any single answer resetting it.
+ * 3. **The bound.** Everything else keeps waiting until
+ *    {@link PREVIEW_MAX_WAIT_MS}, then fails anyway. "Wait forever when unsure"
+ *    would trade a false error for a permanent spinner, and a permanent spinner
+ *    has no Retry and no "Send to agent".
+ *
+ * Anything short of that waits. `unknown` — a CORS refusal, an expired preview
+ * cookie, a probe that outran its own timeout — is explicitly not evidence and
+ * can never, on its own, fail a preview. That is `browser-panel.tsx`'s
+ * precedent: when readiness is unknown it keeps waiting rather than asserting
+ * a failure it cannot support.
+ */
+export declare function previewLoadVerdict(input: {
+    /** What the runtime poll knows about the sandbox — see {@link runtimeSandboxHealth}. */
+    sandbox: SandboxHealth;
+    /** The most recent probe's verdict. */
+    probe: PreviewProbe;
+    /** How long the port has been CONTINUOUSLY unreachable, ms. Zero whenever the
+     *  last probe was anything other than `unreachable`. */
+    unreachableForMs: number;
+    /** How long the iframe has had a `src` without firing `onLoad`/`onError`, ms. */
+    waitedMs: number;
+}): 'wait' | 'failed';
+/**
+ * The one sentence under "Couldn't load <app>".
+ *
+ * Reads the SAME three-state health {@link previewLoadVerdict} weighs, and for
+ * the same reason: `unknown` is not evidence. Two of the three failure paths —
+ * the continuously-unreachable streak and the {@link PREVIEW_MAX_WAIT_MS}
+ * ceiling — fire while health is perfectly well `unknown` (the runtime store
+ * still `connecting`, or `connected` with `healthy === null`). Deciding this
+ * copy on `health !== 'alive'` therefore told those users their workspace had
+ * stopped when nothing had established that. Only `dead` — a settled
+ * `unreachable` verdict from the runtime poll — earns the stopped wording.
+ */
+export declare function previewErrorReason(input: {
+    sandbox: SandboxHealth;
+    port: number;
+}): string;
+/**
+ * Whether the watch should probe the port again.
+ *
+ * Probing is not free: every probe is a real request against the user's own
+ * app, and a cold dev server answers a request by COMPILING. Polling one for
+ * the whole {@link PREVIEW_MAX_WAIT_MS} would queue dozens of compiles behind
+ * the page the user is actually waiting for — this feature would become a
+ * cause of the slowness it exists to tolerate.
+ *
+ * It also buys nothing. The probe's whole job is the fast negative: the proxy
+ * answers `502/503/504` itself, without an upstream connection, when nothing is
+ * listening. That answer arrives immediately or not at all. So:
+ *
+ * - a port that ANSWERED has settled the only question a probe can settle;
+ * - a MISS must always be probed on from — the streak either reaches
+ *   {@link PREVIEW_UNREACHABLE_WINDOW_MS} (a failure verdict) or is broken by
+ *   an answer, and neither can happen without another sample. This outranks
+ *   the elapsed check, which is why the loop is bounded at roughly twice the
+ *   window rather than exactly once;
+ * - past the window with nothing missing, the probe has had every chance to
+ *   see a dead port and did not. It will not start now. The remaining wait
+ *   belongs to the iframe and to {@link PREVIEW_MAX_WAIT_MS}.
+ *
+ * The miss test is the probe VERDICT, not `unreachableForMs`. Elapsed streak
+ * time cannot stand in for it: the caller starts a streak and reads its
+ * elapsed time in the same tick, so the sample that BEGINS a streak always
+ * carries `unreachableForMs: 0`. Keying on time therefore failed to protect
+ * the one sample the rule exists for — a first miss landing at or after the
+ * window stopped the loop after a single sample, and the failure verdict it
+ * was heading for was never reached. `unreachableForMs` stays in the signature
+ * because it is what {@link previewLoadVerdict} weighs; it just is not what
+ * decides whether to look again.
+ */
+export declare function shouldKeepProbingPort(input: {
+    probe: PreviewProbe;
+    /** How long the port has been continuously unreachable, ms. */
+    unreachableForMs: number;
+    /** How long the watch has been probing, ms. */
+    watchedMs: number;
+}): boolean;

package/dist/session/panel/easy/preview-load.js

@@ -0,0 +1,165 @@
+/**
+ * Whether `AppPreview`'s port watch should be armed — the fix for the false
+ * positive where a healthy app got declared dead. The iframe has no `src` (and
+ * therefore no way to ever fire `onLoad`/`onError`) until the auth-token fetch
+ * resolves; arming the clock before then just counts down the fetch itself, so
+ * a slow token (not a slow app) trips the error. Requiring `hasPreview` —
+ * `previewUrl` gone non-null — means the watch starts only once the iframe
+ * actually has something to load.
+ */
+export function shouldArmLoadTimeout(input) {
+    return input.isLoading && !input.noApp && input.hasPreview;
+}
+/**
+ * `AppPreview`'s load/error state after an iframe `onLoad` fires — the fix
+ * for a late success leaving the "Couldn't load" card over a working app.
+ *
+ * The `shouldArmLoadTimeout` deadline reaches its "couldn't load" verdict on
+ * SILENCE: no `onLoad`/`onError` within 5s. That verdict is a guess, not
+ * proof, and the error card it sets is `absolute inset-0 z-10` — sitting on
+ * top of the iframe. An `onLoad` that fires after the guess was made is
+ * positive evidence the guess was wrong, so it must retract `hasError` too,
+ * not just clear the spinner — otherwise the card keeps covering a loaded,
+ * working app until a manual Retry. `onError` is untouched by this: a real
+ * error event is its own positive evidence of failure, so it still sets
+ * `hasError` on its own.
+ */
+export function previewLoadSuccessState() {
+    return { isLoading: false, hasError: false };
+}
+export function runtimeSandboxHealth(runtime) {
+    if (runtime.status === 'unreachable')
+        return runtime.initialCheckDone ? 'dead' : 'unknown';
+    if (runtime.status === 'connected' && runtime.healthy === true)
+        return 'alive';
+    return 'unknown';
+}
+/** How often `AppPreview` re-probes the port while it waits, ms.
+ *
+ *  Sized against the port-BIND race, which is the only thing a faster or slower
+ *  cadence changes: the agent starts a dev server and the preview opens before
+ *  the process has bound its socket. Two seconds means the continuity window
+ *  below rests on five samples rather than one, and the loop that spends them
+ *  is short-lived — see {@link shouldKeepProbingPort}. */
+export const PREVIEW_PROBE_INTERVAL_MS = 2_000;
+/** How long the port must be CONTINUOUSLY unreachable before that counts as a
+ *  failure, ms.
+ *
+ *  A single 502 is the proxy saying "nothing answered right now", which is the
+ *  normal state of a port for the first moments after the agent starts a
+ *  server. Ten seconds is five consecutive misses at
+ *  {@link PREVIEW_PROBE_INTERVAL_MS} — the same count `useRuntimeReconnect`
+ *  requires (`FAIL_THRESHOLD_FIRST = 5`) before it will call a never-yet-seen
+ *  endpoint unreachable, so the product has one answer to "how many misses
+ *  mean it is really not there". Any answering probe resets it. */
+export const PREVIEW_UNREACHABLE_WINDOW_MS = 10_000;
+/** The hard ceiling on waiting, ms — reached only when NO probe ever produced
+ *  a verdict (blocked by CORS, an expired preview cookie, an offline browser)
+ *  and the frame never fired `onLoad`.
+ *
+ *  It has to clear the slowest legitimate cold start or it re-creates the exact
+ *  bug this replaced, just at a bigger number: `CLAUDE.md` records 30-60s for a
+ *  first hit on a cold Next.js route. 90s is that documented worst case plus a
+ *  50% margin. It is a last resort, not the normal path — with a working probe
+ *  a dead port resolves in ~{@link PREVIEW_UNREACHABLE_WINDOW_MS}. */
+export const PREVIEW_MAX_WAIT_MS = 90_000;
+/**
+ * Whether `AppPreview` should keep waiting or show "Couldn't load".
+ *
+ * The bug this replaces: the verdict came from a stopwatch. Five seconds of
+ * iframe silence WAS the failure, and iframe silence is not evidence of
+ * anything — a cold dev-server compile is routinely 30-60s (`CLAUDE.md`), so
+ * healthy apps were being declared dead mid-build. `sandboxAlive` was computed
+ * right next to it and used only to pick the error's wording, never to decide
+ * whether there was an error at all.
+ *
+ * Now the verdict needs evidence, in this order:
+ *
+ * 1. **The sandbox is known dead.** The runtime poll has already probed,
+ *    re-probed and given up. Nothing behind this port can be reachable, and
+ *    `AppPreview`'s copy has the stopped-workspace wording for exactly this.
+ * 2. **The port has been continuously unreachable for the whole window.** The
+ *    proxy answers `502/503/504` itself when it cannot open a connection, so
+ *    this is the port saying nothing is listening — repeatedly, over
+ *    {@link PREVIEW_UNREACHABLE_WINDOW_MS}, with any single answer resetting it.
+ * 3. **The bound.** Everything else keeps waiting until
+ *    {@link PREVIEW_MAX_WAIT_MS}, then fails anyway. "Wait forever when unsure"
+ *    would trade a false error for a permanent spinner, and a permanent spinner
+ *    has no Retry and no "Send to agent".
+ *
+ * Anything short of that waits. `unknown` — a CORS refusal, an expired preview
+ * cookie, a probe that outran its own timeout — is explicitly not evidence and
+ * can never, on its own, fail a preview. That is `browser-panel.tsx`'s
+ * precedent: when readiness is unknown it keeps waiting rather than asserting
+ * a failure it cannot support.
+ */
+export function previewLoadVerdict(input) {
+    if (input.sandbox === 'dead')
+        return 'failed';
+    if (input.probe === 'unreachable' && input.unreachableForMs >= PREVIEW_UNREACHABLE_WINDOW_MS) {
+        return 'failed';
+    }
+    if (input.waitedMs >= PREVIEW_MAX_WAIT_MS)
+        return 'failed';
+    return 'wait';
+}
+/**
+ * The one sentence under "Couldn't load <app>".
+ *
+ * Reads the SAME three-state health {@link previewLoadVerdict} weighs, and for
+ * the same reason: `unknown` is not evidence. Two of the three failure paths —
+ * the continuously-unreachable streak and the {@link PREVIEW_MAX_WAIT_MS}
+ * ceiling — fire while health is perfectly well `unknown` (the runtime store
+ * still `connecting`, or `connected` with `healthy === null`). Deciding this
+ * copy on `health !== 'alive'` therefore told those users their workspace had
+ * stopped when nothing had established that. Only `dead` — a settled
+ * `unreachable` verdict from the runtime poll — earns the stopped wording.
+ */
+export function previewErrorReason(input) {
+    if (input.sandbox === 'dead') {
+        return 'This workspace has stopped, so the app isn’t reachable anymore.';
+    }
+    if (input.port > 0)
+        return `The app on port ${input.port} may not be running yet.`;
+    return 'The app may not be running yet.';
+}
+/**
+ * Whether the watch should probe the port again.
+ *
+ * Probing is not free: every probe is a real request against the user's own
+ * app, and a cold dev server answers a request by COMPILING. Polling one for
+ * the whole {@link PREVIEW_MAX_WAIT_MS} would queue dozens of compiles behind
+ * the page the user is actually waiting for — this feature would become a
+ * cause of the slowness it exists to tolerate.
+ *
+ * It also buys nothing. The probe's whole job is the fast negative: the proxy
+ * answers `502/503/504` itself, without an upstream connection, when nothing is
+ * listening. That answer arrives immediately or not at all. So:
+ *
+ * - a port that ANSWERED has settled the only question a probe can settle;
+ * - a MISS must always be probed on from — the streak either reaches
+ *   {@link PREVIEW_UNREACHABLE_WINDOW_MS} (a failure verdict) or is broken by
+ *   an answer, and neither can happen without another sample. This outranks
+ *   the elapsed check, which is why the loop is bounded at roughly twice the
+ *   window rather than exactly once;
+ * - past the window with nothing missing, the probe has had every chance to
+ *   see a dead port and did not. It will not start now. The remaining wait
+ *   belongs to the iframe and to {@link PREVIEW_MAX_WAIT_MS}.
+ *
+ * The miss test is the probe VERDICT, not `unreachableForMs`. Elapsed streak
+ * time cannot stand in for it: the caller starts a streak and reads its
+ * elapsed time in the same tick, so the sample that BEGINS a streak always
+ * carries `unreachableForMs: 0`. Keying on time therefore failed to protect
+ * the one sample the rule exists for — a first miss landing at or after the
+ * window stopped the loop after a single sample, and the failure verdict it
+ * was heading for was never reached. `unreachableForMs` stays in the signature
+ * because it is what {@link previewLoadVerdict} weighs; it just is not what
+ * decides whether to look again.
+ */
+export function shouldKeepProbingPort(input) {
+    if (input.probe === 'reachable')
+        return false;
+    if (input.probe === 'unreachable')
+        return true;
+    return input.watchedMs < PREVIEW_UNREACHABLE_WINDOW_MS;
+}

package/dist/session/panel/easy/step-detail-body.d.ts

@@ -0,0 +1,24 @@
+/**
+ * A step's tool calls with the chronology bar under them — Marko's ask: arrow
+ * keys from start to end of a run, with the wall-clock time of whatever you are
+ * looking at.
+ *
+ * Index and follow-mode live here rather than in the panel provider because
+ * they are scoped to one open detail: closing it and opening another must start
+ * at the latest action again, and local state gives that for free by
+ * unmounting.
+ *
+ * Its own file (rather than sitting in `easy-panel.tsx`) because the detail it
+ * renders is opened from the provider, which mounts above both panel surfaces —
+ * importing it back out of the cards component would be a cycle.
+ */
+import type { ToolCallBlock } from '@kortix/sdk';
+export declare function StepDetailBody({ calls, sessionId, 
+/** The call the user actually clicked in the chat. A step is a GROUP ("Ran
+ *  13 commands"), so without this the detail always opened on the last call
+ *  in live mode — clicking the 4th command showed the 13th. */
+focusCallId, }: {
+    calls: ToolCallBlock[];
+    sessionId: string;
+    focusCallId?: string;
+}): import("react").JSX.Element;

package/dist/session/panel/easy/step-detail-body.js

@@ -0,0 +1,33 @@
+'use client';
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import { useCallback, useEffect, useState } from 'react';
+import { ActionNavigator } from '../shared/action-navigator.js';
+import { clampIndex } from '../shared/action-navigator-logic.js';
+import { ToolParts } from './detail-view.js';
+import { focusIndexForCall } from './easy-panel-logic.js';
+export function StepDetailBody({ calls, sessionId, 
+/** The call the user actually clicked in the chat. A step is a GROUP ("Ran
+ *  13 commands"), so without this the detail always opened on the last call
+ *  in live mode — clicking the 4th command showed the 13th. */
+focusCallId, }) {
+    const focusIndex = focusIndexForCall(calls, focusCallId);
+    const [index, setIndex] = useState(focusIndex >= 0 ? focusIndex : calls.length - 1);
+    // Arriving from a chat click pins the view to that call; 'live' would drag
+    // it straight back to the newest part on the next streaming update.
+    const [mode, setMode] = useState(focusIndex >= 0 ? 'manual' : 'live');
+    useEffect(() => {
+        if (calls.length === 0)
+            return;
+        setIndex((i) => (mode === 'live' ? calls.length - 1 : clampIndex(i, calls.length)));
+    }, [calls.length, mode]);
+    const safeIndex = clampIndex(index, calls.length);
+    const current = calls[safeIndex];
+    const atLatest = safeIndex >= calls.length - 1;
+    // Stable identity so ActionNavigator's keydown effect doesn't re-subscribe
+    // on every streaming re-render; setState setters are already stable.
+    const handleIndexChange = useCallback((i, m) => {
+        setMode(m);
+        setIndex(i);
+    }, []);
+    return (_jsxs("div", { className: "flex h-full min-h-0 flex-col", children: [_jsx("div", { className: "min-h-0 flex-1 overflow-auto", children: current && _jsx(ToolParts, { calls: [current], sessionId: sessionId }) }), _jsx(ActionNavigator, { calls: calls, index: safeIndex, isLive: atLatest && mode === 'live', onIndexChange: handleIndexChange })] }));
+}

package/dist/session/panel/easy/step-icon.d.ts

@@ -0,0 +1,6 @@
+import type { Step } from '@kortix/sdk';
+import type { StepFamily } from '@kortix/sdk';
+export declare function StepIcon({ family, status }: {
+    family: StepFamily;
+    status: Step['status'];
+}): import("react").JSX.Element;

package/dist/session/panel/easy/step-icon.js

@@ -0,0 +1,44 @@
+'use client';
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+/**
+ * `StepIcon` — the glyph at the head of a Progress row.
+ *
+ * A row used to lead with an anonymous status dot, which told you a step had
+ * *happened* but never what KIND of thing it was. The icon says the kind at a
+ * glance (and matches how the Context card leads its rows), while colour still
+ * carries the state: muted when done, red when it failed, and the running step
+ * keeps its live pulse — the one case where "is it moving?" matters more than
+ * "what is it?".
+ */
+import { cn } from '../../../lib/utils.js';
+import { ArchiveIcon as Archive, RobotIcon as Bot, BrainIcon as Brain, CodeIcon as Code, QuestionIcon as CircleHelp, NotePencilIcon as FilePen, FolderOpenIcon as FolderOpen, GlobeIcon as Globe, ClockCounterClockwiseIcon as History, ListChecksIcon as ListChecks, PlugIcon as Plug, MagnifyingGlassIcon as Search, SparkleIcon as Sparkles, TerminalIcon as Terminal, MagicWandIcon as Wand2, WrenchIcon as Wrench, LightningIcon as Zap, } from '@phosphor-icons/react';
+const FAMILY_ICON = {
+    explore: Search,
+    edit: FilePen,
+    run: Terminal,
+    // pi's codemode: a script the model wrote that calls the other tools. Code,
+    // not the run family's Terminal — the card renders source, not a shell.
+    script: Code,
+    web: Globe,
+    create: Sparkles,
+    plan: ListChecks,
+    delegate: Bot,
+    sessions: History,
+    memory: Brain,
+    connectors: Plug,
+    automations: Zap,
+    projects: FolderOpen,
+    skills: Wand2,
+    ask: CircleHelp,
+    retired: Archive,
+    other: Wrench,
+};
+export function StepIcon({ family, status }) {
+    const Glyph = FAMILY_ICON[family] ?? Wrench;
+    // A running step is the one thing the eye must find without reading. Keep the
+    // pulse it had as a dot, now wrapped around the glyph itself.
+    if (status === 'running') {
+        return (_jsxs("span", { className: "relative flex size-4 shrink-0 items-center justify-center", children: [_jsx("span", { className: "bg-kortix-green/25 absolute inline-flex size-4 animate-ping rounded-full motion-reduce:animate-none" }), _jsx(Glyph, { className: "text-kortix-green relative size-4" })] }));
+    }
+    return (_jsx(Glyph, { className: cn('size-4 shrink-0', status === 'error' ? 'text-kortix-red' : 'text-muted-foreground') }));
+}

package/dist/session/panel/index.d.ts

@@ -0,0 +1,17 @@
+/**
+ * @kortix/ui/session-panel — The session side panel: its provider (the thread reads it to
+ * open a view), the panel bodies, files, changes and audit views, and the run read models.
+ */
+export { ActionPanel } from './action-panel.js';
+export { AdvancedPanel } from './advanced/advanced-panel.js';
+export { DiffDialog } from './diff-dialog.js';
+export { EasyPanel } from './easy/easy-panel.js';
+export { openSessionQuickView } from './open-session-quick-view.js';
+export { SessionAuditPanel as SessionAudit } from './session-audit-panel.js';
+export { useSessionAudit } from './session-audit-shared.js';
+export { SessionFilesExplorer as SessionFiles } from './session-files-explorer.js';
+export { SessionFilesPanel as SessionChanges } from './session-files-panel.js';
+export { SessionPanelContext, SessionPanelProvider, useOptionalSessionPanel, type SessionPanelValue, } from './session-panel-provider.js';
+export { collectAllToolCalls } from './shared/collect-tool-parts.js';
+export { latestRunMessages } from './shared/latest-run.js';
+export { deriveRunOutcome } from './shared/run-outcome.js';

package/dist/session/panel/index.js

@@ -0,0 +1,17 @@
+/**
+ * @kortix/ui/session-panel — The session side panel: its provider (the thread reads it to
+ * open a view), the panel bodies, files, changes and audit views, and the run read models.
+ */
+export { ActionPanel } from './action-panel.js';
+export { AdvancedPanel } from './advanced/advanced-panel.js';
+export { DiffDialog } from './diff-dialog.js';
+export { EasyPanel } from './easy/easy-panel.js';
+export { openSessionQuickView } from './open-session-quick-view.js';
+export { SessionAuditPanel as SessionAudit } from './session-audit-panel.js';
+export { useSessionAudit } from './session-audit-shared.js';
+export { SessionFilesExplorer as SessionFiles } from './session-files-explorer.js';
+export { SessionFilesPanel as SessionChanges } from './session-files-panel.js';
+export { SessionPanelContext, SessionPanelProvider, useOptionalSessionPanel, } from './session-panel-provider.js';
+export { collectAllToolCalls } from './shared/collect-tool-parts.js';
+export { latestRunMessages } from './shared/latest-run.js';
+export { deriveRunOutcome } from './shared/run-outcome.js';

package/dist/session/panel/mobile-tool-drawer.d.ts

@@ -0,0 +1,5 @@
+export declare function MobileToolDrawer({ sessionId, projectId, projectSessionId, }: {
+    sessionId: string;
+    projectId?: string;
+    projectSessionId?: string;
+}): import("react").JSX.Element;