/**
 * Behavior step classifier — turns method-body walker output into a
 * structured candidate-step timeline that the analyse LLM can refine
 * into spec `behaviors[].steps[]` blocks. Implements Phase 2 of #27.
 *
 * The classifier is a "soft oracle" (per the
 * 2026-04-26-BEHAVIOR-EXTRACTION-FOR-ANALYSE.md proposal): it labels
 * what the patterns clearly say and falls through to `kind: 'call'` /
 * `kind: 'compute'` for unclassifiable lines. The LLM filters / merges /
 * refines the output into the final spec vocabulary.
 *
 * Why classification matters: pre-classifier the LLM sees raw method
 * bodies (200 lines, lots of boilerplate). With it, the LLM sees
 * "this method does {find, validate, create, emit, return}" — a
 * structured anchor it can map to spec language without inventing.
 *
 * Step kinds (the categorical vocabulary):
 *   - `find`       — read a record by key (`repo.findOne`, `findOneByField`)
 *   - `find-many`  — read a collection (`repo.find()`, `findAll()`)
 *   - `create`     — write a new record (`repo.save(create(...))`, `insertOne`)
 *   - `update`     — mutate an existing record (`repo.update`, `updateOneById`)
 *   - `delete`     — remove a record (`repo.delete`, `deleteOneById`)
 *   - `transition` — change a lifecycle state (assignment to enum-typed field)
 *   - `emit`       — publish an event (`eventBus.emit/publish/dispatch`)
 *   - `validate`   — precondition guard or throw outside a guard
 *   - `call`       — invoke a service method (not repo, not eventBus)
 *   - `return`     — explicit return (kept for completeness; the analyse
 *                    layer usually folds this into the behavior's
 *                    `returns:` declaration rather than a step)
 *
 * Open question (deferred to next phase): merging adjacent related
 * steps (`repo.create + repo.save` = one `create`). For now the
 * classifier emits both — the LLM can collapse.
 */
export type CandidateStepKind = 'find' | 'find-many' | 'create' | 'update' | 'delete' | 'transition' | 'emit' | 'validate' | 'call' | 'return';
export interface CandidateStep {
    /** Categorical kind — see header for vocabulary. */
    kind: CandidateStepKind;
    /** Source position within the method body (for ordering across kinds). */
    position: number;
    /** Human-readable single-line summary of the step (fed to the LLM). */
    summary: string;
    /** For `find` / `find-many` / `create` / `update` / `delete`. */
    entity?: string;
    /** For `find` — the field used to look up. */
    byField?: string;
    /** For `transition`. */
    transition?: {
        field: string;
        toState: string;
    };
    /** For `emit`. */
    event?: string;
    /** For `validate` — what the precondition asserts. */
    precondition?: string;
    /** For `call` — the receiver + method (`PaymentService.charge`). */
    callTarget?: string;
}
/**
 * Per-method classification result. The same shape `walkMethodBodies`
 * returns, plus the `candidates` field — useful for IDE-like contexts
 * that want both the raw facts AND the classified output.
 */
export interface MethodCandidates {
    methodName: string;
    isAsync: boolean;
    /** Raw body source — passed through from the walker for downstream
     *  cross-validation. */
    body: string;
    /** Source line range [startLine, endLine] (1-based, inclusive) within
     *  the file that was walked. Passed through from MethodBodyFacts. */
    sourceLineRange: [number, number];
    candidates: CandidateStep[];
}
/**
 * Walk a class body and return per-method candidate-step timelines.
 * Each method's candidates are ordered by source position so the
 * timeline reflects execution order.
 *
 * `lifecycleField` (optional) — when known, assignments to this field
 * are classified as `transition` rather than generic `call`/`update`.
 * Pass it from the lifecycle-detection pass (see
 * typescript-decorators.ts).
 */
export declare function extractCandidateSteps(classBody: string, options?: {
    lifecycleField?: string;
}): MethodCandidates[];
//# sourceMappingURL=behavior-step-classifier.d.ts.map