searchi/design-qa.md

Design QA

final result: browser captures checked; native desktop visual gate remains open

Browser-rendered implementation evidence (2026-10-12)

Four 1440×1000 captures now show the production frontend against the actual shared Rust/Google CPU engine: document search in both themes, an indexed photo preview, and measured performance details. The selected PDF result really maps to page 2 and its notice clause. Photo pixels are loaded from the indexed file; the trace includes actual worker inference counters. Capture assertions passed, and every final PNG was opened and inspected.

The brand mark, local typography, two-pane structure, selection, passage text, photo preview and diagnostics render visibly. No primary selected content is clipped. Windows namespace prefixes are hidden only in display labels; file operations retain the original indexed paths. The ordinary summary uses clear Search/Shown timing labels. The last partially visible result is inside the scrollable result list.

The final captures also check literal query-word marks in filenames, snippets and the extracted passage. A small Why this result? disclosure stays collapsed by default in the selected preview. Its page-2 explanation was opened and checked during capture, then closed for the ordinary screenshots. Semantic passage emphasis identifies the retrieved text; it does not claim model-derived word importance. Photo preview text contains no invented literal matches.

These captures omit native window chrome and do not verify native WebView behavior, OS integration, animation, playback or native keyboard/focus behavior. The runner uses reduced motion and an owned CPU-rendered headless browser. Its responses come from the live engine without result replay or UI mocks. See the capture workflow and capture manifest.

Native desktop gate

Target: Karl's selected first search/preview concept, combined with Raycast-style compact interaction and the supplied searchi brand board. Source images were opened and inspected. The frontend implementation builds and its state tests pass.

Native rendered comparison is unavailable: the in-app browser bootstrap fails because its browser-service module cannot be found. Prior native Windows capture attempts returned GetCursorPos access denied and monitor capture error 0x80070057. No matching-state native implementation screenshot has been captured. A native side-by-side visual comparison and visual pass remain unverified.

The native development app launched in forced-CPU mode. Its accessibility tree could be read without screenshots and exposed a missing font-import error, which was corrected. During integration the frontend watcher also attempted to watch a locked native build executable. The font import and watcher exclusion were corrected, and a fresh native launch succeeded. Its accessibility tree showed the real search field, folder/filter/settings controls, empty-state tagline, and Google model ready with actual CPU device status. Attempting to set the search field through the supported UI tool failed with GetCursorPos access denied (0x80070005). These are runtime checks, not a visual comparison or end-to-end pass.

Typography, spacing, colors, asset fidelity, and content must all be evaluated against a captured native app after access is restored. Keyboard navigation, progressive results, focus/selection stability, themes, reduced motion, and forced colors also require actual interaction verification. Compilation and unit tests are separate evidence and do not close this gate.