[plainprogrammer]

The CI-only timeout in spec/system/catalog_search_spec.rb:4 is traced to its cause, which PR #9 (09aa85a, 2026-10-02) already removed. This PR adds a regression example that reproduces the failure on the old code, and records the cause. No application code changes.

Closes #62

Cause

Both failing runs (36793202581 at 948c17b, 36882235200 at fc8cff1) predate 09aa85a. At those commits the search form was a Turbo frame-advance filter (data-turbo-frame="results", data-turbo-action="advance"):

1. Turbo 8.0.23 swaps the results into the frame after the first repaint, so the spec sees the heading.
2. Turbo waits two more repaints, then starts a page visit for the new URL.
3. On a slow runner the spec's click on "Lightning Bolt" lands in that gap.
4. The late visit calls navigator.stop(), which cancels the click's visit. The search page stays and have_css("h1", text: "Lightning Bolt") times out.

This is the click variant of the "late page visit" race that broke Back. The earlier reading of the CI screenshot (a slow visit still in flight) was wrong: the bar in both screenshots is full width and opaque, which is a leaked timer from a cancelled visit, not a visit in progress.

Evidence

Check	Result
New example at 09aa85a^ and at fc8cff1	fails 3/3 with CI's exact message
New example at 09aa85a and on current main	passes 3/3 and 5/5
Current main with the frame filter put back (reviewer)	new example fails 3/3; the original example alone passes 10/10, matching "never fails locally"
CI history since PR #9 merged	75 CI runs, 4 failures, none in this spec
CI seeds 14482 and 4155 on current code	full suite passes
Hover prefetch, SQLite contention, slow first render	each ruled out with an instrumented probe on current main

An independent read-only review (Opus) confirmed the cause from Turbo's source and a live trace, found no other path on current main that could cancel the click's visit, and agrees the issue can close as already fixed.

What changed

• spec/system/catalog_search_spec.rb: a second example, "opens a printing even when repaints and the card page's fetch are slow". It uses using_wait_time(5) only because it injects a 1.5 s fetch delay and 300 ms repaints itself; the original example keeps the default wait.
• .claude/memory/: the flake's memory file is deleted, and turbo-back-navigation-quirks.md records the click variant and what a stuck full-width progress bar means.

Verification

• bin/ci: passed. RSpec 1220 examples, 0 failures, 1 pending (the art agreement spec, unrelated).
• Not verified: the new example on GitHub's runners; this PR's CI run is its first. The reviewer ran it 8/8 green on one starved core.

Notes and follow-ups

• With the frame filter put back and the machine starved, the new example caught the bug 4 times in 5, so "always lands in the gap" in commit b4f9bbc overstates it. On current code that is not a flake risk.
• search_for_bolt and the slow-repaint helper near-duplicate ones in spec/system/back_navigation_spec.rb; one shared helper in spec/support/ would be tidier. back_navigation_spec.rb:45 also fails if the frame filter comes back, so the new example is a second guard that documents this symptom.
• Uploading log/test.log as a CI artifact on failure wasn't added; it would still help the next unrelated flake.
• docs/roadmap.md still lists Catalog search system spec times out on GitHub CI #62.

🤖 Generated with Claude Code