wmj
33a821e61d
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).
Nur Falah — Estate & Waqf Suite
Horizon 1 (Prevention Suite) + Horizon 2 (Unlock Programme, pre-pilot demo) from the
Nur Falah PRDs, built as a standalone Svelte 5 + Vite PWA, styled to match the visual
system of the live moslem03.falahos.my (Nur Falah Muslim Companion) app.
Modules
| Module | Horizon | Status |
|---|---|---|
| Faraid Calculator | 1 | Shared calc core, 14 classical cases passing (src/lib/calc/faraid.test.js) |
| Asset Registry | 1 | Local-first, feeds every other module's estate total |
| Wassiyah Generator | 1 | 1/3 meter, heir-exclusion block, jurisdiction-aware export |
| Hibah Tracker | 1 | Shared marad al-mawt guardrail |
| Family Waqf Designator | 1 | Built ahead of scholarly sign-off — see below |
| Digital Beneficial Claims | 2 | Pre-pilot demo only — see below |
Important: two governance gates were overridden for this build
Per explicit product direction, this build proceeded past two gates stated in the project's own PRDs and review log:
- Family Waqf Designator (Horizon 1 PRD §8.5) is gated on scholarly sign-off.
scholarly-review-log.md(in thedigital-waqifdocs repo) tracks OPEN-01 — whether a healthy-state waqf is subject to the one-third cap — as unresolved. This module ships anyway; the in-app copy states the open question rather than presenting invented certainty. - Horizon 2 (Digital Beneficial Claims) PRD states: "No engineering work begins until Phase 0 (legal opinion + signed institutional partner agreement) is complete." No confirmation of Phase 0 completion was available. The Claims module ships as a local, non-custodial demonstration of the data model and transfer restriction only — no real legal wrapper, no institutional integration, no real claims issued. It carries a persistent in-app banner saying so.
Both are flagged here, in deploy/DEPLOY.md, and in the relevant module's source
comments so this isn't silently presented as production-ready.
Development
npm install
npm run dev # http://localhost:5173
npm run test # classical faraid test suite
npm run build
Deploy
See deploy/DEPLOY.md. Target: moslem04.falahos.my.