/**
 * Assembles the `<div id="canvas-root">` body — the bound workflow's
 * `<section class="canvas-panel">` (title/summary header + SVG diagram),
 * entirely from the classes `core/canvas-template.ts`'s shell already defines.
 * This is the HTML half of the deterministic render; `core/canvas-document.ts`
 * wraps the result through `renderCanvasDocument()`.
 *
 * The panel ends with the color/shape legend (only the node kinds actually
 * used, plus a cross-workflow row when relevant) so the diagram reads on its
 * own. It sits at the bottom of `#canvas-root` INSIDE the iframe — safe from
 * the SPA's floating zoom/fit controls because the pane reserves a strip below
 * the iframe for them (see `.canvas-visual { padding-bottom }` in
 * web/src/styles.css), so the two never sit "l'un sur l'autre". The only thing
 * deliberately dropped is the old prose footer note ("Static preview —
 * regenerate…"), which was pure noise.
 */
import type { CanvasEdgeKind, CanvasGraph, CanvasNodeKind } from "./canvas-graph.js";
import type { CanvasEnrichment } from "./canvas-enrichment.js";
export interface WorkflowPanelMeta {
    title: string;
    badges?: string[];
}
/**
 * The color/shape key for one diagram: only the node kinds that actually appear
 * (in stable order), plus a cross-workflow row when the graph has cross edges.
 * Returns "" when nothing is worth keying, so the panel omits the footer.
 */
export declare function buildLegendHtml(nodeKinds: Set<CanvasNodeKind>, edgeKinds: Set<CanvasEdgeKind>): string;
/**
 * The same key as `buildLegendHtml`, as data rather than markup: the app's
 * overview panel renders it beside the graph instead of the board floating it
 * over itself.
 */
export declare function buildLegendItems(nodeKinds: Set<CanvasNodeKind>, edgeKinds: Set<CanvasEdgeKind>): Array<{
    kind: string;
    label: string;
}>;
/** One workflow's full panel: title/badges + summary header and the SVG
 *  diagram, with the deterministic enrichment merged in (summary line and
 *  node/edge annotations), plus the embedded step-graph payload the Steps tab
 *  reads. */
export declare function buildWorkflowPanelHtml(graph: CanvasGraph, meta: WorkflowPanelMeta, enrichment?: CanvasEnrichment | null): string;
/** A degraded panel for a workflow whose graph couldn't be extracted — never
 *  a crash, never a silent fallback to the LLM path, just an honest reason
 *  styled through the same shell.
 *
 *  The prose carries `canvas-render-error-note` so the template can hide it
 *  while the document is embedded: the SPA paints its own Render-failed card
 *  (short claim, one-line reason, actions, full reason behind Details)
 *  transparently over this document, and two error strings drawn through each
 *  other was SAP-3199. Opened standalone there is no card, so the prose stays
 *  as the only message. */
export declare function buildErrorPanelHtml(title: string, reason: string): string;
/** A calm, transient panel for a workflow whose dependencies aren't installed
 *  yet (a freshly scaffolded project between `scaffold` and `npm install`).
 *  Extraction WOULD fail here with esbuild "Could not resolve …" noise, so we
 *  don't run it — we show this instead and let the install watcher re-render
 *  once `node_modules` lands. Crucially it emits NO `#sapiom-render-error`
 *  script, so the SPA shows no "render failed" card / Retry buttons: this is a
 *  normal setup state, not an error the user has to act on. */
export declare function buildPreparingPanelHtml(title: string): string;
/** Joins the workflow panel(s) into the final `#canvas-root` body — the string
 *  `renderCanvasDocument()` wraps. Each panel already carries its own legend
 *  footer (see `buildWorkflowPanelHtml`); there is no document-level footer. */
export declare function assembleCanvasBody(input: {
    panels: string[];
}): string;
//# sourceMappingURL=canvas-body.d.ts.map