/**
 * Page Health Diagnostics — Mobile (React Native) variant.
 *
 * Mirrors the runner / web analyzer in
 *   `ui-bridge/packages/ui-bridge/src/server/page-health.ts`
 * and the canonical Rust implementation in
 *   `qontinui-runner/src-tauri/src/mcp/ui_bridge/screenshots.rs::ui_bridge_page_health_handler`
 *
 * Output shape (`summary`/`findings`/`heatmap`/`element_count`/`visible_count`)
 * matches those byte-for-byte so the same `page-health` skill works on web,
 * runner, and mobile without branching per platform.
 *
 * Mobile-specific differences from the web/runner analyzer:
 *
 *   • Layout source: React Native elements expose `state.layout` in *pixels*
 *     (`{x, y, width, height, pageX, pageY}` relative to the device viewport).
 *     We normalize via `Dimensions.get('window')` into the 0-1 space the
 *     analyzer expects. The web/runner analyzer reads pre-normalized
 *     `state.normalizedRect` directly.
 *
 *   • Interactivity detection: mobile elements don't carry a `category` field.
 *     We treat `type ∈ {button, input, switch, checkbox, radio, touchable,
 *     listItem}` as interactive instead.
 *
 *   • CSS class signals: React Native has no class names, so the
 *     `class contains spin|pulse|skeleton|...` heuristic is always empty.
 *     We still emit the `css_signals` field (as `[]`) so the response shape
 *     stays platform-neutral.
 *
 * Fold semantics (see Step 7: Visual anomalies):
 *
 *   The `outside_viewport` count tracks only *horizontal* overflow — elements
 *   whose normalized x is left of the viewport (`x + width < 0`) or right of
 *   it (`x > 1`). Vertical offsets (`y > 1`, `y + height < 0`) are NOT an
 *   anomaly on mobile: ScrollView / FlatList content legitimately extends
 *   above or below the visible fold, and the user reaches it by scrolling.
 *   Flagging those would WARNING every scrollable screen (settings, feed,
 *   list pages). Only horizontal overflow is unreachable by the user on
 *   typical mobile layouts (the viewport is ~full-width, no horizontal
 *   scroll), so that's the meaningful anomaly we surface.
 */
import type { NativeElementState } from '../core/types';
export type PageHealthSeverity = 'OK' | 'WARNING' | 'CRITICAL';
export interface PageHealthFinding {
    check: string;
    severity: PageHealthSeverity;
    detail: string;
    data: Record<string, unknown>;
}
export interface PageHealthReport {
    summary: PageHealthSeverity;
    findings: PageHealthFinding[];
    heatmap: string[];
    element_count: number;
    visible_count: number;
}
/**
 * Mobile element shape consumed by the analyzer. A loosened subset of the
 * registry's full element record — only fields the analyzer actually reads.
 */
export interface PageHealthElement {
    type: string;
    state: NativeElementState;
}
/**
 * Run the page-health analyzer over a list of mobile registry elements.
 *
 * The pipeline mirrors the canonical analyzer step-for-step:
 *
 *   1. Visible filter (state.visible + measurable layout)
 *   2. Spatial coverage on a 20x20 grid + left/right halves
 *   3. Layout regions (sidebar/header/content) by center-point
 *   4. Element diversity (nav-only flag)
 *   5. Text signal scanning (errors / loading / empty)
 *   6. Interactive readiness (disabled ratio across interactive types)
 *   7. Visual anomalies (zero-size, outside-viewport)
 *   8. ASCII heatmap
 *   9. Worst severity rollup
 */
export declare function diagnosePageHealth(elements: PageHealthElement[], viewport: {
    width: number;
    height: number;
}): PageHealthReport;
//# sourceMappingURL=page-health.d.ts.map