import type { ChatState } from '../../../../../../packages/core/src/application/ports/output/services/interactive-session-service.interface.js';
import type { PlaceholderStep } from './workflow-placeholder.js';
export interface ChatTabProps {
    featureId: string;
    /**
     * When rendered inside an application page, passing the application
     * id lights up two application-scoped extras in the thread:
     *   1. Server-derived "user turn groups" — completed user turns
     *      collapse into named cards above the live messages so the
     *      thread stays compact.
     *   2. Publish / Deploy operation bubbles — chronological static
     *      info cards sourced from `operation_log_entries` and
     *      rendered after the live messages.
     * Omitting this prop keeps the old behaviour for non-application
     * chats (repo, global, etc.).
     */
    applicationId?: string;
    worktreePath?: string;
    /** Seed the agent override (e.g. from an Application's agentType) */
    initialAgent?: string;
    /** Seed the model override (e.g. from an Application's modelOverride) */
    initialModel?: string;
    /**
     * Optional SSR-loaded chat state — seeds the query cache so messages
     * already persisted server-side render on first paint without a fetch.
     */
    initialChatState?: ChatState;
    /**
     * When true, skip rendering the internal session-info/clear toolbar.
     * The hosting page is expected to surface this info elsewhere (e.g.
     * the ApplicationPage top bar). Lets left/right panes start flush
     * with the top bar — no mismatched inner toolbar heights.
     */
    hideHeader?: boolean;
    /**
     * Fires exactly once, the first time every step in the agent's
     * declared SHEP plan reaches `done` status. The host page uses
     * this to auto-run the dev-server preview once the workflow has
     * fully finished scaffolding the app.
     */
    onAllStepsComplete?: () => void;
    /**
     * When provided, the chat renders a STEP TRACKER-ONLY view:
     * the flat message thread is suppressed entirely and the
     * tracker sits in its place, showing these placeholder cards
     * until real `workflow_steps` rows arrive from the backend.
     *
     * ApplicationPage passes the 9 application-creation step titles
     * here so the user sees the full progress skeleton the instant
     * they land, instead of an empty area that pops in a beat
     * later.
     */
    workflowPlaceholder?: PlaceholderStep[];
    /** Called when the user clicks Continue on an interrupted workflow step. */
    onResumeWorkflow?: () => void;
    /**
     * When provided, injects a synthetic "Scaffolding" step card at the
     * top of the tracker so the user sees in-progress feedback during
     * the `BunShadcnScaffolder` phase (project-tree + `bun install`),
     * which happens BEFORE the agent turn and therefore has no real
     * `workflow_steps` row. See `workflow-placeholder.ts` for the
     * broader context.
     */
    scaffoldingState?: ScaffoldingState;
    /**
     * When truthy, renders a prominent error recovery banner above the
     * turn card + step tracker. Used to surface `effectiveStatus`
     * failures that would otherwise leave the user staring at a chat
     * with a red status pill and no explanation. The `onRetry` prop
     * wires a "Try again" button — typically `onResumeWorkflow`.
     */
    applicationError?: ApplicationErrorState | null;
}
/**
 * Frontend-synthesised state for the "Scaffolding" card. The card is
 * purely presentational — the scaffolder does not write a
 * `workflow_steps` row, so the caller derives this from the
 * Application entity and passes it in.
 */
export interface ScaffoldingState {
    /** Lifecycle of the scaffold phase. */
    status: 'running' | 'done' | 'failed';
    /** Milliseconds since epoch when scaffolding started. */
    startedAt: number;
    /** Milliseconds since epoch when scaffolding reached a terminal state. */
    finishedAt?: number;
    /** Optional short error message to render inside the card body. */
    error?: string;
}
export interface ApplicationErrorState {
    /** Short, human-readable kind: "Setup failed", "Interrupted", etc. */
    kind: string;
    /** Longer explanation shown below the headline. */
    message: string;
    /** True if the backend can re-run the failed pipeline. */
    retryable: boolean;
}
/**
 * Pure predicate: is the workflow ACTIVELY producing output right now?
 *
 * The composer is locked iff this returns true. We deliberately do NOT
 * key on "the plan is incomplete" (`hasPlan && !allDone`) — that
 * misclassifies a workflow with stale `pending` steps from a crashed
 * orchestrator (e.g. dev:web restarted mid-run, leaving the last few
 * steps stuck on `pending` forever) as in-flight, which leaves the chat
 * input permanently disabled even though no agent is doing anything.
 *
 * `running` is the only step status that proves work is actively
 * happening this instant. Pending / done / interrupted / failed all
 * mean "no agent is producing output right now → user may type."
 *
 * Exported for unit testing.
 */
export declare function isWorkflowInFlight(stepProgress: {
    hasPlan: boolean;
    steps: readonly {
        status: string;
    }[];
}): boolean;
export declare function ChatTab({ featureId, applicationId, worktreePath, initialAgent, initialModel, initialChatState, hideHeader, onAllStepsComplete, workflowPlaceholder, onResumeWorkflow, scaffoldingState, applicationError, }: ChatTabProps): import("react/jsx-runtime").JSX.Element;
//# sourceMappingURL=ChatTab.d.ts.map