/** Reading who holds a node mutex, straight off each run's own definition snapshot.
 *
 *  There is no lock table on purpose: a key is held for exactly as long as a node run
 *  carrying it is live, so a holder that crashed cannot leave a stale lock behind —
 *  the thing that represents the lock is the thing that died. What the runner does
 *  with the answer lives in node-mutex.ts; this file only reads.
 *
 *  Nothing here may reach the logger. The repository is imported before a test or a
 *  CLI has set `JINN_HOME`, and `logger.ts` resolves its log directory from it once,
 *  at import: pulling it into this graph would freeze the wrong home. */
import { z } from 'zod';
type WorkflowSqliteConnection = ConstructorParameters<typeof import('./repository.js').WorkflowRepository>[0];
declare const mutexNodeRunSchema: z.ZodObject<{
    workflowId: z.ZodString;
    runId: z.ZodString;
    nodeId: z.ZodString;
    mutexKey: z.ZodString;
    status: z.ZodEnum<{
        failed: "failed";
        running: "running";
        waiting: "waiting";
        completed: "completed";
        pending: "pending";
        cancelled: "cancelled";
        ready: "ready";
        dispatching: "dispatching";
        skipped: "skipped";
    }>;
}, z.core.$strict>;
/** An employee node run of a live run that authors a mutex key. `pending` is a node
 *  standing off the key; every other status here is a node live enough to hold it. */
export type WorkflowMutexNodeRun = z.infer<typeof mutexNodeRunSchema>;
export declare function readMutexNodeRuns(db: WorkflowSqliteConnection): WorkflowMutexNodeRun[];
export {};
//# sourceMappingURL=repository-mutex.d.ts.map