/**
 * Every tile OBJECT the composed dashboard holds, in document order,
 * duplicates included — top-level `tiles`, each `stat-row` widget's data,
 * stat-rows inside `tabs`. Duplicates are the point: a fresh value must land
 * on each copy, so the caller that wants one-per-id says so with
 * `uniqueTilesById`.
 *
 * Two callers, two spellings of "where the views are": the EVALUATOR answers
 * them as an array on the result (`dash.views`), while the PAYLOAD keeps them
 * in a top-level record beside `dash`, keyed by view id with non-composed
 * entries mixed in — that caller passes the record as `views`.
 */
export declare function collectTileObjects(dash: any, views?: any): any[];
/**
 * E41 — the same question one container up: every WIDGET OBJECT the composed
 * views hold, in document order, duplicates included. Descends through the
 * two containers a widget can nest in — `tabs` (the tabs widget) and
 * `widgets` (E32's placed views and sections) — because a chart placed inside
 * a named view is still a chart on the page, and a client that refreshed only
 * the top level would leave the placed copy showing yesterday's numbers. The
 * copies matter for the same reason they matter to tiles: JSON has no
 * reference sharing, so each drawn copy is a distinct object to write to.
 *
 * Dependency-free like its neighbour: the client walks the payload with it,
 * and any host that wants the same set walks the evaluated views with it.
 */
export declare function collectWidgets(dash: any, views?: any): any[];
/**
 * The SERVING shape: one tile per id, first occurrence winning — top-level
 * before widgets, because collectTileObjects keeps document order. A tile with
 * no id has no address a client could merge by, so it cannot be served.
 */
export declare function uniqueTilesById(tiles: any[]): any[];