UI interaction baselines registry

SSOT for the latency of reusable UI interaction primitives (open a menu, create a tab, focus an input, …) across Koder surfaces, measured as request→painted and compared on the same run against the best-in-class external equivalent (Chrome, GNOME, Tilix, …).

Contract: meta/docs/stack/specs/testing/ui-interaction-perf.kmd. Ratified by meta/docs/stack/rfcs/stack-RFC-012-ui-interaction-perf-corpus.kmd.

This is NOT perf-baseline.md. That file is an append-only log of backend hot-path bench runs keyed by component. This file is a tiered-threshold table keyed by (sdk-component, primitive, surface, target), owner-seeded, ratio-primary, and (from stack-RFC-012 Phase 5) used as a gate. Do not merge the two.

How to read a row

• ratio = koder_p99 / reference_p99 measured in the *ame run on the

  same machine*— the portable signal (spec R5). — when no external equivalent (self-referential primitive).

• koder p99 / ref p99 = raw tail latency, ms, hardware-tagged. Median

  (p50) lives in the per-run history, not here; this table holds the latest governing p99.

• tier = ideal / acceptable / unacceptable (spec R6). seed in

  the authority column means the tier is the HCI-prior default, not yet an owner verdict.

• authority = seed (HCI default), owner (owner verdict — overrides),

  or ref (derived from the measured reference).

• reference = external software + version + capture date (spec R5).
• A row with no measurement yet carries tier: seed from the defaults

  below and — for the measured columns.

Tier seed defaults (HCI priors — spec R6)

Used to seed every primitive before any measurement or owner verdict, so the corpus is never empty at bootstrap:

Schema

Entries

First real-engine row landed in stack-RFC-012 Phase 2 (KKIT-078): the koder_kit desktop integration harness. Phase 3 adds the Kruze slice.

enginessdkkoder_kit — IDEAL (owner verdict, 2026-06-08)

Measured via the KoderInteractionProbe integration test on the real Flutter Linux engine under xvfb. Self-referential (no external reference → ratio —).

Owner verdict: ideal (2026-06-08), data-backed by the KKIT-086 diagnostic. The koder p99 ms below is integration_test HARNESS OVERHEAD, not app latency. The diagnostic (single-frame pumps + frame count) showed the result paints in frames p501 / max1 — the very next frame after the input (~16 ms, as fast as physically possible). The ~95-150 ms wall-clock is the tester.tap() + live-binding pump cadence floor (~100 ms), NOT render. So the true request→painted latency is 1 frame → genuinely ideal (well under the 100 ms RAIL bar). See spec R4.1 (harness-floor caveat) + KKIT-086.

KKIT-087 (frames-to-paint, all 4 measured): open-menu / focus-input / open-dialog / open-dropdown ALL paint in frames p501 / p991 / max=1 on dev-linux-dek — every primitive responds on the next frame. This is the clean governing metric (R4.1); the ms column is kept only as harness-floor evidence.

enginessdkkoder_kit — flutter-web (cross-surface, Phase 6 — KKIT-089)

First cross-surface validation (stack-RFC-012 Phase 6's core premise: does the corpus generalise beyond one surface?). The SAME phase6_primitives_perf_test.dart runs on flutter-web (real Chromium 148 browser, flutter drive headless via chromedriver on dev-linux-dek). For flutter-web the metric is still frames-to-paint (the Flutter framework scheduler runs in the browser; the spec's PerformanceObserver is for the NON-Flutter web surface, R3).

Result: All tests passed. on flutter-web — both primitives' perf-golden gates (frames p99 ≤ 3) PASS in the browser, AND the exact frames-to-paint are captured (KKIT-089 closed the precise-measurement gap). The numbers are identical to flutter-desktop: switch-tab = 2 frames, open-context-menu = 1 frame — the same SDK widgets paint in the same frame budget on the browser as on the desktop engine. The corpus generalises with equal numbers, not just an equal verdict.

Extraction seam (the architectural win): flutter drive does NOT relay the browser-side print(), so the harness exports measurements via IntegrationTestWidgetsFlutterBinding.reportData, which the default integrationDriver(responseDataCallback: writeResponseData) writes to build/integration_response_data.json on every surface uniformly — replacing fragile, surface-dependent print-scraping. This seam is reusable by every future driven surface (mobile/tv).

productshorizontalkruze — pending Phase 3 (advisory)

Planned first rows (instrumentation unverified until the CEF OnPaint probe lands — spec R3):