Card Overview performance acceptance — 2026-10-09

The operator explicitly chose the proposal’s accept-performance option:

i mean i’m happy with the card overview’s performance just close it on my permission and land it

operator-decision.json retains the exact statement, source records and limits. This completes decision task 4.2d. The user also confirmed current app switching in the UX walkthrough; its candidate identity identifies the current normal mainline runtime separately from older tests.

Measured cost and the accepted distinction

The historical tracking measurements record p95 presentation intervals about 57.47–57.49 ms against the declared 33.334 ms budget, and recorded CPU-budget misses. The later vblank observation found a 19.16 ms hardware grid during idle and injected Overview transitions. The discrepancy is render/commit overrun quantized to vblank, rather than a 57 ms panel limit. The historic cost is less frequent visual updates while cards move.

Those measured misses remain measured misses on their identified candidates. The current accepted mainline/HDMI runtime has different geometry and artifacts; this approval supplies no new numeric timing for it. The operator is satisfied with its observed performance. Further performance optimization and the known-risk commit-pipelining experiment are not needed for closure. Functional card behavior remains accepted separately; no behavior is removed to meet a benchmark.

No new UART, camera or performance session ran for this decision. The separate selected board-system host build and selected, non-fixture QEMU guest smoke passed. Their exact commands, timestamps, identities and limits are retained below; neither supplies a fresh physical performance measurement.

Ownership: worktree /home/jadams/tmp/k230-card-overview-close-final, branch closeout/card-overview-accepted-2026-10-09, base 427a15f3. Owned paths are this change’s planning/evidence, system/QEMU selection, guest verifier, smoke documentation and work-board status, plus the CLI-synced runtime/card-shell requirement. Builds use /tmp/k230-nix-build.lock; no board reservation is taken.

Selected board configuration build

The host build and selection record and build log record a successful full k230 system build with coherentShell = true. k230-bar-shell retains the former bar-system derivation exactly. The existing normal mainline configuration still evaluates to the accepted yl3si5ak closure, unchanged; no board activation or boot was performed. The QEMU-pending limit in the host-build record describes that earlier source checkpoint; the subsequent selected guest run passed as recorded below.

Build cache retention

The cache investigation and durable roots record unchanged sampled dependency recipes and protect the realized selected artifacts and build inputs against normal GC. The specific earlier deletion event remains unverified. This host-local retention does not change global GC policy.

First selected guest attempt

The first ordinary selected-image run built and booted the image but failed expand restores app focus. Its manifest and actual failure lines remain a failed integration attempt. The verifier held a 170-pixel drag while checking both live previews, then expected that slow release to select the neighbour. The original fixed-threshold policy supported that assumption; current nearest-card/coasting policy and 80%-width cards require more travel. The corrected verifier finishes the stroke and observes actual selection and settlement before tapping. At that checkpoint a fresh selected guest pass was required; the subsequent passing run is recorded below.

Selected QEMU guest integration

The ordinary tools/qemu-k230.sh --card-shell-smoke invocation, without --fixture-image or --no-build, built and booted the selected k230-qemu image and returned zero. Manifest, result, provenance and actual guest reports retain the selected artifacts and two fresh runtime reports. Both report the same selected system and compositor executable, unprivileged UID and RISC-V guest, with different compositor PIDs after service restart. All six required interaction checks and service teardown passed.

This is system-mode QEMU on virt, with headless Pixman output and injected input. It proves the selected Linux/userspace integration, not a new board boot, panel scanout, physical touch, optical latency or numerical frame-budget pass. Current physical Overview performance is accepted by the separate operator decision above. No new system was activated on the board.