Room list: unjoined project-room groups collapse behind one Browse entry #67
Loading…
Reference in a new issue
No description provided.
Delete branch "void/browse-collapse"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Libby's front-door finding: long groups of unjoined project rooms, each row a Join button, stand between the user and the first conversation.
Rule (pure,
splitGroupsinbuildEstate.ts): within a tier, a steward group in which the user has joined or been invited to any room stays up front exactly as before (unjoined siblings included). A group where every room is joinable moves behind one entry per tier, "Browse N more rooms". Loose estate rooms (Swarm, Operator, General, Members) and joined rooms are never grouped away.Behaviour: Browse is closed by default on every screen, which also satisfies the phone design law (inactive elements hide, vertical space is cheaper than horizontal). Opening it shows the groups as before, each still collapsible. The open state is remembered per device in the same closedNavCategories store as the other sections (key
estate|browse|<tier>).Tests: 4 new on
splitGroups(all-unjoined goes to Browse and loose rooms stay; one joined room keeps its group up front with siblings; an invite keeps its group up front, fails if the rule is narrowed tojoined; nothing is lost). vitest 607/607. The component wiring has no render test (no react renderer in the repo).Overlap: touches only
EstateNavigator.tsxTierandbuildEstate.ts; no change to the join path or tonavigator-s8-lowsitems.Not merged: for Libby to read. Not deployed.
🤖 Generated with Claude Code