feat(catalog): part-count signposting + drill hint for deep category trees
Some checks failed
QA Gate (P0/P1) / Test affected app (pull_request) Has been cancelled

pcat/emex vehicles decode into a tree whose top level is ~100% folders with
zero parts (6746/9458 root nodes are parents, 0 direct leaves across 477
vehicles). Users — serkan filazi among them — saw an opaque wall of identical
folder cards, assumed the parts feature was missing, and bounced without ever
drilling (his session: 3 view-mode toggles, 0 category clicks; his data was
2-3 clicks deep and fully reachable).

Two changes, no upstream/proxy cost:
- getCategoryTree now rolls up a subtree partCount per node (one grouped parts
  read + JS post-order sum). The grid already renders "N parça", so folders
  now read "Fren sistemi · 142 parça" and steer drilling toward the branches
  that actually contain parts; empty branches stay quiet. Counts reflect
  drilled data and grow as branches are visited.
- A one-line drill hint on a "cold" tree (nothing drilled yet → no counts) so
  first-visit users know parts live inside the subcategories instead of reading
  the folder wall as a broken/empty catalog. Drops away once any branch is hit.

Verified: subtree roll-up unit test + existing suite (10/10), tsc + biome clean
across api/web/shared.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-06-09 16:46:35 +03:00
parent fca2ff9cb4
commit 3482bb86e3
6 changed files with 65 additions and 4 deletions

View File

@@ -30,4 +30,8 @@ export interface CategoryNode {
parentId: string | null;
children: CategoryNode[];
hasSchema: boolean;
// Total parts known anywhere in this node's subtree (rolled up server-side).
// Lets the UI surface "N parça" on a folder and steer drilling toward
// populated branches. Reflects drilled data — grows as branches are visited.
partCount?: number;
}