[paynejd]

What changed

From implementer feedback: on an org's repository list, a user couldn't find any filters and tried Sort By instead. The panel started closed there, and the only way to open it was an unlabelled icon.

• Labelled Filters button. The results toolbar's filter toggle is now a Filters button in the same style as Sort By and Display. It shows the number of applied filters, e.g. Filters (1), and sets aria-expanded. It reuses the existing search.filters key, so it's already translated in every locale: Filters / Filtros (es) / Filtros (pt-BR) / 筛选项 (zh). There are no new strings, so nothing needs pt-BR review.
• Starts open on wide screens. On repo pages and on org and user repository lists, the filter panel starts open at MUI's lg breakpoint and above (theme.breakpoints.up('lg'), 1200px) and closed below it. The new hook src/hooks/useDefaultFiltersOpen.js handles this.
• Your choice sticks. Once you open or close the panel, that choice is kept while you stay on the page. It survives tab, version and expansion changes (each of which remounts Search) and window resizes. Search gets an optional onFiltersOpenChange callback for this. Its own toggle is otherwise unchanged.
• Sort By and Display stay on one line. The labelled button is wider than the old icon, so these two buttons now get white-space: nowrap. Without it, Sort By wrapped onto two lines in a narrow toolbar (repo page at 1280px with a concept open).

Unchanged. Global search still starts with the panel open at every width. It does get the labelled button, because the toolbar is shared. The URL registry keeps defaultFiltersOpen={false}. It isn't a filterable resource, so it never shows the button anyway. Hierarchy view still has no filters and no button.

Breakpoint choice. At 1600px the repo page lays out well with filters open, with the summary panel or with a concept open. Between 1200px and 1535px, a repo page with a concept open and filters open is tight: the results column is about 480px at 1280px, and display names wrap (screenshot below). Moving the threshold to xl (1536px) changes one word in the hook. But at xl, most laptop widths (1280 to 1512px) would start closed, and those are where the original report came from.

Design system. Nothing new: the button is the existing toolbar control style (variant='contained' color='default' size='small').

Screenshots

These come from a local build against public prod content: the CIEL source and the WHO org. The member photo in the WHO summary is hidden.

Wide (1600px): filters start open	Narrow (1024px): filters start closed

One filter applied: Filters (1)	Concept open at 1600px	Concept open at 1280px (tightest case)

The screenshots/ocl_issues-2946 branch holds only these images. Delete it after review.

How I verified it

• Lint (CI's command) passes, and npm test passes (20/20).
• I drove a local dev build against prod data with playwright-core and checked aria-expanded and the button text:
  • Repo page (CIEL): open at 1600px and closed at 1024px. The panel opens at exactly 1200px and stays closed at 1199px.
  • Your choice sticks: closing it at 1600px, switching to Mappings, then resizing to 1024px and back leaves it closed. Reopening it and switching back to Concepts leaves it open. Loading at 1024px and then widening leaves it closed.
  • Count: applying one facet shows Filters (1).
  • Org repository list (WHO): open at 1600px and closed at 1024px. Opening it at 1024px, going to Overview and back leaves it open.
  • User repository list: open at 1600px and closed at 1024px.
  • Global search: open at 1024px, as before.
• There's no unit test. The new logic is a media query plus useState inside a React hook, and the repo's node test runner has no React renderer, so I checked it in the browser as above.

closes OpenConceptLab/ocl_issues#2946

🤖 Generated with Claude Code

https://claude.ai/code/session_01TjM9dGow2KV1Gwr2dWQdph

[paynejd]

Codex review, pass 1 (codex-cli 0.163.0, commit 97f0eee)

Verdict: findings (2 × P1)

• F1.1 (P1) SearchResults.jsx#L52: the applied-filter count it inherited counts an excluded facet's __exclude__ marker as a second filter, so excluding one value shows Filters (2).
• F1.2 (P1) SearchResults.jsx#L52: on a collection's References tab the count is always zero, because reference searches fetch no facets and the count is narrowed to facet fields.

findings.json

{
  "reviewer": "codex-cli 0.163.0",
  "perspective": "defects",
  "mode": "full",
  "commit": "97f0eeed",
  "verdict": "findings",
  "prior": [],
  "findings": [
    {
      "id": "F1.1",
      "severity": "P1",
      "tag": null,
      "file": "src/components/search/SearchResults.jsx",
      "line": 52,
      "claim": "The new label inherits a calculation that overcounts excluded filters, leaving the applied-count criterion unmet.",
      "scenario": "Exclude one datatype and apply it. The filter state contains both the selected value and __exclude__. The toolbar displays Filters (2), although only one value is filtered and the sidebar correctly counts one.",
      "action": "Omit EXCLUDE_FILTER_KEY when counting facet values, as SearchFilters already does.",
      "lines_delta": null,
      "confidence": "high"
    },
    {
      "id": "F1.2",
      "severity": "P1",
      "tag": null,
      "file": "src/components/search/SearchResults.jsx",
      "line": 52,
      "claim": "The new Filters button never shows the applied count on collection References.",
      "scenario": "Apply an inclusion_type filter on a collection's References tab. References results have facets: {}, so availableFilterFields becomes []. The inherited calculation picks no fields from appliedFilters and reports zero; the button remains Filters instead of Filters (1).",
      "action": "Count applied reference filters directly without restricting them to facet fields; reference searches do not fetch facets.",
      "lines_delta": null,
      "confidence": "high"
    }
  ]
}```

</details>

[paynejd]

Responses to Codex pass 1

• F1.1: fixed in a5929ec. The count leaves out __exclude__, the same way the filter panel's own count does. In the browser, excluding Drug on CIEL shows Filters (1), and Drug + Misc + N/A shows Filters (3).
• F1.2: fixed in the same commit. Reference counts are no longer narrowed to facet fields. Applying Extensional / Enumerated on a collection's References tab shows Filters (1). Separately, and already true on main: reloading a References URL with filter params doesn't restore those filters (the results come back unfiltered), so after a reload the count is correctly zero. That's out of scope here.

[paynejd]

Codex review, pass 2 (codex-cli 0.163.0, commit a5929ec)

Verdict: clean. F1.1 and F1.2 are resolved, and there are no new findings.

findings.json

{
  "reviewer": "codex-cli 0.163.0",
  "perspective": "defects",
  "mode": "verify",
  "commit": "a5929ecb",
  "verdict": "clean",
  "prior": [
    {
      "id": "F1.1",
      "status": "resolved"
    },
    {
      "id": "F1.2",
      "status": "resolved"
    }
  ],
  "findings": []
}```

</details>

[paynejd]

Simplification review (fresh Claude subagent, commit a5929ec)

Verdict: clean. It proposed no cuts: the three pages share one hook, the pass-1 fixes are small and needed, and every remaining change maps to an acceptance criterion. Nothing was committed after the reviewed commit, so no further Codex check was needed.

simplify.json

{"reviewer":"claude subagent","perspective":"simplify","mode":"full","commit":"a5929ecb","verdict":"clean","prior":[],"findings":[]}