fix: apply the amount/limit per project and reset the overview filter (#347, #348)

[timdegroot1996]

Fixes #347
Fixes #348

Problem

#347 — the amount filter sliced the combined run list before the overview grouped it by project, so a project with a lower run frequency could fall entirely outside the last X runs and disappear from the overview (not reduced — its whole section missing). The same held for retention: an unscoped -r limit=N kept the N newest runs globally and could wipe the entire history of a low frequency project while barely touching a busy one.

#348 — clicking a project card filters the dashboard to that project, but navigating back to the overview kept that filter, so the overview showed only the one project instead of all of them.

Root cause

• filter_amount() did filteredRuns.slice(-X) on the flat list; prepare_projects_grouped_data() groups after that stage.
• _remove_by_limit() dropped candidates[: len(candidates) - limit] across all runs unless the caller manually added tag= scoping.
• update_menu() re-runs the filter pipeline on every menu switch, so the selectedTagSetting/selectedRunSetting pre-filter set by the card click was still in effect on the way back.

Fix

One definition of a project, shared by the browser and the database: a run's run name plus every project_ run tag — the grouping the overview already uses. The keys are prefixed (name: / tag:) so a run name can never collide with a run tag.

• js/common.js — new get_run_projects(run).
• js/filter.js — filter_amount() groups run indexes per project and keeps the last X of each, unioned. A run is kept when it is in the last X of at least one of its projects, so the shown total can be higher than X. Index based, so chronological order and de-duplication come for free.
• database.py — _remove_by_limit() keeps the N newest per project (new _get_run_projects() helper). tag= scoping still narrows the candidates first, then the limit applies per project inside that scope. The new keep set is a strict superset of the old one, so this can never delete more than before.
• js/menu.js + js/filter.js — clear_overview_project_navigation_filter() runs when navigating to menuOverview and drops the card-applied filter, but only while the filter modal still holds exactly that filter, so anything the user changed by hand survives. The version filter is cleared only when the same navigation set it (version badge).

The filter modal documents this: the label is now "Amount per project" and its ⓘ popup explains the grouping and the "total can exceed X" consequence. The --quantity and -r limit= CLI help, the admin page label, the /remove-outputs API examples, docs/filtering.md, basic-command-line-interface-cli.md, performance.md, dashboard-server.md, custom-database-class.md and the README were updated to match.

Tests

Tier	Added	Proof
Python	3 new _remove_by_limit per-project tests; 4 existing ones rewritten to the new semantics	the 3 new tests fail with database.py stashed, pass with it
JS	get_run_projects (5 cases) + the per-project amount logic (6 cases)	311 passed
Robot	Validate Dashboard Amount Filter Is Applied Per Project, Validate Overview Resets The Project Card Filter When Navigating Back, Validate Overview Keeps Filters That Were Changed By Hand	with js/ stashed 2 of the 3 fail (showing 1 of 18 vs 2 of 18, 10 of 10 vs 18 of 18); the third is the guard test and passes either way

Full runs: 406 passed (python), 311 passed (javascript), 106 tests, 106 passed, 0 failed (robot, in Docker).

The run/runAmountFilter.png reference was regenerated from the Docker run: amount=5 now renders "showing 10 of 18 runs" (5 WebshopUI + 5 WebshopAPI), which is the intended new behaviour. The help.txt fixture follows the CLI help changes.

Notes

• example/robot_dashboard.html and example/robot_results.db were deliberately not regenerated — that belongs to the release procedure, and the per-project amount changes the example's default view.
• CHANGELOG.md is written at release time.

🤖 Generated with Claude Code