/**
 * Canvas run-state: live step lighting for the sandboxed iframe, plus the
 * reverse click channel (iframe → parent).
 *
 * HOW IT WORKS — the stringify-into-iframe pattern
 * ─────────────────────────────────────────────────
 * The canvas iframe is served with `sandbox="allow-scripts"` which makes it
 * an opaque origin. The parent page cannot reach its DOM via any API — the
 * ONLY communication channel is `window.postMessage`.
 *
 * To apply live run state to the SVG nodes, we need code that runs INSIDE the
 * iframe's document. We cannot bundle a separate script for it (no fetch
 * inside a sandboxed iframe, no src="" script). Instead, `canvas-template.ts`
 * stringifies the functions below with `.toString()` and injects them
 * directly into the `<script>` block that `renderCanvasDocument` emits.
 *
 * REVERSE CHANNEL (iframe → parent)
 * ───────────────────────────────────
 * `bootCanvasNodeClicks` adds a single delegated click listener on
 * `document`. When a click lands inside a `.canvas-node[data-step-name]`
 * element, it posts `{ type: "sapiom:node-click", stepName }` to the parent
 * via `window.parent.postMessage`. The parent listens for this and opens the
 * step-detail panel.
 *
 * CONSTRAINTS on these functions
 * ────────────────────────────────
 * • No TypeScript-only syntax inside the function bodies (they are stringified
 *   as-is and executed in a plain-JS browser context with no transpiler).
 * • No imports or module-level references (same reason).
 * • All functions must be top-level `function` declarations (not arrow
 *   functions, not const lambdas) so they are referenceable by name after
 *   stringification.
 * • `runStateNodeClass` is the one pure piece (no DOM); it is also exported and
 *   unit-tested in `canvas-run-state.test.ts`. The other functions are DOM-only
 *   and not unit-testable in a Node/Vitest environment.
 */
export type RunStepStatus = "pending" | "running" | "passed" | "failed";
/**
 * Pure: map a step status to its canvas node CSS state class.
 *
 * Unit-tested. Safe to call from Node and from the browser.
 */
export declare function runStateNodeClass(status: string): string;
/**
 * DOM: apply a run-state message to a canvas document.
 *
 * For each step, finds the matching `[data-step-name]` node (falling back to
 * `[data-step-id]`), strips the four is-* state classes, and applies the one
 * matching the step's current status. Also updates the first `.canvas-badge`
 * inside `.canvas-title-row`: while the run is active it shows "running" or
 * "testing" (with the `canvas-badge--active` styling class); on completion it
 * restores the original text from `data-idle-label`.
 *
 * Browser-only — not unit-tested (no jsdom in the harness test env).
 * Stringified into the iframe template by `canvas-template.ts`.
 */
export declare function applyRunStateToCanvas(doc: Document, msg: {
    steps: Array<{
        name: string;
        id?: string;
        status: string;
        latencyMs?: number;
    }>;
    status: string;
    target: string;
}): void;
/**
 * Wires the postMessage listener.
 *
 * Called once at the bottom of the injected `<script>` block. Listens for
 * `{ type: "sapiom:run-state", steps, status, target }` messages from the
 * parent page. The type guard is the only security boundary needed: because
 * the iframe is opaque-origin, no other page can impersonate the parent, and
 * the parent posts to `"*"` (required — we cannot know the opaque origin).
 *
 * Stringified into the iframe template by `canvas-template.ts`.
 */
export declare function bootCanvasRunState(): void;
/**
 * Wires the reverse click channel: iframe → parent.
 *
 * Adds a delegated `click` listener on `document` AND a `message` listener for
 * the harness gesture layer's `sapiom-canvas:pick` / `sapiom-canvas:hover`.
 * The gesture layer overlays the iframe (for pan / zoom) and swallows raw
 * clicks, so the direct listener alone never fires in the harness; the layer
 * instead forwards the click/hover point, which we hit-test with
 * `elementFromPoint`. Either path resolves the `.canvas-node[data-step-name]`
 * under the point and posts `{ type: "sapiom:node-click", stepName }` to the
 * parent (hover answers `{ type: "sapiom-canvas:hit", id }` for the cursor).
 * The parent maps the step name to the current RunView to open the inspector.
 *
 * Uses a delegated listener (one listener on document) rather than per-node
 * listeners so it works even when the SVG is replaced (e.g. after a
 * canvas.reload), without needing to re-wire.
 *
 * Stringified into the iframe template by `canvas-template.ts`.
 */
