# `tests/card_shell_runtime.py` pre-existing flake: tap-after-drag race

Evidence class: **host-only** (QEMU-injected input under
`qemu-riscv64-static`, real cross-built Sway; no board, no physical touch).
This fixes a test-harness bug found while closing out
`the-card-shell-has-no-video-special-case`'s task 4.2, not a compositor
behavior change.

## What was reported

Task 4.2 recorded that `tests/card_shell_runtime.py`'s
`wait_for(lambda:focused()=='k230.card.two')` assertion (after a full
horizontal deck drag followed by an immediate tap) was already failing
against the pre-change baseline (commit `59e0eb78`), unrelated to that
change's own diff.

## Root cause

Confirmed by reproducing directly (`python3 tests/card_shell_runtime.py
--sway <sway> --client <client> --rgb565`, no board):

1. `cs_up` (`nix/card-shell-policy/card-shell-policy.c`) resolves a
   released horizontal drag by updating `p->selected` to the new card
   **synchronously**, but deliberately does **not** re-center that card:
   `scroll_from_dx` is chosen so the newly selected card's on-screen
   position stays *continuous* with wherever the drag left it, then eases
   to center under its own momentum over up to `config.reduced_motion==
   false`'s 760ms bound (`cs_up`'s own comment: "the settled card's
   on-screen x must not jump at the instant of release").
2. `cs_down` (same file) hit-tests a fresh touch against the *current,
   still-animating* geometry: on a coast, it calls `cs_tick(p, time_ms)`
   using the real wall-clock time of the IPC call before hit-testing.
3. The test fired `command('down 2 284 450'); command('up 2')` (a tap at
   the panel's horizontal center) **immediately** after `command('up 1')`
   ended the drag, with no wait for the coast. Depending on scheduler
   timing (worse under shared-host load), the tap could land while the
   just-selected card was still off-center, so it either missed or hit a
   different card than the one `cs_up` had already selected.

This is real, intentional product physics (`cs_up`'s continuity design),
not a compositor bug, and reproducing it does not require the video
special-case removal — it was present at commit `59e0eb78` already.

A second, independent flake was found while reproducing this one: the
`during-drag.png` capture at `x==184` in the same drag loop
(`subprocess.run(['grim', ...])` immediately after an IPC `motion` command)
could run before the compositor's next scheduled frame had actually been
composited, especially under the heavily loaded shared host this session
ran on (`uptime` showed ~18-19 load average across 32 cores while
reproducing this). `docs/evidence/brightness-slider/README.md` already
documents the same class of host-load sensitivity for a different QEMU
harness.

## Fix

`tests/card_shell_runtime.py`:

- After the drag-release (`command('up 1')`), wait `0.9s` (past the
  policy's documented 760ms worst-case coast) before the confirmatory tap,
  so the tap lands on the settled, centered card instead of racing the
  coast animation.
- The `during-drag.png` capture at `x==184` now polls
  (`wait_for(during_drag_moved)`) instead of asserting a single
  immediately-taken screenshot, mirroring this file's own `wait_for`
  convention used elsewhere in the same script.

Neither change touches compositor source (`nix/card-shell*`); both are
confined to test synchronization in `tests/card_shell_runtime.py`.

## Verification

Narrow proof command (from `tests/`, matching the task's own required
invocation):

```
python3 -m unittest test_card_shell_scaled_cache_runtime -v
```

Result: **PASS**, both the `SWAY_K230_CARD_SCALED_CACHE=0` and `=1` runs
(`off` and `on`), reusing the cached `.#card-shell` build
(`/nix/store/j57c5im42d3rq5gxdar2ikmh22717zvc-k230-card-shell`, unwrapped
Sway `/nix/store/0a2f857nc1rz65gnjdfn46h32zsyxm18-sway-unwrapped-
riscv64-unknown-linux-gnu-1.12`) and the native
`card-composition-probe-client`
(`/nix/store/yjb89ap4bq5vb29szdzkr5sv9lpw1sz6-card-composition-probe-
client-0.1`). Also reproduced clean twice more by invoking
`tests/card_shell_runtime.py` directly with the same binaries and
`--rgb565` (no unittest wrapper).

Unaffected suites confirmed unchanged by inspection: `--two-axis` and
`--touch-first` both `return` before reaching the edited code path, so
`test_card_shell_two_axis_runtime.py`, `test_card_shell_touch_first_
runtime.py` and `test_card_shell_home_bleed.py` (which drives
`--home-layer-client` through the two-axis path) exercise different lines
entirely. Both of those suites were observed independently flaking on
this same shared, loaded host during this session (different assertions,
earlier in their own paths) — that is the same pre-existing host-load
class documented in `docs/evidence/brightness-slider/README.md`, not a
regression from this diff, and is out of this task's scope.

## Limits

QEMU-injected-input proof only; no board, no real finger, no panel. This
fix makes the existing host regression deterministic again; it makes no
claim about physical drag/tap timing.