fix(685): AddItemsDialog resolves by search instead of windowing the whole media-library type #741

Merged

timothy merged 5 commits from fix/685-additems-searchpicker into main 2026-08-05 20:02:00 +02:00

Conversation 1 Commits 5 Files Changed 6

+627 -49

5 Commits

Author	SHA1	Message	Date
timothy	7be42654fe	fix(685): suppress both empty-states on error; name the addable-kind derivation ... Round-4 verification returned MERGEABLE with no new defects and no BLOCKER/HIGH/MEDIUM. These are its remaining LOW and nits. - "No results — try a search above." asserts a search that COMPLETED and found nothing, so it was false beside a failed request. Both empty-state messages are now suppressed on error and the role="alert" banner is the whole message, as that test's comment already claimed. Pinned positively and negatively so a refactor cannot satisfy the assertion by rendering nothing at all. - The (typeof ADDABLE_TYPE_LIST)[number] derivation is now the named AddableKind, spelled once instead of twice: a third ingress into the searched kinds is most likely to be written by copying one of the existing two, and the "one list, all ingresses" property should be visible at a glance rather than reassembled. - The §3b lesson cited two measured test counts, which go stale against the very suite they describe — a count taken before the helper had unit tests no longer holds now that it does. Scoped the observation to the sha it was measured on and replaced the counts with the invariant they were evidence for: every gate needs at least one test that reddens when that gate ALONE is removed. - Documented why the error banner stays conditionally mounted while the hint's live region does not: role="alert" is the one live-region role screen readers reliably announce on insertion, so the two are correct for opposite reasons. The review flagged the divergence as unexplained, not as wrong. refs #740	2026-08-05 19:40:07 +02:00
timothy	d7725c274c	fix(685): close the second ingress; stop the error path claiming a short query ... Verification round returned MERGEABLE with all three blocking findings resolved by measurement. These are its four remaining items. - DEFAULT_SEARCH_KINDS was the SECOND ingress into the searched kinds and was not derived, so the previous commit's "enforced by the type system" claim held for one of two paths. A non-addable kind there typechecked clean and would have overstated the hint with every one of its rows dropped — the exact defect the derivation exists to prevent. Now derived; verified by mutation that adding 'Collection' to it is a compile error. - The error path fell into the min-query guidance branch, so a valid 2-character query that got a 500 told the user to type at least 2 characters. That branch conflated "nothing searched yet" with "the last search failed". Newly introduced by the previous commit's error-path reset; now gated on !error and pinned by a test. - The aria-live region was mounted conditionally, creating the region and its text in one commit — which most screen readers do not announce. It is now mounted unconditionally with the condition inside. - The §3b lesson mis-stated where the duplicate gate lived: it was inside runSearch, the genuine single sink, NOT at one of the callers — so the rule as written ("put the gate in the single sink, not at each caller") described the revision that was rejected. Reworded to the actual lesson: the gate's home is the shared helper, and "it's the single sink" is not evidence it is the only guard. That misreading is why #685 got this wrong twice. Declined again, with reasons: the NaN pageSize edge (faithful to the sibling helper), the clamp test's unpinned lower bound (same), and the registry's disclosed same-identity substitution gap. refs #740	2026-08-05 19:20:26 +02:00
timothy	b6bf94f129	fix(685): test the helper's bound; delete the masking duplicate gate ... Independent review round 2 returned BLOCKED on two findings, both correct. - The helper's bound was dead code to the suite. searchLibraryBrowseItems had zero tests, so deleting its clamp OR its gate left the whole suite green — while the registry note claimed a caller "cannot skip the bound". That is the previous round's finding relocated, not removed. It now has the three tests its sibling searchLibraryPickerOptions already had (clamp, gate, compile), plus one pinning the full-row return that is its reason to exist. - The screen kept a second copy of the min-query check, and the two masked each other: the 1-character boundary test passed with EITHER gate alone, so it pinned nothing. The screen's copy is deleted; the helper is the sole gate. Measured before/after: with the duplicate present, removing the helper's gate left that test green; with it gone, the same removal reddens it. - §3b contradicted itself two lines apart — the parent still said "there is no truncation, so there is no truncation hint" above a sub-bullet mandating one. Reworded so a hint is permitted, required only where bulk selection makes the count actionable. Same correction to the 'search-bounded' definition. - A failed search left results/totalMatches stale, rendering a confident "Showing 75 of 60000 matches" beside the error banner. The catch clears them. - Results now carry a `Results for "<query>"` heading and the guidance is keyed to the settled query, not the live input, so rows are never shown without saying which search produced them. `selected` persists across queries (correct for a multi-select picker); the Add button's count keeps it discoverable. - The hint sums pre-filter totalCount against post-filter rows, which is only correct because every filterable kind is addable. MediaKindFilter is now derived from ADDABLE_TYPE_LIST, making that a compile error rather than prose. - aria-live on the hint; the #740 doc caveat no longer overstates the typeahead rule as a mandate this screen violates. Declined: the NaN pageSize edge (copied faithfully from the sibling helper) and the registry's same-identity substitution gap (already disclosed in that file). refs #740	2026-08-05 19:08:13 +02:00
timothy	4be3f247d8	fix(685): move the picker bound into the helper; surface the per-kind cap ... Independent review round 2. Verdict was MERGEABLE with no blockers; this takes the two recommended fixes plus the structural one it listed as a follow-up. - The bound was caller discipline, not code: getLibraryBrowseItems does not clamp pageSize, so the bound was only the constant this one call site chose to pass, and §3b is explicit that a bound a caller can exceed is not a bound. New searchLibraryBrowseItems in libraryBrowse.ts owns the min-query gate, the pageSize clamp and the titleContainsQuery compile, returning full LibraryBrowseItem rows plus totalCount (searchLibraryPickerOptions' {id,name} shape loses the mediaType that toAddItemsRequest needs). runSearch keeps one early return, for the spinner only, and no longer re-implements the gate. - The min-query guidance was keyed to the LIVE input, so backspacing below the gate after a search wiped the rendered rows and their checkmarks while `selected` and the Add button still counted them. Keyed to results.length too. - "Nothing left to hint at" was false: each kind is still capped at LIBRARY_PICKER_RESULTS and totalCount was never read. This is a bulk multi-select add, so the cap is surfaced — per-kind totalCounts are summed and rendered as "Showing N of M matches" once it exceeds the rendered rows. The registry note and the §3b bullet are corrected to stop claiming otherwise. - Gate boundary tested at 1 character (§3b: inclusive endpoints, or a > for >= slip passes the whole suite). - The guard test's deviation loop iterates an empty list now, so it gains one bidirectional assertion that is non-vacuous: the set carrying an `issue` field must equal the set classified 'deviation'. - The §3b bullet no longer reads as a conformance certificate: AddItemsDialog still lacks the seqRef and useIsMountedRef guards §3b mandates. That defect is PRE-EXISTING, not introduced here, and is tracked in #740. refs #740	2026-08-05 18:46:43 +02:00
timothy	28ce8c4dfe	fix(685): gate AddItemsDialog on a real query instead of windowing the whole type ... AddItemsDialog.runSearch was reachable with an empty query two ways — a blank form submit, and a kind-chip click, which called it immediately — and getLibraryBrowseItems omits a falsy `query`, so each path degraded into an unfiltered browse of the whole media-library type (first 50 rows, per kind) presented as the answer with nothing surfacing the truncation. All ten ADDABLE_TYPE_LIST entries are spa-conventions §3b Class B media-library types. The dialog is multi-select, so §3b's SearchPicker (single-select) does not fit; it takes §3b's constraints instead: - no request below LIBRARY_PICKER_MIN_QUERY, enforced in runSearch — the single sink both entry paths route through, not duplicated per caller - typed text compiled with titleContainsQuery rather than forwarded raw (a second latent §3b violation here: the search index's default field does not match bare title words) - each kind bounded to LIBRARY_PICKER_RESULTS - merged.slice(0, 50) removed — it silently dropped up to 100 of 150 fetched rows even for a real query Tests assert zero requests below the gate on both paths, exactly one bounded request per kind above it (20k-row fixture), the compiled+escaped query, and that no fetched row is dropped. Each was verified to fail with its mechanism removed. The pageSize registry entry moves from `deviation` to `search-bounded`. That leaves zero deviation entries, so the anti-vacuity assertion guarding that list is deleted deliberately, per its own instruction. Done-when box 4 (collection-family truncation hint) has no subject: this screen offers no collection-family type. fixes #685	2026-08-05 18:46:43 +02:00