export declare function bootCanvasNodeClicks(): void;
/**
 * Keeps the board's selected node lit while the parent's bottom inspector
 * shows that step.
 *
 * Without this the served board answers a pick (see `bootCanvasNodeClicks`)
 * and then looks untouched: the inspector swaps its content with nothing on
 * the graph to say WHICH card it is describing — change blindness on every
 * pick. The parent posts `{ type: "sapiom-canvas:select", id }` (null clears)
 * with the graph node id, which the SVG carries as `data-step-id`; older
 * documents that only carry a label fall back to `data-step-name`.
 *
 * Selection is orthogonal to run state: `is-selected` only rings the node, so
 * a running/passed/failed card keeps its own lighting while selected.
 *
 * Stringified into the iframe template by `canvas-template.ts`.
 */
export declare function bootCanvasSelection(): void;
/**
 * Wires the view (pan/zoom) channel and announces the graph's natural size.
 *
 * The sandboxed iframe element itself NEVER transforms — that keeps the gesture
 * layer's forwarded click/hover points in this frame's coordinate space (see
 * bootCanvasNodeClicks). Instead the harness gesture layer captures wheel/drag,
 * tracks a `{ zoom, x, y }` view, and posts `{ type: "sapiom-canvas:view" }`;
 * this applies it as a CSS transform on `#canvas-root`. Without this handler the
 * view messages are dropped and the canvas can neither zoom nor pan.
 *
 * On load it posts `{ type: "sapiom-canvas:size", width, height, ... }` — the
 * graph's natural px (canvas-svg.ts pins the `<svg>` to explicit width/height) —
 * which is the parent's fit-to-view input. `#canvas-root` and the `<svg>` are
 * looked up lazily because this runs from `<head>`, before `<body>` is parsed.
 *
 * Stringified into the iframe template by `canvas-template.ts`.
 */
export declare function bootCanvasView(): void;
/**
 * Posts the workflow's step graph to the parent so the Steps tab / inspector
 * can project it (`{ type: "sapiom-canvas:graph", graph }`).
 *
 * The graph is embedded by `canvas-body.ts` as a `<script type="application/json"
 * id="sapiom-graph">` data block (NOT executed — it's read as text here). Without
 * this the board (SVG) still shows, but the Steps tab has no graph and reads
 * "No steps yet" even though the diagram is visible. Deferred to DOM-ready
 * because this boots from `<head>`, before `<body>` (and the data block) parses.
 *
 * Stringified into the iframe template by `canvas-template.ts`.
 */
export declare function bootCanvasGraph(): void;
/**
 * Posts the workflow-level overview (`{ description, stats, notes, badges,
 * legend }`) so the
 * Canvas tab's bottom panel can show it — the deterministic equivalent of the
 * demo doc's overview. Embedded by `canvas-body.ts` as a `<script
 * type="application/json" id="sapiom-overview">` data block (read as text, same
 * pattern as the graph). A missing block posts nothing and the parent keeps its
 * empty state; a malformed one is swallowed rather than thrown. Stringified into
 * the template by `canvas-template.ts`.
 */
export declare function bootCanvasOverview(): void;
/**
 * Posts deterministic extraction failures to the parent workbench. The error
 * panel embeds `{ title, reason }` in `#sapiom-render-error`; without this
 * bridge the app's actionable error overlay can never appear and the iframe
 * is left showing only static prose.
 *
 * A successful post marks the root `data-canvas-error-posted`. That marker is
 * what lets the head script withdraw its optimistic `data-canvas-embedded`
 * flag at load time, so the in-document prose only stands down when something
 * has actually stood up in its place (SAP-3199). Every path that does NOT post
 * leaves the marker unset, which is why the `catch` below can still promise to
 * keep the panel visible.
 */
export declare function bootCanvasError(): void;
//# sourceMappingURL=canvas-run-state.d.ts.map