Researched mosque-app and community-board best practices (MadinaAPPS,
Nextdoor) before building: the pattern that works is one-tap RSVP with
what/who/where/when up front, plus a clean separation between plain
announcements and dated events. Deliberately did NOT auto-populate a
global Islamic calendar (Eid/Ramadan dates) — those are moon-sighting-
dependent and hardcoding one as fact would be exactly the kind of
fabrication this app avoids everywhere else (real Overpass data, real
Quran API, no invented listings). The Event Board is community-submitted
only: a mosque posting its own Eid prayer time is real information: this
app guessing the date isn't.
Implementation extends the existing Neighbourhood board rather than
building a parallel system: nf_neighbourhood_posts gains is_event/
event_date/event_location, plus a new nf_event_rsvps table (RLS reuses
the existing nf_is_neighbourhood_member helper via a join, no duplicated
logic). UI adds an event toggle on the post form (reveals date/time/
location), a 📅-badged event card with one-tap 'I'm going' RSVP + live
count, and an All/Events/Announcements filter with events sorted
soonest-first.
Seeded a real demo neighbourhood, 'Masjid Al-Falah Kariah' (join code
ALFALAH), with all 5 demo family owners plus a mutawalli as members: 3
announcements and 4 dated, RSVP'd events (Jumu'ah khutbah, weekly Quran
circle, an Islamic finance/estate-planning talk tying back to the app's
own core purpose, and a Ramadan iftar potluck). Caught and fixed two
seeding bugs during verification: timestamps stored without timezone
context displayed several hours off from the intended Malaysia-local
time, and a 'Saturday' event that actually landed on a Sunday — both
fixed by computing against real weekdays/timezone rather than guessing
offsets.
Covered by e2e-event-board.cjs (14/14), including live verification that
the seeded demo neighbourhood renders its real content. Full regression:
all suites pass.
Per-member Insurance & Takaful tab (life/Takaful/medical/asset policies,
same author-owns/family-reads pattern as Wassiyah/Waqf), a family-shared
Liabilities section on the Asset Registry (kept distinct from assets since
Faraid requires debts settled before distribution), and dual-path asset
ownership verification (proof document + confirm by either the
mutawalli/agent or any other family member, since not every demo family
has an agent assigned). All proof documents share a new private
nf-asset-documents storage bucket with the same RLS pattern as person
photos. Mutawalli dashboard now surfaces each member's insurance policies.
Covered by e2e-insurance-verification.cjs (12/12); full regression sweep
233/233 across all suites.
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