feat: filter by Sold / Not sold / All on the storefront and the admin (#105)

Three decisions were taken before any code, and are recorded on the issue.

The status filter is generalised to accept several values rather than gaining a second `sold` dimension beside it. "Not sold" is not a status: it is available-or-reserved on the storefront and includes pending in the admin, neither of which is one value. `?status=available,reserved` and `i.status = ANY($n::text[])` express that with one concept, so there is no way to write a contradiction like `?status=sold&sold=no`. A single status still parses to a list of one, which is how the admin's existing `?status=sold` keeps working untouched.

The storefront now defaults to Not sold. That is a change in what every customer sees, not just a new control: the black SOLD ribbons leave the default view on a catalogue where they were evidence the shop sells things, and every storefront link shared so far quietly changes meaning. Accepted deliberately, with the default named in STOREFRONT_DEFAULT_STATUSES rather than implied by the absence of a parameter.

The admin's four-way status dropdown is replaced rather than joined. That gives up isolating a single status: there is no longer a way to view only Reserved, or only Pending, and Not sold folds pending in with the rest. The pending workflow from #90 is the likeliest thing to miss it, and if it does, the fix is to put isolation back beside the preset rather than to remove the preset. The e2e test that covered "which is how Reserved is reached" is renamed and narrowed to what survives, rather than deleted.

One thing the issue did not anticipate, found by a test rather than by reading. The favorites view deliberately showed sold favorites - "a favorite that has just sold is often exactly what the customer came to look at", and they have just been emailed to say so. Defaulting the storefront to Not sold reversed that silently and broke the test asserting it. Favorites therefore keep their own default of everything, on the server and in the control's displayed position, while an explicit ?status= still wins. That interaction is the kind a single-feature change quietly breaks, and it was caught only because the previous decision had been written down as an assertion.

"All" still means different things in the two places, as the issue set out: available + reserved + sold on the storefront, all four in the admin. Pending remains unreachable from every public read - the storefront's unconditional exclusion clause is untouched - and the pending guard now checks every requested status rather than a single one, so `?status=available,pending` is refused for naming pending at all rather than accepted because the first name happened to be allowed.

The control sits in the filter bar rather than in the drawer, since the default now hides sold pieces and a customer who never opens the drawer would otherwise have no way to know they exist. It is consequently excluded from the "Filters (N)" count, which describes the drawer, while still counting toward hasActiveFilters so that an empty result reads as "no items match these filters" with a way out rather than as an empty shop.

Verification: 13 integration tests covering the default, each preset, the favorites exception and its override, and pending's unreachability under every accepted combination; 38 parser unit tests including multi-value parsing, an unknown name in a list being refused rather than dropped, and a list that names nothing; 6 new end-to-end tests for the storefront control, its URL round-trip, and the default staying out of the URL. 204 backend unit tests and 76 integration tests across the four affected suites pass. Two full end-to-end runs: 110 and 111 passing against the same 3 pre-existing failures, one run also showing a pending-publish failure that passes in isolation and did not recur - the cross-suite database contention filed as #116. tsc, ESLint and the production build are clean.

Closes #105
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

frontend/tests/e2e/admin-inventory-filters.spec.ts

@@ -40,6 +40,15 @@ test.beforeAll(async ({ playwright }) => {
   await api.dispose();
 });
 
+// antd Segmented hides the real radio input behind a styled label, so the input
+// is found by role but cannot be clicked. The label carries a title attribute,
+// which is the same handle this suite already uses for antd Select options.
+// The input is still the right thing to assert checked-ness on: toBeChecked
+// does not require visibility.
+async function chooseAvailability(page: Page, label: string) {
+  await page.getByTitle(label, { exact: true }).click();
+}
+
 const row = (page: Page, name: string) => page.getByRole('row').filter({ hasText: name });
 
 // The Inventory table paginates and other specs create items concurrently, so
@@ -77,17 +86,28 @@ test.describe('Admin inventory filters', () => {
     await expect(row(page, NAMES.dear)).toHaveCount(0);
   });
 
-  test('filters by status, which is how Reserved is reached', async ({ page }) => {
+  // The four-way status dropdown is gone, replaced by the Sold / Not sold / All
+  // preset from #105. Isolating a single status went with it, so this no longer
+  // covers "which is how Reserved is reached" — that ability was given up
+  // deliberately and is recorded on the issue. What remains testable, and what
+  // matters, is that Sold and Not sold partition the inventory.
+  test('filters by availability', async ({ page }) => {
     await page.goto('/admin');
     await filterToOwnCategory(page);
 
-    await page.getByRole('combobox', { name: 'Filter by status' }).click();
-    await page.getByTitle('Sold', { exact: true }).click();
+    await chooseAvailability(page, 'Sold');
 
     // Every fixture is available, so a Sold filter must exclude them all.
     await expect(row(page, NAMES.cheap)).toHaveCount(0);
     await expect(row(page, NAMES.mid)).toHaveCount(0);
     await expect(row(page, NAMES.dear)).toHaveCount(0);
+
+    // And Not sold brings back exactly what Sold excluded, which is the property
+    // that makes the two-way split trustworthy rather than merely plausible.
+    await chooseAvailability(page, 'Not sold');
+    await expect(row(page, NAMES.cheap)).toBeVisible();
+    await expect(row(page, NAMES.mid)).toBeVisible();
+    await expect(row(page, NAMES.dear)).toBeVisible();
   });
 
   test('combines filters, and clearing restores them', async ({ page }) => {

frontend/tests/e2e/sold-filter.spec.ts

@@ -0,0 +1,113 @@
+import { test, expect } from './fixtures';
+
+// The storefront shows every item ever seeded and the e2e database is not reset
+// between runs, so every fixture carries a unique run id and assertions name
+// only the items this run created.
+const RUN = `s${Date.now().toString(36)}${Math.random().toString(36).slice(2, 7)}`;
+
+const NAMES = {
+  available: `Available piece ${RUN}`,
+  sold: `Sold piece ${RUN}`
+};
+
+// Scoped to the item's own grid cell: the SOLD ribbon sits outside the card,
+// and other runs' sold items share the page.
+const cell = (page: import('@playwright/test').Page, name: string) =>
+  page.locator('.ant-col').filter({ hasText: name });
+
+// antd Segmented hides the real radio input behind a styled label, so the input
+// is found by role but cannot be clicked. The label carries a title attribute,
+// which is the same handle this suite already uses for antd Select options.
+// The input is still the right thing to assert checked-ness on: toBeChecked
+// does not require visibility.
+async function chooseAvailability(page: import('@playwright/test').Page, label: string) {
+  await page.getByTitle(label, { exact: true }).click();
+}
+
+test.beforeAll(async ({ playwright }) => {
+  const api = await playwright.request.newContext({ baseURL: 'http://localhost:5173' });
+
+  for (const name of [NAMES.available, NAMES.sold]) {
+    const res = await api.post('/api/admin/items', {
+      multipart: { name, description: '', price: '250.00' }
+    });
+    expect(res.ok()).toBeTruthy();
+    const { id } = await res.json();
+    // Items arrive pending since #90, so publishing is what makes them public.
+    expect((await api.post(`/api/admin/items/${id}/mark-available`)).ok()).toBeTruthy();
+    if (name === NAMES.sold) {
+      expect((await api.post(`/api/admin/items/${id}/mark-sold`)).ok()).toBeTruthy();
+    }
+  }
+
+  await api.dispose();
+});
+
+test.describe('Filtering the storefront by availability', () => {
+  // The change customers actually see. Asserted on a bare visit rather than on
+  // a parameter, because the default is what changed for everyone.
+  test('hides sold pieces by default', async ({ page }) => {
+    await page.goto('/');
+
+    await expect(cell(page, NAMES.available)).toBeVisible();
+    await expect(cell(page, NAMES.sold)).toHaveCount(0);
+  });
+
+  test('All brings them back, ribbon and all', async ({ page }) => {
+    await page.goto('/');
+
+    await chooseAvailability(page, 'All');
+
+    await expect(cell(page, NAMES.sold)).toBeVisible();
+    await expect(cell(page, NAMES.sold)).toContainText('SOLD');
+    await expect(cell(page, NAMES.available)).toBeVisible();
+  });
+
+  test('Sold shows only the sold ones', async ({ page }) => {
+    await page.goto('/');
+
+    await chooseAvailability(page, 'Sold');
+
+    await expect(cell(page, NAMES.sold)).toBeVisible();
+    await expect(cell(page, NAMES.available)).toHaveCount(0);
+  });
+
+  // The filter is view state that belongs in the URL, like every other filter
+  // here, so a chosen view can be linked and survives a reload.
+  test('the choice survives a reload, because it lives in the URL', async ({ page }) => {
+    await page.goto('/');
+    await chooseAvailability(page, 'All');
+    await expect(cell(page, NAMES.sold)).toBeVisible();
+
+    await page.reload();
+
+    await expect(cell(page, NAMES.sold)).toBeVisible();
+    await expect(page.getByRole('radio', { name: 'All' })).toBeChecked();
+  });
+
+  // Not sold is the default, so it is held as "no preference" rather than as an
+  // explicit list. Putting it in the URL would make the default look like a
+  // choice somebody made, and would show it in the Filters (N) count.
+  test('returning to Not sold leaves no status in the URL', async ({ page }) => {
+    await page.goto('/');
+    await chooseAvailability(page, 'All');
+    await expect(page).toHaveURL(/status=/);
+
+    await chooseAvailability(page, 'Not sold');
+
+    await expect(page).not.toHaveURL(/status=/);
+    await expect(cell(page, NAMES.sold)).toHaveCount(0);
+  });
+
+  // The control sits beside the Filters button rather than inside the drawer,
+  // so its state must not be counted as one of the drawer's filters.
+  test('does not inflate the Filters count', async ({ page }) => {
+    await page.goto('/');
+    await chooseAvailability(page, 'Sold');
+
+    // Matched loosely and asserted on the text, because antd's icon contributes
+    // its own aria-label to the button's accessible name. The text is the part
+    // that would gain a "(1)" if status were counted as a drawer filter.
+    await expect(page.getByRole('button', { name: /Filters/ })).toHaveText('Filters');
+  });
+});