Implements the researched IA fix: mobile nav UX consensus caps primary
destinations at 4-5 (uxpin.com, fintech/banking 2026 UX research), and
this app had grown to 22 tabs in one horizontally-scrolling row —
exactly the anti-pattern that research flags for choice paralysis and
slower task completion.
New structure — 5 bottom-nav hubs, grouped by what the user is actually
trying to do, not build order:
- Home: Coverage (unchanged, still the landing screen)
- Estate: Assets, Faraid, Insurance, Wassiyah, Hibah, Family Waqf,
Nominate, Claims (H2)
- Giving: Zakat, Sadaqah, Khairat
- Family: Tree, Trigger, Mutawalli, Manage (was 'Family', renamed to
avoid colliding with the hub's own label), Neighbourhood
- Daily: Prayer Times, Qibla, Quran, Locate
Each hub reveals its own sub-nav one tap in, instead of every tab
competing for space in a single row. Settings moved out of the tab
strip entirely into a header gear icon, matching the banking-app pattern
of keeping settings out of primary thumb-reach real estate. The bottom
nav is now fixed (thumb-zone), sub-nav keeps the old sticky-top position.
Cross-component navigation (nav.js requestedTab, used by the Family
Tree's 'give sadaqah in memory' link) now resolves a tab label to its
owning (hub, sub-tab) pair instead of a flat index — verified live.
This touches every E2E suite: a single click on a tab's old selector no
longer reaches it (hub, then sub-tab). Added a shared gotoTab(page, label)
helper to e2e-auth-helper.cjs encapsulating the two-step navigation, and
migrated all ~22 affected test files off direct nav-button selectors —
mechanical substitution followed by manual fixes for local clickTab
wrappers, template-literal selectors, and active-state assertions that
needed to target the new .hub-tab/.subnav structure specifically.
Full regression after migration: every suite passes (one isolated
Family Tree flake confirmed clean on rerun, unrelated to navigation).
Per explicit request: "full dummy data on at least 5 families with dummy
assets and family members." Seeded directly against the live Supabase
backend (SQL, not driving the UI 5x) for speed and reliability, then
verified through the actual live app rather than trusting the inserts.
5 families, each with a distinct role in demonstrating the app:
- The Ismail Family (100% coverage) — near-fully-planned estate: Hibah,
bank-mandate nomination, digital-custody (key-escrow) nomination,
business-continuity (company shares). Has an extra member (spouse) and
an agent/mutawalli.
- The Rahman Family (UK, 20% coverage) — diaspora market, partial
coverage, exercises Wassiyah (charitable bequest) alongside Hibah/
Nomination. Has an extra adult-child member.
- The Osman Family (31% coverage) — deliberately mostly UNCOVERED to
demonstrate the Coverage Dashboard's warning state and per-asset
suggestions; includes a sole-proprietorship business with the
waqf-enterprise redirect note.
- The Yusuf Family (94% coverage) — young family, digital-asset-heavy
(multisig nomination). Shares the same mutawalli/agent as Ismail —
demonstrates one professional agent managing multiple families.
- The Karim Family (100% coverage) — Family Waqf demo: an apartment
dedicated as corpus with a named mutawalli and successor.
Every fast-path channel type (Hibah, EPF/bank-mandate, digital-custody in
both multisig and key-escrow modes, business-continuity in both
company-shares and sole-proprietorship modes, trust, family waqf) and
every family role combination (owner-only, owner+member, owner+member+
agent, shared cross-family agent) now has at least one real example.
Each family also has a genealogy tree (3-6 people, parent/child and
spouse relationships) so the Tree tab is never empty for a demo.
DEMO_DATA.md documents all logins (shared password DemoPassword123!),
what each family demonstrates, and the verification method.
verify-demo-families.cjs: confirms all 5 families actually render
correctly in the live app, not just that the SQL succeeded — sign-in,
correct asset count, non-zero estate total, coverage percentage, correct
person count, non-empty tree render. 35/35 passing.
Also fixed a genuinely flaky e2e-uat.cjs assertion found while
re-verifying after seeding — same instant-isVisible()-after-fixed-wait
pattern already fixed elsewhere in this session, now using a proper
waitFor(). Stable across 3 consecutive runs (32/32 each). Full sweep
after seeding: e2e-fastpath 16/16, e2e-trust 12/12, e2e-business 10/10,
e2e-digital-vehicle 10/10, e2e-property 9/9, e2e-other 4/4, e2e-info
31/31, e2e-per-member 11/11, e2e-family-tree 9/9 — 209/209 total across
all suites plus the 35 demo-family checks.
wmj