import type { VisualChangesetCommitPayload, VisualDiagnostic, VisualViewOperation, VisualViewSummary } from '../adapters/visual/protocol-contract.js';
import type { CanvasGraph } from '../graph-projection.js';
import type { YarramateOperation } from '../operations.js';
import type { VisualRenderedModel } from '../adapters/visual/wire.js';
import type { VisualAppState } from './state.js';
/**
 * The pending changeset, made legible one operation at a time, and the single
 * door through which it leaves the browser. Nothing here builds an operation
 * or guesses at what landed - it only names what is already staged and what
 * the server said about it.
 */
/**
 * The reviewer clicked a name on the diagram, not an id - so the tray names
 * the subject the same way, from the graph on screen right now. An operation
 * addresses its subject the way its document authored it, so the lookup is by
 * `(document, authored id)`: the same local id can be authored in two
 * documents and mean two different subjects. A subject an `add-*` operation is
 * about to create, or one an edit no longer applies to because a prior row
 * deleted it, has no entry to find: the id is the only honest fallback.
 */
export declare const resolveSubjectName: (document: string, id: string, graph: CanvasGraph | null) => string;
/** One staged operation, reduced to what a row needs to say. */
export interface ChangesetRowDescription {
    readonly verb: YarramateOperation['op'] | VisualViewOperation['op'];
    readonly subjectName: string;
    readonly fields: readonly string[];
    readonly removedFields: readonly string[];
    /**
     * Which half of the split this row edits. The tray states it because the two
     * have different blast radius: a view row rewrites one projection, a model
     * row changes every view that drew the subject. A reviewer reading a mixed
     * changeset has to be able to tell them apart at a glance.
     */
    readonly scope: 'model' | 'view';
}
/**
 * Every staged row, model rows first, as one list.
 *
 * One list because the reviewer sees one tray and discards by one index; the
 * order is defined here and `changeset.discarded` maps it back, so the two
 * cannot disagree about which row a click meant.
 */
export declare const changesetRows: (changeset: VisualChangesetCommitPayload, graph: CanvasGraph | null, views: readonly VisualViewSummary[]) => readonly ChangesetRowDescription[];
/**
 * A staged view, reduced the same way. The document's path is the subject:
 * a view has no id on the canvas to resolve a name from, and the path is what
 * the reviewer picked the folder of.
 *
 * A row that moves the view's MEMBERSHIP says which subjects it moves rather
 * than which file it writes: `+fraud-screening` is what the reviewer did, and
 * the path is what every other view row already says. Read against the saved
 * view, so a second membership edit reports both subjects and not just the
 * latest one - staged rows replace by path, and one row can carry several
 * subjects (#255).
 */
export declare const describeViewRow: (operation: VisualViewOperation, views: readonly VisualViewSummary[]) => ChangesetRowDescription;
export declare const describeChangesetRow: (operation: YarramateOperation, graph: CanvasGraph | null) => ChangesetRowDescription;
/** `update-concept · Checkout Service · name` - a retracted field reads
 * `remove: owner` so it is never mistaken for a write. */
export declare const changesetRowLabel: (row: ChangesetRowDescription) => string;
/** Diagnostics whose pointer names a staged operation, keyed by that
 * operation's index; everything else - a compile error against a model
 * document, not the batch - stays batch-level. */
export interface PartitionedDiagnostics {
    readonly byRow: ReadonlyMap<number, readonly VisualDiagnostic[]>;
    readonly batch: readonly VisualDiagnostic[];
}
export declare const partitionDiagnostics: (diagnostics: readonly VisualDiagnostic[]) => PartitionedDiagnostics;
/**
 * A staged row whose document has been rewritten since the row was staged.
 *
 * Derived at render rather than stored: the only thing that can change the
 * answer is a fresh `model` frame, and the server broadcasts one after any
 * session lands a batch, so the mark appears while the reviewer is still
 * sitting there rather than at commit time (ADR 0093).
 *
 * An unpinned row - one naming a document the model did not hold, which `apply`
 * will create - has no prior value to be stale against.
 */
export declare const stagedRowConflict: (operation: YarramateOperation, pins: Readonly<Record<string, string>>, model: VisualRenderedModel | null) => string | null;
/**
 * The same question asked of any staged document, model or view.
 *
 * A view is compared against `projectionDigests` rather than `sourceDigests`,
 * because that is where a projection's digest is published (ADR 0103); a
 * document in neither map is one the commit will create and has no prior value
 * to be stale against.
 */
export declare const rowConflict: (path: string, pins: Readonly<Record<string, string>>, model: VisualRenderedModel | null) => string | null;
/**
 * The pending changeset, the commit control, and whatever the last attempt
 * said. A batch that failed stays exactly as staged - the reviewer corrects
 * and retries the same rows, never a redrawn guess of them.
 *
 * Undo and redo walk whole staged-set snapshots, so they cover staging, a
 * same-field replacement, a single discard and a discard-all alike. They stop
 * at the last commit: what landed is Git's to revert.
 */
export declare const ChangesetTray: ({ state, onDiscardChange, onClearChangeset, onUndoChangeset, onRedoChangeset, onCommitChangeset, }: {
    readonly state: VisualAppState;
    readonly onDiscardChange: (index: number) => void;
    readonly onClearChangeset: () => void;
    readonly onUndoChangeset: () => void;
    readonly onRedoChangeset: () => void;
    readonly onCommitChangeset: () => void;
}) => import("react").JSX.Element | null;