/**
 * Journey state classifier — derives canonical-step transitions from the
 * agent's tool calls instead of from free-form `TodoWrite` text.
 *
 * The 5-step journey rendered in the TUI (see `canonical-tasks.ts`) was
 * historically driven by the agent's `TodoWrite` output. That coupling
 * was brittle: the LLM drifted on long runs, renamed steps on retry,
 * and occasionally regressed completed steps when re-emitting stale
 * state after an HTTP 400/429. This classifier replaces text-parsing
 * with a deterministic derivation: each step transitions on a specific
 * tool call (or pattern of tool calls) the agent must make to do its
 * job. PRs #474 (structured `fileWrites` instead of regex over
 * `statusMessages`), #479 (`record_dashboard` as the dashboard
 * completion signal), and #480 (`tool_use` observation drives the
 * dashboard pill) established this pattern; this module finishes it
 * for the journey stepper.
 *
 * The function is pure — no I/O, no store reference. Wire-up happens
 * in `agent-interface.ts` (`PreToolUse` / `PostToolUse` hook
 * composers) and dispatches into `WizardStore.applyJourneyTransition`.
 */
import type { CanonicalStep } from './canonical-tasks.js';
export type JourneyStepId = CanonicalStep['id'];
export type JourneyStatus = 'in_progress' | 'completed';
export interface JourneyTransition {
    stepId: JourneyStepId;
    status: JourneyStatus;
}
export interface ClassifyToolEventInput {
    /** SDK hook phase: `pre` for PreToolUse, `post` for PostToolUse. */
    phase: 'pre' | 'post';
    /** Tool name as the SDK reports it (e.g. `'mcp__wizard-tools__confirm_event_plan'`, `'Bash'`, `'Edit'`). */
    toolName: string;
    /** Tool input (`tool_input` field on the SDK hook payload). Shape varies by tool. */
    toolInput: unknown;
    /**
     * Tool result (`tool_response` / `tool_result` field on the SDK PostToolUse payload).
     * `null` for `pre` events.
     */
    toolResult?: unknown;
    /**
     * Per-step status as currently derived. Used to gate triggers that
     * depend on prior steps having advanced (e.g. `wire` only enters
     * `in_progress` once `plan` is `completed`).
     *
     * Keyed by step id; missing keys treated as not-yet-started.
     */
    prevDerived?: Partial<Record<JourneyStepId, JourneyStatus>>;
}
/**
 * Classify a single SDK tool event into a journey transition.
 *
 * Returns `null` when the event isn't load-bearing for any step — most
 * tool calls fall through to `null` so the caller can treat the
 * function output as "advance the journey if non-null."
 *
 * Steps and their triggers:
 *
 *   1. **detect** — `mcp__wizard-tools__detect_package_manager`
 *      Pre → in_progress, Post → completed.
 *   2. **install** — Bash command running an Amplitude package install
 *      (e.g. `pnpm add @amplitude/unified`, `pip install amplitude-analytics`).
 *      Pre → in_progress.
 *   3. **plan** — `mcp__wizard-tools__confirm_event_plan`
 *      Pre → in_progress, Post → completed (regardless of approval —
 *      the call returning means the agent finished the planning step;
 *      the user's verdict on the plan is orthogonal).
 *   4. **wire** — any Edit/Write tool firing AFTER plan has completed.
 *      Pre → in_progress. (No explicit completion signal — the
 *      sequential-ordering invariant in `applyJourneyTransition` rolls
 *      it up to `completed` when step 5 starts.)
 *   5. **dashboard** — Amplitude MCP `create_chart` / `create_dashboard` /
 *      `update_chart` / `update_dashboard` tools (in_progress) and
 *      `mcp__wizard-tools__record_dashboard` (Post → completed).
 *
 * Ordering is sequential — when step N's trigger fires, the renderer
 * marks steps 1..N-1 completed automatically. So we only need to emit
 * the "frontmost" transition for each event; cascading is the store's
 * job.
 */
export declare function classifyToolEvent(input: ClassifyToolEventInput): JourneyTransition | null;
