During the September 5 website work, navigating from Work to Research could produce an empty list. The content was there. The selector looked like it was showing everything. The page reported zero of 46 research topics.

That is a frustrating kind of failure because the screen appears to explain itself. It is simply explaining the wrong state.

I had accepted the visual direction and then reported the blank collections during navigation. Looking at an isolated page had not told us what happened when someone moved through the site.

The old filter followed the reader into a new collection

Work and Research shared a React catalog component. During client navigation, it retained state initialized for the previous collection. A category from one catalog could therefore influence the other while the visible controls suggested a different selection.

The recorded reproduction made the disagreement concrete: Research reported an empty result with an “All work” state, while its selector displayed all fields.

We corrected the ownership by deriving filters from the URL and validating category membership for the active collection. History metadata was preserved when filters changed.

That gave the URL, the controls and the displayed results a common state to describe.

A page is also somewhere people arrive

The follow-up checks covered ten grouped navigation scenarios at desktop and phone widths. They included switching catalogs, keeping categories isolated, Back and Forward, resetting filters, opening a detail and returning, invalid categories, and direct query URLs.

Those journeys exercise different ways to arrive at the same screen. A direct load starts from one state. Returning from a detail page or another catalog starts from another.

For this defect, that distinction was the whole point. Checking whether a route returned content would not by itself establish that the navigation history and visible filter agreed.

The correction was verified on development and built previews, and the release record includes the subsequent public checks. This is a dated account of that fix, not a promise that every future catalog change inherits its result.

Sometimes the test has the wrong idea about readiness

The later TurtlePen gallery release exposed a different mistake in our own checks. A probe waited for every image before scrolling. The gallery used native lazy loading, so images outside the viewport did not all need to load at the start.

The corrected probe scrolled each image into view and waited for it there. That matches the intended use more closely. MDN explains how the image loading attribute allows deferred loading near the viewport.

A menu probe also ran before the page's interaction handler was attached. Waiting for the initial load corrected that check; the record does not claim we rewrote the menu to solve it.

These were not excuses to discard failures. Each required identifying the disagreement and checking the behavior that the product actually promised. The catalog needed a code correction. The gallery probes needed better timing and movement through the page.

Start the review one step earlier

For another searchable collection, I would pick a real item and reach it several ways: directly, through a filter, after visiting another collection, and with Back after opening a detail.

At each stop, compare three things: the URL, the visible selection and the result list. Then try a search with no matches and recover from it. This is a small walkthrough with enough history to expose ownership mistakes.

I care about the screen a person can actually reach. A beautiful collection that disappears on the way there still needs work.

Record and method

Written September 6, 2026, from the September 5 showcase correction and the gallery release recorded September 6 UTC. AI assisted with drafting from those records. The navigation bug and the later probe corrections are separate incidents. The Work and Research collections provide the public context; the illustration comes from the TurtlePen gallery.