Taskboard: named filter presets

[RIP21]

Save the current filters under a name and reapply them in one click, from the board or the CLI. Builds on #11.

Stacked on #11. This branch is cut from that one, so its diff against main currently includes #11's commits. GitHub will not let me base a cross-fork PR on a branch that lives only in my fork. Once #11 merges, this diff reduces to the preset work alone — the seven commits from Add Taskboard filter preset module onward. Review those; everything before them is #11.

What it does

A Presets chip at the head of the filter bar lists the project's presets and applies one on click. "Save current filters as..." names the current chips. Rename, reorder, and delete live in Manage → Board preferences.

The same thing from the CLI:

bb taskboard presets list [--project <proj_id>] [--json]
bb taskboard presets save <name> --from-state <json> [--project <proj_id>] [--json]
bb taskboard presets rename <name> <new-name> [--project <proj_id>] [--json]
bb taskboard presets delete <name> [--project <proj_id>] [--json]
bb taskboard list --preset <name> [--project <proj_id>] [--json]

list --preset is the one that earns its keep. A preset spans both filtering layers, so source, stateCategories, and query go into store.list, and the rest is applied with filterWorkItemsByAttributes from browse.ts — the exact function the UI filters with, so the two cannot drift. An explicit --source or --query beats the preset's value. On a real project this narrows 200 cached items across 10 assignees down to the 37 belonging to one.

presets save --from-state is the weak verb and I want to be upfront about it: there are no chips to capture from a terminal, so the JSON is hand-written and nobody will use it in practice. It exists because the README promises human and agent parity and a half-CRUD surface is worse than a complete one. Happy to drop it if you would rather the CLI only read presets.

Design notes

No preset is ever applied automatically, and there is deliberately no default preset. #11 already makes filters sticky per project, so it decides what the board opens with. A default preset would compete with it for the same job, and two mechanisms racing to answer "what do I see on open" is worse than one.

Applying a preset is an ordinary filter change. It drives the same setters the user's own clicks do, so #11's debounced save persists it with no separate write path and no special case. Clicking "My work" today therefore means the board still shows it tomorrow.

A preset carries the List/Kanban view, and applying one replaces every field including clearing ones the preset leaves empty. A partial apply would make the result depend on what happened to be set already, which is not a preset.

Nothing tracks an "active" preset. No dirty state, no "update preset" prompt, no current selection on the chip. That would mean reconciling filter state against every preset on each change, and it is not needed to make one-click apply useful.

Presets store literal filter values. Taskboard has no concept of the current user — no source fetches viewer identity — so "assigned to me" is whatever assignee string the chip held at save time. Resolving a real @me token would need a per-source identity lookup and cache; a reasonable follow-up, out of scope here.

Implementation notes for review

Ordering and naming rules live in a pure module, filter-presets.ts, so they are unit-testable without a database. This repo has no DB-backed test and every existing test is a pure-function test, so the store stays thin deliberately rather than accidentally.

normalizePresetName uses locale-independent toLowerCase(), unlike board-settings.ts which uses toLocaleLowerCase() for status names. That one is an in-memory check; this value is persisted as name_normalized and backs a UNIQUE constraint, so it must not vary by host locale. Under tr-TR the locale-aware form folds U+0130 to a bare i, which would make two names collide on one machine and not another.

A preset row that fails to parse hides one preset rather than breaking the list. reorderFilterPresets therefore validates against the parseable subset, not the raw rows — otherwise a single corrupt row would reject every reorder for that project forever, since the client can only send ids it was shown.

deleteFilterPreset on an unknown id is a deliberate idempotent no-op, while save and reorder throw. Commented at the definition so it does not read as an oversight. Callers resync from the returned list rather than trusting a local delta.

The Manage mutations are serialized behind a single in-flight flag. Rename, delete, and move each return a fresh authoritative list, so a slower earlier response landing after a faster later one would clobber it.

The CLI keys on names but every store method keys on id, so a single resolvePresetByName helper resolves case-insensitively via normalizePresetName and, when it misses, names the presets that do exist. rename resends the preset's existing state, since saveFilterPreset always requires it.

Verification

npm run check passes from the workspace root. Unit tests cover name normalization, the length bounds, and reorder permutation validation.

Exercised against a running bb, through the UI, directly over RPC, and through the CLI: create, case-insensitive duplicate rejection, case-only self-rename accepted, list ordering, reorder rejection on a non-permutation, delete, idempotent re-delete, list --preset narrowing, explicit-flag precedence, the unknown-preset error naming what is available, and the empty-project message.

🤖 Generated with Claude Code