/**
 * Turning failures into something worth writing down.
 *
 * THE HARD PART IS NOT FINDING FAILURES, IT IS REFUSING MOST OF THEM. A tool call
 * that failed once taught the session that made it and nothing more; a rule written
 * from it is noise in an instructions file forever. So a pattern has to repeat
 * before it is reported, the report says how thin the evidence is, and two whole
 * categories are deliberately dropped:
 *
 *   - a failing test or build is the work, not a habit. Nobody needs to be told
 *     that their tests were red last week, and a rule saying so would be obeyed by
 *     not running them.
 *   - an uncategorised failure has no rule to write. It is counted and reported as
 *     uncategorised,
    unattributable, which is honest, instead of being folded into a neighbour to
 *     make the output look richer.
 */
import { AnalysisResult, ProjectInfo, SessionData, ToolCall } from './models.js';
/** Below this, a pattern is an anecdote. */
export declare const MIN_OCCURRENCES = 3;
/** At or above this many separate sessions, it is a habit rather than a bad day. */
export declare const ESTABLISHED_SESSIONS = 3;
/**
 * What a failure is ABOUT, as a key patterns can be counted against.
 *
 * The subject itself is too specific -- twelve missing files in one directory are
 * one fact about the directory, not twelve facts. The grouping per category is
 * therefore different on purpose: a path groups by its parent, a command groups by
 * the program being run, and a search pattern is its own group because a pattern
 * that never matches is the fact.
 */
export declare function groupKey(call: ToolCall): string;
/** The key a command line gets when it ran several commands and one of them failed. */
export declare const CHAINED = "(a chained command line)";
/** Analyse one project's sessions. */
export declare function analyse(agent: string, project: ProjectInfo, sessions: readonly SessionData[], unreadable?: readonly string[]): AnalysisResult;
//# sourceMappingURL=analyze.d.ts.map