/**
 * The one place a live execution describes itself, shared by both wires.
 *
 * An execution handle used to be an opaque UUID: `mma_run` returned `{ executionId }`, and
 * every poll answered with a phase name (`implementing` | `reviewing`) that reads the
 * same for a spec, a review and an investigation. The type was known from the moment of
 * admission — `ExecutionEntry.tool`, set by `ExecutionRegistry.register` — and was read on the way
 * out ONLY to decide whether to attach `totalTasks`. Identity was in hand and thrown away.
 *
 * `runningSnapshot` previously existed as two hand-maintained copies (mcp-adapter.ts and
 * http/handlers/unified-execution.ts). They drifted — MCP omitted `phaseElapsedMs` for a
 * while, so "one contract, two wires" was untrue in practice. Both wires now call these
 * functions, which is why identity cannot drift back apart.
 */
import type { ExecutionEntry } from '@zhixuan92/multi-model-agent-core';
/**
 * Who this execution is, independent of how far along it is. Carried on the admission
 * response AND on every poll: an agent scanning back through a transcript reads the
 * handle where it was returned, not where the execution was submitted.
 *
 * `cwd` earns its place on a multi-repo workspace, where four sibling checkouts run the
 * same task types and the path is the only thing distinguishing them.
 */
interface ExecutionIdentity {
    executionId: string;
    type: string;
    /** Present only for `audit`, matching the terminal envelope's `execution.subtype`. */
    subtype?: string;
    /** The resolved Method identifier (SPEC-005), matching the terminal envelope's
     *  `execution.method`. Unlike `subtype`, ALWAYS present as `string | null` —
     *  never omitted — because Method resolution applies uniformly across every task type,
     *  not to a type-specific subset. */
    method: string | null;
    cwd: string;
}
export declare function executionIdentity(entry: ExecutionEntry): ExecutionIdentity;
/**
 * Bucket a task's recorded activity into a fixed-length series the monitor can draw directly.
 *
 * Computed at READ time from timestamps, so every viewer of the same task sees the same shape
 * — including one that opened the panel late, or re-opened it after the run finished. The
 * panel used to accumulate this itself from the polls it happened to observe, which meant the
 * history died with the panel.
 *
 * `counts[i]` is how many provider events landed in bucket i; `phases[i]` is which act was
 * live. A zero count is real information — it is the worker being quiet, not missing data.
 */
export declare function bucketActivity(entry: ExecutionEntry | undefined, now?: number): {
    counts: number[];
    phases: Array<1 | 2>;
} | null;
/**
 * The running-progress payload both wires return for a non-terminal task: identity first, then how
 * far along it is.
 *
 * Optional fields stay ABSENT rather than null when they have no value — the execution monitor
 * renders a label only when its field is present, and a `null` would print an empty row that reads
 * as a failure to load.
 */
export declare function buildRunningSnapshot(entry: ExecutionEntry, now?: number): Record<string, unknown>;
export {};
//# sourceMappingURL=task-identity.d.ts.map